데이터 파이프라인의 구성 요소
데이터 파이프라인
카프카는 분산 메시징 시스템으로 다른 시스템이나 도구에서 보낸 메시지를 받아 다른 시스템이나 도구의 요청에 근거해 메시지를 전달하는 기능을 제공하고 있다. 이 데이터가 전달되는 경로나 처리를 위한 기반 전체를 데이터 파이프라인이라고 한다.
카프카는 하나 이상의 브로커로 된 카프카 클러스터, 프로듀서, 컨슈머, 카프카 클라이언트로 구성되어 있다. 이 중 데이터 파이프라인의 일부가 되는 것은 카프카 클러스터, 프로듀서, 컨슈머다.
데이터 파이프라인의 프로듀서 구성 요소
카프카를 이용한 데이터 파이프라인의 프로듀서 쪽은 데이터를 생성하고 송신하는 미들웨어가 카프카에 대응하고 있는지에 따라 다음 두 가지 패턴으로 분류할 수 있다.
미들웨어가 직접 카프카에 메시지로 송신하는 패턴
말 그대로 미들웨어가 카프카에 메시지를 송신하는 패턴이다. 표준 기능으로 카프카로 송신 기능을 갖추고 있는 것 외에 플러그인 등을 추가함으로써 그 기능을 이용할 수 있는 것도 있다. 이 경우 비교적 쉽게 카프카로 데이터 파이프라인을 구축할 수 있다.
미들웨어가 직접 카프카에 데이터를 송신하지 않고 다른 도구로 메시지를 송신하는 패턴
데이터를 생성하는 미들웨어가 카프카로 메시지를 송신하지 않는 패턴이다. 실제로 현업에서 이 패턴을 사용하는 경우도 많다. 예를 들어 일반적인 HTTP 서버는 엑세스 로그를 카프카에 직접 송신하는 기능을 갖고 있지 않다. 이 경우는 일단 로컬의 로그 파일에 출력한 뒤 별도의 메시지 송신 도구를 사용해 카프카에 메시지로 송신하는 방식이 일반적이다.
그 밖의 예로 사물인터넷 등에서 센서 장치가 MQTT 프로토콜을 이용하여 데이터를 송신하는 경우가 있다. 이러한 미들웨어가 출력한 데이터를 카프카로 송신하는 도구 중 대표적인 것은 Kafka Connect와 Fluentd다.
Kafka Connect는 외부 데이터를 카프카로 입력하고 카프카에서 외부로 데이터 출력 기능을 제공한다. Fluentd는 오픈소스 데이터 수집 도구로 카프카의 메시지 입출력에 특화된 것은 아니지만 각각 입출력용의 플러그인이 제공되고 있다.
데이터 파이프라인의 컨슈머 구성 요소
프로듀서와 마찬가지로 두 가지 패턴으로 분류할 수 있다.
미들웨어가 직접 카프카에서 메시지를 취득해 처리하는 패턴
데이터를 처리하거나 기록하는 미들웨어가 카프카에서 메시지를 수신하는 패턴이다. 이 패턴은 배치 처리와 스트림 처리 모두 가능하지만 카프카가 스트림 데이터를 취급하는 기반이기 때문에 스트림 처리에서 많이 볼 수 있다. Apache Flink가 대표적이다.
이 방식에서는 대부분의 경우 연계하는 외부 시스템이나 피알시스템 등에 처리 결과가 출력되지만 처리한 결과를 다시 카프카에 출력하는 경우도 있다. 예를 들어 전처리를 실시한 스트림 데이터를 다른 스트림 처리 애플리케이션에서 사용하는 경우다. 이 경우 해당 애플리케이션은 카프카에서 메시지를 취득해 처리하는 컨슈머인 동시에, 한편으로는 처리한 결과를 카프카에 송신하는 프로듀서라고도 할 수 있다.
미들웨어가 다른 도구를 통해 카프카에서 메시지를 취득하고 처리/보관하는 패턴
데이터를 처리하고 기록하는 시스템 또는 미들웨어가 카프카에서 메시지 수신을 지원하지 않아 다른 도구로 카프카에서 메시지를 수신한 후 원하는 시스템에 데이터를 전달하는 방식이다. 대표적인 것이 Kafka Connect와 Fluentd이다.
데이터 파이프라인에서 취급하는 데이터
데이터 파이프라인에서 처리 특성
카프카를 사용한 데이터 파이프라인에서는 취급한 데이터 자체도 중요한 요소다. 카프카를 사용한 데이터 파이프라인의 애플리케이션이나 스트림 처리에는 다음과 같은 특성이 있다.
여러 미들웨어나 애플리케이션에서 데이터를 읽고 쓴다.
여러 미들웨어나 애플리케이션에서 데이트를 읽고 쓴다는 것은 데이터 파이프라인의 특성이다. 대부분의 경우에서 프로듀서와 컨슈머는 서로 다른 애플리케이션이며 거기서 다루는 데이터는 당연히 프로듀서, 컨슈머 양쪽에서 모두 취급해야 한다.
예를 들어 웹 서비스의 사용자 액세스 로그 분석에서 프로듀서 쪽 웹 서버가 기록하는 데이터 형식으로 컨슈머 쪽에서 분석한다. 이때 웹 서버의 액세스 로그 기록 방법이 예상과 다른 형식으로 변경되면 컨슈머 쪽 분석을 올바르게 할 수 없다. 따라서 프로듀서가 출력하는 데이터와 컨슈머가 전제로 하는 데이터는 일관성이 있어야 한다.
애플리케이션은 항상 실행 상태로 데이터를 처리한다.
스트림 데이터는 계속 생성되기 때문에 데이터를 수신하는 애플리케이션도 계속 처리해야 한다. 항상 동작하는 데이터 파이프라인에서의 처리 방법은 파이프라인을 구성하는 애플리케이션, 취급하는 데이터를 설계할 때 고려해야 한다. 많은 구성 요소에 영향을 미치는 3가지 요소는 다음과 같다.
- 메시지 데이터 형태
- 스키마 구조를 갖는 데이터 형태 및 스키마 에볼루션
- 데이터 표현 방법
여러 미들웨어나 애플리케이션에서 데이터를 읽고 쓰는 특징은 3가지 요소에 영향을 준다. 그리고 애플리케이션은 항상 실행 상태로 데이터를 처리하는 특징은 스키마 에볼루션을 더욱 어렵게 한다.
메시지 데이터 형태
카프카를 이용한 데이터 파이프라인에서는 카프카를 경유하여 메시지를 송수신하는데, 이 메시지의 데이터 형태는 프로듀서와 컨슈머에서 일치해야 한다. 데이터를 송신하는 쪽과 데이터를 수신하는 쪽에서 데이터 형태가 일치해야 하는 것은 스트림 데이터를 다루는 데이터 파이프라인에만 국한된 이야기가 아니다. 배치 처리도 데이터 형태가 송수신쪽 모두 일치해야 한다. 그러나 카프카에서는 데이터 형태를 관리하고 있지 않기 때문에 카프카 클러스터에서 데이터 형태가 다른 것을 확인하지 못하고 컨슈머가 메시지를 수신하여 역직렬화나 데이터 처리하고 난 뒤에 발견되는 경우가 있다. 따라서 데이터 형태에 주의가 필요하다.
컨슈머뿐만 아니라 송신하는 프로듀서에서도 메시지 데이터 형태에 주의가 필요하다. 프로듀서에서 보낸 메시지의 데이터 형태를 변경하려면 그에 해당하는 컨슈머도 변경해야 한다. 그러나 애플리케이션은 항상 데이터를 처리하고 있어 쉽게 중단시킬 수 없는 경우가 있다. 또한 데이터 허브 같은 사례는 여러 프로듀서, 컨슈머가 메시지를 수신하고 있기 때문에 유지보수가 필요한 범위가 더욱 넓어져 대응하는 데 더욱 어렵게 만든다.
스키마 구조를 갖는 데이터 형태
다루는 데이터나 요구 사항에 따라 하나의 메시지에 여러 값을 포함시키고 싶은 경우가 있다. 이러한 경우 데이터 스트림과 스트림 처리에서는 JSON이나 Apache Avro 같은 구조화된 데이터가 자주 사용된다. 여러 카럼을 가진 스키마를 정의하여 하나의 메시지 안에 여러 값을 포함할 수 있게 된다. 스키마 정의는 메시지를 송신하는 프로듀서 애플리케이션 설계에서 사용되지만 컨슈머 애플리케이션에 미치는 영향이 크기 때문에 확장성을 고려하여 신중하게 결정해야 한다.
스키마 에볼루션
스키마 정의를 운용 중 변경하는 것을 스키마 에볼루션이라 한다.
데이터 파이프라인은 계속 동작하기 때문에 스키마 에볼루션에 동반하여 정지할 애플리케이션의 수나 정지 시간을 최소화해야 하는 경우가 많다. 이러한 문제애 대한 대응으로 스키마 에볼루션을 진행할 때 스키마 변경 전후의 호환성을 고려하게 된다.
Apache Avro는 호환성을 고려할 수 있는 데이터 형태로, 전방 호환성, 후방 호환성 등 일부 호환성의 종류도 선택할 수 있다. 확장성을 고려해야 하는 경우 이러한 데이터 형태도 선택할 수 있는 대안 중 하나다.
데이터 표현 방법
데이터 파이프라인에서는 데이터 표현 방법도 중요하다. 예를 들어 날짜를 표현하는 경우에도 UnixTime이나 문자열 표현 등 여러 방식이 있을 수 있다.문자열로 표현하는 경우에도 '2022/10/05'와 같은 반각 문자를 사용하거나 '2022년 10월 05일' 같은 한글 문자를 사용하는 등 시스템에 따라 다양하게 표현할 수 있다.
이러한 정보를 데이터 파이프라인 안의 카프카에서 다룰 때는 올바른 데이터 형태로 직렬화하면 송신은 가능하지만 각각의 표현 방법에 맞는 처리가 필요해 데이터 활용에 방해가 될 수 있다. 스키마 구조를 갖는 데이터 형태를 채용함으로써 관리할 수 있는 것도 있지만, 본질적인 대책은 데이터 파이프라인 쪽의 시스템만으로는 어렵고 데이터의 표현 방법에 규칙을 정해 각 시스템이 그에 따르도록 하는 노력이 필요하다.
