Kafka - Kafka Producing 성능 비교와 멱등성 조건

 

Producing 성능 비교의 두가지 Factor - Acks, Synchronized/Asynchronized

	acks=all 동기	acks=all 비동기	acks=1 동기	acks=1 비동기
비교 조건	acks=all Synchronized	acks=all Asynchronized	acks=1 Synchronized	acks=1 Asynchronized
기타 조건	replication factor: 2 enable.idempotence: true max.in.flight.requests.per.connection: 5 retries: 3 reconnect.backoff.max.ms: 1000L batch.size: 5KB linger.ms: 10ms compression.type: gizp	replication factor: 2 enable.idempotence: true max.in.flight.requests.per.connection: 5 retries: 3 reconnect.backoff.max.ms: 1000L batch.size: 5KB linger.ms: 10ms compression.type: gizp	replication factor: 2 enable.idempotence: false max.in.flight.requests.per.connection: 5 retries: 3 reconnect.backoff.max.ms: 1000L batch.size: 5KB linger.ms: 10ms compression.type: gizp	replication factor: 2 enable.idempotence: false max.in.flight.requests.per.connection: 5 retries: 3 reconnect.backoff.max.ms: 1000L batch.size: 5KB linger.ms: 10ms compression.type: gizp
count	10,808	10,808	10,808	10,808
duration (ms)	286242 ms	4581 ms	247904 ms	1149 ms
duration (minute)	4.7707 minute	0.07635 minute	4.13173333 minute	0.01915 minute

 

Producing 성능 비교: acks=1 비동기 > acks=all 비동기 > acks=1 동기 > acks=all 동기

acks 설정에 따른 성능 차이는 topic 의 replica 수에 따라 달라질 수는 있나, replica factor: 2 기준으로 성능 차이는 15%  로 파악했습니다.

성능에 큰 영향을 주는 요소는 동기/비동기 여부입니다. 동기/비동기에 따른 정확한 성능 비교는 어렵지만 55~70 배 정도 차이나는 것으로 확인했습니다.

처리 속도만 고려하면 비동기 방식이 훨씬 좋습니다. 1만건 처리하는데 약 1초 밖에 소요 되지 않습니다.

 

Kafka Producer Default 설정(2.x 기준): acks=1 비동기

 

Producer Default 설정이 가장 빠른 방식이라, 단순 메시지 Producing 만 한다면, 설정 변경은 필요 없습니다.

하지만 Producing 이후 메시지 결과 여부에 따른 비지니스 로직이 실행되거나, DB 에 Producing  결과 여부를 저장해야하는 경우 Producer 설정을 변경하고 성능 체크를 해야합니다.

가장 좋은 방법은 Producing 된 메시지의 콜백을 받지 않아도 되는 구조로 설계하는 것이 좋으나, 콜백을 받아야하는 구조라면 최적의 Producer 설정을 찾아야합니다.

 

 

멱등성 보장 조건

Kafka Produce 에서 메시지의 exactly once 을 달성하기 위해서는 멱등성을 가지는 Producer 를 활성화 시켜야합니다.

Produce 옵션 중에 'enable.idempotence' 의 값이 true 로 하면 멱등성을 보장할 수 있게 됩니다.

다만, 해당 옵션을 사용하게 된다면 성능이 저하되는 것을 일부 감수해야하며, 기타 선행 옵션들도 세팅 해주어야합니다.

enable.idempotence definition

When set to ‘true’, the producer will ensure that exactly one copy of each message is written in the stream. 

If ‘false’, producer retries due to broker failures, etc., may write duplicates of the retried message in the stream.

Note that enabling idempotence requires 'max.in.flight.requests.per.connection' to be less than or equal to 5 (with message ordering preserved for any allowable value), retries to be greater than 0, and acks must be ‘all’.

 

Idempotence is enabled by default if no conflicting configurations are set. 

If conflicting configurations are set and idempotence is not explicitly enabled, idempotence is disabled.

If idempotence is explicitly enabled and conflicting configurations are set, a ConfigException is thrown.

Kafka 3.0 이후 부터는  enable.idempotence=true, acks=all 이 기본 옵션으로 설정되어있습니다.

Kafka 3.0 이후 버전을 사용하시는 경우에는 멱등성 보장과 관련된 옵션에 크게 신경 쓰지 않아도 되지만, Kafka 2.x 대 버전을 사용 중이라면 직접 메시지 유실과 메시지 중복을 방지하기 위해서 멱등성 옵션을 사용하는 것을 권장합니다.

 

위의 공식 문서에서 언급한 것 처럼 (acks must be ‘all’)  acks=all 옵션이 선행되어야합니다. 

 

acks option

acks 옵션이란? Producer 가 Broker 에 메시지를 전송한 후 요청 완료를 결정하는 옵션입니다.

acks=0

• acks=0 으로 설정되면 Producer는 Broker 로부터 어떠한 응답(Ack)도 기다리지 않습니다. 
• 즉, Broker 단에 제대로 전달되었는지 확인하지 않습니다.
• Producing 을 하면 저장이 성공한 것으로 즉시 처리합니다.
• 메시지 손실이 다소 있더라도 빠르게 메시지를 보내야 하는 경우에 사용됩니다.

acks=1

• acks=1 으로 설정되면 Producer는 Broker Leader 의 응답 확인(Ack)만 기다립니다.   
• 즉, Broker 의 Ack 만으로 전송 완료 처리합니다.
• 이 경우 리더가 메시지를 Ack를 보낸 후, Follower가 복제하기 전에 Leader 에 장애가 발생하면 메시지가 손실됩니다.
• At most once(최대 한 번) 전송을 보장합니다.
• Kafka 2.8 까지는 acks=1 이 default 입니다.

acks=all (-1)

• acks=all 으로 설정되면 Producer는 Broker Leader 와 Follower 모든 응답 확인(Ack)을 기다립니다.
• 즉, 적어도 하나의 동기화된 Follower 이 살아 있는 한 메시지가 손실되지 않을 것임을 보장합니다.
• 가장 강력한 보장 방식이며, At least once(최소 한 번) 전송을 보장합니다.
• 다만, 모든 Follower 의 응답 확인을 받아야해서 다소 느릴 수 있습니다.
• Kafka 3.0 이후로 acks=all 이 default 입니다.

acks=all 옵션으로 메시지 손실을 없게 함으로써, At least once(최소 한 번) 전송을 가능하게 합니다.

이는 멱등성의 필수 조건인 옵션입니다.

 

enable.idempotence 옵션을 true 로 사용하기 위해서는 acks=all 옵션 외에도 

max.in.flight.requests.per.connection 는 5 이하여야하고 retries 는 1이상으로 설정해야합니다.

enable.idempotence=true 로 적용되면 중복으로 메시지를 Producing 하는 경우가 없어집니다. 

네트워크 오류로 인한 retry 시도로 중복 메시지가 발송될 경우, 메시지의 Produce ID 와 시퀀스 번호를 확인하여 한번만 저장되도록 처리합니다.

즉, 여러 번의 전송 시도가 있더라도 최종적으로 메시지가 한 번만 기록되도록 보장합니다. (exactly once)

 

정리하면, enable.idempotence=true 와 acks=all 로 설정해야, 메시지 유실과 메시지 중복을 막을 수 있습니다.

이를 통해 멱등성 보장과 메시지의 exactly once 을 보장할 수 있습니다.

 

다만, 해당 옵션을 사용하게 되면 메시지 처리가 느려집니다.

'메시지 중복과 유실 방지' 는 메시지의 빠른 처리와 'trade-off 관계' 입니다.

 

enable.idempotence=true 와 acks=all 옵션을 사용하게 된다면, 느려지는 메시지 Producing 속도를 보완하기 위해,

Produce Batch 옵션을 추가적으로 적용해야합니다.

어느 정도 배치 처리를 할 것인지는 메시지의 사이즈에 따라 달라지며, 적정 Batch size 를 결정하기 위해서는 지속적인 성능 테스트가 필요합니다.