아파치 카프카 장애는 카프카 클러스터 또는 그 일부 구성 요소가 실패하여 서비스의 중단 또는 저하가 발생할 때 발생합니다. 카프카는 고처리량 및 내고장성 데이터 스트리밍 및 메시징을 처리하도록 설계되었지만, 인프라 장애, 잘못된 구성, 운영 문제 등 여러 이유로 실패할 수 있습니다.장애 발생 이유
카프카 장애 발생 이유
브로커 장애
과도한 데이터 부하 또는 과다한 하드웨어로 브로커가 응답하지 않게 되는 경우, 하드 드라이브 충돌로 인한 하드웨어 장애, 메모리 고갈 또는 브로커 네트워크 문제 등이 있을 수 있습니다.
증발자 문제
카프카는 클러스터 메타데이터 및 리더 선출을 관리하기 위해 아파치 주키퍼에 의존합니다. 주키퍼 장애(네트워크 분할, 잘못된 구성 또는 리소스 고갈로 인한)는 카프카 작업을 방해할 수 있습니다. 주키퍼 문제는 클러스터가 아파치 카프카의 3.5 버전 이후의 KRaft 모드로 구성된 경우 무시할 수 있습니다.
토픽 잘못 구성
부족한 복제 요소 또는 적절하지 않은 파티션 구성은 브로커가 실패할 때 데이터 손실 또는 서비스 중단을 유발할 수 있습니다.
네트워크 분할
브로커, 클라이언트 또는 주키퍼 간의 통신 장애는 가용성을 감소시키거나 스플릿 브레인 시나리오를 유발할 수 있습니다.
구성 오류
Misconfigured 클러스터 설정 (보존 정책, 레플리카 할당 등)은 예기치 않은 동작 및 장애로 이어질 수 있습니다.
과부하
생산자 또는 소비자 트래픽의 급격한 증가는 클러스터에 과부하를 일으킬 수 있습니다.
데이터 손상
디스크 문제나 갑작스러운 종료로 인한 Kafka 로그 손상은 시작 또는 데이터 검색 문제를 일으킬 수 있습니다.
적절하지 않은 모니터링 및 경보
디스크 사용량의 급증이나 장기 지연과 같은 조기 경보 신호가 인식되지 않고 처리되지 않으면 소규모 문제가 완전한 장애로 이어질 수 있습니다.
Apache Kafka 토픽과 설정의 백업은 재해 복구를 위해 중요합니다. 이를 통해 하드웨어 장애, 소프트웨어 문제 또는 인간 오류 발생 시 데이터와 설정을 복원할 수 있습니다. Kafka에는 토픽 백업을 위한 내장 도구가 없지만 몇 가지 방법을 사용하여 이를 달성할 수 있습니다.
Kafka 토픽 및 설정 백업 방법
토픽 및 설정을 백업하기 위해 여러 가지 방법을 따를 수 있습니다.
Kafka 소비자
우리는 Kafka 소비자를 사용하여 토픽에서 메시지를 읽고 HDFS, S3 또는 로컬 저장소와 같은 외부 저장소에 저장할 수 있습니다. 내장 kafka-console-consumer.sh 또는 사용자 지정 소비자 스크립트와 같은 신뢰할 수 있는 Kafka 소비자 도구를 사용하면 토픽에서 모든 메시지를 최초 오프셋부터 소비할 수 있습니다. 이 절차는 간단하고 사용자 정의가 가능하지만, 고 처리량 토픽에 대해서는 큰 저장 공간이 필요하며 타임스탬프나 헤더와 같은 메타데이터가 손실될 수 있습니다.
Kafka Connect
툴을 사용하여 토픽에서 오브젝트 저장소로 메시지를 스트리밍하는 방법. 우리는 싱크 커넥터(예: S3 싱크 커넥터, JDBC 싱크 커넥터 등)로 Kafka Connect를 설정할 수 있으며, 특정 토픽에서 읽고 백업 대상에 쓸 수 있습니다. 물론 Kafka Connect에 대한 추가 설정이 필요합니다.
클러스터 복제
Kafka의 미러링 기능을 사용하여 기존 Kafka 클러스터의 복제본을 관리할 수 있습니다. 이는 Kafka 소비자를 사용하여 소스 클러스터에서 메시지를 소비하고 다른 Kafka 클러스터로 다시 게시하여 백업으로 사용할 수 있습니다. 백업 클러스터가 중복성을 위해 별도의 물리적 또는 클라우드 지역에 위치해 있는지 확인해야 합니다. 신속한 복제와 점진적 백업을 지원하지만 백업 클러스터를 유지하는 데 높은 운영 부담이 따릅니다.
파일 시스템 수준의 복사
파일 시스템 수준의 백업은 카프카 브로커에서 카프카 로그 디렉토리를 직접 복사하는 것과 같이, 카프카 로그 디렉토리를 식별함으로써 수행할 수 있습니다 (server.properties의 log.dirs에 위치). 이 방법을 사용하면 오프셋과 파티션 데이터를 보존할 수 있습니다. 그러나 일관성을 보장하고 잠재적인 문제를 피하기 위해 세심한 복원 프로세스가 필요합니다.
카프카 구성 및 메타데이터
카프카 구성에 관한 면에서, 토픽에 대한 메타데이터, 액세스 제어 (ACL), 모든 브로커의 server.properties 파일 및 ZooKeeper 데이터 디렉토리 (ZooKeeper 구성의 dataDir 매개변수로 정의됨)을 지정할 수 있습니다. 그런 다음 결과를 파일에 저장하여 참조할 수 있습니다. 모든 사용자 정의 설정(log.retention.ms, num.partitions 등)을 문서화해야 합니다. 내장 스크립트 kafka-acls.sh를 사용하여 모든 acl 속성을 평평한 파일에 통합할 수 있습니다.
결론
위에서 논의한 관행은 주로 온프레미스에 배포된 클러스터 및 클러스터에 구성된 한 자리 숫자의 노드에 적합합니다. 그러나 관리 서비스 제공업체는 플랫폼을 실행하는 데 필요한 운영 베스트 프랙티스를 처리하므로 문제를 탐지하고 수정하는 데 걱정할 필요가 없습니다.
본 문서를 통해 온프레미스 배포에서 Apache Kafka 장애를 대처하기 위한 실용적인 통찰과 검증된 전략을 얻을 수 있기를 바랍니다.
Source:
https://dzone.com/articles/avoid-kafka-outages-with-topic-and-configuration-backups