StarLord

kafka 커넥트는 아파치 kafka의 오픈소스 프로젝트 중 하나로 데이터 베이스 같은 외부 시스템과 kafka를 손쉽게 연결하기 위한 프레임워크 입니다. kafka 사용자들은 kafka 커넥트 프레임워크를 이용해 대용량의 데이터를 kafka 안팎으로 손수비게 이동시킬 수 있으며, 코드를 작성하지 않고도 간단히 사용할 수 있습니다. 물론 프로듀서와 컨슈머를 직접 개발해 원하는 동작을 실행하고 처리할 수 있지만, 때로는 애플리케이션을 개발하고 운영하는데 들어가는 리소스나 비용이 부담되는 경우가 있습니다. 이런 경우 kafka 커넥트를 이용하면 좀더 효율적이고 빠르게 클라이언트를 구성하고 적용할 수 있습니다. 데이터 중심 파이프라인 : 커넥트를 이용해 kafka로 데이터를 보내거나, kafka로부터 데이터를..

중앙 데이터 파이프라인 역할을 하는 카프카에서는 단 한명의 사용자가 단 하나의 토픽에만 접근해 읽고 쓰는것이 아니라 수많은 사용자가 수많은 토픽을 이용합니다. 그리고 그 토픽에는 애플리케이션 하나가 아니라 다수의 각기 다른 애플리케이션들이 접근할 것입니다. 따라서 만에 하나 누군가의 실수로 사전에 정의하지 않은 형태의 데이터를 해당 토픽으로 보내기라도 한다면 그와 연결된 모든 시스템이 영향을 받게 될 것이고 이는 매우 심각한 문제로 이어질 수 있습니다. 한가지 예를 더 들어보겠습니다. kafka의 데이터 흐름은 대부분 브로드캐스트 방식입니다. 다시 말하자면 kafka는 데이터를 전송하는 프로듀서를 일방적으로 신뢰할 수밖에 없는 방식입니다. 따라서 프로듀서 관리자는 kafka 토픽의 데이터를 컨슘하는 관리..

내렷다 올리기 너무 귀찮아서 그냥 systemctl 등록하려고 합니다. CentOS 기준입니다. 1. START/STOP script 를 만들자 # vi startkafka.sh ------------------------------------------------------- #!/bin/bash echo -e "Start Systemd Kafka and Zookeeper" echo -e "Running ZooKeeper" $KAFKA_HOME/bin/zookeeper-server-start.sh -daemon $KAFKA_HOME/config/zookeeper.properties sleep 10 echo -e "Running Kafka" $KAFKA_HOME/bin/kafka-server-start...

권한(ACL) 접근제어 리스트를 만들어 접근제어를 하는 것이다. 혹여 A서비스부서가 B토픽을 사용하는 오류를 방지하기 위해서 적용하는 것이다. kafka보안의 3단계 중 마지막으로 권한 설정을 해보겠습니다. kafka에서의 권한 설정은 각 유저별로 특정 토픽에 접근을 허용할지 또는 거부할지 등의 설정을 하는 것입니다. kafka의 권한 설정을 위해서는 먼저 브로커의 설정파일을 수정하고 그다음으로는 kafka-acls.sh 명령어를 이용해 유저별 권한을 설정해야 합니다. 1. 브로커 권한 설정 kafka 권한설정을 위해 server.properties파일을 수정해서 브로커의 설정을 변경해보겠습니다. # vi $KAFKA_HOME/config/server.properties ----------- # auth..

인증(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..

대용량 데이터를 분산 처리할 수 있는 자바 기반의 프레임워크. hdfs라는 하둡 분산 파일 시스템과 map reduce가 큰 특징임. HDFS 하둡의 DATA STORAGE에 해당하는 것으로 데이터는 block 단위로 분할되어 Slave Node에 저장된다. 데이터 관리를 위해 Master Node에서는 NameNode daemon이 실행되고, 각 Slave Node에서는 DataNode Daemon이 실행된다. 즉, HDFS는 Slave node에 있는 로컬 파일시스템 상에 만들어지는 오버레이 파일 시스템인 것이다. HDFS상에 배치된 파일은 128이나 256MB크기의 블록으로 분할되어 각 Slave Node에 저장되지만, 각 블록데이터는 로컬 파일시스템의 파일로 취급된다. 데이터 접근에 대해서는 기록..

https://www.cncf.io/blog/2022/06/30/how-to-secure-kubernetes-pods-post-psps-deprecation/ How to secure Kubernetes Pods post-PSPs deprecation | Cloud Native Computing Foundation Guest post originally published on the ARMO blog by Amir Kaushansky Kubernetes pods are the basic building blocks of Kubernetes. It's managing one or more tightly coupled application containers… www.cncf.io 파드시큐리티폴리시(PodS..

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