13장 카프카의 발전과 미래

13.1 주키퍼 없는 카프카의 미래

기존은 주키퍼에 대한 의존성이 높음
주키퍼는 매우 단순하고 안정적인 어플리케이션으로서 많은 분산 애플리케이션들의 코디네이터 역할을 함

 

 

13.1.1. 주키퍼 사용에 따른 제약사항

1. 컨슈머의 오프셋 저장소 전환
   
   • 카프카 2.0 이전 버전에서는 컨슈머 그룹의 저장소로 주키퍼의 지노드를 이용함
   • 메시지수 증가/오프셋 증가/컨슈머 증가 -> 카프카 0.10버전부터 카프카의 내부 토픽인 _consum_offsets로 이전하면서 의존선 제거
2. 각기 다른 애플리케이션 운영에 대한 부담
   1. 주키퍼와 카프카는 아파치에서도 완전히 별개의 프로젝트임 (추구하는 방향성도 다름)
   2. 각기 다른 API사용에 따른 부담 -> 개발생산성 저하로 이어짐
   3. 운영의 어려움
      • 습득해야하는 지식이 2배
      • 운영의 리소스가 2배 : 관리자 또는 운영자가 애플리케이션의 안정적인 모니터링을 위해 시스템을 구성하는 경우 따로따로 대응해야함
   4. 보안 문제 : 보안 또한, 따로따로 준비하고 서로 통신의 문제가 없는지 확인이 필요함
   5. • 주키퍼에는 카프카에서 사용하는 모든 메타데이터가 저장되어 있음
      • 주키퍼와 컨트롤러 같의 불일치 : 카프카와 주키퍼는 다른 어플리케이션이기 때문의 동기화 시간이 발생
      • 이때, 장애발생시 문제 발생메타데이터 관리 문제

13.1.2. 주키퍼 의존성을 제거한 카프카 업그레이드

주키퍼의 의존성 제거하는 방법 : 주키퍼에 저장해둔 메타데이터를 카프카로 이동시키는 것

• AS-IS : 주키퍼를 이용한 카프카 구성주키퍼를 통해 선정된 브로커 중 하나의 컨트롤러가 주키퍼와 통신을 담당하여, 메타데이터 업데이트 등 역할
• 컨트롤러는 이러한 메타데이터들을 나머지 브로커들에게 푸시

• TO-BE : 주키퍼의 역할을 대체하는 컨트롤러 3대
• 컨트롤러 노드에도 하나의 리더가 존재
• 컨트롤러가 PUSH하는 방식이 아니라 컨트롤러로부터 PULL방식으로 변경
• 8.2절의 주키퍼 의존성 카프카 롤링 업그레이드 참고하여 변경 가능

13.2 새로운 합의 프로토콜 : KRaft

• AS-IS : 주키퍼의 합의 프로토콜을 이용해 리플리케이션 커밋 처리, 리더 선출 동작을 처리
• TO-BE : 새로운 합의 프로토콜 필요 -> Raft 합의 프로토콜과 카프카의 특성을 추가한 KRaft 합의 프로토콜을 개발
• 래프트는 내부적 합의를 통해 정보를 유지 : 과반수 찬성 방식을 따르기 때문에 고장나도 안정적 서비스 가능
• 래프트의 리더 선출 과정 : 노드들 팔로워/후보자/리더 총3가지 상태(https://zetawiki.com/wiki/Raft_%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98)
  1. 처음 시작할때는 모든 노드 팔로워
  2. 노드들은 리더로부터 하트비트를 받아 활성 상태 체크, 타임아웃 시간동안 하트비트를 받지 못하면 팔로워 상태는 후보자로 바뀜 -> 다른 노드들에게 투표 요청
  3. 후보자 상태의 노드가 다른 노드들로부터 과반수 이상의 투표를 받으면 새로운 리더 노드로 변경
• 카프카는 오프셋, 에포크와 같은 용어 선호 / 래프트는 인덱스, 텀과 같은 용어 선호 -> 기본은 크래프트의 합의 알고리즘을 따르므로 큰 차이는 없음
• 크래프트모드는 주기적으로 스냅샷생성

13.3 최적화된 컨트롤러 노드 구성

• 클러스터 내 임의의 브로커 3개 선정/ 동일한 노드에서 브로커 프로세트와 컨트롤러 프로세스 실행
  -> 별도 서버가 필요하지 않으므로 서버 절약가능
• 클러스터 내 실행되는 브로커 노드와 컨트롤러 노드 분리 / 별도 서버 구성
  -> 장애시 안정성 확보, 각 노드에 할당된 리소스 단독으로 사용 가능

13.4 카프카의 미래가 담긴 KIP

• 카프카의 성장사~미래모습 : KIP (https://www.confluent.io/ko-kr/blog/tag/kip/)
• KIP-500 : 주키퍼 의존성 제거
  • KIP-595 : 래프트 프로토콜 관련
  • KIP-631 : 컨트롤러의 쿼럼
  • 등과 긴밀히 연결되어 있음
• KIP-405 : 계층형 스토리지
  • 최신 데이터는 고성능 디스크에 보관하고, 오래된 데이터는 값이 저렴한 디스크에 보관하는 개념

 

13.5 정리

• 2021년 4월 19일 2.8버전에서 처음으로 주키퍼 없이 컨트롤러 쿼럼노드를 적용할 수 있게 됨
  쿼럼 구성 시 200만개의 파티션 향상 / 제어되지 않은 셧다운을 실행했을 떄는 주키퍼 대비 약 16배가량의 성능향상
• 동물원을 탈출한 카프카 — Zookeeper-less Kafka
  https://psm1782.medium.com/%EB%8F%99%EB%AC%BC%EC%9B%90%EC%9D%84-%ED%83%88%EC%B6%9C%ED%95%9C-%EC%B9%B4%ED%94%84%EC%B9%B4-zookeeper-less-kafka-a71cba58d5d9
• https://www.ciokorea.com/news/235594

주키퍼 지원이 정확히 언제 중단될지는 발표되지 않았다. 현재는 카프카 3.3 릴리즈에서 크라프트를 GA 버전으로 제공하고, 카프카 4.0에서 주키퍼를 제거할 계획이다. 오는 8월에 출시될 카프카 3.3에는 주키퍼와 크라프트 옵션이 모두 포함된다. 맥케이브는 “크라프트 모드가 곧 프로덕션으로 전환될 예정이다. 이는 해당 프로젝트의 큰 발전일 것”이라고 전했다. 

크라프트 모드는 지난 2021년 4월 릴리즈된 카프카 2.8부터 사용할 수 있었지만 프로덕션 준비 상태는 아니었다. 이는 카프카 3.3에서 프로덕션 준비 릴리즈로 제공될 예정이다. 맥케이브는 “주키퍼를 사용해왔던 개발자의 학습 곡선이 가파르지는 않을 것”이라면서, “개발자를 위해 동일한 API가 지원된다. 운영자는 몇 가지 학습해야 할 것이 있을 수 있다. 새로운 관리자가 이를 더 쉽게 찾을 수 있고, 기존 관리자가 관리하기 쉽게 전환할 수 있을 것”이라고 설명했다. 

컨플루언트와 카프카의 공동 창립자 준 라오는 “주키퍼 지원 중단을 카프카 커뮤니티의 중요한 움직임으로 보고 있다”라면서, “메타데이터를 더 효율적으로 처리하기 때문에 배포 및 운영이 훨씬 간단해지고 확장성이 10배 확장된다. 커뮤니티와 이 작업을 함께 하게 돼 기쁘다”라고 말했다. 

한편 아파치 소프트웨어 재단(Apache Software Foundation)에 따르면 포춘 100대 기업 중 80% 이상이 카프카를 사용하고 있다. 아파치 카프카 웹사이트에서 액세스할 수 있는 카프카는 고성능 TCP 프로토콜을 통해 통신하는 클라이언트와 서버로 구성된 분산 시스템이며, 가상머신, 베어메탈 하드웨어, 컨테이너, 온프레미스 또는 클라우드 환경에 배포된다. ciokr@idg.co.kr

원문보기:
https://www.ciokorea.com/news/235594#csidxa92ee6f4efcfc04b60acbc9fe1983ef