마이크로서비스 패턴 1장

모놀리스 지옥에서 벗어나라

MSA 패턴 책을 읽고 내용을 정리합니다.

모놀리스 설계의 시작

리소스가 적은 상태에서의 애플리케이션의 첫 삽은 모놀리스 식 애플리케이션은 생산성있고 관리와 개발이 적합한 구조라고 생각한다.
FTGO 라는 음식배달 서비스를 예를 든다.
하나의 비즈니스 로직을 담은 애플리케이션 모듈로 구성되어 있고 REST API / 웹 UI를 처리하는 인바운드와 그 밖에 외부 서비스를 처리하는 아웃바운드 어댑터로 구성하여 하나의 WAR 로 패키징해서 실행/배포 되게끔 구성을 하게 된다.

이러한 구조는 개발이 간단하고 애플리케이션을 쉽게 변경할 수 있고 테스트하기 쉬우며, 배포 및 스케일 아웃(LB 에 확장한 인스턴스를 실행)하기 쉽다.

모놀리스 방식의 복잡함 대두

여전히 하나의 소스 코드 저장소와 개발 파이프라인을 통해 하나의 애플리케이션을 개발한다. 개발자가 많아져 특정 컴포넌트의 단위로 팀이 나누어진다.
이는 팀간에 소통이나 일정 조정 등의 오버헤드를 유발할 수 있고 CI/CI도 마찬가지이며 프로덕션에 배포되기 까지 신경써야 할 것들이 생길 것이다. 애플리케이션은 점점 무거워지고 서로의 연관관계도 파악이 힘들어질 것이며 이는 사이드 이펙트를 야기시키고 버그도 여럿 발생할 여지가 커진다. 규모가 커지면서 아래와 같은 단점이 발생할 수 있다.

단점

• 컴포넌트 마다 리소스를 최적의 상태로 배분하기 힘들어진다. (메모리 vs cpu 집약적)
• 테스트의 어려움
• 기술 스택의 도입
• 더딘 개발

마이크로서비스로의 전환

비대해진 애플리케이션을 위의 단점을 해소하기 위해 어떠한 확장 모델을 소개한다.

X, Z 축은 모놀리스식 애플리케이션에서도 사용 가능한 확장 수단이며 가용성이 개선된다 하지만 여전히 복잡하다. Y 축을 보면 특정 기능을 단위로 서비스를 나눈다. 어떻게 보면 미니 서비스들을 X, Z 축과 같은 확장 수단을 개별적으로 적용할 수 있어진다.

MSA 는 API 간 정확히 말하면 모듈 간에 경계선을 갖고 있어 서로 독립된 상태로 배포/확장할 수 있다. 이는 곧 서비스(모듈)마다 DB 가 자체 갖고 있어 API 를 통해서만 통신이 가능하다.

참고)) SOA vs 마이크로서비스
SOA : SOAP 등 무거운 기술을 쓰고 전역 데이터 모델링과 디비를 공유하고 복잡한 모놀리스식 애플리케이션을 통합하는 용도로 사용되어 왔다.
MSA : REST/gRPC 처럼 가벼운 프로토콜을 이용한 메시지 브로커등을 사용하고 서비스 개별 데이터 모델링 및 디비 소유, SOA 보다 소규모 서비스

장점

• 크고 복잡한 애플리케이션을 지속적으로 전달/배포할 수 있다.
• 서비스가 작아 관리하기 용이
• 서비스 독립적으로 배포/확장할 수 있다.
• 결함 격리가 잘된다.
• 신기술 시험/도입하기 쉽다.

위의 장점을 보면 어느정도 모놀리스식 아키텍쳐의 단점을 보완했다고 할 수 있겠다. 하지만 단점도 존재한다.

단점

• 분산 시스템은 너무 복잡해 개발/테스트/배포가 어렵다.
  • 서비스 간 통신, 지연시간 처리, 부분 실패한 서비스에 대한 Circuit Breaker 도입, DB 트랜잭션
• 여러 서비스에 걸친 기능을 배포할 땐 주의가 필요.
• 도입 시점

MSA 아키텍쳐로 도입하기 위한 패턴

MSA 로 전환하기 위한 애플리케이션에 따른 서비스/배포방식/데이터/인프라 등을 위한 패턴이 구성돼있다.
자세한 건 다음 번에..

• 서비스를 어떻게 분리할 것인지?
• IPC(프로세스간통신) 종류? 신뢰성 ? 트랜잭셔널 메시징을 통한 행위들의 관리 ? 외부 API 통신?
• 데이터 일관성 유지(사가패턴)
• 배포, 관측, 보안 등등

1장을 읽고

대부분의 소규모, 신규 프로젝트 들은 제한된 리소스와 프로덕트의 빠른 생산을 위해 모놀리스식 설계를 지향하며 실제로 진행하고 있다. 실제로 나 조차 그러한 경험을 많이 했고 모놀리스식 애플리케이션의 장단점을 모두 경험해보았다.
규모가 커지면서 모놀리스 식 애플리케이션을 개선하기 위해 부분적으로 특정 배포 단위로 서비스를 나누기도 해보았지만 완벽하진 않았기에 모든 것이 그렇듯 제대로 알고 전환하지 않으면 MSA 향이 묻어있는 모놀리스 식 앱일 뿐이다.

여럿 그렇듯 MSA 에서 다시 모놀리스 식으로 돌아온 팀의 사례도 보았고 책에서도 언급하지만 MSA로 전환했지만 적합한 서비스가 아님에 모놀리스식으로 회귀하는 모양새도 보았다.

만병통치약은 아니지만 어떤 식으로 접근하고 적용할 수 있는지에 대해 알면 모놀리스 식이든 MSA 든 장점을 살려 개발해나갈 수 있지 않을까 한다.