CheerUp_Cheers

Chapter44.1 토픽과 파티션4.1.1 적정 파티션 개수토픽 생성 시 파티션 개수 고려사항데이터 처리량메시지 키 사용 여부브로커, 컨슈머 영향도데이터 처리 속도 올리는 법컨슈머의 처리량 늘리는 것 스케일 업, GC 튜닝 → 컨슈머 특성상 다른 시스템과 연동으로 일정 수준 힘듬.컨슈머를 추가하여 병렬처리량을 늘리기. 프로듀셔 전송 데이터량 → 컨슈머 랙이 생김.메시지 키 사용 여부 메시지 키와 데이터 처리 순서에 대해 고려 해야 함.기본 파티셔너 메시지 키를 해시로 변환하여 파티션에 매칭함. 파티션 개수가 달라지는 순간 메시지키를 사용하는 특정 메시지 키의 순서는 보장 받을 수 없음.커스텀 파티셔너 파티션 개수가 변해도 메시지 키의 매칭을 가져갈 수 있게. 커스터밍하기 싫다면 처음부터 파티..

Chapter33.1 카프카 브로커,클러스터,주키퍼데이터 저장/전송실습한 저장된 파일 시스템 확인 config/server.properties의 log.dif 옵션에 정의한 디렉토리 ls /tmp/kafka-logs파티션 수만큼 생성된 디렉토리 확인 토픽의 0번 파티션에 존재하는 데이터 용어 log - 메시지와 메타테이터 index - 메시지의 오프셋 timeindex - 메시지에 포함된 timestamp값을 기준으로 인덱싱한 정보, 브로커가 적재한 데이터 삭제나 압축카프카는 파일 시스템에 저장한다.느려지지 않는가? 파일 입출력에대한 속도 이슈가있지만, 페이지 캐시 사용으로 디스크 입출력 속도를 높여서 문제 해결. → 브로커의 힙메모리를 크게 설정할 필요가 없다.데이터 복제, 싱크복제 단..

EC2SSH 접속 인스턴스 퍼블릭 IPv4 주소 ## 접속 ssh -i "{pem 키 경로}" ec2-user@{퍼블릭 IPv4 DNS}탄력적 IP 할당 인스턴스를 재시동해도 IP가 변경되지 않는다. ssh -i "{pem 키 경로}" ec2-user@{발급받은 탄력적 IP}자바설치 카프카 브로커는 스칼라와 자바로 작성되어 JVM 환경 위에서 실행. // 설치 sudo dnf install -y java-1.8.0-amazon-corretto-devel // 버전 확인 java -version카프카설치 // brew brew install wget // 가져오기 wget https://archive.apache.org/dist/kafka/2.5.0/kafka_2.12-2.5.0...

1.1 카프카 탄생탄생 배경소스 애플리케이션과 타깃 애플리케이션을 연결하는 개수가 많아짐.→ 장애 발생 시, 소스 애플리케이션에 그대로 전달.해결애플리케이션 끼리 연결이 아니라, 한곳에 모아 처리할 수 있도록 중앙 집중화.→ 의존도 최소화 (어느 타깃 애플리케이션에 넣을지 고민 없이 카프카에 넣기)파티션 동작파티션 내에서는 FIFO 방식의 큐 자료구조와 유사.다른 파티션끼리는 순서 보장은 되지 않음. 데이터 형식직렬화, 역직렬화로 통신하여 사실상 제한 없음.기술 용어프로듀서 : 큐에 데이터를 보냄컨슈머 : 큐에서 데이터를 가져감.브로커(서버) : 메시지를 전송하고 관리하는 역할.데이터 레이크 : 생성되는 데이터를 모두 모으는것데이터 파이프 라인데이터 수집 → 변경 → 적재의 자동화한 것.높은 처리량데이터..

1. 메시지큐 별 차이점메시지 큐로 사용할 수 있는 대표적인 미들웨어들이다.추가적으로 설명이 필요한 부분은 추가설명에 기입하도록 하겠다.항목 Redis Queue Kafka RabbitMQ 목적인메모리 데이터 저장소, 메시지 큐 가능분산 메시지 스트리밍 플랫폼고급 메시지 브로커 (AMQP 표준)데이터 저장기본적으로 메모리 기반 (디스크 옵션 있음)디스크 기반으로 데이터 영속성 보장디스크 기반으로 영속성 보장 (옵션 조정 가능)속도매우 빠름 (메모리 기반)빠름 (디스크 기반이지만 고효율 설계)빠름 (AMQP 프로토콜의 추가 오버헤드 존재)라우팅 기능*제한적 (List와 Pub/Sub 활용)없음 (토픽 기반, 라우팅은 소비자에서 결정)고급 라우팅 가능 (Exchange, Binding 등)메시지 처리량초..