사용 사례

아무도 배포하지 않았습니다. 그런데도 지연이 두 배가 됐습니다.

분산 시스템에서 느려진 서비스가 곧 고장 난 서비스인 경우는 드뭅니다. 맵은 어느 간선이 먼저 나빠졌는지 보여주고, 트레이스는 대기가 어디까지 번졌는지 보여줍니다.

signal api-gateway p95 1.9 s · was 0.9 s, no deploy

경로

증상에서 원인까지 두 홉

payment-svc@1.4.2는 증상이 나타나기 네 시간 전에 배포된 릴리스입니다. 이것이 전체 경로를 꿰뚫습니다. 맵·트레이스·로그가 모두 여기에 맞춰 좁혀져 있습니다.

deploy payment-svc@1.4.2 /service-map /traces /logs T+0:00 T+1:10 T+2:40

map T+0:00 · deploypayment-svc@1.4.2

맵은 느린 서비스가 아니라 느린 간선을 보여줍니다

호출된 것은 api-gateway지만 그 자체 스팬에는 문제가 없습니다. 나빠진 간선은 두 홉 안쪽, payment-svc에서 user-db로, 평균이 12ms에서 210ms로 올랐습니다.
trace T+1:10 · deploypayment-svc@1.4.2

트레이스는 작업이 아니라 대기를 보여줍니다

느린 요청을 열면 대부분이 db 스팬입니다. 쿼리 자체는 4ms인데 스팬은 210ms입니다. 그 차이는 쿼리가 실행되기도 전에 흘러간 시간입니다.
logs T+2:40 · deploypayment-svc@1.4.2

로그가 릴리스를 지목합니다

그 스팬의 로그 줄에는 pool wait 206ms, 세 번째 시도에 획득이라고 적혀 있습니다. service.version으로 거르면 1.4.2부터 시작되며, 이 릴리스는 풀을 늘리지 않은 채 동시성만 올렸습니다.

결과

새 동시성에 맞춰 풀 크기를 늘렸습니다. 간선의 p95 지연은 롤백 없이 14ms로 돌아왔습니다.

할 수 있는 일

간선은 자체 지연을 가집니다: 맵은 호출자-피호출자 쌍별로 따로 측정합니다. 특정 호출자에게만 나빠진 의존성은 서비스 전체 평균이 아니라 하나의 간선으로 드러납니다.
db 스팬은 대기와 작업의 합입니다: 클라이언트 스팬이 실행뿐 아니라 연결 획득까지 감싸기 때문에, 풀 고갈은 하나의 숫자 안에 숨지 않고 스팬 소요 시간과 쿼리 소요 시간의 차이로 드러납니다.
배포하지 않았다는 것도 배포입니다: 모든 스팬에 service.version이 붙어 있으면 질문이 '누가 배포했는가'에서 '이 스팬은 어느 버전의 것인가'로 바뀝니다. 네 시간 전 릴리스도 4분 전 것만큼 쉽게 찾을 수 있습니다.