Hugging Face 프로덕션 인프라 알림 전략
Hugging Face는 프로덕션 인프라의 안정성과 확장성을 보장하기 위해 강력한 모니터링 및 알림 시스템을 운영합니다. 네트워크 트래픽, 로그 파이프라인, 오케스트레이션 API 상태에 대한 목표 알림을 구현함으로써 팀은 잠재적인 문제를 주요 사고로 확대되기 전에 식별합니다.
높은 NAT 게이트웨이 처리량 및 비용 최적화
Hugging Face는 NAT (Network Address Translation) 게이트웨이를 사용하여 사설 네트워크에서 퍼블릭 인터넷으로 나가는 트래픽을 중앙 집중화하고, 보안 및 비용 분석을 위한 전략적 관점을 제공합니다. 클라우드 비용을 관리하기 위해 팀은 처리량이 사전 정의된 한도를 초과할 때 트리거되는 정적 임계값 알림을 사용해 네트워크 트래픽 양을 모니터링합니다.
이 알림 메커니즘은 두 가지 주요 기능을 수행합니다:
- Early Warning System: 비정상적인 트래픽 급증을 감지하여 예상치 못한 시스템 동작을 나타낼 수 있습니다.
- Infrastructure Review: 인프라 성장과 변화하는 요구에 맞추기 위해 트래픽 추세에 대한 정기적인 검토를 촉구합니다.
실제로 이 알림은 서드파티 보안 및 자동 스케일링 도구가 텔레메트리 데이터 전송을 증가시켰을 때 팀이 구성을 최적화하는 데 도움이 되었습니다. 또한 트래픽이 실수로 저비용 사설 경로를 회피하는 경우를 식별합니다. 예를 들어, LFS 저장소에서 객체를 직접 가져오는 것이 CDN에 호스팅된 자산을 사용하는 것보다 비용 효율적입니다. 이러한 문제를 해결하기 위해 Hugging Face는 CDKTF AWS provider를 통한 DNS 오버라이드를 활용해 트래픽을 사설 네트워크 경로로 라우팅합니다.
엔드투엔드 로그 보관 검증
Hugging Face는 Hub 모델 사용 데이터를 캡처하기 위해 정교한 로깅 파이프라인을 활용합니다. 파이프라인은 Filebeat(로그 수집) → Logstash(변환 및 보강) → Elasticsearch(저장 및 분석) → 최종적으로 AWS object storage(Parquet 형식의 장기 보관) 로 흐르며, Amazon Athena를 통해 쿼리할 수 있습니다.
설계에도 불구하고 파이프라인은 다음과 같은 실패에 취약합니다:
- Elasticsearch Backpressure: 높은 인입량이나 집중적인 쿼리로 인해 로그가 거부되거나 지연될 수 있습니다.
- Schema Mismatches: 애플리케이션 로그 필드 유형의 큰 변화가 자동 스키마 감지를 실패하게 하여 쓰기 오류를 초래할 수 있습니다.
- Memory Exhaustion: Logstash와 Filebeat의 메모리 자원이 제한되어 있어 백프레셔 상황에서 Out-of-Memory (OOM) 충돌이 발생할 수 있습니다.
- Archival Failures: 리소스를 많이 사용하는 보관 작업이 노드 용량 제한이나 비정상적으로 큰 로그 항목 때문에 실패할 수 있습니다.
이러한 위험을 완화하기 위해 Hugging Face는 Application Load Balancer (ALB)가 받은 요청 수와 성공적으로 보관된 로그 수를 비교함으로써 엔드투엔드 로그 흐름을 검증하는 알림을 구현했습니다. 이 비율은 시스템에 들어오는 데이터 양이 보관된 양과 일치함을 보장하여 인프라 재구성 중이나 보관 작업 실패 시 로그 손실을 감지할 수 있게 합니다.
Kubernetes API 상태 및 속도 제한
Kubernetes API가 컨테이너 관리의 중앙 오케스트레이션 포인트 역할을 하기 때문에, Hugging Face는 연쇄적인 실패를 방지하기 위해 API 오류율 및 속도 제한 메트릭을 모니터링합니다. 인프라스트럭처는 kube-rs 라이브러리에 크게 의존하며, 이 라이브러리는 리플렉터, 컨트롤러, 워처, 파이널라이저에 대한 Rust 기반 추상화를 제공합니다.
Hugging Face에서 kube-rs의 주요 활용 사례는 다음과 같습니다:
- Automated Certificate Management:
kube::api::모듈을 사용해 Spaces 제품의 커스텀 도메인에 대한 HTTPS 인증서를 관리합니다. - Custom Controllers:
kube::runtime::모듈을 사용해 청구 관리용 컨트롤러를 구축하며, 워처와 파이널라이저가 고객 파드의 정확한 리소스 청구를 추적합니다. - Maintenance Operations: 인프라 업데이트 중 노드 드레인 및 종료를 지원합니다.
Kubernetes API 모니터링은 중단이 고객 파드 및 클라우드 네트워킹 리소스 관리에 영향을 미칠 수 있기 때문에 중요합니다. 예를 들어, 팀은 이러한 알림을 사용해 서드파티 도구 버그를 식별했으며, 이 버그는 노드 드레인을 반복적으로 요청해 API 속도 제한을 초래했고, 문제 발생 전에 사용자 경험이 저하되는 것을 방지했습니다.
무음 클러스터 메트릭 실패 감지
클러스터가 자주 생성·삭제되는 동적 환경을 관리하기 위해, Hugging Face는 중앙 Grafana Mimir 스토어에 메트릭을 전송하지 않는 클러스터를 감지하기 위한 특정 Prometheus 쿼리를 사용합니다.
이 알림은 로컬 Prometheus 인스턴스의 container_network_transmit_packets_total 메트릭을 모니터링합니다. 쿼리는 다음 상황에서 트리거됩니다:
- 새로운 클러스터가 추가되었지만 아직 메트릭을 전송하지 않은 경우.
- 클러스터가 48시간 이상 존재했지만 한 번도 메트릭을 전송하지 않은 경우.
이는 현재 패킷 전송 속도를 48시간 전의 과거 속도와 비교함으로써 구현됩니다. 현재와 과거 속도가 모두 0이면 알림이 발생하여 메트릭 인프라의 충돌이나 클러스터 설정 중 실패를 팀에 알립니다.