Flink 2.0 disaggregated state — checkpoint 시간이 3배 늘었습니다

Question

Flink 2.0의 disaggregated state로 production 마이그레이션. RocksDB local → S3로 옮겼는데:

지표	1.x	2.0 disaggregated
throughput	1.0x	2.4x
p99 처리 지연	1.0x	0.32x (-68%)
checkpoint 시간	30s	90s
checkpoint 메모리	4 GB	1.2 GB

throughput·지연은 만족인데 checkpoint 시간 3배 늘어서 RPO 우려. checkpoint 빈도 줄이면 복구 시간 증가, 그대로 두면 처리 영향.

어떻게 운영하나요?

환경: Flink 2.0.2, S3, jobs 12개

김영삼 · Accepted Answer

disaggregated state의 checkpoint 시간 증가는 예상된 trade-off입니다. 대신 throughput·메모리·scaling 이점이 큽니다. 운영 패턴 정리. 1. checkpoint 종류 분리 — incremental vs full state.backend.changelog.enabled: true state.backend.changelog.storage: filesystem state.backend.changelog.dstl.dfs.base-path: s3://changelog/ changelog 기반 incremental checkpoint. 30초 → 8초. 2. checkpoint 주기 늘리기 — 5분 → 10분 disaggregated state는 복구 시 S3에서 즉시 fetch. 1.x 대비 복구 시간 자체가 짧음. checkpoint 주기 늘려도 복구 RTO 영향 작음. execution.checkpointing.interval: 10min e

서버지기영호 · Answer

changelog state backend가 답입니다. 처음 도입 시 안정성 약간 우려했지만 6개월 운영 사고 없어요. 2.0.2 정도면 production ready.

flink_user_park · Answer

checkpoint 시간 보다 throughput · 메모리 · scaling이 더 중요한 워크로드 많죠. trade-off 이해하고 그대로 두는 게 정답인 경우도 흔합니다. RPO 비즈니스 요구 다시 점검해보세요.

주말프로젝트 · Answer

운영 6개월 경험인데 위에 적힌 함정 모두 거쳤습니다. 처음부터 정착 패턴 알았으면 좋았을 텐데...

댓글 0