작은 서비스들의 집합으로 전체 서비스를 구현하는 기법이다. 작은 서비스들은 각각을 Deploy 할수 있기 때문에 장애 상황이나 업데이트에 더 유연하게 대처할수 있다. 다만 실용적인 레벨에서는 각 서비스 별로 빌드/배포하는 것이 매우 귀찮은 작업이기 떄문에 기본적으로 빌드/배포 시스템이 모두 자동화 되어 있어야 하고, 이를 이해하는 수준 높은 개발팀에서 시행할수 있다.
Docker 가 그런것 처럼 MSA도 모든 문제를 한방에 해결해줄 “요술지팡이” 일수 없다. MSA는 각 서비스별로 잦은 배포, 재시작, 순단 등이 일어 날수 있기 때문에 다른 서비스들이 언제든 fail 할수 있다고 가정한채로 작성 되어야 한다. 이를 위해 service 간 통신에 반드시 cache, proxy, 로드밸런서 등이 필히 필요하게 된다. k8s 나 다른 clustering 도구들이 이 문제를 해결하는데 도움이 될수 있지만, 완벽할수는 없다. 각 컴포넌트 서비스 개발자가 이러한 사항을 잘 알고 있는 상태에서 작성되어야 하며, 각각의 서비스들에 대한 모니터링 도구도 필요하다. MSA를 가장 잘하는 netflix 의 opensource 가 모두 이러한 tool들인것은 결코 우연이 아니다.
MSA 를 시도하면서 가장 자주 실수하는것은 서비스를 기존과 같이 최대한 죽지 않게 하려고 하는 것이다. MSA에서는 문제가 생기는 상황, 예를들면 과도한 메모리 사용률 상승, 예기치 못한 deadlock 등, 을 재시작, Scale in/out 으로 해결 하는것이 가장 좋은 해결법이다. 잘 설계된 MSA 에서는 그 과정에서 생기는 자잘한 문제는 무시할수 있을정도로 작을것이며, 서비스의 운영작업을 단순하게 만들어 개발과 운영작업을 분리하거나 개발자가 side job 정도로 운영을 하기 쉽게 만든다. 다만 이 시스템을 구축하는데 드는 비용을 공짜가 아니며, GCE 나 AWS는 이 시스템을 최대한 싸게 제공하는 플램폼중 하나이다. 그래서 넷플릭스는 VM 하나에 수배나 비싼 AWS를 적극적으로 사용하는 것이다. 그만한 시스템을 구축하는데는 훨씬 많은 비용이 들어가니까.
No. 절대 그럴수 없다. 서버 비용은 오히려 증가한다. MSA의 금융적인 장점은 서비스의 유연함과 장애 복구의 자동화 운영의 자동화 등등에서 오는 전체적인 운영 비용(대부분은 비싸디 비싼 개발자의 시간 낭비)의 감소이다.