Tech Blog

Environment 4개의 테라덱은 각 소스 스트림을 송출함 각 테라덱은 부팅 시점에 pts를 0으로 초기화하므로 4개의 테라덱이 정확히 동시에 켜지지 않는 이상 동일 프레임에 대해 pts가 상이함 타임 코드는 동일 ntp 서버 기준으로 동일 프레임에 대해 같은 타임코드로 삽입됨 네트워크를 통해 오는 각 스트림은 도착 속도가 다 제각각이므로 동일 프레임이 동일 타이밍에 수신되지 않음, 즉 수신하는 프레임의 타임코드가 정렬되어 있지 않음 Troubleshooting 모든 스트림을 동시에 로컬 .ts 파일로 녹화 시작 (버퍼링) 녹화와 병렬로 각 스트림의 첫 SEI timecode를... Read More

Stream 개요 stream은 메시지 streaming 처리를 위해서 추상화한 layer 변경 불가하며 append만 가능한 collection 연속된 historical 정보 표현 insert된 row는 변경 불가하며 (update, delete 불가) 새로 insert된 row는 stream의 마지막에 추가됨 stream은 key를 가질 수도 그렇지 않을 수도 있으며 동일한 key 값을 가진 row는 동일한 파티션에 저장됨 Stream / Table 연속 처리 stream과 table은 topic을 source로 할 수 있으며, 다른 stream 또는 table을 sou... Read More

KSQLDB SQL 만으로 쉽게 streaming 데이터의 가공/ 변환/ 분석 수행 적용 사례 고객 360 데이터 웨어하우스 사기 탐지 IoT 스트리밍 데이터 파이프라인 고객 충성도 시스템 구축 개인 맞춤형 프로모션 생성 실시간 주문 배송 추적 지리적 위치 기반 알림 및 프로모션 생성 Streams API 기반 데이터 처리 streams 라이브러리를 통해 제공하는 단 한번의 데이터 처리, 장애 허용 시스템 등의 특징들은 컨슈머와 프로듀서 조합만으로 완벽하게 구현 어려움 source topic, sink topic이 다른 카프카 클러스터인 경우 streams 지... Read More

Schema Registry confluent kafka는 schema registry를 통해 schema 정보를 별도로 관리하는 기능 제공 토픽으로 전송되는 data의 schema는 schema registry에서 ID + version 별로 중앙 관리 되므로 레코드 별로 schema를 중복해서 전송할 필요가 없음 Schema Registry 역할 schema 전송 없이 레코드 값만 kafka로 전송할 수 있게 해줌 kafka 메시지의 schema 제약 조건을 유지하면서 schema 변화에 대한 일정 수준 호환성을 제공 Avro 개요 및 장점 데이터 직렬화를 수행하는 시스... Read More

서로 다른 두 파드가 통신하려면 서로의 IP 주소를 먼저 알아야 함 pod 간 통신을 위해서 IP 주소를 사용하는데 IP 주소는 pod 대체 시 변경됨 service address discovery를 통해 문제 해결 pod의 교체된 IP 주소는 kubernetes API를 통해서만 찾을 수 있음 쿠버네티스 내부의 네트워크 트래픽 라우팅 언제든지 pod IP 주소는 바뀔 수 있으므로 고정된 도메인 네임 도입 쿠버네티스 내부에는 전용 DNS 서버가 있음 서비스 생성 시 서비스의 IP 주소가 DNS 서버에 등록되고 서비스 삭제 전까지 변경되지 않음 서비스는 label sele... Read More

쿠버네티스 이해 마스터 노드 (control plain) 클러스터 노드, 파드 관리 워커 노드 (data plane) 컨테이너 실행 kubeadm init 으로 클러스터 초기화하여 새로운 마스터 노드 생성 마스터 노드는 기본적으로 컨테이너를 실행할 수 없지만 설정을 통해 가능하도록 할 수 있음 kubectl은 마스터 노드의 api server에 요청하고 api server는 각 워커 노드에 설치된 kubelet과 통신하여 각 worker 노드에서 pod를 실행하도록 함 마스터 노드의 scheduler가 어떤 워커노드에 po... Read More

CDC (Change Data Capture) 개요 CDC는 RDBMS오 NoSql 등의 data store 시스템의 변경 데이터를 기록하는 내부 트랜잭션 로그 파일로부터 변경 데이터를 capture하는 설계, sw를 지칭 DB 내부 트랜잭션 로그 파일로부터 변경 데이터를 추출하므로 소스 DB 성능에 큰 영향 없이 대용량 변경 데이터를 매우 빠르게 추출하고 준실시간으로 타겟 DB 연동 가능 DBMS 복제 수준의 안정적이고 정확한 데이터 추출 가능 Debezium은 이러한 CDC 기반의 분산 플랫폼으로 기본적으로는 카프카 커넥터로 제공됨 JDBC source connector의 경우 DB에 se... Read More

JDBC Source Connector JDBC source connector는 RDBMS 별 JDBC driver가 별도로 설치되어야 함 JDBC source connector는 JDBC driver를 이용하여 DB 접속 및 데이터 추출을 수행 후 producer를 이용하여 broker로 데이터를 전송함 JDBC source connector는 source 시스템에 주기적으로 query를 날려 변경된 데이터를 추출하는 방식 JDBC Source Connector 모드 유형 incremental query mode : 이전 데이터 추출 이후 새롭게 생성된 데이터나 업데이트 된 데이터... Read More

Kafka Connect 개요 Kafka 메시지 시스템 (Broker/Producer/Consumer)를 기반으로 다양한 데이터 소스 시스템 (ex: RDBMS)에서 발생한 데이터 이벤트를 다른 데이터 타겟 시스템으로 별도의 client 코딩 없이 seamless하게 실시간 전달하기 위해 만들어진 kafka component’ Kafka Connect 활용 Data Pipeline DW ETL 활용 Micro Service DB offloading Kafka Connect 주요 구성요소 Connector JDBC Source / Sink Debe... Read More

Multi Broker Cluster 구축 각 인스턴스 모두 동일 VPC에 속해야 함 보안 그룹 설정 포트 범위 (0-65535) 소스 (172.31.0.0/16) 포트 범위 (0-65535) 소스 (허가 IP 지정) local에서 admin 접근은 public IP로 접근 DNS 설정 각 노드의 /etc/hosts 파일 수정 172.31.3.209 client.foo.bar client 172.31.0.186 kafka1.foo.bar kafka1 172.31.12.195 kafka2.foo.bar kafka2 1... Read More

사용자 정의 리소스 kubectl 명령은 쿠버네티스 API와 거의 일대일로 대응 모든 리소스에 공통으로 있는 표준 action은 create, get, list, match, delete 등 CustomResourceDefinition(CRD)으로 쿠버네티스에 새로운 리소스 타입을 추가할 수 있음 사용자 정의 리소스 및 객체의 정보는 etcd DB에 저장됨 사용자 정의 리소스 역시 API 표준 action 지원 CustomResourceDefinition(CRD)가 생성되면 이 정의와 API 버전 및 유형이 일치하는 정의를 작성하여 사용자 정의 리소스를 생성 가능 일반적인 리소... Read More

Log Cleanup Policy 카프카 브로커는 오래된 메시지를 관리하기 위한 정책을 log.cleanup.policy로 설정 topic 레벨은 cleanup.policy log.cleanup.policy=delete로 설정하면 closed segment 삭제함 log.cleanup.policy=compact로 설정하면 segment를 key 레벨로 가장 최신 메시지만 유지하도록 재구성 log.cleanup.policy=[delete,compact]로 설정 시 함께 적용 Log Cleanup Policy Delete log.retention.hours(... Read More

카프카 로그의 파티션과 세그먼트 카프카 로그는 실제로는 segment로 저장됨 파티션은 단순히 파일 디렉토리로만 되어 있고, 해당 파티션 디렉토리에 메시지 저장 segment를 file로 가지고 있음 파티션은 여러 segment로 구성되며 개별 segment는 용량이 차거나 일정 기간 경과 시 close되고 새로운 segment 생성 segment가 close되면 더 이상 write 불가하고 read-only 됨 broker는 여러 개의 segment 중 하나의 active segment에만 write/read 수행 하나의 파티션은 단 하나의 active segment 가짐 S... Read More

Preferred Leader Election 파티션 별로 최초 할당된 leader/follower broker 설정을 preferred broker로 그대로 유지 broker가 shutdown 후 재기동 될 때 preferred leader broker를 일정 시간 이후에 재선출 auto.leader.rebalance.enable=true로 설정하고, leader.imbalance.check.interval.seconds를 일정 시간으로 설정 (기본 300초) preferred leader election 적용 시 broker가 shutdown되면 leader는 변함 없지만 ISR은 ... Read More

ISR의 이해 (In-sync Replicas) follower들 중 leader가 될 수 있는 것은 ISR 내에 있는 follwer만 가능 controller는 follower들이 leader가 될 수 있는 지 지속적으로 모니터링 수행 ISR에 속하는 지 판단은 leader 브로커가 수행 leader 파티션 메시지를 follower가 복제하지 못하고 뒤쳐질 경우 ISR에서 해당 follower는 제거되며 leader가 문제 생길 때 차기 leader가 될 수 없음 ISR 조건 1) broker가 zookeeper에 연결되어 있어야 함 (zookeeper.sess... Read More

Zookeeper 개요 분산 시스템 간 정보를 신속하게 공유하기 위한 코디네이션 시스템 Zookeeper의 Z node 분산 시스템에서 리더 노드를 선출 개별 노드 간 상태 정보의 동기화를 위한 복잡한 lock 관리 기능 개별 노드들은 zookeeper의 znode를 계속 모니터링 하여 znode에 변경 발생 시 watch event가 트리거되어 변경 정보가 개별 노드들에게 통보 zookeeper 자체에 클러스터링 기능 제공 zookeeper_shell localhost:2181 shell에 접속 후 파일 구조를 API처럼 호출해서 내용 확인 가능 ls ... Read More

멀티 노드 카프카 클러스터 분산 시스템으로 카프카의 성능과 가용성을 함께 향상 시킬 수 있도록 구성 스케일 아웃 기반으로 노드 증설을 통해 메시지 전송과 읽기 성능을 선형적으로 증가시킬 수 있음 데이터 복제를 통해 분산 시스템 기반에서 카프카의 최적 가용성 보장 분산 시스템 구성을 위한 중요 요소 분산 시스템 도입을 위해서는 성능, 안정성, 가용성 측면에서 상세한 기능 검토가 요구됨 분산 시스템은 대량 데이터를 여러 노드간 분산 처리를 통해 처리할 수 있는 큰 성능적 이점을 가지지만 안정성과 가용성 측면에서 상대적인 단점을 가짐 (여러 노드의 데이터 정합 문제) 단일 노드 구성 ... Read More

Consumer 개요 브로커의 topic 메시지 읽는 역할 수행 모든 consumer 들은 고유한 group id를 가지는 consumer group에 속해야 함 Fetcher, ConsumerClientNetwork 등의 주요 내부 객체와 별도의 HeartBeat Thread를 생성 partition은 consumer group에서 단 하나의 consumer에만 할당됨 동일 consumer group 내 consumer들은 작업량을 최대한 균등하게 분배 서로 다른 consumer group의 consumer들은 분리되어 독립적으로 동작 kafka-console-consumer... Read More

Producer 개요 Producer는 Topic에 메시지를 보냄(메시지 write) Producer는 성능/로드밸런싱/가용성/업무 정합성등을 고려하여 어떤 브로커의 파티션으로 메시지를 보내야 할지 전략적으로 결정됨 Producer Record simple producer String topicName = "simgple-producer"; Properties props = new Properties(); props.setProperty(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "192.168.56.101:9092"); props.setProperty(Produce... Read More

Kafka 사용 이유 기존 데이터 통합 솔루션은 각 소스 애플리케이션과 타겟 애플리케이션 M to M 매핑으로 복잡하게 얽혀있음 서비스 타겟이 많아질 수록 인터페이스가 많아짐 A와 A’가 잘못된 경우? A와 B’가 잘못된 경우? 회의만 하다가 시간 다간다!! 따라서 메시지 브로커 역할이 필요 환경 설정 vi ~/.bashrc export CONFLUENT_HOME=/home/사용자명/confluent export PATH=.:$PATH:/home/사용자명/confluent/bin . .bashrc Kafka 기동하기 Zookeeper 기동 $CONFLUENT_HOME... Read More

헬름이 제공하는 기능 헬름 사용 시 여러 개의 YAML 정의 및 스크립트를 하나의 아티팩트로 묶어 공개 또는 비공개 리포지토리에 공유 가능 헬름 프로젝트는 CNCF에서 관리함 Helm3 부터 서버 컴포넌트 필요 없이 사용가능 (kubectl과 동일 접속 정보 사용), 다만 패키지 리포지토리를 따로 설정 해야함 ex) helm repo add test_repo https://test_repo.net helm repo update # 로컬 리포지토리 캐시 업데이트 helm search repo web --versions # 애플리케이션 검색 헬름에서 애플리케이션의 패키지를 chart라고 ... Read More