Summary

MSA(Micro Service Architecture)

• 각각을 마이크로하게 나눈 독립적인 서비스를 연결한 구조
• 시스템 전체의 중단 없이 필요한 부분만 업데이트·배포가 가능
• 유연한 대응이 가능→  실시간으로 요구사항을 반영할 수 있어 급격히 성장한 기업들이 많이 택한 방법
• 각각 독립적인 서비스로 이루어져 있기 때문에 모듈의 인터페이스를 신중하게 처리해야 하고 제약들도 많음
• 분산된 서비스마다 분리된 DB의 트랜잭션 관리 및 서비스간 충돌 가능성 등 사전 체크 필요
• 거시적인 관점에서는 빅뱅(Big Bang) 방식을 택할지, 스트랭글러(Strangler) 방식으로 추진
• 핵심요소는 서비스의 크기를 결정하고 나누는 과정과 각 서비스가 독립성을 가질 수 있도록 아키텍처를 설계하는 과정
• 서비스간에는 API로 호출 →  API First Design
• MSA 설계시 업무의 흐름과 중요성, 그리고 형태 관점에서 서비스를 나눠볼 수 있음
• 업무의 흐름(예: 플로우 상에서 분리)
• 업무의 중요도(예: 핵심/비핵심)
• 업무의 형태(예: 실시간/배치성)

장점

• Monolithic Architecture와 달리 서비스 개발 범위를 최소화할 수 있어, 빠르게 가능하며 유지보수도 쉽게 가능하다.
• 팀 단위로 기술스택을 다르게 가져갈 수 있고, 배포도 독립적으로 간으하다.
• 각 서비스 부하에 따라 개별적으로 Scale Out을 할 수 있기 때문에 비용 효율적으로 운영 가능

단점

• Monolithic Architecture 대 싱대적으로 매우 복잡하다.
• Transaction 유지를 위해  각 서비스별로 체크를 해야하는 제약사항이 많기 때문에 상대적으로 어렵다.
• 통합 테스트가 매우 어렵다.
• 실제 운영환경에서 배포하기 위해서는 다른 서비스 연계과정을 체크해야 하는데 쉽지 않다.
• 각 서비스간 다른 개발환경인 부분에 대해서 관리를 해야 하고 통제가 어렵기 떄문에 통합 관점에서 운영을 하는게 쉽지 않기 떄문에 자칫하면 오히려 생산성이 저하될 수 있다. → 인력을 추가하면 되지만 한계가 있다.
• 세그먼트(Segment)는 MSA에서 Monolithic Architecture로 회귀(링크)

생각

• MSA  관점에서 데이터는 굳이 나눠질 필요가 없다. 데이터는 도구일 뿐 각 서비스의 관점에서는 하위관점에 속하기 때문이다.
• 하지만 AI 조직은 다를 수 있겠다.  모든 모델을 통합하여 API로 제공하되 MLOps를 기반으로 해서 제공하여 파편화되기 쉬운 부분을 서비스라는 기치 아래 통합하여 제공하면 하나의 서비스 단위로 간주할 수도 있겠는데, 앞서 언급한 설계시 관점과 위배가 될 수 있기 때문에 고민이 필요하다.
• 그리고 데이터를 활용하는 조직으로 Feature를 만들기 위한 스트림 구조를 어떻게 설계할지 등  Input소스가 상대적으로 매우 많아지는 상황에서 MSA가 효율적이지는 않을 수 있기 때문에 충분한 추상화를 통해서 모델 설계를 통해 서비스를 제공하는 상황에서 타 서비스 아키텍처 대비 다소 복잡할 수 있어 Kafka등의 메세지 스트림과 Feature Store를 잘 정의함으로써 모델러가 서비스에 오롯이 집중할 수 있는 구조를 가져가는 것이 필요하겠다.
• 잡설이 길었지만, 유지보수 가능하고 확장 가능하며 장애에 대응하기 위해서는 MSA 설계시점의 철학을 확인할 필요가 있겠다.

References

• 요즘 대세 MSA, 마이크로 서비스 아키텍처!
• 실패하지 않는 MSA 전환, 두 가지만 기억하세요! 1편
• "마이크로서비스는 답이 아니었다"··· 세그먼트가 모놀리틱으로 돌아온 이유