37signals는 인프라 전반에 걸쳐 Prometheus 메트릭스를 폭넓게 활용하며, 특히 Rails 애플리케이션 모니터링에 집중합니다. 프로덕션 환경의 다중 프로세스/컨테이너 구조에서 발생하는 메트릭스 집계의 복잡성을 해결하는 것이 주요 과제입니다. 본 글은 37signals가 Yabeda를 통해 Rails 앱 메트릭스를 내보내고, Kamal 환경에서 OpenTelemetry Collector를 활용하여 이를 통합하는 전략을 상세히 설명합니다.
Rails 앱에서 Prometheus 메트릭스를 내보내기 위해 37signals는 Ruby 젬 컬렉션인 Yabeda를 활용합니다. yabeda-prometheus, yabeda-puma-plugin, yabeda-rails 젬을 통해 메트릭스를 쉽게 내보내며, 일반적으로 9394 포트의 /metrics 경로로 서비스됩니다.
초기 yabeda-prometheus 젬은 대량의 메트릭스 처리 시 성능 문제를 보였습니다. 이를 해결하고자 37signals는 GitLab의 prometheus-client-mmap 기반의 yabeda-prometheus-mmap으로 전환했습니다. 이 과정에서 다중 프로세스 환경(예: Puma)에서 워커 재시작 시 PID 기반 메트릭스 파일 과다 생성으로 인한 성능 저하 문제가 발견되었습니다. 이 문제를 해결하기 위해 Prometheus::Client.configuration.pid_provider를 Prometheus::Client::Support::Puma.method(:worker_pid_provider)로 설정하여 PID 제공자를 구성하는 것이 필수적이었습니다.
프로덕션 환경에서는 단일 호스트에 여러 Docker 컨테이너가 실행될 수 있으므로, Prometheus가 스크랩할 단일 통합 엔드포인트가 필요합니다. 37signals는 이를 위해 Kamal 액세서리로서 OpenTelemetry Collector를 도입했습니다. OpenTelemetry Collector는 Docker 내부 네트워크에서 컨테이너별 메트릭스를 스크랩한 후, 이를 통합하여 단일 외부 엔드포인트(9394 포트)로 노출합니다. 이 방식은 호스트당 단일 스크랩 엔드포인트 제공, 포트 충돌 방지, 복잡한 Traefik 설정 회피 등 여러 이점을 제공합니다. OpenTelemetry Collector는 Docker 서비스 디스커버리를 통해 컨테이너를 찾고, 메트릭스에 컨테이너 이름을 레이블로 추가하여 노출합니다. 최종적으로 Prometheus는 이 단일 통합 엔드포인트에서 메트릭스를 스크랩하여 시스템 전반의 모니터링을 수행합니다. Kamal 및 OpenTelemetry Collector의 간결한 설정이 이러한 통합을 지원합니다.
결론적으로, 37signals의 Rails 앱 모니터링 전략은 Yabeda를 통한 메트릭스 내보내기, `yabeda-prometheus-mmap` 및 PID 제공자 설정을 통한 성능 최적화, 그리고 OpenTelemetry Collector를 활용한 다중 컨테이너 환경에서의 메트릭스 통합이라는 세 가지 핵심 요소로 이루어집니다. 이러한 통합된 접근 방식은 복잡한 프로덕션 환경에서도 Rails 애플리케이션의 성능 메트릭스를 안정적이고 효율적으로 수집, 집계 및 모니터링할 수 있는 강력한 솔루션을 제공하며, Kamal과의 시너지를 통해 배포 및 관리를 간소화합니다.