마이크로서비스 패턴 3장

백종현·2024년 5월 21일

마이크로서비스에서는 요청을 통해 애플리케이션과 협동한다. 따라서, IPC(프로세스간 통신)는 매우 중요하고 가용성에 많은 영향을 미친다.

동기 RPI

RPI는 클라이언트가 서비스에 요청을 보내면 서비스가 처리 후 응답을 회신하는 IPC

동기 RPI 패턴 : REST

REST 성숙도

레벨 0 : 서비스별로 유일한 URL 끝점에 POST 요청
레벨 1 : 리소스 개념 지원 + POST
레벨 2 : HTTP 동사를 이용
레벨 3 : HATEOAS(GET에서 다른 동사의 URL을 알려줌) 사용

간단하고 편리. 시스템 단순. 테스트 쉬움

REST API는 요청 한번으로 많은 리소스를 가져오기 힘듬 -> GraphQL, 팔코의 각광
http 동사가 제한적 -> gRPC의 각광

동기 RPI 패턴 : gRPC

gRPC API는 하나 이상의 서비스와 요청/응답 메시지 데피니션(definition, 정의한 코드)으로 구성

큰 메시지에 유리, 양방향 스트리밍으로 RPI, 메시징 둘다 가능

동기 RPI에서의 부분 실패 : 회로 차단기 패턴

연속 실패 횟수가 주어진 임계치를 초과하면 일정 시간 동안 호출을 즉시 거부하는 RPI 프록시. -> 프록시 객체를 통해 몇번의 요청이 실패하면 더 이상 호출하지 않음

구현법

네트워크 타임아웃
미처리 요청 개수제한
회로 차단기 패턴 : 성공/실패 개수보다가 에러율(비율)이 임계치 초과시 이후 시도는 모두 실패

ex) 넷플릭스 히스트릭트

하지만, 부분적인 솔루션일뿐 불능 서비스를 복구시키지는 못한다.

불능 서비스 복구 : 서비스 디스커버리

애플리케이션 수준의 서비스 디스커버리 : 서비스 레지스트리에 서버 등록

플랫폼 내장 서비스 디스커버리

도커/쿠버네티스에서 제공
서드파티 등록 패턴 : 등록기가 서비스 레지스트리 업데이트
서버쪽 디스커버리 패턴: DNS가 서비스 레지스트리에 접근, DNS를 통한 처리

비동기 메시징

메시징 상호 작용 스타일

요청/응답 및 비동기 요청/응답
단방향 알림
발행/구독
발행/비동기 응답

비동기는 위 4가지 방식 한개로 구현

메시지 브로커

메시징 기반의 애플리케이션은 메시지 브로커 사용

브로커리스 메시징도 있음 (성능 향상, 운영복잡도 저하, but 가용성 떨어짐, 전달보장 매커니즘 어려움)

브로커 기반 메시징

장점 : 느슨한 결합, 메시지 버퍼링, 유연한 통신, 명시적 IPC
단점 : 성능 병목 가능성, 단일 장애점 가능성 (브로커가 저가용성인 경우), 운영복잡도 증가

수신자 경합/메시지 순서 유지

메시지 순서를 유지하면서 수평 확장이 가능할까?
샤딩 방식의 채널을 통해 가능 (ex. AWS Kinesis, Kafka)

중복 메시지 처리

멱등한(idempotent) 메시지 핸들러를 작성 : 애플리케이션 처리가 멱등(여러번 실행되도 한번 실행되는것처럼)하면 중복 메시지는 전혀 해롭지 않음.
메시지를 추적하고 중복을 솎아 냄

트랜잭셔널 메시징

DB 테이블을 메시지 큐로 활용
이벤트 발행 : 폴링 발행기 패턴 -> SELECT 후 삭제
이벤트 발행 : 트랜잭션로그 테일링 패턴 -> 트랜잭션 로그 읽기
트랜잭션 로그 테일링 : 디비지움, DynamoDB 스트림즈

비동기 메시징으로 가용성 개선

동기 방식
1. 클라이언트가 주문 서비스에 HTTP POST /orders 요청을 합니다.
2. 주문 서비스는 소비자 서비스에 HTTP GET /consumers/id를 요청하여 소비자 정보를 조회합니다.
3. 주문 서비스는 음식점 서비스에 HTTP GET /restaurant/id를 요청하여 음식점 정보를 조회합니다.
4. 주문 서비스는 이렇게 조회한 소비자/음식점 정보로 올바른 주문인지 확인합니다.
5. 주문 서비스는 주문을 생성합니다.
6. 주문 서비스는 클라이언트에 HTTP 응답합니다....

비동기 방식
1. 주문 서비스는 주문을 PENDING 상태로 생성합니다.
2. 주문 서비스는 주문 ID가 포함된 응답을 클라이언트에 반환합니다.
3. 주문 서비스는 ValidateConsumerInfo 메시지를 소비자 서비스에 전송합니다.
4. 주문 서비스는 ValidateOrderDetails 메시지를 음식점 서비스에 전송합니다.
5. 소비자 서비스는 ValidateConsumerInfo 메시지를 받고 주문 가능한 소비자인지 확인 후, ConsumerValidated 메시지를 주문 서비스에 보냅니다.
6. 음식점 서비스는 ValidateOrderDetails 메시지를 받고 올바른 메뉴 항목인지 음식점에서 주문 배달지로 배달이 가능한지 확인 후, OrderDetailsValidated 메시지를 주문 서비스에 전송합니다.
7. 주문 서비스는 ConsumerValidated 및 OrderDetailsValidated를 받고 주문 상태를 VALIDATED로 변경합니다.
8. …...