State Backend — HashMapStateBackend vs RocksDB
직관적으로
사물함을 어디에 둘지 정하는 문제다 — 책상 바로 옆(빠르게 꺼낼 수 있지만 공간이 적음, HashMapStateBackend)에 둘지, 지하 창고(느리게 꺼내지만 훨씬 많이 보관 가능, RocksDB)에 둘지 고르는 것과 같다.
실제 사례
상태 크기가 작고(수백 MB 이내) 빠른 접근이 중요하면 HashMapStateBackend가 유리하다 — 상태가 Java 객체 그대로 힙 메모리에 있어 직렬화 없이 즉시 읽고 쓴다. 반대로 사용자 수천만 명의 장기 프로필처럼 상태가 수십~수백 GB로 커지면, 클러스터 메모리로는 감당이 안 돼 EmbeddedRocksDBStateBackend를 쓴다 — 상태를 바이트로 직렬화해 로컬 디스크의 RocksDB에 저장한다.
정확한 원리
HashMapStateBackend는 상태를 힙 위의 자바 객체(해시테이블)로 유지해 매우 빠르지만, 클러스터의 가용 메모리 크기에 상태 총량이 제한된다. EmbeddedRocksDBStateBackend는 상태를 직렬화해 TaskManager 로컬 디스크의 RocksDB(임베디드 키-값 저장소)에 저장하므로, 디스크 공간이 허용하는 한 사실상 무제한으로 상태를 키울 수 있지만, 매 접근마다 직렬화/역직렬화 비용이 들어 메모리 방식보다 **한 자릿수 이상 느리다**. RocksDB 방식은 대신 **증분 체크포인트**(마지막 체크포인트 이후 바뀐 부분만 업로드)를 지원해, 상태가 커도 체크포인트 자체는 상대적으로 빠르게 끝날 수 있다는 장점이 있다.
흔한 오해
"RocksDB가 항상 더 안전하니 기본값으로 써야 한다"는 생각은 절반만 맞다. RocksDB는 큰 상태·안정성 측면에서 유리하지만, 상태가 작고 처리량이 중요한 워크로드에서는 불필요한 직렬화 오버헤드 때문에 오히려 HashMapStateBackend가 나을 수 있다 — "내 상태가 클러스터 메모리에 다 들어가는가"가 선택의 첫 번째 기준이다.
확인 문제
Day 3-1(watermark)의 확인 문제에서 "지각 허용치를 60분으로 늘리면 OOM이 날 수도 있다"는 답이 나왔었다. State Backend를 RocksDB로 바꾸면 이 OOM 위험이 어떻게 달라지는가?
Answer Guide
RocksDB는 상태를 로컬 디스크에 저장하므로 힙 메모리 OOM 위험은 크게 줄어든다 — 대신 디스크 사용량 증가와 접근 속도 저하(직렬화 비용)라는 다른 형태의 비용으로 옮겨간다는 점까지 짚으면 좋다.