APACHE KAFKA ™는 분산 형 스트리밍 플랫폼 입니다. 그게 정확히 무슨 뜻입니까? 우리는 스트리밍 플랫폼이 세 가지 핵심 기능을 가지고 있다고 생각합니다. 이를 통해 레코드 스트림을 게시하고 구독 할 수 있습니다. 이 점에서 메시지 큐 또는 엔터프라이즈 메시징 시스템과 유사합니다. 내결함성있는 방식으로 레코드 스트림을 저장할 수 있습니다. 발생하는 레코드 스트림을 처리 할 수 있습니다. 그것은 두 가지 광범위한 종류의 응용 프로그램에 사용됩니다. 시스템 또는
응용 프로그램간에 데이터를 안정적으로 얻는 실시간 스트리밍 데이터 파이프 라인 구축 데이터 스트림을 변환하거나 이에 반응하는 실시간 스트리밍 어플리케이션 구축 카프카가 어떻게 이러한 일을하는지 이해하기 위해 카프카의 능력을 알아보자 Kafka는 하나 이상의 서버에서 클러스터로 실행됩니다. 카프카 클러스터는 topic 이라는 범주 에 record stream을 저장 합니다. 각 레코드는 키, 값 및 타임 스탬프로 구성됩니다. Kafka는 4 가지 핵심 API를 가지고 있습니다. 생산자 API는 하나 개 이상의 카프카 주제에 레코드의 스트림을 게시 할 수있는 응용 프로그램을 할 수 있습니다. 소비자 API는 응용 프로그램이 하나 개 이상의 주제에 가입 그들에게 생산 기록의 스트림을 처리 할 수
있습니다. 스트림 API는 애플리케이션이 역할을 할 수 있도록 스트림 프로세서 유효 입력이 출력 스트림에 스트림 변환, 하나 개 이상의 항목에서 입력 스트림을 소비하는 하나 개 이상의 출력 항목을 출력 스트림을 생성한다. 커넥터 API를 구축하고 기존의 응용 프로그램이나 데이터 시스템에 카프카의 주제를 연결 재사용 생산자 또는 소비자를 실행 할 수 있습니다. 예를 들어, 관계형 데이터베이스에 대한 커넥터는 테이블에 대한 모든 변경 사항을 캡처 할 수 있습니다. USE CASEShttps://kafka.apache.org/uses MESSAGING
WEBSITE ACTIVITY TRACKING
METRICS
LOG AGGREGATION
STREAM PROCESSINGKafka의 많은 사용자는 여러 단계로 구성된 처리 파이프 라인에서 데이터를 처리합니다. 여기에서는 원시 입력 데이터가 카프카 항목에서 소비 된 다음 추가 소비 또는 후속 처리를 위해 새로운 주제로 집계, 강화 또는 변환됩니다. 예를 들어, 뉴스 기사를 추천하는 처리 파이프 라인은 RSS 피드의 기사 내용을 크롤링하여 "기사"주제에 게시 할 수 있습니다. 추가 처리로이 컨텐츠를 정규화 또는 중복 제거하고 정리 된 기사 컨텐츠를 새 주제에 게시 할 수 있습니다. 최종 처리 단계에서이 내용을 사용자에게 권장하려고 시도 할 수 있습니다. 이러한 프로세싱 파이프 라인은 개별 주제를 기반으로 실시간 데이터 흐름의 그래프를 생성합니다. 0.10.0.0부터 시작하여, 가볍지 만 강력한 스트림 처리 라이브러리 인 Kafka Streams 는 Apache Kafka에서 위에서 설명한 데이터 처리를 수행 할 수 있습니다. EVENT SOURCING이벤트 소싱 은 상태 변경이 시간 순서로 기록 된 레코드 순서로 기록되는 응용 프로그램 디자인 스타일입니다. 매우 큰 저장된 로그 데이터에 대한 Kafka의 지원은이 스타일로 구축 된 응용 프로그램을위한 훌륭한 백엔드입니다. COMMIT LOG이벤트 소싱 은 상태 변경이 시간 순서로 기록 된 레코드 순서로 기록되는 응용 프로그램 디자인 스타일입니다. 매우 큰 저장된 로그 데이터에 대한 Kafka의 지원은이 스타일로 구축 된 응용 프로그램을위한 훌륭한 백엔드입니다. KAFKA OPERATIONSGRACEFUL SHUTDOWN카프카는 브로커가 실패하거나 내려갔을때 자동으로 감지해 파티션의 새 리더를 선출 이는 서버 오류, 유지보수나 설정변경으로 내렸을 때 모두 발생 후자일 경우에 카프카는 단순히 죽이는것 보다는 좀더 graceful 한 서버 정지를 지원 장점재시작 시 로그 복구가 필요하지 않도록 모든 로그를 디스크에 동기화 한다. (예를들어 로그 tail에 있는 모든 메세지의 체크섬의 확인) 로그 복구는 시간이 걸리기 때문에 재시작의 속도를 높일 수 있다. 셧다운 이전에 리더 서버의 파티션들을 다른 레플리카로 migration한다. 이는 리더십 전송을 빠르게 하고, 각 파티션이 사용불가능한 시간을 몇 밀리세컨으로 최소화한다. controlled.shutdown.enable=true ALANCING LEADERSHIP브로커가 정지하거나 충돌했을 때 프로커 파티션의 리더십은 다른 레플리카로 위임된다. 이는 기본적으로 브로커가 재시작 되었을 면 오직 파티션들의 follower만이 될 수 있고 읽기/쓰기 동작으로 사용될 수 없다는 것을 의미한다. 이 불균형을 피하기 위해 카프카에는 우선적인 레플리카 개념이 있다. 파티션의 레플리카가 1,5,9일 때 1번 노드가 리더 우선권이 있다. 왜냐하면 레플리카 리스트에 앞에 있기 때문이다. 다음 커맨드를 실행해 복구된 레플리카에게 리더십을 복구할 수 있다. bin/kafka-preferred-replica-election.sh \
이 커맨드를 실행하는게 귀찮기 때문에 다음 configuration을 설정해서 자동화할 수 있다. auto.leader.rebalance.enable=true MIRRORING DATA BETWEEN CLUSTERS카프카는 카프카 클러스터간의 데이터 미러링을 위한 툴을 갖고 있다. 한개 이상의 source 클러스터로부터 데이터를 읽어 destination cluster로 쓰는 툴이다. 미러링의 일반적인 사용예는 다른 데이터 센터로 복제하는 것이다. source, destination 클러스터는 완전히 독립적이고, 다른 파티션 갯수를 갖고, 오프셋이 같지 않을 것이다. 그래서 클러스터 미러링은 fault-tolerance 매커니점으로서의 진정한 목적은 아니다. 하지만, 미러링 프로세스는 파티션 메시지 키를 유지하고 사용해서 키 기반에서 순서가 유지는 된다. EXPANDING YOUR CLUSTER카프카 서버에 서버를 추가하는것은 쉽다. 새 서버에서 카프카 유니크 브로커아이디를 할당해 기동하면 된다. 하지만 이 새로운 서버는 자동으로 데이터 파티션으로 할당되지 않기 때문에, 파티션들이 새 서버로 이동되지 않는 한, Topic이 새로 생길 때까지 어떤 일도 하지 않는다. 그래서 보통 클러스터에 서버를 추가하면 기존 데이터를 이 새 서버로 이동시키려 할 것이다. 새 서버를 마이그레이션 하는 파티션의 follower로 추가하고, 모든 기존 데이터를 복제하도록 한다. 파티션의 내용이 새 서버에 모두 복제 되고 in-sync 레플리카에 연결 되면, 기존 레플리카중 하나가 파티션의 데이터를 삭제한다. —generate: 이 모드는 토픽과 브로커 리스트가 주어지면 툴이 특정 토픽의 모든 파티션들을 새 브로커들로 이동 시킬 재할당 후보를 생성한다. 이 옵션은 단지 주어진 토픽과 브로커 리스트로 파티션 재할당 플랜을 생성하는 편리한 방법을 제공한다. —execute: 이 모드는 제공된 재할당 플랜을 기반으로 파티션 재할당을 시작한다. 관리자가 작성한 재배치 플랜이 될수도 있고, -generate 옵션 사용으로 제공될수 있다. —verify: 이 모드는, 마지막으로 execute 되고 있는 재할당 상태를 확인한다. 상태는 성공적인 완료, 실패, 수행중일 수 있다. topic, broker 리스트 `“topics”: [{“topic”: “foo1”](), “topic”: “foo2”], “version”:1 } DECOMMISSIONING BROKERS아직 파티션 재할당 툴은 디커미셔닝 브로커를 위한 재할당 플랜을 자동으로 생성할 수 없다. 관리자가 브로커의 호스팅 되는 모든 파티션 레플리카를 디커미션할 브로커로 옮겨한다. 브로커 디커미셔닝을 지원하는 툴을 추가할 계획 INCREASING REPLICATION FACTOR재할당 json에 추가할 레플리카를 지정하고, -execute 옵션을 사용해 실행 topic, broker partition 리스트 results matching ""No results matching "" |