GPU 학습 클러스터, 초대규모 메트릭은 어떻게 감시할까? Adobe Firefly의 Amazon Managed Prometheus 전환기

들어가며: GPU 학습 인프라 모니터링의 어려움

생성형 AI 모델을 학습시키는 GPU 인프라는 기존 CPU 기반 애플리케이션 모니터링과는 비교할 수 없을 정도로 복잡한 텔레메트리(Telemetry)를 생성합니다. 단순히 CPU 사용률 하나만 보면 되던 때와 달리, GPU 학습 작업은 컴퓨팅(Compute), 메모리(Memory), 네트워크(Network) 레이어 간의 상호작용을 입체적으로 관찰해야만 병목 지점을 정확히 찾아낼 수 있기 때문입니다.

예를 들어, 2,000개 노드에서 16,000개의 GPU로 학습을 돌리는 상황을 가정해 봅시다. 30초 간격으로 메트릭을 수집하면 단일 쿼리 윈도우에서만 수십억 개의 데이터 포인트가 생성될 수 있습니다. 이런 환경에서 'GPU가 왜 50% 밖에 안 쓰이지?', '특정 노드의 메모리 사용량이 왜 급증했지?'라는 질문에 답하려면, 초고차원(High-Cardinality) 메트릭을 빠르게 질의할 수 있는 관측 가능성 시스템이 필수적입니다.

Adobe Firefly 팀도 비슷한 고민을 했습니다. Firefly는 Photoshop, Illustrator 등 Adobe 핵심 제품군의 창의적인 기능을 지원하는 생성형 AI 모델입니다. 이 모델을 학습시키기 위해 Adobe는 Amazon EKS 기반의 GPU 학습 인프라를 운영 중이며, 초기에는 자체 호스팅(Self-hosted) Prometheus를 사용해 왔습니다. 하지만 Firefly의 채택이 늘어나고 학습 작업 규모가 커지면서 기존 모니터링 시스템의 한계가 뚜렷해졌습니다.

이 글에서는 Adobe Firefly 팀이 자체 관리형 Prometheus에서 Amazon Managed Service for Prometheus로 전환한 과정과 이를 통해 얻은 구체적인 성과(쿼리 성능 최대 28.8배 향상)를 분석합니다. 단순한 서비스 전환 사례가 아니라, 초대규모 GPU 인프라에서 관측 가능성 아키텍처를 설계할 때 고려해야 할 핵심 요소가 무엇인지 함께 살펴보겠습니다.

문제의 본질: 자체 호스팅 Prometheus의 확장성 한계

Adobe Firefly 팀이 직면한 문제는 단순히 '메트릭이 많아서'가 아니었습니다. 문제의 본질은 GPU 학습 작업의 특성상 높은 카디널리티(High-Cardinality) 메트릭이 발생하고, 이를 기존 아키텍처로는 빠르게 질의할 수 없었다는 점입니다.

자체 호스팅 Prometheus는 수집과 저장, 질의라는 3가지 역할을 모두 수행해야 했습니다. 메트릭 볼륨이 증가하면서 질의 성능이 급격히 저하되었고, 특히 장기간(예: 12시간, 24시간) 데이터를 조회할 때 문제가 심각했습니다. 60초 내에 끝나야 할 쿼리가 타임아웃되거나, 2분이 걸려도 부분적인 결과만 반환되는 상황이 발생한 것입니다.

이 문제를 해결하기 위해 Adobe 팀은 Amazon Managed Service for Prometheus를 도입했습니다. 완전 관리형 서비스이므로 확장성과 가용성 문제를 AWS에 위임할 수 있고, 기존 자체 호스팅 Prometheus를 대체하는 것이 아니라 **점진적으로 전환(Incremental Migration)**할 수 있다는 점이 핵심 전략이었습니다.

전환 전략: 점진적 도입 (Incremental Adoption)

Adobe 팀의 전환 방식은 매우 현실적이고 실용적입니다. 전체 모니터링 시스템을 한 번에 교체하는 대신, **Amazon Managed Prometheus Collector(관리형 스크레이퍼)**를 도입하여 Amazon EKS 기반 학습 클러스터의 메트릭 수집을 담당하게 했습니다. 기존 자체 호스팅 Prometheus는 유지하면서, Amazon Managed Prometheus로 보낼 중요한 메트릭(Critical Metrics)만 선별하여 이중으로 수집하는 방식입니다.

# Amazon Managed Prometheus로 메트릭을 보내기 위한 Remote Write 설정 예시
# 이 설정은 기존 Prometheus 서버에 추가하여, 특정 메트릭만 필터링하여 전송할 수 있습니다.
remote_write:
  - url: https://aps-workspaces.us-east-1.amazonaws.com/workspaces/ws-xxxxxxxx/api/v1/remote_write
    # AWS 시그니처 인증을 위한 설정 (예: sigv4)
    sigv4:
      region: us-east-1
    # 전송할 메트릭을 선택하는 쿼리 (예: GPU 관련 메트릭만 선택)
    write_relabel_configs:
      - source_labels: [__name__]
        regex: 'DCGM_FI_DEV_GPU_UTIL|DCGM_FI_DEV_MEM_COPY_UTIL|container_gpu_usage_seconds_total'
        action: keep

이렇게 하면 기존 워크플로우를 중단하지 않으면서도, 가장 중요한 메트릭은 Amazon Managed Prometheus의 확장 가능한 인프라에서 관리하게 됩니다. 이는 **'빅뱅(Big-Bang) 전환'보다 '스트랭글러 패턴(Strangler Pattern)'**이 대규모 인프라 변경에서 얼마나 효과적인지를 잘 보여주는 사례입니다.

전환 효과: 수치로 증명된 성능 개선

Adobe Firefly 팀이 발표한 결과는 Amazon Managed Prometheus 도입 효과를 수치로 명확하게 보여줍니다. GPU 사용률 메트릭을 기준으로 조회 시간 범위(Time Range)에 따른 쿼리 성능을 비교한 결과는 다음과 같습니다.

가장 극적인 변화는 24시간 윈도우에서 나타났습니다. 이전에는 60초 타임아웃이 걸리거나 2분이 걸려도 부분 결과만 반환되던 쿼리가, 전환 후에는 약 10초 만에 완료됩니다. 이는 단순히 '빠르다'는 것을 넘어, 운영 방식 자체를 바꿔놓는 혁신입니다.

운영 관점에서의 변화

쿼리 성능 개선은 단순히 대시보드가 빨라지는 것 이상의 의미를 가집니다. Adobe 팀은 이를 통해 **학습 작업의 관측 가능성 윈도우(Observability Window)**를 이전의 6시간 한계에서 24시간으로 확장할 수 있었습니다.

이는 256개 이상의 노드를 사용하는 대규모 장기 학습 작업에서 특히 중요합니다. 이제 엔지니어는 작업의 전체 수명 주기를 한눈에 볼 수 있고, 성능이 저하된 시점을 정확히 찾아내 인프라 이벤트와의 상관관계를 분석할 수 있습니다. 예를 들어, 특정 시점에 GPU 메모리 사용량이 급증했다면, 그 시점에 다른 작업이 시작되었는지, 네트워크 지연이 발생했는지 등을 함께 추적하여 문제의 근본 원인을 빠르게 파악할 수 있습니다.

결론 및 시사점: 관측 가능성의 미래를 위한 설계 원칙

Adobe Firefly의 사례는 단순히 'AWS 서비스가 좋다'는 것을 넘어, 초대규모 GPU 인프라를 운영하는 개발자와 아키텍트에게 중요한 교훈을 제공합니다.

1. 확장성(Scalability)은 선택이 아닌 필수입니다. GPU 클러스터의 규모가 커지면 메트릭의 카디널리티와 볼륨은 통제 불능 수준으로 증가합니다. 처음부터 확장을 고려한 설계가 필요합니다.
2. 점진적 전환이 성공의 열쇠입니다. 한 번에 모든 것을 바꾸는 것은 위험합니다. Adobe의 사례처럼 중요한 메트릭부터 시작해 단계적으로 전환하는 전략이 실무에서 훨씬 효과적입니다.
3. 성능 개선은 운영 방식을 바꿉니다. 쿼리 성능이 28배 빨라지면서, 이전에는 불가능했던 24시간 전체 데이터 분석이 가능해졌습니다. 이는 장애 대응, 성능 최적화 등 운영 프로세스 전반의 혁신을 가져옵니다.

한국 개발 생태계에서의 적용 맥락

국내에서도 대규모 GPU 클러스터를 운영하는 기업이 늘어나고 있습니다. 특히, LLM(대규모 언어모델) 학습이나 헬스케어 AI, 자율주행 등 고성능 컴퓨팅이 필요한 분야에서 유사한 고민을 하고 있을 것입니다. 이번 사례는 '관측 가능성' 인프라를 설계할 때 자체 구축보다는 클라우드 관리형 서비스를 우선적으로 고려하는 것이 장기적으로 운영 부담을 줄이는 지름길이라는 점을 보여줍니다. 국내 SI 환경에서는 레거시 시스템과의 호환성 문제로 전환이 어려울 수 있지만, Adobe처럼 중요한 메트릭부터 점진적으로 적용하는 방식을 권장합니다.

이 기술의 한계 또는 주의사항

Amazon Managed Prometheus는 비용이 발생하는 유료 서비스입니다. 비용은 수집(Ingested), 저장(Stored), 질의(Queried)되는 메트릭 양에 따라 결정됩니다. 따라서 무작정 모든 메트릭을 전송하기보다는, Adobe가 했던 것처럼 핵심 메트릭(Critical Metrics)을 선별하고, 라벨(Label)을 최적화하여 카디널리티를 낮추는 노력이 선행되어야 합니다. 또한 Amazon Managed Grafana 역시 별도 비용이 발생하므로, 예산을 고려한 설계가 필요합니다. 자세한 내용은 Amazon Managed Service for Prometheus 문서와 Amazon Managed Grafana 문서를 참조하세요.

다음 단계 학습 방향 제시

이 글에서 다룬 내용을 바탕으로, 더 깊이 있는 학습을 원한다면 다음 주제를 추천합니다.

• 메트릭 카디널리티 최적화: Prometheus의 카디널리티가 왜 문제가 되는지, 이를 줄이기 위한 Relabeling 전략을 학습해 보세요.
• GPU 메트릭 수집 도구: NVIDIA DCGM(Data Center GPU Manager)을 활용한 상세 GPU 헬스 체크 방법을 익혀보세요.
• 다중 테넌트(Multi-tenant) 관측 가능성: Adobe가 다음 단계로 추진 중인 다중 테넌트 지원 아키텍처를 설계하는 방법을 고민해 보세요.

함께 보면 좋은 글

• 게임에서 AI 에이전트 추론 비용, 이렇게 줄이세요 NVIDIA IGI SDK 코드 에이전트 실전 가이드
• NVIDIA Vera CPU, 에이전틱 AI 시대의 새로운 CPU 기준을 제시하다