프로덕션 준비 체크리스트

프로덕션 준비 체크리스트 (Production Readiness Checklist)

프로덕션 준비 체크리스트는 Apache Flink 작업(Job)을 프로덕션에 투입하기 전에 신중히 고려해야 할 구성 옵션의 개요를 제공합니다. Flink 커뮤니티는 각 구성에 합리적인 기본값을 제공하려 노력했지만, 이 목록을 검토하고 선택한 옵션이 요구 사항에 충분한지 확인하는 것이 중요합니다.

출처: 문서

본문

명시적인 최대 병렬도 설정 (Set An Explicit Max Parallelism)

작업별·연산자별 세분성으로 설정되는 최대 병렬도(max parallelism)는 상태 저장 연산자가 확장(scale)할 수 있는 최대 병렬도를 결정합니다. 현재 작업이 시작된 후에는 연산자의 상태를 버리지 않는 한 연산자의 최대 병렬도를 변경할 방법이 없습니다. 상태 저장 연산자를 무한히 확장 가능하게 두지 않고 최대 병렬도가 존재하는 이유는, 이것이 애플리케이션의 성능과 상태 크기에 영향을 주기 때문입니다. Flink는 상태를 재확장(rescale)하는 능력을 위해 특정 메타데이터를 유지해야 하며, 이 메타데이터는 최대 병렬도에 선형적으로 증가합니다. 일반적으로 향후 확장성 요구를 수용할 만큼 충분히 높으면서도 합리적인 성능을 유지할 수 있을 만큼 낮은 최대 병렬도를 선택해야 합니다.

최대 병렬도는 다음 조건을 충족해야 합니다: 0 < parallelism <= max parallelism <= 2^15

setMaxParallelism(int maxparallelism)을 사용해 최대 병렬도를 명시적으로 설정할 수 있습니다. 설정하지 않으면 Flink가 작업이 처음 시작될 때 연산자 병렬도의 함수로 결정합니다:

  • 128: 모든 병렬도 <= 128에 대해.
  • MIN(nextPowerOfTwo(parallelism + (parallelism / 2)), 2^15): 모든 병렬도 > 128에 대해.

모든 연산자에 UUID 설정 (Set UUIDs For All Operators)

세이브포인트 문서에서 언급한 대로, 사용자는 DataStream의 각 연산자에 uid를 설정해야 합니다. UID는 Flink가 연산자 상태를 연산자에 매핑하는 데 필요하며, 이는 세이브포인트에 필수적입니다. 기본적으로 연산자 uid는 JobGraph를 탐색하고 특정 연산자 속성의 해시를 생성해 만들어집니다. 사용자 관점에서는 편리하지만, JobGraph의 변경(예: 연산자 교체)이 새 UUID를 만들기 때문에 매우 취약합니다. 안정적인 매핑을 구축하려면 사용자가 setUid(String uid)를 통해 제공하는 안정적인 연산자 uid가 필요합니다.

올바른 상태 백엔드 선택 (Choose The Right State Backend)

자신의 사용 사례에 적합한 백엔드를 선택하는 방법은 상태 백엔드(state backends) 설명을 참고하세요.

올바른 체크포인트 간격 선택 (Choose The Right Checkpoint Interval)

체크포인팅은 Flink의 주요 장애 허용 메커니즘으로, 작업 상태의 스냅샷을 주기적으로 내구성 있는 위치에 저장합니다. 실패 시 Flink는 가장 최근 체크포인트에서 재시작하고 처리를 재개합니다. 작업의 체크포인트 간격은 Flink가 얼마나 자주 이러한 스냅샷을 찍을지를 구성합니다. 완벽한 체크포인트 간격에 대한 단일 정답은 없지만, 커뮤니티는 이 매개변수 구성 시 고려해야 할 요소를 안내할 수 있습니다.

  • 서비스의 SLA는 무엇인가: 체크포인트 간격은 작업의 서비스 수준 계약(SLA)의 표현으로 이해하는 것이 좋습니다. 작업이 다음 체크포인트 1초 전에 실패하는 최악의 시나리오에서, 데이터 재처리를 얼마나 감당할 수 있습니까? 체크포인트 간격 5분은 실패 후 Flink가 5분치 데이터를 넘어 재처리하지 않음을 의미합니다.
  • 서비스가 얼마나 자주 결과를 전달해야 하는가: Kafka나 FileSink 같은 정확히-한 번(exactly-once) 싱크는 체크포인트 완료 시에만 결과를 보이게 합니다. 더 짧은 체크포인트 간격은 결과를 더 빨리 제공하지만 이러한 시스템에 추가 부담을 줄 수 있습니다. 제품 요구 사항을 충족하면서 싱크에 과도한 부하를 주지 않는 전달 시간을 찾기 위해 관계자와 협의하는 것이 중요합니다.
  • Task Manager가 감당할 수 있는 부하는 얼마인가: Flink의 모든 내장 상태 백엔드는 비동기 체크포인팅을 지원하므로, 스냅샷 과정이 데이터 처리를 멈추지 않습니다. 그러나 여전히 머신의 CPU 주기와 네트워크 대역폭을 필요로 합니다. 증분 체크포인팅은 특정 체크포인트의 비용을 줄이는 강력한 도구가 될 수 있습니다.

그리고 가장 중요한 것은, 작업을 테스트하고 측정하는 것입니다. 모든 Flink 애플리케이션은 고유하며, 적절한 체크포인트 간격을 찾는 가장 좋은 방법은 실제 환경에서 자신의 작업이 어떻게 동작하는지 보는 것입니다.

JobManager 고가용성 구성 (Configure JobManager High Availability)

JobManager는 각 Flink 배포의 중앙 조정자 역할을 하며, 클러스터의 스케줄링과 리소스 관리를 모두 담당합니다. 이것은 클러스터 내 단일 장애 지점(SPOF)이며, 크래시하면 새 작업을 제출할 수 없고 실행 중인 애플리케이션도 실패합니다.

Apache Zookeeper나 Flink의 Kubernetes 기반 서비스와 함께 고가용성(High Availability)을 구성하면 빠른 복구가 가능하며, 프로덕션 설정에 강력히 권장됩니다.

Flink는 의도적으로 원격 코드 실행을 지원하도록 설계되었습니다. 악성 코드 실행의 위험을 완화하려면 Flink 클러스터가 제대로 보호되는지 확인하세요. 클러스터를 공용 인터넷에 직접 노출하지 마세요. 대신 회사 인트라넷을 통해 접근을 제한하거나 TLS, 인증, 역할 기반 접근 제어(RBAC) 등으로 클러스터를 보호하세요.

자세한 내용은 Flink Security FAQ를 참고하세요.

더 알아보기 (Learn more)