[Kafka] 아파치 카프카 알아보기(3) - 카프카 소개

카프카는 대용량, 대규모 메시지 데이터를 빠르게 처리하도록 개발된 메시징 플랫폼이다. 서비스를 유지하려면 기본적으로 다음과 같은 데이터 시스템이 필요하다.

시스템	설명
메트릭 모니터링용 데이터 시스템	앱이나 서비스에서 일어나는 미터링(사용량, 응답 시간, 에러 카운트 등) 정도를 저장할 시계열 데이터 처리용 시스템
로그 모니터링용 데이터 시스템	앱/서비스에서 발생하는 로그를 저장하고, 이것을 기반으로 실시간/배치로 분석할 수 있도록 데이터를 저장하는 시스템
서비스에 필요한 컨텐츠와 고객 정보 데이터들을 저장하는 메인 데이터 시스템	대부분의 앱들에서 보낸 OLT(Online Transaction Process) 쿼리(주로 데이터 갱신)를 실행한다.
추천이나 장바구니와 같이 트랜잭션 처리까진 필요없지만 실시간으로 처리를 해줘야하는 내용을 저장하는 키/값 저장소	앱이나 사용자는 HTTP 프로토콜이나 OLTP 쿼리를 실행한다.
서비스와 제품군 전체에서 발생하는 데이터를 모아서 일간/주간/월간/연간 데이터를 제공하는 데이터 마켓이나 이것을 활용해 배치 분석을 하는 데이터 웨어하우스	각종 데이터 시스템에서 이곳으로 데이터를 보낸다.
빅데이터를 저장/처리하기 위한 하둡 시스템.	빅데이터를 처리해서 데이터 웨어하우스에 보낸다. 이런 작업을 ETL(Extract, Transform, Load의 줄임말) 작업이라고 한다.

실제 엔드투엔드 연결 방식의 아키텍처는 많은 문제점이 있다.

 

첫째로 실시간 트랜잭션(OLTP) 처리와 비동기 처리가 동시에 이뤄지지만 통합된 전송 영역이 없으니 복잡도가 증가할 수 밖에 없다. 이 때문에 문제를 발견하고 조치를 취하려면 이와 관련된 여러 데이터 시스템을 확인해야 한다.

 

두번째로 데이터 파이프라인 관리의 여러움이다. 실시간 트랜잭션 데이터베이스, 아파치 하둡, 모니터링 시스템, 키-값 저장소 등 많은 데이터 시스템들이 있는데, 이 시스템에 저장된 동일한 데이터를 개발자나 개발 부서는 각기 다른 방법으로 파이프라인을 만들고 유지하게 되었다. 처음에는 각자의 목적에 맞게 만들어서 간편했지만, 시간이 지나게되면 이 데이터 파이프라인들은 통합 데이터분석을 위해 서로 연결되어야 하는 일들이 필연적으로 발생하게 된다. 하지만 각 파이프라인별로 데이터 포맷과 처리하는 방법들이 완전히 달라서 데이터 파이프라인은 확장하기 어렵게되고, 이러한 데이터 파이프라인들을 조정하고 운영하는 것은 엄청난 노력이 필요하게 된다. 게다가 복잡성으로 인해 두 시스템 간의 데이터가 서로 달라져 데이터의 신뢰도마저 낮아질 수 있다.

 

모든 시스템으로 데이터를 전송할 수 있고, 실시간 처리도 가능하며, 확장이 용이한 시스템을 위해 만들어진것이 카프카이고, 다음과 같은 목표를 가지고 새로운 시스템을 만들었다.

  - 프로듀서와 컨슈머의 분리

  - 메시징 시스템과 같이 영구 메시지 데이터를 여러 컨슈머에게 허용

  - 높은 처리량을 위한 메시지 최적화

  - 데이터가 증가함에 따라 스케일아웃이 가능한 시스템

 

결국 이러한 모든 문제를 해결할 수 있는 새로운 애플리케이션을 개발하기로 결정한 링크드인에서 새로운 데이터 처리 시스템을 구축하게 되었다.

 

사내에서 발생하는 모든 이벤트/데이터의 흐름을 중앙에서 관리하는 카프카를 적용함으로써, 서비스 아키텍처가 매우 깔끔해졌다. 카프카가 전사 데이터 파이프라인으로 동작하기 때문에 모든 데이터 스토어와 발생하는 데이터/이벤트가 카프카를 중심으로 연결되어 있다. 기존 데이터 스토어 뿐만 아니라, 새로운 데이터 스토어가 들어와도 서로 카프카가 제공하는 표준 포맷으로 연결되어 있어서 데이터를 주고받는데 부담이 없게 된다. 그래서 더욱 상세하고 다양한 데이터를 분석하여 좋은 서비스를 제공할 수 있게 된다.

 

개발 입장에서도 이전에는 데이터 스토어 백엔드 관리와 백엔드에 따른 포맷, 별도의 앱개발을 해야 했는데 이젠 카프카에만 데이터를 전달하면 나머지는 필요한 곳 또는 다른 서비스들이 각자 가져갈 수 있어서 자신들 본연의 업무에만 집중할 수 있게 되었다.

 

이와 같이 새로운 데이터 처리 시스템에서는, 링크드인 사용자가 프로필을 업데이트하면 이 정보가 바로 카프카로 전달된다. 이 정보를 실시간 스트림으로 처리해서 데이터 웨어하우스에 저장된 회사 정보, 위치, 기타 속성들을 변경한다. 그리고 카프카에서 이 데이터의 변경사항을 모니터링하고 있던 검색 인덱스 시스템, 소셜 그래프 시스템, 직업 추천을 위한 추천 시스템으로 이동해 처리된다. 이 모든 작업들은 불과 몇 밀리초 단위로 처리된다.

 

2010년 카프카의 도입과 함께 링크드인은 놀랄만한 규모로 성장했고, 약 1조개 이상의 메시지를 하루에 처리하고 있다. 카프카를 메시지 전달의 중앙 플랫폼으로 두고 기업에서 필요한 모든 데이터 시스템(오라클과 같은 실시간 트랜잭션, NoSQL류의 키-값 스토어, 실시간 분석 시스템, 스트림 처리 시스템, 하둡, 데이터 웨어하우스)뿐만 아니라 마이크로서비스, SaaS 서비스 등과 연결된 파이프라인을 만드는 것을 목표로 개발되었다.

중앙에 메시징 시스템 서버를 두고 이렇게 메시지를 보내고 받는 형태의 통신을 Pub/Sub 모델이라고 한다. Pub/Sub은 비동기 메시징 전송 방식으로서, 발신자의 메시지에는 수신자가 정해져 있지 않은 상태로 발행합니다. 구독을 신청한 수신자만이 정해진 메시지를 받을 수 있다. 또한 수신자는 발신자 정보가 없어도 원하는 메시지만을 수신할 수 있다. 이러한 구조 덕분에 다이나믹한 네트워크 토폴로지와 높은 확장성을 확보할 수 있다.

 

일반적 형태의 통신의 경우 통신에 참여하는 개체가 많아질수록 서로 일일이 다 연결을 해야 하고 데이터를 전송해야하기 때문에 확장성이 좋지 않다. 프로듀서가 메시지를 컨슈머에게 직접 전달하는게 아니라 중간의 메시징 시스템에 전달한다. 컨슈머는 자신들의 큐를 모니터링하고 있다가, 큐에 메시지가 전달되면 이 값을 가져간다. 이렇게 구성할 경우 개체가 하나 빠지거나 수신 불능상태가 되었을때에도 메시징 시스템만 살아있으면 프로듀서에서 잔달된 메시지가 유실되지 않을 수 있다. 각각의 개체가 다대다(N:N) 통신을 하는 것이 아니라 메시징 시스템을 중심으로 연결되기 때문에 확장성이 용이하다. 그리고 사용자나 어드민이 연결을 직접 관장하는 것이 아니라, 교환기의 룰에 의해서 데이터가 수신처의 큐에 정확하게 전달되므로 메시지 데이터 유실의 염려가 없다. 다만, Pub/Sub의 단점은 직접 통신을 하지 않기 때문에 메시지가 정확하게 전달되었는지 확인하려면 코드가 좀더 복잡해지고, 중간에 메시징 시스템이 있기 때문에 메시지 전달 속도가 빠르지 않다는 점이다.

 

기존 메시징 시스템을 사용하는 Pub/Sub 모델은 대규모 데이터(데이터 단건당 수MB 이상)를 메시징 시스템을 통해 전달하기보다는 간단한 이벤트(수KB 정도의 크기)를 서로 전송하는데 주로 사용되었다. 왜냐하면 메시징 시스템 내부의 교환기의 부하, 각 컨슈머들의 큐 관리, 큐에 전달되고 가져가는 메시지의 정합성, 전달결과를 전확하게 관리하기 위한 내부 프로세스가 아주 다양하고 복잡했기 때문이다. 즉 기존의 메시징 시스템은 메시지의 보관, 교환, 전달 과정에서 신뢰성을 보장하는 것에 중점을 맞췄기 때문에 속도와 용량을 그렇게 중요하지 않았다. 

 

카프카는 메시징 시스템이 지닌 성능의 단점을 극복하기 위해, 메시지 교환 전달의 신뢰성 관리를 프로듀서와 컨슈머 쪽에 넘기고, 부하가 많이 걸리는 교환기 기능 역시 컨슈머가 만들 수 있게 함으로써 메시징 시스템 내에서의 작업량을 줄이고, 절약한 작업량을 메시징 전달 성능에 집중시켜서 고성능 메시징 시스템을 만들어 냈다.

 

카프카 역시 기존 메시징 시스템과 동일한 비동기 시스템이다. 프로듀서는 컨슈머와 관계없이 새로운 메시지를 카프카로 전송하고, 컨슈머 역시 프로듀서와 관계없이 카프카에서 새로운 메시지를 가져온다. 이렇게 프로듀서와 컨슈머는 각자의 역할이 정확이 구분되어 있다. 카프카에도 수많은 메시지들이 저장되고, 그 메시지들은 토픽이라는 식별자를 이용해 토픽 단위로 저장되고 있다.

 

이처럼 비동기 기반으로 메시지를 전달하는 대표적인 솔루션이 메시지 큐 솔루션이다. 카프카를 사용하지 않고 래빗엠큐 같은 메시지 큐 솔루션을 사용해도 이와 같은 비동기 메시지 전송 시스템을 구성할 수 있다.

특징1) 프로듀서와 컨슈머의 분리

링크드인에서는 메트릭 수집 방식으로 폴링 방식으로 구현된 시스템을 사용했고, 메트릭 수집이 늦어지는 경우가 발생하면서 수집이나 처리 시간이 너무 늦어지는 문제점이 발견되었다. 링크드인 개발자들은 이에 대한 해결방법으로 데이터를 보내는 역할과 받는 역할을 완벽하게 분리했다.

 

각각의 서비스 서버들은 모니터링이나 분석 시스템의 상태 유무와 관계없이 카프카로 메시지를 보내는 역할만 하면 되고, 마찬가지로 모니터링이나 분석 시스템들도 서비스 서버들의 상태 유무와 관계없이 카프카에 저장되어 있는 메시지만 가져오면 된다. 이렇게 각자의 역할이 완벽하게 분리되면서, 어느 한쪽 시스템에서 문제가 발생하더라도 연쇄작용이 발생할 확률은 매우 낮다. 또한 웹서버가 추가되더라도 카프카로만 보내면되기 때문에 서버 추가에 대한 부담도 줄일수 있는 장점이 있다.

 

특징2) 멀티 프로듀서, 멀티 컨슈머

카프카는 하나의 토픽에 여러 프로듀서 또는 컨슈머들이 접근 가능한 구조로 되어있다. 하나의 프로듀서가 하나의 토픽에만 메시지를 보내는 것이 아니라, 하나 또는 하나 이상의 토픽으로 메시지를 보낼 수 있다. 컨슈머도 하나의 토픽에서만 메시지를 가져오는 것이 아니라, 하나 또는 하나 이상의 토픽으로부터 메시지를 가져올 수 있다. 이러한 멀티 긴으은 데이터 분석 및 처리 프로세스에서 하나의 데이터를 다양한 용도로 사용하는 요구가 많아지기 시작했고, 이러한 요구 사항들을 손쉽게 충족할 수 있다.

 

특징3) 디스크에 메시지 저장

카프카는 기존의 메시징 시스템과 가장 다른 특징 중 하나는 바로 디스크에 메시지를 저장하고 유지하는 것이다. 일반적인 메시징 시스템들은 컨슈머가 메시지를 읽어가면 큐에서 바로 메시지를 삭제한다. 하지만 카프카는 컨슈머가 메시지를 읽어가더라도 정해져 있는 보관 주기 동안 디스크에 메시지를 저장해둔다. 트래픽이 일시적으로 폭주해 컨슈머의 처리가 늦어지더라도 카프카의 디스크에 안전하게 보관되어 있기 때문에, 컨슈머는 메시지 손실 없이 메시지를 가져갈 수 있다. 멀티 컨슈머도 카프카에 메시지들이 디스크로 저장되어 있기 때문에 가능한 것이다. 또 컨슈머에 버그가 있어 오류가 발생했다면, 컨슈머를 잠시 중단하고 버그를 찾아 해결한 후 컨슈머를 다시 실행할 수 있다. 이러한 방법으로 작업하더라도 메시지가 디스크에 저장되어 있기 때문에 메시지 손실없이 작업이 가능하다.

 

특징4) 확장성

카프카는 확장이 매우 용이하도록 설계되어 있다. 하나의 카프카 클러스터는 3개의 브로커로 시작해 수십대의 브로커로 확장 가능하다. 확장 작업은 카프카 서비스의 중단없이 온라인 상태에서 작업이 가능하다. 최초 카프카 클러스터 구성시 적은 수로 시작하더라도 이후 트래픽 및 사용량 증가로 클러스터를 확장하는 작업은 매우 간단할 뿐마 ㄴ아니라, 큰 부담없이 할 수 있다.

 

특징5) 높은 성능

카프카는 매우 높은 성능을 목표로 탄생한 애플리케이션이다. 고성능을 유지하기 위해 카프카는 내부적으로 분산처리, 배치처리 등 다양한 기법을 사용하고 있다.

 

카프카 용어	설명
카프카(Kafka)	아파치 프로젝트 애플리케이션 이름이다. 클러스터 구성이 가능하며, 카프카 클러스터라고 부른다.
브로커(Broker)	카프카 애플리케이션이 설치되어 있는 서버 또는 노드를 말한다.
토픽(Topic)	프로듀서와 컨슈머들이 카프카로 보낸 자신들의 메시지를 구분하기 위한 네임으로 사용한다. 많은 수의 프로듀서, 컨슈머들이 동일한 카프카를 이용하게 된다면, 메시지들이 서로 뒤섞여 각자 원하는 메시지를 얻기가 어렵게 된다. 그래서 토픽이라는 이름으로 구분하여 사용하게 된다.
파티션(Partition)	병렬처리가 가능하도록 토픽을 나눌 수 있고, 많은 양의 메시지 처리를 위해 파티션의 수를 늘려줄 수 있다.
프로듀서(Producer)	메시지를 생산하여 브로커의 토픽이름으로 보내는 서버 또는 애플리케이션 등을 말한다.
컨슈머(Consumer)	브로커의 토픽 이름으로 저장된 메시지를 가져가는 서버 또는 애프리케이션 등을 말한다.

카프카는 강력한 메시지 전달 능력을 바탕으로, 단순히 메시징을 연결해주는 역할을 넘어서 실제로 실시간 분석까지 할 수 있는 카프카 스트림즈, KSQL 등 분석 시스템으로 진화하기도 했다.

카프카를 데이터 파이프라인에 적용한 회사중 가장 유명한 회사는 넷플릭스이다. 넷플릭스는 데이터 분석을 통해 비즈니스 및 제품 결정을 하는 것으로도 유명한데, 비즈니스 및 제품 결정에 이용하는 데이터 분석을 위해 넷플릭스의 모든 애플리케이션은 데이터 파이프라인을 사용한다.

 

모든 이벤트가 앞단 카프카로 전송, 수집된 후 메시지 제어부에서 메시지를 보낼 곳을 결정한 다음 메시지 라우터를 거쳐가게 된다. 이후 이 메시지들은 분석 애플리케이션으로 넘겨지게 된다. (엘라스틱서치에 연결되어 실시간 검색이 사용되도록 인덱싱되고, 컨슈머를 위한 또다른 카프카에 연결되어 다른 앱들에서 사용될수도 있다.)

카프카는 크게 프로듀서, 브로커, 컨슈머, 주키퍼로 분류할 수 있다. 프로듀서는 카프카와 통신하면서 메시지를 보내는 역할을 하고, 컨슈머는 카프카와 통신하면서 메시지를 가져오는 역할을 한다. 주키퍼는 컨슈머와 통신하는 부분 외에도 카프카와 직접 통신하면서, 카프카의 메타데이터 정보를 주키퍼에 저장하고, 카프카의 상태관리 등의 목적으로 주키퍼를 이용한다. 

 

이렇게 카프카는주키퍼와 긴밀하게 통신을 하기때문에 주키퍼 사용이 필수 조건이다. 주키퍼는 카프카 패키지에 포함되어 있는 주키퍼를 사용할 수도 있고, 주키퍼 역시 아파치 오픈소스 중 하나이므로 별도로 주키퍼 웹사이트를 접속해 내려받을 수 있다.

 

분산 애플리케이션을 사용하게 되면, 분산 애플리케이션 관리를 위한 안정적인 코디네이션 애플리케이션이 추가로 필요하게 된다. 분산 애플리케이션을 개발하면서 동시에 코디네이션 애플리케이션도 개발하다보면, 코디네이션 애플리케이셔을 위한 추가적인 개발 리소스가 필요하게 되므로, 이미 안정적인 코디네이션 서비스로 검증된 주키퍼를 많이 사용하고 있다. 주키퍼는 본래 하둡의 서브 프로젝트로 중앙에서 분산 애플리케이션을 관리하는 코디네이션 애플리케이션이 필요했기에 서브 프로젝트로서 주키퍼 개발 작업을 진해했던 것이고, 현재는 아파치 카프카뿐만 아니라 Storm, HBase, NiFi 프로젝트 등 많은 애플리케이션에서 사용되고 있다.

 

카프카는 분산 애플리케이션의 한 종류로서 주키퍼를 코디네이션 로직으로 이용하고 있다. 주키퍼는 분산 애플리케이션을 위한 코디네이션 시스템이다. 분산 애플리케이션이 안정적인 서비스를 할 수 있도록 분산되어 있는 각 애플리케이션의 정보를 중앙에 집중하고 구성 관리, 그룹 관리 네이밍, 동기화 등의 서비스를 제공한다.

 

주키퍼 : 분산애플리케이션 코디네이터

주키퍼는 서버 여러대를 앙상블(클러스터)로 구성하고, 분산 애플리케이션들이 각각 클라이언트가 되어 주키퍼 서버들과 커넥션을 맺은 후 상태 정보 등을 주고받게 된다. 상태 정보들은 주키퍼의 znode라 불리는 곳에 key-value 형태로 저장하고, znode에 key-value이 저장된 것을 이용하여 분산 애플리케이션들은 서로 데이터를 주고받게 된다. 주키퍼에 사용되는 znode는 데이털르 저장하기 위한 공간 이름을 말하는 것으로, 디렉토리 개념이라고 생각하면 이해하기 쉽다.

 

주키퍼의 각 지노드는 일반적인 디렉토리와 비슷한 형태로서 자식노드를 가지고 있는 계층형 구조로 구성되어 있다. 주키퍼의 각 지노드는 데이터 변경 등에 대한 유효성 검사 등을 위해 버전 번호를 관리하게 되며, 지노드의 데이터가 변경될 때마다 지노드의 버전 번호가 증가한다.

 

저장용으로 설계된 일반적인 파일 시스템과 달리 주키퍼에 저장되는 데이터는 모두 메모리에 저장되어 처리량이 매우 크고 속도 또한 빠르다. 또한 주키퍼는 좀더 신뢰성 있는 서비스를 위해 앙상블(클러스터)이라는 호스트 세트를 구성할 수 있다. 앙상블로 구성되어 있는 주키퍼는 과반수 방식에 따라 살아있는 노드 수가 과반수 이상 유지된다면, 지속적인 서비스가 가능하게 된다.

 

주키퍼 앙상블을 3대로 구성했을때, 3의 과반수 이상은 2이미로 1대의 노드가 다운되더라도 지속적으로 서비스할 수 있다. 그러나 만약 2대의 노드가 다운되면 살아있는 노드가 과반수 2보다 적기때문에 서비스 장애 상태에 빠지게 된다. 앙상블 구성의 숫자가 많을수록 과반수 역시 커지므로 꽤많은 노드의 수에서 장애가 발생해도 끊김없는 서비스를 제공할 수 있다.

 

주키퍼 서버 3대로 앙상블을 구성한 경우 최대 초당 약 80,000개의 요청을 처리할 수 있지만, 5대 이상의 앙상블을 구성한 경우에는 최대 초당 140,000개의 요청을 처리할 수 있다.

 

주키퍼 앙상블을 3대로만 구성한다면, 1대 정도의 주키퍼 서버 장애에도 안정적으로 서비스를 제공할 수 있다. 만약 IDC 내 주키퍼를 구성하는 경우 주키퍼 앙상블 서버들을 모두 하나의 랙에 배치하지 않고 각각의 주키퍼 서버를 랙별로 분산한다면 한곳에서 랙 전원 장애가 발생하더라도 장애 상황을 회피할 수 있고, 스위치 역시 분산해 구성한다면 하나의 스위치 장애가 발생하더라도 마찬가지로 안정적으로 운영할 수 있다.

 

주키퍼는 애플리케이션에서 별도의 데이터 디렉토리를 사용한다. 이 디렉토리에는 지노드의 복사본인 스냅샷과 트랜잭션 로그들이 저장된다. 지노드에 변경사항이 발생하면, 이러한 변경사항은 트랜잭션 로그에 추가된다. 그리고 로그가 어느정도 커지면, 현재 모든 지노드의 상태 스냅샷이 파일시스템에 저장된다. 이 스냅샷은 모든 이전 로그들을 대체한다. 중요한 디렉토리이기 때문에 설치 경로와는 다른 경로로 설정하는 것이 바람직하다.

 

그리고 앙상블 내 주키퍼 노드를 구분하기 위한 ID를 만들어야 한다. 주키퍼에서는 myid라고 부르며 정수형태로 만들어주면 된다. myid는 누키퍼의 설정 파일에서 사용하게 된다. 다른 주키퍼 서버들에도 myid 파일을 만들어주고 숫자를 입력한다. 주키퍼 환경설정 파일인 zoo.cfg 파일의 내용에 대한 설명은 아래를 참고한다. 2888, 3888은 기본 포트이며 앙상블 내 노드끼리 연결하는데 사용하고, 리더 선출에 사용한다.

환경 설정	설명
tickTime	주키퍼가 사용하는 시간에 대한 기본 측정 단위(밀리초)
initLimit	팔로워가 리더와 초기에 연결하는 시간에 대한 타임 아웃 tick의 수
syncLimit	팔로워가 리더와 동기화하는 시간에 대한 타임아웃 tick의 수(주키퍼에 저장된 데이터가 크면 수를 늘려야 한다)
dataDir	주키퍼의 트랜잭션 로그와 스냅샷이 저장되는 데이터 저장 경로이다.
clientPort	주키퍼 사용 TCP 포트
server.x	주키퍼 앙상블 구성을 위한 서버 설정이며, server.myid 형식으로 사용한다.

 

리눅스 서버를 운영하거나 애플리케이션 서비스를 운영하는 경우에는 여러 종류의 프로세스들을 잘 관리하는 것도 매우 중요하다. 예기치 않게 서버의 오작동으로 인해 리부팅된 경우 어떤 프로세스는 반드시 자동으로 시작돼야 하는 경우도 있고, 반대로 어떤 프로세스는 반드시 관리자가 수동으로 시작해줘야 하는 경우도 있다. 이렇게 다양한 상황에 따라 효율적으로 프로세스들을 관리하기 위한 방법으로 여러 프로세스들을 systemd에 등록해 운영할 수 있다. 

 

systemd의 파일을 새로 만들거나 기존 파일을 수정한 이후에는 반드시 systemd 재시작을 위해 systemctl daemon-reload 명령어를 입력해야 한다.

 

systemd 설명 : https://potatogim.net/wiki/Systemctl

카프카 클러스터

클러스터 구성을 할 수있는 분산 애플리케이션의 한 종류인 카프카는 클러스터를 구성하는 서버 대수를 정해야 한다. 다만, 분산 애플리케이션이라는 면에서 보면 주키퍼와 동일하지만 클러스터가 운영되는 방식은 다르다. 과반수 방식으로 운영되어 홀수로 서버를 구성해야 하는 주키퍼와는 다르게, 카프카 클러스터는 홀수 운영 구성을 하지 않아도 된다. 다시 말해 3대, 4대, 5대, 10대 등으로 자유롭게 서버를 구성할 수 있다. 

 

간혹 카프카와 주키퍼를 동일한 서버 3대에 같이 올려서 운영하기도 하지만 대규모로 카프카를 운영하는 환경에서는 좋은 방법이 아니다. 카프카는 클러스터를 3대로 구성했을때 2대가 다운되어도 서비스를 할 수 있는 반면, 주키퍼는 앙상블을 3대로 구성했을때 2대가 다운되면 과반수에 미치지 못하기 때문에 장애가 발생한다. 이와 같은 장애 상황으로 인해 주키퍼가 코디네이션 역할을 하지 못하는 경우가 되면 카프카 클러스터에는 문제가 없더라도 주키퍼와 통신이 되지 않기 때문에 카프카 역시 장애 상황에 주키퍼와 통신이 되지 않기 때문에 카프카도 장애상황에 놓이게 된다.

 

주키퍼로 노드를 관리하는 애플리케이션들은 임시 노드(ephemeral node)를 이용해 애플리케이션의 호스트를 등록하고, 애플리케이션과 통신이 끊어지면 임시 노드에서 해당 호스트를 삭제하게 된다. 자바 기반의 애플리케이션들은 간혹 메모리를 많이 사용하게 되면서 풀GC가 발생하게 되는데 애플리케이션은 해당 GC타임 동안 일시적으로 멈춤 상태에 빠지게 된다. 자바 애플리케이션의 주키퍼 세션 타임아웃 설정을 너무 짧게 설정하게 되면 GC타임으로 인해 노드가 다운된 것으로 판단해 의도치 않은 동작을 하게 될 가능성이 높다. 그러므로 자바 애플리케이션의 GC타임을 주기적으로 체크하고, 세션 타임아웃 설정도 3초 이상으로 설정해두기를 권장한다.

 

카프카는 일반 메시지 큐 서비스들과 달리 컨슈머가 메시지를 가져가더라도 저장된 데이터를 임시로 보관하는 기능이 있다. 준비한 서버의 디스크가 하나인 경우에는 디렉토리를 하나만 구성하거나 여러 디렉토리에 만들어 구성할 수 있다. 디스크가 여러 개인 서버의 경우 각 디스크의 수만큼 디렉토리를 만들어줘야 각 디스크별로 I/O를 분산할 수 있다.

 

주키퍼 정보를 입력할 때에는 주키퍼 앙상블 서버 리스트를 모두 입력해야 한다. 주키퍼 앙상블의 호스트 이름과 포트 정보만 입력하면 주키퍼 지노드의 최상위 경로를 사용하게 된다. 이렇게 최상위 경로를 사용하게 되면, 하나의 주키퍼 앙상블 세트와 하나의 애플리케이션만 사용할 수 있게 된다. 왜냐하면 서로 다른 애플리케이션에서 동일한 지노드를 사용하게 될 경우 데이터 충돌이 발생할 수 있다. 하나의 주키퍼 앙상블 세트와 하나의 애플리케이션만 사용하는 방법이 잘못된 방법은 아니지만, 설정을 조정하여 하나의 주키퍼 앙상블 세트를 여러 개의 애플리케이션에서 공용으로 사용할 수도 있다. 바로 주키퍼의 최상위 경로를 사용하는 것이 아니라 지노드를 구분해서 사용하는 것이다.

 

노드를 구분해서 사용하는 경우에는, 주키퍼 정보를 입력할 때 호스트 이름과 포트 정보를 입력한 후 마지막 부분에 사용할 지노드 이름을 추가 입력하면 된다. 

 

카프카 브로커 서버들은 주키퍼 서버와 통신이 되어야 하는데, 방화벽으로 포트 접근이 제한된 환경에서는 주키퍼와 통신 이상 유무를 확인해야 한다. 리눅스에서 nc(TC, UDP를 이용해 네트워크 연결에 읽고 쓰는 네트워킹 테스트 도구)라는 명령어를 이용해 확인할 수 있다. (nc -v IP주소 PORT번호)

 

카프카 브로커 주요 옵션 (https://kafka.apache.org/documentation/#brokerconfigs)

옵션	설명
broker.id	브로커를 구분하기 위한 ID
delete.topic.enable	토픽 삭제 기능을 on/off (enable = 토픽 삭제 가능)
default.replication.factor	Replication Factor 옵션을 주지 않았을 경우의 기본값
min.insync.replicas	최소 리플리케이션 팩터
auto.create.topics.enable	존재하지 않는 토픽으로 퍼블리셔가 메시지를 보냈을때 자동으로 토픽 생성
offsets.topic.num.partitions	offsets 토픽의 파티션 수
offsets.topic.replication.factor	offsets 토픽의 리플리케이션 팩터
compression.type	토픽의 최종 압축형태, gzip, snappy, lz4 등의 표준 압축 포맷 지원, uncompressed는 압축을 하지 않음, producer는 producer가 보내는 압축 형태를 유지하라는 옵션임.
log.dirs	로그가 저장되는 위치
num.partitions	파티션 수 옵션을 주지 않았을 경우의 기본값
log.retention.hours	저장된 로그의 보관 주기
log.segment.bytes	저장되는 로그 파일 하나의 크기
log.retention.check.interval.ms	로그 보관주기 체크 시간
message.max.bytes	카프카에서 허용하는 가장 큰 메시지 크기
zookeeper.connet	주키퍼 접속 정보
zookeeper.session.timeout.ms	브로커와 주키퍼 사이의 최대 연결 대기 시간. 해당 시간 동안 주키퍼와 연결이 되지 않으면 타임아웃 발생
unclean.leader.election.enable	ISR그룹에 포함되지 않은 마지막 리플리카를 리더로 인정.
log.flush.interval.ms	메시지가 디스크로 플러시되기 전 메모리에 유지하는 시간
log.flush.interval.messages	메시지가 디스크로 플러시되기 전 누적 메시지 수

출처: https://12bme.tistory.com/531?category=737765 [길은 가면, 뒤에 있다.]