클라우드 환경에서의 Kafka 운영기

https://www.youtube.com/watch?v=XyuqoWUCdGA 

클라우드 플랫폼 개발팀의 김대호 님의 영상을 요약한 내용입니다.

 

카프카의 특징

카프카는 토픽에 메시지를 발행(Publish) 및 구독(Subscribe) 구조

토픽은 병렬 처리를 위해 파티션 단위로 구성되어 있습니다.

파티션은 안정성을 위해 레플리카로 복제 구성되어 있습니다.

 

카프카는 상태 기반 시스템입니다.

발행되는 메시지는 브로커의 파일 시스템에 저장됩니다.

브로커가 토픽 파티션의 메시지를 저장하고 있다 => 

브로커가 토픽 파티션의 레플리카를 가지고 있다 =>

브로커가 토픽 파티션의 상태를 가지고 있다로 귀결됩니다.

 

하지만 카프카는 상태를 자동으로 옮기지 않습니다.

브로커가 가지고 있는 레플리카를 다른 브로코로 임의로 옮기지 않기 때문에 운영자가 상태를 관리해주어야 합니다.

그림 1

예를 들어 [그림 1]처럼 Broker 2를 더 이상 사용할 수 없는 경우게 자동으로 1,3번 레플리카가 옮겨지지 않습니다.

추후에 운영자가 레플리카를 재조정해주어야 합니다.

 

 

클라우드 환경의 특징

- 필요한 리소스를 원하는 만큼 구성하기 쉽습니다.

- 하지만 인프라 이슈에 대해 추적 예측하기 어렵습니다.

 

실제 이슈 사례

- 현상 : 특정 브로커의 갑작스러운 종료로 일시적인 성능 저하

- 원인 : EC2 하드웨어 이슈(네트워크 연결 끊김, 물리적 호스트의 소프트웨어/하드웨어 문제)

 

클라우드 환경 + 카프카

운영자 입장에서 브로커가 죽으면 모든 작업이 ALL STOP 됩니다.

이슈 원인을 파악해야 하며, 안정성을 위해 후속 작업등을 수행해야 합니다.

 

이슈가 언제 발생하지 않는 클라우드 환경과 이슈가 발생하면 상태를 관리해주어야 하는 카프카는 과장해서 말하자면 지뢰밭 같은 느낌입니다.

 

우아한형제들의 카프카 클러스터 규모

- 카프카 클러스터 27개

- 브로커 162대

- 파티션 약 24,000개

- 초당 평균 50만 건, 최대 140만 건 메시지 유입

- 메시지 플랫폼, 라이더 배차 시스템, 데이터 플랫폼 서비스에서 사용 중

- 카프카 클러스터는 지속적으로 생성 중! (20.12 에는 41대 22.08 에는 162대로 증가)

 

점점 커지는 규모로 인한 고민

관리하는 인스턴스 수가 늘어날수록 이슈의 발생 빈도가 증가할 것입니다.

클라우드 환경에서는 이런 이슈의 발생 빈도를 더 증가시킬 수 있습니다.

 

어떻게 안정적이고 효율적으로 운영할 수 있을까?

운영 중 겪었던 이슈와 개선 사례를 만나보겠습니다.

 

이슈 1 : 단일 주키퍼 클러스터

사내 서비스들은 MSA 기반으로 개별적으로 구성되었습니다.

하지만 카프카 도입 초기에 하나의 Zookeeper에 몰려서 사용했습니다.(주키퍼 자체의 컴퓨팅 부하도 낮고, 클러스터도 몇 개 안 되니까)

 

하지만 클러스터가 늘어날수록 의존도가 높아지고 주키퍼 인스턴스에 이슈가 생긴다면 전체 서비스가 마비됩니다.

 

이를 개선하기 위해 주키퍼: 카프카 = 1:1 구조로 변경하여 제공했습니다.

 

이슈 2 : 어려운 업데이트

다양한 상황에서 필요한 카프카 업데이트가 필요합니다.

- Read-only 설정 업데이트

- 보안 패치를 위한 업데이트

 

가장 대표적으로 롤링 업데이트를 수행합니다.

하지만 브로커가 많아질수록 롤링 업데이트가 어려워집니다.

 

동작하고 있는 브로커를 실제로 내려야 하기 때문에 여러 부담이 발생합니다.

- 복제는 잘 되었는지

- 클라이언트 쪽 이슈는 없는지

 

여기에 클라우드 환경에서 이슈가 발생하는 경우 일부 파티션이 오프라인 됩니다.

 

이를 개선하기 위해 브로커 ID를 기준으로 논리적인 스택을 구성하였습니다.

이를 기준으로 업데이트된 신규 브로커를 추가하고, 기존 브로커를 제거하는 방식으로 활용하였습니다.

1 ~ 1000: Blue

1001 ~ 2000: Green

 

리소스 추가가 자유로운 클라우드 환경의 이점을 잘 활용한 사례입니다.

 

이슈 3.  카프카 스트림즈의 상태 깨짐

카프카 스트림즈는 스트리밍 집계를 위해 사용됩니다.

상태 정보를 로컬과 토픽에 저장하는데 다양한 원인으로 상태 깨짐이 발생할 수 있습니다.

- 브로커의 갑자스러운 종료

- 클라이언트 네트워크 이슈

 

실제 이슈로 권역 내의 라이더가 -2로 표기되는 상황이 발생하였습니다.

브로커 세션 만료로 인한 갑작스러운 탈락이 발생했으며 스트림즈가 상태 반영을 제대로 하지 못한 사례입니다.

 

상태 복구 툴을 활용하여 개선하고자 했습니다.

카프카 스트림즈 애플리케이션 reset 스크립트를 이용하여 복구합니다.

 

하지만 스트림즈 앱을 중지해야 하기 때문에 효율적인 방법을 위해 지속적인 고민 중입니다.