Combine framework를 공부하다, Request-Driven이라는 단어를 보게 되었다. Event-Driven 방식과 무엇이 다른지 알아보고자 한다.
Request-Driven
특정 데이터를 서버로부터 받고 싶다고 하자. 일반적인 REST API를 사용한다면 서버에 GET 요청을 하고, 그 결과로 json 데이터를 받을 것이다. 이렇게 일반적으로 가장 많이 사용하는 Server 통신 방식이 Request-Driven 방식이라 생각하면 된다. 그런데 이런 Request-Driven 방식도 맞지 않는 기술 선택일 수 있다.
만약 요청의 결과가 시간이 필요한 작업이라면, 그 작업이 끝나는 시기에 Client는 Server에 주기적으로 질의해야 한다. 이는 Block-NonBlock 방식을 얘기할 때, 비동기로 처리되나 작업의 완료시점을 알기 위해 작업을 요청한 thread에서 작업을 하고 있는 thread에 계속해서 완료 시점을 점검하는 것과 유사하다.
직관적으로 보았을 때, 이러한 처리가 필요한 task에서 위와 같은 Request-Driven 방식을 사용하는 것은 좋지 않다.
Event-Driven
이러한 문제에 대해 가장 쉬운 해결 방법은 서버쪽에서 Ready 상태일 때, client로 정보를 밀어넣어주는 것이다. 이렇게 처리할 경우, 이제 정보 제공 Event는 Server로부터 시작된다고 할 수 있다. 이렇게 Event 발생시 Client쪽으로 데이터를 넘겨주는 방식을 WebHook이라 한다.
webHook이 event 발생시 client로 데이터를 넣어주는 방식이라면, 연결 후 계속해서 데이터를 넣어주는 Streaming API도 있다.
이렇게 설명하면 Socket 통신과 비슷한 것 아니냐는 질문을 할 수도 있을 것 같다. 하지만 Socket의 경우는 양방향 통신, 즉 client 쪽에서도 정보를 보내고 받을 수 있으나, WebHook 또는 Streaming API의 경우 Client로 데이터를 보내는 단방향 통신에 사용된다.
마무리
Request-Driven 방식은 필요한 시점에 정보를 요청하고, 그에 맞는 데이터를 받아 처리하는 방식이다. 서버에서 데이터를 이미 가지고 있어 제공만 하면 되는 경우 이 방식이 Resource를 적게 먹기 때문에 좋은 방식이라 할 수 있겠다.
하지만 작업 처리에 시간이 걸리는 경우, 특정 이벤트가 발생했을 시 처리되어야 하는 경우, 계속해서 데이터를 밀어넣어주어야 하는 경우에는 이런 Request-Driven 방식은 좋지 않은 엔지니어링 판단이 될 수 있다. 이런 경우 Event-Driven 방식을 통해 Event 발생 시 데이터를 전송하는 것이 Resource를 아낄 수 있는 좋은 방법이라 할 수 있다.
Event-Driven Architecture는 보다 많은 내용이 있으나, 지금으로써는 가볍게 알아보고 마치려고 한다. 추후 더 깊은 내용이 필요한 경우 여기에 정리할 예정이다. 추가적으로 궁금하다면 링크를 참고하자. 끝!
Reference
