2초짜리 작업 20건을 한꺼번에 넣었더니 사용자는 최대 20초를 기다렸다. 처리 시간은 건마다 2.02초로 일정했고, 나머지는 전부 큐에서 줄 선 시간이었다. 로그에 wait_ms 를 남기고 OpenSearch Dashboards 로 둘을 나눠 보니 병목이 워커 수로 드러났고, 워커를 6개로 늘리자 큐 대기 p50 이 10.0초에서 2.0초가 됐다.
Fluentd 집계기 출력을 OpenSearch 로 바꿨더니 request_id 가 text 로 잡혀 trace-8th-0001 을 찾는데 다른 요청까지 44건이 나왔고, event 로 집계하자 "Text fields are not optimised" 로 거절됐다. 인덱스 템플릿으로 타입을 정하고, 집계기와 OpenSearch 를 지워도 로그가 남는지 쟀다.
ingress-nginx 는 요청마다 X-Request-ID 를 만들어 주는데, 앱 로그에는 그 번호가 한 줄도 없었다. 번호를 web 로그와 RabbitMQ 메시지의 correlation_id, worker 로그까지 넘겼더니 재시도 두 번에 DLQ 까지 간 요청 하나가 번호 하나로 15줄, 파드 5개에 걸쳐 이어졌다.
작업 하나의 로그 34줄이 파드 4개에 흩어져 있었고, web 로그의 56.9% 는 /healthz 였다. 노드마다 Fluentd forwarder 를 DaemonSet 으로 띄워 한곳의 aggregator 로 모았더니 지운 파드의 로그도 남았다. 대신 aggregator 가 바뀌자 쌓여 있던 581건이 사라졌다.
실패를 다시 할 것과 끝낼 것으로 나누고, TTL 과 데드레터만으로 5초·15초 재시도와 DLQ 를 만든다. 워커를 강제로 죽였더니 작업은 사라지지 않았지만 72.9초 뒤에야 돌아왔고, 평범하게 내렸더니 python 이 PID 1 이라 SIGTERM 을 무시해 31.2초가 걸렸다.
동기 호출을 RabbitMQ 큐로 바꿨더니 죽은 주소가 섞여도 접수가 24ms 에 끝났다. 대신 결과 조회가 404 를 내며 실패했다. 파드가 여럿일 때 상태를 메모리에 두면 생기는 일과, 큐가 대기를 없애는 게 아니라 옮긴다는 점까지 실측으로 짚는다.
링크 미리보기 서비스의 평균 응답은 0.41초다. 그런데 죽은 주소 두 개가 들어오자 멀쩡한 요청이 7.17초를 기다렸다. 34배다. 평균만 보면 멀쩡해 보이는 시스템이 왜 무너지는지 직접 재 본다.
매니페스트 세 종류가 각각 무슨 일을 하는지 한 줄씩 짚는다. 서비스끼리는 IP 가 아니라 이름으로 부른다. 하위 경로에 앱을 붙였다가 API 요청이 엉뚱한 서비스로 새어 나간 이야기도 함께.
링크 미리보기 카드를 만드는 작은 서비스를 마이크로서비스로 쪼개 쿠버네티스에 올린다. 배포는 kubectl 이 아니라 git 커밋으로 한다. 아홉 편에 걸쳐 RabbitMQ·Fluentd·OpenSearch 까지 붙여 볼 연재의 첫 글.
