[kafka] topic config 설정(retention.ms, segment.bytes)

kafka topic의 데이터는 일반적인 파일로 저장이 된다. 파일로 저장되기 때문에 disk 용량을 차지하게 된다.

데이터의 양이 많을 경우 disk가 꽉 차서 문제가 되기도 한다.

그래서 kafka broker는 토픽에 대한 retention time, retention byte 등의 옵션을 제공한다.

retention 관련 옵션은 얼마 기간동안까지 topic 데이터를 유지할지, 어느정도 데이터의 양을 유지할지를 정한다.

---

먼저 환경을 미리 만들어 두었다.

configTopic이라는 topic을 만들고 여기에 110MB 정도의 데이터를 producing해두었다. 1kb 짜리 토픽을 110 * 1024번 producing 해두었다.

topic에 필요한 config도 미리 설정해두었다.

topic을 describe해보면 Configs에 설정한 config들이 나온다.(안나오는 것들은 기본값)

$ kafka-topics.sh --describe --bootstrap-server localhost:9092  --topic configTopic
Topic: configTopic	TopicId: Sf2J1AcQR_O5Ml65SGYFgw	PartitionCount: 1	ReplicationFactor: 1	Configs: segment.bytes=10485760,retention.ms=600000,retention.bytes=5242880
	Topic: configTopic	Partition: 0	Leader: 0	Replicas: 0	Isr: 0	Elr: 	LastKnownElr:

 

데이터가 저장된 위치를 확인해보자.

위치 뿐만 아니라 partition별 사이즈도 알 수 있다. 지금은 파티션은 하나만 만들어두어서 configTopic-0으로 되어있다.

$ kafka-log-dirs.sh --bootstrap-server localhost:9092 --describe --topic-list configTopic
Querying brokers for log directories information
Received log directory information from brokers 0
{"brokers":[{"broker":0,"logDirs":[{"partitions":[{"partition":"configTopic-0","size":116469468,"offsetLag":0,"isFuture":false}],"error":null,"logDir":"/bitnami/kafka/data"}]}],"version":1}

logDir이라고 나와있는 곳을 방문해보자.

$ cd /bitnami/kafka/data
$ ls
__cluster_metadata-0   __consumer_offsets-15  __consumer_offsets-22  __consumer_offsets-3   __consumer_offsets-37  __consumer_offsets-44  __consumer_offsets-7	       myTopic-0   myTopic-16  myTopic-6
__consumer_offsets-0   __consumer_offsets-16  __consumer_offsets-23  __consumer_offsets-30  __consumer_offsets-38  __consumer_offsets-45  __consumer_offsets-8	       myTopic-1   myTopic-17  myTopic-7
__consumer_offsets-1   __consumer_offsets-17  __consumer_offsets-24  __consumer_offsets-31  __consumer_offsets-39  __consumer_offsets-46  __consumer_offsets-9	       myTopic-10  myTopic-18  myTopic-8
__consumer_offsets-10  __consumer_offsets-18  __consumer_offsets-25  __consumer_offsets-32  __consumer_offsets-4   __consumer_offsets-47  bootstrap.checkpoint	       myTopic-11  myTopic-19  myTopic-9
__consumer_offsets-11  __consumer_offsets-19  __consumer_offsets-26  __consumer_offsets-33  __consumer_offsets-40  __consumer_offsets-48  cleaner-offset-checkpoint    myTopic-12  myTopic-2   recovery-point-offset-checkpoint
__consumer_offsets-12  __consumer_offsets-2   __consumer_offsets-27  __consumer_offsets-34  __consumer_offsets-41  __consumer_offsets-49  configTopic-0		       myTopic-13  myTopic-3   replication-offset-checkpoint
__consumer_offsets-13  __consumer_offsets-20  __consumer_offsets-28  __consumer_offsets-35  __consumer_offsets-42  __consumer_offsets-5   log-start-offset-checkpoint  myTopic-14  myTopic-4   smallTopic-0
__consumer_offsets-14  __consumer_offsets-21  __consumer_offsets-29  __consumer_offsets-36  __consumer_offsets-43  __consumer_offsets-6   meta.properties	       myTopic-15  myTopic-5

내가 생성한 토픽들도 있고 아닌 토픽들도 있다.(기본으로 제공해주는 토픽들도 있다.)

나의 토픽이 configTopic-0이기에 여기로 들어가보자.

$ cd configTopic-0/
I have no name!@bitnami-kafka-controller-0:/bitnami/kafka/data/configTopic-0$ ls
00000000000000000000.index	00000000000000019339.index	00000000000000029009.timeindex	00000000000000048349.snapshot	00000000000000067689.log	00000000000000087029.index	00000000000000096699.timeindex
00000000000000000000.log	00000000000000019339.log	00000000000000038679.index	00000000000000048349.timeindex	00000000000000067689.snapshot	00000000000000087029.log	00000000000000106369.index
00000000000000000000.timeindex	00000000000000019339.snapshot	00000000000000038679.log	00000000000000058019.index	00000000000000067689.timeindex	00000000000000087029.snapshot	00000000000000106369.log
00000000000000009669.index	00000000000000019339.timeindex	00000000000000038679.snapshot	00000000000000058019.log	00000000000000077359.index	00000000000000087029.timeindex	00000000000000106369.snapshot
00000000000000009669.log	00000000000000029009.index	00000000000000038679.timeindex	00000000000000058019.snapshot	00000000000000077359.log	00000000000000096699.index	00000000000000106369.timeindex
00000000000000009669.snapshot	00000000000000029009.log	00000000000000048349.index	00000000000000058019.timeindex	00000000000000077359.snapshot	00000000000000096699.log	leader-epoch-checkpoint
00000000000000009669.timeindex	00000000000000029009.snapshot	00000000000000048349.log	00000000000000067689.index	00000000000000077359.timeindex	00000000000000096699.snapshot	partition.metadata

index, log, snapshot 등등 많은 정보가 이곳에 저장되어있다.

실제로 데이터가 저장된 부분은 .log의 파일이다.

log파일만 확인해보자.

$ ls *.log -lh
-rw-r--r-- 1 1001 1001 9.6M Mar  9 07:51 00000000000000000000.log
-rw-r--r-- 1 1001 1001 9.6M Mar  9 07:51 00000000000000009669.log
-rw-r--r-- 1 1001 1001 9.6M Mar  9 07:51 00000000000000019339.log
-rw-r--r-- 1 1001 1001 9.6M Mar  9 07:51 00000000000000029009.log
-rw-r--r-- 1 1001 1001 9.6M Mar  9 07:51 00000000000000038679.log
-rw-r--r-- 1 1001 1001 9.6M Mar  9 07:51 00000000000000048349.log
-rw-r--r-- 1 1001 1001 9.6M Mar  9 07:51 00000000000000058019.log
-rw-r--r-- 1 1001 1001 9.6M Mar  9 07:51 00000000000000067689.log
-rw-r--r-- 1 1001 1001 9.6M Mar  9 07:51 00000000000000077359.log
-rw-r--r-- 1 1001 1001 9.6M Mar  9 07:51 00000000000000087029.log
-rw-r--r-- 1 1001 1001 9.6M Mar  9 07:51 00000000000000096699.log
-rw-r--r-- 1 1001 1001 6.2M Mar  9 07:51 00000000000000106369.log

파일들이 9.6M가 될때마다 새로운 파일을 만들었다.(9.9M가 될때마다 만들어야할 줄 알았는데 9.6M에서 새로운 파일을 만들었다.)

이 각각의 파일을 segment라고 한다.

이 segment들은 위에서 확인한 segment.bytes의 영향을 받는다. 이 segment들은 우리가 설정한 segment.byte보다 클 수 없다.

기본값은 1GB인데 상황에 따라 적절히 조절하면 된다.

---

실제로 운영하는데 많은 topic이 있는데 저장소의 공간이 16GB밖에 안되었다. segment.bytes의 기본값이 1GB다 보니 토픽들의 데이터는 쌓여가는데 1GB가 넘지 않으니 segment들이 삭제 되지 않았다. (현재 log가 쌓이는 segment를 active segment라고 하는데 active segment는 지워지거나 분할되지 않는다.) 얼마간의 시간이 지난 후 topic segment 사이즈의 합이 16GB를 넘어 시스템이 죽는 상황이 있었다. 그래서 segment.bytes와 retention time 등을 조절하여 저장소가 다 차지 않도록 설정했다.

---

얼마간의 시간이 지난 후 segment 목록을 확인했는데 다 삭제되고 아래만 남았다.

$ ls -lh
total 12K
-rw-r--r-- 1 1001 1001   0 Mar  9 08:06 00000000000000112640.log
-rw-r--r-- 1 1001 1001  10 Mar  9 08:06 00000000000000112640.snapshot
-rw-r--r-- 1 1001 1001 10M Mar  9 08:11 00000000000000112640.timeindex
-rw-r--r-- 1 1001 1001  13 Mar  9 08:06 leader-epoch-checkpoint
-rw-r--r-- 1 1001 1001  43 Mar  9 07:50 partition.metadata

이유는 간단하다. retention.ms가 600000(10분)이어서 10분이 지난 후 segment들이 삭제가 되었다.

그러나 현재 active상태인 active segment는 사라지지 않는다.

 

kafka topic의 config를 적절히 조절하면 운영하면서 저장소가 꽉차 문제가 발생하는 일은 없을것이다.

 

참고:

• Topic 설정 관련 명령어