microservice pattern.05

using asynchronous messaging to improve availability

IPC 메커니즘은 서로 다른 트레이드-오프를 가집니다. 이런 트레이드 오프 중 하나는 IPC 메커니즘의 선택이 서비스의 가용성에 영향을 미친다는 것입니다.

synchronous communications reduces availability

REST는 가장 인기있는 IPC 메커니즘입니다. 가장 흔하게 사용되는 IPC 메커니즘이기도 하기에, 서비스간 통신에도 적용하는 것을 고려할 수도 있습니다. 하지만, REST의 문제는 동기적 프로토콜이라는 점입니다. HTTP 클라이언트는 서비스가 응답을 보내는 것을 반드시 기다려야합니다. 서비스가 동기적 프로토콜을 이용해서 통신하면, 서비스의 가용성은 감소됩니다.

OrderService는 주문을 생성하는 REST API를 가집니다. POST /orders 요청이 발생하면, ConsumerService와 RestaurantService를 호출해서 Order를 검증합니다.

주문 생성 과정은 다음과 같이 이뤄집니다.

1. 클라이언트는 주문 서비스에 POST /orders HTTP 요청을 보냅니다.
2. 주문 서비스는 고객 서비스에 GET /restaurant/id HTTP 요청을 보내는 것으로 고객의 정보를 반환받습니다.
3. 주문 서비스는 식당 서비스에 GET /restaurant/id HTTP 요청을 보내는 것으로 식당의 정보를 반환받습니다.
4. Order Taking이 고객과 식당의 정보를 사용해서 요청을 검증합니다.
5. Order Taking이 주문을 생성합니다.
6. Order Taking이 HTTP 응답을 클라이언트에게 반환합니다.

서비스들이 HTTP를 사용하기에, 애플리케이션이 주문 생성 요청을 처리하기 위해서는 모두 해당 시점에 사용 가능해야합니다. 애플리케이션은 3가지 서비스 중 하나라도 장애가 발생했다면, 주문을 생성할 수 없습니다. 수학적으로 말하자면, 시스템 운영의 가용성은 그 운영에서 호출되는 서비스들의 가용성의 곱입니다. 만약 주문 서비스와 그 서비스가 호출하는 두 가지 서비스가 각각 99.5%의 가용성을 가진다면, 전체 가용성은 99.5%^3 = 98.5%로 상당히 낮아집니다. 요청 처리를 위해 추가되는 각 서비스는 가용성을 더욱 감소시킵니다.

이 문제는 REST에 국한된 문제가 아닙니다. 서비스가 다른 서비스로부터 응답을 받은 이후에 클라이언트에게 응답을 할 수 있게되면 가용성은 감소됩니다. 비동기 메세징을 이용해서 request / response 상호작용 스타일을 이용해 통신해도 이 문제는 발생합니다. 가용성을 최대화하기 위해서는 동기적 통신의 양을 최소화해야합니다.

eliminating synchronous interaction

동기 요청을 처리하는 동안 다른 서비스와의 동기 통신을 줄이는 몇 가지 방법이 있습니다. 한 가지 해결방법은 서비스를 비동기 API만을 가지도록 정의하는 것입니다. 하지만, 이 해결 방법은 항상 가능하지는 않습니다. 몇몇 공개 API는 보통 REST를 사용합니다. 그렇기에 모든 서비스가 비동기 API만을 사용하도록 설계할 수는 없습니다.

다행히도, 동기 요청을 동기 방식으로 처리하지 않고도 처리할 수 있는 방법들이 있습니다.

use asynchronous interaction styles

앞서 언급한 것처럼 모든 상호작용은 비동기 상호작용을 사용하는 것이 이상적입니다. 예를 들어, 애플리케이션의 클라이언트가 비동기 요청/비동기 응답 스타일의 상호작용을 사용해서 주문을 생성한다고 해봅시다. 클라이언트는 OrderService에 요청 메세지를 보내는 것으로 주문을 생성할 수 있습니다. 주문 서비스는 비동기적으로 다른 서비스와 메세지를 교환하고, 이후에 클라이언트에게 응답 메세지를 보냅니다.

클라이언트와 서비스들은 메세징을 이용해 비동기적으로 통신합니다. 이 상호작용에서 어떤 서비스도 응답을 대기하기 위해 block되지 않습니다. 이러한 아키텍처는 메세지 브로커가 메세지를 소비할 수 있을 때까지 버퍼링하기 때문에 매우 강력한 복원력을 가질 것입니다. 하지만 문제는 서비스들이 종종 REST와 같은 동기 프로토콜을 사용하는 외부 API를 가지고 있어 요청에 즉시 응답해야 한다는 점입니다.

만약 서비스가 동기 API를 가진다면, replicate data를 이용해서 서비스의 가용성을 향상시킬 수 있습니다.

replicate data

리퀘스트를 처리하는 동안 동기 요청을 최소화하는 한 가지 방법은 데이터를 복사하는 것입니다. 서비스는 요청을 처리할 때 필요한 데이터를 복제본으로 유지합니다. 이 복제본은 데이터를 소유한 서비스가 발행하는 이벤트를 구독함으로써 최신 상태로 유지됩니다. 예를 들어, 주문 서비스는 고객 서비스, 식당 서비스가 소유한 데이터의 복제본을 유지합니다. 데이터를 복제함으로써 다른 서비스와 상호작용을 하지 않아도됩니다.

고객 서비스와 식당 서비스는 데이터가 변경될때마다 이벤트를 발행합니다. 주문 서비스는 해당 이벤트를 구독하고, 복제본의 값을 변경합니다.

몇몇 상황에서 이렇게 데이터를 복제하는 접근 방법이 효율적입니다. 복제본을 사용하는 방법의 단점은, 가끔 복제할 데이터의 크기가 너무 클 수도 있습니다. 이런 경우 복제본을 사용하는 것이 비효율적입니다. 또 다른 결함은 다른 서비스가 소유한 데이터를 어떻게 업데이트해야할지에 대한 문제가 발생하게 된다는 것입니다.

이 문제를 해결하는 한 가지 방법은 서비스가 클라이언트에게 응답한 후에 다른 서비스와의 상호작용을 지연하는 것입니다.

finish processing after returning a reponse

요청을 처리할 때 동기 communication을 줄이는 또 다른 방법은 서비스로 하여금 다음 과정을 통해 요청을 처리하게 하는 것 입니다.

1. locally available한 데이터만 사용해서 요청을 검증합니다.
2. 데이터베이스를 업데이트합니다, 이때 OUTBOX 테이블에 메세지를 추가합니다.
3. 클라이언트에 응답을 반환합니다.

요청을 처리할 때, 서비스는 다른 서비스와 동기적으로 상호작용하지 않습니다. 대신에, 비동기적으로 서비스들에게 메세지를 발송합니다. 이런 접근 방법은 서비스들의 느슨한 결합을 보장합니다.

추후에 다룰 것이지만, 이런 접근 방법은 종종 saga를 이용해 구현됩니다.

만약 주문 서비스가 이런 접근 방법을 사용한다면, 주문을 PENDING 상태로 생성하고, 다른 서비스와 비동기적으로 통신하며 주문을 검증할 수 있습니다.

createOrder() 오퍼레이션이 호출됐을 때 다음과 같은 과정으로 이벤트들이 진행됩니다.

1. 주문 서비스가 PENDING 상태로 주문을 생성합니다.
2. 주문 서비스가 클라이언트에게 주문 아이디 값을 리턴합니다.
3. 주문 서비스가 고객 서비스에게 고객 정보 검증 메세지를 보냅니다.
4. 주문 서비스가 식당 서비스에게 주문 검증 메세지를 보냅니다.
5. 고객 서비스는 메세지를 받고, 주문을 생성한 고객을 검증하고, 주문 서비스에게 메세지를 보냅니다.
6. 식당 서비스는 메세지를 받고, 메뉴 아이템과 식당을 검증하고, 주문 서비스에게 메세지를 보냅니다.
7. 주문 서비스는 식당 서비스와, 고객 서비스에게 메세지를 받고, 주문의 상태를 VALIDATED으로 변경합니다.

주문 서비스는 식당 서비스의 메세지를 먼저 받을 수도, 고객 서비스의 메세지를 먼저 받을 수도 있습니다. 주문 서비스는 주문의 상태를 변경함으로써 어떤 메시지를 먼저 받았는지 추적합니다. 만약 ConsumerValidated 메시지를 먼저 받으면 주문의 상태를 CONSUMER_VALIDATED로 변경하고, OrderDetailsValidated 메시지를 먼저 받으면 주문의 상태를 ORDER_DETAILS_VALIDATED로 변경합니다. 주문 서비스는 나머지 메시지를 받으면 주문의 상태를 VALIDATED로 변경합니다.

주문이 검증된 이후에, 주문 서비스는 나머지 주문 생성에 관한 처리를 합니다. 이런 접근 방법의 좋은 점은, 고객 서비스가 다운된 상황에서도, 주문 서비스는 고객에게 응답을 할 수 있다는 점입니다. 고객 서비스가 다시 살아난 이후에, 큐에 있는 메세지를 처리할 것이고, 주문은 검증될 것입니다.

요청을 전부 다 처리하기 전에 응답하는 방법의 결함은 클라이언트의 복잡성을 증가시킨다는 점입니다. 예를 들어, 주문 서비스는 응답을 리턴할 때, 새로 생성된 주문에 대한 최소한의 보장만을 제공합니다. 주문을 검증하고, 고객의 결제 수단을 검증하기 이전에 주문을 생성하고, 리턴합니다. 결과적으로 클라이언트가 주문이 성공적으로 처리되었는지 알기 위해서는 주기적으로 서버에 요청을 보내 확인하거나, 주문 서비스가 알림 메세지를 보내는 것입니다. 복잡해 보이지만, 많은 상황에서 이러한 접근 방법이 권장됩니다.