AWS EKS에서 Apache Flink와 함께하는 여정
Source: Dev.to
번역할 텍스트를 제공해 주시면 한국어로 번역해 드리겠습니다. 현재는 소스 링크만 포함되어 있어 번역할 내용이 없습니다. 텍스트를 복사해서 보내주시면 바로 번역해 드리겠습니다.
소개
스트리밍 파이프라인을 구축할 때 가장 큰 과제 중 하나는 단순히 데이터를 처리하는 것이 아니라, 데이터가 지속적으로 흐르는 동안 작업을 안정적으로 실행하도록 유지하는 것입니다. Apache Flink는 이 과제를 효과적으로 해결합니다.
Apache Flink 개요
Apache Flink은 상태를 유지하는 실시간 데이터 처리를 위해 구축된 분산 스트림‑처리 프레임워크입니다. 배치‑우선 프레임워크와 달리 Flink는 스트림을 핵심 추상화로 다루며, 배치는 그 특수한 경우에 불과합니다.
핵심 강점
- 정확히 한 번만 처리 보장
- 장기 실행 작업을 위한 네이티브 상태 관리
- 워터마크를 이용한 이벤트‑시간 처리
- 장애 복구를 가능하게 하는 체크포인팅
이러한 기능들 덕분에 Flink는 단순한 도구라기보다 항상 켜져 있는 시스템을 위한 플랫폼처럼 느껴집니다.
체크포인트 기반 실행 모델
스트리밍 파이프라인은 시간이 지남에 따라 진화합니다: 로직이 변경되고, 스키마가 확장되며, 성능 튜닝이 필요해집니다. Flink의 체크포인트 기반 실행 모델은 다음을 가능하게 합니다:
- 하위 시스템을 중단시키지 않고 작업을 재시작
- 로직이나 구성 변경을 안전하게 롤아웃
- 스트리밍 작업을 일회성 배포가 아니라 살아있는 시스템으로 다룸
상태 기반 처리, 정확히 한 번 실행 보장, 그리고 안전한 진화를 결합한 덕분에 Flink는 프로덕션 파이프라인에 명확한 선택이 됩니다.
AWS EKS에서 Flink 실행
Flink를 선택한 후에는 신뢰할 수 있는 런타임이 필요했습니다. AWS EKS는 다음을 제공합니다:
- 관리형 Kubernetes 컨트롤 플레인
- AWS 서비스와의 네이티브 통합
- 개발, 테스트, 프로덕션 전반에 걸친 일관된 환경
Flink를 진정한 Kubernetes‑네이티브로 만들기 위해 Flink Kubernetes Operator를 도입했습니다.
Source:
Flink Kubernetes Operator
운영자를 Helm을 통해 설치하면 FlinkDeployment 커스텀 리소스 정의(CRD)가 도입됩니다. 배포는 완전히 선언형이 되며, 우리는 YAML에 원하는 상태를 정의하고 운영자는 이를 지속적으로 조정합니다.
Operator Responsibilities
- JobManager 파드(Flask UI 호스팅) 실행
- 필요에 따라 TaskManager 스케일링
- 네트워킹, 볼륨, 서비스 계정 설정
- 작업 재시작, 업그레이드 및 복구 관리
이를 통해 운영 오버헤드가 크게 감소하고 Flink가 클라우드 네이티브 및 프로덕션 준비 상태가 됩니다.
Deployment Model
클러스터 관리와 작업 관리를 분리합니다:
- FlinkDeployment – 세션 클러스터 정의(이미지, 리소스, Flink 설정, EFS 마운트)
- FlinkSessionJob – 실제 스트리밍 작업 정의(엔트리포인트, 인수, 병렬도, 업그레이드 모드)
대부분의 배포는 Terraform을 통해 이루어지며, YAML 템플릿을 렌더링하고 kubernetes_manifest로 적용합니다.
Simplified Example of a FlinkSessionJob
apiVersion: flink.apache.org/v1beta1
kind: FlinkSessionJob
metadata:
name: my-streaming-job
spec:
job:
jarURI: s3://my-bucket/jars/my-job.jar
parallelism: 4
args:
- "--input"
- "s3://my-bucket/input/"
- "--output"
- "s3://my-bucket/output/"
upgradeMode: last-state # 💡 Tip: To rerun a job from the last checkpoint, set upgradeMode to `last-state`.Source: …
안전하게 작업 운영하기
초기 실행에서는 일반적으로 작업을 무상태(stateless)로 시작합니다. 재시작, 백필(backfill) 또는 업그레이드 시에는 upgradeMode: last-state를 사용한 체크포인트 기반 복구에 의존합니다. 이를 통해 다음을 보장합니다:
- 작업이 최신 성공 체크포인트에서 재개됨
- 하위 시스템이 안정적으로 유지됨
- CDC 소스의 경우에도 최소한의 간격이나 중복 발생
안전한 변경 절차
- 작업 또는 클러스터 사양을 업데이트합니다.
- Terraform 또는
kubectl을 통해 변경 사항을 적용합니다. - 운영자가 상태를 자동으로 복원합니다.
비즈니스 로직 변경 (Python, SQL, JAR)
- 업데이트된 코드를 S3에 푸시합니다.
- AWS DataSync를 통해 EFS와 동기화합니다.
- Flink 컨테이너 내 파일을 확인합니다.
- 롤링 방식의 상태 유지 업그레이드를 수행합니다.
이 절차를 통해 핵심 스트리밍 파이프라인을 안전하게 반복 개발할 수 있습니다.
독립형 Flink 배포 (대체)
운영자는 기본이지만 구성에 제한이 있습니다. 특수한 경우를 위해 Terraform을 사용하여 독립형 Flink 배포를 유지합니다:
- JobManager와 TaskManager를 별도로 배포합니다.
- Flink UI를 노출하는 Service와 Ingress를 설정합니다.
트레이드오프
| 접근 방식 | 장점 | 단점 |
|---|---|---|
| 오퍼레이터 | 더 안전하고, 간단하며, 자동화됨 | 제한된 구성 가능성 |
| 독립형 | 파드와 설정에 대한 완전한 제어 | 높은 운영 오버헤드 |
대부분의 워크로드는 오퍼레이터와 완벽하게 맞지만, 대체 옵션을 보유함으로써 엣지 케이스에 대한 유연성을 확보할 수 있습니다.
결론
상태 저장 스트리밍 모델을 위해 Flink를 선택하고, AWS EKS에서 실행하며, 마지막으로 Flink Kubernetes Operator로 작업을 안전하게 운영하는 과정은 스트리밍 파이프라인을 구축하고 유지하는 방식을 형성했습니다. Flink는 단순한 처리 엔진이 아니라, 진화하는 장기 실행 데이터 파이프라인을 위한 플랫폼입니다. AWS에서 Kubernetes‑네이티브로 실행함으로써 운영 안전성, 확장성 및 유연성의 균형을 맞출 수 있습니다.
우리는 AWS Community Builders와 더 넓은 스트리밍 커뮤니티와 계속해서 우리의 학습을 공유하게 되어 기쁩니다.