회사의 제품은 MSA(Micro-Service Architecture)로 이루어져있다.
지금까지 내가 참여한 프로젝트는 대부분 Monolithic Architecture로 이루어져있었다.
따라서 해당 Architecture가 생소했고, 새롭게 알아야하는 부분들도 많았다.
Monolithic Architecture
소프트웨어의 모든 구성 요소가 한 프로젝트에 통합되어 있는 형태를 의미한다.
예를 들어 아래 이미지와 같이 택시 호출 애플리케이션을 구축한다고 하자.
전체 애플리케이션 내부를 살펴보면 Billing, Payments, Passenger & Driver Management 등
여러 모듈들이 존재하지만, 그 모든 것이 하나의 단일체로 패키징되어 있다.
그리고 하나로 패키징한 애플리케이션을 WAS(Web Application Archive) 파일로 빌드하고,
WAS(Web Application Server)에 배포한다면 이를 Monolithic Architecture라 할 수 있다.
Monolithic Architecture의 장점은 심플함이다. 따라서 개발, 빌드, 배포, 테스트가 용이하다.
그러나 프로젝트의 규모가 커질 경우 복잡도가 증가한다는 단점이 있다.
그 결과 개발자의 애플리케이션에 대한 이해도가 낮아지는 것은 물론,
버그를 수정하거나 새로운 기능을 구현하는 것이 어려워진다.
또한, 작은 수정 사항에도 애플리케이션 전체를 새로 빌드하고 배포해야하며,
이로 인해 CI(Continuous Integration), CD(Continuous Delivery, Deployment)가 어려워진다.
Micro-Service Architecture
Micro-Service Architecture는 Service-Oriented Architecture의 일종으로,
소프트웨어를 작고 독립적이며 느슨하게 결합된 모듈들로 구성하는 형태를 의미한다.
아래 이미지와 같이 각 모듈들은 개별적인 작업을 담당하며 독립적으로 개발, 배포가 가능하며,
모듈들은 잘 정의된 API를 통해 서로 다른 모듈과 통신한다.
Micro-Service Architecture에서는 각각의 모듈이 독립적이다.
따라서 개발자는 자신이 담당한 모듈을 이해하고 해당 모듈에 집중하여 개발을 진행할 수 있다.
또한, 특정 모듈이 변경되거나 오류가 발생하더라도 다른 모듈에 미치는 영향이 적다.
새로운 기술이나 기능을 적용해보기 쉬우며, 서로 다른 언어로 프로그래밍하는 것도 가능한다.
CI, CD를 구성 역시 Monolithic Architecture보다 쉬워진다.
그러나 분산 시스템이기에 갖는 단점들이 존재한다.
예를 들어, 모듈 간의 통신과 데이터 정합성을 위한 추가적인 작업이 필요하며,
분산되어 있는 모듈들을 통합해서 테스트하는 것 역시 어렵다.
단순히 개념적으로 Micro-Service Architecture를 이해하는 것은 어려운 문제가 아니었다.
회사 제품 코드를 보면서 제품 내 API Gateway 역할이 무엇인지,
서로 다른 모듈들은 어떻게 통신하고, 데이터의 정합성을 맞추는지 확인하는 것이 쉽지 않았다.
이후에 작성할 회고 내용 대부분이 이와 관련한 내용이다.
참고 자료 1) - Microservice architecture style
참고 자료 2) - Introduction to Microservices
