Prometheus에서 ARMS까지: Alibaba Cloud에서 다계층 애플리케이션의 관측성을 간소화한 방법
Source: Dev.to
마이크로서비스 전반에 걸친 지연 스파이크를 디버깅하느라 잠을 잃은 적이 있다면, 관측성은 단순히 메트릭만이 아니라 컨텍스트와 관련된다는 것을 알게 될 것입니다.
몇 달 동안 우리 팀은 Alibaba Cloud에서 ACK (Alibaba Cloud Container Service for Kubernetes) 위에 Prometheus를 사용해 다계층 SaaS 애플리케이션을 운영했습니다. 잘 동작했지만, 확장 요구, 도구의 파편화, 알림 피로도가 우리를 따라잡았습니다.
우리는 최근 Application Real‑Time Monitoring Service (ARMS), Alibaba Cloud의 관리형 관측성 플랫폼으로 마이그레이션했습니다. 결과는? 40 % 더 빠른 사고 해결, 훨씬 적은 운영 오버헤드, 그리고 전체 스택에 걸친 통합 뷰였습니다.
왜 우리는 Prometheus의 한계에 부딪혔는가
- Operational drag – HA Prometheus, 스토리지, 보존 기간, 그리고 클러스터 전반에 걸친 스크레이프 설정을 관리하는 데 귀중한 엔지니어링 시간이 소모되었습니다.
- No end‑to‑end visibility – 메트릭은 Prometheus에, 로그는 별도 시스템에, 트레이스는 또 다른 시스템에 존재했습니다. 프론트엔드 지연을 느린 데이터베이스 쿼리와 연관 짓기 위해서는 수동으로 탐색해야 했습니다.
- Scaling unpredictably – 트래픽 급증 시 과다 프로비저닝(비용 낭비)하거나 메트릭 누락 위험에 직면했습니다.
- Noisy, low‑context alerts – “CPU 사용량 높음” 또는 “API 오류율 증가”와 같은 알림이 어떤 서비스 혹은 어떤 의존성이 원인인지 알려주지 않았습니다.
우리는 metrics + traces + logs를 한 곳에서 제공하고, 유지보수가 최소화된 무언가가 필요했습니다.
왜 ARMS를 선택했는가
ARMS는 단순히 “Prometheus‑as‑a‑service”가 아닙니다. 통합 관측 플랫폼으로서 다음을 지원합니다:
- 전체 Prometheus 원격 쓰기/읽기 호환성
- 클라우드 리소스 자동 탐지 (Kubernetes 워크로드, 로드 밸런서, 관리형 데이터베이스 등)
- 내장형 분산 트레이싱 (Java, Python, Go 등에 대한 자동 계측 포함)
- Alibaba Cloud 서비스와의 긴밀한 통합 — 별도의 에이전트나 복잡한 네트워킹 필요 없음
가장 중요한 점: 기존 투자 자산을 포기할 필요가 없었다는 것입니다. ARMS는 기존 Prometheus 메트릭을 그대로 수집하면서, 기반 클라우드 인프라에서 제공하는 더 깊은 컨텍스트를 추가했습니다.
우리의 마이그레이션 전략: 안전하고 점진적
We didn’t flip a switch. Observability is too critical for that. Here’s our phased approach:
- Parallel ingestion – Configured ARMS to receive metrics via Prometheus remote write—same exporters, same metrics.
- Validation period – Ran both systems side‑by‑side for two weeks, comparing dashboards, alert fidelity, and data completeness.
- Gradual cutover – Shifted Grafana dashboards to use ARMS as a data source, then migrated alert rules.
- Decommission – Once confident, we scaled down our self‑managed Prometheus stack and reclaimed resources.
Zero downtime. Minimal risk.
💡 Pro tip: Start with ARMS’ Prometheus Monitoring mode—it’s the gentlest on‑ramp if you’re already using Prometheus.
모든 계층에 걸친 가시성—드디어
우리의 스택은 다음을 포함합니다:
- 프론트엔드 (CDN + OSS에 저장된 정적 자산)
- API 게이트웨이 (Application Load Balancer를 통해)
- 무상태 마이크로서비스 (ACK 상)
- 캐시 레이어 (관리형 Redis)
- 영구 스토리지 (관리형 PostgreSQL)
ARMS 도입 이전에 “결제 과정이 왜 느린가?” 라는 질문에 답하려면 세 개 이상의 도구를 오가야 했습니다.
이제 단일 ARMS 대시보드에서 다음을 확인할 수 있습니다:
- 프론트엔드 성능 (실제 사용자 메트릭)
- API 지연 시간 및 오류 비율
- 실시간 트레이스가 포함된 서비스 의존성 맵
- 느린 데이터베이스 쿼리가 호출 서비스와 자동으로 연결됨
이제는 “데이터 수집”이 아니라 행동을 이해하는 것이 중요합니다.
중요한 결과
- 평균 해결 시간(MTTR) 40 % 감소
- 관측성 인프라 관리에 소요되는 시간 60 % 감소
- 신호가 강한 알림은 적지만 더 중요함 (서비스‑수준 컨텍스트 포함)
- 더 빠른 온보딩 — 새 엔지니어가 트라이벌 지식이 아닌 ARMS를 통해 시스템을 탐색
비슷한 이전을 고려하고 있다면
- 구성 재작성 없이 ARMS의 Prometheus‑compatible endpoint를 사용하세요.
- 자동 계측을 위해 Application Monitoring을 활성화하세요—JVM 인수 몇 개나 SDK 호출을 추가하면 됩니다.
- 보안 및 자격 증명 없이 접근하기 위해 RAM roles(Alibaba Cloud의 IAM)를 설정하세요.
- 여전히 사용자 정의 메트릭을 푸시하시나요? ARMS는 OpenTelemetry와 Prometheus 클라이언트 라이브러리를 지원합니다.
최종 생각
이는 단순히 도구 교체가 아니라 reactive monitoring에서 proactive understanding으로의 전환이었습니다. managed, cloud‑native observability platform에 의존함으로써 주말을 되찾고 SLOs를 안정적으로 관리할 수 있게 되었습니다.
Kubernetes에서 Prometheus를 운영하면서 규모 확장의 어려움을 겪고 있다면, 클라우드 제공업체와 관계없이 unified observability platform이 팀에 어떤 도움이 될 수 있는지 탐색해볼 때일지도 모릅니다.