25G.story

카프카 커넥트 카프카커넥트는 아파치 카프카의 오픈소스 프로젝트 중 하나로, 데이터베이스 같은 외부 시스템과 카프카를 손쉽게 연결하기 위한 프레임워크입니다. 대용량의 데이터를 카프카의 안팎으로 손쉽게 이동시킬수 있습니다. 코드작성없이.. 프로듀서와 컨슈머를 직접 개발해 원하는 동작을 실행하고 처리할 수 있지만, 개발 비용이 부담된다면 카프카 커넥트를 이용하면 빠르게 적용할 수 있다. • 데이터 중심 파이프라인: 커넥트를 이용해 카프카로 데이터를 보내거나，카프카로부터 데이터를 가져옵니다. • 유연성과 확장성: 커넥트는 테스트 및 일회성 작업을 위한 단독 모드 실행 할 수 있고, 대규모 운영 환경을 위한 분산 모드(클러스터형)로 실행할 수 도 있습니다. • 재사용성과 기능 확장: 커넥트는 이미 만들어진 기존 ..

스키마? RDB에서 스키마란 정보를 구성하고 데이터가 저장될때에 약속을 만들어 주는것이라고 생각합니다. RDB에서는 스키마를 정의한 형태로 데이터를 입력해야하고 사전에 정의된 스키마의 내용과 다른 데이터를 추가하려고 시도하면 작업은 실패합니다. 카프카에서 스키마가 없을때의 예를 들어 보자면 한명만 카프카를 사용한다면 별 다른 이슈가 없겠지만 수많은 사용자가 카프카를 사용하고 수많은 사용자가 수많은 토픽을 사용합니다. 그리고 토픽마다 각기 다른 애플리케이션에 접근하기 때문에 하나의 데이터라도 사전에 정의되지 않은 토픽으로 데이터가 이전돼면 큰 문제가 생길 것입니다. 카프카는 대부분 브로드캐스트 방식으로 데이터를 전송하기 때문에 프로듀서를 일방적으로 신뢰 할 수 밖에 없는 방식입니다. 따라서 프로듀서 관리자..

업그레이드를 위한 준비 현제 사용중인 버전 체크하기 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): 카프카는 메시지 피드들을 토픽으로 구분하고, 각 토픽의 ..