주키퍼, 카프카 질문사항

주키퍼, 카프카 질문사항으로 많이 나오는 항목에 대한 답변 정리를 하겠습니다. 해당 내용을 바탕으로 실무에서 카프카가 어떻게 활용되고 있는지를 보다 명확히 알 수 있는 계기가 되었으면 합니다.

주키퍼

주키퍼는 몇 대로 구성하는 게 가장 좋은가?

→ 주키퍼는 홀수로 구성하고 안정적인 운영 환경에서는 5대로 구성함. 작은 규모는 3대.

주키퍼의 하드웨어 권장 사양은?

→ 일반 CPU / 4G~8G 메모리 / 240~480 SSD / 1G NIC 등 일반적인 웹 서버 정도 수준으로 구성

주키퍼의 모니터링은 어떻게 하는가?

→ JMX를 이용해 모니터링 가능. 4글자 단어(Four Letter Words)라는 것을 지원하므로 mntr 같은 단어를 이용해 모니터링 가능함. 주키퍼 공식 홈페이지 참조.

Apache ZooKeeper

주키퍼와 카프카를 동일한 서버에서 사용해도 되는가?

→ 사용 가능. 하지만 장애 대응 등을 고려하면 별도로 분리해서 사용하는 것을 권장.

카프카 질문사항

브로커의 하드웨어 권장 사양은 어떻게 되는가?

→ 24 코어 CPU / 64~128GB 메모리 / 4~8TB SATA 12개 / 10G NIC

메시지는 손실되지 않는가?

→ 100% 보장은 안됨. 다만 토픽의 리플리케이션 팩터 수 3, min.insync.replicas 2로 설정하면 카프카로 저장된 메시지는 손실되지 않음. 3대 전부의 하드웨어 장애 시에는 보장 못함.

토픽의 적절한 파티션 수는?

→ 정답은 없음. 파티션 수는 한 번 늘이면 줄일 수 없음. 아래는 파티션 수 예측할 수 있는 사이트임.

https://eventsizer.io

운영 중에 파티션 수를 늘릴 수 있는가?

→ 늘릴 수 있음. 8.3절 ‘카프카의 확장’ 참조

파티션을 줄일 수 있는가?

→ 불가함. 동일한 토픽명을 사용해야 하고 파티션 수는 줄여야 하는 경우 → 프로듀서와 컨슈머를 중단한 상태에서 토픽을 삭제하고 동일한 토픽명과 원하는 수의 파티션으로 재생성하는 방법이 있음.

토픽의 이름을 바꿀 수 있는가?

→ 불가함. 토픽의 재명명 기능은 지원하지 않음.

토픽의 리플리케이션 팩터 수를 늘려야 하는데 운영 중에 늘릴 수 있는가?

→ 토픽의 리플리케이션 팩터 수는 운영 중에 늘릴 수 있음. 사용량이 적은 시간에 작업하고 현재의 리더가 그대로 유지되도록 변경 권장.

토픽의 리플리케이션 팩터 수를 4로 해도 되는가?

→ 가능함. 리플리케이션 팩터 수가 커지면 디스크 공간도 많이 필요하므로 확인 필요.

브로커의 디스크를 로컬 디스크 대신 SAN이나 NAS를 사용해도 되는가?

→ 사용 가능함. 단, 비용면에서 브로커의 장점 중 저렴한 디스크를 사용해도 높은 성능을 낼 수 있다는 것인데, 고배용의 디스크를 사용하면 비효율적임. 네트워크 병목으로 인한 디스크 성능 저하 문제도 있음.

브로커의 디스크 사용량이 가득찼을 경우 대응책은?

→ 토픽의 보관 주기를 짧게 설정하거나 이렇게 했을 경우 줄어들지 않으면 보관 주기를 체크하는 간격의 기본값이 5분이므로 5분 후에 확인해 보면 됨.

하나의 클러스터에서 브로커들의 하드웨어 사양이 모두 동일해야 하는가?

→ 강제 사항은 아님. 단, 동일해야 운영 관리 측면에서 효율적임. 사양이 다르면 처리 성능, 저장 용량도 다르기 때문임.

브로커의 디스크는 RAID로 구성하는 것이 좋은가?

→ 운영 측면에서 RAID 구성 더욱 효율적임. 단 JBOD 구성도 환경에 따라 고려 가능.

오픈 파일과 관련한 오류가 발생하면서 브로커가 다운되었음.

→ 많은 로그 세그먼트를 사용하면 운영 체제의 오픈 파일 관련 설정을 조정해줘야 함. 현재 사용 중인 브로커의 오픈 파일 디스크립터는 ‘lsof -p 브로커 pid’를 이용해 확인 가능, 늘리는 방법은 시스템 레벨(/etc/sysctl.conf 파일에서 fs.file-max 수정)과 유저 레벨(/etc/security/limits.conf 파일에서 nofile 수정)에서 변경함.