[Kafka] kafka에 대하여 알아보자 - 1

kafka에 대하여 알아보자

요즈음 여러 서버개발자 채용공고에 공통적으로 나타나는 기술중엔 kafka가 있습니다.
이전에는 kafka가 message queue라는 것만 알고, 이를 왜 사용하는지 이해하지 못했는데 시간이 난 김에 한번 공부해보려 합니다.

kafka란?

• kafka란 데이터를 제공하는 sourceApplication과 데이터를 이용하는 targetApplication의 커플링을 약하게 하기 위해 나타났습니다.
• sourceApplication -> targetApplication의 형태로 이동하던 데이터를 sourceApplication -> kafka -> targetApplication의 형태로 중간에 kafka가 위치하게 됩니다.
• kafka는 json, tsv 등의 여러 포맷의 데이터를 받고, 전송할 수 있습니다.
• kafka에는 topic이라는 것이 있는데, 이 topic은 queue의 형태로 데이터를 받으면 topic안에 적재됩니다.
• topic에 데이터를 넣는 역할을 producer이라 합니다.
• producer을 통해 topic에 들어간 데이터를 가져가는 역할을 consumer이라 합니다.
• producer과 consumer은 라이브러리로 되어 있어 spring 등의 프로그램에서 구현이 가능합니다.

토픽(topic)이란?

• kafka에 다양한 데이터가 입력될 때, 데이터가 들어가는 공간을 topic이라 합니다.
• 하나의 kafka에는 여러 개의 topic을 생성할 수 있습니다.
• topic은 이름을 가질 수 있습니다.
  • 이러한 topic의 이름을 이용해 원하는 topic에 접근할 수 있습니다.
  • 어떠한 데이터를 해당 topic에 담는지 명확하게 명시한다면 추후 유지보수 시에 편리하게 관리할 수 있습니다.
• 하나의 topic은 여러 개의 파티션으로 구셩합니다.
  • 파티션 번호는 0부터 시작하여 1씩 등차로 증가합니다.
  • 하나의 파티션은 큐와 같이 끝에서부터 데이터가 쌓이게 됩니다.
• topic에 consumer가 붙게 된다면 topic의 queue의 끝부터 데이터를 가져가게 됩니다.
  • 더 이상 데이터가 들어오지 않는다면 consumer은 새로운 데이터가 들어올 때 까지 대기하게 됩니다.
• consumer가 데이터를 가져가더라도 데이터는 삭제되지 않습니다.
  • consumer가 데이터를 가져가는 과정은 index를 이용합니다.
• 컨슈머 그룹이 다른 컨슈머가 동일한 topic에 붙는다면 다시 0번 데이터부터 가져가서 사용할 수 있습니다.
  • auto.offset.reset = earlist가 설정되어 있어야 합니다.
  • 이렇게 이미 사용한 데이터를 다시 사용할 수 있다는 것은 카프카를 사용하는 아주 중요한 이유이기도 합니다.
• 파티션이 여러개일 때에
  • topic안의 파티션이 여러개인 경우에는 producer가 데이터를 보낼 때 키를 지정해 원하는 파티션에 데이터를 넣을 수 있습니다.
  • 하지만 키를 지정하지 않고 기본 파티셔너를 사용하는 경우 라운드 로빈(Round robin)으로 데이터를 할당하게 됩니다.
  • 키가 있고, 기본 파티셔너를 이용하는 경우에는 키의 해시값을 구하고, 특정 파티션에 할당하게 됩니다.
• 파티션을 늘리는 것은 매우 조심해야 합니다.
  • 파티션을 늘리는 것은 가능하지만 줄이는 것은 불가능하기 때문입니다.
• 파티션을 늘리면 컨슈머의 개수를 늘려서 데이터 처리를 분산시킬 수 있습니다.
• 파티션의 레코드는 언제 삭제될까?
  • log.retention.ms 옵션을 이용해 최대 record 보존 시간을 설정할 수 있습니다.
  • log.retention.byte 옵션을 이용해 최대 record 보존 크기(byte단위)를 설정할 수 있습니다.

broker, replication, ISR(In-Sync-Replication)

broker

• broker은 카프카가 설치되어 있는 서버의 단위를 말합니다.
  • 보통 3개 이상의 broker로 구성하는 것을 권장합니다.

replication

• replication은 복제를 뜻하며 카프카 아키텍쳐의 핵심입니다.
• 카프카의 가용성을 보장하는 가장 좋은 방법은 replication(복제)입니다.
  • 만약 서버에 장애가 생겼을 때, 복제된 다른 파티션을 이용한다면 문제를 해결할 수 있습니다.
• replication이 1이라면 partition은 1개만 존재 2라면 원본 partition 1개, 복제본 partition 1개 3이라면 원본 partition 1개, 복제본 partition 2개 의 방식으로 데이터가 저장됩니다.
  • 원본 파티션을 Leader partition, 복제본 파티션을 Floower partition이라고 부릅니다.
• replication은 브로커 개수에 따라 제한됩니다.
  • 브로커 개수가 3이라면 replication의 최대는 3이 됩니다.
• replication의 개수가 많아진다면 그만큼 브로커의 리소스 사용량도 늘어나게 되기 때문에, 전송되는 데이터 양, retention date(저장시간)을 잘 생각해서 replication의 개수를 정해야 합니다.

ISR(In-Sync-Replication)

• Leader partition, Follwer parittion을 합쳐서 ISR이라고 볼 수 있습니다.

ack

• producer에는 ack라는 상세 옵션이 있습니다.
• ack는 partition의 replication과 관련이 있습니다.
• ack는 0, 1, all 세가지 옵션이 있는데, 이 중 하나를 선택해서 사용합니다.
  • 0: producer -> partition으로 데이터를 전달한 후, 응답을 받지 않습니다.
    속도가 빠르다는 장점이 있지만, 리더 파티션에 정상적으로 데이터가 전송되었고 나머지 파티션에 정상적으로 복제되었는지 알 수 없다는 단점이 있습니다.
  • 1: producer -> partition으로 데이터를 전달한 후, reader partition에 정상적으로 데이터가 전달되었는지 응답을 받습니다.
    리더 파티션이 데이터를 받았는지 응답을 받을 수 있는 장점이 있지만, 리더 파티션이 데이터를 받고 응답한 즉시 장애가 난다면 나머지 파티션에 복제가 정상적으로 진행되었는지 알 수 없다는 단점이 있습니다.
  • all: producer -> partition으로 데이터를 전달한 후, follower partition에 복제가 잘 이루어졌는지 응답을 받습니다.
    데이터 유실이 없고, 리더 파티션에 데이터를 보낸 후에 팔로워 파티션에도 데이터가 잘 전송했는지 확인하는 절차가 있어 안정적이라는 장점이 있지만, 0, 1번 옵션에 비해 데이터 확인 과정으로 인해 속도가 느리다는 단점이 있습니다.