Kafka에서 데이터 저장 방법 이해

Kafka는 사용자가 토픽에 대한 보존 한계를 구성할 수 있도록 합니다.

retention.bytes 구성은 토픽의 파티션마다 메시지에 대해 할당되는 총 바이트 수입니다. 이 값을 초과하면 Kafka 는 가장 오래된 메시지를 삭제합니다. 따라서 예를 들어, 일반적으로 하루에 200MB의 메시지를 단일 파티션 토픽으로 전송하고 이를 5일동안 보존하려면 retention.bytes 를 1GB (200MB x 5일) 로 설정하십시오.

이 파티션이 10개를 초과하는 경우 retention.bytes = 100MB (1GB/10개의 파티션) 로 설정합니다.

내부적으로 Kafka가 각 파티션을 로그 세그먼트로 분할합니다. 이는 다시 log.segment.size를 설정할 수 있는 특성이며, 기본값은 512MB입니다. Kafka 가 가장 오래된 메시지를 삭제한다고 언급했을 때 실제로는 가장 오래된 로그 세그먼트를 삭제합니다. 이러한 이유로 Kafka 는 retention.bytes 구성을 충족시키는 데 필요한 로그 세그먼트 수 외에 하나의 추가 로그 세그먼트를 위한 공간을 보존해야 합니다.

다음 예제를 참조하십시오.

 retention.bytes = 1 GB
 log.segment.size = 512 MB
 Kafka needs approximately 1.5 GB per partition for the topic storage.

 retention.bytes = 100 MB
 log.segment.size = 512 MB
 Kafka needs approximately 1 GB per partition for the topic storage.

인덱스의 경우 파티션당 더 많은 스토리지가 필요합니다. 각 로그 세그먼트의 경우 Kafka는 두 개의 인덱스도 저장합니다. 해당 크기는 segment.index.size에 의해 정의되며, 이는 또한 구성 가능하며 기본값은 10MB입니다. 참조를 위해 인덱스에서 사용하는 스토리지는 다음과 같이 계산됩니다.

 2 x number.of.log.segments x segment.index.size

여기서,

 number.of.log.segments = floor(retention.bytes/log.segment.size) + 1

Event Streams에서 스토리지 미러링

토픽 작성, 파티션 작성 또는 토픽 구성 변경과 같은 토픽 관리 조작을 수행할 때 Event Streams 는 조작을 충족시키기 위해 충분한 스토리지가 사용 가능한지 확인합니다. 이를 수행하기 위해 각 주제에 대해 Event Streams 는 다음 메소드를 사용하여 각 주제에 대해 "예약된 크기" 를 계산합니다.

cleanup.policy 설정이 compact 인 토픽의 경우 각 파티션에 사용되는 예약 크기는 항상 1GB입니다. 토픽에 대한 cleanup.policy 가 compact 로 설정되면 retention.bytes 또는 retention.ms 토픽 설정에 사용되는 모든 값이 무시됩니다.

cleanup.policy 설정이 delete 또는 compact, delete 인 토픽의 경우 각 파티션에 사용되는 예약 크기는 다음과 같이 계산됩니다.

 Reserved size = retention.bytes + log.segment.size + (2 x segment.index.size x number.of.log.segments)

여기서,

 number.of.log.segments = floor(retention.bytes/log.segment.size) + 1

총 예약 스토리지 백분율은 ibm_eventstreams_instance_reserved_disk_space_percent 메트릭 에 의해 IBM Cloud Monitoring 에도 표시됩니다.

새 토픽을 작성하거나 기존 토픽에 파티션을 추가하는 요청이 Event Streams 인스턴스에 대해 구성된 스토리지의 90% ^[1] 를 초과하는 총 예약 스토리지 양을 초래하는 경우 거부됩니다. 거부된 요청은 인스턴스에 대해 예약된 스토리지 한계에 도달했음을 설명하는 PolicyViolation 오류를 수신합니다. 예약 스토리지 한계에 도달하면 토픽을 삭제하거나 추가 토픽을 작성하기 전에 인스턴스에 대해 구성된 스토리지의 양을 늘려야 합니다.

예약된 크기 계산은 Kafka 스토리지 요구사항이 업데이트되는 경우 나중에 변경될 수 있습니다.

예제

명확하지 않은 효과는 Kafka 가 토픽 구성에 따라 예상보다 더 많은 스토리지를 예약할 수 있다는 것입니다. 다음 예제를 참조하십시오.

1. 1GB의 retention.bytes가 있는 토픽 및 512MB의 로그 세그먼트 크기:

   하나의 패턴을 사용하여 스토리지의 약 1.5GB를 예약합니다.
   이 경우 예약된 크기는 보유 크기보다 훨씬 더 큽니다.

2. 50GB의 retention.bytes가 있는 토픽 및 512MB의 로그 세그먼트 크기:

   하나의 패턴을 사용하여 스토리지의 약 50.5GB를 예약합니다.

   이 경우 예약된 크기는 보유 크기와 거의 비슷합니다.

3. 1GB의 retention.bytes가 있는 토픽 및 128MB의 로그 세그먼트 크기:

   하나의 패턴을 사용하여 스토리지의 약 1.1GB를 예약합니다.

   이 경우 예약된 크기는 보유 크기와 거의 비슷합니다.