25G.story

업그레이드를 위한 준비 현제 사용중인 버전 체크하기 kafkaᅳtopics.sh --version /usr/local/kafka/bln/kafka-toplcs.sh --version 카프카의 릴리스 노트등을 잘 살펴보면서 업그레이드시 문제가 될 만한 부분은 없는지 확인합니다. 스칼라 Scala 컨슈머, 프로듀서처럼 서비스가 종료된 경우도 있으므로 전체적으로 카프카의 릴리스 노트를확인해야합니다. 카프카가 다운타임을 가질 수 있다면 종료후 최신 버전을 실행시키면 됩니다. 하지만 대부분의 경우 카프카가 다운되는것은 상상하기 싫은 일입니다. 이런경우엔 브로커 한 대씩롤링 업그레이드를 하는것입니다. 주키퍼 의존성이 있는 카프카 롤링 업그레이드 먼저 토픽을 먼저 삭제합니다. 삭제가 성공적으로 됐다면 앤서블을 통해서..

안정적인 운영을 위한 주키퍼와 카프카 구성 카프카는 애플리케이션이 워낙 안정적이기때문에 클러스터를 구성해놓은 뒤 신경을 쓰지 않는 경우가 많다. 하지만 장애를 대비해서 꼼꼼히 클러스터를 구성해 놓는것이 좋다. 주키퍼 구성 최근들어 아파치 카프카 오픈소스 진영에서는 카프카의 코디네이터 역할을 하는 주키퍼의 의존성을 제가혀라는 움직임이 있습니다. 주키퍼는 파티션과 브로커의 메타데이터를 저장하고 컨트롤러 서버를 선출하는 동작을 수행합니다. 주키퍼 서버 수량 주키퍼는 기본적으로 쿼럼(과반수)구성을 기반으로 동작하므로 반드시 홀수로 구성해야 합니다. 최소 서버수는 3입니다. 이렇게 3대로 구성된 주키퍼는 과반수인 2를 추족할 수 있는 최대 1대까지의 주키퍼 장애를 허용합니다.5로 구성한다면 3까지 허용하는것입니다..

컨슈머 오프셋 관리 컨슈머의 동작 중 가장 핵심은 오프셋 관리입니다. 컨슈머는 카프카에 저장된 메시지를 꺼내오는 역할을 하기 때문에 컨슈머가 메시지를 어디까지 가져왔는지를 표시하는것은 매우 중요합니다. 컨슈머가 어떠한 문제로 동작을 멈추고 재시작하는 경우나 컨슈머가 구동중인 서버에 문제가 발생해서 다른 컨슈머가 역할을 대신하는등 새로운 컨슈머가 메시지를 가져올 수 있어야만 장애로 부터 빠르게 복구 될 수 있습니다. 오프셋? 카프카에서 메시지의 위치를 나타내는 위치를 오프셋이라고 부르고 오프셋은 숫자 형태로 나타냅니다. 컨슈머 그룹은 자신의 오프셋 정보를 카프카에서 가장 안전한 저장소인 토픽에 저장합니다. 그룹 코디네이터 컨슈머들은 하나의 컨슈머 그룹의 구성원이 되고 컨슈머 그룹 내의 각 컨슈머들은 서로 ..

파티셔너 메시지들은 프로듀서의 send() 메소드를 통해 시리 얼라이저，파티셔너를 거쳐 카프카로 전송됩니다. 카프카의 토픽은 성능 향상을 위한 병렬 처리가 가능하도록 하기 위해 파티션으로 나뉘고, 최소 하나 또는 둘 이상의 파티션으로 구성됩니다. 그리고 프로듀서가 카프카로 전송한 메 시지는 해당 토픽 내 각 파티션의 로그 세그먼트에 저장됩니다 이때 프로듀서는 토픽으로 메시지를 보낼때 해당 토픽의 어느 파티션으로 메시지를 보내야 할지 결정해야하는데 이때 사용하는 것이 파티셔너입니다. 예를 들어서 a토픽 으로 메시지를 전송하는데 미시지 키는 user22입니다. 메시지 키값 user22는 프로듀서의 기본파티셔너를 거치면서 해시 알고리즘을 통해 a토픽의 파티션중 하나와 매핑되고 이후부터는 메시지 키값이 user..

카프카 리플리케이션 리플리케이션 동작 개요 카프카는 브로커의 장애에도 불구하고 연속적으로 안정적인 서비스를 제공함으로써 데이터 유실을 방지하며 유연성을 제공합니다. 리플리케이션 동작을 위해 토픽생성시 필숫값으로 replication factor라는 옵셥을설정해야합니다. 카프카는 리플리케이션 팩터라는 옵션을 이용해 관리자가 지정한 수만큼의 리플리케이션을 가질 수 있기 때문에 N개의 리플리케이션이 있는 경우 N-1까지의 브로커 장애가 발생해도 메시지 손실 없이 안정적으로 메시지를 주고받을 수 있습니다. 리더와 팔로워 토픽 상세보기 명령어를 실행해 보면 출력 내용 중 파티션의 리더 라는 부분이 있습니다. 모두 동일한 리플리케이션이라 하더라도 리더만의 역할이 따로 있기 때문에 카프카에서 리더를 특별히 강조해 표..

개발 편의성은 태라바이트대에서 올라온다고 합니다. - 태라바이트대정도의 데이터를 주고받아야지 카프카를 선호한다. - 그 이하일때는 레빗엠큐가 훨신 유용하다. - 운영비나 여러가지를 대비했을때 서비스가 클수록 카프카가 처리량 이 더 좋지만 비싸고 - 서비스가 작을수록 레빗엠큐가 더 유용할 수 있다.

AWS 실제 환경 구성 카프카를 실제 운영하는 환경에서는 서비스의 안정성이 최우선이므로 단독 서버 형태로 운영하는 경우는 거의 없고, 대부분 이중화 또는 클러스터 형태로 구성합니다. 주키퍼의 경우 최소수량인 ec2 인스턴스 3대로 구성하고, 카프카의 경우도 최소 수량인 ec2 인스턴스 3대로 구성. 일반적인 운영 환경에서는 배포서버 1대 포함 프라이븟 도메인을 위한 도메인 표시. 환경구성 실습 aws가입/로그인해서 ec2사용 클릭 위 버튼을 통해서 AMI선택화면이 나오는데 이는 인스턴스의 운영체제를 선택하는 화면입니다. Amazon Linux 2AMI 선택. 선택을 하면 인스턴스 유형 선택화면이 나옵니다. 실습과정에선 ec2하나 이상의 애플리케이션을 구동하게 되므로 4GB 용량의 메모리가 지원되는 t2...

카프카를 구성하는 주요 요소 주키퍼(ZooKeeper): 아파치 프로젝트 애플리케이션 이름입니다. 카프카의 * 메타데이터(metadata) 관리 및 브로커의 정상상태 점검(health check)을 담당합니다. 카프카(Kafka) 또는 카프카 클러스터(Kafka cluster): 아파치 프로젝트 애플리케이션 이름입니다. 여러 대의 브로커를 구성한 클러스터를 의미합니다. 브로커(broker): 카프카 애플리케이션이 설치된 서버 또는 노드를 말합니다. 프로듀서(producer): 카프카로 메시지를 보내는 역할을 하는 클라이언트를 총칭합니다. 컨슈머(consumer): 카프카에서 메시지를 꺼내가는 역할을 하는 클라이언트를 총칭합니다. 토픽(topic): 카프카는 메시지 피드들을 토픽으로 구분하고, 각 토픽의 ..

카프카의 주요 특징 높은 처리량과 낮은 지연시간 카프카를 선택하는 가장 큰 이유가됩니다. 기업 수준으로 커저가는 데이터 처리를 위해 굉장히 우수한 처리량과 낮은 지연시간을 지표에서 확인 할 수 있습니다. 높은 확장성 기업급의 데이터들은 아무리 뛰어난 처리량과 낮은지연시간을 가지고 있다고 해도 한계를 부딪히기 마련입니다. 그럴때 중요한것이 확장성인데 카프카는 손쉬운 확장이 가능하도록 잘 설계된 어플리케이션입니다. 기업을 운영하면서 사업이 다각화 됐을때에도 카프카는 높은 확장성이라는 장점을 발휘할 수 있습니다. 고가용성 카프카는 2013년에 클러스터 내 리플리케이션 기능이 추가되면서 고가용성이 확보됐습니다. 리플리케이션?* 참고 블로그 https://mangkyu.tistory.com/97#:~:text=%..

팀장님께서 카프카스터디가 있는데 함께 해 보는것이 어떠냐고 하셔서 신입에 애기개발자인 저는 고민하지도 않고 덥석 하겠다고 해버렸습니다. 신입의 패기와 욕심은 이런것을까요,,? ㅎㅎ MSA,EDA 기반 설계에서 카프카는 핵심 시스템으로 자리잡았다고 합니다. MSA? 마이크로서비스 아키텍처에 대한 정확한 정의는 없다. 하지만 마이크로서비스란 작고, 독립적으로 배포 가능한 각각의 기능을 수행하는 서비스로 구성된 프레임워크라고 할 수 있다. 마이크로서비스는 완전히 독립적으로 배포가 가능하고, 다른 기술 스택(개발 언어, 데이터베이스 등)이 사용 가능한 단일 사업 영역에 초점을 둔다. EDA? 수집한 데이터가 들어왔을 때, 이를 다양한 각도에서 관찰하고 이해하는 과정입니다. 한마디로 데이터를 분석하기 전에 그래프..