[시스템디자인 1편] 동기 통신 오래 걸릴 때 해결방안 정리

목차는 시스템 디자인 목차 에 있습니다.

[시스템디자인 1편] 동기 통신 오래 걸릴 때 해결방안 정리

동기 패턴 문제점

• client 에서 server api 를 호출하는데 응답이 느리다고 가정하겠습니다.
  • 인프라, 네트워크, 기타 등등의 이유로
• 동기 방식은 request 를 줘서 response 가 올 때까지 기다립니다. 이게 동기 방식의 문제점입니다.

해결방안 message broker 이용 (kafka 같은)

• 메시지 브로커를 이용하면 client 와 server 간의 결합이 끊어지기에 이런 문제를 해결할 수 있습니다.
• 그러나 메시지 브로커를 통해 처리하게 된다면 client 에게 응답을 어떻게 줘야할지에 대한 문제점이 있습니다.
  • push 나 문자 이런 것들은 message broker 를 써도 괜찮습니다. 어차피 응답이 가야하므로.
  • 문제는 api 응답 값으로 후속 작업을 해야하는 경우입니다.

해결방안 HTTP Pooling

• client --> Server 로 api 를 호출했을 때, message queue 에 데이터를 담고 즉각적으로 응답을 줍니다.
  • 이 떄, http 응답은 202 로 보냅니다.
  • 202 는 해당 요청이 처리중이라는 의미입니다.
• Message queue 에서 데이터를 꺼내서 후속 작업으로 처리해줍니다.
• 여기서 2가지로 나뉩니다.
  • 하나는 똑같은 API 를 계속 호출하는 겁니다. 그럼 서버는 둘중 하나입니다. 처리중이면 202 return 하고, 처리가 다 됐다면 302 를 통해 url 을 전달해줍니다.
  • 또 하나는 이미 client 에서는 비동기 처리 결과 값을 받아올 수 있는 api 를 알고 있는 것입니다. 그럼 주기적으로 해당 api 를 호출하면 됩니다.

결론

• client 와 server 동기 통신을 할 때, 응답이 느리다면 메시지 브로커, HTTP Pooling 을 고려해보면 좋습니다.
• 응답이 알림 (SMS, Push) 과 같이 가도 된다면 메시지 브로커를 응답을 기다려서 후속 작업을 해야한다면 HTTP Pooling 을 선택하면 됩니다.

Reference

• https://docs.microsoft.com/ko-kr/azure/architecture/patterns/async-request-reply