Elastic의 OpenTelemetry를 통한 독립성

By

Bahubali Shetti

illustration-scalability-gear-1680x980_(1).jpg

더 빠르고 확장성이 뛰어난 서비스에 대한 수요가 증가하고 있습니다. 우리의 일상 생활은 앱에 의존합니다. 좋아하는 음식을 배달해 주는 음식 배달 앱에서부터 계좌를 관리하는 뱅킹 앱, 심지어 의사 진료를  예약하는 앱까지 말입니다. 이러한 앱은 기능 측면뿐만 아니라 사용자 용량 측면에서도 성장할 수 있어야 합니다. 글로벌 범위의 확장과 필요성으로 인해 이러한 수요가 많은 클라우드 애플리케이션의 복잡성이 증가하고 있습니다.

수요에 발맞추기 위해, 이러한 온라인 애플리케이션 및 서비스(예: 모바일 애플리케이션, 웹 페이지, SaaS)의 대부분이 분산형 마이크로서비스 기반 아키텍처 및 Kubernetes로 이동하고 있습니다. 애플리케이션을 클라우드로 마이그레이션한 후에, 서비스의 운영, 확장 및 가용성을 어떻게 관리하고 모니터링하시나요? OpenTelemetry는 Kubernetes 애플리케이션을 위한 애플리케이션 원격 측정 데이터를 계측하고 수집하기 위한 사실상의 표준으로 빠르게 자리잡고 있습니다.

OpenTelemetry(OTel)는 소프트웨어 성능 및 동작을 이해하기 위해 원격 측정 데이터(메트릭, 로그 및 추적)를 생성, 수집하여 내보내는 데 사용할 수 있는 도구, API 및 SDK 모음을 제공하는 오픈 소스 프로젝트입니다. OpenTelemetry는 최근 CNCF 인큐베이팅 프로젝트가 되었으며, 커뮤니티 및 공급업체의 지원이 크게 증가하고 있습니다.

OTel은 애플리케이션에 표준 원격 측정 형식을 제공하는 표준 방법을 제공하지만 백엔드 또는 분석 구성 요소는 제공하지 않습니다. 따라서 애플리케이션, 인프라 및 사용자 경험 모니터링에서 OTel 라이브러리를 사용하면 적절한 Observability 도구를 선택할 수 있는 유연성을 제공합니다. 애플리케이션 성능 모니터링(APM)에 대한 벤더 종속은 더 이상 없습니다.

Elastic Observability는 추적, 메트릭 및 로그를 수집하기  위해 OpenTelemetry 및 해당 OpenTelemetry 프로토콜(OTLP)을 기본적으로 지원합니다. Elastic Observability의 모든 APM 기능은 OTel 데이터에서 사용할 수 있습니다. 따라서 OTel 데이터에 대해 다음과 같은 기능(및 기타 기능)을 사용할 수 있습니다.

  • 서비스 지도
  • 서비스 세부 정보(대기 시간, 처리량, 실패한 트랜잭션)
  • 서비스 간 종속성
  • 트랜잭션(추적)
  • 머신 러닝 상관 관계(특히 대기 시간에 대한)
  • 서비스 로그

이제 Elastic의 APM 및 원격 측정 데이터의 통합 보기 외에도, Elastic의 강력한 머신 러닝 기능을 사용해 분석을 줄이고 경보를 사용해 MTTR을 줄일 수 있습니다.

오픈 소스의 전통에 기반한 Elastic은 Prometheus, Fluentd, Fluent Bit, Istio, Kubernetes(K8S) 등과 같은 다른 CNCF 기반 프로젝트도 지원합니다.  

이 블로그에서는 다음과 같은 내용을 보실 수 있습니다.

  • 몇 가지 간단한 단계를 통해 Elastic Cloud로 수집하도록 구성된 인기 있는 OTel 계측 데모 앱(HipsterShop)을 얻는 방법
  • OTel 데이터와 관련된 일부 Elastic APM 기능 및 일단 데이터를 Elastic으로 가져온 후 이 데이터로 할 수 있는 작업 소개

다음 블로그에서는, Elastic의 머신 러닝을 OTel 원격 측정 데이터와 함께 사용하는 방법, 특정 언어에 대한 OTel 애플리케이션 메트릭을 계측하는 방법, OTel Collector를 통해 Prometheus 수집을 지원할 수 있는 방법 등에 대해 자세히 설명합니다. 주목해서 봐주세요!

필수 구성 요소 및 구성

이 블로그를 팔로우할 계획이신 경우를 위해, 구성을 설정하는 데 사용한 몇 가지 구성 요소와 세부 정보를 소개해 드립니다.

  • Elastic Cloud 계정과 배포된 스택이 있는지 확인합니다(여기 지침 참조).
  • 우리는 매우 인기 있는 HipsterShop 데모 애플리케이션의 변형을 사용했습니다. 이것은 원래 OpenTelemetry 데모 앱과 같이 사용 가능한 다양한 변형에서 Kubernetes를 선보이기 위해 Google이 작성한 것입니다. 앱을 사용하려면, 여기로 이동하여 지침에 따라 배포하세요.
  • 또한 우리는 애플리케이션의 OTel 수동 계측 버전을 사용하고 있습니다. 이 블로그 구성에는 OTel 자동 계측이 사용되지 않았습니다.
  • 클러스터의 위치. Google Kubernetes Engine(GKE)을 사용하는 동안, 원하는 Kubernetes 플랫폼을 사용하실 수 있습니다. 
  • Elastic은 OTel 계측 서비스에서 직접 원격 측정을 수집할 수 있지만, 우리는 OpenTelemetry Collector를 사용하는 보다 전통적인 배포에 초점을 맞출 것입니다.
  • 기존에 모든 Kubernetes 데이터를 가져오는 데 사용되었던 Prometheus 및 FluentD/Fluent Bit는 Kubernetes 에이전트와 비교하여 여기에서 사용되지 않습니다. 다음 블로그에서 이를 소개합니다.

다음은 이 블로그에서 설정할 구성입니다.

이 블로그에서 사용되는 OpenTelemetry 데이터를 수집하기 위한 구성

모든 설정

다음 몇 단계에 걸쳐, 다음에 대해 상세하게 설명해 드리겠습니다.

  • Elastic Cloud의 계정 만들기
  • GKE 클러스터 불러오기
  • 애플리케이션 불러오기
  • Elastic Cloud를 가리키도록 Kubernetes OTel Collector 구성 맵 구성
  • 가시성 향상을 위해 OTel 데이터와 함께 Elastic Observability APM 사용

0단계: Elastic Cloud의 계정 생성하기

Elastic Cloud 시작하기 지침에 따르세요.

1단계: K8S 클러스터 불러오기

우리는 Google Kubernetes Engine(GKE)을 사용했지만, 여러분은 원하는 Kubernetes 플랫폼을 사용하실 수 있습니다.

Elastic이 Kubernetes 클러스터에서 OpenTelemetry 데이터를 수집하기 위한 특별한 요건은 없습니다. GKE, EKS, AKS 또는 Kubernetes 호환 클러스터(자체 배포형 및 관리형)의 일반 Kubernetes 클러스터는 모두 작동합니다.

2단계: 클러스터에서 HipsterShop 애플리케이션 로드하기

선택한 클라우드 서비스 또는 로컬 Kubernetes 플랫폼의 Kubernetes 클러스터에서 애플리케이션을 가져옵니다. 제가 사용하고 있는 애플리케이션은 여기에서 제공됩니다.

일단 애플리케이션이 Kubernetes에서 실행되면, default 네임스페이스에서 다음 포드(또는 일부 변형)가 실행됩니다.

kubectl get pods -n default

출력은 다음과 유사해야 합니다.

NAME                                     READY   STATUS    RESTARTS   AGE
adservice-f9bf94d56-5kt89                1/1     Running   0          41h
cartservice-54d5955c59-7lrk9             1/1     Running   0          41h
checkoutservice-57b95c78bb-qqcqv         1/1     Running   0          41h
currencyservice-6869479db8-7tsnj         1/1     Running   0          43h
emailservice-7c95b8766b-mp5vn            1/1     Running   0          41h
frontend-5f54bcb7cf-kxwmf                1/1     Running   0          41h
loadgenerator-bfb5944b6-2qhnw            1/1     Running   0          43h
paymentservice-5bc8f549c8-hkxks          1/1     Running   0          40h
productcatalogservice-665f6879d6-kv29f   1/1     Running   0          43h
recommendationservice-89bf4bfc5-ztcrr    1/1     Running   0          41h
redis-cart-5b569cd47-6wt59               1/1     Running   0          43h
shippingservice-768b94fb8d-8hf9c         1/1     Running   0          41h

이 버전에서는 모든 services와 loadgenerator만 제공합니다. 여러분도 알아차리셨겠지만, OpenTelemetry Collector는 아직 불러오지 않았습니다. (다음 단계를 참조하세요.)
개별 서비스 yaml을 보면 port 4317의 OpenTelemetry Collector를 가리키고 있습니다.

        - name: OTEL_EXPORTER_OTLP_ENDPOINT
          value: "http://otelcollector:4317"

Port 4317은 서비스에서 원격 측정을 수신하는 기본 포트입니다.  따라서 모든 서비스는 OTel Collector를 가리켜야 합니다.

3단계: Elastic을 가리키는 OpenTelemetry Collector 불러오기

otelcollector.yaml 파일의 /deploy-with-collector-k8s에서 configmap 섹션에서 설정해야 하는 두 가지 특정 변수가 있습니다.

    exporters:
      otlphttp/elastic:
        endpoint: OTEL_EXPORTER_OTLP_ENDPOINT
        headers:
          Authorization: OTEL_EXPORTER_OTLP_HEADERS

OTEL_EXPORTER_OTLP_ENDPOINT는 Elastic의 APM Server입니다.

OTEL_EXPORTER_OTLP_ENDPOINT는 여러분의 승인을 제공합니다.

변수에 대한 자세한 내용은 OTel Collector 구성에 대한 Elastic의 설명서를 참조하세요.

이러한 값은 어디에서 얻을 수 있을까요? 

APM, +add data 아래 Elastic's Observability의 UI에서 다음과 같은 화면이 나타납니다. 

다음과 같이 OpenTelemetry 아래로 이동합니다.

변수 OTEL_EXPORTER_OTLP_ENDPOINT (여러분의 Elastic APM Server 엔드포인트)의 값과 OTEL_EXPORTER_OTLP_HEADERS의 승인이 표시되는 것을 볼 수 있습니다.

Elastic의 APM Server 엔드포인트를 사용하여 OTel Collector를 구성할 때, gRPC 와 http, 이렇게 두 가지 옵션이 있습니다.

여기에 있는 otelcollector.yaml에서 exporters는 http로 구성됩니다. 

gRPC 포트를 사용하여 APM 서버로 전송하려면, 내보내기를 다음과 같이 수정해야 합니다.

    exporters:
      otlp/elastic:
        endpoint: OTEL_EXPORTER_OTLP_ENDPOINT
        headers:
          Authorization: OTEL_EXPORTER_OTLP_HEADERS

otlphttp에서 otlp.로 변경되었다는 점에 유의하세요. 위에서 설명한 대로 필요한 내용을 변경하면, 다음과 같이 otelcollector를 생성합니다.

kubectl create -f otelcollector.yaml

정상적으로 실행되고 있는지 확인합니다.

mycomputer% kubectl get pods | grep otelcollector
otelcollector-5b87f4f484-4wbwn          1/1     Running   0            18d

4단계: Kibana를 열고 APM 서비스 지도를 사용하여 OTel 계측 서비스 보기

APM 아래의 Elastic Observability UI에서 servicemap을 선택하여 서비스를 확인합니다.

이렇게 표시되면, OpenTelemetry Collector가 Elastic으로 데이터를 전송하고 있습니다.

축하합니다. OpenTelemetry를 사용하여 추적을 위한 HipsterShop 데모 애플리케이션을 계측하고 원격 측정 데이터를 Elastic으로 성공적으로 수집하셨습니다!

특정 환경을 구성하는 방법

Elastic APM을 사용하면 Environment를 기준으로 필터링할 수 있는 기능으로 여러 애플리케이션을 수집하실 수 있습니다. 따라서 UI를 사용하는 dev team 1과 dev team 2가 모두 있는 경우, environment 변수를 올바르게 설정해야 합니다. 

이 애플리케이션에 대한 환경 변수 설정은 service yaml의 deployment.environment 변수를 통해 이루어집니다.

만약 이를 변경하고 싶다면, 당신은 이 블로그의 애플리케이션에 대한 git의 각 서비스 yaml에서 OTEL_RESOURCE_ATTRIBUTES를 변경해야 할 것입니다.

다음에서:

       - name: OTEL_RESOURCE_ATTRIBUTES
          Value: "service.name=recommendationservice,service.version=1.0.0,deployment.environment=MY-DEMO"

다음으로 변경:

       - name: OTEL_RESOURCE_ATTRIBUTES
          Value: "service.name=recommendationservice,service.version=1.0.0,deployment.environment=XXX"

모든 서비스에서 이 작업을 수행하려면, 다음을 실행합니다.

sed -i `s/MY-DEMO/XXX/g` *.yaml

5단계: Elastic은 무엇을 보여줄 수 있는가?

이제 OpenTelemetry 데이터가 Elastic으로 수집되었으니, 무엇을 할 수 있을까요?

먼저, APM 서비스 지도를 볼 수 있습니다(이전 단계 참조). 그러면 모든 서비스와 서비스 간 트랜잭션 흐름을 전체적으로 볼 수 있습니다.

다음으로, 개별 서비스와 수집 중인 트랜잭션을 확인할 수 있습니다.

보시는 것처럼, 프런트 엔드 세부 정보가 나열되어 있습니다. 다음 정보를 모두 보실 수 있습니다. 

  • 평균 서비스 대기 시간
  • 처리량
  • 트랜잭션
  • 실패한 트랜잭션 비율
  • 오류
  • 종속성

이제 추적을 시작하겠습니다. 다음과 같이 트랜잭션 탭에서 프런트 엔드 서비스와 관련된 모든 트랜잭션 유형을 검토할 수 있습니다.

/cart/checkout 트랜잭션을 선택하면 모든 범위에 대한 전체 추적을 볼 수 있습니다.

이 트랜잭션, 처리량, 실패 및 (당연히) 추적에 대한 평균 대기 시간!

추적을 검토할 수 있을 뿐만 아니라 /kr/chart/checkout에 대해 일반 대기 시간보다 긴 관련 항목을 분석할 수도 있습니다.

Elastic은 머신 러닝을 사용하여 추적을 통해 서비스 전반에 걸쳐 잠재적인 대기 시간 문제를 식별합니다. Latency Correlations 탭을 선택하고 상관 관계를 실행하기만 하면 됩니다.

이는 클라이언트 10.8.0.16가 이 트랜잭션에 대해 잠재적으로 비정상적인 대기 시간이 있음을 보여줍니다.

그런 다음, 추적 보기에서 직접 로그를 드릴다운하고 추적과 관련된 로그를 검토하여 잠재적인 문제를 파악하고 정확히 짚어낼 수 있습니다.

Elastic 머신 러닝(ML)으로 데이터 분석

OpenTelemetry 메트릭을 Elastic으로 가져오면, Elastic의 머신 러닝 기능을 통해 데이터 분석을 시작합니다.

이러한 기능에 대한 훌륭한 리뷰를 APM 원격 측정을 상호 연결하여 트랜잭션의 근본 원인 확인에서 확인하실 수 있습니다.

그리고 Elastic의 블로그에 더 많은 동영상과 블로그가 있습니다.

OpenTelemetry 데이터에 대해 Elastic의 머신 러닝 기능을 활용하는 방법에 대한 추가 블로그도 계속해서 소개해 드리겠습니다.

결론

Elastic Observability가 Elastic의 APM 기능을 통해 OpenTelemetry 데이터를 수집하고 분석하는 데 어떻게 도움이 되는지 잘 알게 되셨기를 바랍니다.

간략한 학습 요약과 보다 구체적으로 학습한 내용은 다음과 같습니다.

  • 몇 가지 간단한 단계를 통해 Elastic Cloud로 수집하도록 구성된 인기 있는 OTel 계측 데모 앱(HipsterShop)을 얻는 방법
  • OTel 데이터와 관련된 일부 Elastic APM 기능 및 일단 데이터를 Elastic으로 가져온 후 이 데이터로 할 수 있는 작업 소개

시작할 준비가 되셨나요? Elastic Cloud에 가입하고 위에서 간략히 설명한 기능을 사용하여 OpenTelemetry 데이터의 가치와 가시성을 최대한 활용하세요.

Elastic Cloud 무료 체험판 등록하기

선택하신 클라우드 서비스 제공자에서 완전히 로드된 배포를 이용하세요. Elasticsearch 개발사로서 클라우드에 있는 사용자의 Elastic 클러스터에 기능과 지원을 제공해드립니다.

무료 체험판 사용 시작