Toss의 Apache Flink + RocksDB 튜닝 — 광고 집계를 일주일로 늘린 방법

광고가 같은 사람에게 너무 많이 노출되면 불쾌하다. 이를 막는 게 Frequency Capping이다. "이 광고는 하루에 3번까지만 보여준다"는 규칙이 있다면, 실시간으로 노출 횟수를 세어야 한다.

토스는 이 집계를 1분에서 7일까지의 슬라이딩 윈도우로 처리한다. 그것도 4번의 Redis 조회를 1번으로 줄이면서. 그 과정에서 Flink와 RocksDB를 어떻게 튜닝했는지 정리한다.

기존 구조와 문제

기존엔 구간별로 다른 파이프라인을 썼다.

단기 (1분~1시간) → Flink 실시간 집계
장기 (1일~7일)  → Airflow 배치 (75회/일 실행)
서빙             → Head + Mid + Tail 3개 Redis 조회 합산

목표는 1분~7일 슬라이딩 집계를 단일 Flink 스트림으로 통합하고, 서빙 시 Redis 조회를 1번으로 줄이는 것이었다. Event Time 기반으로 재처리 시에도 정합성을 보장해야 했다.

앱 분리 결정

구간별로 병목 패턴이 완전히 다르다. 하나의 앱으로 통합하면 서로 다른 병목이 충돌한다. 3개 앱으로 분리했다.

비유하면 짧은 거리용 소형차, 장거리용 대형 트럭, 화물용 컨테이너를 따로 쓰는 것과 같다. 같은 엔진으로 세 용도를 다 커버하려면 어느 것도 제대로 못 한다.

초기 적재 정합성 — 재처리의 함정

새 파이프라인을 켤 때 과거 데이터를 채워야 한다(Backfill). 문제는 채우는 도중에 만료 타이머가 발화하면 아직 다 쌓이지 않은 집계에서 감소가 먼저 일어난다는 것이다. 값이 음수가 되는 사태가 생긴다.

2단계로 나눠서 해결했다.

1. Backfill: 과거 데이터를 채운다. 이 단계에서는 Redis 쓰기를 하지 않는다.
2. Catch-up: Backfill 완료 후, 실시간 스트림을 따라잡으며 Redis에 쓰기 시작한다.

Redis 쓰기: eventTime 기준 (watermark 아님)
withIdleness: 60초
timerState TTL: 슬라이딩 윈도우 만료보다 충분히 길게

[💡 잠깐! 이 용어는?] Watermark: Flink에서 "이 시각 이전의 이벤트는 모두 도착했다"를 선언하는 마커. Event Time 기반 윈도우의 완료 시점을 결정한다.

RocksDB 튜닝

Flink의 상태 백엔드로 RocksDB를 쓴다. 각 앱마다 병목이 달랐고, 튜닝도 각각 달랐다.

minutes 앱 — Write Stall 해결

Write Buffer가 가득 차면 Flink가 멈추는 Write Stall이 발생했다.

# 변경 전
managed-memory: 500MB
write-buffer-ratio: 0.25
 
# 변경 후
managed-memory: 1200MB
write-buffer-ratio: 0.50

결과: Block Cache Hit Rate가 6264%에서 99100%로 올라갔다.

hours 앱 — FilterBlock Cache Miss

async-profiler로 프로파일링하니 CPU의 96.2%가 FilterBlock 디스크 읽기에 쏠렸다.

[💡 잠깐! 이 용어는?] FilterBlock: RocksDB의 Bloom Filter 인덱스. "이 키가 이 SST 파일에 있는가?"를 디스크 읽기 없이 판단한다. 캐시 미스 시 디스크 I/O가 폭증한다.

partitioned-index-filters: true     # 캐시 미스당 read를 ~2,750배 감소
managed-memory: 1GB → 3GB (단계적)
target-file-size-base: 64MB → 256MB  # SST 파일 수 180개 → 40개

partitioned-index-filters를 켜면 전체 필터 블록 대신 필요한 파티션만 읽는다. 캐시 미스 비용을 대폭 줄인다.

days 앱 — 규모 자체가 병목

State가 커서 SST 파일이 기하급수적으로 늘어났다.

target-file-size-base: 256MB  # SST 파일 수 75% 감소
managed-memory: 12GB          # Block Cache 대부분 수용

7일치 집계 State의 live SST 파일 크기가 68GB, Savepoint는 220~230GB였다. 파일 수를 줄이는 것만으로 Compaction 부하가 크게 줄었다.

공통 최적화 3가지

1. Direct I/O 활성화

K8s 환경에서 OS Page Cache를 우회한다. 메모리 사용량을 Flink가 직접 제어할 수 있다. 단, Cache Miss 비용이 커지므로 partitioned-index-filters가 필수다.

2. 직렬화 방식 변경: Kryo → POJO

CPU 점유율: 20% → 12%
Block Cache 수용량: 2.2배 향상
Changelog I/O: 60% 감소

Kryo는 범용이지만 느리다. POJO 직렬화는 타입 정보를 미리 알기 때문에 훨씬 빠르다.

3. State 키 구조 단순화

// 변경 전: 중첩 맵
MapState<String, Map<String, Map<String, Any>>>
 
// 변경 후: 플랫 구조
MapState<String, AdsFrequencyStats>

중첩 맵은 직렬화/역직렬화 비용이 크다. 플랫하게 바꾸면 Block Cache도 더 효율적으로 쓴다.

Flink Changelog (DSTL)

Checkpoint가 전체 State를 저장하면 크기가 220~230GB였다. 변경분만 저장하는 DSTL(Distributed State Transfer Log)로 바꿨다.

전체 Checkpoint: 220~230GB
Incremental Checkpoint (DSTL): ~70MB

70MB면 네트워크 부하도, 스토리지도 완전히 다른 차원이다.

minutes: materialization 5분 주기
hours·days: materialization 10분 주기
Savepoint: NATIVE 대신 CANONICAL 사용

NATIVE Savepoint는 ID 갱신 교착 문제가 있어서 CANONICAL로 바꿨다.

결과

Head·Mid·Tail 세 계층을 합산하던 서빙이 단일 Redis 조회로 단순해졌다.

마무리

RocksDB 튜닝은 "메모리를 더 주면 된다"는 단순한 접근이 아니었다. 각 앱의 병목 패턴을 먼저 파악하고, 그에 맞는 설정을 찾는 과정이었다. minutes는 Write 버퍼, hours는 FilterBlock 캐시, days는 파일 수가 각각 핵심이었다.

Flink + RocksDB로 대규모 상태를 다룬다면 async-profiler로 프로파일링부터 시작하는 걸 권장한다. 어디서 CPU를 쓰는지 보이면 튜닝 방향이 명확해진다.

참고:

• Apache Flink + RocksDB 튜닝: https://toss.tech/article/flink-realtime-frequency-capping