1. Overview
Flink 애플리케이션은 기본적으로 두 가지 방식으로 실행된다. 하나는 클러스터를 미리 띄워 두고 여러 작업을 계속 올리는 방식이고, 다른 하나는 작업마다 전용 클러스터를 만드는 방식이다.
2. Session Cluster
Session Cluster는 클러스터를 먼저 띄워 두고, 여러 잡을 그 위에서 실행하는 방식이다. JobManager와 TaskManager가 항상 켜져 있기 때문에, 잡 제출 시 별도의 초기 부팅 과정을 거치지 않는다. 이 구조는 반복적인 개발과 실험이 많은 환경에서 자연스럽게 쓰인다. 코드를 수정하고 바로 제출하는 흐름이 빠르기 때문이다. 또한 여러 작은 잡을 단일 클러스터에서 돌릴 수 있어 리소스를 아끼는 효과도 있다.
다만 여러 잡이 동일한 JobManager를 공유하기 때문에, 한 작업이 과도하게 자원을 사용하거나 오류를 발생시키면 같은 클러스터의 다른 작업도 영향을 받을 수 있다. 개발 환경에서는 큰 문제가 되지 않지만, 운영 환경에서는 안정성 측면에서 주의가 필요하다.
| 구분 | 내용 |
|---|---|
| 클러스터 구성 방식 | 사전 실행된 단일 클러스터 사용 |
| 잡 실행 속도 | 매우 빠름 |
| 적합한 환경 | 개발, 실험, 노트북 기반 분석 |
| 특징 | 여러 잡이 JobManager 공유 |
| 한계 | 장애 전파 가능성, 격리 부족 |
3. Application Cluster
Application Cluster는 잡마다 전용 클러스터를 하나씩 생성하는 방식이다. 잡이 제출되는 순간 해당 잡을 위해 JobManager와 TaskManager가 새로 만들어지며, 그 클러스터는 오직 해당 작업만 실행한다. 이 구조의 핵심은 “격리”다. 잡별로 리소스와 상태가 독립되기 때문에 문제 발생 시 영향 범위가 명확하게 한정된다. 운영 안정성을 가장 우선하는 환경에서 자연스럽게 선택되는 이유다.
다만 클러스터를 매번 새로 구성해야 하므로 잡 시작 시간이 길어지고, 오버헤드도 Session Cluster보다 크다. 짧은 작업을 여러 번 반복 실행하는 용도에는 잘 맞지 않는다. 반면 장기간 운영되는 스트리밍 잡이나 SLA가 명확한 파이프라인에는 적합하다.
| 구분 | 내용 |
|---|---|
| 클러스터 구성 방식 | 잡 제출 시 전용 클러스터 생성 |
| 잡 실행 속도 | 상대적으로 느림 |
| 적합한 환경 | 운영, SLA 있는 서비스, 장기간 실행 잡 |
| 특징 | 완전한 잡 격리, 리소스 독립 |
| 한계 | 부팅 오버헤드, 리소스 요구 증가 |
참고자료
- flink 공식문서 : https://flink.apache.org/
