목차
- Kafka Replication
- Replication factor
- Leader & Follower
- ISR(In Sync Replica)
Kafka Replication
Kafka에서는 높은 가용성을 위하여 Replication이란 기능을 제공합니다.
Replication은 각 Topic의 Partition들을 Kafka Cluster내의 다른 Broker들로 복제하는 것을 말하며 Topic생성 시 Replication의 수를 지정할 수 있습니다.
생성된 Replication은 Leader와 Follower로 나뉘어 ISR(In Sync Replica)이라는 일종의 Replication Group을 형성하여 관리됩니다.
Replication factor
Replication factor는 Topic 단위로 설정할 수 있습니다.
기본값은 1로 설정되어 있으며, 이를 변경하고 싶으면 Kafka 설정 파일에서 default.replication.factor 값을 변경하면 됩니다.
Topic 단위로 replication factor를 설정한다 해서 Topic을 replication 하는 것이 아니라, Topic을 이루는 각각의 Partition을 replication 하는 것입니다.
아래 Topic을 생성하는 명령어를 살펴보겠습니다.
kafka-topics.sh --bootstrap-server localhost:9092 --replication-factor 1 --partitions 3 --topic test --create| bootstrap-server | Topic이 생성될 Broker의 IP주소와 PORT번호입니다. 같은 Kafka Cluster에 속해있는 Broker들을 ,(반점)으로 구분하여 여러개 기입할 수 있습니다. ex) --bootstrap-server Broker1-IP:9092,Broker2-IP:9092,Broker3-IP:9092 |
| replication-factor | 생성할 Topic의 replication factor 수를 지정합니다. |
| partitions | 생성할 Topic의 Partition 수를 지정합니다. |
| topic | 생성할 Topic의 이름을 지정합니다. |
| create | Topic을 생성합니다. |
해당 명령어를 실행하게 되면 Kafka Cluster에는 test란 이름의 Topic이 생성됩니다.
partitions의 값을 3, replication factor 값을 1로 설정했으므로 3개의 Partition이 복제 없이 여러 Broker에 분산된 형태로 구성됩니다.
그림으로 나타내면 아래와 같습니다.
만약 replication-factor가 3인 Topic을 생성하게 된다면 아래와 같은 형태로 구성될 것입니다.
kafka-topics.sh --bootstrap-server localhost:9092 --replication-factor 3 --partitions 3 --topic test --create
replication factor 값을 높이게 되면 가용성이 증가하는 것은 분명합니다. 하지만 그에 비례하여 디스크 사용량이 배가 되며 Broker의 일부 리소스 사용량 또한 증가하게 됩니다. 따라서 replication factor 값을 무작정 높게 설정하기보다는 해당 Topic에 저장되는 Data의 중요도에 따라 적절히 값을 조정하여 운영하는 것이 바람직합니다.
Leader & Follower
Kafka의 Topic은 1개 이상의 Partition으로 구성되고, 각 Partition은 1개의 leader replica와 0개 이상의 follower replica로 구성됩니다.
예를 들어 Replication factor가 1이라면 Partition은 1개의 leader replica와 0개의 follower replica로 이루어집니다.
만약 Replication factor가 3이라면 1개의 leader replica와 2개의 follower replica로 이루어집니다.
Leader replica는 일관성을 보장하기 위해 모든 Producer와 Consumer의 요청을 처리하며 데이터를 저장합니다.
Follower replica는 Leader replica의 데이터를 복제하여 동일하게 유지하다가 Leader replica가 중단되는 경우 Follower replica 중 하나가 해당 Partition의 새로운 Leader replica로 선출됩니다.
만약 기존 Leader replica에 예상치 못한 문제가 생겨 새로운 Leader replica가 선출되어야 하는 상황이 발생했을 때 제대로 데이터를 복제해 오지 못한 Follower replica가 존재한다면, 해당 개체를 제외한 나머지 Follower replica 중에서 Leader replica를 선출해야 할 것입니다. 이를 위해서 Kafka에서는 ISR(In Sync Replica)이라는 개념을 도입했습니다.
ISR(In Sync Replica)
ISR(In Sync Replica)이란 일종의 Replication group이라 생각하시면 됩니다.
이 Group은 Leader replica와 제대로 동기화가 이루어진 Follower replica들로 구성됩니다.
동기화를 하기 위해 Follower replica들은 Fetch 요청을 Leader replica에게 보내고, Leader replica는 그 응답으로 Follower replica들에게 메시지를 전송합니다. Fetch 요청에는 Follower replica들이 다음으로 받기 원하는 메시지의 Offset이 포함되며, 항상 수신된 순서대로 처리됩니다.
Leader replica가 중단되는 경우에는 말씀드린 대로 ISR에 속해있는 Follower replica 중 하나가 Leader replica로 선출됩니다.
Follower replica가 일정 시간 이상 Fetch 요청을 하지 않거나, 요청은 했지만 시간 안에 Leader replica의 마지막 Offset의 메시지를 복제하지 못한다면 동기화에 실패한 것으로 간주하여 Leader replica는 해당 Follower replica를 ISR에서 제거합니다. (해당 시간은 Broker 설정 파일의 replica.lag.time.max.ms 값으로 설정됩니다.)
'Confluent > Apache Kafka' 카테고리의 다른 글
| Apache Kafka 개요 & Architecture 설명 (0) | 2021.07.29 |
|---|