dial9 — Tokio 런타임의 블랙박스 레코더, 프로덕션에서 5% 미만 오버헤드로 이벤트 타임라인 기록

dial9: Tokio 런타임의 블랙박스 레코더가 나왔음

• Tokio용 런타임 텔레메트리 도구 dial9이 공개됨. 핵심은 기존의 집계 메트릭(aggregate metrics)이 아니라 개별 poll, park, wake 이벤트를 타임라인 로그로 기록한다는 점
• Tokio 런타임 이벤트 + 애플리케이션 span/로그 + Linux 커널 이벤트를 통합해서, 앱 ↔ Tokio ↔ OS 간 상호작용의 전체 그림을 보여줌

탄생 배경: 프로덕션에서만 재현되는 성능 문제

• 수천 개의 호스트에 동시 연결하는 Rust 서비스에서 CPU 90% 넘어가면 성능이 급락하는 문제가 있었음. CPU 여유는 있는데 왜 느려지는지 알 수 없었음
• Tokio 런타임 메트릭을 보면 워커는 유휴 상태인데 큐는 가득 차 있는 모순적 상황
• dial9을 붙여보니 원인이 바로 보였음: 10ms 이상의 커널 스케줄링 딜레이가 빈번하게 발생하고 있었음. 5-10ms 레이턴시를 유지해야 하는 서비스에서 이건 치명적

실제 프로덕션 디버깅 사례들

• 커널 스케줄링 딜레이 감지: 워커 47을 깨우려고 했는데 커널이 실제로 스케줄링하기까지 18ms 걸림. 그 동안 트래픽을 단일 워커가 처리하고 있었음
• fd_table 컨텐션 발견: 서비스 시작 시 대량의 동시 연결을 열 때 fd_table 리사이징에 락이 걸려서 100ms+ poll이 발생. 집계 메트릭만으로는 절대 못 찾는 유형의 문제
• 태스크가 워커 사이를 계속 옮겨다니는 현상: I/O 드라이버 특성상 소켓 대기 후 다음에 픽업하는 워커가 사실상 랜덤임. 2ms 동안 하나의 태스크가 5개 워커를 옮겨다니는 걸 실제로 시각화해서 보여줌. runtime-per-core 아키텍처가 데이터 집약 앱에 유리한 이유를 직관적으로 보여주는 사례

바로 써볼 수 있음

• cargo add dial9-tokio-telemetry로 설치하고, TracedRuntime으로 런타임을 감싸면 끝
• RotatingWriter가 디스크 사용량을 제한해줘서 프로덕션에 그냥 켜둘 수 있음. S3 직접 쓰기도 지원
• 오버헤드는 보통 5% 미만이라고 함. 이미 AWS 내부 팀들이 프로덕션에서 사용 중