> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sifi.life/llms.txt
> Use this file to discover all available pages before exploring further.

# 서버리스 성능과 안정성을 위한 분산 시스템 재설계

작성자: Databricks Spark 팀 | 2026년 5월 6일

원문: [https://www.databricks.com/blog/rethinking-distributed-systems-serverless-performance-and-reliability](https://www.databricks.com/blog/rethinking-distributed-systems-serverless-performance-and-reliability)

***

> **참고**
> **요약**

* **사용자가 인프라를 관리하지 않는 진짜 서버리스**: 전통적인 Spark 배포는 사용자가 자원 경합과 인프라를 직접 다뤄야 했습니다. 서버리스 Spark는 클라이언트-서버 분리, 지능형 라우팅, 적응형 오토스케일링으로 이를 시스템 책임으로 옮깁니다.
* **연 45억+ 워크로드를 99.998% 성공률로**: Spark Connect 기반의 격리된 실행이 매년 25회의 메이저 Spark 런타임 업그레이드를 사용자 개입 없이 처리합니다.
* **실측 성능 — 5배 빠른 파이프라인, 32% 클라우드 비용 절감**: Unilever, CKDelta, HP의 실측 결과가 인용됩니다.

***

전통적인 Spark 배포는 인프라를 사용자에게 직접 노출합니다. 결과적으로:

* 한 잡의 자원 폭주가 다른 잡의 안정성을 깨고
* 애플리케이션과 컴퓨트가 강하게 결합되어 런타임 업그레이드가 어려우며
* 성능과 비용의 균형은 사용자가 수동으로 맞춰야 합니다

Databricks의 서버리스 Spark는 이 모델을 **시스템이 책임지는 모델**로 다시 설계합니다. 핵심 아키텍처 컴포넌트 세 가지를 살펴봅니다.

## 1. Spark Connect — 클라이언트-서버 분리로 격리 확보

전통적인 Spark는 사용자 애플리케이션이 Spark 드라이버와 같은 머신에서 실행되는 모놀리식 구조입니다. 한 사용자가 드라이버 메모리를 다 써버리면 같은 클러스터의 다른 작업이 영향을 받습니다.

> "Spark Connect는 애플리케이션이 Spark 드라이버와 **gRPC로 통신**하는 클라이언트-서버 아키텍처를 도입합니다."

이 분리가 만드는 것:

* **사용자 애플리케이션 ↔ 인프라 디커플링**: 애플리케이션 변경 없이 백엔드 업그레이드 가능
* **멀티 테넌트 실행**: 같은 클러스터에서 여러 워크로드가 안전하게 격리됨
* **연 45억+ 워크로드를 99.998% 성공률로 처리**
* **연 25회의 메이저 Spark 런타임 업그레이드**가 사용자 개입 없이 진행됨

## 2. Serverless Gateway — 지능형 워크로드 라우팅

모든 쿼리를 똑같이 다루는 것이 아니라, 게이트웨이가 세 가지 신호를 평가합니다:

1. **예상 쿼리 크기** — 작은 탐색 쿼리인가, 대용량 ETL인가
2. **현재 클러스터 활용도** — 어디에 여유가 있는가
3. **레이턴시 프로파일** — 인터랙티브 응답이 필요한가, 배치인가

이 신호들을 종합해 작은 탐색 쿼리는 가벼운 클러스터로, 무거운 ETL 잡은 여유 용량이 있는 클러스터로 라우팅합니다. 자원 경합이 구조적으로 줄어듭니다.

## 3. Adaptive Autoscaling — 동적 자원 최적화

서버리스 Spark의 오토스케일링은 두 가지 모드를 제공합니다:

* **Standard 모드** — 비용 최적화 우선
* **Performance-Optimized 모드** — 속도 최적화 우선

전통적인 정적 오토스케일링 규칙(예: "CPU 70% 넘으면 노드 추가")과 달리, 적응형 오토스케일러는 **워크로드 패턴을 지속 분석**해 각 작업을 최적의 비용-성능 곡선 위에 위치시킵니다.

특히 인상적인 동작:

> Out-of-memory 에러가 발생하면, 오토스케일러가 **수동 개입 없이 더 큰 VM에서 작업을 자동 재시작**합니다.

사용자가 "메모리를 더 줘야 하나?"를 고민할 필요가 없습니다.

## 실측 성능 — 고객 사례

블로그는 측정된 결과를 인용합니다:

| 고객           | 결과                                    |
| ------------ | ------------------------------------- |
| **CKDelta**  | 잡 시간이 4–5시간 → **20분**으로 단축            |
| **Unilever** | 파이프라인 **2\~5배 빠르게**, 운영 비용 **25% 절감** |
| **HP**       | 클라우드 비용 **32% 절감**, 잡 런타임 **36% 단축**  |

이 수치들은 단순한 인프라 자동화로 얻기 어려운 수준입니다. 게이트웨이의 라우팅, 적응형 오토스케일링, Spark Connect의 격리가 함께 작동할 때 가능합니다.

## 핵심 전환

근본적인 전환은 이것입니다:

> **사용자가 인프라 트레이드오프를 수동으로 다루는 모델 → 시스템이 안정성·성능·비용을 아키텍처 차원에서 자동 최적화하는 모델**

이는 단순히 "오토스케일링 + 자동 종료"가 아닙니다. Spark Connect가 만든 격리, 게이트웨이가 만든 지능형 라우팅, 그리고 적응형 오토스케일러가 함께 만든 **결합된 시스템**입니다.

## 시작하기

서버리스 Spark는 Databricks 워크스페이스에서 즉시 활성화할 수 있습니다. 자세한 활성화와 모드 선택은 [Databricks 서버리스 컴퓨트 문서](https://docs.databricks.com/aws/en/compute/serverless/)를 참고하세요.