배포
배포 (Deployment)
Flink는 다양한 배포 시나리오를 조합하여 지원하는 다재다능한 프레임워크입니다. 아래에서 Flink 클러스터의 구성 요소들, 그 목적과 사용 가능한 구현들을 간략히 설명합니다. 로컬에서 Flink를 빠르게 시작하려면 Standalone Cluster를 구성해 보세요.
출처: 문서
본문
Flink는 다양한 배포 시나리오를 조합(mix and match)하여 지원하는 다재다능한 프레임워크입니다.
아래에서 Flink 클러스터의 구성 요소, 그 목적과 사용 가능한 구현들을 간략히 설명합니다. 로컬에서 Flink를 시작하고 싶다면 Standalone Cluster를 설정하는 것을 권장합니다.
개요와 참조 아키텍처 (Overview and Reference Architecture)
아래 그림은 모든 Flink 클러스터의 구성 요소를 보여줍니다. 어디에선가 항상 클라이언트(client)가 실행 중이며, Flink 애플리케이션의 코드를 받아 JobGraph로 변환한 뒤 JobManager에 제출합니다.
JobManager는 작업을 실제 연산자(소스, 변환, 싱크 등)가 실행되는 TaskManager에 분배합니다.
Flink를 배포할 때 각 구성 요소마다 여러 옵션이 제공되는 경우가 많습니다. 아래 그림의 하단 표에 목록을 정리했습니다.
| 구성 요소 | 목적 | 구현 |
|---|---|---|
| Flink Client | 배치 또는 스트리밍 애플리케이션을 데이터플로우 그래프로 컴파일한 뒤 JobManager에 제출합니다. | |
| JobManager | JobManager는 Flink의 중앙 작업 조정 구성 요소의 이름입니다. 리소스 제공자에 따라 다양한 구현이 있으며, 고가용성(high availability), 리소스 할당 동작, 지원되는 작업 제출 모드에서 차이가 있습니다. JobManager의 작업 제출 모드:
|
|
| TaskManager | TaskManager는 Flink 작업의 실제 작업을 수행하는 서비스입니다. | |
| 외부 구성 요소 (모두 선택 사항) | ||
| High Availability Service Provider | Flink의 JobManager는 고가용성 모드로 실행될 수 있으며, JobManager 장애로부터 Flink가 복구되도록 합니다. 장애 조치를 빠르게 하기 위해 여러 대기(standby) JobManager를 백업으로 시작할 수 있습니다. | |
| File Storage and Persistency | 체크포인팅(스트리밍 작업의 복구 메커니즘)을 위해 Flink는 외부 파일 저장 시스템에 의존합니다. | FileSystems 페이지 참고 |
| Resource Provider | Flink는 Kubernetes나 YARN 같은 다양한 리소스 제공자 프레임워크를 통해 배포될 수 있습니다. | 위의 JobManager 구현 참고 |
| Metrics Storage | Flink 구성 요소는 내부 메트릭을 보고하고, Flink 작업은 추가적인 작업별 메트릭도 보고할 수 있습니다. | Metrics Reporter 페이지 참고 |
| Application-level data sources and sinks | 애플리케이션 수준 데이터 소스·싱크는 기술적으로 Flink 클러스터 구성 요소의 배포에 포함되진 않지만, 새 Flink 프로덕션 배포를 계획할 때 고려해야 합니다. 자주 사용하는 데이터를 Flink와 함께 배치하면 상당한 성능 이점이 있을 수 있습니다. | 예:
|
반복 가능한 리소스 정리 (Repeatable Resource Cleanup)
작업이 finished, failed, cancelled 중 하나의 전역 종료 상태에 도달하면, 해당 작업과 연관된 외부 구성 요소 리소스가 정리됩니다. 리소스 정리 중 실패가 발생하면 Flink는 정리를 재시도합니다. 사용된 재시도 전략은 구성에서 설정할 수 있습니다. 최대 재시도 횟수에 성공 없이 도달하면 작업은 더티(dirty) 상태로 남게 됩니다. 해당 아티팩트는 수동으로 정리해야 합니다(자세한 내용은 High Availability Services / JobResultStore 섹션 참고). 동일한 작업(같은 job ID 사용)을 다시 시작하면 작업을 다시 실행하지 않고 정리가 재개됩니다.
현재 일반적인 CompletedCheckpoint 관리의 일부로 subsuming되면서 삭제에 실패한 CompletedCheckpoint의 정리에 문제가 있습니다. 이러한 아티팩트는 반복 가능한 정리 대상에 포함되지 않으므로 여전히 수동으로 삭제해야 합니다. 이 내용은 FLINK-26606에서 다룹니다.
애플리케이션 리소스 정리도 유사합니다(자세한 내용은 High Availability Services / ApplicationResultStore 섹션 참고).
배포 모드 (Deployment Modes)
Flink는 애플리케이션을 두 가지 모드로 실행할 수 있습니다:
- Application Mode,
- Session Mode.
위 모드는 다음에서 차이가 있습니다:
- 클러스터 수명주기와 리소스 격리 보장
- 애플리케이션의
main()메서드가 클라이언트에서 실행되는지, 클러스터에서 실행되는지 여부
Application Mode
애플리케이션의 main() 메서드가 클라이언트 측에서 실행되면, 이 프로세스는 애플리케이션의 의존성을 로컬에 내려받고, Flink 런타임이 이해할 수 있는 애플리케이션 표현(즉 JobGraph)을 추출하기 위해 main()을 실행하며, 의존성과 JobGraph(s)를 클러스터로 전송합니다. 이 때문에 클라이언트는 의존성 다운로드와 바이너리 전송에 상당한 네트워크 대역폭, main() 실행에 CPU 사이클이 필요할 수 있어 리소스를 많이 소비하게 됩니다. 이 문제는 클라이언트가 여러 사용자 간에 공유될 때 더 두드러질 수 있습니다.
이 관찰을 바탕으로 Application Mode는 제출된 애플리케이션마다 클러스터를 만들고, 애플리케이션의 main() 메서드는 JobManager가 실행합니다. 애플리케이션별 클러스터를 만드는 것은 특정 애플리케이션의 작업들만 공유하는 세션 클러스터를 만들고, 애플리케이션이 끝나면 종료하는 것으로 볼 수 있습니다. 이 아키텍처로 Application Mode는 애플리케이션 단위의 리소스 격리와 로드 밸런싱 보장을 제공합니다.
Application Mode는 사용자 jar가 접근이 필요한 모든 Flink 구성 요소(JobManager, TaskManager)의 클래스패스(usrlib 폴더)에 이미 존재한다는 가정을 기반으로 합니다. 즉, 애플리케이션이 Flink 배포판과 함께 번들되어 있다는 뜻입니다. 이를 통해 다른 배포 모드처럼 RPC로 사용자 jar를 Flink 구성 요소에 배포할 필요가 없어져 배포/복구 과정이 빨라집니다.
정보: Application mode는 사용자 jar가 Flink 배포판과 함께 번들되어 있다고 가정합니다.
클러스터에서
main()메서드를 실행하면 코드에 다른 영향이 있을 수 있습니다. 예를 들어registerCachedFile()로 환경에 등록한 경로는 애플리케이션의 JobManager에서 접근 가능해야 합니다.
Application Mode는 여러 작업으로 구성된 애플리케이션 제출을 허용합니다. 작업 실행 순서는 배포 모드가 아니라 작업을 실행하는 데 사용하는 호출에 의해 결정됩니다. 블로킹(blocking)인 execute()를 사용하면 순서가 정해져 "다음" 작업이 "이" 작업이 끝날 때까지 연기됩니다. 논블로킹(non-blocking)인 executeAsync()를 사용하면 "이" 작업이 끝나기 전에 "다음" 작업이 시작됩니다.
경고: Application Mode는 멀티 작업 애플리케이션(
main()메서드에서execute()또는executeAsync()를 여러 번 호출)을 허용하지만, 이런 경우 High-Availability가 제한됩니다. Application Mode의 High-Availability는 단일 스트리밍 작업 또는 여러 배치 작업이 있는 애플리케이션에서만 지원됩니다. 자세한 내용은 FLIP-560 참고.추가로, Application Mode에서 실행 중인 여러 작업 중 하나(예:
executeAsync()로 제출)가 취소되면 기본적으로 모든 작업이 중지되고 JobManager가 종료됩니다. 이 동작은execution.terminate-application-on-any-job-terminated-exceptionally옵션으로 구성할 수 있습니다. 일반적인 작업 완료(소스가 종료됨으로써)는 지원됩니다.
Session Mode
Session mode는 이미 실행 중인 클러스터를 가정하고 그 리소스를 사용해 제출된 애플리케이션을 실행합니다. 같은 (세션) 클러스터에서 실행되는 애플리케이션들은 같은 리소스를 사용하며 경쟁합니다. 제출된 작업마다 전체 클러스터를 띄우는 리소스 오버헤드를 지불하지 않아도 된다는 장점이 있습니다. 그러나 작업 하나가 잘못 동작하거나 TaskManager를 내리면 그 TaskManager에서 실행 중인 모든 작업이 해당 장애의 영향을 받습니다. 이는 장애를 일으킨 작업에 부정적인 영향 외에도, 재시작하는 모든 작업이 동시에 파일시스템에 접근하여 다른 서비스에서 사용 불가하게 만드는 잠재적 대규모 복구 과정을 의미합니다. 또한 단일 클러스터가 여러 작업을 실행한다는 것은 클러스터의 모든 작업의 북키핑을 담당하는 JobManager에 더 많은 부하가 걸린다는 의미입니다.
Session Mode에서 애플리케이션의 main() 메서드는 클라이언트 또는 클러스터에서 실행될 수 있습니다. Command-Line Interface(CLI) 또는 SQL Client로 애플리케이션을 제출하면 main() 메서드는 클라이언트에서 실행됩니다. 반면 REST API /jars/:jarid/run-application으로 제출하면 main() 메서드는 클러스터에서 실행됩니다. 이는 Session Mode의 공유 클러스터 리소스 모델을 유지하면서도 클라이언트의 리소스 사용과 네트워크 대역폭 측면에서 Application Mode와 같은 이점을 제공합니다.
요약 (Summary)
Session Mode에서는 클러스터 수명주기가 클러스터에서 실행되는 애플리케이션과 무관하며 리소스가 모든 애플리케이션에 공유됩니다. 애플리케이션의 main() 메서드는 클라이언트 또는 클러스터에서 실행될 수 있습니다. Application Mode는 애플리케이션마다 세션 클러스터를 만들고 애플리케이션의 main() 메서드를 클러스터에서 실행합니다. 따라서 리소스가 단일 main() 메서드에서 실행되는 작업(들)에만 사용되므로 리소스 격리가 더 좋습니다. 대신 애플리케이션마다 전용 클러스터를 띄워야 한다는 비용이 있습니다.
벤더 솔루션 (Vendor Solutions)
여러 벤더가 관리형 또는 완전 호스팅 Flink 솔루션을 제공합니다. 이 벤더 중 누구도 Apache Flink PMC의 공식 지원 또는 보증을 받지 않습니다. 이 제품들을 사용하는 방법은 벤더가 유지하는 문서를 참고하세요.
- AliCloud Realtime Compute — Website · AliCloud
- Amazon EMR — Website · AWS
- Amazon Managed Service for Apache Flink — Website · AWS
- Cloudera Stream Processing — Website · AWS, Azure, Google Cloud, On-Premises
- Confluent Cloud and Platform — Website · AWS, Azure, Google Cloud, On-Premises
- Huawei Cloud Stream Service — Website · Huawei Cloud
- Ververica's Unified Streaming Data Platform (Managed Service / BYOC / Self-Managed) — Website · AliCloud, AWS, Azure, Google Cloud, On-Premises