분산 트레이스의 이점과 제한 사항

분산 트레이스란?

분산 트레이스란? 분산 트레이스는 IT팀과 DevOps팀이 애플리케이션과 마이크로 서비스로 구성된 애플리케이션을 모니터링하는 방법입니다. 분산 트레이스는 장애가 발생하는 장소와 최적의 성능을 발휘하지 못하는 원인을 특정하는 데 도움이 됩니다. 분산 트레이스를 사용하려면 소프트웨어 개발자가 애플리케이션 코드에 계장을 추가해야 합니다. 이 계측은 관리자가 성능을 분석하고 개발자가 복잡한 소프트웨어의 작업을 디버깅할 수 있도록 정보를 제공합니다. 추적 기본 요청에 대해서 설명하자면 요청 트레이스는 소프트웨어 엔지니어링의 기본 작업입니다. 개발자는 애플리케이션 코드 내의 중요한 동작에 대한 관련 메트릭을 추적하고 전달하기 위해 설정된 계측 코드의 작은 부분을 사용합니다. 대부분의 경우 웹 사이트에 대한 사용자 요청 등 소프트웨어 내에서 발생하는 요청 동작을 추적하는 것이 목표입니다. 이 일반적인 사용법이 이 기술에 이름 요청 트레이스라는 이름을 부여했습니다. 요청 추적은 애플리케이션 성능 관리와 유사성을 공유합니다. 보고 도구는 요청에서 메트릭 스트림의 시각화를 구성, 처리 및 생성하여 소프트웨어 동작의 그림을 만듭니다. 애플리케이션 팀은 이 보고서를 사용하여 성능 문제나 사용자 경험 저하를 일으킬 수 있는 잠재적인 이상을 신속하게 발견합니다. 여러 기능 모듈 또는 서비스를 사용하는 분산 소프트웨어 아키텍처에서 요청 추적을 사용할 경우 심각한 문제에 직면합니다. 서비스는 독립적으로 확장되므로 동일한 기능을 여러 번 반복할 수 있으며 잠재적으로 다른 호스트 시스템 또는 다른 환경에서 실행될 수 있습니다. 단일 애플리케이션 내에서 함수 X를 통해 요청을 추적하는 것은 간단한 일이지만 마이크로 서비스 기반 아키텍처는 2개의 데이터 센터에 있는 4대의 서버에서 함수 X를 20회 반복 실행할 수 있습니다. 이러한 서비스는 모두 연계하여 다른 서비스와 상호 운용하여 완전한 애플리케이션을 형성해야 합니다. 요청 추적은 요청이 여러 다른 서비스와 여러 서비스 인스턴스를 통과할 때 메트릭을 계속 수집해야 합니다. 분산 요청 추적은 각 모듈 또는 서비스를 통해 요청을 추적할 수 있습니다. 예를 들어서 분산 추적을 통해 애플리케이션 설계자는 함수 X의 각 반복의 성능을 시각화할 수 있습니다. 지원을 수행하는 개발자 및 운영 전문가는 함수 X의 한 인스턴스가 다른 인스턴스보다 훨씬 많은 지연 시간을 발생시키고 있음을 신속하게 식별하고 문제를 해결할 수 있습니다. 트레이스 및 스팬에 대해서 살펴보자면 분산 트레이스는 트레이스와 스팬에 의존합니다.트레이스는 요청의 완전한 처리입니다. 트레이스는 요청이 분산 시스템의 모든 서비스 또는 컴포넌트를 통과할 때의 이동 경로 전체를 나타냅니다. 요청에 의해 생성된 모든 트레이스 이벤트는 툴이 특정 트레이스를 정리, 필터링 및 검색하기 위해 사용하는 트레이스 ID를 공유합니다. 각 트레이스는 다수의 스팬으로 구성됩니다. 스팬은 세그먼트라고도 불리며 분산 시스템의 개별 서비스 또는 컴포넌트 내에서 이루어지는 액티비티 또는 조작입니다. 각 스팬은 요구 전체의 전체 처리의 다른 단계입니다. 일반적으로 스팬은 명명된 작업 및 시간 지정 작업입니다. 스팬은 각각 고유한 스팬 ID를 전송하며 메타데이터 또는 기타 주석을 전송할 수도 있습니다. 소프트웨어 개발자와 운영 직원은 각 스팬을 통해 사용자 요청을 추적하고 각 스팬을 서비스 인스턴스와 연관시킬 수 있으며 각 스팬이 실행되는 호스트 시스템의 물리적 위치도 확인할 수 있습니다. 스팬은 요청 트레이스의 완전한 그림을 형성합니다.트레이스내의 각 스팬을 평가함으로써 문제의 원인을 특정할 수 있습니다. 추적 데이터는 실시간으로 공유 및 처리되지 않습니다. 소프트웨어 계측과 통신하는 에이전트 또는 데몬을 사용하여 로컬 저장소 리소스로 생성 및 수집됩니다. 그런 다음 해당 데이터를 중앙 위치로 이동하고 필요에 따라 분석합니다. 이는 현대의 이벤트 로깅 및 기타 메트릭 수집 활동과 유사한 프로세스입니다. 분산된 요구 트레이스는 애플리케이션을 통한 요구의 완전한 경로를 반영하기 위한 것이므로 거의 항상 요구가 프론트 엔드에 도착한 시점부터 미들웨어, 백엔드 액세스 및 요구자에게 전달된 결과를 통해 엔드 투 엔드의 퍼포먼스를 평가합니다. 로컬 트레이스라는 개념은 일반적으로 분산 요구 트레이스 액티비티에는 적용되지 않습니다. 그렇다면 본격적으로 분산 추적의 이점과 제한 사항에 대해서 살펴보겠습니다. 분산 트레이스의 장점은 문제를 정확히 파악하는 정확성과 최신 소프트웨어 아키텍처와의 호환성입니다. 하지만 셋업이 어렵고 벤더에 구속될 위험이 있는 등 제한이 있습니다. 분산 요구 트레이스는 가장 일반적으로 APM 테크놀로지와 비교됩니다.APM 툴은 소프트웨어 워크로드의 퍼포먼스와 가용성을 감시하고 관리하며 워크로드에 대해 확립된 최소한의 서비스 수준과 관련된 성능 문제 및 경고에 대한 정보를 제공합니다. APM 툴은 피크 부하 시의 평균 응답 시간 등 최종 사용자의 경험을 반영하는 메트릭을 제공합니다. 또한, 워크로드에서 사용되는 리소스를 자주 추적하여 리소스 용량과 잠재적인 병목 현상을 식별합니다. 이러한 도구는 소프트웨어 코드에 직접 연결되어 있지 않습니다. 분산 요구 트레이스는 이벤트 로깅과도 자주 비교됩니다. 이는 로깅과 트레이스 모두 주요 소프트웨어 액티비티를 감시 및 보고하기 위해 일정 수준의 계측에 의존하기 때문입니다. 이벤트 로깅은 몇 가지 주요 영역에서 요청 추적과 다릅니다. 로깅은 리소스가 소정의 임계값을 초과하는 등 높은 수준의 이벤트 정보를 캡처합니다.과도한 정보나 중복 정보를 포함할 수 없으며 로그 집계 및 분석에 대해 규정된 표준 형식을 따르는 경우가 많습니다. 이에 비해 요청 추적은 다양한 형식으로 방대한 양의 낮은 수준의 정보를 캡처할 수 있습니다. 분산 트레이스는 마이크로 서비스 등의 최신 분산 소프트웨어 아키텍처를 디버깅하고 감시하는 데 적합합니다. 이 경우 시간에 민감한 요구는 여러 서비스, 시스템, 심지어 설비를 통과해야 합니다. 트레이스는 잠재적인 문제를 확실하게 분리할 수 있는 정확한 세부 정보를 제공합니다. 그러나 분산 트레이스를 사용하려면 프로덕션 코드베이스에 어느 정도 수준의 계측을 추가해야 하며 트레이스 데이터를 검색하고 시각화하는 데 사용되는 도구는 설정 및 생산적으로 사용하기에는 복잡할 수 있습니다. 분산된 요청 추적 정보를 수집, 필터링 및 제공하는 도구는 많습니다. 일반적인 예시는 다음과 같습니다. 먼저 데이터로그는 APM 업그레이드 패키지에 분산 트레이스를 통합합니다. 그리고 Zipkin은 주로 구글의 Dapper 조사에 기반한 오픈 소스 도구입니다. 이어서 오픈 소스 Embassy 프록시 도구는 Lyft에서 수행한 작업을 통해 개발되었고 AWS는 고객에게 X-Ray 서비스를 제공합니다. 또한 LightStep 모니터링 서비스는 또한 구글의 대퍼 연구로부터 시작되었으며 분산 트레이스 커뮤니티는 벤더에 의존하지 않는 오픈 표준 오픈트레이싱을 개발했습니다. 개발자는 API를 사용하여 애플리케이션 코드베이스에 인스트루먼테이션을 쉽게 추가할 수 있습니다. 이것에 의해서 특정의 제품에 인스트루먼테이션은 행해지지 않습니다.