강의

멘토링

로드맵

인프런 커뮤니티 질문&답변

오늘 ONEUL님의 프로필 이미지
오늘 ONEUL

작성한 질문수

시스템 디자인 첫걸음: 면접에서 돋보이는 백엔드 아키텍처 설계하기

서버와 서버 간 통신

MSA 전환 시점

해결된 질문

작성

·

16

0

안녕하세요!

덕분에 아키텍처에 대한 큰 그림을 그려보며 강의를 듣고 있습니다.

 

MSA 전환 시점 관련해서 질문 드립니다.

모놀리식 아키텍처에서 MSA로 전환하는 적절한 시점은 어떤 기준으로 잡는게 좋을까요?

물론 상황마다 다르겠지만, 강사님은 어떤 기준을 가장 중요하게 생각하시는지 궁금합니다.

예를 들어, Scale-out 한계, 빌드&배포 시간 증가, 혹은 서비스 크기와 복잡성 같은 요소들.. 이 있을 것 같은데 제가 미처 생각 못한 부분이 있다면 덧붙여 답변 부탁드립니다.

감사합니다!

답변 2

1

성장랜턴님의 프로필 이미지
성장랜턴
지식공유자

안녕하세요 오늘님! 어려운 질문이네요 😄
말씀해주신 것처럼 성능적인 이유나, 비즈니스 로직마다 적합한 기술 스택이 다른 경우 등 MSA를 도입할 이유는 다양합니다.
하지만 개인적으로는 강의에서도 언급했듯이 도메인과 데이터가 가장 중요한 기준이라고 생각합니다.

 

조금 더 구체적으로 말하자면, 비즈니스가 성장하면서 데이터의 생명주기(데이터가 생성되고, 성장하고, 다른 데이터와 연결되는 흐름)가 명확히 구분되기 시작할 때가 MSA 전환을 고려(도입이 아닌!) 해볼 시점이라고 봅니다.
이 시점이 오면 도메인별 데이터의 성장 속도나 방향이 달라지면서, 한 도메인의 변화가 다른 도메인에 영향을 주거나 개발/배포 과정에서 병목이 생기기 쉽습니다. 예를 들어 한 서비스의 작은 변경 때문에 전체 배포를 미루거나, 다른 개발자의 작업까지 영향을 받는 상황이 반복된다면 분리를 고려해볼 신호라고 생각합니다.

그리고 개발 외적이지만 팀의 규모와 MSA 전환에 대한 구성원 간 합의 수준도 중요한 요소라고 생각합니다.
MSA는 단순히 모듈 수만 늘어나는 것이 아니라, 각 서비스마다 별도의 설정, DB, 배포 파이프라인, 모니터링 체계 등이 필요해지고, 모듈 간 협업을 위한 개발자 간 커뮤니케이션 비용도 생깁니다.
관리 포인트가 단순히 두 배가 아니라, 실제로는 세~다섯 배 이상 늘어나게 됩니다.
그래서 팀 규모가 이런 복잡도를 감당할 수 있는지 (유지보수를 쉽게 하려고 분리했는데 정작 담당할 사람이 없는 상황이 생기지 않을지) 고민해봐야 합니다.

그리고 어떻게 도메인을 분리할지에 대한 팀의 공감대가 형성된 시점에 전환을 고려해보는 것이 좋습니다. 아직 성숙하지 않은 서비스에서 각각의 도메인에 대한 정확한 이해 없이 성급히 분리하면 나중에 차라리 다시 합치는 게 낫겠다는 생각이 들 수도 있습니다.

결론적으로는 분리로 인한 오버헤드를 감안하더라도 도메인과 데이터의 성장 관점에서 분리가 필수적이라는 확신이 팀 내에서 충분히 공유된 시점에
점진적으로 정말 필요한 도메인부터 분리해 나가는 게 좋다고 생각합니다.

오늘 ONEUL님의 프로필 이미지
오늘 ONEUL
질문자

구체적인 답변 감사드립니다!

데이터의 생명 주기 뿐만 아니라 구성원 간 합의 수준도 굉장히 중요하겠군요..! 관리 포인트가 어마무시하게 늘어나네요.

좋은 답변 주셔서 많이 도움 되었습니다, 감사합니다 :)

0

안녕하세요, 인프런 AI 인턴입니다. 오늘 ONEUL님.

MSA(Microservices Architecture)로의 전환 시점은 여러 가지 요소에 의해 결정될 수 있으며, 이는 각 조직과 프로젝트의 대상 조건에 따라 달라집니다. 모놀리식 아키텍처에서 MSA로 전환할 때 고려해야 할 몇 가지 주요 기준에 대해 소개드리겠습니다.

  1. Scale-out 한계: 모놀리식 아키텍처가 특정 서비스나 기능의 급격한 확장을 방해하고 있다면 MSA로의 전환을 고려할 수 있습니다. MSA는 더 나은 확장성을 제공하며, 각 서비스가 독립적으로 확장될 수 있기 때문입니다.

  2. 빌드&배포 시간 증가: 모놀리식 애플리케이션의 경우 코드베이스가 커질수록 빌드와 배포 시간이 크게 늘어날 수 있습니다. 이는 배포 주기를 지연시키고 개발 효율성을 저하합니다. MSA는 독립적인 서비스 단위로 코드 및 배포를 관리하여 이러한 문제를 해결할 수 있습니다.

  3. 서비스 크기와 복잡성: 서비스가 복잡해지거나 여러 그룹에서 동시에 개발을 진행해야 하는 경우, 서로의 작업이 간섭하는 것을 방지하기 위해 MSA로 전환하는 것이 좋습니다. MSA는 개별 팀이 별도의 서비스에 집중할 수 있도록 하여 효율성을 높입니다.

추가적으로 고려해야 할 사항들에는 조직의 역량 (예: MSA 운영에 필요한 경험과 지식), 도메인 경계의 명확성 (각 마이크로서비스의 책임이 명확하게 정의되어야 함), 그리고 서비스 간 통합과 데이터 관리 (MSA 환경에서 서비스 간 데이터의 일관성과 동기화 문제를 해결할 수 있는 준비가 되어 있어야 함) 등이 있습니다.

관련하여 보다 구체적인 사례 탐색 및 논의는 아래의 Q&A 게시판에서 진행된 답변들을 통해 확인하실 수 있습니다:
- 멱등성. ‘같은 요청’의 기준?

이처럼 다양한 요소들을 종합적으로 고려해 각 상황에 맞는 최적의 전환 시점을 판단하는 것이 중요합니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

오늘 ONEUL님의 프로필 이미지
오늘 ONEUL

작성한 질문수

질문하기