서버리스 성능 및 안정성을 위한 분산 시스템 재고

Apache Spark를 위한 진정한 서버리스 컴퓨팅을 구축하는 것은 Spark가 처음 등장한 이래로 존재해 온 근본적인 아키텍처 문제를 해결해야 했습니다. 그 복잡성은 단순히 머신 웜 풀을 생성하거나 기본적인 자동 확장을 구현하는 것을 훨씬 뛰어넘습니다. 분산 컴퓨팅 시스템이 어떻게 작동해야 하는지에 대한 핵심 가정을 재고해야 했습니다.

기존 Spark 배포는 인프라를 사용자에게 직접 노출하여 애플리케이션과 컴퓨팅 간의 긴밀한 결합을 만듭니다. 워크로드는 공유 리소스를 놓고 경쟁하며, 작은 비효율성이 연쇄적인 장애로 이어질 수 있고, 사용자는 성능, 비용, 안정성을 수동으로 균형 있게 조정해야 합니다. 수요가 변함에 따라 시스템은 높은 활용도와 예측 가능한 성능을 모두 유지하는 데 어려움을 겪습니다.

서버리스 컴퓨팅은 인프라를 완전히 관리하여 사용자가 데이터와 인사이트에 집중할 수 있도록 하는 다른 접근 방식을 취합니다. 안정성은 사용자 책임이 아닌 시스템 속성이 되며, 이는 워크로드를 격리하고, 지능적으로 배치하며, 리소스를 동적으로 조정하는 아키텍처를 통해 가능해집니다.

서버리스 컴퓨팅은 안정성, 성능 및 운영 단순성을 개선하도록 설계되었습니다. 세 가지 핵심 시스템이 이를 가능하게 합니다.

1. Spark Connect: 사용자 애플리케이션을 컴퓨팅 인프라에서 분리
2. Serverless Gateway: 컴퓨팅 리소스 전반에 걸쳐 워크로드를 지능적으로 라우팅
3. 적응형 자동 확장기: 성능 및 비용을 위해 클러스터 크기를 지속적으로 최적화

이러한 시스템들은 함께 시스템 전반의 안정성을 먼저 확보함으로써 성능을 달성하는 모델을 가능하게 합니다.

Spark Connect: 격리를 통한 안정성

Spark Connect는 Spark 역사상 가장 중요한 아키텍처 변화를 나타내며, 10년 이상 분산 컴퓨팅을 정의해 온 모놀리식 설계에서 완전히 벗어났습니다. 기존 아키텍처에서는 사용자 애플리케이션이 Spark 드라이버와 동일한 머신에서 직접 실행되어 중요한 제한 사항을 초래하는 긴밀한 결합을 만듭니다. 여러 애플리케이션이 동일한 클러스터에서 리소스를 놓고 경쟁하거나 사용자 코드가 과도한 메모리 또는 CPU를 소비할 때 시스템은 불안정해지고, 이는 워크로드 전반에 걸쳐 연쇄적인 장애로 이어질 수 있습니다.

Spark Connect는 애플리케이션이 gRPC를 통해 Spark 드라이버와 통신하고, 드라이버가 사용자 프로세스를 직접 실행하는 대신 클라이언트를 대신하여 쿼리를 실행하는 클라이언트-서버 아키텍처를 도입합니다. 이는 실행 단위를 애플리케이션 프로세스에서 쿼리로 전환하고 사용자 애플리케이션과 인프라 간의 명확한 분리를 가능하게 합니다.

이러한 분리는 안정성을 크게 향상시키고 플랫폼이 사용자 워크로드와 독립적으로 드라이버를 관리할 수 있도록 합니다. 컴퓨팅에서 애플리케이션을 격리함으로써 Spark Connect는 안정적인 다중 테넌트 실행에 필요한 기반을 마련하고 시스템 전반에 걸쳐 더욱 고급 리소스 관리를 가능하게 합니다.

이 아키텍처를 통해 Databricks는 사용자 개입 없이 연간 25회 이상의 주요 Spark 런타임 업그레이드를 45억 개 이상의 워크로드에 걸쳐 99.998%의 성공률로 제공할 수 있습니다.¹

게이트웨이: 효율성과 예측 가능성의 균형

분산 시스템은 오랫동안 효율성과 예측 가능성 사이의 근본적인 긴장에 직면해 왔습니다. 활용도를 극대화하면 종종 리소스 경합으로 이어지고, 워크로드를 격리하면 용량 부족으로 이어질 수 있습니다. 기존 클러스터 모델은 사용자가 이러한 절충점을 수동으로 조정하도록 강요하며, 이는 워크로드 변경 시 예측 불가능한 성능이나 신뢰할 수 없는 실행으로 이어지는 경우가 많습니다.

수십 개의 쿼리가 동시에 실행될 때 어떤 일이 발생하는지 생각해 보십시오. 일부는 샘플 데이터에 대해 실행되는 작은 탐색적 스캔이고, 다른 일부는 수백 기가바이트를 처리하는 대규모 프로덕션 ETL 작업입니다. 단순한 라우터는 이들을 동일하게 처리하여 대규모 작업이 작은 작업 뒤에서 대기하게 하거나 워크로드가 동일한 클러스터를 놓고 경쟁하게 하여 예측 불가능한 성능 저하를 초래합니다. 이러한 역학으로 인해 공유 환경에서 높은 활용도와 일관된 성능을 모두 제공하기가 어렵습니다.

Databricks 게이트웨이는 세 가지 실시간 신호(예상 쿼리 크기(논리적 계획에서 파생), 클러스터 풀 전체의 현재 활용도, 지연 시간 프로필(세션이 대화형이고 지연 시간에 민감한지 또는 처리량에 최적화된 배치 작업인지))를 평가하여 각 워크로드를 라우팅합니다. 작은 탐색적 쿼리는 몇 초 안에 응답할 수 있는 가볍게 로드된 클러스터로 라우팅됩니다. 대규모 ETL 작업은 데이터 볼륨에 사용할 수 있는 여유 공간이 있는 클러스터로 보내지거나, 자동 확장기에 프로비저닝 신호가 전달됩니다. 조건이 변경되면(클러스터가 가득 차거나, 장기 실행 작업이 완료되거나, 새 클러스터가 온라인 상태가 되면) 게이트웨이는 사용자 개입 없이 배치를 지속적으로 재평가하고 라우팅을 수정합니다. 그 결과: 워크로드는 서로 격리됩니다. 한 클러스터의 폭주 쿼리가 다른 클러스터의 쿼리를 지연시키지 않으며, 시스템은 예측 가능성을 희생하지 않고 높은 활용도를 유지합니다.

자동 확장: 비용-성능 곡선 최적화

동적 클러스터 크기 조정은 분산 시스템에서 가격 대비 성능을 최적화하는 주요 메커니즘이지만, 최적의 컴퓨팅 양을 결정하는 것은 본질적으로 복잡합니다. 최적의 구성은 워크로드 특성, 데이터 크기, 지연 시간과 비용의 상대적 중요도에 따라 달라지며, 모든 시나리오에 적용되는 단일 구성은 없습니다. Databricks 서버리스는 다양한 요구 사항에 맞춰 두 가지 모드를 제공합니다. Standard는 비용 절감을 위해 더 적은 컴퓨팅을 사용하고, Performance-Optimized는 시간에 민감한 워크로드에 더 빠른 시작 및 실행을 제공합니다.

시작 시간은 저희에게 우선순위이며, 서버리스 노트북과 워크플로우가 큰 변화를 가져왔습니다. 노트북용 서버리스 컴퓨팅은 단 한 번의 클릭으로 쉽게 사용할 수 있습니다. — Chiranjeevi Katta, Airbus 데이터 엔지니어

Databricks는 중복 워크플로우를 제거하면서 서버리스 컴퓨팅으로 전환하는 데 도움을 주었습니다. 이러한 효율성 덕분에 운영 비용을 25% 절감할 수 있었습니다. 기존 인프라의 파이프라인은 이전에 처리하는 데 몇 시간이 걸렸습니다. 이제 2~5배 더 빠르게 실행됩니다. — Evan Cherney, Unilever 선임 데이터 과학 관리자

기존 자동 확장 접근 방식은 정적 규칙과 반응형 임계값에 의존하며, 이는 종종 이러한 미묘한 차이를 포착하지 못합니다. 그 결과 클러스터는 자주 과소 또는 과잉 프로비저닝되어 비효율성, 불안정성 또는 둘 다를 초래합니다.

서버리스 자동 확장은 보다 적응적인 접근 방식을 취합니다. 워크로드 패턴과 시스템 전반의 신호를 지속적으로 분석하여, 자동 확장기는 각 워크로드를 최적의 비용-성능 곡선에 배치합니다. 이는 대부분의 수동으로 구성된 클러스터가 분산 시스템의 올바른 크기 조정의 어려움으로 인해 성능이 저하되고 비용이 높아지는 지점입니다. 필요에 따라 수평 및 수직으로 확장하여 컴퓨팅 용량을 동적으로 조정하고, 메모리 부족 오류를 방지하며 워크로드가 증가함에 따라 안정성을 유지합니다. 작업이 메모리 부족 오류를 만나면 자동 확장기는 이를 자동으로 감지하고, 더 큰 VM에서 작업을 다시 시작하며, 수동 개입이나 작업 실패 없이 작업을 계속합니다.

그 영향은 측정 가능합니다. CKDelta는 이전에 4~5시간 걸리던 작업이 20분 만에 완료되었다고 보고했습니다. Unilever는 파이프라인이 2~5배 더 빠르게 실행되고 운영 비용이 25% 절감되는 것을 확인했습니다. HP는 32% 이상의 클라우드 비용 절감과 총 작업 실행 시간 36% 감소를 달성했습니다.

Spark Connect, 게이트웨이 및 자동 확장기는 함께 Spark를 위한 근본적으로 다른 운영 모델을 가능하게 합니다. 워크로드는 사용자 개입 없이 격리되고, 지능적으로 배치되며, 동적으로 리소스가 할당됩니다. 아키텍처 수준에서 안정성을 다룸으로써 서버리스 컴퓨팅은 안정성을 유지하면서 강력한 성능을 제공하여 사용자가 인프라 관리 대신 데이터 및 AI 워크로드 구축에 집중할 수 있도록 합니다.

¹ Justin Breese et al., "Blink Twice: 재시도를 사용한 버전리스 Apache Spark의 자동 워크로드 고정 및 회귀 감지," SIGMOD/PODS '25, pp. 103–106. https://doi.org/10.1145/3722212.3725084

오늘 서버리스 여정을 시작하세요

• 가입하기 Serverless Databricks 계정으로
• 노트북, Lakeflow 작업 및 Spark 선언적 파이프라인을 위한 Serverless Compute
• Serverless Compute 실무자 가이드

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