StarLord

인증(SASL) SASL/GSSAPI : 카프카 0.9 버전부터 지원됐습니다. GSSAPI는 커버로스 인증 방식으로 많이 사용되는 인증 방식중 하나입니다. 회사 내부에 별도의 커버로스 서버가 있는 환경이라면 커버로스 인증 방식을 사용하는 것이 가장 좋습니다. 커버로스 인증 방식을 적용할 때는 렐름이라는 설정이 필요한데, 이때는 되도록 하나의 렐름으로 모튼 애플리케이션을 적용하는 방법을 추천합니다. 크로스 랠름 설정으로 인해 클라이언트들의 재인증, 인증 실패 등이 일어나는 경우가 종종 있기 때문입니다. SASL/PLAIN : PLAIN은 아이디와 비밀번호를 텍스트 형태로 사용하는 방법으로서, 운영 환경보다는 개발 환경에서 테스트 등의 목적으로 활용합니다. SASL/SCRAM-SHA-256 : Salted ..

kafka의 통신에 적용해야할 보안 요소는 다음과 같다. SSL 통신 ※ kafka는 JAVA로 개발된 플랫폼이어서 jks 로 인증서를 관리하게 만들어주면 kafka가 쉽게 사용할수 있습니다. 이에 따라 jks 로 인증서를 관리하는 체계로 아래에 서술되어 있으니 참고바랍니다. ※ 그리고 해당 내용은 kafka server 01번을 CA로 쓰는 프로세스이므로 정석적인 방식은 아닙니다. 사실 인증서 체계는 당연히 분리하는것이 맞습니다. 꼭 kafka 서버 중 하나가 CA가 되어야 하는게 아니며 사용가능한 자원이 한정되어 이렇게 진행하는 것이니 참고바랍니다. 1. 브로커 키스토어 생성 키스토어는 서버 측면에서 프라이빗 키와 인증서를 저장하며, 자격 증명을 제공합니다. 그외에 프라이빗하고 민감한 정보를 저장합니..

어떤 토픽은 총 4개의 파티션으로 구성되어 있고, 브로커는 3대로 구성되어 있습니다 .각 브로커마다 하나의 파티션이 배치됐지만 어느하나의 브로커에는 총 2개의 파티션이 배치됐습니다. kafka 확장 실습을 위해 브로커를 한대 더 추가하겠습니다. $KAFKA_HOME/config/server.properties 설정 파일에서 broker.id=4로 지정합니다. 별다른 어려움 없이 broker 추가가 완료되었습니다. 그렇다면 기존의 토픽과 파티션들은 어떻게 될까요? 브로커를 추가했지만 기존의 토픽과 파티션들은 새로 추가된 브로커로 이동하지 않습니다. 그렇 어떻게 해야 할까요? 관리자가 수작업으로 토픽의 파티션들을 고르게 분산시켜야 합니다. 우선 새로운 토픽을 생성합니다. $ $KAFKA_HOME/bin/ka..

그라파나와 프로메테우스를 기반으로 카프카와 하드웨어 리소스를 모니터링 하는 방법등을 살펴보겠습니다. 주키퍼 주키퍼는 높은 하드웨어 리소스를 요구하지 않으므로 주키퍼의 물리적인 메모리 크기는 4~8GB로 구성하고 디스크는 240, 480GB SSD를 사용하는 것을 추천합니다. 주키퍼에서 필요로 하는 힙 메모리 크기는 일반적으로 1~2GB이며 나머지는 운영체제 영역등에서 사용하게 됩니다. 따라서 주키퍼 서버에 과도한 물리 메모리를 장착하는 것은 오히려 메모리를 낭비하는 일이 될 수 있습니다. 주키퍼는 트랜젝션이나 스냅샷 로그들을 로컬 디스크에 저장하는데 일반적인 SAS 디스크 보다는 SSD디스크를 추천합니다. 물리서버를 배치하는 경우에는 일반적으로 데이터센터 내에 랙 마운트를 하게 됩니다. 이때 하나의 랙에..

컨슈머의 오프셋관리 컨슈머의 동작중 가장 핵심은 오프셋 관리입니다. 컨슈머는 카프카에 저장된 메시지를 꺼내오는 역할을 하기 때문에 컨슈머가 메시지를 어디까지 가져왓는지를 표시하는 것은 매우 중요합니다. 예를 들어 코드 배포로 인해 컨슈머가 일시적으로 동작을 멈추고 재시작하는 경우나, 컨슈머가 구동중인 서버에서 문제가 발생해 새로운 컨슈머가 기존 컨슈머의 역할을 대신 하는 경우에는 기존 컨슈머의 마지막 메시지 위치부터 새로운 컨슈머가 메시지를 가져올 수 있어야만 장애로부터 빠르게 복구될 수 있습니다. kafka에서는 메시지의 위치를 나타내는 위치를 오프셋이라고 부르는데, 이 오프셋은 숫자 형태로 나타냅니다. 컨슈머 그룹은 자신의 오프셋 정보를 kafka에서 가장 안전한 저장소인 토픽에 저장합니다. __co..

파티셔너 카프카의 토픽은 병렬처리가 가능하도록 하기 위해 파티션으로 나뉘고 최소 하나 또는 둘 이상의 파티션으로 구성됩니다. 그리고 프로듀서가 kafka로 전송한 메시지는 해당 토픽 내 각 파티션의 로그 세그먼트에 저장됩니다. 따라서 프로듀서는 토픽으로 메시지를 보낼 때 해당 토픽의 어느 파티션으로 메시지를 보내야할지 결정해야 하는데 이때 사용하는 것이 바로 파티셔너 입니다. 프로듀서가 프로듀서가 파티션을 경정하는 알고리즘은 기본적으로 메시지의 키를 해시처리해 파티션을 구하는 방식을 사용합니다. 따라서 메시지의 키값이 동일하면 해당 메시지들은 모두 같은 파티션으로 전송됩니다. 예상치 못한 많은 양의 메시지가 kafka로 인입되는 경우 kafka는 클라이언트의 처리량을 높이기 위해 토픽의 파티션을 늘릴 수..

리플리케이션 동작개요 카프카는 브로커의 장애에도 불구하고 연속적으로 안정적인 서비스 제공함으로써 데이터 유실을 방지하며 유연성을 제공합니다. 카프카의 리플리케이션 동작을 위해 토픽 생성 시 유실을 방지하며 유연성을 제공합니다. 카프카의 리플리케이션 동작을 위해 토픽 생성 시 필수값으로 replication factor 라는 옵션을 설정해야 합니다. # ./kafka-topics.sh --bootstrap-server localhost:9092 --create --topic peter-overview01 --partitions 1 --replication-factor 3 # ./kafka-topics.sh --bootstrap-server localhost:9092 --topic peter-overview..

Topic 생성 # ./kafka-topics.sh --bootstrap-server localhost:9092 --create --topic peter-overview01 --partitions 1 우선 프로듀서가 어떻게 디자인 되어 있는지를 살펴봅시다. 주요옵션 bootstrap.servers 연결할 서버 정보입니다. host1:port1,host2:port2와 같이 여러개를 나열할 수 있습니다. 초기 커넥션 연결시에 사용하기 때문에, 모든 서버 리스트를 포함할 필요는 없습니다. 실제 메시지 전송시에는 새로운 커넥션을 맺은 다음에 전송하기 때문이지요. key.serializer, value.serializer 메시지를 serialize 할 때 사용할 클래스를 지정하면 됩니다. ByteArraySeri..

kafka를 왜 사용하는가? 이벤트 드리븐 아키텍처를 구현하는데에 동기방식으로 구현할 경우 다음과 같은 한계에 봉착하게 된다. 여러 네트워크를 이용하는 환경에서 모든 데이터 변경에 대한 올바른 전달 보장 문제 동일한 데이터를 동시에 수정하면서 정확하게 순서를 보장해야 하는 문제, 그리고 수정된 이벤트들을 정확한 순서대로 아웃바운드 전송하는 문제 다양한 클라이언트들의 요구사항을 효율적으로 지원하기 어려운 문제 빠른 전송을 위한 클라이언트 또는 대량의 배치 전송을 위한 클라이언트를 지원하기 어려운 문제 이를 해결하는 요소는 다음과 같다. 그리고 kafka가 이 요소를 갖고 있다. 비동기 방식의 스트리밍 플랫폼 빠른 데이터 수집이 가능한 높은 처리량 순서 보장 적어도 한번 전송방식으로 누락이 없음 멱등성 클라..

CentOS7을 기준으로 작성한 가이드 입니다. JDK 설치 # sudo yum install java-1.8.0-openjdk-devel # java -version kafka 서버 Install # wget --no-check-certificate https://archive.apache.org/dist/kafka/3.2.0/kafka_2.12-3.2.0.tgz # tar xvf kafka_2.12-3.2.0.tgz # cd kafka_2.12-3.2.0 Configuration # cd config # vi server.properties //[31번 라인 정도에 있는 다음 내용 주석 해제] listeners=PLAINTEXT://:9092 //[36번 라인 정도에 있는 다음 내용 주석 해제 후 다..