layout: post title: 마이크로서비스와 SAGA 패턴 categories: [dev] author: 김동현 email: [email protected] date: 2022-01-28 tag:
기존의 프로젝트들은 단일 애플리케이션 위에 각 기능이 켜켜히 쌓아 올려지는 모놀리식(Monolithic) 아키텍처가 대부분이었습니다. 초기에 구조를 잡기에도 편리하고 하나의 구조 위에서 설정과 변경이 가능하기 때문에 테스트하기 용이하다는 장점을 가지고 있습니다.
그러나 프로젝트가 점점 비대해지면서 수많은 문제점들이 드러나게 되는데, 추가와 변경이 반복되면서 점점 복잡해지는 로직을 파악하기가 어려워지고, 빌드 시간도 길어지게 됩니다. 코드 한 줄 수정하는 데도 전체를 다시 빌드해야 하기 때문에 비효율적이고, 각 기능별 버전 관리 또한 통합되기 어려워 프로덕션 배포 시 어느 부분을 빼고 어느 부분을 더해야 하는지 확인하는 것 또한 문제가 됩니다.
이런 점들을 보완하기 위해 도입된 것이 애플리케이션을 여러 단위로 쪼개는 마이크로서비스(Microservices) 입니다.
출처: https://microservices.io/index.html
쇼핑몰을 구축한다고 하면 위 그림과 같이 프론트, 계정, 보유 상품, 배송 서비스 등으로 각각의 애플리케이션을 구축해서 일정한 양식을 통해(주로 REST API를 통한) 각 애플리케이션 간 통신을 하여 유기적으로 동작하게 됩니다.
개발 조직들은 각각의 서비스를 맡아서 따로 개발하고, 배포도 단위별로 할 수 있으며, 각 애플리케이션 별로 별도의 개발 스택을 사용할 수도 있기 때문에 유연한 구축, 변경, 분리가 가능해집니다.
그러나 마이크로서비스라고 장점만 있는 것은 아닙니다. 마이크로서비스는 모놀리식 아키텍처와 반대의 장단점을 가지고 있다고 볼 수 있습니다. 분리되어 있기 때문에 통합된 테스트를 하기가 어렵고, 배포할 때 각 서비스 간 호환 버전이 맞아야 하기 때문에 조율이 필요합니다. 또한 적절하게 서비스를 분리하기 힘들고, 마이크로서비스 또한 규모가 커지게 되면 각 서비스의 연결 관계와 동작이 어떻게 이루어지는지 파악하기가 힘들어 관리 포인트가 증가할 수 있습니다.
이런 단점에도 불구하고 마이크로서비스가 주는 이점이 크기 때문에 단점을 최소화 하기 위한 여러 가지 아키텍처 패턴들이 고안되어 왔습니다.
오늘은 그 중에서 데이터 정합성(Consistency)을 위한 패턴인 SAGA에 대해 알아보고자 합니다.
서비스들을 분리하면 각 서비스가 동일한 데이터베이스를 사용할 수도 있고(용도와 권한 관리 필요성에 따라 스키마 분리, 또는 테이블을 따로 사용할 수도 있습니다), 서비스마다 데이터베이스를 각각 사용할 수도 있습니다.
이 때 복수의 데이터베이스를 처리해야 하는 경우 트랜잭션(transaction) 처리에 곤란한 상황이 발생하게 됩니다.
