클라우드 환경에서의 Kafka 운영기 #우아콘2022 #Day2_음식그이상의것을문앞으로

장비 이슈는 네트워크 연결 끊김일 수도, 물리 장비 문제일 수도 있으며 발생을 예상하기도 영향 범위를 추적하기도 어렵다. 브로커가 중단되면 다른 작업이 멈추고, 메시지 유실 등 클라이언트 영향 확인, 원인 파악, 안정성 유지 후속 작업까지 필요하다. 인스턴스가 언제 죽을지 모르는 클라우드와 이슈 시 상태를 일일이 관리해야 하는 카프카의 특성이 겹쳐 운영이 결코 쉽지 않다.

발표자는 이를 "지뢰밭"에 빗댄다. 우아한형제들의 카프카 규모는 (그해 8월 기준) 클러스터 27개, 브로커 169대, 파티션 약 2만 4천 개로, 메시지는 초당 평균 50만 건, 최대 140만 건 유입된다. 메시지 플랫폼·라이더 배차·데이터 플랫폼 등에 쓰이며, 운영 브로커는 2020년 12월 41대에서 그해 8월 162대까지 늘었다. 관리할 인스턴스가 늘면 이슈도 늘어, 늘어나는 클러스터를 안정적·효율적으로 운영하는 것이 핵심 과제다.

운영 중 겪은 이슈와 개선 세 가지 중 첫째는 "단일 주키퍼 클러스터"다. 초기 카프카 클러스터는 MSA 환경에 따라 서비스별로 만들어졌지만, 도입 초기에는 모두 하나의 주키퍼에 함께 물려 있었다. 당시엔 주키퍼 부하가 적고 확장 규모를 가늠하기 어려워 내린 결정이었다.

그러나 클러스터가 늘수록 이 하나의 주키퍼에 대한 의존도가 높아져, 여러 서비스 마비를 초래할 수 있는 단일 장애 지점(SPOF)이 되었다. 이를 없애기 위해 서비스별 카프카 클러스터에 주키퍼까지 개별로 두는 격리된 클러스터를 구성해, 단일 주키퍼의 영향도를 낮추고 이슈를 서비스별로 격리할 수 있게 했다.

둘째 이슈는 "업데이트가 어려워"다. 카프카는 설정 수정·보안 패치 등으로 업데이트가 필요한데, 대표적 방법인 롤링 업데이트(브로커를 하나씩 껐다 켜기)는 브로커가 10대, 50대, 200대로 늘면 하루 안에 끝내기 어렵다. 내렸다 올리는 대상이 동작 중인 브로커라, 올라온 브로커의 ISR이 갖춰졌는지·클라이언트 이슈는 없는지를 일일이 확인해야 한다. 클라우드까지 더하면 min.insync.replicas를 높여 둔 상태에서 롤링 중 다른 인스턴스 실패가 겹치면 일부 파티션이 오프라인이 되어 다운타임이 발생할 수 있다.

그래서 더 쉬운 업데이트 환경을 구성했다. 브로커 ID 기준으로 논리적 "스택"을 구성하고, 기존 브로커 수만큼 업데이트된 새 브로커를 추가한 뒤 레플리카를 옮기고 기존 브로커를 제거해 결국 업데이트된 브로커만 남긴다. 리소스 추가가 자유로운 클라우드 이점 덕에 가능했으며, 트래픽 받는 프로세스를 종료하지 않아 안정적이고 브로커가 많을수록 더 쉬워지며 운영자 판단이 적어 이벤트 기반 자동화도 기대한다.

셋째 이슈는 카프카 스트림즈의 상태 깨짐이다. 스트림즈는 집계 정보를 로컬 DB와 클러스터 토픽으로 저장하는데, 토픽 상태 반영 과정에서 실패하면 상태가 깨질 수 있다. 이 이슈가 클라우드와 연결되는 이유는 다소 불안정한 네트워크가 대표 원인이기 때문이다. 실제로 특정 브로커와 주키퍼의 통신이 일시 불안정해 주키퍼 세션이 만료되며 브로커가 클러스터에서 제외됐고, 라이더 수 집계가 정상 반영되지 못해 특정 권역의 라이더 수가 음수(-)가 되는 현상까지 나타났다.

복구는 카프카가 함께 제공하는 "스트림즈 애플리케이션 리셋 스크립트"를 활용한다. 관련 스트림즈 앱을 중지하고, 컨슈머 처리 시점을 깨진 상태 이전으로 옮긴 뒤(상태 토픽 초기화 가능) 그 시점부터 다시 실행해 상태를 복구한다. 다만 앱을 중단·재실행해야 해 공수가 크고 더 효율적인 방법을 고민 중이다. 이 밖에 클러스터 간 토픽 미러링, 부하가 다른 파티션의 자동 관리 등 규모 확장에 따른 고민도 해결해 나간다고 덧붙인다. 마지막으로, 이슈를 예상·추적하기 어려운 클라우드는 카프카 운영자에게 쉽지 않은 환경이지만 신뢰성 있는 카프카를 제공하도록 지속 개선하고 있다는 말로 마무리한다.