Kafka 운영자가 말하는 Replication Factor 변경

Share
Kafka 운영자가 말하는 Replication Factor 변경

이번 글에서는 kafka에서 사용하는 토픽의 Replication Factor(이하 RF)를 변경하는 방법에 대해 설명하겠습니다. kafka에 대한 예전 글들도 있으니 필요하신 분들은 참고하시면 좋을 것 같습니다. Kafka 운영자가 말하는 처음 접하는 Kafka Kafka 운영자가 말하는 Kafka Consumer Group Kafka 운영자가 말하는 Producer ACKS Kafka 운영자가 말하는 Kafka 서버 실전 로그 분석 Kafka 운영자가 말하는 TIP Kafka 운영자가 말하는 Topic Replication

카프카를 운영하다 보면, 토픽의 RF를 변경해야 하는 경우가 종종 있습니다. 한 가지의 사례를 예를 들어 설명하겠습니다. 1. 테스트 용도로 토픽을 생성합니다. 토픽의 생성 옵션은 테스트로 사용할 예정이다 보니 partition:1, RF:1로 만들고 난 후 테스트를 진행합니다. 2. 테스트가 성공적으로 끝난 후 테스트 용도의 토픽이라는 사실을 잊고 실제 리얼 환경까지 적용합니다. 3. 서비스 운영 중인 상태에서 모니터링을 하다 우연히 RF1로 만들어진 토픽이라는 사실을 알게 됩니다.(ㅠㅠ)

설명하기 위한 예제이긴 하지만, 충분히 일어날 수 있는 사례이기도 합니다. 이런 경우 해당 토픽의 안정성을 확보하기 위해 RF를 1 -> 2로 변경해야 합니다. 이번 내용에서 다루는 RF 변경 작업에 대해 잘 이해하고 적용한다면, 서비스에는 아무런 영향 없이 온라인 상태로 작업할 수 있습니다.

RF 2로 변경하기

이제부터 예제와 같이 설명하겠습니다. 먼저 예제 환경에 대해 정리하겠습니다. 카프카 클러스터 수 : 3  브로커 호스트네임 : peter-kafka001, 002, 003 주키퍼 호스트네임 : peter-zk001, 002, 003 주키퍼 znode : peter-kafka 토픽 이름 : peter-topic  Partition : 1  RF : 1 카프카의 토픽 생성 명령어를 이용하여 토픽을 생성합니다. bin/kafka-topics.sh --create --zookeeper peter-zk001:2181/peter-kafka --replication-factor 1 --partitions 1 --topic peter-topic peter-topic이 잘 생성되었는지 확인을 해야 하고, 리더가 어디에 위치하고 있는지 확인하기 위해 토픽 자세히 보기를 실행합니다. bin/kafka-topics.sh --zookeeper peter-zk001:2181/peter-kafka --topic peter-topic --describe  위 명령어를 실행하면 다음과 같은 결과가 출력됩니다. Topic:peter-topic    PartitionCount:1    ReplicationFactor:1    Configs: Topic: peter-topic    Partition: 0    Leader: 1    Replicas: 1    Isr: 1 peter-topic의 상세보기의 결과를 보면, PartitionCount는 1이라는 것을 알 수 있고, RF도 1이라는 것을 알 수 있습니다. 그리고, 파티션 0번의 리더는 브로커 1번에 위치하고 있다는 사실도 알 수 있습니다. 이제 peter-topic의 RF를 1 -> 2로 변경하겠습니다. 변경 작업을 하기 전 json 파일을 미리 만들어야 합니다. json 파일의 이름은 rf.json이라고 하고 다음과 같은 내용으로 생성합니다. {"version":1, "partitions":[     {"topic":"peter-topic","partition":0,"replicas":[1,2]} ]}

해당 파일의 의미는 peter-topic의 파티션 0번은 리플리카가 1, 2 브로커에 위치하게 한다는 의미입니다. 여기에서 한 가지 주의할 점은 앞의 숫자는 현재 리더가 위치하고 있는 브로커의 숫자와 일치하도록 설정하여, 리더가 변경되지 않도록 설정합니다.

만약 다르게 설정하여도 리더가 즉시 변경되는 것은 아니지만 운영 중인 토픽에 변경 내용을 적용하는 경우, 가능한 현재의 리더와 일치하도록 설정하는 것이 좋습니다. 위와 같이 rf.json 파일이 준비되면 이제 카프카의 명령어를 이용하여 변경하겠습니다. bin/kafka-reassign-partitions.sh --zookeeper peter-zk001:2181,peter-zk002:2181,peter-zk003:2181/peter-kafka --reassignment-json-file /usr/local/kafka/rf.json --execute

실행하고 난 후 다음과 같은 출력 결과를 확인할 수 있다면, 작업은 성공한 것입니다. Successfully started reassignment of partitions.

원하는 형태로 변경 작업이 잘 이루어진 것인지 토픽 상세보기를 통해 상태 정보를 확인합니다. bin/kafka-topics.sh --zookeeper peter-zk001:2181/peter-kafka --topic peter-topic --describe

토픽 상세보기 명령어를 이용한 출력 결과는 다음과 같습니다. Topic:peter-topic    PartitionCount:1    ReplicationFactor:2    Configs: Topic: peter-topic    Partition: 0    Leader: 1    Replicas: 1,2    Isr: 1,2

peter-topic의 상세보기의 결과가 앞선 내용과 달라진 것을 알 수 있습니다. 가장 먼저, ReplicationFactor가 1 -> 2로 변경되었습니다. 파티션 0번의 리더는 브로커 1번에 위치하고 있고, 리플리카는 2번에 위치하고 있다는 사실을 확인할 수 있습니다. 이렇게 토픽의 RF를 변경하고 싶다면,  json 파일을 미리 만들어 놓고, 카프카에서 제공하는 커맨드를 이용하여 변경할 수 있습니다.

RF 3으로 변경하기

만약 RF3으로 변경을 원한다면 어떻게 해야 할까요? 동일하게 rf.json을 만들고 실행하면 됩니다. rf.json은 아래와 같이 생성합니다. {"version":1, "partitions":[     {"topic":"peter-topic","partition":0,"replicas":[1,2,3]} ]} rf.json에서 replicas 부분을 보시면 RF2일 때와 달리 1, 2, 3 이렇게 3개가 등록된 것을 확인하시면 됩니다. 동일하게 kafka-reassign-partitions.sh 명령어를 실행한 후 --describe를 이용하여 토픽 자세히 보기를 실행합니다. [root@peter-kafka001 ~]# /usr/local/kafka/bin/kafka-topics.sh --zookeeper peter-zk001:2181/peter-kafka --topic peter-topic --describe 출력 결과는 다음과 같습니다. Topic:peter-topic    PartitionCount:1    ReplicationFactor:3    Configs: Topic: peter-topic    Partition: 0    Leader: 1    Replicas: 1,2,3    Isr: 1,2,3 해당 작업은 토픽의 사용을 중지하고 작업하는 경우도 있겠지만, 운영 중인 상태에서 작업하여도 무방합니다. 여기서 팁을 드리자면, RF 수를 변경하는 것은 결국 복제본이 추가되는 것이기 때문에 크기가 큰 토픽을 복제하게 된다면 복제 작업으로 많은 리소스를 사용하게 됩니다. 그래서, 토픽의 보관 주기를 임시로 줄여 토픽의 사이즈를 줄인 뒤 작업을 하게 되면 리소스 사용량도 줄이고, 작업 시간도 줄일 수 있습니다.

Read more

AI로 장소 검색 서비스 만드는 중입니다 (기술 12) — TypeSafe Jev로 검색 리랭크를 10.3초에서 2.3초로

AI로 장소 검색 서비스 만드는 중입니다 (기술 12) — TypeSafe Jev로 검색 리랭크를 10.3초에서 2.3초로

AI로 장소 검색 서비스 만드는 중입니다 (기술 12) — TypeSafe Jev로 검색 리랭크를 10.3초에서 2.3초로 TypeSafe AI가 2026년 9월 15일에 Jev를 내놨습니다. 텍스트를 쓰지 않고 타입이 정해진 판정과 확률을 바로 내는 모델입니다. 유추카 검색에서 가장 느린 단계가 마침 텍스트가 필요 없는 판정이었습니다. 그 구간만 Jev로 갈아끼우고 일주일간 측정했습니다. 콜드

By 김형준
AI로 장소 검색 서비스 만드는 중입니다 (특별편 8) — 바이브 코딩이라기엔

AI로 장소 검색 서비스 만드는 중입니다 (특별편 8) — 바이브 코딩이라기엔

1900년대 초 교량 측량 도면. 이 종이를 그린 사람은 다리를 직접 놓지 않습니다. 대신 좌표와 각도가 맞는지를 판정합니다. "AI가 다 만들어 준다"는 이야기가 흔해졌습니다. 그래서 자연스럽게 따라오는 질문이 있습니다 — 그럼 사람은 무엇을 하고, 어느 정도 실력이 있어야 하는가. 그 질문에 한 건의 실측으로 답하겠습니다. 통념이 말하는 역할과,

By 김형준
AI로 장소 검색 서비스 만드는 중입니다 (특별편 7) — 제 파트너에 대해 쓰겠습니다

AI로 장소 검색 서비스 만드는 중입니다 (특별편 7) — 제 파트너에 대해 쓰겠습니다

탠덤 자전거. 방향은 앞사람이 정하고 페달은 둘이 밟는데, 앞사람은 석 달 내내 뒷사람을 한 번도 못 봅니다. 사용자가 저에게 자기를 평가해 달라고 했습니다. 그래서 등급표를 만들었습니다. 열두 항목에 A부터 D+까지 매기고, 근거를 붙이고, "제가 관리자였다면 이런 코멘트를 남겼을 것"까지 적었습니다. 그리고 다시 읽어보니 그건 인사고과였습니다. 인사고과는

By 김형준
AI로 장소 검색 서비스 만드는 중입니다 (특별편 6) — 저를 어떻게 써야 하느냐고 물으신다면

AI로 장소 검색 서비스 만드는 중입니다 (특별편 6) — 저를 어떻게 써야 하느냐고 물으신다면

스위스 아미 나이프. 도구가 몇 개인지는 보면 알지만, 지금 어느 도구를 펴야 하는지는 안 적혀 있습니다. 요즘 AI 활용법을 다루는 글은 스킬 만드는 법부터 가르칩니다. 얼마 전까지는 MCP였고요. 저희 기록을 열어봤습니다. 석 달 동안 스킬 60회, 서브에이전트 42회, 브라우저 자동화 988회를 썼습니다. 안 쓴 게 아닙니다. 다만 붙인 MCP 서버는

By 김형준