1. 데이터 쿼리 패턴
MSA 소프트웨어 아키텍처를 설계하면서 생긴 "데이터 쿼리"의 어려움을 해결하기 위한 패턴으로 모놀리식 아키텍처에서는 한개의 DB에서 Table간 Join을 통해 처리가 가능했지만 MSA에서는 각 서비스 별로 다른 DB를 사용하기에 Query로 Join을 사용하기에 어려움이 있다. 따라서 이를 해결하기 위해 API Aggregation, CQRS 2가지의 패턴을 사용한다.
(1) API Aggregation(API 조합) 패턴
여러 서비스로부터 정보를 모아서 하나의 응답으로 제공해주는 패턴입니다.
- 장점
- 한번의 요청으로 필요한 데이터를 모두 얻을 수 있습니다.
- 서비스 간의 상호작용이 API 게이트웨이 내에서 수행되기 때문에 클라이언트 로직이 단순해집니다.
- 각각의 MSA는 독립적으로 진화, API 게이트웨이만 적절히 업데이트
- 단점
- 많은 요청이 올 경우 API 게이트웨이에서 지연될 가능성이 높아 병목 지점이 될 수 있습니다.
- 여러 서비스의 응답을 모아 처리하는 로직이 복잡해집니다.
(2) CQRS 패턴
Command(Write, Update, Delete) 작업과, Query(Read) 작업의 Endpoint를 분리하고 Command에서 발생된 데이터의 변경을 이벤트 발행을 통해 원하는 포맷대로 Query를 위한 전용 데이터 구조를 만들어 이곳에서 복잡한 Query를 담당
-
장점
- 명령과 조회를 분리함으로서 각 부분을 독립적 사용 가능
- 읽기 전용 모덱을 따로 설계하여 조회 성능과 구조를 최적화 가능
-
단점
- 기존의 CRUD 패턴보다 구현이 복잡해짐
2. 가시성 패턴
MSA 소프트웨어 아키텍처를 설계하면서 생긴 로깅, 모니터링의 어려움(가시성의 부재)을 해결하기 위한 패턴
가시성이란?
각각의 마이크로서비스가 자체적으로 운영 상태, 성능, 로그, 모니터링 등에 대한 정보를 외부로 노출하고 관리할 수 있는 능력을 가리킵니다. 이는 각각의 마이크로서비스가 독립적으로 운영될 수 있고, 문제가 발생했을 때 빠르게 대응할 수 있도록 해줍니다. 이를 위해 로깅, 분산 추적, 모니터링 등의 기술이 활용되며, 이를 통해 전체 시스템의 건강 상태를 파악하고 문제를 해결할 수 있게 됩니다.
3. 신뢰성 패턴
MSA 소프트웨어 아키텍처를 설계하면서, 분리/분해로 인해 떨어진 신뢰성을 해결하기 위한 패턴
장애 복구, 자가 치유, 무정지 배포 등을 구현하기 위한 패턴들이 이에 속합니다.
(1) Circuit Breaker Pattern (서킷 브레이커)패턴
서비스 간의 통신에서 발생할 수 있는 장애를 처리하는 패턴으로, 장애가 발생한 서비스에 대한 요청을 중단시키고, 일정 시간 이후에 다시 시도하여 전체 시스템에 더 큰 영향을 막습니다.
예를 들어, A -> B -> C처럼 통신을 하고 있을때 C에서 문제가 발생하여 B에 응답을 500 상태를 주었을 경우, 서킷 브레이커를 사용하지 않는다면 또다른 A1이 B를 요청할때 오류가 발생함 따라서, C에서 B로 500상태 응답을 주었을때 서킷 브레이커를 통해 B에서는 C와의 연결상태를 막고 A1에게는 200상태와 함께 C와의 오류가 발생했다는 메세지를 전송해줌
(2) Retry Pattern (재시도)패턴
네트워크 통신 등에서 발생할 수 있는 일시적인 장애에 대응하기 위해 요청을 다시 시도하는 패턴으로, 일시적인 문제가 해결될 수 있도록 여러 번의 재시도를 통해 안정성을 높입니다.
