소스 어플리케이션 (데이터 전송) -----
데이터 라인
-----> 타켓 어플리케이션 (데이터 수신)
시간이 지나며 소스 어플리케이션과 타켓 어플리케이션이 많아졌고, 자연스레 데이터 라인도 많아지게 됐다.
그런데 데이터 라인이 너무 복잡해졌기에 관리가 복잡해졌다.
이를 해결하기 위해 Apach Kafka가 등장
소스 어플리케이션 <-카프카
-> 타겟 어플리케이션
중간에서 소스 어플리케이션과 타켓 어플리케이션의 커플링을 약하게 하기 위해 등장
소스 어플리케이션 -> 카프카
: 데이터 전송 (클릭 로그, 결제 로그 등등 전송 형식 제한은 거의 없다)
카프카
-> 타겟 어플리케이션 : 데이터 가져옴 (로그 적재, 로그 처리)
카프카는 데이터를 담는데 토픽이라는 개념(큐와 비슷)을 사용
토픽에 데이터를 넣는 주체는 producer
토픽에서 데이터 꺼내는 주체는 consumer
(이 둘은 java 라이브러리로 돼있어서 구현 가능)
리더 파티션이 프로듀서로부터 데이터를 받는 주체!!
프로듀서에 설정할 수 있는 ack
ack?? 0,1,all
1) 리더 파티션이 데이터를 성공적으로 받았는지
2) 다른 파티션에 제대로 복제됐는지
0 : x , 속도는 빠르나 데이터 유실의 가능성
1 : 1), 다른 파티션으로의 데이터 유실 가능성 있다.
all : 1) + 2) 데이터 유실 가능성 x 속도 느리다
원본 + 복제본 합쳐서: ISR, in sync replica
데이터를 가져가도 파티션에서 데이터가 사라지지않는다.
데이터를 가져오는 것을 폴링(polling)
컨슈머 역할 :
토픽의 파티션으로부터 데이터를 polling (후에 db에 저장하거나 다른 파이프라인에 전달 가능)
파이션 오프셋 위치 기록 commit 가능 컨슈며 그룹별로 별도로 저장
컨슈머 그룹을 통해 병렬처리 가능
실습을 위해 1. AWS Ec2(Amazon Linux 2), 2. 로컬 Ubuntu 18.04 필요
1은 카프카 브로커
2는 카프카 클라이언트(프로듀서, 컨슈머 등등에 활용)
두 서버에 같은 버전의 kafka를 설치하는 것이 좋다. (나는 2.5.0)
$ wget https://archive.apache.org/dist/kafka/2.5.0/kafka_2.12-2.5.0.tgz
$ tar xvf kafka_2.12-2.5.0.tgz
카프카 패키지의 기본 설정으로 카프카 브로커는 1G, 주키퍼는 512MB로 힙 메모리가 설정돼있다.
ec2가 프리티어일 경우 메모리가 1G이기에 위의 1.5G를 감당할 수 없기에 힙 메모리 사이즈를 줄여주자.
환경변수로 KAFKA_HEAP_OPTS를 선언 후 echo 명령어로 확인해주자.
$ export KAFKA_HEAP_OPTS="-Xmx400m -Xms400m"
$ echo $KAFKA_HEAP_OPTS
-Xmx400m -Xms400m
Xms 최소 힙 메모리 사이즈, Xmx 최대
터미널에서 사용자가 입력한 환경변수는 터미널이 재시작하면 초기화되기에 ~/.bashrc 파일에 환경변수 선언문을 넣어줘서 터미널이 구동될 때마다 선언되게 하자. (Amazon Linux 2는 bash쉘을 사용하는데 실행될 때마다 ~/.bashrc가 반복적으로 구동된다.)