Hugging Face 생산 인프라를 지원한 세 가지 강력한 알람

Hugging Face 의 인프라 팀은 Hugging Face 의 생산 인프라 내부 작동 방식을 살펴보는 behind-the-scenes(behind-the-scenes) 내용을 공유하게 되어 기쁩니다. 우리는 이 인프라의 설계와 유지보수에 도움을 주었던 영광을 누렸습니다. 우리 팀이 견고한 모니터링 및 알람 시스템을 설계하고 구현하는 데 헌신한 것은 플랫폼의 안정성과 확장성을 보장하는 데 결정적인 역할을 했습니다. 우리는 항상 우리의 알람이 잠재적인 문제를 주요 사고가 되기 전에 식별하고 대응할 수 있는 능력에 미치는 영향에 대해 일깨워졌습니다.

이 블로그 포스트에서는 우리 생산 인프라를 지원하기 위해 고유한 역할을 수행하는 세 가지 강력한 알람의 세부 사항을 살펴보고, 커뮤니티가 의존하는 높은 수준의 성능과 가용성을 유지하는 데 어떻게 도움이 되었는지 탐구합니다.

클라우드 컴퓨팅 아키텍처에서 데이터가 사설 네트워크와 공공 네트워크 간에 흐르는 경우, NAT(Network Address Translation) 게이트웨이를 구현하는 것은 확고한 모범 사례입니다. 이 게이트웨이는 모든 외부 트래픽을 공공 인터넷으로 모니터링하고 촉진하는 전략적 문지기 역할을 합니다. NAT 게이트웨이로 에그리스 트래픽을 중앙화함으로써 우리는 포괄적인 가시성을 위한 전략적 관점을 제공합니다. 우리 팀은 이 트래픽을 쉽게 쿼리하고 분석할 수 있어, 보안, 비용 최적화 또는 기타 다양한 조사 시나리오에서 작업할 때 귀중한 자산이 됩니다.

비용 최적화는 클라우드 인프라 관리의 중요한 측면이며, 가격 동학을 이해하는 것이 핵심입니다. 데이터 센터에서는 가격 구조가 일반적으로 같은 랭크 또는 빌딩 내 통신인 동서 트래픽과 더 먼 사설 네트워크 또는 인터넷 간 통신인 남북 트래픽을 구분합니다. Hugging Face 는 네트워크 트래픽 부피를 모니터링함으로써 이러한 트래픽 패턴에 대한 귀중한 통찰력을 얻습니다. 이 인식을 통해 우리는 인프라 구성 및 아키텍처에 대해 정보에 기반한 결정을 내릴 수 있어, 불필요한 비용을 발생시키는 것을 제한합니다.

우리의 주요 알람 중 하나는 네트워크 트래픽 부피가 미리 정의된 임계치를 초과할 때 우리를 알림하도록 설계되었습니다. 이 알람은 여러 목적을 수행합니다. 첫째, 그것은 잠재적인 문제나 예상치 못한 행동을 나타낼 수 있는 트래픽의 비정상적인 급증을 알리는 조기 경보 시스템으로 작용합니다. 둘째, 우리는 인프라의 성장과 변화하는 요구 사항을 계속 관리할 수 있도록 정기적으로 트래픽 추세를 검토하도록 우리를 유도합니다. 이 알람은 우리가 시간이 지남에 따라 세밀하게 조정하여 여전히 관련성과 효과성을 유지하도록 설정된 정적 임계치로 설정됩니다. 트리거될 때, 그것은 종종 인프라를 리팩토링하는 기간과 일치합니다.

예를 들어, 제 3 의 보안 및 자동 확장 도구를 통합할 때, 우리는 노드에서 증가된 테lemetry 데이터 에그리스를 관찰하여 알람을 트리거하고 구성을 최적화하도록 우리를 유도했습니다.

한 번의 경우, 인프라 구조 조정이 제품별 인프라 (예: Space 에서 Hub 로 향하는 트래픽을 위한 레포지토리 데이터 상호작용) 간의 사설 저비용 경로를 잘못 회피하도록 유도했습니다. 더 자세히 설명하자면, 우리가 발견한 비용 절감 측면에서 가장 영향력 있는 워크로드들은 객체 스토리지에 접근하는 것들입니다. LFS 레포지토리 스토저를 위한 CDN 호스팅 자산보다 직접적으로 객체를 가져오는 것이 저렴하며, 또한 WAF 가 제공하는 것과 비교하여 공개 요청이 우리 프론트 도어에 도착할 때와 동일한 수준의 보안 조치를 필요로 하지 않습니다. CDKTF AWS 제공자를 통해 DNS 오버라이드를 활용하여 트래픽을 사설 네트워크 경로와 공개 네트워크 경로를 통해 전환하는 것은 우리에게 가치 있는 기술이 되었습니다.

new Route53ResolverFirewallRule(
stack,
`dns-override-rule-${key}-${j}`,
...
)

마지막으로, 우리는 코드 설정을 통해 원하는 상태가 항상 적용되도록 보장하지만, 코드를 통해 원하는 상태를 표현할 때 실수가 발생했을 경우를 대비하여 추가적인 알림 레이어를 가지는 것이 도움이 됩니다.

Hugging Face 의 로깅 인프라는 우리 애플리케이션과 서비스에서 생성되는 방대한 양의 로그 데이터를 수집, 처리 및 저장하기 위해 설계된 복잡한 시스템입니다. 이 시스템의 중심에는 Hub 애플리케이션 로깅 파이프라인이 있으며, 이는 잘 설계된 솔루션으로 Hub 모델 사용 데이터가 효율적으로 캡처, 풍부화 및 저장되어 보고 및 보관 목적으로 사용됩니다. 파이프라인은 각 Kubernetes 클러스터에서 애플리케이션 포드와 함께 데몬셋으로 실행되는 Filebeat 라는 경량 로그 시퍼를 시작합니다. Filebeat 의 역할은 애플리케이션 컨테이너 등 다양한 소스에서 로그를 수집하고 다음 단계의 파이프라인으로 전달하는 것입니다.

Filebeat 가 로그를 수집한 후, Logstash 라는 강력한 로그 처리 도구로 전송됩니다. Logstash 는 데이터 처리 작업마스로 작용하여 들어오는 로그에 일련의 변형 및 변환을 적용합니다. 이는 GeoIP 데이터를 추가하여 지리 위치 인사이트 제공, 미리 정의된 기준에 따라 로그를 특정 Elasticsearch 인덱스로 라우팅, 그리고 로그 필드를 추가하거나 제거하거나 재포맷하여 일관성과 분석 용이성을 보장하는 것 등을 포함합니다. Logstash 가 로그를 처리한 후,它们是转发到 Elasticsearch 클러스터로.

Elasticsearch 는 분산 검색 및 분석 엔진으로 우리 로깅 저장 및 분석 플랫폼의 핵심을 형성합니다. 그것은 Logstash 에서 로그를 받아들이고 Elasticsearch 파이프라인을 통해 자체 일련의 처리 규칙을 적용합니다. 이러한 파이프라인은 최소한의 처리 작업을 수행하며, 예를 들어 처리 시간을 나타내는 시간 필드를 추가하는 것 등이 있으며, 이는 로그 분석 및 상관관계에 필수적입니다. Elasticsearch 는 확장 가능하고 유연한 저장 솔루션을 제공하여 운영 사용 및 실시간 분석을 위해 로그를 버퍼링할 수 있게 합니다.

Elasticsearch 내에서 로그의 라이프사이클을 관리하기 위해, 우리는 강력한 저장 및 라이프사이클 관리 전략을 사용합니다. 이는 로그가 Elasticsearch 에서 정의된 기간 동안 보관되어 운영 및 문제 해결 목적으로 빠른 접근을 제공함을 보장합니다. 이 보유 기간 후, 로그는 장기 보관 저장으로 오프로드됩니다. 보관 과정은 Elasticsearch 인덱스에서 로그를 읽어서 Parquet 파일로 포맷하는 자동화된 도구를 포함하며, 이는 효율적인 열형 저장 형식이며, 그리고 이를 우리 객체 스토리지 시스템에 작성합니다.

로그 파이프라인의 최종 단계는 AWS 데이터 웨어하우스 서비스를 활용합니다. 여기서 AWS Glue 크롤러를 사용하여 객체 저장소에 있는 데이터를 발견하고 분류하며, 이를 통해 Glue 데이터 카탈로그를 자동으로 생성합니다. 이는 통합 메타데이터 저장소를 제공합니다. Glue 테이블 스키마는 주기적으로 갱신되어 로그 데이터의 변화하는 구조와 최신 상태를 유지합니다. AWS Glue와의 이 집합은 Amazon Athena라는 서버리스 인터랙티브 쿼리 서비스를 사용하여 아카이브된 로그를 쿼리할 수 있게 합니다. Athena는 객체 저장소에 있는 데이터에 대해 직접 SQL 쿼리를 실행하여 로그 분석 및 역사적 데이터 탐색을 위한 비용 효율적이고 확장 가능한 솔루션을 제공합니다.

로그 파이프라인은 정밀하게 설계되었지만, 문제점과 잠재적인 고장 지점이 없습니다. 가장 중요한 취약점은 시스템의 탄력성, 특히 Elasticsearch 클러스터에 있습니다. Elasticsearch는 분산 시스템으로, 높은 잉레스 트래픽, 집중적 쿼리, 또는 쉘드 리로케이션과 같은 내부 작업과 같은 다양한 시나리오에서 백프레셔를 경험할 수 있습니다. 백프레셔가 발생하면 파이프라인 전체에 걸쳐 문제의 연쇄가 발생할 수 있습니다. 예를 들어, Elasticsearch 클러스터가 과부하 상태가 되면 로그 인그레션이 거부되거나 지연될 수 있으며, Logstash 또는 Filebeat에 백로그를 유발하여 로그 손실이나 지연 처리를 초래할 수 있습니다.

또 다른 취약점은 Elasticsearch의 자동 스키마 감지 메커니즘입니다. 이는 로그 구조의 변화에 적응하도록 설계되었지만, 애플리케이션 로그가 중요한 필드 타입 변화를 겪을 때 실패할 수 있습니다. 스키마 감지가 새로운 필드 타입을 인식하지 못하면 Logstash에서 Elasticsearch로의 실패한 작성이 발생할 수 있으며, 로그 처리 병목 현상과 잠재적인 데이터 불일치를 초래합니다. 이 문제는 사전적 로그 스키마 관리의 중요성과 이러한 문제를 신속하게 감지하고 해결하기 위한 강력한 모니터링의 필요성을 강조합니다.

메모리 관리는 파이프라인 안정성의 중요한 측면입니다. 로그 처리 티어, 즉 Logstash 및 Filebeat는 비용을 통제하기 위해 제한된 메모리 리소스를 사용합니다. 백프레셔가 발생하면 이러한 구성 요소는 시스템 느림 기간 동안 Out-of-Memory (OOM) 문제를 경험할 수 있습니다. 로그가 축적되고 백프레셔가 증가하면 이러한 프로세스의 메모리 발자국이 커져 한계에 더 가까워집니다. 신속하게 해결하지 않으면 프로세스 충돌이나 백프레셔 문제의 추가 악화를 초래할 수 있습니다.

아카이브 작업은 Elasticsearch에서 객체 저장소로 로그를 전송하는 데 책임이 있으며, 때로는 이러한 작업은 성능에 민감한 노드 크기 및 메모리 가용성에 대한 리소스 집약적일 수 있습니다. 쓰레기 데이터 또는 비정상적으로 큰 로그 엔트리가 파이프라인을 통과할 경우, 아카이브 프로세스를 견인하여 메모리 고갈 또는 노드 용량 한계로 인한 실패를 초래할 수 있습니다. 이는 이러한 문제가 아카이브 단계에 도달하지 않도록 파이프라인의 초기에 데이터 유효성 검사 및 필터링의 중요성을 강조합니다.

이러한 잠재적 실패를 완화하기 위해 우리는 전체 로그 흐름을 검증하는 독특한 동기를 가진 강력한 알림 시스템을 구현했습니다. 이 알림은 애플리케이션 로드 밸런서 (ALB) 에 수신된 요청 수와 성공적으로 보관된 로그 수를 비교하여 파이프라인 전체에 걸친 로그 데이터 흐름의 포괄적인 관점을 제공합니다. 이 접근법은 잠재적 로그 손실 또는 처리 문제를 나타낼 수 있는 불일치를 신속하게 식별할 수 있게 합니다.

알림 메커니즘은 단순하지만 효과적인 비교에 기반합니다: ALB 를 타격하는 요청 수 (시스템에 들어가는 총 로그 볼륨을 나타냄) 와 장기 저장소에 성공적으로 보관된 로그 수. 이 비율을 모니터링함으로써, 시스템에 들어가는 것은 반드시 나가는 것을 보장하여 로그 인프라의 건강에 대한 견고한 검증을 제공합니다. 알림이 트리거될 때, 이는 잠재적 불일치를 나타내며 즉각적인 조사 및 수정을 유도합니다.

실제로, 이 알림은 특히 인프라 재설계 기간 동안 가치 있는 도구로 입증되었습니다. 예를 들어, 우리는 ALB 를 VPC 원시 (VPC origin) 로 마이그레이션했을 때, 이 알림은 결과적인 로그 흐름 불일치를 식별하고 해결하는 데 중요한 역할을 했습니다. 그러나 그것은 또한 덜 명백한 시나리오에서 우리를 구했습니다. 예를 들어, 예상치 못한 문제로 인해 보관 작업이 실행되지 않았을 때, 이 알림은 누락된 보관된 로그를 표시하여 우리가 로그 분석 및 보존 프로세스에 영향을 미치기 전에 문제를 신속하게 조사하고 해결할 수 있게 했습니다.

이 알림은 강력한 도구이지만, 이는 우리의 포괄적인 모니터링 전략의 일부일 뿐입니다. 우리는 항상 증가하는 로그 데이터의 볼륨과 복잡성을 처리하기 위해 로그 인프라를 지속적으로 개선하고 적응시킵니다. 사전 예방적 모니터링, 효율적인 자원 관리 및 시스템 동작에 대한 깊은 이해를 결합함으로써, Hugging Face 은 우리 로그 파이프라인이 탄력적이고 신뢰할 수 있으며 플랫폼의 성장 및 변화하는 요구 사항을 지원할 수 있음을 보장합니다. 이 알림은 강력한 투명성 있는 로그 시스템을 유지하기 위한 우리의 헌신의 증언이며, Hugging Face 을 원활하게 운영할 수 있도록 팀에 필요한 통찰력을 제공합니다.

클라우드 네이티브 애플리케이션과 Kubernetes 기반 인프라를 운영할 때, 심지어 미미한 문제라도 방치되면 심각한 다운타임을 초래할 수 있습니다. 이는 특히 Kubernetes API 가 컨테이너의 생성, 관리 및 네트워크를 orchestrate 하는 Kubernetes 클러스터의 중추 신경계 역할을 하기 때문에 더욱 그렇습니다. Hugging Face 은 경험을 통해 Kubernetes API 에러율과 rate limiting 지표를 모니터링하는 것이 잠재적 재앙을 예방할 수 있는 중요한 관행임을 배웠습니다.

Hugging Face 의 인프라는 Kubernetes 와 깊이 통합되어 있으며, kube-rs 라이브러리는 이 생태계를 효율적으로 구축하고 관리하는 데 중요한 역할을 했습니다. kube-rs 는 Rust 중심의 Kubernetes 애플리케이션 개발 접근법을 제공하며, 개발자에게 친숙하고 강력한 툴킷을 제공합니다. 핵심에는 kube-rs 가 있습니다.