이유즈 데엔 여정

하둡

: 대용량 데이터를 분산 처리할 수 있는 자바 기반의 오픈 소스 프레임워크.

 분산 시스템인 HDFS에 데이터를 저장하고, 맵리듀스를 이용해 데이터를 처리한다.

- 여러 대의 서버에 데이터 저장하고, 저장된 각 서버에서 동시에 데이터를 처리하는 방식

- 기존의 RDBMS와 달리 데이터처리에 적합하지 않고, 배치성으로 데이터를 저장하고 처리

ex. 회원이 관심있게 보는 물품들, 이동경로, 머무르는 시간 등 배치성으로 저장되는 데이터

RDBMS : 회원가입, 결제진행 등

즉 하둡은 RDBMS와 협력하는 것

HDFS (Hadoop DIstributed File System)

: 대용량 파일을 하둡에 안정적으로 저장할 수 있게 하는 파일 시스템.

- 네임노드, 데이터노드 로 구성

(1) 네임노드

: 메타데이터 관리(파일 시스템 유지) , 데이터노드 모니터링(데이터노드는 네임노드에게 3초마다 하트비트 전송. 네임노드는 이를 이용해 데이터노드의 실행상태와 용량을 체크함. 하트비트를 전송하지 않는 데이터노드는 장애서버로 판단함.)

블록관리 , 클라이언트 요청접수 

(2) 데이터노드 

: 클라이언트가 HDFS 에 저장하는 파일을 로컬 디스크에 유지한다. 이 때 파일은 두가지로 저장됨. ( 실제 저장되는 로우데이터, 체크섬이나 파일생성일자같은 메타데이터)

출처 : https://yookeun.github.io/java/2015/05/24/hadoop-hdfs/

토폴로지 : 2개 이상의 노드들과 선으로 이루어진 집합 (링형, 트리형, 성형)

카프카 스트림즈

- 토폴로지를 이루는 노드 : 프로세서 

- 노드와 노드를 이은 선 : 스트림 (토픽의 데이터)

프로세서 - (소스 프로세서, 스트림, 싱크) 3가지로 구성. 

(1) 소스 프로세서 : 데이터를 처리하기 위해 최초로 선언해야 하는 노드. 하나 이상의 토픽에서 데이터를 가져오는 역할

(2) 스트림 프로세서 : 다른 프로세서가 반환한 데이터를 처리하는 역할 (변환, 분기처리)

(3) 싱크 프로세서 : 데이터를 특정 카프카 토픽으로 저장하는 역할

ProducerRecord 생성 시 파라미터로 추가해야 한다. 

토픽 이름, 메시지 키, 메시지 값을 순서대로 파라미터로 넣고 생성했을 경우 메시지 키가 지정된다. 

ProducerRecord<String, String> record = new ProducerRecord<>
                ("test", "Pangyo", "23");

확인하기

메시지 키가 지정된 데이터는 kafka-console-consumer 명령을 통해 확인할 수 있다. 

property 옵션의 print, key, key.seperator 값을 주면 출력 화면에서

메시지 키, 값을 함께 확인할 수 있다. 

key.seperator설정값을 기준으로 나뉘어 한 줄로 출력된다. 

파티션을 직접 지정하고 싶을때)

토픽 이름, 파티션 번호, 메시지 키,값을 순서대로 파라미터로 넣고 생성하면 된다.

파티션 번호는 토픽에 존재하는 파티션 번호로 설정해야 한다. 

int partitionNo = 0;
ProducerRecord<String, String> record = new ProducerRecord<>(TOPIC_NAME, 
partitionNo, messageKey, messageValue) ;

프로듀서는 카프카 브로커로 데이터 전송 시 내부적으로 파티셔너, 배치 생성 단계를 거친다. 

전송하고자 하는 데이터는 ProducerRecord 클래스를 통해 인스턴스를 생성했지만

생성 필수 파라미터인 토픽, 메시지 값만 설정했다. 

ProducerRecord 생성 시 추가 파라미터를 사용해 오버로딩하여 내부 변수 선언할 수 있음.

파티션 번호를 지정하거나 타임스탬프 설정, 메시지 키 설정할 수도 있다. 

레코드의 타임스탬프는 카프카 브로커에 저장될 때 브로커 시간을 기준으로 설정.

필요에 따라 레코드 생성시간 또는 그 이전/이후로 설정할 수도 있다. 

카프카 프로듀서 인스턴스가 send() 메서드 호출하면 ProducerRecord는 파티셔너에서 토픽의 어느 파티션으로

전송될지 정해진다. 

파티셔너에 의해 구분된 레코드는 데이터를 전송하기 전에 어큐뮬레이터에 데이터를 버퍼로 쌓아놓고 발송한다. 

버퍼로 쌓인 데이터는 배치로 묶어서 전송함으로써 카프카의 프로듀서 처리량을 향상시킨다.

프로듀서 API를 사용하면 2가지 파티션 제공.

- 둘 다 메시지 키 있을 때는 메시지 키의 해시값과 파티션을 매칭하여 데이터를 전송한다. 

- 없을때는 파티션에 최대한 동일하게 분배한다. 

1. UniformStickyPartitioner (default)

- RoundRobinPartitioner의 단점 개선. 

- 높은 처리량, 낮은 리소스 사용률 가짐.

- 될 수 있으면 많은 데이터가 배치로 묶여 전송되어야 성능 향상을 기대할 수 있으므로 카프카 2.4.0 부터 유니폼스티키가 기본.

- 어큐뮬레이터에서 데이터가 배치로 모두 묶일 때까지 기다렸다가 배치로 묶인 데이터는 모두 동일한 파티션에 전송함으로써

  라운드 로빈에 비해 향상된 성능 가지게 됌

2. RoundRobinPartitioner

- 카프카 2.4.0 이전에는 라운드로빈이 기본 파티셔너였다.

- ProducerRecord가 들어오는 대로 파티션을 순회하며 전송하기 때문에 배치로 묶이는 빈도가 적다.

카프카 클라이언트 라이브러리에서는 사용자 지정 파티셔너를 생성하기 위한 Partitioner 인터페이스를 제공한다.

Partitioner 인터페이스 상속받은 사용자정의 클래스에서 메시지 키, 값에 따른 파티션 지정 로직을 적용할 수도 있다. 

파티셔너를 통해 파티션이 지정된 데이터는 어큐뮬레이터에 버퍼로 쌓인다. 

센더(sender) 스레드는 어큐뮬레이터에 쌓인 배치 데이터를 가져가 카프카 브로커로 전송한다. 

카프카 프로듀서는 압축 옵션을 통해 브로커로 전송 시 압축 방식을 정할 수 있다. 압축 옵션을 정하지 않으면 압축이 되지 않은 상태로 전송된다. 

압축하면 데이터 전송 시 네트워크 처리량에 이득을 볼 수 있지만 압축하는데 CPU 또는 메모리 리소스를 사용하므로 사용환경에 따라 적절한 압축 옵션을 사용해야 한다. 

(주의) 프로듀서에서 압축한 메시지는 컨슈머 애플리케이션이 압축을 풀게 되는데 이때도 컨슈머 애플리케이션 리소스가 사용된다.

프로듀서 주요 옵션

프로듀서 애플리케이션을 실행할 때 사용자가 반드시 설정해야하는 필수 옵션과,

사용자의 설정을 필수로 받지 않는 선택옵션이 있다. 

토픽 : 데이터를 구분하기 위해 사용하는 단위. 카프카는 토픽 이름 변경을 지원하지 않으므로 누구나 알아볼 수 있게, 팀 규칙에 따라

짓는것이 중요하다!

파티션에는 프로듀서가 보낸 데이터들(레코드)이 들어가 저장됨.

큐(queue)와 비슷한 구조! FIFO. 먼저 들어간 레코드는 컨슈머가 가져가게 됨. 하지만 pop을 써도 카프카에서는 삭제하지 않고 컨슈머가 가져가는 것과 별개로 관리됨. 

파티션은 카프카의 병렬처리의 핵심. 그룹으로 묶인 컨슈머들이 레코드를 병렬로 처리할 수 있도록 매칭된다. 

많은 레코드를 병렬로 처리하는 가장 좋은 방법은 컨슈머의 개수를 늘려 스케일 아웃 하는 것 . 

컨슈머 개수를 늘림과 동시에 파티션 개수도 늘리면 ==> 처리량이 증가한다. 

레코드

: 타임스탬프, 메시지 키, 메시지 값, 오프셋으로 구성

프로듀서가 생성한 레코드가 브로커로 전송되면 오프셋과 타임스탬프(브로커 기준 유닉스 시간)가 지정되어 저장된다. 브로커에 한번 적재된 레코드는 수정할 수 없고 로그 리텐션 기간 또는 용량에 따라서만 삭제된다. 

메시지 키 - 메시지 값을 순서대로 처리하거나 메시지 값의 종류를 나타내기 위해 사용

              이를 사용하면 프로듀서가 토픽에 레코드를 전송할 때 메시지 키의 해시값을 토대로 파티션을 지정하게 된다. = 동일한 메시지 키라면 동일 파티션에 들어감 (다만 어느 파티션에 지정될지 알 수 없고, 파티션 개수가 변경되면 메시지 키와 파티션 매칭이 달라지게 되므로 주의해야 한다. 메시지 키 사용 안하면 프로듀서에서 레코드 전송할 때 메시지 키를 선언하지 않으면 된다. null. )

메시지 값 - 실질적으로 처리할 데이터 들어있음. 메시지 키,값은 직렬화되어 브로커로 전송되므로 컨슈머가 이용할 때는 직렬화한 형태로 

                  역직렬화 수행해야 한다! 

오프셋 - 카프카 컨슈머가 데이터를 가져갈때 사용된다. 컨슈머 그룹으로 이루어진 카프카 컨슈머들이 파티션의 데이터를 어디까지 가져갔는지 명확히 지정할 수 있다. 

카프카에서 데이터의 시작점은 프로듀서이다. 프로듀서 애플리케이션은 카프카에 필요한 데이터를 선언하고 브로커의 특정 토픽 타피션에 전송한다. 프로듀서는 데이터를 전송할 때 리더 파티션을 가지고 있는 카프카 브로커와 직접 통신한다. 

브로커 : 프로듀서로부터 데이터를 전달받으면 , 프로듀서가 요청한 토픽의 파티션에 데이터 저장,

             컨슈머가 데이터 요청하면 파티션에 저장된 데이터 전달해줌. 

카프카는 파일 시스템에 저장하여 사용 (메모리나 DB에 저장하지 않음) , 이로인해 발생하는 처리 속도 이슈를 

페이지 캐시를 사용해 디스크 입출력 속도를 올려 문제 해결. 

페이지 캐시 ? : OS 에서 파일 입출력의 성능 향상을 위해 만들어놓은 메모리 영역. 

한번 읽은 파일의 내용은 메모리의 페이지 캐시 영역에 저장해 추후 동일한 파일의 접근이 일어나면

디스크에서 읽지 않고 메모리에서 직접 읽는 방식!

이를 사용하지 않았으면 카프카에서 캐시를 직접 구현해야 했을 것이고, 지속적으로 변하는 

데이터 때문에 가비지 컬렉션이 자주 일어나 속도가 현저히 늘려질 것,,

이 때문에 카프카 브로커를 실행하는데 힙 메모리 사이즈를 크게 설정할 필요가 없다. 

데이터 복제, 싱크

클러스터로 묶인 브로커 중 일부에 장애가 발생하더라도 데이터를 유실하지 않고 안전하게 사용하기 위해

토픽을 생성할 때 파티션의 복제 개수를 같이 설정. 

최솟값 : 1 (복제없음), 최댓값 : 브로커 개수만큼. 

팔로워들은 리더의 오프셋을 확인해 현재 자신이 가지고있는 오프셋과 차이가 나는 경우 리더로부터 데이터를 가져와 자신의 파티션에 저장하는 방식으로 복제함. 

장애 발생 시 팔로워 파티션 중 하나가 리더가 됨!! 

이로인해 저장 용량이 증가하지만, 데이터를 안전하게 사용할 수 있다. 

데이터가 일부 유실되어도 무관하고 데이터 처리 속도가 중요하면 1 , 2 로 설정하고 금융정보와 같이 유실되면 안되는 경우는 복제 개수를 3으로 설정해 최대 2개의 브로커에서 동시에 장애가 발생하더라도 데이터를 안정적으로 유지할 수 있도록 한다. (서버가 1대일 때를 가정)

컨트롤러

: 다른 브로커들의 상태를 체크하고 브로커가 컨트롤러에서 빠지는 경우 해당 브로커에 존재하는 리터 파티션을 재분배함. 

클러스터의 다수 브로커 중 한대가 컨트롤러의 역할을 함. 

다른 것들 중 하나는 코디네이터.

코디네이터

: 컨슈머 그룹의 상태를 체크하고 파티션을 컨슈머와 매칭되도록 분배하는 역할. 

컨슈머가 빠지면 매칭되지않은 파티션을 정상 동작하는 컨슈머로 할당하여 끊임없이 데이터가 처리되도록 도와줌. = 리밸런스

데이터 삭제 

: 컨슈머가 데이터 가져가도 토픽의 데이터는 삭제되지 않음. 브로커만 삭제 가능! 

삭제가 파일 단위 (로그 세그먼트) 로 이루어짐. 로그 세그먼트엔 다수의 데이터 들어있기 때문에 다른 DB 처럼 선별해 삭제할 수 없음. 

log.segment.bytes 또는 log.segment.ms 옵션에 값이 설정되면 세그먼트 파일이 닫힘. 그리고 그 설정값이 넘으면 삭제됨.

(메시지 키를 기준으로 오래된 데이터를 압축하는 정책을 가져갈 수도 있음)

주키퍼 : 카프카의 메타데이터를 관리하는데 사용. 

(주키러 쉘 명령어는 zookeeper-shell.sh 로 실행하고, bin 폴더 안에 있다.)

커맨드 라인 툴을 통해 카프카 브로커 운영에 필요한 다양한 명령을 내릴 수 있다. !!

카프카 클라이언트 애플리케이션을 운영할 때는 카프카 클러스터와 연동하여 데이터를 주고받는 것도 중요하지만

토픽이나 파티션 개수 변경과 같은 명령을 실행해야 하는 경우도 자주 발생함. ==> 커맨드 라인 툴, 툴별 옵션에 대해 알고있어야 한다!

명령어 실행 방법

1. 카프카 브로커가 설치된 인스턴스에 ssh로 원격 접속하여 명령을 실행

2. 브로커에 9092 로 접근 가능한 컴퓨터에서 명령 실행

 데이터를 전송 (프로듀서)

 받는 (컨슈머) 실습 

1. kafka-topics.sh 

토픽과 관련된 명령 실행 (토픽 : 카프카에서 데이터 구분하는 가장 기본적인 개념.)

카프카 클러스터에 토픽은 여러 개 존재할 수 있다.

토픽 생성하는 방법 1. 컨슈머 또는 프로듀서가 카프카 브로커에 생성되지 않은 토픽에 대해 데이터를 요청할 때. 2. 커맨드라인 툴로 명시적으로 토픽 생성. (추천!)

토픽을 생성할 때 동시에 처리하는 데이터 양이 많을 때는 파티션 개수를 100으로 설정 가능. 

단기간 데이터 처리만 필요할 때는 데이터 보관기간 옵션을 짧게 설정할 수도 있다. 

==> 토픽에 들어오는 데이터양과 병렬로 처리되어야 하는 용량을 잘 파악해 생성하는 것이 중요

<토픽 생성>

--create                        : 토픽 생성

--bootstrap-server      : 토픽을 생성할 클러스터를 구성하는 브로커들의 IP,port 적음

--topic                           : 토픽 이름 작성 (내부 데이터가 무엇이 있는지 유추 가능할 정도로 자세히!)

--partitions                   : 파티션 개수 지정

--replication-factor      : 토픽의 파티션을 복제할 복제 개수 

     1 : 복제하지않고 사용. 

     2 : 1개의 복제본 이용

--config                         : kafka-topics.sh 명령에 포함되지 않은 추가적인 설정 할 수 있음. (ex. retention.ms : 토픽의 데이터 유지하는 기간)

<토픽 리스트 조회>

bin/kafka-topics.sh --bootstrap-server 토픽이름:9092 --list

<토픽 상세 조회>

위에명령에 -describe --topic 토픽이름 

파티션 개수가 몇개인지, 복제된 파티션이 위치한 브로커의 번호, 기타 토픽 구성하는 설정들을 출력함. 토픽이 가진 파티션의 리더가 현재 어느 브로커에 존재하는지도 같이 확인할 수 있음. 

=> 클러스터의 성능이 좋지 않다면 이 명령어를 통해 파티션 쏠림 현상 확인하는 것도 좋음!

<토픽 옵션 수정>

kafka-topics.sh   : 파티션 개수 변경

kafka-configs.sh : 토픽 삭제 정책인 리텐션 기간 변경. // 카프카 2.5 까지는 --alter 옵션 사용했지만 추후 삭제 예정

다이나믹 토픽 옵션 (log.segment.bytes , log.retention.ms ) : kafka-configs.sh 로 수정

alter, partitions 옵션들을 사용해 파티션 개수 변경 가능.

토픽의 파티션을 늘릴 수는 있지만 줄일 수는 없으므로 주의 !! 

--add-config 옵션 : 이미 존재하는 설정값은 변경하고 존재하지 않는 설정값은 신규로 추가한다.

2. kafka-console-producer.sh

생성된 토픽에 데이터 넣을 수 있는 명령어. 

토픽에 넣는 데이터는 레코드라고 부르며 메시지 키, 메시지 값으로 이루어짐. (key, value)

(1) 메시지 키 없이 메시지 값만 보내기

메시지 키는 자바의 null 로 기본 설정되어 브로커로 전송된다. 

단, String 이 아닌 타입으로는 직렬화하여 전송 불가. 하고싶으면 프로듀서 애플리케이션 직접 개발해야!

(2) 메시지 키 가지는 레코드 전송하기 

parse.key 를 true 로 두면 레코드를 전송할 때 메시지 키를 추가할 수 있음. 

key.separator : 메시지 키와 메시지 값 구분하는 구분자 선언 (default : \t 탭!)

메시지 키와 값을 함께 전송한 레코드는 토픽의 파티션에 저장된다 . 

3. kafka-console-consumer.sh 

토픽으로 전송한 데이터 확인하는 명령어

필수옵션 : --bootstrap-server 에 클러스터 정보 

                --topic 에 토픽 이름 적기

추가 : --from-beginning 에 토픽에 저장된 가장 처음 데이터부터 출력함

데이터 순서가 출력되는 순서와 다른 이유 : 파티션때문에. 

위의 명령으로 토픽의 데이터를 가져가게 되면 토픽의 모든 파티션으로부터 동일한 중요도로 데이터 가져감. 

이로인해 데이터 순서가 달라지게 되는 것 .

데이터 순서 보장하고 싶다면 파티션 1개로 구성된 토픽을 만드는 것 !!

4. kafka-consumer-group.sh 

생성된 컨슈머 그룹의 리스트 보는 명령어

group , topic, partition : 조회한 컨슈머 그룹이 마지막으로 커밋한 토픽,파티션 나타냄 

- 가장 첫번째 줄 hallo-group 이름의 컨슈머 그룹이 hallo.kafka 토픽의 1번 파티션의 레코드가 마지막으로 커밋됨

 current-offset  : 컨슈머 그룹이 가져간 토픽의 파티션에 가장 최신 오프셋(파티션의 각 레코드의 할당된 번호)이 몇번인지 나타냄.

- 이 번호는 데이터가 파티션에 들어올 때마다 1씩 증가함!! 

- 위 사진에선 1번 파티션에 가장 최신 오프셋은 3. 3개의 데이터가 들어간 것 알 수 있음.

log-end-offset : 해당 컨슈머 그룹의 컨슈머가 어느 오프셋까지 커밋했는지 알 수 있음. 

- 커런트는 로그앤드보다 같거나 작은 값.

lag : 컨슈머 그룹이 파티션에 있는 데이터를 가져가는데 얼마나 지연이 발생하는지 나타냄

- 커밋한 오프셋과 해당 파티션의 가장 최신 오프셋 간의 차이

consumer-id : 컨슈머의 토픽 할당을 카프카 내부적으로 구분하기 위해 사용하는 id. 자동설정됨 

5. kafka-verifiable-producer , consumer.sh

kafka-verifiable로 시작하는 2개의 스크립트를 사용하면 String 타입 메시지 값을 코드 없이 주고받을 수 있음.

카프카 클러스터 설치가 완료된 이후 토픽에 데이터를 전송해 

간단한 네트워크 통신 테스트를 할 때 유용!

max~. :verify 로 보내는 데이터개수 지정. -1 : 종료될 때까지 계속 데이터를 토픽으로 보냄

--topic : 데이터를 받을 대상 토픽 입력

마지막 줄에서 avg_~ 에서 평균 처리량 확인 가능

6. kafka-delete-records.sh

이미 적재된 토픽의 데이터 지우는 명령어

가장 오래된 데이터 (가장 낮은 숫자의 오프셋) ~ 특정 시점의 오프셋까지 삭제 가능!

삭제하고자 하는 데이터에 대한 정보를 파일로 저장해 사용해야 한다. 

삭제하고자 하는 토픽, 파티션, 오프셋 정보가 들어가야 한다. 

config/ server.properties  : 카프카 브로커가 클러스터 운영에 필요한 옵션들을 지정. 

여기서는 실습용 카프카 브로커를 실행할 것이므로 advertised, listener만 설정!

(카프카 클라이언트 또는 커맨드 라인 툴을 브로커와 연결할 때 사용된다.)

인스턴스 iP 와 카프카 포트를 PLAINTEXT:// 와 함께 넣고 advertised, listeners 를 주석 해제한다. 

==> kafka-server-start.sh 와 함께 지정할 수 있다. 

이미 실행되고있는 브로커의 설정을 변경하고 싶다면 브로커를 재시작해야하므로 신중히 설정해야 한다. 

broker.id : 실행하는 카프카 브로커의 번호를 적는다. 클러스터를 구축할 때 브로커들을 구분하기 위해 단 하나뿐인 번호로 설정해야 함. 

다른 카프카 브로커와 id 같을 경우 에러남

브로커 통신을 위해 열어둘 인터페이스 IP , port, 프로토콜 설정. 따로 설정하지 않으면 모든 IP, port 에서 접속할 수 있다. 

카프카 클라이언트 또는 커맨드 라인 툴에서 접속할 때 사용하는 IP, port 정보. 

보안 설정 시 프로토콜 매핑을 위한 설정.

네트워크를 통한 처리를 할 때 사용할 네트워크 스레드 개수 설정

카프카 브로커 내부에서 사용할 스레드 개수 지정

통신을 위해 가져온 데이터를 파일로 저장할 디렉토리 위치. 디렉토리 생성되지 않았으면 오류나므로 브로커 실행 전에 디렉토리 생성 여부 확인.

파티션 개수를 명시하지 않고 토픽 생성할 때 기본 설정되는 파티션 개수. 파티션 개수 많아지면 병렬처리 데이터 양이 늘어난다. 

-카프카 브로커가 저장한 파일이 삭제되기까지 걸리는 시간 설정. 가장 작은 단위가 기준이므로 log.retention.hours 보다 ~.ms 값을 설정하여 운영하는 것이 좋다. ms = -1 이면 영원히 삭제되지 않는다.

- 브로커가 저장할 파일의 최대 크기 지정 / 데이터 양이 많아 이 크기를 채우면 새로운 파일 생성됨.

-브로커가 저장한 파일 삭제하기 위해 체크하는 간격 지정할 수 있음. 

카프카 브로커와 연동할 주키퍼의 IP, port 설정. 

주키퍼의 세션 타임아웃 시간 지정. 

카프카 브로커를 실행하기 위해선 힙 메모리 설정이 필요하다. 

브로커) 레코드의 내용은 페이지 캐시로 시스템 메모리를 사용하고 나머지 객체들을 힙 메모리에 저장하여 사용한다.

실습용으로 생성한 인스턴스는 1G 메모리를 가지고 있으므로 카프카 브로커와 주키퍼를 기본 설정으로 실행하면 에러가 난다.

(카프카 패키지 힙 메모리 - 카프카 브로커 : 1G, 주키퍼 - 512MB)

따라서 힙 메모리 사이즈를 미리 환경변수로 지정해서 살행해야 함! (1.5G 이상 메모리 가진 EC2 인스턴스면 ㄱㅊ)

환경변수를 export 명령어로 선언하고

echo + 환경변수 로 정상적으로 설정되었는지 확인!

(힙 메모리 최소 크기 : Xms, 최대 크기 Xmx)

터미널에서 사용자가 입력한 환경변수는 터미널 세션이 종료되고 나면 다시 초기화되어 재사용이 불가능하므로 

이 환경변수 선언문을 ~/.bashrc 파일에 넣으면 된다. (bash 쉘이 실행될 때마다 반복적으로 구동되어 적용되는 파일)

개발하는 환경에 맞는 힙 메모리 사이즈를 KAFKA_HEAP_OPTS 환경변수로 선언한다. 

source : 스트립트 파일을 수정한 후에 수정된 값을 바로 적용하기 위해 사용. 

수정한 .bashrc 를 바로 반영하도록함. 

이제 터미널 세션이 끊기거나 인스턴스에 재접속하더라도 KAFKA_~ 환경변수를 재선언할 필요가 없다.

 (카프카 실행 시 메모리를 설정하는 부분은 카프카를 실행하기 위해서 사용하는 스크립트.)

* if ~ fi 문에서 카프카 브로커 실행 시 사전에 정의할 자바 힙 메모리 사이즈 지정. 저 값은 default 값이다. 최소 Xms, 최대 Xmx

* -daemon 옵션을 사용하여 카프카 브로커가 실행될 때 백그라운드로 실행될지 포어그라운드로 실행될지 설정할 수 있다.

-daemon 옵션을 붙이면 백그라운드로 실행되어 터미널 세션 끊기더라도 카프카 브로커는 계속해서 동작함.

                            붙이지 않으면 포어그라운드 동작 => ctrl + c 누르기 전까지 카프카 로그가 출력되고 다른 작업을 실행할 수 없다. 

일시적인 브로커 테스트가 아닌 이상 -daemon 옵션을 붙여 백그라운드로 실행하는 것이 일반적인 운영방법이다. 

EC2 인스턴스를 발급받고 자동 생성된 기본 보안 그룹에 가서, 

Inbound 인바운드 : 인스턴스 외부로부터 들어오는 트래픽.  ==> ssh(22번 포트) 만 가능!

Outbound 아웃바운드 : 인스턴스로부터 나가는 트래픽        ==> 모든 IP, 모든 port 접속 가능으로 기본 설정.

카프카 브로커의 기본 포트 : 9092

주키퍼 기본 포트 : 2181

EC2 에 설치된 브로커에 접속하기 위해서는 AWS EC2의 보안 그룹 인바운드 설정에 해당 포트들 열어야 한다. source IP 는 위치무관(any)로 설정 가능, but 보안 신경쓰일 경우 자신의 IP 확인하여 입력하기.

any 로 설정하는 경우 고정 IP 아닌 컴퓨터 사용할 경우에는 실습환경이 달라지거나 와이파이망이 달라질 때마다 IP 변경됨.