목록DevOps/Kafka (4)
devops
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/bVwUyX/btrRGwsNyjl/6y5loAV0EJi0t5IRWkvJK0/img.png)
컨슈머의 주요 역할은 카프카에 저장된 메시지를 당겨오는 것이다. 메시지를 당기는데 중요한 요소인 오프셋과 그룹 코디네이터, 파티션 할당 전략을 간단히 정리해보려고 한다. 1) 오프셋 (Offset) 오프셋 관리는 컨슈머의 동작 중에 핵심이라고 볼 수 있다. 컨슈머는 카프카에 저장된 메시지를 꺼내기 때문에 컨슈머가 메시지를 어디까지 가져왔는지를 표시하고 확인하는 것은 중요하다. 여기서 메시지의 위치를 나타내는 것을 오프셋이라고 한다. 이 오프셋은 숫자 형태로 저장된다. 컨슈머 그룹은 오프셋 정보를 카프카의 토픽에 저장한다. (__consumer_offsets 토픽에 각 컨슈머 그룹 별 오프셋 위치 정보가 기록됨) 2) 그룹 코디네이터(Group Cordinator) 컨슈머 그룹에서 컨슈머들은 속한 컨슈머 ..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/cc0Vy0/btrRH7sGoHJ/UNdCDeOUjqGkKWcCAlkgJk/img.png)
Producer 카프카의 토픽은 병렬처리가 가능하기 위해서 파티션으로 나뉘어, 최소 하나 이상의 파티션으로 구성된다. 그리고 프로듀서가 카프카로 전송한 메시지는 토픽 내 각 파티션의 로그 세그먼트에 저장된다. 그래서, 프로듀서는 토픽으로 보낼 때 토픽의 어느 파티션으로 메시지를 보내야할 지 결정해야하고 이 때 사용하는 것이 '파티셔너(Partitioner)'다. 그래서 파티션의 증가에 따라 관리자의 의도와 다르게 메시지 전송이 이뤄질 수 있기 때문에 되도록 파티션 수를 변경하지 않는 것이 좋다. 파티셔닝 방법 2가지 레코드들은 배치 처리를 위해서 프로듀서의 버퍼 메모리 영역에서 잠시 대기한 후에 카프카로 전송된다. 이 때 크게 두가지전략을 고려할 수 있다. 1) 라운드 로빈 전략 키 값을 지정하지 않은 ..
Producer와 Consumer는 Python으로 테스트, Broker와 Zookeeper는 Docker로 올려본다. 서버를 EC2로 올리는 건 비용이 들기 때문에 간단한 테스트용으로 추천한다. (Confluent-Kafka는 개발이 활발하고 다른 버전들보다 여러면에서 스펙이 가장 뛰어나기 때문에 Confluent버전을 사용함) 1) Confluent-kafka 설치 $ pip install confluent-kafka (consumer와 producer 어플리케이션을 위해) 2) Broker와 Zookeeper docker-compose로 올리기 # docker-compose.yml --- version: '3' services: zookeeper: image: confluentinc/cp-zooke..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/cBlzmQ/btrRzfYCpH3/Oshk8OqBIWMtptcmJ4Zck1/img.png)
여러 곳을 찾아봐도 깔끔하게 개념을 이해할 수 있는 정리된 자료가 없어서 직접 정리해보려고 한다. kafka는 높은 처리량과 가용성, 확장성을 지니고 있지만, 의외로 구조는 간단하기 때문에 쉽게 이해할 수 있으리라 생각함. 카프카를 구성하는 주요 요소들 1) 주키퍼(Zookeeper) 카프카의 메타데이터를 관리하고 브로커의 health check를 담당하는 역할을 한다. 주키퍼는 여러 대의 서버를 클러스터로 구성한다. 그래서 살아 있는 노드가 과반수 이상이면 유지될 수 있다. 그래서 홀수로 구성되어야 한다. Znode를 통해서 카프카의 메타정보가 주키퍼에 기록된다. 주키퍼는 지노드를 이용하여 브로커의 노드 관리부터, 토픽과 컨트롤러를 모두 관리할 수 있다. 2) 카프카(Kafka) 카프카 클러스터(Clu..