Chapter 5.3 점진적으로 o11y를 적용하고 개선하기

HotROD는 Jaeger의 레퍼런스 어플리케이션입니다. 오픈 트레이싱으로 개발되었으며, 4개의 Go 마이크로서비스로 구성되었습니다.

소개하는 HotROD 아키텍처는 아래와 같습니다. 어플리케이션에 몇 가지 문제점이 있는데 추적을 사용해서, 근본 원인 분석을 어떻게 수행하는지 설명하겠습니다.

아직 부족하고 개선점이 많은 어플리케이션인데, 문제점이 무엇이고 어떻게 개선해야 되는지 설명드리겠습니다.

이 글에서는 아래처럼 일부 개선하였습니다.

1. 오픈서치를 부분적으로 연계하였습니다.
2. 오픈텔레메트리 컬렉터를 적용하였습니다.

HotROD를 그라파나와 오픈서치 관찰가능성으로 구현하고 확장하는 작업을 수행할 것입니다. 최종적으로 변경된 아키텍처는 아래와 같습니다. 최종 데모에 대한 소개는 다른 글에서 소개하도록 합니다.

다양한 기술을 사용해서 관찰가능성을 개선하고, 기능을 추가하는 데모를 제공합니다. 아래의 기능을 추가하였습니다.

1. Exemplar, 서비스 그래프, 스팬 메트릭을 추가했습니다.
2. 오픈텔레메트리를 적용했습니다.
3. 프로파일을 추가하였습니다.
4. 그라파나와 오픈서치를 지원합니다.
5. 프롬스케일을 추가하였습니다.
6. 자동 계측을 사용합니다.
7. 오브젝트 스토리지 등 대용량 트래픽을 지원하도록 개선합니다.
8. 쿠버네티스에서 운영됩니다.
9. 복잡한 상관 관계를 구현합니다.

레거시 어플리케이션이 어떻게 오픈텔레메트리와 표준 기술을 사용해서 개선되어 가는지 이해하는 좋은 데모입니다. HotROD를 정확히 이해해야 하는 이유입니다. 계속 HotROD를 보게 될 것입니다.

HotROD 특징

HotROD 어플리케이션의 특징은 아래와 같습니다.

1. HotROD는 추적, 프로메테우스 메트릭과 로그를 제공합니다. 다양한 텔레메트리를 제공함으로써, HotROD 어플리케이션의 내부적인 문제점을 이해할 수 있도록 도와줍니다.
2. HotROD는 4개 마이크로서비스에 대한 메트릭을 제공합니다. request_latency_bucket 메트릭은 요청 지연에 따른 분포도를 출력합니다. 세부적인 le 값을 조정하면서, 모니터링을 수행합니다.
3. HotROD는 Exemplar을 지원해 주지 않습니다.

3가지 테스트 시나리오를 진행합니다.

예거와 연계

1번째는 예거를 사용합니다.

receivers:
  jaeger:
    protocols:
      grpc:

exporters:
  otlp/2:
    endpoint: 127.0.0.1:21890
    tls:
      insecure: true
      insecure_skip_verify: true
  logging:
service:
  pipelines:
    traces:
      receivers: [jaeger]
      exporters: [logging, otlp/2]

아래처럼 예거를 시작합니다.

./binary/jaeger-1.38.1-linux-amd64/jaeger-agent --reporter.grpc.host-port=localhost:14250

템포와 연계

2번째는 템포를 사용합니다.

receivers:
  jaeger:
    protocols:
      grpc:

exporters:
  otlp:
    endpoint: localhost:4317
    tls:
      insecure: true
  logging:
service:
  pipelines:
    traces:
      receivers: [jaeger]
      exporters: [logging, otlp/2]

오픈텔레메트리의 구성을 약간 변경하므로, 템포와 연계가 가능합니다.

오픈서치와 연계

3번째는 오픈서치를 사용하는 경우입니다.

오픈서치를 시작합니다.

./opensearch-2.4.1/bin/opensearch

오픈서치 대시보드를 시작합니다.

./opensearch-dashboards-2.4.1-linux-x64/bin/opensearch-dashboards

데이터 프리페르를 시작합니다.

./opensearch-data-prepper-jdk-1.5.2-linux-x64/data-prepper-tar-install.sh /home/philip/opensearch-data-prepper-jdk-1.5.2-linux-x64/config/example-pipelines.yaml /home/philip/opensearch-data-prepper-jdk-1.5.2-linux-x64/config/example-data-prepper-config.yaml

오픈텔레메트리 컬렉터를 시작합니다.

./binary/otelcol-contrib --config ./binary/collector.yml

예거 에이전트를 시작합니다.

./binary/jaeger-1.38.1-linux-amd64/jaeger-agent --reporter.grpc.host-port=localhost:14250

HotROD를 시작합니다.

./example-hotrod --metrics prometheus all 2>&1 | tee hotrod.log

프로메테우스를 시작합니다.

./binary/prometheus-2.39.1.linux-amd64/prometheus --config.file=./binary/prometheus-2.39.1.linux-amd64/prometheus.yml --enable-feature=exemplar-storage --storage.tsdb.max-block-duration=1m --storage.tsdb.min-block-duration=1m

템포를 시작합니다.

./binary/tempo -config.file ./binary/config.yaml

로키를 시작합니다.

./binary/loki-linux-amd64 --config.file=./binary/loki-local-config.yaml

프롬테일을 시작합니다.

./binary/promtail-linux-amd64 -config.file ./binary/promtail-local-config.yaml

그라파나 데이터소스 설정

프로메테우스 설정

템포

로키 설정

HotROD 흐름

HotROD 어플리케이션의 흐름은 아래와 같습니다.

1. customer 서비스는 택시를 호출합니다.
2. driver 서비스는 이용 가능한 택시를 반환합니다.
3. route 서비스는 택시가 고객에게 도달하는 시간을 계산합니다.
4. frontend 서비스는 도착 시간을 출력합니다.

신호를 이해하는 방법

어플리케이션은 아래와 같은 문제점이 발생합니다.

1. customer 서비스는 잠금(Lock)이 발생합니다.
2. driver 서비스는 순차처리됩니다.
3. driver 서비스는 에러(레디스)가 자주 발생합니다.
4. route 서비스는 리소스 풀 제약이 있습니다.

위와 같은 문제점은 쉽게 드러나지 않습니다. 사용자 입장에서는 서비스에 지연이 발생하거나 최악의 경우 연결이 끊길 것입니다. 하지만 백엔드에서는 원인이 다양합니다.

추적을 사용하면, 어플리케이션의 내부적인 문제점을 쉽게 발견할 수 있습니다.

잠금, 순차처리, 리소스 풀과 같은 에러는 개발과 디버깅 과정에서 발견되지 않습니다. 왜냐하면 다수의 트랜잭션을 처리하는 도중에 발생하기 때문입니다. 그래서 개발자도 모르는 경우가 대부분입니다.

운영자는 직접 개발한 소스가 아니므로 자세한 로직은 모릅니다. 하지만 경험이 많은 운영자는 위에서 언급한 시스템 내부적인 에러를 쉽게 이해하고, 금방 해결하곤 합니다.

경험 많은 운영자는 마법사가 아닙니다. 이유는 신호를 이해하기 때문입니다. 관찰가능성 전문가가 되어야 하는 이유이며, 어떻게 마법사처럼 일하는지 살펴보도록 합시다.

아래와 같은 흐름으로 어플리케이션은 처리됩니다.

분포도를 보면, 오른쪽 상단에 분홍색이 보입니다. 문제가 있는 것을 알 수 있습니다.

mysql 처리시간이 오래 소요되는 것을 알 수 있습니다. Waiting for lock behind 4 transactions 를 볼 수 있다.

Lock으로 인해서, 다수 트랜잭션들이 대기합니다.

redis 에러가 발생하는 것을 확인할 수 있습니다.

redis는 순차적으로 처리되고 있다. 병렬로 처리하면 휠씬 빠르게 처리할 수 있습니다.

route 서비스는 한번에 3개 이상은 처리하지 않는 것을 확인할 수 있다. 리소스 풀의 제약 때문입니다.

트랜잭션이 많아지면, 전체적으로 처리 속도가 늦어지는 것을 확인할 수 있다.

route 서비스를 변경하였습니다. 리소스 풀의 제약 없이 처리되는 것을 확인할 수 있다.

소스에 대한 이해가 없이도, 추적을 통해서 시스템 내부의 문제점을 이해하고 개선작업을 수행할 수 있습니다.

아래처럼 처리 속도가 개선된 것을 확인할 수 있다.