일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 반복문
- Sequelize
- back-end
- 코틀린
- 개발이 취미인 사람
- react
- node.js
- 상속
- state
- AWS
- java
- class
- file upload
- kafka
- Producer
- props
- component
- 개발자
- 자바
- restful api
- Nest.js
- front-end
- javascript
- SWIFT
- vue
- Kotlin
- It
- spring boot
- 조건문
- swagger
- Today
- Total
개발이 취미인 사람
[Kafka] - Broker 리플리케이션(Replication) 동작 원리 본문
개요
안녕하세요. 이번 시간에는 브로커 리더와 팔로워 사이에 메시지를 복제하는 동작 원리에 대해 알아보겠습니다.
혹시 이전 시간에 내용을 학습하고 오지 못하신 분들은 아래 링크를 통해 학습하고 오시는 걸 추천드리겠습니다.
[Kafka] - Broker 메시지 복제와 커밋 ISR(In Sync Replica)
리플리케이션 동작 원리
이전 시간에 리더와 팔로워에 대한 개념에 대해 설명했습니다. 아래는 Kafka 구조를 보여줍니다.
Producer가 메시지를 보내면 리더 브로커에 메시지가 전송됩니다. 그 후 해당 메시지는 팔로워가 복제합니다. 그런 다음
Kafka로 수많은 메시지의 읽고 쓰기를 처리하는 리더는 매우 바쁘게 동작합니다. 이렇게 바쁜 리더가 리플리케이션 동작을 위해 팔로워들과 많은 통신을 주고받고 리플리케이션 동작에 관여를 한다면, 결과적으로 리더의 성능이 떨어지고 카프카의 장점인 높은 처리량과 낮은 지연시간을 보장받기는 어려울 것 같습니다.
따라서 카프카는 리더와 팔로워 간에 통신을 최소화하고 리더의 부하를 줄였습니다.
그럼 리플리케이션이 어떤 방식으로 동작을 하는지 단계별로 알아보겠습니다. 1개의 파티션에 3개의 리플리케이션 팩터로 설정했을 때의 과정을 설명하겠습니다.
리플리케이션 과정
1번 과정에서 현재 리더는 0번 오프셋에 message 1이라는 메시지를 갖고 있는 상태입니다.
프로듀서가 message 1 이라는 메시지를 전송했으며, 리더만 메시지를 저장하고 팔로워는 아직 리더에게 저장된 메시지를 리플리케이션 하기 전 단계입니다.
다음 과정으로 팔로워들은 리더에게 0번 오프셋 메시지를 가져오기(Fetch) 요청을 보낸 후 새로운 메시지 message 1이 있다는 사실을 인지하고 리플리케이션을 하는 과정입니다.
여기서 리더는 모든 팔로워가 0번 오프셋 메시지를 리플리케이션하기 위해 요청을 보냈다는 사실을 알고 있습니다.
하지만 리더는 팔로워들이 0번 오프셋에 대한 리플리케이션 동작을 성공했는지 실패했는지 여부는 알지 못합니다.
대표적인 메시지 큐 시스템인 RabbitMQ의 트랜잭션 모드에서는 모든 미러(Kafka에서는 팔로워를 뜻함)가 메시지를 받았는지에 대한 ACK를 리더에게 리턴하므로, 리더는 미러들이 메시지를 받았는지 알 수 있습니다.
여기서 카프카는 ACK를 주고받지 않기 때문에 리플리케이션 동작의 성능을 더욱 신경 썼다고 볼 수 있습니다.
그런데 만약 팔로워가 장애가 발생하면 어떤 식으로 메시지를 일괄성이 있게 보장할 수 있을까요?
만약 2번 팔로워가 장애가 발생 했다면, 해당 팔로워 복귀 뒤 리더에게 자신의 상태를 보고하고 현재까지의 메시지를 다시 전달받아 동기화를 진행합니다.
3번 과정에서 리더는 새로운 message 2 메시지를 전달 받고 저장(commit)합니다. 0번 오프셋에 리플리케이션 동작을 마친 팔로워는 1번 오프셋에 대한 리플리케이션을 요청합니다.
리더는 팔로워들이 0번 오프셋에 대한 리플리케이션 동작을 성공했음을 인지하고, 오프셋 0에 대해 커밋 표시를 한 후 하이워터마크를 증가시킵니다.
4번 과정은 리플리케이션에 마지막 과정으로 리더의 응답을 받은 모든 팔로워는 0번 오프셋 메시지가 커밋되었다는 사실을 인지하게 되고, 리더와 동일하게 커밋을 표시합니다. 그런 다음 1번 오프셋 메시지인 message 2를 리플리케이션 합니다.
이런 식으로 1번 ~ 4번 과정을 반복적으로 수행하면서 메시지 일괄성을 유지합니다.
- 몇 가지 중요한 부분들은 다음과 같습니다.
- 1. 다른 메시징 시스템과 다르게 카프카는 ACK 통신 단계를 제거 했다는 사실입니다.
- 2. 리더가 푸시(Push)하는 방식이 아니라 팔로워들이 풀(Pull)하는 방식으로 동작합니다.
이번 시간에는 리플리케이션(Replication) 동작 원리의 대해 알아 봤습니다. 모르는 개념이 있다면 댓글을 남겨주시면 감사하겠습니다.
'백앤드(Back-End) > Kafka' 카테고리의 다른 글
[Kafka] - Producer 메시지 전송 방식 (0) | 2024.10.21 |
---|---|
[Kafka] - Broker 컨트롤러(Controller) (2) | 2024.10.18 |
[Kafka] - Broker 메시지 복제와 커밋 ISR(In Sync Replica) (0) | 2024.08.02 |
[Kafka] - Kafka Consumer 메시지 소비 (0) | 2024.08.02 |
[Kafka] - Kafka Producer 메시지 생성 (0) | 2024.08.01 |