MSA를 언제 도입하는 게 적절한 지 파악하기 위해, 기존에 글로벌 기업들이 어떤 상황에서 MSA를 도입했는 지 사례를 몇 가지 살펴보자.
✅ MSA 도입 사례
여러 기업들은 다양한 나름의 이유를 기반으로 MSA를 도입했다. 유명한 글로벌 기업들의 MSA 도입 사례들을 살펴보자.
넷플릭스(Netflix)
2008년 발생한 데이터베이스 손상 사고로 인해 서비스가 중단되는 경험을 한 후, 시스템의 안정성과 탄력성 확보를 위해 MSA로 전환했다. 넷플릭스는 MSA를 통해 매우 빠른 배포 속도를 확보하고, 각각의 기능을 독립적으로 확장하여 대규모 트래픽을 안정적으로 처리할 수 있게 되었다.
아마존 (Amazon)
아마존은 "모든 팀은 2개의 피자만으로 먹을 수 있는 규모여야 한다"는 원칙 아래 MSA를 도입했다. 이는 소규모 팀이 각자 맡은 서비스를 독립적으로 개발하고 운영하는 것을 목표로 합니다. 아마존은 MSA를 통해 거대한 전자상거래 플랫폼을 유연하고 빠르게 확장할 수 있었으며, 다양한 신규 서비스를 신속하게 배포해서 시장에 선보일 수 있었다.
우버 (Uber)
우버는 초기 모놀리식 아키텍처가 성장 속도를 따라가지 못하는 문제에 직면했다. 새로운 기능을 추가하거나 수정할 때마다 복잡성이 증가하고 배포 시간이 길어졌습니다. 우버는 MSA로 전환하여 승객, 운전자, 결제 등 핵심 기능을 독립적인 서비스로 분리했습니다. 이를 통해 개발 속도를 높이고, 각 서비스의 확장성을 확보하여 글로벌 서비스를 안정적으로 제공할 수 있게 되었습니다.
위 기업들의 사례를 보면 크게 3가지 이유 때문에 MSA로 전환을 했다.
신속한 배포
대규모 트래픽를 안정적으로 처리
시스템 안정성 확보
위 3가지 이유는 우리가 이전에 배웠던 MSA의 핵심적인 장점 3가지랑 완전히 일치한다.
서비스별 독립적인 배포 → 배포 사이클이 빨라짐
데이터베이스의 독립적인 분리 → 대규모 트래픽 처리 용이
서비스를 독립적으로 분리 → 장애 전파를 최소화
이런 사례를 기반으로 언제 MSA로 전환하는 게 좋은 지 대략적으로 유추할 수 있다. MSA로 언제 전환하는 게 좋은 지 알아보자.
✅ MSA로 언제 전환하는 게 좋을까?
모놀리식 아키텍처로 프로젝트를 관리하고 운영하면서 다음과 같은 문제를 만날 때 MSA 전환을 고민하면 된다.
프로젝트 규모가 크거나 또는 개발자 인원이 너무 많아서 배포 사이클이 느려진 경우
모놀리식 아키텍처에서는 도저히 감당할 수 없는 트래픽이 발생하는 경우
모놀리식 아키텍처로 인한 장애 전파의 횟수가 잦거나, 한 번의 장애 전파도 서비스에 치명적인 경우
위 3가지 이유 중 하나라도 해당한다면 MSA 전환을 고려해보면 된다.
하지만 MSA로 전환해보면 알겠지만 모놀리식 구조보다 훨씬 복잡하고 전환하는 데 많은 시간과 비용이 들어간다. 따라서 MSA로 전환했을 때 얻는 이득이 더 큰 지를 신중하게 따져보고 전환을 시도해야 한다.
