카프카는 어떻게 현실이 되었나

헤이 하브르!

저는 Tinkoff 팀에서 일하고 있는데, 이 팀은 자체 알림 센터를 개발하고 있습니다. 저는 주로 Spring boot를 사용하여 Java로 개발하고 프로젝트에서 발생하는 다양한 기술적 문제를 해결합니다.

대부분의 마이크로서비스는 메시지 브로커를 통해 비동기적으로 서로 통신합니다. 이전에는 IBM MQ를 브로커로 사용했는데, 이는 더 이상 부하를 감당할 수 없었지만 동시에 높은 전달 보장은 제공했습니다.

대체 솔루션으로 Apache Kafka가 제안되었는데, 이는 확장성이 뛰어난 잠재력을 가지고 있지만, 안타깝게도 다양한 시나리오에 맞게 구성에 대한 사실상 개별적인 접근 방식이 필요합니다. 게다가, 카프카에서 기본적으로 작동하는 최소 한 번 전달 메커니즘은 처음부터 필요한 수준의 일관성을 유지하는 것을 허용하지 않았습니다. 다음으로, Kafka 구성에 대한 경험을 공유하겠습니다. 특히, 정확히 한 번만 전달되도록 설정하고 실행하는 방법을 알려드리겠습니다.

보장된 배송 및 기타

아래에 설명된 설정은 기본 연결 설정으로 인해 발생할 수 있는 여러 문제를 방지하는 데 도움이 됩니다. 하지만 먼저 디버깅을 용이하게 할 수 있는 한 가지 매개변수에 주의를 기울이고 싶습니다.

이것이 도움이 될 것입니다 클라이언트.아이디 생산자와 소비자를 위해. 처음에는 애플리케이션 이름을 값으로 사용할 수 있는 것처럼 보이며 대부분의 경우 제대로 작동합니다. 하지만 애플리케이션에서 여러 Consumer를 사용하고 이를 동일한 client.id로 설정하면 다음과 같은 경고가 발생합니다.

org.apache.kafka.common.utils.AppInfoParser — Error registering AppInfo mbean javax.management.InstanceAlreadyExistsException: kafka.consumer:type=app-info,id=kafka.test-0

Kafka를 사용하는 애플리케이션에서 JMX를 사용하려는 경우 문제가 될 수 있습니다. 이 경우에는 애플리케이션 이름과 주제 이름 등을 조합하여 client.id 값으로 사용하는 것이 가장 좋습니다. 구성 결과는 명령 출력에서 ​​확인할 수 있습니다. 카프카-소비자-그룹 Confluent 유틸리티에서:

이제 보장된 메시지 전달 시나리오를 살펴보겠습니다. Kafka Producer에는 매개변수가 있습니다. Acks이를 통해 클러스터 리더가 메시지가 성공적으로 작성되었다고 간주해야 하는 확인 횟수를 구성할 수 있습니다. 이 매개변수는 다음 값을 가질 수 있습니다.

• 0 - 확인이 고려되지 않습니다.
• 1은 기본 매개변수이고, 1개의 복제본만 확인하면 됩니다.
• -1 — 모든 동기화된 복제본의 확인이 필요합니다(클러스터 설정) min.insync.replicas).

나열된 값을 보면 acks가 -1일 때 메시지가 손실되지 않을 것이라는 가장 강력한 보장이 제공된다는 것이 분명합니다.

우리 모두 알다시피, 분산 시스템은 신뢰할 수 없습니다. 일시적인 실패로부터 보호하기 위해 Kafka Producer는 다음 매개변수를 제공합니다. 재시도이를 통해 재시도 횟수를 설정할 수 있습니다. 배달.시간 초과.ms. retries 매개변수의 기본값은 Integer.MAX_VALUE(2147483647)이므로 delivery.timeout.ms만 변경하면 메시지 재전송 횟수를 조정할 수 있습니다.

정확히 한 번 배달로 전환

나열된 설정을 사용하면 제작자가 높은 보장성을 갖춘 메시지를 전달할 수 있습니다. 이제 Kafka 토픽에 단 하나의 메시지 사본만 기록되도록 하는 방법에 대해 알아보겠습니다. 가장 간단한 경우에는 Producer에 매개변수를 설정해야 합니다. enable.idempotence 사실입니다. 멱등성은 단일 주제의 특정 파티션에 단 하나의 메시지만 기록됨을 보장합니다. 멱등성을 활성화하기 위한 전제 조건은 값입니다. acks = all, 재시도 > 0, 연결당 최대 비행 중 요청 수 ≤ 5. 개발자가 이러한 매개변수를 설정하지 않으면 위에 지정된 값이 자동으로 설정됩니다.

멱등성이 구성되면 항상 동일한 메시지가 동일한 파티션에 저장되도록 해야 합니다. 이 작업은 Producer에서 partitioner.class 키와 매개변수를 구성하여 수행할 수 있습니다. 열쇠부터 시작해 보겠습니다. 각 배송마다 동일해야 합니다. 이는 원본 메시지의 비즈니스 식별자를 사용하면 쉽게 달성할 수 있습니다. partitioner.class 매개변수의 기본값은 다음과 같습니다. 기본 파티셔너. 이 기본 분할 전략을 사용하면 다음과 같이 진행됩니다.

• 메시지를 보낼 때 파티션이 명시적으로 지정되면 해당 파티션을 사용합니다.
• 파티션이 지정되지 않았지만 키가 지정된 경우 키의 해시로 파티션을 선택합니다.
• 파티션과 키가 지정되지 않으면 파티션을 하나씩 선택합니다(라운드 로빈).

또한 키와 멱등성을 사용하여 매개변수를 보냅니다. 연결당 최대 비행 중 요청 수 = 1 소비자에게 메시지를 순서대로 처리해 줍니다. 클러스터에 액세스 제어가 구성된 경우 해당 주제에 대한 멱등 쓰기 권한이 필요하다는 점도 기억해 두는 것이 좋습니다.

갑자기 키에 의한 멱등 전송 기능이 부족해지거나 생산자 측의 로직이 서로 다른 파티션 간의 데이터 일관성을 유지해야 하는 경우, 트랜잭션이 해결책이 될 수 있습니다. 또한 체인 트랜잭션을 사용하면 Kafka의 레코드를 데이터베이스의 레코드와 조건부로 동기화할 수 있습니다. 생산자에게 트랜잭션 전송을 활성화하려면 멱등성을 가져야 하며 추가로 다음을 지정해야 합니다. transactional.id. Kafka 클러스터에 액세스 제어가 구성된 경우 멱등 쓰기와 같은 트랜잭션 쓰기에는 쓰기 권한이 필요하며, 이 권한은 transactional.id에 저장된 값을 사용하여 마스크를 통해 부여할 수 있습니다.

공식적으로는 애플리케이션 이름과 같은 모든 문자열을 트랜잭션 식별자로 사용할 수 있습니다. 하지만 동일한 transactional.id로 동일한 애플리케이션의 여러 인스턴스를 시작하면 Kafka가 처음 실행한 인스턴스를 좀비 프로세스로 간주하여 오류가 발생하면서 중지됩니다.

org.apache.kafka.common.errors.ProducerFencedException: Producer attempted an operation with an old epoch. Either there is a newer producer with the same transactionalId, or the producer's transaction has been expired by the broker.

이 문제를 해결하려면 환경 변수에서 얻은 호스트 이름을 애플리케이션 이름에 접미사로 붙입니다.

프로듀서는 구성되었지만, Kafka의 트랜잭션은 메시지 범위만 관리합니다. 거래 상태와 관계없이 메시지는 즉시 주제로 전송되지만 추가적인 시스템 속성이 있습니다.

이러한 메시지가 소비자에게 미리 읽히지 않도록 하려면 매개변수를 설정해야 합니다. 격리 수준 read_committed 값으로. 이러한 소비자는 이전과 마찬가지로 비트랜잭션 메시지를 읽을 수 있으며, 커밋 이후에만 트랜잭션 메시지를 읽을 수 있습니다.
위에 나열된 모든 설정을 완료했다면, 정확히 한 번 배송이 설정된 것입니다. 축하해요!

하지만 한 가지 더 중요한 점이 있습니다. 위에서 구성한 Transactional.id는 실제로는 트랜잭션 접두사입니다. 거래 관리자에 일련번호가 추가됩니다. 수신된 식별자는 다음에 발급됩니다. transactional.id.expiration.msKafka 클러스터에 구성되고 기본값은 "7일"입니다. 이 시간 동안 애플리케이션이 메시지를 수신하지 못한 경우 다음 거래를 보내려고 하면 다음과 같은 메시지가 표시됩니다. InvalidPidMappingException. 이후, 거래 조정자는 다음 거래에 대한 새로운 일련번호를 발급합니다. 그러나 InvalidPidMappingException이 올바르게 처리되지 않으면 메시지가 손실될 수 있습니다.

합계 대신

보시다시피, 단순히 카프카에 메시지를 보내는 것만으로는 충분하지 않습니다. 여러 매개변수를 조합하여 선택해야 하며, 빠른 변경에 대비해야 합니다. 이 글에서는 정확히 한 번 전달 설정을 자세히 보여드리고, 우리가 겪은 몇 가지 client.id와 transactional.id 구성 문제에 대해 설명하고자 했습니다. 아래는 생산자 및 소비자 설정에 대한 요약입니다.

프로듀서 :

1. acks = 모두
2. 재시도 > 0
3. enable.idempotence = true
4. 연결당 최대 비행 중 요청 수 ≤ 5(1 - 주문된 전송의 경우)
5. transactional.id = ${application-name}-${hostname}

소비자:

1. 격리 수준 = 읽기 커밋됨

향후 애플리케이션에서 오류를 최소화하기 위해, 우리는 스프링 구성에 자체 래퍼를 만들었으며, 여기에 나열된 일부 매개변수의 값이 이미 설정되어 있습니다.

다음은 자율 학습을 위한 몇 가지 자료입니다.

• KIP-98 - 정확히 한 번 전달 및 트랜잭션 메시징
• 설정 설명

출처 : habr.com