고딩왕 코범석
Apache Kafka란? 본문
Before Kafka
데이터를 전송하는 Source Application, 데이터를 받는 Target Application이 하나씩 있다고 가정하고, 추후에 애플리케이션의 덩치가 커지면서 여러 개의 Source, Target App 들이 굉장히 많아질 것이다.
문제는 이 Source, Target이 많아질수록 각각을 연결하는 라인들이 많아지게 되고, 이들을 배포하고, 이슈에 대해 추적하고, 유지보수하는 등등 관리하기가 굉장히 복잡할 것이다.
이를 해결하기 위해 링크드인에서 Kafka를 개발하였고, 현재는 오픈소스화 되어있다.
Kafka Features
Kafka를 사용할 경우, Source App들은 Kafka에 데이터를 전달하기만 하면 되고, Target App들은 Kafka에서 데이터를 받기만 하면 되고, Source와 Target의 결합도를 굉장히 낮춰준다.
또한, Kafka는 데이터의 여러 포맷을 지원한다. JSON은 물론이고 tsv, sql-query 등등 굉장히 많은 포맷을 갖고 있다.
Topic
Kafka는 다양한 데이터 포맷을 지원하는데, 이 데이터들이 들어가는 공간을 Topic 이라고 한다. 이 토픽은 AMQP와는 다르게 동작한다.
토픽은 우선 카프카에서 여러 개 생성할 수 있으며, 토픽은 DB의 테이블 파일 시스템의 폴더와 유사한 구조를 가지고 있으며, 각 토픽은 이름을 명시할 수 있다.
Partition
하나의 토픽에는 여러개의 파티션으로 구성될 수 있으며, 0번부터 시작한다. 파티션에 데이터들이 쌓여있으면, Producer(데이터 공급)가 보낸 데이터중 오래된 순서로 Consumer가 데이터를 가져가는 메커니즘이다.
더 이상 데이터가 들어오지 않더라도, Consumer는 데이터가 올 때 까지 기다리며, Partition에 쌓여있는 데이터는 삭제되지 않는다. Partition에 그대로 남아있으며, 이 남은 데이터는 새로운 Consumer가 붙었을 때, 0번부터 그 데이터를 가져가는 구조다.
Partition이 복수인 경우 프로듀서가 데이터를 보낼 때, 키를 지정할 수 있다. 이 때, 키가 없고 기본 파티셔너로 설정했다면, 라운드 로빈으로 데이터가 할당되고, 키가 있고, 기본 파티셔너로 설정했다면 키의 Hash를 구해 특정 파티션에 할당하며, 파티션은 늘리는 것이 가능하지만 줄일 수 없다.
파티션을 늘리면 컨슈머도 늘려 데이터 처리를 분산시킬 수 있는데, 그럼 파티션에 쌓인 데이터들은 언제 삭제될까?
옵션에 따라서 다른데, 레코드가 저장되는 최대 시간과 크기를 지정할 수 있다. 이를 지정하게 되면 일정 기간 혹은 용량에 따라 쌓인 데이터들이 삭제된다
Broker, Replication, ISP
Broker
카프카가 설치되어 있는 서버 단위를 말하며, 보통 3개 이상의 브로커로 구성하는 것을 권장한다.
Replication
파티션의 복제를 의미하며, 만약 replication이 1이라면, 파티션이 1개만 존재하는 것이고, replication이 2라면 파티션 하나와 replication 하나가 있는 것을 의미한다.
다만, 브로커 갯수에 따라 replication 갯수가 제한되는데, 만약 브로커가 세개인 경우, replication은 4가 될 수 없다!
ISR(In Sync Replica)
만약 Replication이 3이라고 가정하면, 하나의 원본 파티션은 리더 파티션, 나머지 복제된 두 개의 파티션은 팔로워 파티션, 이 세가지를 통틀어 ISR이라고 볼 수 있다.
Replication을 사용하는 이유?
고가용성을 위해서! 예를들어 Replication이 1인 경우, 이 리더 파티션이 죽게되면 복구할 수 없다. 하지만 Replication이 2인 경우는 리더 파티션이 죽더라도, 팔로워 파티션이 리더 파티션을 승계할 수 있어 보다 안전하게 운용할 수 있다.
Replication이 많을수록 좋은 것은 아니다. 그만큼 브로커의 리소스 사용량도 늘어나기 때문에 카프카에 들어오는 데이터량, 저장시간을 잘 고려해서 replication 갯수를 정하는 것이 좋다.
Leader vs Follower (Partition)
프로듀서가 토픽의 파티션에 데이터를 전달할 때, 전달받는 주체가 바로 Leader이다.
Producer가 토픽의 파티션에 데이터를 전달할 때, ack 옵션을 설정할 수 있는데, 0일 경우 응답값을 받지 않아서 데이터가 잘 전송되었는지 알 수 없다. 이 때문에 속도는 빠르지만 안정성을 보장할 수 없다.
ack이 1인 경우는 데이터를 전달받았는지 응답을 받는 설정이지만, Follower 파티션들에게도 데이터가 잘 전달 되었는지는 알 수 없다. 이 때, 리더 파티션이 데이터를 받은 즉시 해당 브로커에 장애가 발생할 경우, 나머지 파티션에 데이터가 전달되지 못한 상태이므로 데이터 유실가능성이 존재한다.
all 옵션인 경우는 Follwer 파티션들도 복제가 잘 되었는지 응답값을 받는 옵션이다. 데이터 유실은 없다고 보면 되나, 모든 브로커의 파티션들을 확인해봐야 하기 때문에 속도가 느린 편이다.
Partitioner
파티셔너를 통해 각 브로커들로 데이터가 전송되는데, 파티셔너의 역할은 데이터를 토픽의 어떤 파티션에 넣을지 결정하는 역할을 한다.
파티셔너에 메세지 키가 있을 경우, 특정한 해쉬값이 생성되는데 이 해쉬값을 기준으로 어느 파티션에 들어갈지 정해지게 된다.
예를 들어 서울의 온도를 가정해보면 키를 "서울"이라고 가정했을 때, 키가 같다면 해쉬값도 같게 나오며, 항상 동일한 파티션에 데이터가 순서대로 들어가기 때문에 컨슈머는 "서울"이라는 레코드를 순서를 지켜 처리할 수 있다.
메세지 키가 없을 경우는 라운드 로빈으로 파티션에 들어가는데, 프로듀서에서 최대한으로 모을 수 있는 레코드들을 모아서 파티션으로 데이터를 보내게 된다. 이러한 방식을 배치방식으로 넣으면 파티션에 적절히 효율적으로 분배된다고 생각하면 될 것 같다.
카프카는 커스텀 파티셔너를 제공하게끔 Patitioner 인터페이스를 제공하고 있다. 이 인터페이스를 사용해 메세지 키, 값, 토픽 이름에 따라 어느 파티션에 데이터를 보낼 지 결정할 수 있다.
Kafka Lag
프로듀서는 토픽의 파티션에 데이터를 순차적으로 넣는데, 각 데이터는 offset이라는 숫자가 붙게 된다.
랙은 그림처럼 Producer Offset, Consumer Offset의 차이이며, 이걸 통해 상태의 유추가 가능하다. 주로 컨슈머의 상태를 볼 때 사용하며 토픽에 여러 파티션이 있을 경우 Lag도 그에 따라 여러개 존재한다.
해당 포스팅은 '데브원영' 님의 아파치 카프카 for beginners를 참조하면서 공부한 포스팅입니다.