Spark를 Kubernetes 위에 올리면 무엇이 달라지는가

Spark를 Kubernetes 위에 올리면 무엇이 달라지는가 Spark를 왜 굳이 Kubernetes 위에 올리는지, 그리고 그 순간 운영 방식이 어떻게 바뀌는지를 실무 관점에서 정리한다.

---

들어가며

Spark on Kubernetes 이야기를 하면 대개 설치법이나 성능 튜닝부터 떠올리기 쉽다.
하지만 현업에서 더 중요한 질문은 따로 있다.
왜 굳이 Spark를 Kubernetes 위에 올리는가, 그리고 그 순간 운영 방식이 어떻게 바뀌는가다.
이 질문에 답하려면 먼저 Spark와 Kubernetes를 아주 짧게라도 다시 정리해야 한다.

먼저 Spark가 무엇인가

Apache Spark 공식 문서는 Spark를 대규모 데이터 처리를 위한 통합 분석 엔진으로 정의한다.
그리고 Spark SQL, Structured Streaming, MLlib, GraphX처럼 서로 다른 데이터 처리 도구를 하나의 생태계 안에서 제공한다고 설명한다. 실무적으로 풀어 말하면 Spark는 대량의 데이터를 분산 환경에서 읽고, 가공하고, 집계하고, 학습시키는 일을 빠르게 처리하기 위한 엔진이다.

즉 Spark는 단순한 라이브러리라기보다, 데이터 엔지니어링과 분석 파이프라인을 실행하는 실행 엔진에 가깝다.
배치 처리, 스트리밍, 머신러닝 전처리까지 한 플랫폼 안에서 다룰 수 있기 때문에 데이터 플랫폼의 중심축으로 자주 등장한다.

Kubernetes는 또 무엇인가

Kubernetes 공식 문서는 Kubernetes를 컨테이너화된 워크로드와 서비스를 관리하는 이식 가능하고 확장 가능한 오픈소스 플랫폼이라고 설명한다. 같은 문서에서 Kubernetes는 선언형 구성과 자동화를 지원하고, 스케줄링, 자가복구, 확장, 시크릿과 설정 관리, 배치 실행 같은 기능을 제공한다고 정리한다.

개발자 감각으로 다시 말하면 Kubernetes는 컨테이너를 실행하는 단순 실행기가 아니라, 컨테이너 워크로드를 운영하는 표준 운영 체계에 가깝다. 애플리케이션을 어디에 배치할지, 장애가 나면 어떻게 다시 띄울지, 리소스를 어떻게 나눌지, 비밀정보를 어떻게 주입할지 같은 문제를 플랫폼 차원에서 해결한다.

그럼 왜 Spark를 Kubernetes에 올리려 하는가

여기서 자연스럽게 질문이 생긴다.
Spark는 원래도 잘 돌아가는데 왜 굳이 Kubernetes를 붙이려 할까.
Spark 공식 문서는 Spark가 standalone, YARN, Kubernetes 같은 여러 배포 방식을 지원한다고 설명한다.
그리고 Spark on Kubernetes 문서는 Spark가 Kubernetes 클러스터 위에서 실행되며,
Kubernetes의 네이티브 스케줄러를 사용한다고 밝힌다.

이 말은 곧 Spark를 더 이상 별도 섬처럼 운영하지 않고, 조직이 이미 쓰고 있는 클라우드 네이티브 플랫폼 위의 하나의 워크로드로 다루겠다는 뜻이다. 배치 잡, API 서버, 내부 어드민 툴, 워커, 실험용 환경이 모두 Kubernetes 위에 있다면 Spark 역시 같은 규칙 안으로 편입하는 편이 운영상 자연스럽다.

아래 그림은 이 관계를 한 장으로 정리한 것이다.

Spark와 Kubernetes의 관계를 설명하는 다이어그램

그림처럼 핵심은 단순하다. Spark는 데이터 처리 엔진이고, Kubernetes는 컨테이너 워크로드 운영 플랫폼이다.
이 둘이 만나면 Spark 애플리케이션은 Kubernetes 위에서 driver pod와 executor pod 형태로 실행되고, 스케줄링과 복구, 리소스 배치, 운영 표준화는 Kubernetes의 책임 아래로 들어간다.

---

아주 간단한 예제로 보면

말로만 설명하면 추상적으로 들릴 수 있다.
가장 단순한 형태로 보면 로컬에서 돌리던 PySpark 코드 자체는 크게 달라지지 않는다.
달라지는 것은 코드보다 어디에 어떻게 제출하느냐다.
아래 예시는 숫자 범위를 만든 뒤 짝수 개수를 세는 아주 짧은 PySpark 코드다.

from pyspark.sql import SparkSession

spark = (
    SparkSession.builder
    .appName("spark-on-k8s-demo")
    .getOrCreate()
)

numbers = spark.range(1, 1000001)
even_count = numbers.filter("id % 2 = 0").count()

print(f"even_count={even_count}")

spark.stop()

이 코드를 Kubernetes 위에 제출할 때는 Spark 공식 문서가 설명하는 방식대로 spark-submit에서 master를 Kubernetes API 서버로 지정하고, 실행에 사용할 컨테이너 이미지와 namespace 같은 값을 함께 넘긴다. 아주 축약하면 아래처럼 이해하면 된다.

./bin/spark-submit \
  --master k8s://https://kubernetes.default.svc:443 \
  --deploy-mode cluster \
  --name spark-on-k8s-demo \
  --class org.apache.spark.examples.SparkPi \
  --conf spark.executor.instances=2 \
  --conf spark.kubernetes.container.image=myrepo/spark:4.1.1 \
  --conf spark.kubernetes.namespace=data-platform \
  local:///opt/spark/examples/jars/spark-examples_2.13-4.1.1.jar

여기서 중요한 것은 코드 본문이 아니라 실행 모델이다. 개발자는 Spark 애플리케이션을 제출하고, Kubernetes는 driver pod와 executor pod를 배치한다. 그래서 Spark on Kubernetes를 이해할 때는 소스 코드보다 제출 설정, 이미지, namespace, 권한, 리소스 설정을 같이 봐야 한다.

---

가장 크게 달라지는 지점 1: 실행 단위가 클러스터 관리자에서 Pod 중심으로 바뀐다

Spark on Kubernetes 문서에 따르면 spark-submit으로 애플리케이션을 제출하면 드라이버가 Kubernetes Pod로 뜨고, 그 드라이버가 executor Pod들을 생성해 작업을 수행한다.
즉 개발자가 보는 Spark 코드는 비슷할 수 있지만, 운영자가 보는 실행 단위는 완전히 달라진다.

구분	Spark 전용 운영 감각	Kubernetes 위 Spark 운영 감각
실행 단위	애플리케이션, executor	driver pod, executor pod
배치 기준	Spark 클러스터 기준	namespace, pod, quota, node 기준
장애 확인	Spark UI와 애플리케이션 로그 중심	Spark UI + pod 상태 + 이벤트 + 클러스터 로그
권한 설계	Spark 설정 중심	service account, RBAC, secret 중심

이 변화는 생각보다 크다. 이전에는 Spark 애플리케이션이 어떤 executor 수와 메모리를 먹는지가 주 관심사였다면, Kubernetes 위에서는 이 Pod가 어느 namespace에 속하는지, 어떤 리소스 quota 안에서 돌아가는지, 어느 노드에 배치되는지까지 함께 봐야 한다. 다시 말해 Spark 운영이 플랫폼 운영 문법 안으로 들어온다.

---

가장 크게 달라지는 지점 2: 왜 운영하는가의 이유가 달라진다

Spark를 Kubernetes 위에 올리는 이유는 단지 최신 기술을 쓰고 싶어서가 아니다. 실제 이유는 꽤 현실적이다.

첫째, 플랫폼 통합이 가능해진다.
이미 조직 안의 서비스들이 Kubernetes 위에서 돌아간다면 Spark만 별도 운영 체계로 가져갈 이유가 줄어든다.
둘째, 멀티테넌시와 리소스 격리를 같은 방식으로 관리할 수 있다.
Kubernetes는 quota, namespace, scheduling 같은 메커니즘을 통해 서로 다른 팀과 워크로드를 한 클러스터 안에서 다룰 수 있다.
셋째, 보안·관측·배포 표준화가 쉬워진다.
시크릿 주입, 설정 관리, 로그 수집, 이미지 배포 같은 절차를 Spark만 따로 만들지 않아도 된다.

이 지점이 중요한 이유는 데이터 플랫폼이 점점 더 독립적인 특수 시스템이 아니라, 조직 전체 엔지니어링 플랫폼의 일부가 되고 있기 때문이다. Spark on Kubernetes는 바로 이 변화와 맞닿아 있다.

---

가장 크게 달라지는 지점 3: 보안과 권한은 더 세밀해지지만 더 복잡해진다

많은 팀이 Kubernetes 위에 올리면 자동으로 보안이 좋아질 것이라 기대한다.
하지만 Spark on Kubernetes 문서는 기본적으로 모든 보안 기능이 자동 활성화되는 것은 아니며, Pod Security Admission, 볼륨 사용, 사용자 ID, RBAC, Secret 처리 같은 항목을 따로 다뤄야 한다고 설명한다.

이 말은 곧 보안이 좋아질 수는 있지만, 저절로 좋아지지는 않는다는 뜻이다.
예를 들어 드라이버 Pod가 다른 리소스를 만들 수 있어야 한다면 서비스 계정 권한을 설계해야 하고, 외부 저장소 비밀키를 써야 한다면 Secret을 어떻게 마운트할지 결정해야 한다.
Spark만 알던 시절보다 훨씬 더 많은 운영 결정이 필요해진다.

---

가장 크게 달라지는 지점 4: 디버깅 관점이 넓어진다

Spark만 운영할 때는 실패 원인을 Spark 설정, 셔플, 메모리, 코드 로직에서 먼저 찾는다.
Kubernetes 위에서는 여기에 Pod 스케줄링 실패, 이미지 pull 실패, 권한 누락, 볼륨 마운트 실패, 클러스터 리소스 부족이 함께 들어온다. 그래서 문제를 볼 때도 애플리케이션 문제 + 플랫폼 문제를 같이 봐야 한다.

실제로 Spark on Kubernetes 문서가 로그 접근, Driver UI 접근, 디버깅과 인트로스펙션을 별도 항목으로 다루는 이유도 여기에 있다.
같은 executor 실패라도 원인이 Spark 코드가 아니라 Pod 생성 실패일 수 있기 때문이다.
이 차이 때문에 Spark on Kubernetes는 엔진 하나를 아는 것만으로는 부족하고, Kubernetes 운영 감각까지 같이 요구한다.

---

그럼 언제 이 선택이 맞는가

Spark를 Kubernetes 위에 올리는 선택이 특히 잘 맞는 경우는 비교적 분명하다.
조직의 표준 운영 플랫폼이 이미 Kubernetes이고, 여러 워크로드가 같은 관측·배포·보안 체계를 쓰고 있으며,
데이터 처리 워크로드도 그 흐름 안으로 넣고 싶을 때다. 이 경우 Spark는 별도 운영 사일로가 아니라 플랫폼의 일부가 된다.

반대로 아직 Kubernetes 운영 역량이 약하거나, 데이터 플랫폼 전용 클러스터가 이미 충분히 안정적이고, 팀이 Spark 외 레이어까지 감당하기 어렵다면 꼭 옮겨야 할 이유는 약하다. 기술적으로 가능하다는 사실과 조직적으로 이득이라는 사실은 다르다.

마무리

Spark를 Kubernetes 위에 올리면 가장 크게 달라지는 것은 Spark API가 아니다. 운영의 관점이 바뀐다. Spark를 데이터 처리 엔진으로만 보는 것이 아니라, Kubernetes 위에서 돌아가는 워크로드로 보게 된다. 그 순간부터 실행 단위는 Pod가 되고, 리소스 운영은 quota와 scheduling이 되고, 보안은 RBAC와 Secret 설계가 되며, 장애 분석은 클러스터 레벨까지 확장된다.

결국 이 선택은 성능 문제 하나로 결정되지 않는다. 오히려 조직이 데이터를 다루는 시스템을 얼마나 플랫폼적으로 운영하고 싶은가에 더 가깝다. 그리고 그 질문에 대한 답이 이미 나와 있는 팀이라면, Spark on Kubernetes는 단순 유행이 아니라 꽤 설득력 있는 운영 모델이 된다.

참고 자료

• https://spark.apache.org/docs/latest/ "Overview - Spark Documentation"
• https://kubernetes.io/docs/concepts/overview/ "Overview | Kubernetes"
• https://spark.apache.org/docs/latest/running-on-kubernetes.html "Running Spark on Kubernetes - Apache Spark Documentation"