OpenTracing 연구하기
- 5. High Availability/Tracing
- 2020. 6. 24.
OpenTracing 개요
안녕하세요 김민욱입니다.
이번 포스팅에서는 마이크로서비스(Microservice) 구조에서 서비스 간의 호출에 따른 요청과 실행 되는 메소드들을 추적하여 확인하고 지연, 장애를 식별할 수 있는 트레이싱 툴의 비공식 표준인 CNCF의 OpenTracing에 대해 공식 문서[1]를 기준으로 한 번 살펴보도록하겠습니다.
클라우드 환경이 도입되고 컨테이너로의 발전과 함께 소프트웨어 아키텍쳐의 발전으로 이어지고 있습니다. 개발 프로세스는 DevOps로 가상머신은 컨테이너로, 어플리케이션 아키텍쳐는 기존 모놀리식 구조에서 마이크로서비스 구조로 진화하였습니다.
컨테이너 기반의 마이크로서비스들은 클라이언트의 요청을 처리하기 위해 여러 개의 개별적인 분산 서비스들로 구성되고 서로 클라우드 상에서 네트워크 혹은 메시지 버스를 통해 연결되어 있습니다. 그러나 클라이언트 요청에 완벽하게 응답하기 위해서는 마이크로서비스 구조는 한 가지 단점이 있었습니다. 만약 요청에 대한 응답이 오지 않을 경우 분산된 서비스들 중 어느 서비스에서 장애가 발생하였는지, 그에 대한 이유가 무엇인지 파악하기 어려웠습니다.
기존 모니터링 시스템들을 적용하더라도 서비스의 순서를 파악하고 어느 서비스에서 왜 장애가 발생했는지 파악하기 어려웠기 때문에 트레이싱 기술이 다시 떠오르게 되었습니다. 트레이싱 기술은 분산된 환경에서 어플리케이션 기능을 제공하기 위해 구성된 개별적인 여러 서비들 간의 호출을 추적하여 어느 서비스에서 응답이 지연 되었는지, 병목이 발생하지 않는지, 장애가 발생하였는지 등을 파악할 수 있는 기술 입니다.
그 중 컴퓨팅 분야에서 막강한 영향력을 끼치고 있는 CNCF(Cloud Native Computing Foundation)에서는 OpenTracing 프로젝트를 표준으로 선정하였습니다. OpenTracing 프로젝트는 실행 가능한 프로젝트가 아닌 트레이싱을 위한 규격, API, 프레임워크 등을 정의하는 프로젝트이고 Tracer라는 실제 프로젝트들이 이러한 표준을 기반으로 구현되었습니다.
다만 CNCF는 공식적인 표준 기관이 아니기 때문에 OpenTracing은 CNCF에서 사용하는 표준이지 대외적으로 인정되는 표준은 아닙니다. 하지만 그만큼 많은 사람들이 사용하고 이를 기반으로 많은 프로젝트가 나온 상태이기 때문에 그만큼 영향력 있다고 볼 수 있습니다.
참고로 OpenTracing은 Google의 논문 "Dapper, a Large-Scale Distributed System Tracing Infrastructure" 를 기반으로 용어를 정의하였습니다. 그럼 지금부터 OpenTracing의 구성과 용어에 대해 알아보도록 하겠습니다.
OpenTracing 구성
본 포스팅에서 설명하는 OpenTracing의 내용은 기본적으로 OpenTracing 공식 문서를 기준으로 설명하고자 합니다. 이후 이러한 트레이싱을 구현한 프로젝트 또한 포스팅 할 예정입니다. 앞서 말씀드린대로, OpenTracing의 용어 혹은 구조들은 Google의 논문 " Dapper, a Large-Scale Distributed System Tracing Infrastructure"의 기술을 기반으로 적용된다고 공식 문서에서 언급하고 있습니다.
그림 1에서는 OpenTracing 기본 플로우를 나타냅니다. 클라이언트의 요청 부터 시작하여 요청을 처리하기 위해 구성된 여러 서비스들을 거치는 전체 플로우를 Trace라고합니다. 상단 그림에서 보이는 바와 같이 클라이언트 요청을 처리하는 전체 과정을 Trace로 정의합니다.
Span은 일정 시간 동안의 작업으로 시간에 따른 시작과 끝을 가지게 됩니다. 프로그램 흐름상 메소드 혹은 함수 하나의 실행으로 봐도 될 것같습니다. 메소가 실행하는 도중 다른 메소드 호출이 발생할 때 이는 이전 메소드에 속한 것과 동일함으로 Child Span으로 정의합니다. 따라서 서비스는 가장 먼저 실행되는 Parent Span에서 호출되는 여러 Child Span으로 이루어 지게 됩니다. 공식문서에서는 Span은 다음 내용을 포함해야한다고 말합니다.
- An Operation Name
- A start timestamp and finish timestamp
- A set of key:value span Tags
- A set of key:value span Logs
- A SpanContext
위에서 언급한 Span을 구성하는 전체 예를 공식문서에서는 아래와 같이 나타내었습니다.
그림 2에서는 Span의 예를 나타내며 그 의미는 아래와 같습니다.
#Operation Name
=> 실행되는 Span의 이름으로 Span 예제에서는 db_query를 의미합니다.
#TimeStamp
=> Span의 시작과 종료되는 시간을 나타냅니다.
#Tag
=> 트레이싱 되는 정보를 필터링 하거나, 쿼리하기 위한 키:값입니다.
#Log
=> 로그 메시지와, 디버깅 및 정보를 출력하는데 사용되는 키:값입니다.
#SpanText
=> 특정 서비스의 모든워크플로우가 끝나고 다음 서비스로의 네트워크 혹은 메시지 버스를 통해 전달하는 정보의 집합체로 Trace ID, 다음 서비스에게 전달해야할 데이터 정보등이 포함됩니다.
결론
이번 포스팅에서는 OpenTracing에 대해 공식문서를 기준으로 간략하게 알아보았습니다.
짧은 내용이지만 대략적인 구성을 파악하고 이후 실 Tracer를 연구하기 위해 비교적 기본적인 내용들만 포함하였습니다. 혹 부족한 부분이 있다면 말씀주시면 수정하겠습니다.
감사합니다.
인용글
[1] OpenTracing Docs : https://opentracing.io/docs
업데이트로그
-------------------------------------------------------------------------------------------------------------------------
해당 글은 스스로 연구한 내용을 통한 주관적인 이해를 바탕으로 작성 되었습니다. 수정 할 부분이 있거나, 다른 의견이 있으시다면 언제든지 말씀해주시면 반영하도록 하겠습니다. 읽어 주셔서 감사합니다. 끝으로 불법으로 복제하는 것은 금합니다.