나의 개발 일상 기록

[Tomcat] JSESSIONID

느린 거북이 — Thu, 24 Mar 2022 07:53:51 +0900

JSESSIONID

Session에 대해서 문득 궁금한 부분이 생겼습니다. 만약 사용자 A와 사용자 B가 있다고 한다면 로그인이 된 상태에서 서버는 Session의 정보에 담긴 각 사용자에 대한 로그인 아이디를 HttpSession.getAttribute("userId") 이와 같은 방식으로 정보를 조회를 하는데 과연 어떤 방식을 통해 각 사용자 Session을 구분해서 정보를 가지고 오는 걸까라는 궁금증이 생겼습니다. 구글링을 통해 JSESSIONID를 통해 각 브라우저의 Session을 구분해서 정보를 조회 할 수 있다고 알게되었습니다.

JSESSIONID란?

Tomcat 컨테이너에서 세션을 유지하기 위해 발급하는 키로 HTTP 프로토콜은 무상태(stateless) 하기 때문에 요청 시 마다 새로운 연결이 생성되고 응답 후 연결은 끊어지게 되므로 상태를 유지할 수 없게 됩니다. 상태를 저장하기 위해서 Tomcat은 JSESSIONID 쿠키를 클라이언트에게 발급해주고 이 값을 통해 세션을 유지할 수 있도록 해줍니다.

쿠키 형태로 전송되는 JSESSIONID 동작방식

각 사용자가 브라우저를 통해 웹 페이지 URL 입력 후 서버에 요청을 한다면 서버에서 요청한 사용자가 최초 요청했다고 판단되면 JSESSIONID 값을 사용자에게 전달해줍니다. 전달된 JSESSIONID 값은 쿠키 형태로 사용자의 매번 요청때마다 서버에 전달하게 됩니다. 사용자에게 전달 받은 JSESSIONID 값으로 동일한 사용자의 요청인지를 판단하여 사용자 정보를 유지할 수 있게 됩니다.

JVM Cannot allocate memory 에러 해결

느린 거북이 — Fri, 4 Mar 2022 00:31:54 +0900

Spring boot를 사용해서 어플리케이션을 개발하는 중 jenkins 자동 배포를 하는 과정에서

다음과 같은 에러가 나면서 build가 되지 않았습니다.

원인

시스템의 물리적 RAM 또는 스왑 공간 부족
프로세스 크기 제한에 도달

구글링을 통해 많은 다양한 해결 방법이 있다는 것을 알게 되었습니다. 그 중에서도 저는 Swap 공간을 늘리는 방법으로 접근하였습니다.

Swap 파티셔닝

1. Swap 공간 확인

free -h

2. Swap 공간 확인

$ touch /var/spool/swap/swapfile 
$ dd if=/dev/zero of=/var/spool/swap/swapfile count=2048000 bs=1024

swap 파일 생성 후 2G의 메모리를 할당하였습니다.

chmod 600 /var/spool/swap/swapfile

권한 설정을 해줍니다.

$ mkswap /var/spool/swap/swapfile
$ swapon /var/spool/swap/swapfile

파일 포맷을 Swap으로 변환하고 Swap File로 등록해줍니다.

3. Swap 영역 확인

4. jenkins 자동 배포

해결!!

[FCM] FireBase를 활용한 Web Push Alarm

느린 거북이 — Sat, 26 Feb 2022 21:39:33 +0900

FireBase를 활용한 Web Push Alarm

사전 작업

1. Firebase 프로젝트 생성

https://console.firebase.google.com/

위의 url을 접속하여 Friebase 프로젝트를 생성합니다. 프로젝트 생성 과정은 간단하여 생략하였습니다.

2. Web 추가

아래의 그림에서 Web(3번째 아이콘)아이콘을 클릭하여 Web을 생성합니다.

내 웹 닉네임을 본인이 원하는 명으로 기입 후 앱 등록 버큰을 클릭합니다.

3. 프로젝트 새 비공개 키 생성

프로젝트 진입 후 좌측 상단에 아래의 그림에 표시된 문양을 클릭 후 프로젝트 설정을 클릭합니다.

프로젝트 설정 화면에서 상단의 Tab 메뉴에서 서비스 계정을 선택합니다.

서비스 계정 Tab을 선택하면 [새 비공개 키 생성] 버튼을 클릭하하면 ***.json 파일이 생성됩니다.

4. Script에 설정할 프로젝트 정보 확인

프로젝트 설정 화면에 상단의 Tab 메뉴에서 일반을 선택합니다. 스크롤을 아래로 내리면 SDK 설정 및 구성에 대한 정보를 확인할 수 있습니다. 해당 부분은 추후 Script에서 사용할 정보 입니다.

FCM 작업

FCM Web Push를 구현하기 위해 아래의 그림처럼 Java 및 다른 파일들이 필요합니다. 사전 작업 단계에서 '새 비공개 키 생성' 에서 받은 json 파일은 resources 경로 아래에 위치해 둡니다. (java11, gradle 환경에서 진행하였습니다.)

1. Java 백엔드 작업

Dependecny 설정

build.gradle

dependencies {
	// FCM push
	implementation 'com.google.firebase:firebase-admin:6.8.1'
}

FCM 초기화

어플맄이션이 시작될 때 Firebas 프로젝트에 본인의 APP을 등록해주어야 합니다. 만일 두번 등록이 되면 에러가 나므로 시작할 때 초기화를 해줍니다.

FirebaseInt

@Service
public class FirebaseInit {

    private static final String path = "fooddelivery-f80a5-firebase-adminsdk-arc1t-21f2efbc96.json";

    @PostConstruct
    public void init(){
        try{
            FirebaseOptions options = new FirebaseOptions.Builder()
                    .setCredentials(
                            GoogleCredentials.fromStream(
                                    new ClassPathResource(path).getInputStream()
                            )
                    ).build();

            if(FirebaseApp.getApps().isEmpty()){
                FirebaseApp.initializeApp(options);
            }
        }catch (IOException e){
            e.printStackTrace();
        }
    }
}

Send Message

메세지를 보낼 때 토큰과 토픽 방식으로 보낼 수 있습니다. 해당 Service에서는 Token 방식을 채택하여 메세지를 보내보았습니다.

FCMService

@Slf4j
@Service
public class FCMService {

    public void sendFcm(FcmNotificationRequest fcmNotificationRequest) {
        Message message = Message.builder()
                .setToken(fcmNotificationRequest.getToken())
                .setWebpushConfig(WebpushConfig.builder().putHeader("ttl", "300")
                        .setNotification(new WebpushNotification(fcmNotificationRequest.getTitle(),
                                fcmNotificationRequest.getMessage()))
                        .build())
                .build();

        try{
            String response = FirebaseMessaging.getInstance().sendAsync(message).get();
            log.info("Sent message: " + response);
        }catch (Exception e){
            log.error("FCM PUSH ERROR");
            log.error(e.getMessage());
        }
    }
}

Message Builder를 통해 메세지를 정삭적으로 보낸다면 response에는 아래의 그림처럼 message return값을 확인이 가능합니다.

* FCMController는 간단히 request 받았을 경우 html로 보내주는 간단한 로직 구성이 되어있고, MvcConfiguration의 경우 html 경로를 설정해주는 코드가 작성이 되어있기에 생략하였습니다.

2. 프론트엔드 작업

firebase-messaging-sw.js 파일 생성

servicework에 등록하기 위해 firebase-messageing-sw.js 파일을 생성합니다. 해당 파일의 명을 동일하게 해주셔야 servicework에 등록이 됩니다.

importScripts('https://www.gstatic.com/firebasejs/5.9.2/firebase-app.js');
importScripts('https://www.gstatic.com/firebasejs/5.9.2/firebase-messaging.js');

// Initialize Firebase
let firebaseConfig = {
    apiKey: "",
    authDomain: "",
    projectId: "",
    storageBucket: "",
    messagingSenderId: "",
    appId: "",
    measurementId: ""
};
firebase.initializeApp(firebaseConfig);
const messaging = firebase.messaging();

firebaseConfig의 내용은 사전 작업 중 4. Script에 설정할 프로젝트 정보 확인의 내용을 참고하셔서 작성을 하시면 됩니다.

fcm.html 작성

firebaseConfig에 내용에 들어갈 정보 또한 사전 작업 단계에서 4번 내용을 참고하셔서 작성을 해주시면 됩니다.

<!DOCTYPE html>
<html xmlns xmlns:th="http://www.thymeleaf.org">
<head>
  <meta charset="UTF-8">
  <title>FCM</title>
</head>
<body>
<h1>Test page!</h1>
<script src="https://www.gstatic.com/firebasejs/5.9.2/firebase.js"></script>
<script src="https://www.gstatic.com/firebasejs/5.9.2/firebase-app.js"></script>
<script src="https://www.gstatic.com/firebasejs/5.9.2/firebase-messaging.js"></script>

<script th:inline="javascript">

    let firebaseConfig = {
        apiKey: "",
        authDomain: ",
        projectId: "",
        storageBucket: "",
        messagingSenderId: "",
        appId: "",
        measurementId: ""
    };

    firebase.initializeApp(firebaseConfig);

    const messaging = firebase.messaging();

    messaging.requestPermission()
        .then(function() {

            return messaging.getToken();
        })
        .then(async function(token) {
            console.log(token);

            messaging.onMessage(payload => {
                console.log(payload);

            })
        })
</script>
</body>
</html>

화면 초기 진입 시 messaging.requestPermission() 에 의해 Push 알람 권한 요청 화면이 나오게 됩니다.

Token 정보 확인

개발자 도구를 열어 Console를 확인 해보시면 Token 정보가 나오게 되는 것을 확인하실 수 있습니다.

ServiceWork 등록

프론트엔드 작업에서 firebase-messageing-sw.js 파일이 Service Workes에 등록이 됩니다.

Web Push 발송

[AWS] Kafka 설치

느린 거북이 — Thu, 24 Feb 2022 14:25:39 +0900

Kafka 설치 과정 정리

1. Java 8 버전 이상 설치

-> sudo yum install -y java-1.8.0-openjdk-devel.x86_64

2. Kafka 설치 및 압축 해제

-> wget https://downloads.apache.org/kafka/3.0.0/kafka_2.12-3.0.0.tgz

Kafka 설치

-> tar xvf kafka_2.12-3.0.0.tgz

압축 해제

3. Kafka heap memory 설정

-> export KAFKA_HEAP_OPTS="Xmx400m -Xms400m"

Kafka 패키지의 기본 힙 메모리 설정이 Kafka = 1G, Zookeeper = 512M 으로 설정되어 있어서 프리티어의 메모리 1G 에서는 Kafka와 Zookeeper를 동시에 실행하면 "Cannot allocate memory"와 같은 문제가 방생합니다.

4. Kafka 설정 파일 수정

-> vi config/server.properties

아래의 그림 처럼 두가지 항목을 수정해줍니다.

advertised.listeners는 통신을 위해 열어두는 PROTOCOL, IP, PORT를 지정합니다.

5. zookeeper 실행 및 확인

-> bin/zookeeper-server-start.sh -daemon config/zookeeper.properties

-> jps

6. Kafka 실행 및 확인

-> bin/kafka-server-start.sh -daemon config/server.properties

-> jps

[AWS] Redis 설치

느린 거북이 — Wed, 23 Feb 2022 17:39:26 +0900

Redis 설치 과정 정리

1. Redis 설치 전 linux update를 하고 gcc make 설치

1. linux update

-> sudo yum update -y

2. gcc make

-> sudo yum install gcc make -y

2. Redis 설치 및 압축풀고 gcc make로 컴파일

1. Redis 설치

-> wget http://download.redis.io/releases/redis-6.2.5.tar.gz

2. Redis 압축해제

-> tar xzf redis-6.2.5.tar.gz

3. 경로 진입

-> cd redis-6.2.5

4. gcc make 컴파일

-> make

3. 디렉토리 생성 및 Redis 설정 파일 복사

1. 디렉토리 생성

-> sudo mkdir /etc/redis

-> sudo mkdir /var/lib/redis

2. Redis 설정 파일 복사

-> sudo cp src/redis-server src/redis-cli /usr/local/bin/

-> sudo cp redis.conf /etc/redis/

4. redis.conf 설정파일 수정

1. 설정파일 수정

-> sudo vi /etc/redis/redis.conf

5. Redis 서버 초기화 스크립트 다운로드

1. 스크립트 다운로드

-> wget https://raw.github.com/saxenap/install-redis-amazon-linux-centos/master/redis-server

6. /etc/init.d로 옮기고 권한을 설정

1. init.d 경로 변경

-> sudo mv redis-server /etc/init.d

2. 권한 설정

-> sudo chmod 755 /etc/init.d/redis-server

7. redis-server 파일에 redis 항목 체크

1. Redis 항목 체크

-> sudo vim /etc/init.d/redis-server

8. Redis 실행

1. 실행

-> sudo service redis-server start

9. Redis 접속

[Spring] TDD(Test-Driven-Development)

느린 거북이 — Tue, 22 Feb 2022 17:41:16 +0900

TDD(Test-Driven-Development)란?

TDD란 '테스트 주도 개발' 이라고 불립니다. 반복 테스트를 이용한 소프트웨어 방법론으로 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현합니다. 짧은 개발 주기의 반복에 의존하는 개발 프로세스입니다. 애자일 방법론 중 하나인 eXtream Programming(XP)의 ‘Test-First’ 개념에 기반을 둔 단순한 설계를 중요시합니다.

eXtream Programming(XP)란?

미래에 대한 예측을 최대한 하지 않고 지속적으로 프로토타입을 완성하는 애자일 기방법론 중 하나입니다. 이 방법론은 추가 요구사항이 생기더라도 실시간으로 반영할 수 있습니다.

TDD 개발주기

맨 위의 그림(TDD의 개발주기)를 참고하시면 됩니다.

- Red단계 : 실패하는 테스트 코드를 먼저 작성합니다.

- Green단계 : 테스트 코드를 성공시키기 위한 실제 코드를 작성합니다.

- Yellow단계 : 중복 코드 제거, 일발화 등의 리팩토링을 수행합니다.

실패하는 테스트 코드를 작성할 때까지 실제 코드를 작성하지 않는 것과, 실패 코드를 작성하지 않는 것과, 실패하는 테스트를 통과할 정도의 최소 실제 코드를 작성해야하는 것이 중요합니다. 이를 통해, 실제 코드에 대해 기대되는 바를 보다 명확하게 정의함으로써 불필요한 설계를 피할 수 있고, 정확한 요구 사항에 집중할 수 있습니다.

TDD 개발 방식의 장점

보다 튼튼한 객체 지향적인 코드 생산

TDD는 코드의 재사용 보장을 명시하므로 TDD를 통한 소프트웨어 개발 시 기능 별 철저한 모듈화가 이뤄집니다. 이는 종속성과 의존성이 낮은 모듈로 조합된 소프트웨어 개발을 가능하게 하며 필요에 따라 모듈을 추가하거나 제거해도 소프트웨어 전체 구조에 영향을 미치지 않게 됩니다.

재설계 시간의 단축

테스트 코드를 먼저 작성하기 때문에 개발자가 지금 무엇을 해야하는지 분명히 정의하고 개발을 시작하게 됩니다. 또한 테스트 시나리오를 작성하면서 다양한 예외사항에 대해 생각해 볼 수 있습니다. 이는 개발 진행 중 소프트웨어의 전반적인 설계가 변경되는 일을 방지할 수 있습니다.

디버깅 시간의 단축

TDD의 경우 자동화 된 유닛테스팅을 전재하므로 특정 버그를 손 쉽게 찾아낼 수 있습니다.

테스트 문서의 대체 가능

TDD를 하게 될 경우 테스팅을 자동화 시킴과 동시에 보다 정확한 테스트 근거를 산출할 수 있습니다.

추가 구현의 용이함

TDD의 경우 자동화된 유닛 테스팅을 전제하므로 테스트 기간을 획기적으로 단축시킬 수 있습니다.

TDD 개발 방식의 단점

가장 큰 단점은 바로 생산성 저하입니다. 왜냐하면 처음부터 2개의 코드를 짜야하고, 중간 테스트를 하면서 고쳐나가야 하기 때문입니다. TDD방식의 개발 시간은 일반적인 개발 방식에 비해 대략10~30% 정도가 늘어납니다.

[MySQL] Connection Blocked Error

느린 거북이 — Tue, 15 Feb 2022 15:58:08 +0900

Connection Blocked Error 현상

MySQL 서버를 평시 잘 사용을 하다 Connection을 하려고 하는데 갑작스럽게 아래와 같은 에러가 발생하였습니다.

ERROR 1129(00000): Host '*' is blocked because of many connection errors. Unblock with 'mysqladmin flush-hosts'

구글링을 통해 원인을 파악을 해보니 Host로부터 접속 요청 max_connect_errors 와 관련된 접속 연결 설정값 보다 초과하여 발생하여 설정된 값 이상의 Host에서 연결이 발생하여 MySQL에서는 해당 Host를 Block을 하게 된다는 것을 알게 되었습니다.

해결방법

1. MySQL 접속합니다.

- mysql -u root -p

2. max_connect_errors 카운트 확인

- select @@global.max_connect_errors;

3. 에러 카운트 초기화

- flush hosts;

4. max_connections 변경

- set global max_connections=300;

5. max_connect_errors 변경

- set global max_connect_errors=10000;

[트래픽 분산처리] 로드밸런싱(Load Balancing)

느린 거북이 — Tue, 15 Feb 2022 15:01:53 +0900

LOAD BALANCING

1. 로드밸런싱이란?

트래픽이 많을 때 여러 대의 서버가 분산처리하여 서버의 로드율을 증가, 부하량, 속도저하 등 고려하여 분산처리하여 해결해주는 서비스입니다.

로드밸런싱(Load Balancing)을 해주는 소프트웨어 혹은 하드웨어 장비를 로드밸런서(Load Balancer)라고 합니다.

동작 방식

1. 네트워크 상단에 L4 스위치 가상서버가 존재하여 서버로 들어오는 패킷을 리얼 서버로 균일하게 트래픽을 분산

2. 서버에 장애가 발생하면 이를 감지하여 정상적으로 작동하는 서버로 트래픽을 분산

2. L4 Load Balancing

L4는 L4 계층에서 동작하는 Load Balancer 이므로 네트워크 계층이나 트랜스포트 계층의 정보를 바탕으로 로드를 분산합니다. 다시 말해,, IP 주소나 Port번호, MAC 주소, 전송 프로토콜 등에 따라 트래픽을 나누고 분산처리 하는 것이 가능합니다.

L4 Load Balancing 방법

1. Round Robin(라운드 로빈 기반)

- 세션을 각 서버에 순차적으로 맺어주는 방식입니다. 단순히 순서에 따라 세션을 할당하기 때문에 경우에 따라 같은 처리량을 보장받지는 않습니다.

2. 가중치 및 비율 할당 방식

- 서버마다 비율을 설정해두고 해당 비율 만큼 세션을 맺어주는 방식입니다. 특정 서버의 성능이 월등히 뛰어나다면 해당 서버로 세션을 많이 맺어주도록 가중치를 설정하고 나머지 low급의 서버들은 적은 세션이 맺어질 수 있도록 가중치를 설정합니다.

3. Least Connection(최소 연결 기반)

- 가장 적은 세션을 가진 서버로 트래픽을 보내는 방식입니다.

4. Response Time(응답 시간 기반)

- 가장 빠른 응답 시간을 보내는 서버로 트래픽을 우선 보내주는 방식입니다. 각 서버들의 가용 가능한 리소스와 성능, 처리중인 데이터 양이 다를 경우 적합한 방식입니다.

5. Hash(해시 기반)

- 특정 클라이언트는 특정 서버로만 할당 시키는 방식입니다. 특정 IP 주소 또는 Port의 클라이언트들은 특정 서버로만 세션이 맺어지도록 합니다. 경로가 보장되며 접속자 수가 많을수록 분산 및 효율이 뛰어납니다.

6. Bandwidth(대역폭 기반)

- 서버들과의 대역폭을 고려하여 트래픽을 분산시키는 방법입니다.

3. L7 Load Balancing

L7 Load Balancer는 L4 Load Balancer의 기능을 포함하는 것 뿐만 아니라 OSI 7계층의 프로토콜을 바탕으로도 분산 처리가 가능합니다.

L7 Load Balancing 방법

1. URL Switching

- 특정 하위 URL들은 특정 서버로 처리하는 방식입니다. 특정 URL을 가진 주소들은 서버가 아닌 별도의 스토리지에 있는 객체 데이터로 바로 연결되도록 구성할 수 있습니다.

2. Context Switching

- 클라이언트가 요청한 특정 리소스에 대해 특정 서버 등으로 연결 해줄 수 있습니다. 예를 들어 이미지 파일에 대해서는 확장자를 참조하여 별도로 구성된 이미지 파일이 있는 서버/스토리지로 직접 연결해줄 수 있습니다.

3. Persistenve with Cookies(쿠키 지속성)

- 쿠키 정보를 바탕으로 클라이언트가 연결 했었던 동일한 서버에 계속 할당해 주는 방식입니다.

4. 로드밸런싱 장/단점

장점

- 로드밸런싱을 이용하면 한 서버가 다운되더라도 이중화시킨 다른 서버에서 서비스를 지속하여, 사용자들이 문제를 인지하지 못하게 할 수 있습니다.

- 단지 노드를 추가하는 것 만으로 서비스가 확장성을 가질 수 있습니다.

단점

- 로드밸랜서를 사용할 때 어려운 문제 중 하나는 세션 데이터를 관리하는 것입니다. 이러한 문제를 해결하기 위해 세션을 고정(session sticky)를 합니다. 그러나 고정된 세션의 노드에 장애가 발생하면 고정한 의미가 없어집니다.

[Kafka] Kafka Producer&Consumer Application

느린 거북이 — Tue, 5 Oct 2021 09:27:47 +0900

Kafka Producer Application

Kafak Producer는 데이터를 프로듀싱 즉 생산하는 역할을 합니다. 즉, 데이터를 Kafka Topic에 생성합니다.

Producer의 역할

Topic에 해당하는 메시지를 생성
특정 Topic으로 데이터를 publish
처리 실패/재시도

gradle 설정

compile group: 'org.apache.kafka', name: 'kafka-clients', version: '2.3.0'

Kafka Producer를 작성한 코드

public class Producer{
    public static void main(String[] args) throws IOException{
        
        Properties configs = new Properties();
        configs.put("bootstrap.servers", "localhost:9092");
        configs.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
        configs.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
        
        KafkaProducer <String, String> producer = new KafkaProducer<String, String>(configs);
        
        ProducerRecord record = new ProducerRecord<String, String>("click_log", "click");
        
        producer.send(record);
        
        producer.close();
    }
}

Properties configs

Producer를 위한 설정입니다. 자바 프로퍼티 객체를 통해 Producer의 설정을 정의합니다. 부트스트랩 서버 설정을 로컬 호스의 Kafka를 바라보도록 설정을 의미합니다. Kafka broker의 주소목록은 되도록이면 2개 이상의 ip와 port를 설정하도록 권장합니다.

KafkaProducer <String, String> producer

설정한 프로퍼티로 Kafka Producer 인스턴스를 생성합니다.

ProducerRecord record

ProducerRecord 인스턴스를 생성할 때 어느 Topic에 넣을 것인지 어떤 key와 value를 담을 것인지 선언할 수 있습니다. 파라미터 개수에 다라 자동으로 오버로딩되어 인스턴스가 생성되므로 이점을 유의하여 ProducerRecord를 생성합니다.

// key값 포함
ProducerRecord record = new ProducerRecord<String, String>("click_log", "1", "click");

producer.send()

send() 메서드의 파라미터로 ProducerRecord를 넣으면 전송이 이루어집니다. click_log Topic에 click value가 들어가게 됩니다.

producer.close()

Producer 종료

Kafka Consumer Application

Kafka에서 Consumer가 데이터를 가져가더라도 데이터가 사라지지 않습니다. 이와 같은 특징은 Kafka 그리고 Kafka Consumer를 데이터 파이프라인으로 운영하는데 매우 핵심적인 역할을 합니다.

Kafka Consumer는 기본적으로 Topic의 데이터를 가져옵니다. 데이터는 Topic 내부의 Partition에 저장됩니다. Consumer는 Partition에 저장된 데이터를 가져옵니다. 이렇게 데이터를 가져오는 것을 폴링(polling)이라고 합니다.

Consumer의 역할

Topic의 Partition으로 부터 데이터 Polling
Partition offset 위치 기록(commit)
Consumer group을 통해 병렬 처리

gradle 설정

compile group: 'org.apache.kafka', name: 'kafka-clients', version: '2.3.0'

Kafka Consumer를 작성한 코드

public class Consumer{
    public static void main(String[] args){
        Properties configs = new Properties();
        configs.put("bootstrap.servers", "localhost:9092");
        configs.put("group.id", "click_log_group");
        configs.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
        configs.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
        
        KafkaConsumer<String, String> consumer = new KafkaConsumer<String, String>(configs);
        
        consumer.subscribe(Arrays.asList("click_log"));
        
        while(true){
            ConsumerRecords<String, String> records = consumer.poll(500);
            for(ConsumerRecord<String, String> record : records){
                System.out.pritln(record.value());
            }
        }
    }
}

Properties configs

기본적인 Consumer 옵션을 지정할 수 있습니다. bootstrap servers 옵션을 통해 Kafka broker를 설정합니다.

그룹 아이디를 지정합니다. 그룹 아이디는 Consumer 그룹이라고도 불립니다.

KafkaConsumer<String, String> consumer

Kafka Consumer 클래스를 통해 이전에 선언한 설정들을 매개변수로해서 Consumer인스턴스를 생성합니다. 이 Consumer 인스턴스를 통해 데이터를 읽고 처리할 수 있습니다.

consumer.subscribe()

어느 Topic을 대상으로 데이터를 가져올지 선언합니다. 만약 특정 토픽의 전체 Partition이 아니라 일부 Partition의 데이터만 가져오고 싶다면 아래의 코드처럼 assign() 메서드를 사용하면 됩니다.

TopicPartition partition0 = new TopicPartition(topicName, 0);
TopicPartition partition1 = new TopicPartition(topicName, 1);
consumer.assign(Arrays.asList(partition0, partition1));

while(true)폴링 루프 구문

Kafka Consumer에서 폴링 루프는 poll()메서드가 포함된 무한루프를 말합니다. Consumer API의 핵심은 broker로부터 연속적으로 그리고 Consumer가 허락하는 한 많은 데이터를 읽는 것입니다. 이런 측면에서 폴링 루프는 Consumer API의 핵심 로직이라고 볼 수 있습니다. Consumer는 poll() 메서드를 통해 데이터를 가져오는데 poll()메서드에서 설정한 시간동안 데이터를 기다리게 됩니다.

[Kafka] Kafka란?

느린 거북이 — Fri, 1 Oct 2021 18:25:13 +0900

Kafka

위키백과에서 Kafak는 실시간 데이터 피드를 관리하기 위해 통일된, 높은 처리량, 낮은 지연시간을 지닌 플랫폼을 제공하는 것이 목표이며 분산 트랜잭션 로그로 구성된 상당히 확장 가능한 pub/sub 메시지 큐로 정의한다고 나와있습니다.

데이터 전송하는 Source 애플리케이션과 데이터를 받는 Target 애플리케이션이 있었습니다. Source & Target 애플리케이션들이 많아지면서 데이터를 전송하는 라인이 매우 복잡해졌습니다. 데이터 전송 라인이 많아지면 배포와 장애에 대응하기가 힘들어지니다. 그래서 Apache Kafka는 이러한 복잡함을 해결하기 위해 개발되었습니다.

Topic은 일종을 큐 라고 생각을 하시면 됩니다. Producer의 역할은 Topic에 데이터를 삽입을 하며 Consumer의 역할은 Topic에 데이터를 조회 하는 역할을 합니다. Kafka는 아주 유연한 큐 역할을 한다고 보시면 됩니다. 이런 데이터 흐름에 있어서 Kafka는 고가용성으로서 서버가 이슈가 생기거나 갑작스럽게 랙(전원이) 내려간다던가 하는 상황에서도 데이터를 손실없이 복구할 수 있습니다. 또한, Kafka는 낮은 지연과 높은 처리량을 통해서 아주 효과적으로 데이터를 아주 많이 처리할 수 있습니다.

1. Kafka Topic

Kafka에는 다양한 데이터가 들어갈 수 있는데 데이터가 들어가는 공간을 Topic이라고 합니다. Kafka에서는 Topic을 여러개 생성할 수 있습니다. Topic은 데이터베이스의 테이블이나 파일시스템의 폴더와 유사한 성질을 가지고 있습니다. 이 Topic에 Producer가 데이터를 넣게되고 Consumer는 데이터를 가져가게 됩니다. Topic은 이름을 가질수 있는데 목적에 따라 클릭로그, send sms, location log 등과 같이 무슨 데이터를 담는지 명확하기 명시하면 추후 유지보수 시 편리하게 관리 할 수 있습니다.

Partition이 하나인 경우

하나의 Topic은 여러개의 Partition으로 구성될 수 있으며 첫번째 Partition 번호는 0번부터 시작합니다. 하나의 Partition은 큐와같이 내부에 데이터가 Partition 끝에서부터 차곡차곡 쌓이게 됩니다. 클릭로그 Topic에 Kafka Consumer가 붙게되면 데이터를 가장 오래된 순서대로 가져가게 됩니다. 더이상 데이터가 들어오지 않으면 Consumer는 또 다른 데이터가 들어올때까지 기다립니다. Consumer가 Topic 내부의 Partition에서 데이터를 가져가더라도 데이터는 삭제되지 않고 Partition에 그대로 남게됩니다.

만약 Partition #0번의 남은 데이터를 재사용을 하기위해서는 새로운 Consumer가 붙었을때 다시 0번 부터 사용할 수 있습니다. 이를 위해서 몇가지 제약 조건이 있습니다. 첫번째로 Consumer그룹이 달라야하고 auto.offset.reset=earliest 이여야 합니다. 이처럼 사용할 경우 동일 데이터에 대해서 두번 처리할 수 있는데 이는 Kafka를 사용하는 아주 중요한 이유이기도 합니다.

Partition이 두개 이상인 경우

Partition이 2개 이상인 경우 새로운 데이터가 유입 되었을 때 어떤 Partition으로 보내는 경우는 Producer가 키를 지정 할 수 있습니다. 키가 null 즉, 키를 지정하지 않고 기본 파티셔너 사용한다면 round-robin으로 Partition이 지정됩니다. 반대로 키가 있고 기본 파티셔너를 사용할 경우에는 키의 해시값을 구하고 특정 Partition에 항상 할당되게 됩니다.

Partition을 늘리는 것에는 주의해야 할 점이 있습니다. Partition은 늘리는 것은 가능하지만 다시 줄일 수는 없기 때문입니다. Partition을 늘리는 이유는 Partition을 늘리면 Consumer의 개수를 늘려서 데이터 처리를 분산시킬 수 있습니다. 지속적으로 Partition의 데이터가 늘어나면 옵션에 따라 일정 기간 또는 용량 동안 데이터를 저장할 수 있게 되고 적절하게 데이터가 삭제될 수 있도록 설정할 수 있습니다.

log.retention.ms : 최대 record 보존 시간
log.retention.byte : 최대 record 보존 크기

2. Kafka broker, replication, ISR

2.1 Kafka broker

Kafka borker는 Kafka가 설치되어 있는 서버 단위를 말합니다. 보통 3개 이상의 borker로 구성하여 사용하는 것을 권장합니다. 만약 Partition이 1개이고 replication이 1인 topic이 존재하고 borker가 3대라면 borker 3대중 1대에 해당 topic의 정보(데이터)가 저장됩니다.

2.2 Kafka replication

replication은 Partition의 복제를 뜻합니다. 만약 replication이 1이라면 Partition은 1개만 존재한다는 것이고 replication이 2라면 Partition은 원본 1개와 복제본 1개로 총 2개가 존재합니다. replication이 3이라면 Partition은 원본 1개와 복제본 2개로 총 3개가 존재하게 됩니다. 다만 borker 개수에 따라서 replication개수가 제한됩니다. borker개수가 3이면 replication은 4가 될수 없습니다. 원본 1개 Partition은 Leader Partition이라고 부릅니다. 그리고 나머지 복제본 Partition은 Follower Partition이라고 부릅니다.

replication을 사용하는 이유

replication은 Partition의 고가용성을 위해 사용됩니다. 만약 borker가 3개인 Kafka에서 replication이 1이고 Partition이 1인 Topic이 존재한다고 가정한다면 borker가 어떠한 이유로 사용불가하게 된다면 더이상 해당 Partition은 복구할 수 없습니다. 만약 replication이 2라면 borker 1개가 죽더라도 Follower Partition이 존재하므로 복제본은 복구가 가능합니다. 나머지 1개가 남은 Follower Partition이 Leader Partition역할을 승계하게 되는 것입니다.

* ack

Producer가 Topic의 Partition에 데이터를 전달할때 전달받는 주체가 Leader Partition입니다. Producer에는 ack라는 상세 옵션이 있습니다. ack를 통해 고가용성을 유지할 수 있는데 이 옵션은 Partition의 replication과 관련이 있습니다. ack는 0, 1, all 옵션 3개중 1개를 골라서 설정할 수 있습니다.

ack Option 0
- Producer는 Leader Partition에 데이터를 전송하고 응답값을 받지않습니다. 그렇기에 Leader Partition에 데이터가 정상적으로 전송됏는지 그리고 나머지 Partition에 정상적으로 복제되엇는지 알 수 없고 보잘할 수 없기에 속도는 빠르지만 데이터 유실 가능성이 있습니다.
ack Option 1
- Leader Partition에 데이터를 전송하고 Leader Partition이 데이터를 정상적으로 받앗는지 응답값을 받습니다. 다만 나머지 Partition에 복제되엇는지는 알 수 없습니다. 만약 Leader Partition이 데이터를 받는 즉시 broker가 장애가 발생한다면 나머지 Partition에 데이터가 전송되지 못한 상태이므로 데이터의 유실 가능성이 있습니다.
ack Option all
- 1옵션에 추가로 Follower Partition에 복제가 잘 이루어졌는지 응답값을 받습니다. Leader Partition에 데이터를 보낸 후 나머지 Follower Partition에도 데이터가 저장되는 것을 확인하는 절차를 거칩니다. 때문에 속도가 현저히 느리다는 단점이 있습니다.

replication개수가 많아지면 그만큼 broker의 리소스 사용량도 늘어나게 됩니다. 따라서 Kafka에 들어오는 데이터량과 retention data 즉, 저장시간을 잘 생각하여 replication 개수를 정하는 것이 좋습니다. 3개 이상의 브로커를 사용할때

replication은 3으로 설정하는 것을 권장합니다.

2.3 Kafka ISR

위의 2.2에서 설명한 Leader, Follower Partition을 합쳐서 ISR 즉, In Sync Replica라고 볼 수 있습니다.

3. Kafka Partitioner

Partitioner는 Kafka Producer의 중요한 개념 중 하나입니다. Producer가 데이터를 보내면 무조건 Partitioner를 통해서 broker로 데이터가 전송됩니다. Partitioner는 데이터를 Topic에 어떤 Partitioner에 넣을지 결정하는 역할을 합니다.

레코드에 포함된 메시지 키 또는 메시지 값에 따라서 Partitioner의 위치가 결정되게 됩니다. Producer를 사용하실 때 Partitioner를 따로 설정하지 않으면 UniformStickyPartitioner로 설정이 됩니다. 이 Partitioner는 메시지 키가 있을 때와 없을 때 다르게 동작하게 됩니다.

메시지 키가 있는 경우

메시지 키를 가진 레코드는 Partitioner에 의해서 특정한 해쉬값이 생성됩니다. 이 해쉬값을 기준으로 어느 Partitioner으로 들어갈지 정해지게 됩니다. 동일한 메시지 키를 가진 레코드는 동일한 해쉬값을 만들기 때문에 항상 동일한 Partition에 들어가는 것을 보장합니다. 예를 들어 서울의 온도를 기록하는 레코드를 Partition에 집어넣는다고 가정해볼 수 있습니다. 메세지 키에 "서울"이라는 String 값을 넣고 레코드를 지속적으로 보낸다면 항상 동일한 Partition에 데이터가 순서대로 들어가기 때문에 Consumer는 서울이라는 레코드를 순서를 지켜서 데이터를 처리할 수 있게 되는 것입니다. Partition 한개 내부에서는 큐처럼 동작하기 때문에 순서를 지킬 수 있는것입니다.

메시지 키가 없는 경우

메시지 키가 없는 레코드는 라운드 로빈으로 Partition에 들어가게 됩니다. UniformStickyPartitioner는 Producer에서 배치로 모을 수 있는 최대한의 레코드들을 모아서 Partition으로 데이터를 보내게 됩니다. 이렇게 배치단위로 데이터를 보낼 때 Partition에 round-robin 방식으로 들어가면서 데이터를 넣게 됩니다. 쉽게 말해서 메시지 키가 없는 레코드들은 Partition에 적절히 분배된다고 생각하시면 될 것 같습니다.

4. Kafka Consumer Lag

Kafka lag은 Kafka를 운영함에 있어서 중요한 모니터링 지표 중 하나입니다.

Kafka Producer는 Topic의 Partition에 데이터를 차곡차곡 넣게됩니다. 이 Partition에 데이터가 하나 하나씩 들어가게되면 각 데이터는 오프셋이라고하는 숫자가 붙게됩니다. 만약 Partition이 1개가 존재한다면 Partition이 1개인 Topic에 Producer가 데이터를 넣을 경우 0부터 차례대로 숫자가 매겨지게 됩니다. Producer는 계속해서 데이터를 넣게되고 Consumer는 계속해서 데이터를 가져가게 됩니다. 만약 Producer가 데이터를 넣어주는 속도가 Consumer가 가져가는 속도보다 빠르게 되면 Producer가 넣은 데이터의 오프셋, Consumer가 가져간 데이터의 오프셋 이 두개의 오프셋 간에 차이가 발생합니다. 이게 바로 Consumer Lag입니다. Lag은 적을수도 있고 많을 수도 있습니다. 이 Lag의 숫자를 통해 현재 해당 Topic에 대해 파이프라인으로 연계되어 있는 Producer와 Consumer의 상태에 대해 유추가 가능합니다. Consumer Lag은 주로 Consumer의 상태에 대해 볼때 사용합니다.

Lag은 각 Partition의 오프셋기준으로 Producer가 넣은 데이터의 오프셋과 Consumer가 가져가는 데이터의 오프셋의 차이를 기반으로 합니다. 그렇기 때문에 Topic에 여러 Partition이 존재할 경우 Lag은 여러개가 존재할 수 잇습니다. 만약 Consumer 그룹이 1개이고 Partition이 2개인 Topic에서 데이터를 가져간다면 Lag은 2개가 측정될 수 있습니다. 이렇게 한개의 Topic과 Consumer 그룹에 대해 Lag이 여러개 존재할 수 있을때 그 중 높은 숫자의 Lag를 records-lag-max라고 부릅니다.