46P by xguru 10달전 | favorite | 댓글 13개
  • "Monolith > apps > services > microservices"
  • 첫째, 이건 규칙은 아니고 내 생각이 그렇다는 것. 대규모 분산 시스템을 구축해 본 사람은 실제로 그대로 작동하지 않으며, 적응해야 한다는 것을 알고 있음
  • 둘째, 단계가 중요함
    • 5-50인 회사라면 그냥 Monolith로 가세요
    • 1만명 회사라면, 위의 모든 것들을 다 가지고 있을 것. 근데 예전과 달라진 생각들을 얘기해보자면..

먼저 정의(Definition) 부터

  • monolith - xyz.com
  • apps - abc.xyz.com
  • services - 앱/모노리스를 지원, 핵심 인프라, 핵심 컴플라이언스 기능, 앱팀에서 작성하지 않을 수 있음(인프라에서 유지관리)
  • microserivces - 몇백라인의 코드, 대부분 일회성, 라이브러리 또는 SDK 일수/있어야(could/should) 함

Why ? : 기본적으로 "Speed & Risk" 때문

  • #1 전체 개발팀이 하나의 빅앱(전체 사이트가 Rails앱 이라고 생각해 볼 것)에서 개발하는게 더 쉬움
  • #2 성장하면 필수로 가지게 될 분산시스템은, 자체적으로 위험한 수백개의 마이크로서비스 없이도 이미 추론하기가 어려움
  • #3 완전히 마이크로로 간다면, 무분별한 확장을 처리하기 위해 새로운 개념을 도입해야 함
  • #4 맞춤형(Bespoke) 인프라 서비스 또는 마이크로서비스는 부채의 극단적 개념임. 코드도 부채이지만 서비스가 그것의 극단적인 버전. 이게 뭘 의미하는지 생각해 볼 것. 레버리지 포인트가 되게 할 것
  • 분산 시스템 엔지니어들은 중복되는걸 싫어하기 때문에 뭔가가 여러데서 이뤄진다면 "이걸 빼내서 마이크로 서비스를 만들자" 라고 생각함
  • 이론적으로는 이게 맞고, 일이십개 까지 되는 것은 괜찮음. 하지만 수십개가 넘어가거나 대규모 회사를 넘어서 사용된다면 기술 문제가 아니라 조직의 문제가 됨
  • 내가 이야기 하는 것이 잘못된 이분법 처럼 느껴지긴 하지만, 실제로 마이크로서비스에 대해서는 기술적인 도전들이 있고, 더 많은 조직적인 문제도 있음

내가 우려하는 것은

  • #1 (특이하게 IT출신 CEO가 이끌지 않는 한) 인프라는 항상 우선순위에서 밀려남(get the short end of priority stick)
  • #2 서비스가 너무 많으면 일반적으로 소유권 문제 및 경계 문제가 생김
  • #3 수많은 마이크로서비스를 처리하기 위해 더 많은 도구를 도입함
  • #4 가장 중요한 것은 라이브러리나 SDK가 되었어야할 각 마이크로서비스들이 프로덕션에 위험을 초래함

일반적으로 내가 추천하는 것은

  • #1 가능하면 최대한 오래 Monolith를 유지
  • #2 서비스는 인프라에 필요한 것에서 시작하고, 앱 개발쪽에서 시작하지 말 것
  • #3 Mono를 쪼개야 한다면, 작은 서비스들이 아닌 큰 앱들로 분해할 것
  • #4 각 새로운 앱은 회사내의 가상 벽이라고 생각할 것
  • #5 가능하다면 마이크로서비스 대신 라이브러리를 선호

마지막 부분 우려와 추천 부분이 공감되네요.
사실 회사 규모나 서비스 규모나 비슷한 맥락이고, 쪼개지 않으면 안 되는 순간이 올텐데 그걸 미리 대비하는 탁월한 판단이 필요하겠다라고 느꼈습니다.

회사 규모가 아니라 시스템 규모에 따라 달라져야 되는 거 아닌가? 내가 msa 를 잘못 이해하고 있었나?

윗 댓글중에
마이크로서비스의 문제가 아니라 무분별한 서비스의 확장이 문제가 아닐까요?
라는 의견에 일단 동의하고, 회사가 커질수록 배포 문제+브랜치 관리같은 모노리스 자체의 단점이 너무 명확하게 드러나기 때문에 비용과 생산성간의 trade off 를 잘 선택해야할 것 같네요

너무 좋은 글이네요. 감사합니다.

디자인패턴 중요성 논란? 과 비슷한거 같아요.
디자인패턴이라는게 다양한 문제를 해결하는 과정에서 도출 된 코드 패턴들인데....
어디까지나 상황에 맞게 필요에 의해서 응용 & 적용해야 하는데.....

모범답안 마냥 디자인 패턴이 필수이고 몰입하는 사람들이 종종 있죠...

요즘 MSA 관련해서도 비슷한게 무조건 MAS...인 사람들이 많아지는거 같습니다.

닭이 먼저냐 달걀이 먼저냐 같은 말 같아요.
마이크로서비스의 문제가 아니라 무분별한 서비스의 확장이 문제가 아닐까요?

적절한 균형이 중요하다고 생각이 듭니다.
마이크로서비스로 가게 되면 새로운 기능 = 새로운 마이크로 서비스로 귀결될 수 있는 점 때문에,
관리가 점점 어려워지는것이 아닐까 싶네요.

대체로 제 생각과 일치합니다.
저희 회사의 개발자는 5명이라 아직까지는 monolith(RubyOnRails)를 지향하는게 맞다고 생각됩니다.
위 글 처럼 50인 이상이 동시에 개발하는 프로젝트가 되면 그때는 두 번째 monolith를 개발하게 될거 같습니다.

5-50인 회사라면 그냥 Monolith로 가세요 << 이는 개발자수가 아니라 총 구성원의 수겠죠?

회사 규모를 말하는 것 같아요~

가능하면 최대한 오래 Monolith를 유지 < 극공감합니다. 분리하면서 유지비용 늘어나는게 커요

MSA가 도그마화 되어 가는 것에 대한 반동으로서의 글이라 생각이 되고, 그런 점에서 의미가 있겠다 싶습니다.

이전에 Segment 기술 블로그에 올라온 'Goodbye Microservices' 라는 글이 떠오르네요.
Segment 역시 CDP라 굉장히 많은 데이터를 실시간으로 처리함에도 불구하고, Microservices에서 Monolith 구조로 전환하며 그 이유 등을 블로그에 정리해놓았습니다. 이 글과도 일정 부분 맞닿아있다고 생각이 듭니다 :)

https://segment.com/blog/goodbye-microservices/