BLOG

[re:Invent 2019] Lift and shift an Apache Kafka cluster to Amazon MSK
작성일: 2019-12-03

* 세션명 : Lift and shift an Apache Kafka cluster to Amazon MSK
* 일자 : 2019/12/02 10:45~13:00
* 장소 : Aria, Level 3, West, Stavine 10 – T2

 

 

Amazon MSK를 사용해야하는 이유와 On-premise에서 Amazon MSK migration하는 방법 소개 등 MSK를 전반적으로 이해하고 활용 하는 방법에 대해서 알아보는 세션이었습니다.

MSK의 최대 장점은 사용하기가 쉽고, 컨트롤 플레인, 클러스터의 관리가 쉬운 것입니다. 브로커에 대한 이중화 지원이 가능하며, 고객은 ENI만 볼 수 있습니다. 클러스터 전체가 managed by AWS이며, serverless 서비스를 제공 하고 있습니다. 브로커의 network delay 등의 장애에 대비한 아키텍처 또한 제공하고 있습니다.

[참고사진1: Stream Data의 구분]

Consumer group에서 어떻게 Kafka topic내의 partition data를 pull하는지와 만약 multi consumer에서 하나의 topic을 바라본다면 일반적으로 one consumer에 one topic을 구성해야 되는 지에 관련하여 설명을 들을 수 있었습니다.

각 분석 시간별 use cases, Kafka는 타 스트리밍 데이터 솔루션에 비해 디스크에 데이터를 써서 데이터가 영속성이 있으며, 일정 부분은 배치작업으로도 이용할 수 있습니다.

[참고사진2: MSK 기본아키텍처]

On-premise -> Amazon MSK  migration 방법론에 대해서는 MirrorMaker 2.0을 사용하여 migration 하는 방법에 대해 소개하였습니다. 방법은 아래와 같습니다.

      • Start MirrorMaker를 시작하고, Destination Cluster에 레플리케이션을 준비한다
      • 컨슈머와 미러메이커 컨슈머의 메시지를 받는지 확인한다
      • 프로듀서를 스탑한다
      • 컨슈머와 미러메이커 컨슈머의 메시지가 끊기는지 확인한다
      • 컨슈머 스탑
      • 컨슈머를 데스티네이션 클러스터로 설정하고, 최신 메시지를 컨슈밍을 시작트한다
      • 프로듀서를 데스티케이션 클러스터로 설정하고 메시지를 시작한다.
      • shutdown mirrorMaker

또한 K8S의 경우 POD에 fluentd daemonset과 kinesis 서비스를 통해서도 log analysis를 구현 가능합니다.

 

위와 같이 시스템에서 생성되는 데이터를 어떻게 가공처리 해야하는지 전반적으로 알 수 있었으나, 현재 시장에서 알려진 ELK Stack에 대해서는 언급이 없었던 부분이 아쉬웠습니다.