Kafka(카프카) 개관

 

 분산 서비스가 대세가된 지금 대부분의 현대 웹애플리케이션의 아키텍쳐는 위 그림과 같은 복잡한 모습을 가지게 됩니다. 보기만 해도 머리가 아플 정도로 복잡한 의존성 관계 때문에 시스템이 깨지기 쉽다는 것을 알 수 있습니다.  

 

 카프카는 대용량, 대규모의 데이터를 빠르게 처리하기 위해 개발된 일종의 메세지 발행/구독 시스템입니다. 카프카를 이용해서 현대 웹애플리케이션의 복잡하고 위험한 의존성 관계를 깔끔하게 해결 할 수 있습니다.

 

 

 위 그림은 카프카를 도입한 웹 애플리케이션의 아키텍쳐를 나타냅니다. 복잡했던 의존관계가 사라지고 카프카를 통하는 단순한 선들만 남아이 있는 것을 볼 수 있습니다.

 

 위 그림에서 Producer, Brokers, Consumers 라는 단어가 등장합니다. 이 단어를 이해하기 위해서는 먼저 카프카의 특징적인 구조를 이해해해야 합니다.

 

 앞서서 카프카가 일종의 메세지 발행/구독 시스템이라는 표현을 했는데 카프카는 기본적으로 메시징 서버로 동작합니다. 중앙 메시징 시스템 서버에 메세지를 보내고(publish) 받는(subscribe)현태의 통신을 펍/섭 모델이라고 합니다. 펍/섭은 비동기 메시징 전송 방식으로 발신자의 메시지에는 수신자가 정해져 있지 않고 구독을 신청한 수신자만이 정해진 메시지를 받게 됩니다. 이 때 메시지를 보내는 쪽을 프로듀서(producer)혹은 퍼블리셔(publisher)라고 하고 반대로 메시지를 수신하는 쪽을 컨슈머(consumer) 또는 섭스크라이버(subscriber)라고 합니다. 카프카는 이처럼 프로듀서와 컨슈머가 분리되어 있는 특징이 있습니다. 

---

펍/섭 모델의 특징

• 프로듀서가 컨슈머에게 메시지를 직접 전달하지 않고, 중간의 메시싱 시스템에 전달한다.
• 컨슈머가 불능 상태가 되더라도 프로듀서는 메시지를 메시징 시스템에 전달할 수 있으며, 메시지는 유실되지 않는다. 그리고 컨슈머가 회복되면 다시 메시지를 가져간다.
• 각각의 개체가 N:N 통신을 하는것이 아니기 때문에 확장이 용이하다.
• 메시지가 정확하게 전달되었는지 확인하려면 코드가 복잡해진다.
• 메시지 전달 속도가 빠르지 않다. (중간에 메시징 시스템이 있기 때문에)

---

 그럼 이제 그림에서 남은 것은 Brockers 인데요. 그림에서 나타난 것 처럼 카프카 서버를 지칭합니다. 끝에 s가 붙어 있는 것으로 눈치를 채졌을 지도 모르겠지만 브로커 역시 여러개를 띄워서 사용할 수 있습니다. 

 

 

 위 그림처럼 아키텍쳐를 조금 더 자세히 나타낼 수 있습니다. 또 새로운 단어가 등장했습니다. ZooKeeper는 카프카의 분산 메시지 큐의 정보를 관리해 주는 역할을 합니다. 카프카를 띄위기 위해서는 zookeeper가 반드시 실행되어 있어야 합니다.

 

 Topic과 Partition이라는 단어도 등장했네요. 토픽은 메세지를 분류하는 단위 입니다. 메세지는 토픽으로 분류가 되고 이 토픽은 다시 여러개의 파티션으로 나눠 질 수 있습니다. 파티션 내의 한 칸은 로그라고 합니다. 데이터는 한 칸의 로그에 순차적으로 append됩니다. 이 때, 메세지의 상대적인 위치를 나타내 주는 것이 offset 입니다.

 

 

 하나의 토픽에 다중 파티션을 사용하는 이유는 병렬로 메세지를 처리함으로써 처리속도를 높이기 위함입니다. 주의해야 할 점은 한 번 늘린 파티션은 줄일 수 없기 때문에 운영중에 파티션을 늘리는 것은 사전에 충분한 고려가 있어야 할 것입니다. 또 각각의 파티션은 Round-Robin 방식으로 사용되게 됩니다. 순서가 중요한 메세지라면 위험이 발생할 수도 있습니다.

 

 offset이라는 단어를 잠깐 언급했는데 offsetdms 파티션 내부의 위치를 나타냅니다. 컨슈머는 토픽을 구독할때 각 파티션 내에 존재하는 offset의 위치를 통해서 이전에 받았던 offset의 위치를 관리하고 이를 통해 혹시 컨슈머가 다운되는 일이 있어도 이전에 마지막으로 읽었던 위치부터 메세지를 다시 읽어들일 수 있게 됩니다. 

 

 

 Consumer Group은 말 그대로 컨슈머들의 묶음을 의미합니다. 카프카 클러스터에서 데이터를 가져오게 될 때는 컨슈머 그룹단위로 가져오게 됩니다. 이 컨슈머 그룹은 자신이 가져와야하는 토픽 안의 파티션의 데이터를 Pull하게 되고 각각 컨슈머 그룹안의 컨슈머들이 파티션이 나뉘어져 있는 만큼 데이터를 처리하게 됩니다. 토픽과 컨슈머는 항상 1:n의 관계를 유지해야 하기 때문에 파티션을 늘릴때 컨슈머의 개수도 생각해야 합니다.

 

 마지막으로 Replication에 대해 알아보겠습니다. 카프카는 토픽을 파티션 단위로 복제합니다. 서로다른 broker로 복제된 토픽들 중에 하나의 서버만 leader가 되고 나머지 둘은 follower입니다. 컨슈머와 프로듀서가 실제로 사용하는것은 리더가 올라온 서버이고 나머지 팔로워들은 리더와 항상 싱크를 맞추고 있다가 리더가 다운되었을 때 나머지 팔로워가 리더가 됩니다.

---

카프카의 구성요소 및 특징 정리

• topic
• partiton Producer
• Consumer broker
• zookeepr
• consumer group
• replication

---

참고사이트

 

[Kafka, 카프카] 아파치 카프카(Apache Kafka) 아키텍처 및 동작방식, 파티션 읽기 쓰기(Partition Read and W

 

Kafka 이해하기

 

카프카, 데이터 플랫폼의 최강자 - 카프카란 무엇인가?