FOR A BETTER ME162 [Kafka] Consumer Group: Rebalancing 📌 kafka 및 Confluent 를 공부하며 정리하는 글 Consumer Group 의 Rebalancing consumer group 프로세스가 하나 돌아가는 중에 하나를 더 추가로 돌려보자. 첫 번째 돌고 있던 consumer group 로그에서 "Attempt to heartbeat failed since group is rebalancing" 를 통해 rebalancing 시작을 알 수 있다. 이어서 Rejoining 이 발생하고, 파티션이 나누어 할당된다. "Adding newly assigned partitions: coding_topic-2" 로그를 통해 첫번째 consumer 프로세스는 2 파티션을 할당 받음을 알 수 있다. 대상 토픽의 파티션 3개를 두 개의 consumer 가 나누어.. 2021. 8. 2. [JAVA] 배열 개념 정리: 배열 복사 arraycopy 1. 기본 자료형 배열의 복사 System.arraycopy(복사할 소스 배열, 복사할 첫 위치, 복사 대상 배열, 붙여넣을 첫 위치, 복사할 요소 갯수(length)) 그런데, 위와 같이 복사할 요소 갯수가 복사 대상 배열의 크기보다 넘어가는 경우, 에러가 발생한다. 2. 객체 배열의 복사 2-1) 얕은 복사 객체 배열을 복사해본다. 그런데, 복사 원본 객체 배열의 값을 바꾸었더니, 해당 원본을 복사한 shelf2 배열의 값도 따라 바뀌었다. 이는 값이 복사된 것이 아니고 "주소"가 복사된 얕은 복사였기 때문이다. 즉, shelf1[0] 과 shelf2[0]이 같은 값을 가리키고 있다. 2-2) 깊은 복사 각 객체 배열이 서로 다른 인스턴스의 메모리를 요소로 가지게 하는 깊은 복사는 다음과 같이 get.. 2021. 8. 1. [Kafka] Producer 관련 주요 옵션 📌 kafka 및 Confluent 를 공부하며 정리하는 글 Producer Configurations Idempotent Producer acks=0 (no acks) producer는 메세지만 보낼 뿐, 해당 메세지가 broker단에 제대로 전달되었는지 확인하지 않는다. 메세지 손실의 위험이 있다. 단순 메트릭 정보와 같이 메세지 손실이 어느정도 눈감아지는 상황이라면 사용해도 괜찮다. acks=1 (leader acks) producer에서 Kafka로 데이터를 보내면(:write request), leader Broker는 write request에 대해 respond를 보낸다. 그리고 해당 데이터를 Topic에 write한다. leader에게 응답을 받지 못한 경우 producer는 다시 writ.. 2021. 5. 29. [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. 이전 1 2 3 4 5 6 ··· 18 다음
