Asynchronous pattern

Usecase

• 프로세스와 예측 사이에 의존성이 없는 경우.
• 예측을 요청할 클라이언트와 응답할 목적지가 분리되어 있는 경우.

Architecture

Asynchronous pattern은 클라이언트와 예측 서버 사이에 대기열이나 캐시를 배치해 예측 요청과 예측 검색을 분리합니다. 이 패턴은 클라이언트가 예측 지연을 기다리지 않도록 합니다. 클라이언트가 예측을 얻으려면 큐에서 결과를 가져오기 위해 폴링을 추가해야 합니다. Diagram2와 같이 클라이언트 이외의 리소스에서 예측 결과를 검색하려는 경우 예측 대기 시간을 기다리지 않고 다음 단계로 진행할 수 있습니다.
또한, Diagram1과 Diagram2의 경우 예측 서버를 만들어 결과를 다른 구성 요소로 푸시하도록 만들 수 있지만, 시스템의 사용 사례를 신중하게 고려해야 하고 워크플로우가 매우 복잡해질 수 있습니다.

Diagram

Diagram1

Diagram2

Pros

• 클라이언트와 예측을 분리할 수 있습니다.
• 클라이언트가 예측 대기 시간을 기다릴 필요가 없습니다.

Cons

• 큐, 캐시 또는 유사한 종류의 프록시가 필요합니다.
• 실시간 예측엔 적절하지 않습니다.

Needs consideration

• 예측을 실행할 방법:
  • Queue: FIFO(요청한 시간 순으로) 예측합니다.
  • Cache: 캐시의 존재 여부에 따라 다릅니다.
  • PubSub: 예측 서버가 구독할 경우 예측합니다.
• 예측 오류에 대한 고려가 필요합니다:
  • 만약 재시도해야 하면, 예측 서버에서 재시도하거나 또는 큐로 돌아갑니다.
  • 만약 오류가 데이터 또는 프로그래밍 이슈로 발생했다면, 수동으로 요청을 처리할 때까지 요청이 계속 재시도될 가능성이 있습니다.
• 이 패턴은 순서가 있는 예측을 지원하지 않기 때문에, 사용 사례에서 입력 또는 이벤트에 대한 구체적인 워크플로우를 고려해야 합니다.

Sample

https://github.com/shibuiwilliam/ml-system-in-actions/tree/main/chapter4_serving_patterns/asynchronous_pattern