[Kafka] - 8. acks / Batch / Page Cache&Flush

목차

1. Kafka Acks

2. Kafka Batch

3. Page Cache&Flush

 

1. Kafka Acks

---

Acks은 Network에 3hand-shake에서 나오는 개념으로, Data가 안전하게 전송하였는지 여부를 확인하는 용도입니다.

이와 같이 Kafka에서도 동일하게 Message(Data)에 대해 Producer가 Kafka에게 전송이 잘 되었는지 알고 싶어합니다.

 

1-1) Ack

Request가 성공할 떄, 사용되는 Producer에 의해 설정되는 Parameter

Case1) Acks = 0

• Acks가 필요하지 않다는 의미
• 메시지 손실이 있더라도 빠르게 전송하는 경우 외에는 자주 사용되지 않는다.

case1

 

Case2) Acks = 1

• Default 값이다.
• Leader가 Message를 수신하면 Ack 발생
• Follower가 복제 하기 전에 Leader에 장애 발생 시 Message는 손실이 발생
• At most once(최대 한번) 전송을 보장

case2

 

Case3) Acks = -1 / Acks = all

• Leader가 모든 Replica까지 Commit 되면 Ack를 발생
• Leader에 장애가 발생하여도 Data가 손실되지 않는다.
• 대기 시간이 길고, 특정 실패 사례에서 반복되는 Data가 발생될 수 있다.
• At least once(최소 한번) 전송을 보장

case3

1-2) Producer Retry

Network, System 상의 오류를 보완하기 위해 모든 환경에서 재전송에 대한 환경을 구축

Acks=0 일 때는 동작하지 않는다.

대부분의 상황에서 delievery.timeout.ms Command를 통해 제어한다.

Parameter	설명	Default
retries	message를 send하기 위해 재시도하는 함수	Max_int
retry.backoff.ms	재시도 사이에 추가되는 대기시간	100
request.timeout.ms	Producer가 응답을 기다리는 최대 시간	30000(30초)
delievery.timeout.ms	Send() 후 성공,실패 보고하는 시간의 상한	120000(2분)

 

2. Kafka Batch

---

Batch 처리는 Remote Procedure Call(RPC)을 줄여 Broker가 처리하는 작업을 줄여, 더 나은 처리량을 제공한다.

• Kafka의 Producer가 주는 Message의 단위가 1개의 Message마다 전달 시켜 준다고 한다면, 상황에 따라서는 비효율적일 수도 있다.

예를 들어, 100명이 같은 목적지를 간다고 하여보자. 

버스를 타고 가면 타는 곳은 여러 곳이지만, 하나의 버스를 이용하여 도착 할 수 있다.

택시를 타고 가면 각각 타는 곳에서 100개의 택시를 이용하여 도착 할 수 있다.

100개의 택시를 타고 가면 Latency는 줄어들겠지만 그 만큼 100대의 택시가 사용되었으니 Throughput이 높아질 것이다.

그에 반해 버스는 한대의 버스를 사용함으로써, Throughput이 엄청나게 낮아질 것이다.

이와 같이 버스를 이용해서 움직이는 것을 Batch라 생각하면 편하다.

 

1. Linger.ms

• Message가 함께 batch 될 때 까지의 대기 시간
• Default = 0으로, 즉시 보낸다.

2. Batch.size

• 보내기 전 Batch의 최대 크기
• Default = 16KB

일반적으로 Batch는 Linger.ms = 100 , batch.size=1000000

Batch Process

 

Delievery timeout

Producer가 생성한 Message(Record)를 Send() 할 때의 LifeCycle을 표현

Send() 이후에 일어나는 작업의 시간을 의미한다. ( Retry 까지 포함 )

Delievery timeout

Message send 순서 보장

• Retry가 발생하다 보면, 먼저 처리되어야 할 Data들이 이후에 오는 Message보다 늦게 처리 되는 경우가 발생한다.
• 순서가 의미 없다면 상관이 없지만, 순서가 의미 있다면 어떻게 처리해야 하는 것이 옳을까?

 

Multiple in-flight request

max.in.flight.requests.per.connections=5 (default) 라는 값을 이용하여 한번에 처리되어야 할 Batch, Message의 갯수를 정해준다.

 

enable.idempotence

하나의 Batch가 실패 시, 같은 Partition으로 들어오는 Batch들은 모두 실패 처리하게 한다.(OutofOrderSequenceException)

 

• 아래 그림은 Multiple in-flight request=5개로 지정된 예시이다.
• 이 상황에서 Batch0이 실패하게 되고, Batch1이 성공하게 되면 Commit log에는 순서가 보장이 되지 않는다.

 

Before

After

 

3. Page Cache & Flush

---

• Broker가 실제 Disk에 저장되는 과정

 

• Message(data)는 Partition에 기록된다.
• Partition은 Log Segment File로 구성(1GB마다 새로운 Segment 생성)
• 성능을 위해 Log Segment는 OS 내에 Page Cache에 기록한다.
• Log File에 저장된 Message Data 형식은 Broker가 Producer로 부터 수신한 것과 Consumer에게 보내는 것과 동일하여 *Zero-Copy 가 가능하다.
• Page Cache가 Disk로 Flush 되는 경우는 Broker가 완전 종료되거나 Os의 Flusher Thread가 실행될 때.

 

*Zero-Copy

• 전송된 Data가 User Space 영역에 복사하지 않고, CPU 개입 없이 Page cache와 Network buffer 사이에서 직접 전송 되는 것이다. -> 이로 인해 Broker의 HeapMemory를 절약하여 처리량을 높일 수 있다.

Zero Copy

 

Normal Send Process

 

그렇다면, Flush 되기 전에 Broker에게 장애가 발생하면 어떻게 될까?

• OS는 Disk로 Flush하기 전에 Broker의 System 장애가 발생하게 되면, Data를 손실한다.
• Partition이 Replication이 되어야만, 복구 가능

 

Flush 정책

• 마지막 Flush 이후의 Message 수(log.flush.interval.messages), 시간(log.flush.interval.ms)로 Flush(Fsync)를  Trigger로 설정 가능하다.
• Kafka는 Os의 Background Flush(pdflush)를 효율적으로 허용하는 것을 선호하기 때문에 위 설정 값을 무한(Fsync 비활성화)으로 처리하도록 권장
• *.log file에는 disk로 Flush된 Data와 아직 Flush되지 않은 Page Cache에 있는 Data가 표시된다.