개요

RR(Request and Response)와 eda(event driven architecture) 사이의 trade off를 이해하고 적절히 사용을 해야하는 것 같다. 같은 기능을 RR과 EDA로 모두 구현할 수 있기 때문에 여러 리소스를 비교하고 확장성을 고려해서 최선을 선택을 해야한다. 그러기 위해서는 두 방식의 차이점에 대해서 정확히 알고 있어야 한다.

내용

EDA 방식

eda 방식에서는 broker를 우체국의 개념으로 사용한다고 한다. broker를 사용하지 않는 방식도 있다고 하는데 여기서는 다루지 않겠다. 대표적인 broker는 kafaka, service bus가 있다. broker는 무조건 eda의 서비스와 서비스 사이의 우체국 개념으로만 사용되는 것은 아니라고 한다. 특정 서비스에서 부하를 분산하기 위해서 작업 큐의 용도로 사용할 수 도 있다. broker를 사용한다는 것은 곧바로 처리하지 않고 몰려드는 요청을 특정 공간에 저장해놓는다고 이해하면 쉬울 것 같다. 만약에 동기적 rr 처리 방식이라면 앞선 처리가 부하가 걸려서 지연이 된다면 몰려오는 모든 처리들도 밀리게 될 수 있다(극단적 예시). 만약에 비동기로 처리가 된다고 하더라도 요청에 대한 응답을 기다리는 각 클라이언트 및 서비스들은 cpu를 할당하지 않고 대기를 한다고 하지만, 요청을 받은 서비스는 수많은 요청을 동시에 처리해야하기에 cpu를 최대로 사용하여 나중에는 뻗어버릴 수 도 있다.

물리적 리소스의 한계로 인해서 동시에 처리할 수 있는 요청은 정해져있다고 볼 수 있다. 만약 서비스가 갑자기 인기가 상승하여 요청량이 급격하게 상승한다면 모든 요청을 메모리에 로드하기때문에 메모리가 부족하거나 cpu가 부하가 걸려서 서버가 다운될 수 있다. 그러나 안좋은 점만 있는 것은 아니다. 서비스의 유저수가 정해져 있거나, 요청량이 예상할 수 있는 수준이라면 rr 방식을 채택하여 eda 비해 구조적 단순함과 비용을 줄일 수 있다.

Request/Response(RR) 방식

직관적이다. 요청한 내용에 대한 응답을 기다린다. 기다리는 방식은 동기적, 비동기적으로 나뉜다. rr을 언제 사용하면 좋을지 생각해 본 적 없이 그냥 사용했었다. 부하가 적고 예상되는 트래픽이 많지 않은 경우에는 RR 방식을 사용하는 게 단순하고 직관적이다. 불필요한 오버 엔지니어링을 피할 수 있다. 불필요한 구조를 선택한 경우, 인프라 비용 증가, 개발 속도 저하, 그리고 디버깅 난이도가 엄청나게 올라가는 것을 느꼈다. 심지어 cloud service를 활용하는 경우, 내부가 어떻게 동작하는지 정확히 파악하기 쉽지 않아서 더욱 어렵게 다가왔던 것 같다. 그러나 어떤 기술을 쓰는지 보다는 상황에 맞게 채택하여 사용하는 것이 고수인 것 같다.

결론

상황에 맞게 기술을 골라야 한다. 더욱 공부하고 경험해서 상황 상황마다 최선을 선택을 하는 사람이 되고 싶다.