07. 데이터 파이프라인 구축하기
카프카로 데이터 파이프라인을 구축하는 방법에 대해 알아보겠습니다.
데이터 파이프라인이란#
아파치 카프카를 사용하여 데이터 파이프라인을 구축할 때 사용하는 두 가지 케이스가 있습니다.
첫 번째는 아파치 카프카가 두 개의 엔드 포인트 중 하나가 되는 데이터 파이프라인 구축하는 경우입니다.
이 경우 카프카는 일종의 엔드포인트가 되며, 이 때 개발자는 카프카의 데이터를 어떻게 엘라스틱서치로 가져올까?에 대한 해답을 카프카를 엔드포인트로 사용하자!로 내리게 됩니다.
그러나 이는 잘못된 설계일 수 있다고 저자는 지적하고 있는데요.
저자는 데이터 통합을 위해서 카프카를 중심으로 해서 두 개 이상의 시스템을 엔드 포인트로 갖게 하는 편이 좋다고 말하고 있습니다.
데이터 통합 문제에서 당장 필요한 엔드포인트 보다는 더 큰 관점을 고려할 것을 권장하고 있습니다.
두 번째 케이스는 일반적으로 서로 다른 시스템 중간에서 카프카를 중개 역할로 사용하는 파이프라인 구축입니다.
가장 일반적인 카프카의 사용 방법이기도 하고 많은 기업들이 이러한 구조를 갖고 있습니다.
이번 시간에는 카프카에서 제공하는 카프카 커넥트 API가 일반적인 프로듀서, 컨슈머 클라이언트와 어떻게 다른지 카프카 커넥트에 대해 조금 더 자세하게 살펴보겠습니다.
데이터 파이프라인 구축 시 고려사항#
데이터 파이프라인을 구축할 때 몇 가지 고려해야할 것들이 있습니다.
적시성#
하루에 한 번 대량의 데이터를 받는 시스템이 있는 반면, 데이터 생성 즉시 수 밀리초 안에 받아야하는 실시간 처리 시스템 두 가지가 있을 때 카프카는 그 중간정도의 포지션을 갖고 있음
카프카는 시간 단위의 배치 든 실시간 처리든 데이터를 적시에 전송하고 받을 수 있는 구조여야함
이게 가능한 이유는 데이터의 쓰기와 읽기가 분리되어 있기 때문
신뢰성#
단일 장애점을 피하고 모든 종류의 장애 발생에 신속하고 자동화된 복구를 할 수 있어야함
카프카는 가용성과 신뢰성을 6장에서 보장하였으며, 자체적으로 최소 한 번 데이터 전달을 제공한다.
카프카 커넥트는 외부 시스템과의 데이터 통합에 필요한 API를 제공하므로 정확히 한 번 데이터 전달 파이프라인을 더 쉽게 구축할 수 있음
높으면서도 조정 가능한 처리량#
카프카는 매우 높은 Throughput을 갖도록 확장할 수 있어야 하며 불시에 처리량이 증가하더라도 조정할 수 있어야 한다.
카프카는 평범한 클러스터에서도 초당 수백 메가 바이트를 처리할 수 있는 고성능 애플리케이션이다.
즉 카프카가 요구사항에 맞게 확장되지 못할 것이라는 걱정은 필요 없다.
데이터 형식#
카프카와 카프카 커넥트 API는 데이터 형식에 구애받지 않는다. (변환기를 사용하면 어떤 형식으로도 데이터 저장 가능)
ES는 JSON, 하둡은 Parquet(파케이), 아마존 S3는 CSV 형식을 받는데 카프카 커넥트 API는 이 모두를 지원한다.
변환#
카프카는 ETL과 ELT를 모두 지원한다.
ETL은 들어본적 있는데, ELT의 경우 대상 시스템에 전달되는 데이터가 원본 데이터와 최대한 유사하게 전달하기 위함이라고 한다.
그래서 대용량 데이터를 ELT로 처리하면 대상 시스템의 부하가 있을 수 있다고 한다.
ETL과 ELT의 차이는 누가 데이터 변환의 책임을 가지냐가 핵심인 것 같다
보안#
파이프라인을 거쳐 가는 데이터가 암호화된다고 확신, 보장할 수 있는가?
파이프라인을 수정할 수 있도록 허용된 사람은 누구인가?
접근이 제어된 시스템에서 데이터를 파이프라인으로 읽거나 쓸 때, 인증 기능을 올바르게 사용하고 있는가?
카프카는 데이터 전송시 암호화된 데이터의 네트워크 전송을 허용하고, SASL(Simple Authentication and Security Layer) 인증을 지원한다.
장애 처리#
- 카프카는 모든 데이터를 긴 시간동안 저장하므로 장애가 발생하면 해당 시점에 맞게 이전으로 돌아가서 에러를 복구할 수 있다.
결합과 민첩성#
임기응변식 파이프라인#
ES와 Logstash는 ELK 스택이라고도 불리며 환상의 짝꿍으로 불리지만, 로그스태시라는 데이터 파이프라인을 구성하게 되면 커스텀 애플리케이션들이 이런 엔드포인트와 강하게 결합되어서 이후 유지보수가 어렵게 될 수 있습니다.
메타데이터 유실#
데이터 파이프라인이 스키마 메타데이터를 보존하지않고 스키마의 진화를 허용하지 않으면, 데이터를 생성하는 쪽과 소비하는 쪽 간의 강결합이 발생하게 됩니다.
파이프라인이 스키마 데이터를 갖고 있질 않으면 다른 두 시스템이 스키마에 대한 정보를 각자 갖고 있을 수 밖에 없습니다.
만약 오라클 DB로 부터 HDFS로 데이터가 이동하는 구조에서 오라클 DB에 컬럼이 추가되면 HDFS로부터 데이터를 읽는 모든 애플리케이션이 중단될 것입니다.
반대로 파이프라인에서 스키마 진화를 지원한다면 각 시스템들은 유연하게 변경할 수 있을 것입니다.
과도한 처리#
파이프라인에서 너무 많은 처리를 해버리면 후속 시스템들이 파이프라인에 종속적이게 됩니다.
가령 어떤 필드를 보존하고, 데이터 집계를 어떻게 할 지에 대한 요구사항이 있을 때 파이프라인의 처리 로직을 변경해야하기 때문에 신속성, 효율성, 안전성이 떨어지게 됩니다.
그러니 가능한 원시 데이터의 형태로 보존하는 편이 좋고, 후속 애플리케이션에서 스스로 결정하여 데이터 처리를 하는 편이 더 나은 방법입니다.
카프카 커넥트 VS 프로듀서/컨슈머#
둘 중 언제 어느 것을 사용하는 편이 좋을까?
코드를 작성할 수 없고 변경도 불가능한 시스템들 ( DB, Storage Service, Amazon S3, 하둡 HDFS, ES )에 카프카를 연결할 때 카프카 커넥트를 사용한다.
카프카의 데이터를 일거엇 외부 시스템에 쓰는데 사용하는 컴포넌트 클래스가 커넥터
카프카 커넥트#
- 카프카 커넥트는 아파치 카프카의 일부로 포함되며 카프카와 다른 데이터 저장소간의 데이터 이동을 위해 확장성과 신뢰성 있는 방법을 제공한다.
카프카 커넥터는 Source 커넥터와 Sink 커넥터 두 종류로 나눠진다.
소스 커넥터 : 외부 시스템 -> 커넥트 -> 카프카
싱크 커넥터 : 카프카 -> 커넥트 -> 외부 시스템
커넥트의 내부구조#
커넥트는 미리 템플릿이 구현되어있고 그 템플릿의 설정값을 기준으로 인스턴스를 생성합니다.
커넥트에서는 그 템플릿을 Plugin이라 부릅니다.
이제부터 하나씩 자세히 그 역할을 들여다보도록 하겠습니다.
커넥터#
커넥터는 파이프라인의 Task들을 관리합니다.
예를 들어, JDBC 소스 커넥터는 DB에 연결하고 복사할 기존 테이블들을 찾은 후 그 결과에 기반해 몇 개의 테스크가 필요한지를 결정합니다.
REST API를 사용해서 커넥터를 실행할 때는 어떤 노드에서도 시작시킬 수 있고, 이후 실행되는 테스크들도 마찬가지로 REST API로 실행시킬 수 있습니다.
태스크#
태스크는 카프카의 데이터를 실제로 입출력하는 책임을 갖습니다.
모든 태스크는 관련 워커 프로세스로부터 컨텍스트를 받아 초기화됩니다.
예를 들어, 소스 컨텍스트는 하나의 객체를 포함하며 이 객체는 소스 태스크가 소스 레코드의 오프셋을 저장할 수 있게 해줍니다.
즉 태스크는 카프카와의 메시지 복제에 대한 구현체이고 실제 파이프라인의 동작 요소들입니다.
워커 프로세스#
카프카 커넥트의 워커 프로세스는 커넥터와 태스크를 실행하는 컨테이너 프로세스입니다.
커넥터와 커넥터의 구성을 정의하는 HTTP 요청을 처리하는 책임을 갖습니다.
워커 프로세스는 커넥트의 구성을 저장하고 커넥터와 해당 커넥터의 태스크를 실행시킵니다.
만약 특정 워커 프로세스가 중지되면 커넥트 클러스터의 다른 워커 프로세스들이 이를 알게 되고, 중단된 워커 프로세스에서 실행되던 커넥터와 태스크들이 나머지 워커 프로세스들에게 재할당됩니다.
새로운 워커 프로세스가 커넥트 클러스터에 합류하면, 다른 워커 프로세스들이 이를 알게 되고, 모든 워커 프로세스의 워커량이 균등하게 조정되도록 새로 합류한 워커 프로세스에게 커넥터와 태스크가 할당됩니다.
워커 프로세스는 소스와 싱크 커넥터 모두의 오프셋을 자동으로 커밋하고 에러가 생길 때 재시도를 수행합니다.
커넥터와 태스크는 데이터 통합에서 이동되는 데이터만을 처리한다면,
워커 프로세스는 REST API, 구성 관리, 신뢰성, 고가용성, 확장성, 부하 분산 등의 모든 작업을 처리하는 책임을 갖습니다.
커넥터를 고려할 때 주의할 점#
커넥터를 구성할 때 몇 가지 주의해야할 점이 있습니다.
외부 시스템을 지원하는 플러그인의 존재 유무
해당 플러그인의 라이센스 정보
플러그인의 경우 제공하는 업체나 커뮤니티가 각각 다릅니다. (심지어 싱크와 소스도 따로 제공되는 경우도 많다고 합니다)
그렇기 때문에 커넥터를 고려할 때는 라이센스도 같이 확인을 해봐야합니다.
JDBC Connector의 경우 Source와 Sink를 모두 지원하고 무료입니다.
카프카 커넥트의 대안#
지금까지 카프카 커넥트 API에 관해 깊게 공부해보았습니다.
카프카 커넥트 API는 얼핏 좋아보이지만, 라이센스 이슈로 인해 사용하지 못할 수도 있습니다.
이런 경우 대안은 어떤 것들이 있을까요?
다른 데이터스토어의 프레임워크#
카프카가 우주의 중심이라고 생각하는 사람도 있지만, 이에 동의하지 않는 사람들도 있습니다.
하둡이나 ES로 대부분의 데이터 아키텍처를 구축하는 사람들도 있기 때문이지요.
이러한 시스템들은 대체로 데이터 처리에 필요한 수집, 통합, 전달 도구를 갖고 있습니다.
가령 하둡의 경우 Flume, ES는 로그스태시와 플루언트디가 있죠.
카프카가 아키텍처의 핵심 부분이고 대량의 소스와 싱크를 연결하는 것이 그 목적이라면 카프카 커넥트 API는 필수적인 선택입니다.
그러나 하둡이나 ES가 중심의 시스템이라면 카프카는 그 시스템의 입력 시스템 중 하나로 고려하고, 플룹이나 로그스태시 플루언트디를 사용합시다.
스트림 프로세싱 프레임워크#
이 부분은 개인적으로 이해가 잘 안갔습니다. 스트림 프로세싱 프레임워크가 무엇이고, 데이터 통합을 같은 프레임워크로 한다는게 무슨 의미일까요
대부분의 스트림 프로세싱 프레임워크에서는 카프카로부터 데이터를 읽어 다른 대상 시스템에 쓸 수 있습니다.
대상 시스템이 카프카를 지원하고, 카프카의 데이터 처리를 위해 스트림 프로세싱 프레임워크를 사용할 의향이 있다면, 데이터 통합도 같은 프레임워크를 사용하는 편이 바람직할 것 같습니다.
결론#
카프카 커넥터 API이 왜 데이터 통합에 적합한지에 대하여 알아보았습니다. (내부 동작도)
최종적으로 어떤 데이터 통합 솔루션을 사용하든, 모든 장애 상황에서 모든 데이터를 전달할 수 있는 능력이 가장 중요할 듯 한데요.
그런 면에서 저자는 카프카 커넥트가 매우 신뢰성이 높다고 믿고 있습니다.
그러나 궁극적으로 데이터 통합 시스템의 목적은 데이터를 전달하는 것이므로 카프카 커넥트를 사용하지 않더라도 충분한 테스트를 통해 데이터 전송 신뢰성을 확보한다면 다른 대안을 사용하는 것도 좋다고 말하고 있습니다.
결국 시스템 요구사항에 맞게 적절하게 사용할 수 있도록 하는 것이 가장 중요할 듯 싶습니다.
마지막으로 객체지향의 바이블이라 불리는 조영호님의 책 Object의 마지막 구절로 마무리하도록 하겠습니다.
Reference#
카프카 핵심 가이드