MSA 사용하기 위해 필요한 패턴들 [ MSA, 패턴, 데이터쿼리, 가시성 패턴, 신뢰성 패턴 ]

데이터 쿼리 패턴

MSA 소프트웨어 아키텍처를 설계하면서 생긴 "데이터 쿼리"의 어려움을 해결하기 위한 패턴

API Aggregation 패턴

필요한 데이터를 얻어오기 위해서, 분리된 서비스들 각각에 각 도메인에 대한 데이터를 요청 후 필요에 맞게 Aggregation(조합) 한다.

 

CQRS 패턴

Command(Write, Update, Delete) 작업과, Query(Read) 작업의 Endpoint를 분리하고

Command 에서 발생된 데이터의 변경을 이벤트 발행을 통해 원하는 포맷대로 Query를 위한 전용 데이터 구조를 만들어 이곳에서 복잡한 Query를 담당합니다.

 

가시성 (Visibility, Observability)

MSA 소프트웨어 아키텍처를 설계하면서 생긴 로깅, 모니터링의 어려움(가시성의 부재)을 해결하기 위한 패턴

하나의 트랜잭션에 대해 여러개의 각 서비스 요청들을 하나의 요청처럼 볼 수 있게 하는 트레이싱

구체적으로 어떻게 로깅, 메트릭을 저장하고 인덱싱하여 검색할 지에 집중하는 패턴

신뢰성 ( Reliability )

MSA 소프트웨어 아키텍처를 설계하면서, 분리/분해로 인해 떨어진 신뢰성을 해결하기 위한 패턴

장애 복구, 자가 치유, 무정지 배포 등을 구현하기 위한 패턴들 입니다

무정지 배포의 흐름은 어떻게 될까..?( Graceful Shutdown )

A서비스가 있고 지금 A서비스로 트레픽이 흘러가는 상황입니다 하지만 A` 서비스로 다시 배포해야 하는 상황이 왔는데 이때 A서비스 앞에는 리버스 프록시가 트레픽을 넘겨줍니다. 만약 A`서버를 배포해야하는 상황이라면 리버스 프록시는 잠시동안 A서비스로 트레픽을 보내지 않고 A서비스는 남은 트랜젝션과 자원을 정리합니다. 정상적으로 끝났다면 A서버는 Graceful Shutdown이 되고 A`서비스가 그 자리를 대체합니다. A`서비스로 대체되었다면 리버스 프록시는 다시 트레픽을 보냅니다.

 

서킷 브레이커 ( Circuit Breaker )

신뢰성을 높이기 위한 패턴의 일종으로, 분산 시스템에서 장애 전파를 막고 피해를 최소화하기 위한 패턴입니다.

이해가 안돼요..!

A서비스 B서비스 C서비스 순서대로 트랜잭션이 진행된다고 치면, A서비스는 B서비스로 요청을 보내고 B서비스가 C서비스로 요청을 보냈는데 C서비스에서 어떠한 문제가 생겨 500에러가 발생한다면 C서비스를 호출하는 B서비스, B서비스를 호출하는 A서비스 는 500에러가 발생하면서 장애가 발생할 것입니다. 하지만 여기서 B서비스에 서킷 브레이커를 적용한다면 서킷 브레이커에 특정 조건을 만족하였을때 B서비스에서 C서비스로 가는 길을 막고 서킷 브레이커는 B서비스를 호출한 A서비스에게 200 ok와 함께 메시지를 보냅니다. 여기서 B서비스의 서킷 브레이커는 C에게 지속적으로 해결이 됐는지 확인하고 해결이 됐다면 B서비스에서 C서비스로 가는 길을 다시 열어둡니다.