전 GitHub CTO, "지난 10년간 가장 큰 아키텍처 실수는 풀 마이크로서비스로 전환한 것"
(twitter.com/jasoncwarner)- "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 가능하다면 마이크로서비스 대신 라이브러리를 선호
마지막 부분 우려와 추천 부분이 공감되네요.
사실 회사 규모나 서비스 규모나 비슷한 맥락이고, 쪼개지 않으면 안 되는 순간이 올텐데 그걸 미리 대비하는 탁월한 판단이 필요하겠다라고 느꼈습니다.
윗 댓글중에
마이크로서비스의 문제가 아니라 무분별한 서비스의 확장이 문제가 아닐까요?
라는 의견에 일단 동의하고, 회사가 커질수록 배포 문제+브랜치 관리같은 모노리스 자체의 단점이 너무 명확하게 드러나기 때문에 비용과 생산성간의 trade off 를 잘 선택해야할 것 같네요
디자인패턴 중요성 논란? 과 비슷한거 같아요.
디자인패턴이라는게 다양한 문제를 해결하는 과정에서 도출 된 코드 패턴들인데....
어디까지나 상황에 맞게 필요에 의해서 응용 & 적용해야 하는데.....
모범답안 마냥 디자인 패턴이 필수이고 몰입하는 사람들이 종종 있죠...
요즘 MSA 관련해서도 비슷한게 무조건 MAS...인 사람들이 많아지는거 같습니다.
적절한 균형이 중요하다고 생각이 듭니다.
마이크로서비스로 가게 되면 새로운 기능 = 새로운 마이크로 서비스로 귀결될 수 있는 점 때문에,
관리가 점점 어려워지는것이 아닐까 싶네요.
이전에 Segment 기술 블로그에 올라온 'Goodbye Microservices' 라는 글이 떠오르네요.
Segment 역시 CDP라 굉장히 많은 데이터를 실시간으로 처리함에도 불구하고, Microservices에서 Monolith 구조로 전환하며 그 이유 등을 블로그에 정리해놓았습니다. 이 글과도 일정 부분 맞닿아있다고 생각이 듭니다 :)
대체로 제 생각과 일치합니다.
저희 회사의 개발자는 5명이라 아직까지는 monolith(RubyOnRails)를 지향하는게 맞다고 생각됩니다.
위 글 처럼 50인 이상이 동시에 개발하는 프로젝트가 되면 그때는 두 번째 monolith를 개발하게 될거 같습니다.