79e98271bd866ffe23e681e1409c701813726e6083a706d34f4d71298bec743e5a6b85989db5e2de5c283098766d4ecf95401e3e6a

이론상 고점같은 느낌임

특정 서비스가 트래픽이 몰려서 스케일아웃을 해야할때 거대한 모놀리틱인 경우 다 늘려야되지만 MSA 로 잘 나누어 놓앗으면 필요한 서비스만 스케일아웃을 하면된다 라고 하는데, 애초에 저런 고민을 하게되는 프로덕트라면 그때 해도 늦지않은듯

저런 고민을 하게된단건 병목이 생겨서 서비스가 터져나가는게 아닌이상 잘되는 서비스라는거잖아?

그런데 그렇게 잘되기도 하고 돈도 잘벌어오는 서비스를 VC들은 절대로 가만안놔둠

그 VC들이 투자하겟다고 돈을줄텐데 그 돈으로 그런 경험 해본사람들 데려와서 해도 절대늦지않더라

---

그리고 쿠버네티스니 그안의 서비스메시니 사이드카니 메시지브로커니 하기전에 가장먼저 코드베이스를 도메인으로 잘쪼개야함


“대충 이럴거같은데?” 하고 이 기능은 무슨서비스 이 기능은 무슨서비스 하고 나눠놓으면 나중에 신규기능개발하다가 “아” 소리 외치면서 줄담배만 늘어갈거임

그렇다고 에릭에반스의 도메인주도설계 반버논의 도메인주도설계실습을 후루룩 보면 “이건 어디에 가야한다” 라고 말이 딱 나오느냐? 

그거도 아님

이벤트 스토밍같은 과정들로 교통정리를 잘한다음 그거로 바운더리를 묶어내야함

근데 그거하려면 결국 시간이 있어야 하고 시간은 곧 돈인데 자금이 후달려서 당장 비즈니스 임팩트 내야하는 스타트업 입장에서 이 과정을 현실적으로 할수있을까? 

그나마 그래도 이건 코드레벨에서 해볼수있는 좋은 도전이고 첫단추인만큼 해보는걸 추천하고싶음

---

그 다음단계론 데이터베이스의 트랜잭션을 서비스레벨의 트랜잭션으로 대체하는게 난관이엇음

MSA 에서 트랜잭션 문제는 어떻게 할거냐는 이야기에 사가나 아웃박스 패턴을 쓴다 롤백은 보상트랜잭션을 구현한다 라고 대답은 다들 하겠지

근데 직접 그거 해보면 코드 꽤 머리 아파짐

스프링은 그나마 스프링스테이트머신이라는 스프링딱지달고나오는 라이브러리도잇고 예제도 좀잇는거같다만 노드나 고 같은 것들은 말그대로 그런역할을하는 오케스트레이터 만드는거부터 맨땅에 머리박으면서 해야함

물론 저렇게 여러 이벤트 묶어서 트랜잭션 만드는걸 가급적 피해야한다고는 하는데 결국엔 피할수없는 문제가 되드라 

특히 커머스같은경우...

---

인프라 비용이나 고수준으로 추상화된 컨테이너 환경의 이해에서 오는 어려움 이전에 개발자 입장에서 당장 해결해야 하는 문제들을 좀 적어봄

돈은 잘버는데 전환을 안하면 인프라 비용이나 개발자 경험이 박살나버려서 회사의 살자각이 날카롭게 서는게 아닌이상 서비스 복잡도는 최대한 줄이고 뭔가를 하고싶다면 코드레벨부터 해봅시다 

예를들면 테스트 가능한 구조로 잘 바꾸고 테스트 코드를 짜나간다든가 저위에말한 도메인주도설계를 코드에 잘적용해본다든가 클린아키텍처라는거로 어플리케이션의순수성이니뭐시기를 도메인객체를만들어서 뭐 그런거


우리가다니고잇는회사는... 베를린의 잘란도나 사운드클라우드가 아니니가... 잠실의 쿠팡이나 우아한형제들이 아니니가...

---

물론 여기있는 사람들을 보면 “헉 마이크로서비스 그거 완전 엑셀팡션이구나” 한다기보단 “맞다시팔 나도 MSA 대전환 메타의 희생자다” 라고 이야기할 쳐맞아본사람들이 많아보여서 전혀의미없어보인다만 그냥적어봄

여담으로 저런 MSA류의 자매품으로 이전+그당시엔 TDD, 요즘은 BFF 가 대가리를 드는거같음