[MSA] 20. Custom System 구축, Kafka

엔코아 플레이데이터(Encore Playdata) Backend 2기 백엔드 개발 부트캠프 (playdata.io)

백엔드 개발 부트캠프

---

1. Custom System

나만의 서비스를 구축해보기 위해, 선생님께서 주신 encore 디렉토리를 기반으로 작업을 진행할 예정이다.

encore 디렉토리 구성

1. github 등록
2. jenkins 도입
3. k8s 서비스 
- aws ECR
- minikube 
- aws EKS 
4. CI/CD

 

현재 디렉토리 구성에 위에 작성한 기능들을 추가하여 서비스를 배포해볼 예정이다.

---

2. Github Push

# 내 컴퓨터에서 key 파일 만들기 
ssh-keygen -t ed25519 -C "이메일주소"

key 생성

생성 된 키 확인

# 생성 된 파일 확인
cat id_ed25519.pub

# github key 등록 위치
https://github.com/settings/keys

# SSH-Key 생성
id_ed25519.pub 의 내용을 넣어 SSH-Key를 생성한다.

generate ssh-key

# private repository 에 push

1. private repository 생성
이 때 gitignore 생성 안하고 일단 만들어야 pull을 안해도 된다.

2. git init 

3. git remote add origin "my repository address"

4. git remote -v 
원격 레포지토리 연결됐는지 확인

5. git branch -m master main
branch 명 master -> main 변경

6. git branch -m main 
main 사용

7. git add .

8. git commit -m "my message"

9. git push --set-upstream origin main
처음에만 --set-upstream을 이용해 push하고, 이후부터는 그냥 git push 만 해도 적용된다.

git push 완료

---

3. Kafka 

여러 대의 분산 서버에서 대량의 데이터를 처리하는 분산 메세징 시스템으로, 데이터 (메세지) 를 받고, 받은 메세지를 다른 시스템이나 장치에 보내기 위해 사용한다.

즉, 카프카는 여러 시스템과 장치를 연결하는 중요한 역할을 한다.

 

카프카는 대량의 데이터를 높은 처리량과 실시간으로 취급하기 위해 다음과 같은 특징을 가지고 있다.

1. 확장성
여러 서버로 확장 (scale out) 구성할 수 있기 때문에 데이터 양에 따라 시스템 확장이 가능하다.

2. 영속성
수신한 데이터를 디스크에 유지할 수 있기 때문에 언제라도 데이터를 읽을 수 있다

3. 유연성
연계할수 있는 제품이 많기 때문에 제품이나 시스템을 연결하는 허브 역할을 한다.
이를 미들웨어 프로그램이라고 한다.

4. 신뢰성
메세지 전달을 보증하므로 데이터 분실을 걱정하지 않아도 된다.

 

1. 탄생 배경

카프카는 2011년 미국 LinkedIn에서 출발한 서비스로, 링크드인 웹사이트에서 생성되는 로그를 처리하여 웹 사이트 활동을 추적하는 것을 목적으로 개발 되었다.

# 링크드 인이 실현하려는 목표

1. 높은 처리량으로 실시간 처리
전 세계 사용자의 방대한 엑세스 데이터를 처리해야하기 때문에 처리량이 우수해야 했고,
사용자의 활동을 신속하게 파악하거나 사용자의 활동에 따라 즉시 피드백하기 위해서는 
사용자의 활동단위로 실시간 처리를 해야했다.

2. 임의의 타이밍에서 데이터를 읽음
실시간 처리에 대한 요구가 있는 반면, 링크드 인은 기존 시스템에서 수집한 엑세스 로그를 일정 시간마다
배치 처리로 취급하고 싶다는 요구사항도 있었다.

또한, 데이터를 사용하는 타이밍이 반드시 실시간이 아니라 이용 목적에 따라 다를 가능성이 있기 때문에
방대한 데이터를 전달할 때 버퍼 역할도 가능하기를 원했다.

3. 다양한 제품과 시스템에 쉽게 연동
링크드 인에서 데이터 발생원이 되는 데이터 소스와 관련된 시스템이 하나가 아니기 때문에 여러 시스템을 통해
들어오는 데이터를 쉽게 저장, 이용할 수 있어야 했다.

4. 메세지를 잃지 않음
메세지가 방대하더라도 메세지를 손실하지 않아야 했다.
즉, 중복이 있더라도 손실이 발생하면 안됐다.

 

2. 기존 시스템

# 로그 수집 시스템

실시간으로 데이터를 수집한다는 관점에서 생각할 수 있는 로그 수집을 위한 미들웨어로,
페이스북이 개발한 Scribe 와 클라우데라가 개발한 Flume 이 대표적이다.

각 프론트엔드 서버가 로그를 중계용 서버로 전송하고, 거기서 로그를 수집하여 데이터베이스와 
분산 파일시스템 HDFS(Hadoop Distributed File System) 에 축적된다.

대량의 로그를 처리하는 것을 가정하고 있기 때문에 분산 환경의 다중 서버 구성으로 이루어져 있고,
이들 제품은 대량의 로그를 HDFS에 축적하고 일괄 처리하는 것이 주 목적이기 때문에 
하둡에서 동작하도록 프로그램을 다시 작성해야한다.

즉, 다양한 제품과의 연계를 실현하기 위해서 이용하기 쉬운 송수신 API 가 없기 때문에
수신하는 쪽이 임의로 메세지를 수신하기 어렵다.

# ETL 도구

데이터의 소스에서 데이터를 추출하여 필요에 따라 변환해서 데이터베이스에 적재하는 도구로,
DataStage, Interstage, Cosminexux, Infromatica PowerCenter, Talend 등이 있다.
이들 제품은 데이터를 파일 단위로 다뤄, 수신하는 쪽이 임의로 메세지를 수신하기가 어려웠다.

 

이렇게 기존 제품들은 데이터를 주고 받을 때 각각의 플랫폼이 서로 사용하는 언어가 다르기 때문에,

수신자가 송신자가 보낸 데이터를 자신의 플랫폼에 맞는 형식으로 변환해 사용해야했다.

때문에 유지보수가 힘들어지고, 확장성이 떨어지는 단점이 존재했다.

 

3. 대체 모델

# 메세징 모델

메세징 모델은 다음 세가지 요소로 구성 된다.
Producer : 메세지 생산자
Broker : 메시지 수집 / 전달 역할
Consumer : 메세지 소비자

# 큐잉 모델

브로커 안에 큐를 준비해, 프로듀서의 메세지가 큐에 담기고, 컨슈머가 큐에서 메세지를 추출한다.
하나의 큐에 컨슈머가 여러명 존재할 수 있으며,
컨슈머를 여러 개 준비함으로서 컨슈머에 의한 처리를 확장시킬 수 있고,
컨슈머가 메세지를 받으면 다른 컨슈머는 메세지를 받을 수 없었다.

# 펍 / 섭 메세징 모델

메세지 생산자인 프로듀서를 Publisher, 소비자인 컨슈머를 Subscriber 라고 한다.
퍼블리셔는 누가 그 메세지를 수신하는 지 알 수 없고, 브로커에 있는 topic이라 불리는 카테고리 안에
메세지를 등록하기만 한다.

이때, subscriber는 여러 개 존재하는 토픽 중 하나를 선택하여 메세지를 받고,
여러 subscriber가 동일한 토픽을 구독하기로 한다면 모든 subscriber는 동일한 메세지를 받는다.
또한, 다른 토픽에서 다른 메세지를 받을 수도 있다.

 

4. 카프카의 주요 특징

1. 높은 처리량과 낮은 지연시간
카프카는 매우 높은 처리량과 낮은 지연시간 (latency) 를 가진다.

2. 높은 확장성
손쉬운 확장 (scale out) 이 가능하다.

3. 고가용성
고가용성 (high avaliability) 는 서비스가 죽지않고 계속 유지되는 것을 의미한다.
고가용성을 갖추면서 지연 없는 빠른 메세지 처리 기능을 유지하는 것이 어렵지만,
카프카는 이를 신경써 개발하였다.

4. 내구성
프로듀서는 카프카로 메세지를 전송할 때, 
프로듀서는 acks라는 옵션을 조정하여 메세지의 내구성을 강화할 수 있다.

5. 개발 편의성
카프카는 메세지를 전송하는 역할을 producer, 메세지를 가져오는 역할을 하는 consumer가 
완벽하게 분리되어 동작하고 서로 영향을 주고 받지 않는다.
이러한 구성에 따라 프로듀싱을 원하는 개발자는 프로듀서만 개발하면 되고 컨슈밍을 원하는 개발자는
컨슈머만 개발해 사용하면 된다.

6. 운영 및 관리 편의성
카프카는 중앙 메인 데이터 파이프라인 역할을 하게 되는데, 운영이나 관리의 편의성이 떨어진다면
그와 같은 주요 역할을 맡기기에 부담되기 때문에, 성능 확장을 위한 증설 작업이 쉽고 간단하며,
최신 버전이 릴리스 되는 경우 무중단으로 버전 업그레이드도 가능하다.

---

4. Kafka의 주요 구성 요소

1. 브로커
브로커는 하나의 서버 당 하나의 데몬 프로세스로 동작하여 메세지 수신/ 전달 요청을 받아들인다.
이것을 여러 대의 클러스터로 구성할 수 있으며 브로커를 추가함으로써 수신 / 전달의 처리량 향상 (scale out) 이 가능하다.
브로커에서 받은 데이터는 모두 디스크로 내보내기가 이루어져, 디스크의 총 용량에 따라 장기간 데이터를 보존할 수 있다.

2. 메세지
카프카에서 다루는 데이터의 최소 단위, 카프카가 중계하는 로그의 한줄과 센서 데이터 등이 이에 해당한다.
메세지는 key, value 를 갖게 되어 메세지 전송에 파티셔닝을 이용한다.

3. 프로듀서
프로듀서 / 컨슈머를 구현하는 기능은 브로커로 데이터를 보내고 브로커에서 데이터를 받기 위한 라이브러리로 제공된다.
프로듀서는 프로듀스 API 를 이용하여 브로커에 데이터를 송신하기 위해 구현 된 어플리케이션이다.
실제 사례로는 각종 로그 전송 및 미들웨어와 연동하여 동작하기 때문에 프로듀서 API를 내포한 도구, 미들웨어를 통해 이용하는 형태 등 다양하다.

* 사용할 수 있는 서드 파티 플러그인
- Apache Log4j
- Apache Flume
- Fluentd
- Logstash

4. 컨슈머
컨슈머 API를 이용해 브로커에서 메세지를 취득하도록 구현 된 어플리케이션으로, 브로커는 메세지를 영속화하기 위해, 브로커에 도달하는 즉시 컨슈머에서 취득해야하는 제약이 없다.

즉, 디스크에 보관되어 있는 동안은 메세지 취득이 가능하다.
또한, 일정 기간 데이터를 축적한 스토리지에서의 데이터 추출 및 실시간 처리를 위한 어플리케이션의 데이터 입력 등으로 이용 가능하다.

* 카프카 연계를 위한 컨슈머 기능을 갖춘 기존 제품들 리스트
- Apache Spack
- Apache Samza
- Apache Flink
- Apache Flume
- Fluentd
- Logstash

 

 

5. 주키퍼
카프카의 브로커에 있어 분산 처리를 위한 관리 도구로 Apache Zookeeper가 필요하다.
주키퍼는 하둡 등 병렬 분산 처리용 프로그램으로, 설정 관리, 이름 관리, 동기화를 위한 잠금 관리를 위한 구조로 자주 사용한다.

카프카에 있어서 주키퍼는 분산 메세징의 메타 데이터를 관리하기 위한 구성요소로 기능한다.
또한, 주키퍼 클러스터의 구조상 3, 5 처럼 홀수로 구성하는 것이 일반적이다.

6. 카프카 클라이언트
토픽 작성 등 카프카의 동작 및 운영 상에 필요한 조작을 실행하는 서버로, 메세지의 송수신을 처리하는 서버는 아니다.

7. 카프카 클러스터
카프카는 여러 대의 브로커 서버, 주키퍼 서버로 이루어진 클러스터링의 메세지 중계 기능과 메세지 송수신을 위한 라이브러리 그룹으로 구성되어 있다.
즉, 주키퍼에 의해 구성 된 클러스터 시스템을 카프카 클러스터라고 정의한다.

---

5. 67일차 후기

앞으로 수업중에 만들 예정인 서비스를 구축하기 위한 기반 디렉토리를 받아, Git의 Private Repository에 올리는 작업을 진행했다.

 

대용량 데이터를 처리하기위해 각 마이크로서비스 끼리 End-To-End 방식 아키텍쳐로 서비스를 구축하면, 유지보수도 어렵고 확장성도 떨어진다.

이를 카프카를 활용하면 해결할 수 있지만, 카프카를 구성하기 위한 추천 여건은 최소 3대의 주키퍼 서버, 최소 3대의 카프카 서버를 권장한다. 때문에 카프카를 사용할 여건을 가진 서비스를 잘 구축하는 것이 중요하다 생각이 들었다.