OpenTelemetry가 앱 추적 및 설계 방식을 어떻게 바꾸고 있는가

여러 위치에서 실행되는 수많은 마이크로서비스 간의 상호작용을 통해 애플리케이션 기능이 구현되는 클라우드 네이티브 앱을 운영할 때는 관측 가능성이 핵심입니다. 마이크로서비스 앱은 느슨하게 결합되어 있으므로 각 마이크로서비스가 자체적인 방식으로 활동을 보고할 수 있습니다. 이러한 텔레메트리 데이터를 수집하고 연계하는 도구가 없다면 문제 해결에 필수적인 요청 처리 과정을 처음부터 끝까지 추적하기가 불가능하지는 않더라도 매우 어렵습니다.

다기능 관측성 도구를 찾던 중, NGINX Modern Apps Reference Architecture(MARA) 프로젝트 팀은 OpenTelemetry를 선택했습니다. OSS 팀이 이 신생 프로젝트를 선택한 만큼, 이에 대해 더 자세히 살펴보고자 합니다. GlueCon 2022에서 저는 F5 CTO실의 아키텍트인 Granville Schmidt와 만나 OpenTelemetry의 현재 상태와 향후 제공 기능에 기대를 거는 이유를 논의했습니다. 아래에서 대화를 시청하고, 이 블로그를 통해 OpenTelemetry가 클라우드 네이티브 애플리케이션 환경에 매우 유용한 자산인 이유를 자세히 알아보세요.

OpenTelemetry가 옵저버빌리티 2.0을 지원합니다

바르셀로나에서 열린 KubeCon 2019에서 처음 발표된 OpenTelemetry는 열정적인 기여자들의 참여를 이끌어냈습니다. 기여 횟수를 기준으로 Cloud Native Computing Foundation(CNCF)에서 두 번째로 인기 있는 프로젝트이며, 지난 6개월 동안 기여 속도는 그 어느 때보다 빨랐습니다. 이처럼 많은 기여자가 참여한다는 것은 OpenTelemetry가 성숙 단계에 접어들었으며, 남들보다 앞서 나가려는 얼리 어답터와 성숙한 제품을 원하는 실용주의자 사이의 간극을 넘어 대중화되기 시작했음을 보여줍니다.

OpenTelemetry는 데이터, 구체적으로는 애플리케이션을 가장 효과적으로 이해하고 문제를 해결하며 개선하는 데 필요한 데이터와 데이터 스트림(텔레메트리)에 중점을 둡니다. 데이터는 대규모로 집계, 분석 및 시각화할 수 있을 때만 유용합니다. OpenTelemetry는 데이터를 시각화하는 방법에 대한 지침을 제공하지는 않지만, 어떤 데이터를 얻을 수 있는지에 대한 고민에서 벗어나 그 데이터로 무엇을 할 수 있는지에 집중할 수 있게 해줍니다.

OpenTelemetry는 이러한 데이터 소스 간의 상관관계를 직접 파악해야 하는 부담 없이 자연스럽게 연계할 수 있도록 해줍니다. 여러 애플리케이션에서 발생하는 이벤트를 연계하는 OpenTelemetry의 기능은 클라우드에서 애플리케이션 활동을 측정하는 새로운 기준인 Observability 2.0으로 우리를 이끌고 있습니다. 데이터가 이미 서로 연계되어 있으므로 애플리케이션 환경을 바라보는 방식도 달라집니다. 이제는 애플리케이션의 실행 여부만 파악하는 데 그치지 않고, 모든 요청이 애플리케이션을 거치며 이동하는 경로까지 이해할 수 있습니다.

OpenTelemetry에 앞서 두 개의 주목할 만한 오픈 소스 프로젝트인 OpenTracing(OT)과 OpenCensus(OC)가 있었습니다. 두 프로젝트 모두 추적 데이터의 형식을 표준화하여 필요한 정보를 확보하고 해당 데이터가 최신 애플리케이션에 미치는 영향을 파악하는 과제를 해결하고자 했습니다. 두 프로젝트는 유사한 점이 있었지만 리소스를 두고 경쟁했으며, 기업들은 둘 중 하나만 선택해야 하는 경우가 많았습니다. 2019년 3월, 두 프로젝트는 OpenTelemetry로의 통합을 발표했으며, 추적 데이터의 생성 및 형식 지정 방식을 통합하는 것을 목표로 삼았습니다. OpenTelemetry 프로젝트는 추적과 동일한 텔레메트리 채널을 통해 다른 유형의 관측 가능성 데이터(메트릭 및 로그)를 수집하기 위한 표준도 추가로 정의하여 통합성과 명확성을 높이고 있습니다.

다음으로 OpenTelemetry의 흥미로운 두 가지 기능적 측면인 분산 추적과 애플리케이션 인텔리전스를 살펴보겠습니다.

최신 애플리케이션 아키텍처에 분산 추적이 필요한 이유

분산 추적은 수년 전부터 사용되어 왔지만, 지난 10년간 일어난 많은 변화로 인해 그 필요성이 더욱 커졌습니다. Cynefin 프레임워크를 활용하면 현대 애플리케이션에서 현재 직면하고 있는 몇 가지 변화와 과제를 다음과 같이 살펴볼 수 있습니다:

Cynefin 프레임워크는 단순한 영역에서 복잡한 영역으로 이동함에 따라 실천 방식을 어떻게 바꿀 수 있는지를 보여줍니다. 문제는 각각 고유한 특성을 지닌 두 개의 서로 다른 경로를 따라 이동해야 한다는 점이며, 단순한 영역에서 복잡한 영역으로 곧장 가는 지름길을 택하려 하면 혼란이 발생하고 전환이 불완전해지는 경우가 많습니다.

최신 앱 및 클라우드 네이티브로 전환하는 여정에서 어떤 요소가 경로를 형성하는지 살펴보겠습니다. 첫 번째 경로(Cynefin 다이어그램의 Y축)에는 일반적으로 마이크로서비스 아키텍처로 구성되며 각 앱이 특정 작업을 수행하는 최신 앱이 있습니다. 두 번째 경로(X축)에서는 복잡한 환경이 일시적으로 존재합니다. 수요에 따라 마이크로서비스 인스턴스가 생성되거나 종료되고, 네트워크 문제에 대응하여 다른 호스트로 이동하기 때문입니다.

Amazon Web Services(AWS), Microsoft Azure, Google Cloud Platform(GCP)과 같은 클라우드 환경의 등장과 폭발적인 성장도 고려해야 합니다. 이러한 클라우드의 장점은 현재 수요 수준에 맞춰 리소스를 확장하거나 축소하는 탄력적 대응 능력입니다. 여기에 컨테이너 오케스트레이션(가장 일반적으로 Kubernetes 사용)의 영향까지 더해지면, 시간이 지남에 따라 리소스의 수와 위치가 바뀌면서 혼돈적 양상이 나타나기 시작합니다. (이처럼 비교적 제한된 관점에서도 혼돈적이며, 서버리스 함수 같은 요소가 더해지면 혼돈이 더욱 심해질 수 있습니다.)

현대적인 아키텍처에서는 수많은 개별 구성 요소가 애플리케이션을 모니터링하고 유지 관리하는 데 필요한 텔레메트리 데이터를 생성하므로, 데이터 부하가 방대하고 복잡합니다. 인프라와 통신 경로를 완전히 제어할 수 없기 때문에 문제가 일관되게 재현되지 않거나 쉽게 유발되지 않을 수 있습니다. 변화하는 환경을 이해하고 분석하려면 모든 활동과 관련 요소를 추적할 수 있는 기술이 필요합니다.

바로 이때 OpenTelemetry가 필요합니다.

OpenTelemetry를 활용한 분산 추적의 미래

분산 추적은 업계에 큰 변화를 일으키고 있으며, 특히 요청을 기반으로 메트릭을 통해 성능을 내부적으로 파악하는 방식에 큰 영향을 미치고 있습니다. 분산 추적을 사용하면 다양한 유형의 새로운 메트릭을 추적할 수 있지만, 가장 일반적인 것은 단위 시간당 요청 수, 단위 시간당 오류 수, 그리고 해당 시간 동안 집계된 요청을 처리하는 데 걸리는 시간과 관련된 메트릭입니다.

메트릭은 오래전부터 사용되어 왔습니다. 관리와 저장이 쉽고, 간편하게 집계할 수 있으며, 수학적 분석에도 적합합니다. OpenTelemetry에서는 메트릭을 생성하는 모든 애플리케이션이 텔레메트리(전송) 계층을 통해 공통 수집 지점으로 메트릭을 보낼 수 있습니다. 이를 통해 메트릭을 생성하는 느슨하게 결합된 서비스의 데이터를 일관되게 정렬할 수 있으며, 여기에는 기반 인프라와의 정렬도 포함됩니다. 요약하면 OpenTelemetry를 사용하면 메트릭을 더 쉽게 수집하고 전송할 수 있습니다.

OpenTelemetry는 이벤트 간의 상관관계를 파악하기 어렵게 만드는 타임스탬프 드리프트 및 스큐 문제를 해결하는 데도 도움이 될 수 있습니다. OpenTelemetry는 각 요청에 TraceId를 할당하지만, 클라우드 네이티브 아키텍처에서 흔히 발생하는 드리프트와 스큐의 영향을 데이터가 여전히 받을 수 있습니다. 드리프트와 스큐는 보고 경로마다 소요 시간이 다르거나 여러 호스트의 시계가 긴밀하게 동기화되지 않아 발생할 수 있습니다. 분산 추적은 트래픽 처리 중 구성 요소 간 통신을 추적함으로써 OpenTelemetry가 관련 앱을 심층적으로 계측하지 않고도 개별 스팬 – 작업 단위이자 트레이스의 구성 요소 – 을 측정할 수 있도록 합니다.

이 세 가지 신호(텔레메트리 범주)를 결합하면 문제를 해결하고 앱을 프로덕션 품질로 복원할 수 있습니다.

• 메트릭 – “문제가 있나요?”
• 트레이스 – “문제가 어디에 있나요?”
• 로그 – “문제가 무엇인가요?”

여기서 다시 Observability 2.0으로 돌아가 보겠습니다. 트레이스를 확보하고 어떤 메트릭이 어떤 트레이스에 해당하는지 즉시 확인할 수 있다는 것은 매우 강력한 기능입니다. 예를 들어 메트릭이 문제를 나타낼 때 분산 트레이싱을 사용하면 최초 문제를 일으킨 특정 요청까지 거슬러 올라가 요청 처리의 각 단계에서 진행 상황을 추적할 수 있습니다. 트레이스는 발생 순서대로 정렬된 스팬으로 구성되므로 요청이 거치는 각 단계를 따라갈 수 있습니다. 최초 이벤트부터 감지된 문제를 거쳐 최종 결과에 이르기까지 어떤 일이 어떤 순서로 발생했는지 파악하면 앱 내에서 정확히 “어디에” 주의를 집중해야 하는지 특정할 수 있습니다.

간단하게 들릴 수도 있지만, OpenTelemetry의 분산 추적 기능은 요청의 성공 여부와 실행 시간을 간접적으로 보여 주므로 사용자가 무엇을 경험하고 있는지 파악하는 데 매우 유용합니다. 사용자로서 저는 제 요청에 관심이 있습니다. 사이트 신뢰성 엔지니어(SRE)로서 저는 집계된 요청에 관심이 있습니다. OpenTelemetry는 이 두 가지를 모두 제공할 뿐만 아니라, 모든 애플리케이션에서 필요한 모든 데이터를 사용할 수 있도록 설계되었기 때문에 집계된 정보에서 구체적인 세부 정보까지 자세히 살펴볼 수 있게 해 줍니다.

AI 및 ML을 활용한 애플리케이션 인텔리전스

OpenTelemetry에서 제공되는 이 새로운 데이터 스트림을 통해 개발 및 운영 대응을 상황에 맞게 조정하고 자동화할 수도 있습니다. 이렇게 축적된 모든 데이터를 활용하면 애플리케이션을 더욱 지능적으로 만들 수 있습니다. 현재 F5는 고객이 이른바 “적응형 애플리케이션”을 개발하고 배포하는 여정을 지원하는 데 주력하고 있습니다. 적응형 앱은 이름 그대로 환경 변화에 대응하여 동작을 자동으로 지능적으로 조정하는 애플리케이션입니다.

이러한 이유로 다양한 솔루션에서 인공지능(AI)과 머신러닝(ML)이 훨씬 더 많이 활용되고 있습니다. 단지 유행하는 용어이기 때문만은 아닙니다. 이제 인과관계에 대한 정확한 결론을 도출하고 적절한 대응 방안을 설계할 만큼 충분한 데이터가 확보되었기 때문에 AI와 ML이 유용한 것입니다.

OpenTelemetry는 텔레메트리 데이터에 쉽게 접근할 수 있도록 표준화함으로써 적응형 애플리케이션으로 전환하는 과정을 훨씬 수월하게 해줍니다. 다양한 유형의 제품이 유사한 메트릭을 출력하기 시작하고 OpenTelemetry에 확립된 시맨틱 규칙을 활용하면, 요청 처리 중 각 제품의 동작을 서로 연관 짓고 해당 정보를 ML 및 AI 알고리즘에 제공하여 애플리케이션과 인프라가 동적으로 적응하도록 지원하기가 더 쉬워집니다.

이 모든 것의 기반이 되는 데이터 과학을 이해하고 텔레메트리 데이터가 AI 및 ML과 연계되도록 하면, 적응형 앱의 데이터 기반 특성이 한층 발전하고 진가를 발휘할 수 있습니다.

요약

텔레메트리를 표준화하는 것은 OpenTelemetry 사용자와 이를 텔레메트리 채널로 사용하는 애플리케이션 모두에게 분명한 이점이 있습니다. 여러 소스에서 데이터를 수집하여 호환되는 모든 집계 및 분석 도구로 전달할 수 있습니다. 또한 OpenTelemetry Collector를 사용하면 공급업체가 수집기를 직접 구현할 필요가 없습니다. 대신 의미 있는 분석을 수행하고 지능적인 조치를 취할 수 있도록 코드를 개선하는 데 집중하고, 복잡하고 혼란스러운 이 새로운 세계를 이해하는 데 도움이 되는 새로운 도구를 개발할 수 있습니다. 실제로 오픈 소스의 혁신을 기반으로 하는 OpenTelemetry Collector는 거의 모든 기존 형식을 처리하는 동시에 기술을 미래로 이어갈 수 있는 탁월한 역량을 갖추고 있습니다.

OpenTelemetry는 애플리케이션을 이해하는 데 필요한 주요 데이터 유형에 중점을 둠으로써, 앱이 복잡한 현대 애플리케이션 환경의 성능과 문제에 대해 더욱 심층적인 인사이트를 제공할 수 있도록 해줍니다. OpenTelemetry는 데이터를 서로 연계하고 의미 체계 및 표준 규약에 맞춤으로써 현대적인 애플리케이션으로 전환하는 과정을 더욱 수월하게 만듭니다. 또한 프로젝트가 계속 성숙하고 도입이 확대됨에 따라, OpenTelemetry는 복잡성을 더 깊이 이해하고 AI 및 ML 기술을 적용해 이를 이해 가능한 형태로 만드는 확실한 접근 방식으로 자리 잡고 있습니다.

NGINX의 OSS 엔지니어들이 OpenTelemetry를 어떻게 활용하고 있는지 자세히 알아보려면 최신 앱 참조 아키텍처와 샘플 애플리케이션(Bank of Sirius)을 사용해 보세요.

관련 게시물

• Kubernetes로 클라우드 네이티브 여정을 시작하는 3단계