마이크로서비스를 사용하도록 애플리케이션을 다시 작성하면 단일 사용자 트랜잭션과 관련된 구성요소 및 엔드포인트의 수가 증가합니다. 따라서 사용자 서비스를 안정적으로 운영하기 위해서는 관측 가능성이 중요합니다. 이 참조 아키텍처는 OpenTelemetry 및 Cloud Trace를 사용하여 마이크로서비스 애플리케이션의 trace 정보를 캡처하는 방법을 보여줍니다.
이 문서는 분산 추적의 기본 사항을 이해하고 그러한 원칙을 서비스에 적용하여 관측 가능성을 개선하고자 하는 개발자, SRE, DevOps 엔지니어를 대상으로 합니다.
아키텍처
다음 다이어그램은 이 아키텍처를 구현하는 애플리케이션의 아키텍처를 보여줍니다.
앞의 다이어그램에서 볼 수 있듯이 이 아키텍처에는 2개의 GKE 클러스터가 포함되어 있습니다. 각 클러스터에 애플리케이션을 배포합니다. 사용자 트래픽은 프런트엔드 클러스터의 프런트엔드 애플리케이션으로 전송됩니다. 프런트엔드 클러스터의 프런트엔드 포드는 백엔드 클러스터의 백엔드 포드와 통신합니다. 백엔드 포드는 외부 API 엔드포인트를 호출합니다.
관측 가능성 데이터는 요청이 애플리케이션을 통해 전파되는 방법을 추적하는 Cloud Trace로 내보내집니다.
설계 고려사항
Kubernetes에서 실행되는 서비스의 경우 Istio와 같은 서비스 메시를 사용하여 전용 계측 도구 없이 서비스 간 트래픽의 분산 추적을 활성화합니다. 그러나 다음과 같은 요구사항이 있을 수 있습니다.
- Istio에서 제공하는 것보다 trace를 더 상세하게 제어하려고 합니다.
- trace 정보에서 애플리케이션 내부를 캡처해야 할 수 있습니다.
- Kubernetes에서 실행되지 않는 코드를 추적해야 할 수 있습니다.
이러한 사용 사례에서는 분산된 마이크로서비스 애플리케이션에 계측을 추가하여 광범위한 언어, 플랫폼, 환경에서 trace, 측정항목, 로그를 수집할 수 있는 오픈소스 라이브러리인 OpenTelemetry를 사용할 수 있습니다.
trace, 스팬, 컨텍스트 이해
분산 추적의 개념은 Google이 발표한 Dapper 연구 논문에 설명되어 있습니다. 논문의 설명과 같이 다음 다이어그램은 trace에서 5개의 스팬을 보여줍니다.
trace는 분산 시스템이 사용자 요청에 응답하는 방법을 설명하는 정보의 총합입니다. trace는 스팬으로 구성되며 각 스팬은 사용자 요청 처리와 관련된 특정 요청 및 응답 쌍을 나타냅니다. 상위 스팬은 최종 사용자 관점에서 경험하는 지연을 설명합니다. 각 하위 스팬은 분산 시스템의 특정 서비스가 어떻게 호출되고 응답했는지를 각각에 대해 캡처된 지연 정보와 함께 설명합니다.
다이어그램은 2개의 백엔드 요청을 수행하는 단일 프런트엔드 요청을 보여줍니다. 두 번째 백엔드 호출을 완료하려면 두 번의 도우미 호출이 필요합니다. 각 호출에는 스팬 ID와 상위 스팬의 ID 라벨이 표시됩니다.
분산 시스템의 추적에서 문제는 다양한 백엔드 서비스에 대한 후속 요청이 수행될 때 원래 프런트엔드 요청에 대한 정보가 자동으로 또는 본질적으로 전달되지 않는다는 것입니다.
일부 도구(예: Go 언어)를 사용하면 컨텍스트(클러스터 IP 주소 및 사용자 인증 정보)로 요청을 수행할 수 있습니다. OpenTelemetry는 컨텍스트의 개념을 확장하여 스팬 컨텍스트를 포함합니다. 즉, HTTP 헤더에 추가 정보가 로드됩니다. 그런 다음 상위 스팬에 대한 정보를 각 후속 요청에 포함할 수 있습니다. 하위 스팬을 추가해서 전체 trace를 구성하면 사용자 요청이 어떻게 시스템을 통과하고 최종적으로 사용자에게 다시 돌아오는지를 확인할 수 있습니다.
배포
이 아키텍처를 배포하려면 마이크로서비스 지연 시간을 관찰하기 위한 분산 추적 배포를 참조하세요.
다음 단계
- OpenTelemetry에 대해 알아보세요.
- 이 아키텍처와 관련된 DevOps 기능을 자세히 알아보세요.
- DevOps 빠른 점검을 사용하여 업계와 비교되는 자신의 현재 상태를 파악하세요.
- 그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 클라우드 아키텍처 센터를 확인하세요.