Skip to content

Latest commit

 

History

History
122 lines (110 loc) · 6.42 KB

2022_WOOWACON_Kafka.md

File metadata and controls

122 lines (110 loc) · 6.42 KB

2022_WOOWACON_Kafka




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

카프카와 클라우드 환경의 특징

카프카의 특징

  • 카프카는 토픽에 메시지를 발행(Publish) 및 구독(Subscribe) 구조
    • 토픽은 병렬 처리를 위해 파티션 단위로 구성
    • 파티션은 안정성을 위해 레플리카로 복제 구성
      • 이는 서로 다른 브로커에 퍼져서 존재함
  • 상태 기반 시스템
    • 발행되는 메시지는 브로커의 파일 시스템에 저장
      • 토픽 파티션 별 로그 세그먼트에 메시지가 저장
    • 브로커가 토픽 파티션의 메시지를 저장하고 있다.
      • = 브로커가 토픽 파티션의 레플리카를 가지고 있다.
      • = 브로커가 토픽 파티션의 상태를 가지고 있다.
    • 하지만, 상태를 자동으로 옮기지 않는다.
      • 운영자가 상태를 관리해줘야한다. (브로커가 하나 고장나더라도 자동으로 변경되지 않음)

클라우드 환경의 특징

  • 필요한 리소스를 원하는 만큼 구성하기 쉽다.
  • 하지만! 추적/예상하기 어려운 인프라 이슈
    • 내부적으로 진행되는 인프라 작업에 의한 영향
    • 물리적인 장비 이슈
  • 이슈 사례
    • 현상: 특정 브로커의 갑작스러운 종료 → 클러스터의 일시적인 성능 저하
    • 원인: EC2 underlying hardware 이슈 (네트워크 연결 끊김, 리적 호스트의 소프트웨어/하드웨어 문제)
  • 운영자 입장
    • 브로커가 죽으면 모든 작업 ALL STOP
    • 클라이언트 쪽 영향도 확인
    • 이슈 원인 파악
    • 안정성을 위해 레플리카를 옮겨주기 등 후속 작업

우아한형제들의 카프카

  • 카프카 클러스터 규모 (2022.08 기준)
    • 카프카 클러스터 27개
    • 브로커 162대
    • 파티션 약 24,000개
    • 초당 평균 50만건, 최대 140만건 메시지 유입
  • 서비스
    • 메시지 플랫폼
    • 라이더 배차 시스템
    • 데이터 플랫폼
  • 점점 커지는 규모로 인한 고민
    • 카프카의 안정성이 입증되며, 계속해서 늘어날 예정
    • 인스턴스 수가 늘어날수록 이슈의 발생 빈도는 증가할 것
    • 클라우드 환경은 이러한 이슈 빈도를 더 높일 수 있음

운영 중 겪었던 이슈와 개선

  • 안정적이고, 효율적으로 운영하기 위해 지속적인 노력

1. 단일 주키퍼 클러스터

  • 초기 카프카 클러스터 구성
    • 사내 서비스들은 MSA 기반으로 개별적으로 구성됨
    • 카프카 클러스터도 각 서비스 별로 구성
    • 도입 초기엔 하나의 주키퍼 클러스터에 여러 카프카 클러스터를 구성
      • 주키퍼 자체의 컴퓨팅 부하도 낮고, 아직 클러스터가 몇 개 안되기 때문
  • 클러스터가 점점 늘어날수록 의존도가 증가
    • 점점 주키퍼에 등록되는 카프카 클러스터가 증가
      • 주키퍼 클러스터 이슈의 영향도가 증가하기 시작
    • 만약, 주키퍼 인스턴스에 이슈가 생긴다면 전체 서비스 마비! (SPOF. Single Point of Failure)
  • 개선. 격리된 클러스터 구성
    • 주키퍼 : 카프카 = 1 : 1 구조로 변경하여 제공
    • 서비스 별 격리된 환경으로 구성

2. 업데이트가 어려움

  • 다양한 상황에서 필요한 카프카 업데이트
    • Read-only 설정, 보안 패치를 위한 업데이트
    • 가장 대표적인 카프카 업데이트 방법 > 롤링 업데이트(클러스터를 하나씩 껐다 키며 업데이트)
  • 롤링 업데이트의 한계
    • 동작하고 있는 브로커를 내려야하는 부담감
      • 복제는 잘 되었나?
      • 브로커 중단 중에 클라이언트 쪽 이슈는 없나?
    • 클라우드 환경
      • 언제 인스턴스 실패가 발생할지 모르는 클라우드 환경
      • 롤링 업데이트 중 다른 인스턴스에 이슈가 생긴다면..?
        • 일시적인 다운타임 발생 가능!
  • 개선. 카프카 클러스터 내에 논리적인 스택 구성
    • 브로커 ID를 기준으로 논리적인 스택 구성
      • 1~1000 : Blue
      • 1001~2000 : Green
    • 업데이트된 신규 브로커를 추가하고, 기존 브로커를 제거하는 방식
      • 리소스 추가가 자유로운 클라우드 환경의 이점을 활용!
  • 방식
    1. 신규 브로커를 기존 브로커 수에 맞게 클러스터에 추가한다.
    2. 기존 브로커에서 신규 브로커로 파티션을 옮긴다.
    3. 상태의 이동
    4. 기존 브로커들을 제거한다.
  • 장점
    • 카프카 클러스터 내에 논리적인 스택 구성
    • 트래픽이 있는 프로세스를 종료하지 않는 안정적인 업데이트 방법
    • 브로커가 많아질수록 더 쉽고 간단해지는 방법
    • 이벤트를 기반으로 하는 자동화를 구성할 수 있지 않을까? 하는 기대
      • 신규 브로커 프로비저닝 완료 > 파티션 이동 > 기존 브로커 제거

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

  • 카프카 스트림즈의 상태 관리
    • 스트리밍 집계를 위해 사용
    • 카프카 스트림즈는 상태 정보를 로컬과 토픽에 저장
    • 그렇다보니 다양한 원인으로 상태 깨짐을 발생시킬 수 있다.
      • 브로커의 갑작스러운 종료
      • 클라이언트 네트워크 이슈
  • 사례
    • 라이더 현황 집계 값이 음수가 나오는 현상
    • 브로커 세션 만료로 인한 갑작스러운 탈락 발생
      • 스트림즈가 상태 반영을 제대로 하지 못함
  • 개선. 상태 복구 툴 활용
    • kafka-streams-application-reset.sh 스크립트를 이용한 복구
    • 특정 시점부터 스트림즈 애플리케이션을 Replay
    • 스트림즈앱을 중단하고, 실행해야하기에 상당한 공수가 필요함