이벤트 기반 시스템(Event-Driven Systems)에서 기본 설정(Default Config)이라는 신화

우리가 실제로 해결하고 있었던 문제
우리는 재고 수준, 배송 상태 및 잠재적 지연에 대해 여러 공급업체에 실시간으로 알림을 보내야 하는 복잡한 공급망 문제를 직면하고 있었습니다. 시스템은 초당 수천 개의 이벤트를 처리해야 했지만, 현실은 5초 미만의 지연 시간(Latency)을 유지하는 데에도 어려움을 겪고 있었습니다. 시스템을 구축한 엔지니어들은 기본 설정(Default configuration)만으로도 충분할 것이라고 가정했지만, 그들이 고려하지 못한 점은 엄청난 데이터 양과 공급업체 응답 시간의 가변성이었습니다.

우리가 처음 시도했던 것 (그리고 실패한 이유)
우리는 이벤트 기반 시스템(Event-driven systems)에 대한 표준적인 접근 방식을 취했습니다. 문제 해결을 위해 더 많은 컴퓨팅 파워를 투입하고, 데이터베이스를 고성능 변형으로 업그레이드하며, 증가한 부하를 처리할 수 있도록 메시지 큐(Message queue)를 구성했습니다. 듣기에는 좋아 보이지 않나요? 하지만 결과적으로 얻은 것은 여전히 느리고, 여전히 이벤트를 누락하며, 가끔 지연된 응답을 보내는 공급업체를 여전히 감당하지 못하는 시스템이었습니다. 시스템을 구축했던 엔지니어들은 문제가 설계가 아닌 기반 기술에 있다고 확신했습니다. 우리는 실제 문제를 들여다보는 대신, 시스템을 더 많은 자원을 투입해야 하는 블랙박스(Black box)로 보는 사고방식에 갇혀 있었습니다.

아키텍처 결정
늦은 밤 디버깅(Debugging) 세션 중에 저는 문제가 기술에 있는 것이 아니라, 모니터링과 로깅(Logging)에 대해 '단일 창(Single pane of glass)' 접근 방식을 취했다는 사실을 깨달았습니다. 우리는 모든 개별 이벤트를 실시간으로 수집하고 처리하려고 시도했는데, 이는 재앙을 초래할 수 있는 방식이었습니다. 대신, 저는 한 걸음 물러나 실시간으로 처리해야 하는 중요한 이벤트에만 집중하는 별도의 로깅 파이프라인(Logging pipeline)을 구현하기로 결정했습니다. 이를 통해 비중요 이벤트를 낮은 우선순위의 큐(Queue)로 오프로드(Offload)할 수 있었고, 시스템의 지연 시간과 가변성을 줄일 수 있었습니다.

수치로 나타난 결과
새로운 로깅 파이프라인(Logging Pipeline)을 구축한 후, 평균 지연 시간(Latency)이 5초에서 2초 미만으로 크게 감소하는 것을 확인했습니다. 또한 이벤트 드롭률(Event Drop Rate)도 10%에서 1% 미만으로 대폭 줄어들었습니다. 하지만 가장 놀라운 통계는 벤더(Vendor)에 대한 평균 응답 시간이 30초에서 10초 미만으로 단축되었다는 점입니다. 이제 시스템은 벤더 응답 시간의 가변성(Variability)에 대처할 수 있게 되었고, 고객에게 더 나은 경험을 제공할 수 있게 되었습니다.

다르게 했을 점
돌이켜보면, 처음부터 이벤트 기반 시스템(Event-Driven Systems)에 대해 더 구조적인 접근 방식을 취했을 것입니다. 기본 설정(Default Configuration)만으로 충분할 것이라고 가정하기보다는, 지연 시간(Latency), 가변성(Variability), 그리고 확장성(Scalability)에 초점을 맞추어 시스템을 설계하는 데 더 많은 시간을 할애했을 것입니다. 또한 문제가 발생한 후에 해결하려고 하기보다, 처음부터 더 견고한 모니터링 및 로깅 파이프라인(Monitoring and Logging Pipeline)을 구현했을 것입니다. 하지만 이번 경험을 통해 배운 점은, 이벤트 기반 시스템이란 단순히 문제에 더 많은 리소스를 투입하는 것이 아니라, 실제 세계의 이벤트가 가진 가변성에 적응할 수 있는 시스템을 설계하는 것이라는 사실입니다.