Lease와 Hazelcast로 구현한 Kubernetes Pod 클러스터링

Kubernetes는 기본적으로 무상태 아키텍처라 Pod 간 데이터 공유가 없지만, 서비스 디스커버리와 클러스터링을 활용하면 필요한 기능만 협력적으로 묶을 수 있다.

크래시리포트에는 두 가지 개선 사례가 적용됐다.

• 실시간 5분 통계: 기존에는 GCP Dataflow와 별도 Kubernetes 클러스터를 써야 했고, Apache Beam 학습 부담과 버전 관리, 지원 종료 이슈가 있었다.
• 심볼리케이팅 캐시 공유: Pod마다 따로 쌓이던 캐시를 공유하지 못해 성능 개선에 한계가 있었다.

실시간 통계 기능은 Apache Camel과 Spring Boot로 다시 구성했다. Pod 내부를 사전 통계 계산용 스트리밍 라우터와 최종 통계 계산용 라우터로 나눠, MapReduce와 유사한 구조를 만들었다. Camel의 Aggregation Strategy를 사용해 메시지를 합산했고, Kubernetes Lease를 이용한 리더 선출로 Active-Standby 구성을 만들었다.

Lease 기반 클러스터링을 위해서는 애플리케이션 설정과 ServiceAccount 권한 설정이 필요했다. 설정 후에는 클러스터 멤버 목록과 리더 변경 로그를 통해 정상 동작을 확인했으며, kubectl get leases leaders-lock2 -o yaml로도 리더를 점검할 수 있었다.

적용 결과, 기존 구성과 비슷한 안정성을 유지하면서 미확인 메시지 수와 가장 오래된 미확인 메시지 기간이 줄어들었다.

심볼리케이팅 캐시 공유에는 Hazelcast를 도입했다. 기존 embedded H2DB 기반 JPA 캐시는 Pod 간 공유가 어려웠지만, Hazelcast의 Key-Value 캐시와 Kubernetes auto discovery를 쓰면 클러스터 간 데이터 공유가 가능했다. 여기에 계정·권한 설정과 통신 포트 설정을 더해 클러스터를 구성했다.

배포 후에는 Hazelcast 클러스터링 성공 로그로 동작을 검증했고, 캐시가 주변 Pod로 공유되면서 심볼리케이팅 평균 시간이 감소했다. 또한 미확인 메시지 기간도 최댓값 기준 평균 50% 정도 개선됐다. Hazelcast의 캐시 동기화 옵션 덕분에 신규 배포 시에도 기존 캐시를 유지해 초기 성능 저하도 줄일 수 있었다.

결국 핵심은, Kubernetes의 기본 무상태 특성을 유지하면서도 Lease와 Hazelcast 같은 오픈소스를 활용해 Pod 간 협력 구조를 얹으면, 실시간 처리와 캐시 성능을 함께 끌어올릴 수 있다는 점이다.