[Cloud Design Patterns] Asynchronous Request-Reply pattern 비동기 요청/응답 패턴 (feat. HTTP 폴링, 웹소켓)

최신 애플리케이션 개발에서 클라이언트 애플리케이션이 비즈니스 로직을 제공하기 위해 원격 API에 의존한다.

대부분의 경우 클라이언트 애플리케이션에 대한 API는 100ms 이하로 신속하게 응답하도록 설계되었다.

다음과 같은 요인들이 응답 대기 시간에 영향 줄 수 있다.

• 애플리케이션 호스팅 스택
• 보안 구성 요소
• 클라이언트와 백엔드 시스템의 위치
• 네트워크 인프라
• 현재 부하
• 요청 페이로드 크기
• 큐 처리 길이
• 백엔드에서 요청을 처리하는 시간

 

 

이미지를 검수하는 웹 애플리케이션의 시나리오를 상상해보자. 이미지 검수하는 과정은 과정은 몇 초에서 몇 분이 걸릴 수 있다.

 

API는 보통 100ms 이하로 응답이 설계되었다고 했는데, 위의 그림에서는 최대 몇분까지 걸릴 수 있는 구조이다.

 

 

서버에서는 다음과 같이 이미지 검수를 처리하는 큐를 추가하여 비동기 처리를 할 수 있다.

 

하지만 이 방식은 클라이언트가 즉각적인 응답이 필요할 경우, 처리가 복잡해질 것이다.

 

해결책

이는 HTTP Polling(폴링)으로 해결할 수 있다.

HTTP 폴링은 클라이언트가 업데이트된 정보를 얻기 위해 서버에 반복적으로 요청을 보내는 방식이다. 이 경우 이미지 검수 처리가 완료되었는지 반복적으로 서버에 요청하여 여부를 확인할 수 있다.

 

1. 클라이언트가 서버에 이미지 검수 요청을 보낸다.
2. 서버는 이벤트를 발행하여 큐에 검수 작업을 추가하고, 작업 ID로 클라이언트에 응답한다.
3. 클라이언트는 수신된 작업 ID로 폴링을 수행한다. (ex) GET /jobs/{id})
4. 서버는 현재 상태를 HTTP 상태 코드를 사용하여 응답한다.

 

다른 해결책으로는 웹소켓(WebSocket)이 있다.

이는 클라이언트가 작업 상태를 실시간 받아야 하는 경우 더 적합하다. 작동 방식은 작업 상태를 폴링하는 대신 클라이언트와 서버 사이에 WebSocket 연결이 설정되어 클라이언트가 작업 상태를 업데이트하도록 유지한다.

 

 

참고

Asynchronous Request-Reply pattern - Azure Architecture Center