모놀리식 지옥

이 글은 책 마이크로서비스 패턴 정리하여 쓴 글입니다.

기존 모놀리식 아키텍쳐의 장점

• 개발이 간단하다.
  - IDE 등 개발 툴은 단일 어플리케이션 구축에 초점이 마주어져 있다.
• 어플리케이션을 쉽게 변경할 수 있다.
  - 코드, DB 스키마를 변경해서 빌드/배포하기 용이하다.
• 테스트하기 쉽다.
• 배포하기 쉽다.
  - 서버에 톰캣경로에 WAR 파일만 복사하여 두면 된다.
• 확장하기 쉽다.
  - LB(LoadBalancer) 인스턴스를 여러개 실행할 수 있다.

하지만 서비스가 커질 수록 개발, 테스트, 배포, 확장이 어려워진다.

모놀리식의 지옥도

서비스와 팀이 커지면서 모놀리식 아키텍쳐는 불안해진다.

• 서비스가 커질 수록 빌드/실행/테스트 시간이 늘어나, 개발 생산성이 떨어진다.
• 소스코드를 하나의 저장소에 Murge하는 것에 소통/조정 간 오버헤드(어떤 처리를 하기 위해 들어가는 간접적인 처리 시간 · 메모리 등)를 유발한다.
• 개발 파이프라인을 거치는 동안의 테스트 과정이 복잡하고 오래걸린다.
• 장애대응이 늦어질 수 있다.
• 빠른 서비스 배포가 불가능하다.
• 서비스를 확장하기 어렵다.
• 기술 스텍을 쉽게 바꿀 수 없다.

그렇다면 모놀리식 지옥에서 벗어나려면 어떻게 해야 할까.

다음글에서 모놀리식 지옥에서 벗어날 아키텍처에 대해 소개하려 한다.