요청 추적으로 gRPC 애플리케이션 디버깅하기
데모 애플리케이션 emojivoto에는 몇 가지 문제가 있어요. 이 예제를 Linkerd와 함께 사용해, 전체 서비스가 크래시하는 것보다는 조금 더 미묘한 방식으로 실패하는 애플리케이션을 진단해 볼게요. 이 가이드는 Getting Started 가이드의 단계를 따라 Linkerd와 데모 애플리케이션을 Kubernetes 클러스터에 실행 중이라고 가정해요. 아직 안 했다면 시작하고, 끝나면 돌아와 주세요!
출처: Linkerd Debugging gRPC applications with request tracing
본문
데모 애플리케이션 emojivoto에는 몇 가지 문제가 있어요. 이 예제와 Linkerd를 사용해, 전체 서비스가 크래시하는 것보다 조금 더 미묘한 방식으로 실패하는 애플리케이션을 진단해 볼게요. 이 가이드는 Getting Started 가이드의 단계를 따라 Linkerd와 데모 애플리케이션을 Kubernetes 클러스터에 실행 중이라고 가정해요. 아직 그렇게 하지 않았다면 시작하고, 끝났으면 돌아와 주세요!
Linkerd 대시보드(linkerd viz dashboard 명령 실행)를 보면 emojivoto 네임스페이스의 모든 리소스(디플로이먼트 포함)가 보여요. Linkerd가 실행되는 각 디플로이먼트는 성공률, 초당 요청 수, 지연 백분위를 표시해요.
최상위 메트릭
꽤 멋지죠? 하지만 가장 먼저 눈에 띄는 건 성공률이 100%보다 훨씬 낮다는 거예요! web을 클릭해서 자세히 파고들어 봐요.
디플로이먼트 상세
이제 web 디플로이먼트의 Deployment 페이지를 보고 있을 거예요. 가장 먼저 보이는 것은 web 디플로이먼트가 vote-bot(emojivoto에 포함되어 계속 낮은 수준의 실시간 트래픽을 생성하는 디플로이먼트)에서 트래픽을 받고 있다는 점이에요. web 디플로이먼트에는 emoji와 voting이라는 두 개의 나가는 의존성도 있어요.
emoji 디플로이먼트는 web에서 오는 모든 요청을 성공적으로 처리하고 있지만, voting 디플로이먼트는 일부 요청을 실패시키고 있는 것 같아요! 의존 디플로이먼트의 실패가 바로 web이 반환하는 오류의 원인일 수 있어요.
페이지를 조금 더 아래로 스크롤하면 web으로 들어오는 그리고 web에서 나가는 모든 트래픽의 실시간 목록을 볼 수 있어요. 흥미롭네요.
상위
100%가 아닌 호출이 두 개 있어요. 첫 번째는 vote-bot의 /api/vote 엔드포인트 호출이에요. 두 번째는 web 디플로이먼트가 의존 디플로이먼트인 voting으로 보내는 VoteDoughnut 호출이에요. 아주 흥미로워요! /api/vote는 들어오는 호출이고 VoteDoughnut은 나가는 호출이므로, 이 엔드포인트가 문제의 원인일 가능성이 크다는 좋은 단서예요.
마지막으로 더 깊이 파고들기 위해 오른쪽 끝 열의 tap 아이콘을 클릭할 수 있어요. 그러면 이 엔드포인트와 일치하는 요청만의 실시간 목록으로 이동해요. GRPC status 열에 Unknown이 보일 거예요. 요청이 gRPC 상태 코드 2로 실패하기 때문이에요. 코드에서 볼 수 있듯이 이 코드는 흔한 오류 응답이에요. Linkerd는 다른 설정 없이도 gRPC의 응답 분류를 인지하고 있어요!
Tap
이 시점에서 우리는 엔드포인트를 고치고 애플리케이션의 전반적인 건강을 복구하는 데 필요한 모든 것을 갖췄어요.