제네시스 – 광고추천팀의 카프카 기반 스트리밍 데이터 플랫폼

안녕하세요, 광고추천데이터플랫폼파트에서 데이터 엔지니어로 일하고 있는 cory입니다. 저는 광고추천팀에서 카프카 기반 스트림 데이터 플랫폼을 만들고 운영하고 있습니다.

광고추천팀에서는 광고 로그(impression, click, conversion 등)를 원천 데이터로 사용하여 개인화된 광고를 서빙하는 작업을 진행합니다. 팀 내 데이터 사이언티스트 크루들의 원활한 분석을 위해 ETL 프로세싱이 필요합니다. 광고추천데이터플랫폼파트에서는 대용량 대규모 데이터인 광고 원천 로그를 원활히 ETL 프로세싱 하기 위해 2021년 말부터 제네시스(genesis)라는 이름의 카프카 기반 데이터 플랫폼을 운영 중입니다.

이번 글에서는 광고추천팀에서 운영하고 있는 제네시스가 어떻게 도입되었는지 그리고 앞으로 어떤 방향으로 발전할 것인지에 대해서 이야기하려고 합니다.

 



레거시 데이터 파이프라인 아키텍처

 

제네시스가 도입되기 전 원천 로그의 ETL 프로세싱은 로그스태시를 통해 수행되었습니다. 로그스태시는 엘라스틱 스택 중 하나로서 input, filter, output 플러그인을 적용하여 풍부한 ETL 처리를 할 수 있는 장점이 있습니다.

그러나 로그스태시를 사용한 데이터 파이프라인은 다음과 같은 단점이 있었습니다.

  • 사용자 분석을 위해 필요한 카프카 토픽의 개수가 많아짐에 따라 로그스태시의 configuration 파일이 지속적으로 많아짐

  • 파이프라인의 생성, 수정, 삭제는 git을 통해 수행해야 했기 때문에 각 파이프라인의 동작을 알기 위해서는 git code를 조회해야 함

  • 공용으로 사용하고 있었기 때문에 오너십 없이 운영했음. 이에 따라 파티션 개수보다 컨슈머 로그스태시가 더 많이 실행되는 것과 같은 리소스 낭비가 발생함

  • 적정 파티션 개수 지정과 지연 모니터링을 위해 처리량 모니터링 대시보드가 없었음


이와 같은 레거시 파이프라인 아키텍처을 개선하기 위해 고민을 거듭했고 결과적으로 카프카 커넥트 기반의 플랫폼을 구성했습니다.


제네시스

 

제네시스는 카프카 커넥트 기반 데이터 플랫폼으로서 기존 로그스태시 기반 파이프라인을 개선하기 위해 신규 개발한 플랫폼입니다.

Genesis :광고추천팀의 모든 광고 원천 데이터는 제네시스를 통해 유입되어 처리되기 시작되기 때문에 ‘기원, 발생, 시작’의 뜻을 지닌 제네시스로 명칭을 정했습니다.

제네시스를 도입하면서 고려했던 점은 다음과 같습니다.

  1. 오너십 : 각 데이터 파이프라인의 소유자와 관련 지라 번호를 지정하여 운영의 편의성을 높임

  2. 모니터링 : 데이터 파이프라인의 개별 처리량과 전체 처리량, 개별 파이프라인에 대한 컨슈머 랙을 모니터링 수행

  3. 배포 : 웹 플랫폼을 통해 파이프라인의 생성/삭제/수정을 할 수 있도록 수행

  4. 데이터 리니지 : 광고추천팀에 오너십이 있는 토픽에 대해 파이프라인의 계보를 확인할 수 있도록 화면 제공

위 4가지를 달성하기 위해 다양한 오픈소스 소프트웨어들을 고려했습니다. 그중 카프카 커넥트를 최종 선택하게 되었습니다.


카프카 커넥트

카프카 커넥트는 오픈소스 아파치 카프카에서 제공하는 툴로서 카프카 기반 데이터 파이프라인을 반복적으로 생성하고 운영하는데 적합합니다. 아파치 카프카와 완벽하게 호환되며 필요에 따라 커넥트 노드를 추가하여 스케일 아웃할 수 있습니다. 기본 통신 구조는 REST API를 활용하여 커넥터라고 불리는 데이터 파이프라인을 반복적으로 생성, 수정, 삭제할 수 있습니다.

파이프라인으로 활용되는 커넥터는 연동 되는 DB 또는 애플리케이션에 대응하여 오픈소스가 시중에 많이 나와있으며 필요에 따라 커스텀 커넥터를 개발할 수도 있습니다. 제네시스는 오픈소스 커넥터와 직접 만든 커스텀 커넥터를 함께 사용 중입니다.


카프카 커넥트 아키텍처

카프카 커넥트는 분산 커넥트와 단일 커넥트로 나뉩니다.

  • 단일 커넥트 : 단일 프로세스(워커)로 실행되기 때문에 주로 디버깅 또는 테스트용으로 사용됨

  • 분산 커넥트 : 다수의 프로세스(워커)에서 분산되어 파이프라인이 운영되기 때문에 고가용성을 특징을 가지며 처리량에 따라 가변적으로 스케일 아웃할 수 있음

카프카 커넥트에서 실질적으로 ETL 역할을 수행하는 것을 커넥터라고 부릅니다. 커넥터는 싱크 커넥터와 소스 커넥터로 나뉩니다.

  • 싱크 커넥터 : 카프카의 토픽 내 데이터를 타깃 애플리케이션으로 저장 또는 호출하는 역할을 합니다. 컨슈머와 동일한 역할을 수행

  • 소스 커넥터 : 소스 애플리케이션으로부터 데이터를 카프카 토픽으로 저장하는 역할을 합니다. 프로듀서와 동일한 역할을 수행


제네시스 아키텍처

제네시스 플랫폼은 다음과 같은 큰 구성요소로 구분되어 이루어져 있습니다.

  • apache kafka : 카카오에서는 공용 카프카 클러스터를 사용합니다. 공용 카프카에 용도별 카프카 커넥트 클러스터를 배포합니다.

  • genesis-connect(kafka connect) : 커스텀 커넥터, 오픈소스 커넥터 등이 포함된 커넥트(워커) 도커 이미지를 운영 중입니다.

  • JMX exporter, Burrow : 커넥트, 커넥터 모니터링을 위해 jmx exporter, burrow로부터 지표를 프로메테우스로 수집합니다.

  • genesis-web : 파이프라인을 생성, 수정, 삭제할 수 있는 웹입니다.


제네시스에서 사용중인 커넥터

제네시스에서는 다음과 같은 커넥터들을 사용 중입니다.

  • 오픈소스 커넥터

    • HdfsSinkConnector

    • MongoSinkConnector

    • MongoSourceConnector

    • CouchbaseSinkConnector

    • DseSinkConnector(Cassandra)

  • 커스텀 커넥터

    • KafkaSinkConnector : 필터링, 레코드 주입 기능(timestamp, 메시지 키), 샘플링(n%)

    • extFeatureJoinKafkaSinkConnector : 광고 로그에 외부 피쳐 주입

    • adLogJoinKafkaSinkConnector : 광고 로그에 추가 데이터 주입

대부분 오픈소스 커넥터를 사용하되 필요에 따라 커스텀 커넥터를 개발하여 운영 중입니다. 오픈소스 커넥터를 도입할 때는 해당 커넥터의 라이선스를 반드시 확인하고 도입하는 것이 좋습니다. 대부분 아파치 2.0 라이선스이지만 일부 커넥터의 경우 기업용은 구매가 필요할 수 있습니다.

카프카와 연계되는 모든 카프카 프로세싱 애플리케이션을 커넥터로 개발할 필요는 없습니다. 요구사항에 따라서 상태 기반 데이터 프로세싱이 필요할 수도 있고 단발성 파이프라인은 별개의 애플리케이션으로 개발하여 운영하는 편이 더 좋을 수 있기 때문입니다.


제네시스 웹

REST API로 동작을 수행하는 카프카 커넥트 특성상 커넥터를 생성, 수정, 삭제하기 위한 동작을 CLI 툴 또는 데스크톱 도구를 사용하는 것은 지속적인 운영에 한계가 있습니다. 이런 한계를 해소하고 지속적인 운영을 위해 vue.js로 어드민 페이지를 만들었고 모든 파이프라인 관련 동작은 제네시스 웹을 통해 수행 가능하도록 개발했습니다.

파이프라인 생성 페이지에서는 생성하고자 하는 파이프라인 종류(여기서는 커넥터 종류)를 선택하고 추가 설정값을 넣을 수 있습니다.

생성된 파이프라인은 파이프라인 리스트에서 조회할 수 있으며 검색 기능도 제공합니다. 각 파이프라인에는 크루 닉네임과 관련 지라 번호를 입력하도록 설정하였기 때문에, 개별 파이프라인에 대한 히스토리를 확인하기 용이해졌습니다.

파이프라인을 조회하면 해당 파이프라인에 대한 상세 내용을 조회할 수 있으며 스트림 데이터의 계보(리니지), 모니터링도 함께 확인할 수 있습니다.

이와 같은 구성을 통해 제네시스는 다음과 같은 특징을 가지게 되었습니다.

  1. 오너십 : 각 파이프라인에 대해 담당자를 지정하여 개별 파이프라인에 대한 오너십을 위임하였습니다.

  2. 모니터링 : 개별 파이프라인에 대한 모니터링을 수행할 수 있게 되었습니다. 또한 전체 커넥트 클러스터에 대한 모니터링도 함께 수행할 수 있습니다.

  3. 배포 : 개별 파이프라인은 웹을 통해 개발자가 직접 수행합니다.

  4. 데이터 리니지 : 토픽을 기준으로 스트림 데이터의 계보를 확인할 수 있게 되었습니다. 이를 통해 현재 사용 중인 토픽의 데이터가 어떤 프로세싱을 거쳤는지 확인할 수 있습니다.


카프카 커넥트를 운영하면서 느낀 점

카프카 커넥트는 강력하지만 좋다고 당장 도입하기에는 고려해야 할 점이 많습니다. 카프카 커넥트를 운영하면서 느낀점과 고려해야 할 점을 다음과 같이 정리해 보았습니다.


1) 반드시 웹 화면이 필요함

카프카 커넥트는 REST API를 통해 파이프라인을 생성, 수정, 삭제할 수 있지만 언제까지나 curl 또는 postman과 같은 툴로 운영할 수는 없습니다.

				
					$ curl -X POST http://genesis-connect.cc/connectors \
-H "Content-Type: application/json" \
-d " {
    "name": "sample-sink-connector",
    "config": {
        "connector.class": "com.genesis.SampleConnector",
        "tasks.max": "10",
        "topics": "test-topic"
    }
}" 
				
			

지속적인 운영과 모니터링을 위해서는 반드시 REST API들을 호출할 수 있는 웹 화면이 필요합니다. Vue.js 또는 React를 통해 직접 개발해도 되지만, 오픈소스로 나와 있는 카프카 커넥트 웹을 사용해도 됩니다. 카카오 광고추천팀에서는 제네시스 웹을 오픈소스화 한 kafka-connect-web을 깃허브에 공개하였습니다.

Vue.js로 만들어진 kafka-connect-web은 bootstrap 5가 적용된 웹 페이지로서 커넥트를 운영하고 커넥터를 생성, 수정, 삭제할 수 있는 기능을 제공합니다. 직접 코드를 다운로드해서 빌드 하여 사용해도 되고 또는 도커 허브의 이미지를 사용해도 좋습니다.

				
					$ docker run -d -p 8080:8080 \
             -e 
    "VUE_APP_CONNECT_SERVERS=http://connect:8083,http://connect2:8083" \
             officialkakao/kafka-connect-web:1.0
				
			

해당 오픈소스에 대한 문의사항 또는 이슈는 다음 링크를 사용해 주세요.

 

2) 커스텀 커넥터 개발 여부 결정

앞서 설명드렸다시피 카프카와 연동되는 모든 파이프라인을 커스텀 커넥터로 개발할 필요는 없습니다. 일부 커넥터는 오픈소스로 제공되고 있는 경우도 있으며 일부 요구사항은 커넥터에 부적합할 수 있습니다. 커넥트와 커넥터는 카프카와 연동되어 싱크, 소스 파이프라인을 만들 때 강력한 프로세싱을 수행하지만 분명 한계가 있습니다. 예를 들어 카프카 커넥터의 동작은 반드시 토픽을 기준으로 input 또는 output을 가져야만 하기 때문에 카프카와 연관되지 않은 데이터 처리에는 부적합합니다. 또한 보안 설정이 된 하둡 환경의 여타 데이터 플랫폼들(HBase, Hive, HDFS) 등과 연동하여 대규모 데이터 처리를 해야 할 때는 설정이 매우 복잡해질 수 있습니다. 이런 경우에는 스파크 스트리밍과 같은 도구가 적합할 수 있습니다.

 

정리하자면 다음 체크리스트를 통과한 경우 커스텀 커넥터 개발을 진행합니다.

  1. 오픈소스 커넥터 유무

  2. 카프카의 토픽을 input 또는 output으로 사용하는가?

  3. 1 record + 1 process를 만족하는 비상태기반(stateless)처리인가?

  4. 2개 이상 반복적으로 생성이 되어야 하는 파이프라인인가?

 

3) 커넥트 클러스터 구분 운영

상용 환경에서는 분산 모드로 카프카 커넥트를 클러스터 단위로 운영합니다. 커넥트에는 다수의 다양한 커넥터가 실행되는 특징을 가집니다. 그렇기 때문에 커넥터의 특징에 따라 타 커넥터 또는 커넥트 클러스터 전체에 영향을 끼칠 수 있습니다. 예를 들어 일부 커넥터의 경우 메모리를 많이 사용할 수 있습니다. 메모리를 많이 활용하는 커넥터로 인해 OutOfMemoryException이 발생하면 정상적인 커밋이 불가능하기 때문에 동일 노드의 타 커넥터들의 처리에 중복이 발생할 수도 있습니다. 그렇기 때문에 필요에 따라 특정 커넥터들은 커넥트 클러스터를 분리하는 작업이 필요할 수도 있으므로 이를 반드시 고려해서 운영해야 합니다.

추가적으로 카프카 커넥트는 최대 1개의 카프카 클러스터에 붙을 수 있기 때문에 카프카 클러스터가 여러 개인 경우에는 다수의 커넥트 클러스터를 운영해야 한다는 점도 잊지 말아야 합니다.


앞으로 해야 할 일

지금까지 구성된 제네시스 플랫폼은 많은 역할을 수행하고 있진만 앞으로도 해야 할 일들은 더욱 많습니다. 앞으로 진행되어야 할 to-do 리스트 중 일부를 공개하며, 이 글을 마치도록 하겠습니다. 

  • 데이터 디스커버리

  • 상태 기반 프로세싱 아키텍처

  • SQL 기반 프로세싱 아키텍처

  • 데이터 리니지 고도화

  • 배치 -> 스트림 & 스트림 -> 배치 


감사합니다. 

Latest Posts