Datadog에서 숨겨진 병목들을 찾아 Latency를 해결한 방법

Datadog 엔지니어링팀에서 usage estimation 서비스를 배포할때 latency가 크다는 것을 관찰했습니다. 배포되는 기능의 복잡도나 사이즈에 상관 없이 latency가 늘어났기 때문에 본인들이 구현한 기능의 문제가 아니라고 판단을 하고 이를 해결하기 위해 딥다이브를 했고 어떻게 해결했는지에 대해 공유드립니다. NOTE: 문제가 발생한 usage estimation 서비스는 router -> counter -> aggregator로 구성되어 있음. try1) remote cache replica를 늘려보기 -> scale out해도 크게 latency가 줄어들지 않음. counter application이 배포될때마다 latency가 튀어서 network-issue라고 판단. Request가 remote cache까지 가기 전에 sidecar Envoy proxy로 라우팅되는데 이때 read/write가 많아서 CPU intensive해짐. try2) Envoy에 CPU 리소스 더 늘려보기 -> 조금의 개선은 있었지만, 평소보다는 높음. 그래서, counter application이 remote cache에서 데이터 갖고 올 때 문제가 있다고 판단. Envoy에서 remote cache로 갈때 AWS ENA를 활용하는데, Linux Kernel bug로 인해 8개의 transmit queue중 하나로만 매핑되는 버그 확인. try3) 8개의 transmit queue에 요청을 분산시켜서 Linux kernel 버그 고치기 -> 롤아웃하지 않을 때는 latency줄었지만, 롤아웃 할때는 문제가 동일. ENA에서 허용된 bandwidth를 넘어가도록 요청을 보내는 것을 확인했고 이렇게 된 경우 패킷을 드랍하고 다시 재시도하는데 이때 전체 요청이 느려짐. try4) Bandwidth 허용치가 더 높은 network optimized EC2 instance로 이전 -> 드랍되는 패킷의 수가 많이 줄었음. p99 remote cache latency가 매우 안정적으로 되었지만 (100ms) 여전히 간간히 latency가 튀는 경우가 있었음(1sec). Latency가 pod이 종료될때 발생하는 것을 확인. 클라이언트 요청이 종료중인 remote cache pod에 보내졌고 timeout과 retry가 발생한 것으로 관찰됨. try5) preStop hook을 remote cache pod에 구현해서 클라이언트에게 pod이 곧 종료됨을 알려줄 수 있게 함 -> ✨ 드디어 모든 문제가 해결됨 문제가 발생하면 때로는 문제를 해결해줄 하나의 silver bullet을 찾을 때가 있지만, 실제로는 이와 같이 여러 환경과 코드의 복합적인 요소로 문제가 발생하게 되는 경우가 많습니다. 이런 문제를 마주 했을 때 하나씩 파헤치면서 문제가 되어보이는 범위를 줄여가다보면 병목이 되는 부분을 발견할 수 있는 것 같습니다. https://www.datadoghq.com/blog/engineering/not-just-another-network-latency-issue/