2장 카프카 환경 구성

2-1. 책의 실습 환경 구성

책에서는 aws 내에서 실습환경을 구성하였으나,

GCP의 무료크레딧을 사용하여 환경을 구성하기로 했다...(금전 이슈ㅠ)

1) 인스턴스 생성

GCP의 인스턴스 그룹을 사용해서 7개의 인스턴스를 통합적으로 생성, 관리하기로 했다.

(아 테라폼 안쓴다 오예)

내가 만든 인스턴스들

2) hosts 파일 수정하기 & ansible을 위한 ssh 키 복사

DNS를 사용하기에는 실습환경에서는 굳이라는 생각이 들어 사용하지 않았다.

차라리 그돈으로 일주일 더 학습하는 것이..

그래서 hosts파일을 수정해서 사용하기로 했다.

ansible용으로 하나, 주키퍼 3대, 카프카 3대로 구성했다.

sudo nano /etc/hosts
<내부ip> peter-ansible01.foo.bar
<내부ip> peter-zk01.foo.bar
<내부ip> peter-zk02.foo.bar
<내부ip> peter-zk03.foo.bar
<내부ip> peter-kafka01.foo.bar
<내부ip> peter-kafka02.foo.bar
<내부ip> peter-kafka03.foo.bar

 

자 이제 ansible으로 카프카를 설치할 것이므로 ssh로 각 인스턴스들을 연결할 수 있도록 해야 한다.

ssh키를 scp 명령을 이용해 ansible 인스턴스에 전송한다.

scp -i keypair.pem keypair.pem key@<ansible01-ip>

 

키를 보냈다면 사용을 위해서 키의 권한을 조정하고

등록하는 과정이 필요하다. 

# 키 권한 조정
chmod 600 keypair.pem
# 키 등록
ssh-agent bash
ssh-add keypair.pem

 

마지막으로 모든 작업이 끝나면 git을 이용해서 예제 파일을 다운로드 한다.

(실습 환경설정 완료?)

git clone https://github.com/onlybooks/kafka2

 

 

2-2. 카프카 클러스터 구성

1) common role 편집 (yum → apt)

책에서는 amazon-linux 또는 centOS를 추천하나 GCE에서 해당 환경이 이용 불가하므로 Ubuntu에서 진행....

이에 yum 코드를 apt를 사용하는 코드로 변경해 주는 작업이 필요했다.

 

따라서 roles/common/tasks/main.yml 파일을 수정할 필요가 있다.

# 변경 코드
---
- name: Set timezone to Asia/Seoul
  timezone:
    name: Asia/Seoul

- name: Install Java and tools
  apt:
    name:
      - dstat
      - openjdk-8-jdk
      - openjdk-8-jdk-headless
      - krb5-user
      - git
    state: latest
    update_cache: yes

- name: Copy krb5.conf
  template:
    src: krb5.conf.j2
    dest: /etc/krb5.conf
    owner: root
    group: root
    mode: '0644'
    backup: no

코드를 변경하고 정상적으로 설치가 진행되었다!

 

2) 주키퍼 & 카프카 설치

책의 설명대로 주키퍼와 카프카를 설치한다.

실습 파일을 뜯어보면 간단한 코드니까

저자를 위해서 해당 코드는 공개하지 않는다!

 

주키퍼 설치완료!
카프카 설치 완료!

2-3. 카프카 맛보기

2장의 마지막에는 카프카 토픽을 생성하고

컨슈머와 프로듀서를 실행해 간단한 실습을 수행하는 부분이 나와있다.

정말 간단하니까 실습을 해보는 것을 추천하고

마지막은 내가 실습했던 사진을 첨부한다.

 

마지막으로 내가 참고했던 글들을 가져왔다.

 

실시간 처리에 대해서 관심이 있었던지라 카프카 스터디에 참여해 실시간 데이터 수집에 대해 공부하기 시작했다.

작성할 내용들은 카프카 스터디를 통해서 알게 된 내용들을 적고 실습한 내용을 같이 채우고자 한다.

1장 카프카 개요

카프카의 도입 사례, 주요 특징, 성장에 대해서 가볍게 짚고 넘어간다.

조금씩 뜯어보면서 어떤 부분이 중요한지 살펴보자

 

1-1. 카프카 도입 사례 및 이용 현황

책에서는 잘란도라는 기업(처음 들어봤다..)과 트위터의 도입 사례를 설명한다.

잘란도는 독일의 무신사(?) 같은 느낌의 기업이라고 한다. 궁금해서 웹 페이지를 들어가 봤는데..

그린 고블린 형님께서..!

(여튼 트위터는 X로 바뀌고.. 다들 많이 아니까 패스!)

 

잘란도의 도입배경은 이러하다.

 

'데이터 변화가 스트림으로 컨슈머에 전달되는 이벤트 드리븐 시스템으로의 전환'

 

이를 목적으로 여러 시도들을 진행했는데..!

바운드 아웃바운드 데이터의 일치성 검증, 통신 방법에 대한 선택과 같은 다각적 고민 
->

동기화 방식의 CRUD를 채택했으나, 한계점에 봉착했다. 이유는 다양한 클라이언트들의 요구사항을 효율적으로 지원하기 어렵다는 것.

빠른 전송을 위한 클라이언트 또는 대량의 배치 전송을 위한 클라이언트를 지원하기 어려움

 

위와 같은 문제들에 봉착하고 말았다. 그래서 꺼내든 것은 바로 카프카! 

그 이유들은 카프카의 주요 특징들에 담겨있으니 아래에서 한 번에 설명하고자 한다.

1-2. 카프카 주요 특징

높은 처리량과 낮은 지연시간

카프카는 매우 높은 처리량과 낮은 지연시간을 자랑한다고 한다.

 

다른 MQ들과 비교했는데..

래빗 MQ의 경우 응답속도가 가장 빠르나, 처리량이 늘어나면 카프카가 독보적이라고 한다.

펄사의 경우는 서버 간의 메시징을 위한 멀티테넌트 고성능 솔루션이라고..(?)

(GPT:티 테넌트(Multi-tenant)는 소프트웨어 아키텍처 모델로,
여러 고객(테넌트)이 단일 소프트웨어 인스턴스를 공유하는 방식을 말합니다. )

 

추가로 관련 자료를 가져왔다.

카프카, 펄사, 래빗 MQ 비교: https://www.confluent.io/blog/kafka-fastest-messaging-system/

 

Benchmarking RabbitMQ vs Kafka vs Pulsar Performance

A complete benchmark of RabbitMQ, Kafka, and Pulsar to determine performance, throughput, and latency at scale. View the comparison results!

www.confluent.io

Apache Pulsar 소개: https://devocean.sk.com/blog/techBoardDetail.do?ID=164597&boardType=techBlog

 

Open Source 기반 Messaging Platform - Apache Pulsar 소개

 

devocean.sk.com

 

높은 확장성

카프카는 손쉬운 확장이 가능하도록 설계되었다고 한다.

프로듀서와 컨슈머를 생성해서 넣으면 되니까..?라고 생각한다.

여튼 링크드인에서는 확장이 필요서 해당 부분을 고려해 설계했다고 한다.

 

고가용성

클러스터 내 리플리케이션 기능을 통해서 고가용성을 확보했다.

 

내구성

acks옵션을 이용해서 메시지 내구성을 강화했다.

 

개발편의성, 운영 및 관리의 편의성

프로듀서와 컨슈머가 완벽하게 분리되어 동작해 원하는 부분만 개발해 사용가능하다.

또한 개발 편의성을 위해 카프카 커넥트와 스키마 레지스트리를 지원한다.

 

 

자..

마지막으로 카프카는 Apache Kafka와 Confluent 카프카가 있는데 이를 비교한 글이 컨플루언트에 있어서 가져와보았다.

https://www.confluent.io/ko-kr/apache-kafka-vs-confluent/

 

Apache Kafka vs. Confluent: 특징 및 기능 비교 | KR

Kafka and Confluent have numerous differences. Here's a side-by-side comparison of Confluent vs Kafka: features, connectors, clients, performance, scalability, and more.

www.confluent.io

 


책을 읽으면서 제로카피, 이벤트 버스 패턴, 람다 아키텍처와 같이 기존에 알지 못했던 지식들이 나와
CS공부를 함에 있어서도 많은 도움이 되리라 생각한다.

 

이번 기회로 카프카를 공부해 보고 실제 환경에서 데이터를 가져오는 방법으로 카프카를 고려할 수 있는 역량을 길러보고자 한다.

'Data Engineering > kafka' 카테고리의 다른 글

kafka > 실전 카프카 개발부터 운영까지 2장  (3) 2024.10.15

3장. 우수한 데이터 아키텍처 설계

데이터 아키텍처에 대한 소개, 우수한 데이터 아키텍처는 무엇인가? 그리고 그 예시까지. 3장에 대한 정리글을 시작한다.

 

1. 데이터 아키텍처에 대한 정의

책에서는 데이터 아키텍처를 엔터프라이즈 아키텍처의 하위 집합으로 소개한다. 엔터프라이즈 아키텍처란 무엇일까?

엔터프라이즈 아키텍처는 기업의 변화를 지원하는 시스템 설계로,
신중한 트레이드오프 평가를 통해 도달한 유연하고 되돌릴 수 있는 의사결정으로 달성된다.

 

쉽게 유연성과 트레이드오프의 균형을 유지하는 것이라고 줄일 수 있다.

 

그렇다면 이제 데이터 아키텍처에 대해 알아보자.

데이터 아키텍처는 기업의 진화하는 데이터 요구 사항을 지원하는 시스템 설계로,
트레이드오프에 대한 신중한 평가를 통해 유연하고 되돌릴 수 있는 결정을 내림으로써 실현된다.

 

데이터 아키텍처의 특징으로 운영과 기술적인 부분을 추가로 소개한다.

  • (What) 운영 아키텍처: 인력, 프로세스 및 기술과 관련한 필요 기능의 요건을 포괄
    > 데이터는 어떤 비즈니스 프로세스를 지원하는가?, 조직은 어떻게 데이터 품질을 관리하는가?
  • (How) 기술 아키텍처: 데이터 엔지니어링 수명 주기를 통해 데이터를 수집, 저장, 변환 및 제공하는 방법
    > 시간당 10TB의 데이터를 원천DB에서 데이터 레이크로 옮기려면 어떻게 해야 할까?

2. 우수한 데이터 아키텍처

최고의 아키텍처를 추구하기보다는 덜 나쁜 아키텍처를 추구하라
- 마크 리처즈, 닐 포드

 

우수한 아키텍처란 무엇인가.?

유연성을 유지하고, 적절한 트레이드오프를 실현하는 동시에,
광범위하게 재사용 가능한 공통 구성 요소를 사용해 비즈니스 요건을 충족하는 아키텍처

 

조금 줄여본다면 유연하고 민첩한 아키텍처가 될 것 같다.

저자는 아키텍처는 비즈니스 내부의 변화와 더 많은 가치를 창출할 수 있는 기술, 관행에 맞추어 진화해야 한다고 한다.

 

데이터 아키텍처는 살아 숨 쉬며 결코 완성되지 않는다.

 

그럼 이제 우수한 아키텍처의 '원칙'에 대해서 알아본다.

 

[우수한 아키텍처의 원칙]

1. 공통 컴포넌트를 현명하게 선택하기

: 조직 전체에서 사용가능한 공통 컴포넌트의 선택이다. 팀 간의 자산의 공유가 쉽게 이루어지면서도 잘못된 접근을 막는 것이 필요하다. 클라우드 플랫폼으로 이를 쉽게 수행가능하다.

 

2. 장애에 대비
: 장애에 대비해 설계 시 허용가능한 신뢰성, 가용성, RTO(복구시간목표) 및 RPO(복구시점목표)를 고려해야 한다.

- RTO: 서비스 또는 시스템 장애의 최대 허용시간

- RPO: 허용 가능한 최대 데이터 손실

 

3. 확장성을 위한 아키텍처 설계

: 스케일 업과 스케일 다운이 가능해야 한다. 탄력적 시스템을 활용해 이를 동적으로 확장할 수 있다.

 

4. 아키텍처 리더십

: 효과적인 리더십과 교육을 통해 기술의 결정과 아키텍처의 설명을 담당, 전파할 책임이 있다.

 

5. 항상 아키텍처에 충실하기

: 단순히 기존 상태를 유지하는 역할만 수행하는 것이 아니라, 비즈니스와 기술의 변화에 대응해 새롭고 흥미로운 것들을 끊임없이 설계해야 한다.

 

6. 느슨하게 결합된 시스템 구축

: 다른 팀에 의존하지 않고 작업이 수행가능해야 한다. 각 팀은 독립적으로 자신의 컴포넌트를 빠르게 발전시키고 개선 가능하다.

 

7. 되돌릴 수 있는 의사결정 수행

: 현재 상황에 적합한 최고의 설루션을 위해 변화가 가능한 의사결정을 내려야 한다.

 

8. 보안 우선순위의 지정

: 자신이 구축하고 유지 관리하는 시스템의 보안을 책임져야 한다. (제로-트러스트 보안, 공동 책임 모델)

- 제로-트러스트 보안: 이미 조직의 네트워크 내부에 있는 사람이나 기기를 기본적으로 신뢰해서는 안 된다는 생각을 바탕으로 조직을 보호하는 데 사용되는 보안 모델

- 공동 책임 모델: AWS가 대표적, 클라우드 보안과 클라우드 내 보안으로 나눈다. 클라우드 서비스에서 실행되는 인프라와 안전하게 사용하는 서비스를 AWS에서는 제공하나, 클라우드 내 보안은 사용자가 관리해야 한다.

 

9. 핀옵스의 수용

: 핀옵스는 데브옵스와 재무팀 간의 협력적인 업무 관계를 지원하는 움직임이라 말한다.

 


책의 내용을 꼼꼼하게 읽으면서 포스팅하다 보니 읽으면서도 조금 지치는 기분이고 포스팅도 매우 느려지고 있다.

작은 단위로 나누어서 포스팅하면서 주기를 줄이는 방식으로 진행해야 할 것 같다.

다음 포스팅에서는 주요 아키텍처 개념을 소개한다.

'Data Engineering' 카테고리의 다른 글

DE > 견고한 데이터 엔지니어링 - 4  (0) 2024.06.13
DE > Spark란?  (0) 2024.06.12
빅데이터 처리 시스템  (2) 2024.06.12
DE > 데이터 정합성  (0) 2024.06.12
DE > 견고한 데이터 엔지니어링 - 3  (0) 2024.06.11

2장. 데이터 엔지니어링 수명 주기

데이터 옵스

데이터옵스는 무엇일까? 책에서 인용한 데이터옵스에 대한 글을 가져왔다.

https://datakitchen.io/what-is-dataops/

 

What is DataOps? | DataKitchen

DataOps enables rapid innovation, high data quality and low error rates, strong collaboration, and clear measurement of results.

datakitchen.io

번역을 좀 한다면...

데이터옵스는 다음 사항들을 실현하는 기술 관행, 워크플로, 문화적 규범, 아키텍처 패턴의 집합이다.

  • 신속한 혁신과 실험으로 고객에게 새로운 통찰력을 빠르게 제공
  • 매우 높은 데이터 품질과 매우 낮은 오류율
  • 인력, 기술, 환경의 복잡한 집합 전반에 걸친 협업
  • 명확한 측정, 모니터링 및 결과의 투명성

이렇게 설명하고 있다.

책에서는 한가지를 더 강조하는데 데이터옵스가 문화적 습관이라고 말하고있다.

데이터 엔지니어링 팀은 비즈니스와 소통항고 협업해야하며, 지속적인 학습과 신속한 반복주기를 채택해야한다. 이러한 문화적 습관이 정착되어야 기술과 도구에서 최상의 결과를 얻을 수 있다고 한다.

 

데이터 옵스의 세 가지 핵심 기술 요소

자동화, 모니터링 및 관찰 가능성, 사고 대응이라는 세 가지는 데이터옵스의 핵심 기술 요소이다. 이를 조직의 성숙도에 맞추어서 책에서는 설명한다.

 

[자동화]

자동화를 사용하면 데이터옵스 프로세스의 신뢰성과 일관성의 보장이 가능하며, 데이터 엔지니어가 새로운 제품 기능과 개선 사항을 기존 워크플로에 신속하게 구현 가능하다고 한다. 데브옵스와 유사한 프레임워크와 워크플로를 가지며, 기술과 시스템의 신뢰성을 모니터링하고 유지한다고 한다.

데이터 엔지니어가 워크로드를 줄이고 비즈니스에 제공하는 가치를 높일 수 있는 자동화를 지속해서 구현하는 것이 핵심이다.

 

[관찰 가능성과 모니터링]

몇 달 또는 몇 년씩 보고서에 남아있는 잘못된 데이터를 기반으로하는 의사결정은 쉽게 발견하기 어렵다. 따라서 데이터와 데이터 생성 시스템을 재대로 관찰하고 감시하지 않으면 자신만의 데이터 공포 상황에 직면할 수 있다.

따라서 DODD 방법론에서는 데이터 엔지니어의 수명 주기에서 데이터 관찰 가능성을 최우선 고려 사항으로 삼는 데 중점을 둔다.

 

[사고 대응]

사고 대응이란 자동화와 관찰 가능성 기능을 사용해 사고의 근본 원인을 신속하게 특정하고 가능한 확실하고 빠르게 해결하는 것이다.

데이터 엔지니어는 기업이 문제를 보고하기 전에 미리 문제를 발견해야 한다.

 

 

데이터옵스는 선언과 기타 자원을 활용하여 데브옵스 원칙을 데이터 도메인에 적용하고, 초기 비전을 수립하는 작업을 성공적으로 수행한다. 데이터 엔지니어는 모든 업무에서 데이터옵스의 작업 우선순위를 높게 지정하는 것이 좋다고 한다.

 


2장은 뒤에서 나올 내용을 가볍게 가져와 설명한다. 뒷 장에서 이를 자세하게 다룰 것이다.

+ Recent posts