From d51217286ab1830c3ecc01768c60d0d429066e74 Mon Sep 17 00:00:00 2001 From: Sim-km Date: Wed, 7 Aug 2024 22:09:35 +0900 Subject: [PATCH] =?UTF-8?q?docs:=209=EC=9E=A5=20=EB=8D=B0=EC=9D=B4?= =?UTF-8?q?=ED=84=B0=20=ED=8C=8C=EC=9D=B4=ED=94=84=EB=9D=BC=EC=9D=B8=20?= =?UTF-8?q?=EA=B5=AC=EC=B6=95=ED=95=98=EA=B8=B0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- gyumin/ch09.md | 127 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 127 insertions(+) create mode 100644 gyumin/ch09.md diff --git a/gyumin/ch09.md b/gyumin/ch09.md new file mode 100644 index 0000000..5101095 --- /dev/null +++ b/gyumin/ch09.md @@ -0,0 +1,127 @@ +# 9장 데이터 파이프라인 구축하기 + +* 데이터 파이프라인에 있어 카프카가 갖는 주요한 역할은 데이터 파이프라인의 다양한 단계 사이사이에 버퍼 역할을 해준다는 점입니다. + +## 9.1 데이터 파이프라인 구축 시 고려사항 + +### 9.1.1 적시성 + +* 대부분의 파이프라인은 실시간성을 요구하거나 요구하지 않는 두 가지 경우가 있다. +* 카프카를 쓰는 쪽과 읽는 쪽 사이의 시간적 민감도에 대한 요구 조건을 분리시키는 거대한 버퍼로 생각하면 좋다. + +### 9.1.2 신뢰성 + +* 서비스 유형에 따라 데이터가 유실되면 안되는 경우가 있다. 이때 카프카의 최소 한 번 전송을 통해 데이터 손실을 방지할 수 있다. + +### 9.1.3 높으면서도 조정 가능한 처리율 + +* 매우 높은 처리율을 가질 수 있는 확정상 있는 시스템에서 카프카는 버퍼 역할로서 쓰는 속도와 읽는 속도를 조정할 수 있다. + +### 9.1.4 데이터 형식 + +* 데이터 파이프라인에서 가장 중요하게 고려해야 할 것 중 하나는 서로 다른 데이터 형식과 자료형을 적절히 사용하는 것이다. +* 카프카와 커넥트 API는 데이터 형식에 완전히 독립적이다. 따라서 데이터 형식을 변경하더라도 카프카에 영향을 주지 않는다. + +### 9.1.5 변환 + +* 데이터 파이프라인을 구축하는 방법에는 ETL와 ELT 두 방식이 있습니다. +* ETL은 "추출-변환-적재(Extract-Transform-Load)"의 약자로, 데이터를 추출하고 변환한 후 다른 시스템에 적재하는 방식입니다.(smart pipeline) +* ELT는 "추출-적재-변환(Extract-Load-Transform)"의 약자로, 데이터를 추출하고 다른 시스템에 적재한 후 변환하는 방식입니다.(dude pipeline) +* 카프카 커넥트는 원본 시스템의 데이터를 카프카로 옮길 때 혹은 카프카의 데이터를 대상 시스템으로 옮길 때 단위 레코드를 변환할 수 있게 해주는 단일 메시지 변환 기능을 제공합니다. +* 데이터를 추출할 때 성급하게 최적화하려하지 말아야합니다. 어떤 경우에는 원본 데이터가 필요할 수 있기 때문입니다. + +### 9.1.6 보안 + +* 데이터 파이프라인의 관점에서 보안에 대해 주로 고려해야 할 점은 다음과 같습니다. + * 누가 카프카로 수집되는 데이터에 접근할 수 있는가? + * 파이프라인을 통과하는 데이터가 함호화되었다고 확신할 수 있는가? 이것은 여러 데이터센터에 걸쳐 구축된 데이터 파이프라인의 경우 특히 중요하다. + * 누가 파이프라인을 변경할 수 있는가? + * 만약 파이프라인이 접근이 제한된 곳의 데이터를 읽거나 써야할 경우, 문제 없이 인증을 통과할 수 있는가? + * 개인 식별 정보를 저장하고, 접근하고, 사용할 때 법과 규제를 준수하는가? +* 카프카는 데이터 전송 과정의 암호화를 지원합니다. 또한 SASL을 사용한 인증과 인가 역시 지원합니다. + +### 9.1.7 장애 처리 + +* 데이터 파이프라인에는 장애가 발생할 수 있기 때문에 모든 단계에서 장애 처리를 고려해야 합니다. + +### 9.1.8 결합과 민첩성 + +* 데이터 파이프라인을 구현할 때 데이터 원본과 대상을 분리할 수 있어야 합니다. +* 임기 응변 파이프라인 + * 데이터 파이프라인이 특정 엔드포인트에 강항게 결합되어 있는 경우, 새로운 기술을 도입하는 데 많은 비용이 발생한다. +* 메타데이터 유실 + * 데이터 파이프라인에서 스키마 진화를 지원함으로써 각 팀은 시스템 중단을 걱정할 필요 없이 자신들의 애플리케이션을 변경할 수 있다. +* 과도한 처리 + * 데이터를 가공하지 않고 그대로 전달하는 것이 더 좋을 수도 있다. + +## 9.2 카프카 커넥트 vs. 프로듀서/컨슈머 + +* 카프카 커넥트는 카프카를 직접 코드나 API를 작성하지 않고, 변경도 할 수 없는 데이터 저장소에 연결시켜야할 때 쓴다. +* 카프카 커넥트는 여러 저장소에 맞게 구현되어 있어, 설정 파일만 작성하기만하면 사용할 수 있다. + +## 9.3 카프카 커넥트 + +* 카프카 커넥트는 아파치 카프카의 일부로서, 카프카와 다른 데이터 저장소 사이에 확장성과 신뢰성을 가지면서 데이터를 주고받을 수 있는 수단을 제공합니다. +* 카프카 커넥트는 여러 워커 프로세스들의 클러스터 형태로 실행된다. +* 커넥터는 대용량의 데이터 이동을 병렬화해서 처리하고 워커의 유휴 자원을 더 효율적으로 활용하기 위해 태스크를 추가로 실행시킨다. +* 소스 커넥터 테스크는 데이터를 읽어서 워커 프로세스에 전달한다. +* 싱크 커넥트 테스크는 워커로부터 데이터를 받아서 대상 시스템에 쓴다. + +### 9.3.1 카프카 커넥트 실행하기 + +* 카프카 커넥트는 카프카 브로커와 별도의 서버에서 실행시켜야 한다. +* 커넥트 워커의 핵심 설정은 다음과 같다. + * bootstrap.servers: 커넥트 커넥트와 함께 작동하는 카프카 브로커 목록 + * group.id: 커넥트 클러스터 내에서 고유한 그룹 ID + * plugin.path: 커넥트 플러그인이 설치된 디렉터리 + * key.converter, value.converter: 카프카 메시지의 키와 값을 변환하는 클래스 + * rest.host.name, rest.port: 카프카 커넥트의 REST API를 사용할 때 사용하는 호스트 이름과 포트 + +### 9.3.4 개별 메시지 변환 + +* 카프카 생태계에서는 상태 없는 변환을 상태가 있을 수 있는 스트림 처리와 구분하여 개별 메시지 변환이라고 부른다. +* SMT는 카프카 커넥트가 메시지를 복사하는 도중에 데이터 변환 작업의 일부로서, 보통 코드를 작성할 필요 없이 수행된다. +* 카프카는 다음과 같은 SMT들을 포함한다. + * Cast: 필드의 데이터 타입을 변경 + * MaskField: 필드의 값을 null로 채운다. + * Filter: 특정 조건에 부합하는 모든 메시지를 제외하거나 포함한다. + * Flatten: 중첩된 자료구조를 핀다. + * HeaderForm: 메시지의 필드를 헤더로 이동하거나 복사한다. + * InsertHeader: 헤더에 정적인 문자열을 추가한다. + * InsertField: 메시지에 새로운 필드를 추가해 넣는다. + * RegexRouter: 정규식과 교체할 문자열을 사용해 목적지 토픽의 이름을 바꾼다. + * ReplaceField: 필드의 값을 다른 값으로 교체한다. + * TimestampConverter: 타임스탬프 필드의 형식을 변경한다. + * TimestampRouter: 타임스탬프 필드의 값을 기반으로 목적지 토픽을 선택한다. + +### 9.3.5 카프카 커넥트: 좀 더 자세히 알아보기 + +#### 1. 커넥터와 태스크 + +* 커넥터 플러그인은 커넥터 API를 구현한다. +* 커넥터는 다음의 세 가지 작업을 수행한다. + * 커넥터에서 몇 개의 태스크가 실행되어야 하는지 결정한다. + * 데이터 복사 작업을 각 태스트에 어떻게 분할해 줄지 결정한다. + * 워커로부터 태스트 설정을 얻어와 태스크에 전달한다. +* 태스크는 데이터를 실제로 카프카에 넣거나 가져오는 작업을 담당한다. +* 모든 태스크는 워커로부터 컨텍스트를 받아 초기화된다. +* 소스 컨텍스트는 소스 태스크가 소스 레코드의 오프셋을 저장할 수 있게 해주는 객체를 포함한다. +* 태스크가 시작되면 소스 태스크는 외부 시스템을 폴링해서 워커가 카프카 브로커로 보낼 레코드 리스트를 리턴한다. + +#### 2. 워커 + +* 카프카 커넥트의 워커 프로세스는 커넥터와 태스크를 실행시키는 역할을 맡는 '컨테이너' 프로세스라고 할 수 있다. +* 워커 프로세스가 다운되면 클러스터 내의 다른 워커 프로세스가 해당 워커 프로세스의 태스크를 다시 실행시킨다. +* 클러스터에 새로운 워커가 추가되면 워커들의 부하가 균형이 잡히도록 재조정을 거친다. + +#### 3. 컨버터 및 커넥트 데이터 모델 + +* 컨버터는 커넥트 워카가 카프카 메시지를 변환할 때 사용하는 클래스이다. +* 싱크 커넥터는 반대로 동작한다. 워커가 카프카로부터 레코드를 읽어 온 뒤, 설정된 컨버터를 사용해 읽어 온 레코드를 카프카에 저장된 형식 커넥트 데이터 API 레코드로 변환한다. + +#### 4. 오프셋 관리 + +* 커넥터는 어떤 데이터를 이미 처리했는지 알아야 하며 커넥터는 카프카가 제공하는 API를 사용해서 어느 이벤트가 이미 처리됐는지에 대한 정보를 유지 관리할 수 있다. +* 소스 커넥터의 경우, 커넥터가 커넥트 워커에 리턴하는 레코드에는 논리적인 파티션과 오프셋이 포함된다. +* 워커는 소스 커넥터로부터 받은 레코드를 카프카 브로커로 전송하며, 해당 레코드가 정상적으로 저장되면 오프셋을 갱신한다. +* 싱크 커넥터는 레코드를 읽어온 뒤 대상 시스템에 저장하면 오프셋을 갱신한다.