Kafka (6) 썸네일형 리스트형 Kafka 모니터링 이 글에서는 항상 모니터링 해야하는 중요한 메트릭은 어느 것인지, 그에 대해 어떻게 대응해야 하는지에 대해 알아볼 예정이다. 크게 브로커, 프로듀서, 컨슈머에서 각각 중요한 메트릭 정보가 나올 것이며, 브로커는 다시 토픽, 파티션, 로깅과 같이 3가지 세부항목으로 나누어 좀 더 상세한 메트릭 정보를 제공할 예정이다. Kafka의 메트릭 카프카의 모든 메트릭은 JMX(Java Management Extensions) 인터페이스를 통해 사용할 수 있다. 외부 모니터링 시스템에서 카프카 메트릭을 사용할 때는, 해당 모니터링 시스템의 모니터링 에이전트를 카프카 프로세스에 연결하는 것이 가장 쉬운 방법이다. 카프카 브로커의 JMX에 직접 연결하는 애플리케이션을 도와주기 위해 주키퍼에 저장된 브로커 정보에는 JMX.. Kafka 신뢰성 보장 이번 글에서는 카프카에서 보장할 수있는 신뢰성은 어떤것인지, 신뢰성을 보장하기 위해 브로커, 프로듀서, 컨슈머를 각각 어떤식으로 구성하면 될 것인지를 알아볼 예정이다. 카프카에서의 신뢰성 아파치 카프카에서 보장하는 것들은 무엇인지 아래의 항목들을 살펴보자 - 카프카는 파티션의 메세지 순서를 보장한다 - 각 파티션의 모든 동기화 리플리카에 메세지를 썼다면, 해당 메세지는 '커밋' 된 것으로 간주한다 - 최소한 하나의 리플리카가 살아있다면, 커민된 메세지는 유실되지 않는다 - 컨슈머는 커밋된 메세지만 읽을 수 있다 복제 복제 메커니즘은 카프카의 신뢰성 보장의 핵심이다. 복제된 리플리카들의 동기화 여부 체크 - 주키퍼와 세션이 연결되어 있는 경우 (주키퍼와 리플리카 간의 하트비트 전송 시간이 존재함 defau.. Kafka 내부 메커니즘 - 1)소개,주키퍼, 복제 실제 개발자가 Kafka를 사용하는 경우 이 내부 메커니즘이 필수적으로 필요한 내용은 아니다. 다만 어떻게 동작하는지 알아둔다면 Kafka를 운영하면서 튜닝이 필요한 부분을 보다 빨리 캐치하거나 감을잡기 위한 목적으로 이 글을 보기 바란다. 무엇에 대해 알아볼 것인가 내부 메커니즘 챕터를 통해서 크게 아래의 세가지 항목에 대해 알아볼 예정이다 - 카프카 복제(replication)가 동작하는 방법 - 카프카가 프로듀서와 컨슈머의 요청을 처리하는 방법 - 카프카가 스토리지를 처리하는 방법 Kafka Cluster 알고 넘어가기 Kafka Broker는 일반적으로 Load Balancing 및 HA (High Availability)를 위해서 다수의 Node 위에서 Cluster를 이루어 동작한다. Brok.. Kafka 내부 메커니즘 - 4)스토리지 앞서 Kafka가 요청에 대해 어떻게 쓰고, 읽는지 흐름을 알아 보았다. 그렇다면 실제로 Kafka가 데이터를 어떤식으로 저장하고 있을까? 이 부분에 대해 알아보자 카프카의 스토리지 단위 먼저 카프카의 기본적인 스토리지 단위는 파티션이다. 하나의 파티션은 여러 브로커 간에 분할될 수 없다. 따라서 하나의 파티션 크기는 단일 마운트 포인트에 사용 가능한 공간으로 제한된다. 카프카 저장공간 설정 카프카를 구성할 때, 파티션이 저장 될 디렉터리 내역을 log.dirs 매개변수에 설정 한다. (카프카 로그를 저장하는 곳이 아닌 저장공간인 디렉터리를 설정하는 매개변수임을 잊지 말자!! 실제 카프카 에러로그는 log4j.properties파일에 설정되니 참고바란다) 스토리지 파악 순서 1) 브로커와 브로커의 디렉터.. Kafka 내부 메커니즘 - 3)쓰기/읽기요청 쓰기요청(produce request) 일단 쓰기 요청의 흐름을 알기 전에 acks 매개변수에 대해 간단히 알고 넘어가자. acks매개 변수란, Producer config정보에서 ack(acknowlegement)옵션이 있다. 메세지를 보내고 잘 받았다고 확인받는 메세지라고 보면된다. 이 ack옵션에 따라서 네트워크를 몇번을 타야하는지를 결정할 수 있다. all 메세지를 리더한테 보내고 쓰여지고, 나머지 follower들이 똑같이 메세지를 다 복사할 때까지 기다린다. 복사까지 완벽하게 되면, 그제서야 ack옵션을 producer에게 보낸다.(메세지 잘 쓰여졌고, 복사까지 잘 됬어!)라고 - 장점은 leader가 어느 순간 뻗어도, 복제된 데이터가 follower들에게 있으니, 메세지의 유실이 전혀 없다.. Kafka 내부 메커니즘 - 2)요청처리 Kafka의 요청 처리 당연히 클라이언트가 요청하는 주체 일 것이고, 요청을 처리하는 주체는 Broker가 된다. 또 여기서 말하는 클라이언트는 아마 Producer, Consumer가 될 것이다. Kafka는 TCP로 전송되는 이진 프로토콜을 갖고 있으며, 항상 요청을 수신한 순서대로 브로커가 처리하기 때문에 카프카가 메세지 큐처럼 동작이 가능하다. 그럼 Kafka가 갖고있는 프로토콜의 모양을 살펴보자 프로토콜 헤더 살펴보기 요청타입 ID 16bit, 정수형 요청 타입을 구분하는 값이 들어간다 ex. Produce하는 요청의 ID값은 1, Consumer하는 요청의 ID값는 2 (아마 Kafka 내부적으로 정의된 값이 있을 것이다. 위 예시는 정말로 예일 뿐) 요청 버전 16bit, 정수형 API 버전.. 이전 1 다음
