서버리스 최적화 아티팩트 레지스트리에서 매일 수천만 개의 컨테이너 이미지 다운로드

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)

소개

이 블로그에서는 서버리스 최적화 아티팩트 레지스트리를 처음부터 구축하는 여정을 공유합니다. 주요 목표는 컨테이너 이미지 배포가 예측할 수 없고 버스티한 서버리스 트래픽 하에서 원활하게 확장되고 주요 의존성 실패와 같은 어려운 시나리오에서도 사용 가능하게 하는 것입니다.

컨테이너는 격리, 이식성 및 풍부한 툴링 생태계를 특징으로 하는 현대의 클라우드 네이티브 배포 형식입니다. Databricks 내부 서비스는 2017년부터 컨테이너로 운영되고 있습니다.  우리는 컨테이너 레지스트리로 성숙하고 기능이 풍부한 오픈 소스 프로젝트를 배포했습니다. 서비스는 일반적으로 통제된 속도로 배포되었기 때문에 잘 작동했습니다.

2021년에 이르러 Databricks가 서버리스 DBSQL 및 ModelServing 제품을 출시하기 시작했고, 매일 수백만 개의 VM이 프로비저닝될 것으로 예상되었으며, 각 VM은 컨테이너 레지스트리에서 10개 이상의 이미지를 끌어올 것으로 예상되었습니다. 다른 내부 서비스와 달리, Serverless 이미지 풀 트래픽은 고객 사용에 의해 주도되며 훨씬 더 높은 상한선에 도달할 수 있습니다.

그림 1은 1주일 동안의 생산 트래픽 부하를 보여줍니다 (예: 새로운 데이터 웨어하우스 또는 MLServing 엔드포인트를 시작하는 고객들)이 Serverless Dataplane의 피크 트래픽이 내부 서비스의 100배 이상임을 보여줍니다.

우리의 스트레스 테스트를 바탕으로, 오픈 소스 컨테이너 레지스트리는 서버리스의 요구사항을 충족시키지 못한다는 결론을 내렸습니다.

서버리스의 도전

그림 2는 오픈 소스 컨테이너 레지스트리로 서버리스 워크로드를 제공하는 주요 도전을 보여줍니다:

• Databricks의 성장을 따라가기 어렵습니다:
  • 컨테이너 이미지 메타데이터는 수직적이고 느리게 확장되는 관계형 데이터베이스에 의해 지원됩니다.
  • 피크 트래픽 시에는 수천 개의 레지스트리 인스턴스가 몇 초 안에 프로비저닝되어야 하며, 이는 종종 이미지를 끌어오는 중요한 경로에서 병목 현상이 됩니다.
• 충분히 신뢰할 수 없음:
  • 요청 서비스는 OSS 기반 아키텍처에서 복잡하며, 이로 인해 더 많은 실패 모드가 도입됩니다.
  • 관계형 데이터베이스나 클라우드 객체 저장소 같은 의존성이 다운되면 지역 전체가 중단됩니다.
• 운영 비용이 많이 듭니다: OSS 레지스트리는 성능 최적화되지 않았고 CPU 사용량이 높은 경향이 있습니다. Databricks 규모에서 운영하는 것은 비용이 많이 듭니다.

클라우드 관리 컨테이너 레지스트리는 어떨까요? 일반적으로 더 확장 가능하며 가용성 SLA를 제공합니다. 하지만, 다른 클라우드 제공 업체 서비스는 각각의 할당량, 제한, 신뢰성, 확장성 및 성능 특성이 다릅니다. Databricks는 여러 클라우드에서 운영되며, 우리는 클라우드의 이질성이 요구사항을 충족시키지 못하고 운영하는 데 비용이 많이 든다는 것을 발견했습니다.

피어 투 피어(P2P) 이미지 배포는 다른 인프라 계층에서 확장성을 향상시키는 또 다른 일반적인 접근 방식입니다. 이는 주로 레지스트리 메타데이터의 부하를 줄이지만, 앞서 언급한 신뢰성 위험에 여전히 노출되어 있습니다. 나중에 P2P 계층을 도입하여 클라우드 저장소 이그레스 처리량을 줄였습니다. Databricks에서는 전체 스택에 대한 신뢰성을 제공하기 위해 각 계층이 최적화되어야 한다고 믿습니다.

아티팩트 레지스트리 소개

우리는 서버리스 최적화 레지스트리를 구축하는 것이 필요하다는 결론을 내렸고, Databricks의 빠른 성장을 앞서가기 위해 이를 보장하기로 했습니다. 따라서 우리는 아티팩트 레지스트리 - 자체 제작 다중 클라우드 컨테이너 레지스트리 서비스를 구축했습니다. 아티팩트 레지스트리는 다음 원칙에 따라 설계되었습니다:

1. 모든 것이 수평으로 확장됩니다:
   • 관계형 데이터베이스(PostgreSQL)를 제거하고, 메타데이터는 클라우드 오브젝트 스토리지(이미지 매니페스트와 레이어 저장소에 대한 기존 의존성)에 유지되었습니다. 클라우드 오브젝트 스토리지는 훨씬 더 확장 가능하며 클라우드 간에 잘 추상화되어 있습니다.
   • 캐시 인스턴스(Redis)를 제거하고 간단한 인메모리 캐시로 대체했습니다.
2. 몇 초 안에 확장/축소: 이미지 매니페스트와 blob 요청에 대한 광범위한 캐싱을 추가하여 느린 코드 경로(레지스트리)를 줄였습니다. 결과적으로, 수백 개 대신 몇 초 안에 추가해야 하는 인스턴스가 몇 개만 필요합니다.
3. 단순함이 신뢰성입니다: 3개의 오픈 소스 마이크로서비스(nginx, 메타데이터 서비스 및 레지스트리)를 하나의 서비스, 아티팩트 레지스트리로 통합했습니다. 이로 인해 2개의 추가 네트워킹 홉이 줄어들고 성능/신뢰성이 향상됩니다.

그림 3에서 보듯이, 우리는 기본적으로 5개의 서비스로 구성된 원래 시스템을 간단한 웹 서비스로 변환했습니다: 로드 밸런서 뒤에 있는 상태가 없는 인스턴스들이 요청을 처리합니다!

그림 4와 5는 오픈 소스 레지스트리에서 아티팩트 레지스트리로 이전한 후 P99 지연 시간이 90% 이상 감소하고 CPU 사용량이 80% 감소했음을 보여줍니다. 이제 우리는 이전에 수천 개였던 것에 비해 동일한 부하에 대해 몇 개의 인스턴스만 할당하면 됩니다. 사실, 대부분의 경우 생산 피크 트래픽을 처리하려면 확장이 필요하지 않습니다. 자동 확장이 트리거되는 경우, 몇 초 안에 완료될 수 있습니다.

주요 설계 결정은 이미지 메타데이터에 대해 관계형 데이터베이스를 완전히 클라우드 객체 저장소로 교체하는 것입니다. 관계형 데이터베이스는 일관성과 풍부한 쿼리 기능에 이상적이지만, 확장성과 신뢰성에는 제한이 있습니다. 예를 들어, 모든 이미지 풀 요청은 인증/권한 부여가 필요했으며, 이는 오픈 소스 구현에서 PostgreSQL에 의해 제공되었습니다. 트래픽의 급증은 정기적으로 성능을 불안정하게 만듭니다. auth에 의해 사용되는 조회 쿼리는 더 확장 가능한 키/값 저장소의 GET 작업으로 쉽게 대체될 수 있습니다. 우리는 또한 편의성과 신뢰성 사이에서 신중한 타협을 했습니다. 예를 들어, 관계형 데이터베이스를 사용하면, 다른 차원별로 그룹화하여 이미지 수, 총 크기를 쉽게 집계할 수 있습니다. 그러나 이러한 기능을 지원하는 것은 객체 저장소에서는 비일비재합니다. 신뢰성과 확장성을 위해, 우리는 아티팩트 레지스트리가 이러한 통계를 지원하지 않기로 결정했습니다.

클라우드 오브젝트 스토리지 장애 생존

관계형 데이터베이스, 원격 캐싱, 내부 마이크로서비스의 의존성을 제거한 후 서비스 신뢰성이 크게 향상되었지만, 가끔 발생하는 실패 모드가 여전히 있습니다: 클라우드 객체 저장소의 중단. 클라우드 객체 저장소는 일반적으로 매우 신뢰할 수 있고 확장 가능하지만; 그러나 그들이 사용할 수 없을 때(때때로 몇 시간 동안), 이는 지역적인 중단을 일으킬 가능성이 있습니다. Databricks는 기본 클라우드 중단의 영향을 최소화하고 고객에게 계속 서비스를 제공하기 위해 신뢰성에 대한 높은 기준을 유지합니다.

아티팩트 레지스트리는 지역 서비스로, 각 클라우드/지역 내에 동일한 복제본이 있음을 의미합니다. 이 설정은 이미지 다운로드 지연 시간과 이그레스 비용을 절충하여 다른 지역으로 장애 조치할 수 있는 능력을 제공합니다. 지연 시간과 용량을 신중하게 관리함으로써, 우리는 클라우드 공급자의 중단에서 빠르게 회복하고 Databricks의 고객에게 계속 서비스를 제공할 수 있었습니다.

결론

이 블로그 게시물에서, 우리는 Databricks 컨테이너 레지스트리를 구축하는 여정을 공유했습니다. 이는 낮은 변동성의 내부 트래픽을 제공하는 것에서 고객을 대상으로 하는 버스티한 서버리스 워크로드를 제공하는 것입니다. 우리는 서버리스 최적화 아티팩트 레지스트리를 특별히 제작했습니다. 오픈 소스 레지스트리에 비해, 이는 90%의 P99 지연 시간 감소와 80%의 리소스 사용량을 제공했습니다. 또한, 우리는 시스템을 지역 클라우드 공급자의 중단을 견딜 수 있도록 설계하여 신뢰성을 더욱 향상시켰습니다. 오늘날, Artifact Registry는 Databricks의 빠른 Serverless 성장 속에서 안정성, 확장성, 효율성을 원활하게 만드는 견고한 기반이 계속되고 있습니다.

감사의 말

신뢰성 있고 확장 가능한 서버리스 인프라를 구축하는 것은 우리의 주요 기여자들인 로버트 랜드로드, 티안 오우양, 진 동, 시드하르스 구프타의 팀 노력입니다. 이 블로그도 팀 작업입니다 - 우리는 Xinyang Ge와 Rohit Jnagal이 제공한 통찰력 있는 리뷰어들에게 감사합니다.