자기발전소140 [Kafka] Broker & Zookeeper 📌 kafka 및 Confluent 를 공부하며 정리하는 글 Producer와 Consumer는 자동으로 어떤 브로커에 데이터를 write할지, 어떤 브로커의 데이터를 read할지를 알게된다고 하였다. 어떻게 이러한 동작이 가능할까? Producer 와 Consumer 가 Borker를 발견해내는 방법을 알아보자. 1. Broker Discovery 모든 카프카 브로커는 "bootstrap server"라고 하는데, 하나의 broker에 접속만 하면 전체 클러스터에 접속할 수 있다는 것이다. 각 브로커는 모든 브로커뿐만 아니라 토픽, 파티션(metadata)을 알고 있다. 2. Zookeeper 브로커를 관리하며, 브로커의 리스트를 가지고 있다. 각 파티션에 대한 leader 브로커를 선정한다. 새로운 .. 2021. 5. 19. [Kafka] Consumer 📌 kafka 및 Confluent 를 공부하며 정리하는 글 카프카에서 데이터를 읽어내는 방식을 알아보자. Consumer topic(이름으로 식별 가능)으로부터 데이터를 읽는다. producer가 자동으로 어떤 broker에 write해야 할지 인식하는 것과 같이, consumer 또한 어떤 broker로부터 데이터를 read 할지 자동으로 인식한다. broker 장애 발생 시, producer와 마찬가지로 consumer는 복구하는 방법을 안다. 데이터는 각 파티션 내에서 순서대로 read된다. consumer가 복수의 파티션을 read하는 경우, 그 파티션은 하나의 consumer에 의해 병행적으로 read된다. 순서에 대한 보장은 없음 (하나의 파티션 내에서는 순서에 맞게 read되지만) 1) C.. 2021. 5. 19. [Kafka] Producer 📌 kafka 및 Confluent 를 공부하며 정리하는 글 카프카에서 데이터를 얻는 방법을 알아보자. Producer topic에 data를 write한다. 어떤 broker의 어떤 파티션에 write해야 할지 자동으로 인식한다. Broker에 장애가 난 경우, Producer는 자동으로 복구한다. 기본적으로(key가 없는 경우) Producer는 라운드 로빈 방식으로 파티션에 데이터를 write한다. 파티션의 개수에 따라 라운드 로빈된다. 1) acks strategy Producer는 data writes에 대한 확인 메세지를 받는데, 아래와 같이 3가지의 방법이 있다. acks=0 : 확인 메세지를 기다리지 않고 진행 (데이터 손실 가능) acks=1 : leader의 확인 메세지만 대기 (제한된.. 2021. 5. 19. [Kafka] Topic 📌 kafka 및 Confluent 를 공부하며 정리하는 글 1. Topic (토픽) 이란? 토픽은 데이터 스트림과 비슷한 개념이다. 데이터베이스의 테이블과 비슷하다. (제약사항이 없는!) 카프카에서 원하는 만큼의 토픽을 만들 수 있고, 각 토픽은 이름으로 구별한다. 2. 토픽과 Partition (파티션), Offset(오프셋) 토픽은 파티션으로 쪼개진다! 각 파티션은 NUMBER를 가지는데(partition0, partition 1, 이렇게), 각 파티션은 순서를 갖게 된다. 하나의 파티션 안의 각 메세지는 0부터 순차적으로 증가하는 id(offset)를 가진다. 🔎 Topic Example: delivery_gps 여러 배달 오토바이가 배달 중인 비즈니스에서 카프카를 사용한다고 가정해보자. 각 배달.. 2021. 5. 19. [Kafka] Apache Kafka란 📌 kafka 및 Confluent 를 공부하며 정리하는 글 1. 카프카의 필요성 기존의 데이터를 다루는 아키텍처는 너무 복잡했다. 아래 그림과 같이 비즈니스 구조에 필요한 데이터 source 시스템과 target 시스템이 점점 많아지면서 복잡해질 수 밖에.. 이렇게 꼬일대로 꼬인 데이터 스트림을 관리하기도 어려웠을 것이다. 그래서 이렇나 데이터 스트림과 시스템들을 decoupling 하는 작업이 필요해졌다. 이를 위해 바로 분산 메시지 처리 시스템인 Apache Kafka가 나왔다. 아래와 같이 source 시스템은 각 target으로 모두 데이터를 보내는 대신에 하나의 Log에 데이터를 쌓는다. 그리고 target 시스템에서는 Log에서 각각 자신이 필요한 데이터를 가져가게 되면서 훨씬 더 간결한 구.. 2021. 5. 19. [K8s] Controller 와 Workload > Deployment 컨트롤러를 통해 Pod 실행 (pod만 독립적으로 실행하고 싶다면? --restart=Never) 즉, pod가 정지됐을 때 자동으로 재기동해야 하는지에 따라 옵션을 선택하면 된다.만약 해당 옵션을 생략하는 경우 디폴트로 Always가 적용되어 디플로이먼트에 의해 파드가 기동 된다. $ kubectl create deploy --image=hello-world hello-world 👉 deployment 생성 후, deployment가 생성한 모든 오브젝트를 확인할 수 있다: pod, replicaset. 👉 레플리카 셋과 파드 뒤에 해시 문자열이 추가되어 고유한 이름이 주어진 것을 확인할 수 있다. 👉 레플리카셋과 디플로이먼트는 지정된 pod의 개수가 유지될 수 있도록 관리하는 .. 2021. 3. 6. [K8s] Hello Minikube(CentOS 7) 노트북 사양이 부족한 관계로 멀티 클러스터 구성보다 Minikube로 쿠버네티스 실습이 적절했다 ㅠ ㅠ (이전에 서버를 사용할 수 있었을 때에는 신나게 클러스터 구축했었는데...) 추가로 구매한 메모리가 온다면, 얼른 데스크톱에 추가하여 쿠버네티스 클러스터 환경 구축 실습을 진행할 것이다 ! 😎😎😎 오늘의 Minikube 설치 환경은 다음과 같다. 💡 VMware 기반 가상 서버 OS: CentOS 7 CPU : 2 (가상화 지원 YES) # grep -E --color 'vmx|svm' /proc/cpuinfo 명령어를 사용하여 가상화 지원 확인 필요. MEM: 4 HDD: 20 매우 노트북의 사양이 연약한 관계로 최소한의 자원을 사용하였다 (메모리는 2GB여도 된다하지만, 메모리는 항상 될 수 있는한.. 2021. 3. 6. [Linux] ssh key 기반 인증 ssh key 기반 인증 SSH 키 기반 인증을 사용하면, 암호없이 인증이 가능하다. 이를 위해서는 개인키 및 공개키로 이루어진 암호화 키 파일 pair를 생성해야 한다. 💡 개인키 : 인증용으로 사용되며 안전하게 유지되어야 하는 키 공개키: 연결하고자 하는 시스템에 복사되어 개인키를 확인하는 데 사용하는 키 ssh key 실습 📍환경: 서로 네트워크 통신 가능한 가상 머신 2대(a-server & b-server) 🔑 간단한 방식의 ssh key 기반 접속 설정 $ ssh-keygen : 개인키 및 공개키 생성 해당 계정의 홈디렉토리 아래 .ssh 폴더가 생성되는데, 그 아래 id_rsa 및 id_rsa.pub 파일에 각 키가 저장된다. 이때 고유한 이름을 입력하지 않으면 id_* 와 같이 디폴트명으로.. 2021. 2. 21. [Linux] 디스크 관리하기 Parted DISK 관리 관련 명령어 1. 디스크 목록 확인 (fdisk -l 과 비슷한 결과 출력) # parted -l 2. 특정 디스크 관련 목록 확인 # parted /dev/sdb (parted) print 또는 p 3. 파티션 가상머신에 할당한 디스크를 사용하기 위해서는 먼저 디스크를 파티셔닝 하고 원하는 파일시스템으로 포맷한 다음, 마운트를 해야 사용 가능하다. (리눅스 기준) 1) 디스크 파티션 형식 지정 (parted) mklabel gpt 또는 mklabel msdos gpt : GPT - 최대 128개 파티션, 2TB 이상 설정 가능 msdos : MBR - 최대 4개 주 파티션, 3개의 주 파티션 후 확장 논리 파티션 구성 가능 (최대 2TB까지만 관리 가능) 2) 파티션 생성 (.. 2021. 1. 26. 이전 1 2 3 4 5 6 ··· 16 다음
