STUDY/실전 카프카 개발부터 운영까지 (6) 썸네일형 리스트형 12장 - 엔터프라이즈 카프카 아키텍처 구성 사례 엔터프라이즈 카프카 아키텍처 개요 엔터프라이즈 환경에서는 장애/복구, 성능 등을 위해 하나 이상의 데이터 센터를 사용하는 경우가 많다. 따라서 각 데이터 센터마다 카프카 클러스터를 배치해야 하고, 각 카프카 클러스터 간의 데이터 리플리케이션은 필수이다. 카프카 클러스터 안에서의 브로커 간의 리플리케이션이 아니라, 카프카 클러스터 간의 리플리케이션이다. 카프카 리플리케이션은 업스트림 카프카에서 다운스트림 카프카 사이에 필요할 수도 있고, 여러 카프카 데이터를 모으기 위해 필요할 수도 있다. 이렇게 복제된 미러 카프카는 최적의 위치에서 엘라스틱 서치, HBase 등에 연결되어 사용될 수 있다. 지금까지 배운 내용을 종합해서 위와 같은 엔터프라이즈 아키텍처를 만들고자 한다. 2개의 카프카 클러스터가 존재하고,.. 5장 - 프로듀서의 내부동작 원리와 구현 파티셔너 카프카는 토픽마다 병렬처리를 위한 파티션을 가지고 있고, 이에따라 각 메시지가 어느 파티션에 들어가야 하는지 결정하는 로직이 필요하다. 이때 사용하는 것이 바로 파티셔너이다. 카프카는 별도의 파티셔너를 정의하지 않으면 기본적으로 라운드 로빈 알고리즘을 사용하는 파티셔너를 사용했었다. 그러나 2019년 부터는 이를 개량한 스티키 파티셔닝 알고리즘을 사용한다. 라운드 로빈 알고리즘은 메시지를 각 파티션에 순서대로 하나씩 넣는다. 이렇게 하면 각 파티션에 동일한 수의 메시지가 들어가게 되고, 자연스럽게 각 파티션을 가져가는 컨슈머도 동일한 부하를 가지도록 한다. 하지만 카프카의 기본 특징인 메시지의 배치 전송 때문에 라운드 로빈 전략은 약점이 존재한다. 위 이미지처럼 batch.size가 3으로 설정.. 3장 - 카프카 기본 개념과 구조 카프카의 주요 구성 요소 주키퍼(Zookeeper): 카프카의 메타데이터를 관리 하고 브로커의 상태를 점검하는 어플리케이션 카프카(Kafka): 프로듀서와 컨슈머 사이에서 메시지를 중개하는 메시지 브로커 어플리케이션 브로커(Broker): 카프카가 설치되고 동작하는 서버 또는 노드 프로듀서(Producer): 카프카로 메시지를 보내는 클라이언트 컨슈머(Consumer): 카프카에서 메시지를 가져가는 클라이언트 토픽(Topic): 카프카 메시지를 구분하는 카테고리. 카프카 내에서 고유하다. 파티션(Partition): 병렬 처리를 위해 토픽을 나눈 것 세그먼트(Segment): 메시지가 저장된 브로커의 디스크 파일 메시지(Message) 또는 레코드(Record): 프로듀서가 전송하고 컨슈머가 가져가는 데.. 카프카 환경 구성, peter 대신 내 이름 쓰기 https://nankisu.tistory.com/73 2장 - 카프카 환경 구성 AWS EC2 인스턴스 생성 총 7개의 Amazon-Linux EC2 인스턴스를 생성한다. 여기서 1개의 인스턴스는 ansible, 3개의 인스턴스는 주키퍼 클러스터, 3개의 인스턴스는 카프카 클러스터에 사용된다. 이때 인스 nankisu.tistory.com 이전에 책에 있는 내용을 실습하기 위한, 카프카 환경 구성에 관한 글을 포스팅 했다. 그런데 해당 실습 예제 peter-ansible, peter-kafka01~03, peter-zk01~03 처럼 peter 닉네임으로 각 인스턴스들의 호스트 네임이 붙어져 있다. 이를 kisu-ansible과 같이 내 닉네임으로 바꾸어서 환경구성하는 법을 찾아보았다. 실습 예제 코드.. 2장 - 카프카 환경 구성 AWS EC2 인스턴스 생성 총 7개의 Amazon-Linux EC2 인스턴스를 생성한다. 여기서 1개의 인스턴스는 ansible, 3개의 인스턴스는 주키퍼 클러스터, 3개의 인스턴스는 카프카 클러스터에 사용된다. 이때 인스턴스의 보안규칙은 1. ssh 접속을 위해 22번 포트는 열어두고 2. 클러스터 내부 통신을 위해 VPC에서 오는 모든 포트를 열어두고 3. 이후 실습할 내용을 위해 0 - 65535 포트를 열어둔다. (교육용으로 실환경에서는 사용하는 포트만 열어야 한다.) DNS 설정 > sudo vi /etc/hosts 아래 내용 삽입 ////////////////////////////////////////////////////////////////////// {ec2 private ip} pet.. 1장 - 카프카 개요 MSA의 등장 과거에는 하나의 어플리케이션에 모든 기능이 들어가있는 모놀릭 아키텍처가 대부분이었다. 따라서 모든 데이터의 흐름은 어플리케이션 안에서 이루어지고, 다른 어플리케이션과의 데이터 공유는 제한적이었다. 하지만 시대가 변하고, 최근에는 대부분의 어플리케이션이 마이크로서비스 아키텍처를 채택하고 있다. 마이크로서비스 아키텍처는 하나의 어플리케이션을 각각의 기능을 가지는 여러 서비스로 나누고, 이들을 결합하여 운영하는 구조이다. 따라서 서비스간의 활발한 데이터 공유가 이전보다 더욱 많아지고 중요해졌다. 문제발생 서비스간 데이터 공유를 한다는 것은 공통에 저장소에서 데이터를 사용하는 것(Reddis나 Oracle Database 같은 경우)일 수도 있다. 아니면 한 서비스에서 다른 서비스로 데이터를 전송.. 이전 1 다음
