카프카 운영 레퍼런스: 우아콘

카프카를 운영하면서, 다른 회사들은 카프카를 어떻게 사용하고 있을까? 또 어떤 고민이 있을까? 궁금해서 찾아 보다가 우아콘에서 발표한 좋은 영상을 찾아서 내용을 정리하고 공유한다.

카프카 우아콘 세미나 다시 보기

우아한 형제들의 카프카 환경?

• 퍼블릭 클라우드

카프카 클러스터 규모(2022.8월 운영기 기준)

• 카프카 클러스터 27대
• 브로커 162대
• 파티션 약 24,000개
• 초당 평균 50만건, 최대 140만건 메세지 유입
• 지금도 점점 늘어나는 추세
  • 20.12월 기준 브로커 41대 --> 22.8월 기준 162대
• 카프카는 메세지 플랫폼, 라이더 배차 시스템, 데이터 플랫폼 등 핵심 기능에 이용 중

퍼블릭 클라우드의 문제점

• 물리 장비에 언제 어떤 작업이 있어서 브로커가 갑자기 종료할지 모른다.
• 실제로 원인: EC2 underlying hardware이슈로 클러스터의 일시적인 성늘 저하를 경험 했었음.
• 브로커가 죽으면 모든 작업이 스탑 되고 운영자는 클라이언트쪽 영향도 확인 (ex. 메세지 유실), 이슈 원인 파악, 안정성을 위해서 레플리카를 옴기는 등 해야 하는것이 많다.

운영중 겪었던 이슈와 개선 사항

단일 주키퍼 클러스터

• 사내 서비스들은 MSA 기반으로 개별적으로 구성됨
• 카프카 클러스터도 각 서비스 별로 구성
• 도입 초기엔 주키퍼의 컴퓨팅 부하도 낮고 클러스터가 몇개 안되기 때문에 하나의 주키퍼 클러스터에 여러 카프카 클러스터를 구성
• 점점 주키퍼에 등록되는 카프카 클러스터가 증가되어 주키퍼 클러스터 이슈의 영향도가 증가 됨
• 주키퍼가 문제가 생기면 전체 서비스 문제가 되는 상황을 해결하기 위해서 격리된 클러스터를 각각 구성하여 해결

업데이트가 어려워

• 카프카 업데이트는 Read-only 설정, 보안 패치 등 다양한 이유로 필요하다.
• 보통 롤릴 업데이트를 하는데, 관리할 서비스가 많아지면 롤링 업데이트가 너무 오래 걸린다.
• 또한, 동작하고 있는 브로커를 내려야 하는건 큰 부담이다. 데이터 복제, 다음 액션 가능 여부, 클라이언트 이슈를 모두 확인해야기 때문이다.
• 이를 해결하기 위해서 카프카 클러스터 내에 논리적인 스택을 구성
• 1~1000: Blue
• 1001~2000: Green
  업데이트된 신규 브로커를 추가하고, 기존 브로커를 제거하는 방식
  리소스 추가가 자유로운 클라우드 환경의 이점을 활용
• 이런 방식은 트래픽이 있는 프로세스를 종료하지 않는 안정적인 업데이트 방법.

카프카 스트림즈의 상태 깨짐

• 스트리밍 집계를 위해서 사용되는데 스트림즈는 상태 정보를 로컬과 토픽에 저장한다. 그러다 보니 브로커의 갑작스러운 종료나 클라이언트 네트워크 이슈 등으로 상태 깨짐 발생
• 이를 해결하기 위해서 카프카 내에 상태 복구를 위한 툴 활용
• kafka-streams-application-reset.sh 스크립트를 이용한 복구
• 특정 시점부터 스트림즈 애플리케이션을 Replay

그 밖에 다양한 운영적 고민

• 토픽 메세지를 다른 클러스터로 쉽게 옴기는 방법
• 클러스터 별 인증된 사용자만 접근 시키고 싶음
• 파티션의 위치 자동 관리
• 컨슈머가 어느팀에서 구성된걸까?
• 토픽 스키마 중앙관리 방법
• 사용자들이 리소스를 관리하기 쉬운 방법