이 글은 책 마이크로서비스 패턴 정리하여 쓴 글입니다.
기존 모놀리식 아키텍쳐의 장점
- 개발이 간단하다.
- IDE 등 개발 툴은 단일 어플리케이션 구축에 초점이 마주어져 있다.
- 어플리케이션을 쉽게 변경할 수 있다.
- 코드, DB 스키마를 변경해서 빌드/배포하기 용이하다.
- 테스트하기 쉽다.
- 배포하기 쉽다.
- 서버에 톰캣경로에 WAR 파일만 복사하여 두면 된다.
- 확장하기 쉽다.
- LB(LoadBalancer) 인스턴스를 여러개 실행할 수 있다.
하지만 서비스가 커질 수록 개발, 테스트, 배포, 확장이 어려워진다.
모놀리식의 지옥도
서비스와 팀이 커지면서 모놀리식 아키텍쳐는 불안해진다.
- 서비스가 커질 수록 빌드/실행/테스트 시간이 늘어나, 개발 생산성이 떨어진다.
- 소스코드를 하나의 저장소에 Murge하는 것에 소통/조정 간 오버헤드(어떤 처리를 하기 위해 들어가는 간접적인 처리 시간 · 메모리 등)를 유발한다.
- 개발 파이프라인을 거치는 동안의 테스트 과정이 복잡하고 오래걸린다.
- 장애대응이 늦어질 수 있다.
- 빠른 서비스 배포가 불가능하다.
- 서비스를 확장하기 어렵다.
- 기술 스텍을 쉽게 바꿀 수 없다.
그렇다면 모놀리식 지옥에서 벗어나려면 어떻게 해야 할까.
다음글에서 모놀리식 지옥에서 벗어날 아키텍처에 대해 소개하려 한다.