Apache Kafka 생태계를 위한 포괄적인 수동 테스트 방법론은 스키마 생애 주기 관리, 클러스터 스트레스 하의 소비자 행동, 실패 모드 처리를 구조적으로 탐색하는 것이 필요합니다. 테스터는 생산급 메시지 볼륨을 시뮬레이션하면서 의도적으로 스키마 변이를 도입하여 Confluent Schema Registry의 호환성 규칙을 검증하는 시나리오를 설계해야 합니다. 이는 데이터 계약이 기존 소비자를 중단시키지 않고 분산 팀 간에 온전하게 유지되도록 보장합니다.
이 접근 방식은 재조정을 유발하기 위해 제어된 소비자 그룹 멤버십 변경을 생성하고, 그 후 오프셋 커밋과 메시지 순서 보장을 검증하는 것을 포함합니다. 또한, 잘못된 Avro 페이로드를 수동으로 주입하여 오류 처리 메커니즘이 손상된 메시지를 사망 편지 주제로 올바르게 라우팅하는지 검증하는 데 도움을 줍니다. 이러한 활동은 네트워크 파티션 동안 컨트롤러 선출 안정성을 확인하기 위해 ZooKeeper 또는 KRaft 메타데이터와 직접 상호작용해야 합니다.
한 금융 서비스 회사에서, 우리 팀은 결제 처리 시스템을 IBM MQ에서 Kafka 3.5로 마이그레이션할 때 중요한 데이터 손실 위험에 직면했습니다. 이 시스템은 Confluent Schema Registry를 사용하여 거래 이벤트에 대해 Avro 스키마를 활용하였고, 우리는 스키마 변경으로 인해 소비자 애플리케이션이 크래시 되며 재조정 이벤트로 인해 중복 결제 기록이 생성된 것을 발견했습니다. 마이그레이션 마감일은 엄격하게 정해져 있었고, 자동화된 테스트 스위트 개발의 여지가 없었습니다.
첫 번째 접근 방식은 기존의 자동화된 통합 테스트에만 의존하는 것이었습니다. 이는 빠른 피드백 루프와 쉬운 CI/CD 통합을 제공했으나, 실제 네트워크 지연 효과와 며칠 간의 소크 테스트 중에만 나타나는 동시 스키마 진화 시나리오를 포착하지 못했습니다.
두 번째 접근 방식은 사전 정의된 차터 없이 순수한 탐색 테스트를 제안했습니다. 비록 이 방법이 예상치 못한 행동을 발견하는 최대한의 유연성을 제공했지만, 프로듀서 중복 확인 실패와 같은 중요한 실패 모드의 불일치 있는 커버리지 위험을 초래하여 정확히 한 번 의미론에서의 엣지 케이스를 놓칠 수 있습니다.
우리는 구조화된 테스트 차터와 카오스 엔지니어링 원칙을 결합한 하이브리드 방법론을 선택했습니다. 이 접근 방식은 스키마 호환성 매트릭스에 대한 체계적인 커버리지를 제공하면서 발생하는 행동을 적응적으로 탐색할 수 있었습니다. 우리는 메시지를 최대한 수집할 때 중개인 노드의 롤링 재시작을 수동으로 트리거하여 소비자 지연 및 재조정 패턴을 관찰하고, 동시에 역호환 및 비호환 변경을 통해 스키마를 발전시켜 레지스트리 집행을 검증했습니다.
결과적으로 중복 처리 사건을 없애고 생산에 도달하는 파괴적인 변경을 방지하는 스키마 거버넌스 프로세스가 수립되었습니다. 소비자 그룹은 시뮬레이션된 노드 실패 동안 안정적인 처리량을 유지했으며, 사망 편지 큐는 손상된 거래 메시지를 성공적으로 격리하여 주요 처리 흐름에 영향을 미치지 않았습니다.
브로커가 쓰기를 승인할 때 Kafka 프로듀서 재시도가 정확히 한 번 의미론을 위반하지 않는지를 수동으로 어떻게 검증할 수 있습니까? 네트워크 타임아웃으로 인해 클라이언트 측에서 재시도가 발생할 때입니다.
후보자들은 종종 메시지 메타데이터에서 Producer ID (PID)와 시퀀스 번호를 조사하는 중요성을 간과합니다. 수동 테스트 중에는 프로듀서 및 소비자에 대해 DEBUG 로깅을 활성화하고, Toxiproxy 또는 iptables 규칙을 사용하여 네트워크 지연을 의도적으로 도입해야 합니다. 중복 시퀀스 번호가 Kafka 브로커의 중복 삭제 로직에 의해 거부되도록 하려면 소비자 기록에서 LogAppendTime 및 Offset 값을 확인해야 합니다.
핵심 통찰력은 수동 테스터가 kafka-console-consumer를 사용하여 __consumer_offsets 주제를 직접 조사해야 하며, formatter 플래그를 설정하여 조정자 메타데이터가 올바르게 로그 세그먼트에 나타나는 것을 확인해야 한다는 것입니다.
소비자 그룹에서 비동일 처리 지연을 가진 경우 StickyAssignor와 RangeAssignor를 사용할 때 파티션 할당 불균형을 식별하기 위해 어떤 수동 기술을 사용할 수 있습니까?
많은 테스터는 파티션 분포가 재조정 중 정확히 한 번 보증에 직접적인 영향을 미친다는 것을 인식하지 못합니다. 이를 수동으로 검증하기 위해 Thread.sleep() 변형을 사용하여 인위적으로 지연된 소비자 인스턴스를 생성한 후, 소비자를 추가 및 제거하여 재조정을 유도하면서 kafka-consumer-groups.sh를 통해 consumer group description을 모니터링합니다.
Current-OFFSET, Log-END-OFFSET, LAG 열을 관찰하여 StickyAssignor가 소규모 멤버십변경 동안 파티션 소유권을 유지하는지를 확인해야 합니다. 파티션 간의 지연의 표준 편차를 수동으로 계산하고, 큰 변동은 장애 시나리오 동안 처리 순서 보증을 위반할 수 있는 할당 불균형을 나타냅니다.
자동화된 호환성 검사를 단독으로 의존하지 않고 Schema Registry 호환성 모드 (BACKWARD, FORWARD, FULL)를 어떻게 검증할 것인가?
초보자들은 종종 레지스트리 수준의 호환성 집행과 런타임 역직렬화 동작 간의 구별을 놓칩니다. 특정 호환성 설정으로 스키마 버전을 등록한 후, 이전 스키마 버전을 사용하여 메시지를 생성하고, 새 클라이언트 라이브러리로 소비하면서 수동 테스트를 수행해야 합니다 (그리고 그 반대도 마찬가지입니다).
curl 명령을 사용하여 Schema Registry REST API에 스키마를 등록하고, 호환성 엔드포인트가 예상대로 true 또는 false를 반환하는지 확인합니다. 이후에는 kafka-avro-console-producer를 사용하여 명시적인 스키마 버전으로 생산 시나리오를 시뮬레이트합니다. 중요한 검증은 예상 스키마를 위반하는 메시지를 수신할 때 소비자 애플리케이션에서 SerializationException 처리 과정을 관찰하는 것입니다. 이는 SpecificRecord 구현이 필드를 조용히 삭제하거나 비즈니스 논리를 손상시키는 null 기본 값으로 채우지 않고 우아하게 실패하도록 보장하는 것입니다.