Kafka 특징 및 용어

Kafka 특징

1) pub-sub 구조를 가진다.

• 메시지를 보내는 역할(Producer)과 받는 역할(Consumer)가 완벽하게 분리되어 있다.
• 느슨한 결합을 통해 어느 한쪽 시스템에서 문제가 발생하더라도 서로 의존성이 없으므로 연쇄작용이 발생할 확률은 매우 낮다.
• Consumer의 서버가 추가 되도 Kafka로만 보내면 되기 때문에 서버 추가에 대한 부담이 적다.
• 하나의 Topic에 여러 Producer 또는 Consumer들이 접근 가능한 구조로 되어 있다. 하나 또는 하나 이상의 Topic으로 메시지를 보내고 가져올 수 있다.

2) 디스크에 메시지를 저장한다.

• 통신할 때 TCP/IP 통신을 통해 바로 디스크로 저장한다.
• Kafka는 별도의 설정 없이 디스크에 적대하며 환경설정에서 그 주기를 변경 할 수 있다. 통신방법의 차이로 Kafka는 초당 10만건 데이터 처리가 가능하다.
• 별다른 설정 없이 데이터의 영속성(Persistence)가 보장된다.
• 트래픽이 일시적으로 폭주해 Consumer의 처리가 늦어지더라도 Kafka의 디스크에 안전하게 보관되어 있기 때문에 Consumer는 메시지의 손실 없이 메시지를 가져갈 수 있다.
• 디스크가 순차적으로 저장되어 있어 디스크 I/O가 줄어들어 성능이 빨라진다.

3) 분산 환경에 특화되도록 설계되었다.

• 하나의 Kafka 클러스터는 3대의 Broker로 부터 시작해 수십대의 Broker로 확장 가능하다.
• 확장 작업은 Kafka 서비스의 중단 없이 온라인 상태에서 작업이 가능하다.
• 최초 Kafka 클러스터 구성시 적은 수로 시작하더라도 이후 트래픽 및 사용량 증가로 클러스터를 확장하는 작업은 매우 간단하고 큰 부담이 없다.

4) 클러스터 구성, fail-over, replication과 같은 여러 특징을 가지고 있다.

• Kafka는 고성능을 유지하기 위해 내부적으로 분산처리, 배치 처리 등 다양한 기법을 사용한다.
• 클러스터 구조의 분산 시스템은 단일 시스템보다 성능이 좋다.

구조와 주요 용어

Topic, Partitions, Offsets

1) Topic: 메세지 종류, 특정한 데이터 스트림을 의미한다.

• Topic의 개수는 제한이 없고 이름으로 구분된다.
• Topic이 다시 특정한 개수의 partitions이 된다. 개수의 명시가 필요하다.

2) Partitions: Topic이 나눠지는 단위

• 유한한 시간(default oneweek)동안 디스크에 저장되어 있다.
• Partition에 한 번 쓰여진 데이터는 변경이 불가능 하다.
• Topic을 구성하는 Partition은 "정렬"되어 있지만 쓰여지는 데이터는 키 값이 제공되지 않으면 파티션에 "랜덤하게" 할당된다.
• 각 파티션 속 메시지는 오름차순의 id값인 offset을 가지고 있다.

3) Offsets: 속해 있는 Partition에서만 의미 있는 값, Partition 내에서 각 메시지가 가지는 unique id

• 순서는 속해 있는 Partition에서만 보장된다. -> 다른 Partition에서 동일한 offset이 가리키는 데이터는 같지 않다.

Broker

• Broker는 Kafka의 서버를 가리킨다. Kafka 클러스터는 1개 이상의 Broker(서버)로 구성된다.
• 각 Broker는 정수형 ID값으로 구분되며 특정한 Topic의 Partition을 보유한다.
• Broker끼리 연결하면 클러스터가 되며, 3개 이상을 가지는 것이 장애 허용 관점에서 좋다.
• Topic을 생성하면 Kafka가 자동적으로 Partition들을 브로커에 분배한다.

• 분산 처리를 하게 될 때 하나의 Broker에 장애가 발생해도 시스템이 정상적으로 운영되게 하기 위해 다른 Broker에 레플리케이션(복사본)을 만들어 두는 것이 안정적이다. 위 그림은 레플리케이션이 3개인 Topic이 Broker가 3개인 클러스터에 각 파티션이 분산되어 있는 예시이다.
• Topic은 replication의 개수가 1개 보다는 커야 좋고, Broker가 다운되면 다른 Broker가 데이터를 처리해준다.

• 레플리케이션 정책에서 오직 하나의 Broker만이 주어진 Partition 복사본들의 리더가 될 수 있다. 그리고 오직 이 리더 하나만 데이터를 받고 처리하는 Partition이 된다.
• 다른 Broker들은 데이터를 동기화한다. 각 Partition은 하나의 리더와 다수의 ISR(In-SyncReplica)이 있다.

Producer, Consumer

1) Producer

• 메세지 생산(발행)자. 기본적으로 Kafka에서 Producer는 Topic에 데이터를 쓰는 개체이다.

• Producer는 선택한 Topic으로 데이터를 발행한다.

• Producer는 메세지를 발행할 Topic을 선택하는 책임을 지게 된다. 이때 키를 선택하지 않으면 default로 round-bin 방식을 사용하여 균등하게 발행 하며 메세지 키를 이용하여 특정 Partition에 특정키를 가진 메세지를 보낼 수 있다.

• 어떤 Broker의 Partition에 저장해야하는지 자동으로 저장 위치를 안다. 장애 발생시 자동 회복이 된다.

• 메세지에 문자열이나 숫자 등의 키 값을 포함해서 메세지를 보낼 수 있다.

• 데이터 저장 성공 여부를 acks를 통해 확인할 수 있다.

• 키 값이 없으면 데이터는 라운드 로빈 방식으로 Broker에 전송(로드 밸런싱)
  

• 키 값이 있으면 메세지는 (키 해싱에 의한)하나의 Partition에만 지속적으로 전달
  

2) Consumer

• 메세지 소비자, Topic으로부터 데이터를 읽어들인다.
  

• 데이터는 각 Partition에 들어온 순서대로 읽힌다.

• 읽어 들이는 Partition 순서는 정해져 있지 않고, 돌아가면서 병렬처리 된다. -> Partition 순서에 대한 보장이 없다.

• Consumer Group: 개별 Consumer들을 하나로 묶은 논리적 그룹 단위, Consumer들끼리 메세지를 나눠서 가져간다. offset을 공유하여 중복으로 가져가지 않는다.

• 그룹 내 특정 Consumer에 장애가 생겨도 다른 Consumer들이 데이터를 읽을 수 있다.
• 컨슈머 그룹내 Consumer가 Partition 숫자보다 많으면 비활성화되는 Consumer가 발생한다. -> Consumer와 Partition 개수를 잘 조절해야 한다.

• Consumer 그룹 단위로도 데이터를 읽은 위치 정보인 Offset이 관리된다. 읽어들인 위치를 기록하는 Offset은 _consumer_offsets로 관리, Topic에 저장, 데이터를 읽어들인 순간 Offset이 기록된다. Consumer가 중지되면 Offset에 저장된 위치에서부터 다시 데이터를 읽어 들인다.

• 위와 같은 "기록 시점" 정책 3가지
  A. At most once(비선호)
  - Consumer가 메세지를 받는 순간 기록
  - 처리가 잘못되어도 메세지는 이미 삭제되어 있다.(데이터 손실)
  B. At least once(선호)
  - 메세지를 받은 Consumer가 데이터를 처리하는 순간 기록
  - 프로세스가 잘못되면 메세지를 다시 읽어들인다.
  - 데이터 중복 처리가 발생해도 시스템에 문제가 없는 프로세스에만 적용
  C. Exactly once
  - Kafka 생태계(Kafka -> Kafka)에서 가능(Kafka Stream API 등)
  - 외부 시스템과의 연결을 할 때는 연산을 여러번해도 결과가 달라지지 않는 컨슈머만 가능(멱등 시스템)
  

Broker Discovery, Zookeeper

1) Broker Discovery

• 모든 Kafka Broker는 "부트스트랩 서버"라 불린다.
• 다른 Broker 하나와만 연결해도 전체 클러스터에 연결이 되며 각각의 Broker는 전체 Broker와 Topic들 그리고 Partition들에 대한 정보(메타데이터)를 알고 있다.

2) Zookeeper

• Kafka 서버(+클러스터) 상태를 관리 -> 분산 코디네이터다.
• Broker를 모니터링하고, Topic과 Partition을 관리한다.
• Zookeeper는 Kafka 클러스터 내의 Broker들의 리스트를 가지고 있으며 Broker들을 관리하며 Kafka는 Zookeeper 없이 실행할 수 없다.
• 리더 Partition에 장애가 발생시 Zookeeper를 통해 새로운 리더 Partition을 선발한다.
• 새로운 Topic 추가, Broker 장애 및 Topic 삭제 등의 변경 정보를 Kafka에 전달한다.
• Zookeeper는 홀수 개의 서버(3,5,7...)를 가지고 있어야 한다.
• Zookeeper는 쓰기를 관장하는 리더 서버 1개와 읽기를 관장하는 나머지 팔로워 서버로 구성된다.