코레오그래피 패턴
IT 위키
코레오그래피 패턴(영어: Choreography Pattern)은 마이크로서비스 아키텍처에서 각 서비스가 이벤트 기반으로 독립적으로 작동하며 전체 흐름을 자율적으로 구성하는 설계 패턴이다.
정의[편집 | 원본 편집]
코레오그래피 패턴은 여러 서비스가 비동기 이벤트 기반으로 상호작용하면서 워크플로우의 흐름을 중앙에서 제어하지 않고, 각 서비스가 자신의 책임을 수행하고 다음 서비스를 트리거하는 방식으로 설계되는 구조이다. 다시 말해, 주문-재고-배송 등의 단계가 있을 때 각 단계의 서비스가 해당 이벤트를 받고 처리한 뒤 다음 이벤트를 발행하여 흐름을 이어가는 형태다.
주요 구성 요소 및 작동 방식[편집 | 원본 편집]
- 서비스(Service): 각 기능 단위로 독립적으로 존재하며, 자신의 로직을 수행한다.
- 이벤트(Event): 서비스 간에 흐름을 연결하는 메시지이며 보통 메시지 브로커나 이벤트 버스를 통해 전달된다.
- 구독(Subscribe) / 발행(Publish): 서비스는 자신이 관심 있는 이벤트를 구독하고, 처리 완료나 상태 변화 시 다음 이벤트를 발행한다.
- 흐름(Workflow): 중앙 오케스트레이터가 흐름을 제어하지 않고, 각 서비스가 자신의 조건과 이벤트에 따라 다음 단계로 흐름을 이어간다.
장점[편집 | 원본 편집]
- 서비스 간 느슨한 결합(loose coupling)이 가능하다. 중앙관리자가 없으므로 서비스 추가/삭제가 비교적 자유롭다.
- 비동기 통신이 기본이므로 시스템 확장성이 높고, 다양한 흐름을 유연히 처리할 수 있다.
- 중앙 오케스트레이터로 인한 단일 실패점(Single Point of Failure)이 제거되거나 감소한다.
단점 및 고려사항[편집 | 원본 편집]
- 전체 시스템 흐름을 추적하기 어렵다(traceability, observability). 어느 서비스가 어떤 이벤트를 발생시켰는지 파악하기가 복잡해질 수 있다.
- 서비스 수가 많아지면 테스트, 통합, 디버깅 복잡도가 급격히 증가한다.
- 이벤트 기반 설계이므로 메시지 중복, 순서 보장, 실패 보상(보상 트랜잭션이나 롤백) 등의 문제에 주의해야 한다.
적용 가능한 상황 및 예시[편집 | 원본 편집]
적용에 적합한 경우[편집 | 원본 편집]
- 여러 독립 서비스가 있으며, 각 서비스가 자신의 역할을 수행하고 결과를 이벤트로 알려 다음 단계로 이어지는 워크플로우가 존재할 때.
- 흐름이 비교적 단순하고, 중앙관리자 없이 분산형 방식으로 확장하고자 할 때.
예시[편집 | 원본 편집]
온라인 쇼핑몰 시스템에서:
- 주문 서비스가 “주문 생성됨” 이벤트를 발행한다.
- 재고 서비스가 해당 이벤트를 구독하고 재고를 확인한 뒤 “재고 확보됨” 이벤트 또는 “재고 부족” 이벤트를 발행한다.
- 배송 서비스가 “재고 확보됨” 이벤트를 받아 배송 프로세스를 시작한다.
이와 같이 각 서비스가 흐름을 직접 관리하고 이벤트 기반으로 이어가는 방식이 코레오그래피 패턴이다.
오케스트레이션 패턴과의 비교[편집 | 원본 편집]
| 항목 | 코레오그래피 패턴 | 오케스트레이션 패턴 |
|---|---|---|
| 흐름 제어 위치 | 분산된 각 서비스 내부 | 중앙 오케스트레이터 존재 |
| 결합도 | 낮음 (느슨한 결합) | 상대적으로 높음 (중앙 제어) |
| 확장성 | 높음 | 서비스 추가/변경 시 중앙 로직 변화 가능성 있음 |
| 흐름 추적성 | 어려움 | 중앙에서 관리하므로 상대적으로 용이 |
주의 사항 및 설계 팁[편집 | 원본 편집]
- 이벤트 설계 시 이벤트 명칭, 의미, 상태 변화 등을 명확히 해야 한다.
- 메시지 브로커(예: Kafka, RabbitMQ 등)를 활용해 이벤트 유실이나 순서 문제 등에 대비해야 한다.
- 로그나 추적(Tracing) 시스템을 구축해 분산 흐름에서 어디서 문제가 생기는지 파악할 수 있어야 한다.
- 서비스가 실패했을 때의 보상 트랜잭션(compensation transaction) 설계도 검토해야 한다.
- 흐름이 너무 복잡하거나 서비스 간 의존 관계가 많아질 경우 오케스트레이션 패턴이 더 적합할 수도 있다.
결론[편집 | 원본 편집]
코레오그래피 패턴은 복잡한 중앙관리 없이 마이크로서비스끼리 자율적으로 이벤트 기반 흐름을 만들어가는 방식으로, 느슨한 결합과 확장성 측면에서 유리하다. 다만 전체 흐름의 가시성, 디버깅, 서비스 복잡성 증가 등의 단점이 있으므로 설계 초기부터 흐름 설계, 이벤트 명세, 모니터링/로깅 등을 꼼꼼히 준비하는 것이 중요하다.
같이 보기[편집 | 원본 편집]
참고 문헌[편집 | 원본 편집]
- Microsoft. Choreography pattern. Azure Architecture Center.
- AWS. Saga Choreography pattern. AWS Prescriptive Guidance.
