Ohouse Spark - 오늘의집의 통합 Spark 환경
카테고리
프로그래밍/소프트웨어 개발
서브카테고리
DevOps
대상자
- *데이터 엔지니어, 머신러닝 엔지니어, DevOps 엔지니어**
- 난이도: 중급 이상*
- 데이터 플랫폼 관리, 컨테이너화 기반 Spark 환경 운영에 관심 있는 개발자에게 유용*
핵심 요약
- Ohouse Spark는 다양한 환경에서 사용되는 Spark 이미지의 통합 관리를 위해 설계된 플랫폼으로, Base Image와 Derived Image를 통해 환경 일관성과 유지보수 효율성을 극대화
- EMR 기반 이미지 사용의 비용 문제와 프로젝트별 Dockerfile 관리 복잡성을 해결하여 15% 이상의 EC2 비용 절감 가능
- GitHub Actions + Docker Buildx를 기반으로 자동화된 CI/CD 파이프라인을 구축, Buildspec.toml을 통해 의존성 명세 및 이미지 빌드 가능
섹션별 세부 요약
1. 문제 상황 및 배경
- Spark 환경의 분산화 문제: JupyterHub, Airflow, Kyuubi 등 다양한 환경에서 OSS/EMR 기반 이미지 혼용, Python/Spark 버전 차이로 인한 의존성 불일치 발생
- 운영 비용 증가: EMR 기반 Docker 이미지 사용으로 1일 20,000개 작업 처리 시 15% EC2 비용 추가 발생
- 프로젝트별 Dockerfile 관리 복잡성: 데이터 플랫폼팀, 추천팀 등 팀별 이미지 관리 방식 차이로 인한 유지보수 어려움
2. Ohouse Spark의 핵심 구성
- Base Image:
- 공통 기반 환경 제공 (Java/Python 버전, AWS 라이브러리, Iceberg 지원 등)
- docker buildx를 활용한 Multi-platform Build 및 Layer Caching 지원
- GitHub Release를 통해 버전 관리 및 통합 테스트 수행
- Derived Image:
- Buildspec.toml을 통해 의존성 명세 및 프로젝트별 이미지 생성
- Airflow, Jupyter 등 시스템별 이미지 분리 (Batch Image, Jupyter Image)
- CI/CD 자동화: GitHub Actions를 통한 이미지 빌드 → 배포 → Airflow Variable 등록
3. 기술적 구현 및 효과
- Buildspec.toml 예시:
```toml
[project]
name = "discovery"
project_type = "scratch"
[[project.releases]]
release = "py311_gpu_vllm"
base_image_version = "2.1.0"
platforms = ["linux/amd64"]
setup_script = """apt-get update && apt-get -y install cuda-toolkit-12-4"""
requirements = """vllm==0.7.2 flash-attn==2.7.4.post1"""
```
- SparkSubmitOperator 활용:
```python
cdc_table_task = PysparkOperator(
runtime_release=("pyspark", "spark35"),
submitter=SparkOnKubernetesSubmitter(),
)
```
- 효과:
- 프로젝트별 이미지 관리로 의존성 일관성 확보
- 자동화 CI/CD로 이미지 배포 시간 70% 감소
- EMR 기반 이미지 사용 비용 15% 절감
결론
- Ohouse Spark는 Base Image + Derived Image 구조를 통해 프로젝트별 이미지 관리 복잡성을 해결하며, GitHub Actions + Docker Buildx 기반의 CI/CD 자동화를 통해 운영 효율성을 극대화
- Buildspec.toml을 통해 의존성 명세를 명확히 하여 프로덕션-개발 환경 불일치 문제를 해결
- DevOps 팀은 Base Image 통합 테스트와 Layer Caching 기능을 통해 이미지 빌드 시간을 최소화하고 비용 절감 가능