Apache Kafka를 사용한 데이터 스트림

완료됨

Apache Kafka는 2010년 LinkedIn에서 큰 규모의 데이터를 높은 내결함성 수준에서 매우 낮은 대기 시간으로 이동시키고자 만들어졌습니다. 이후 2012년에 LinkedIn은 해당 프로젝트를 Apache Foundation에 기부하였으나 여전히 에코시스템 전반에서 사용자 활동 추적, 메시지 교환 및 메트릭 수집을 위해 Kafka를 사용합니다.

Kafka은 다음을 위해 설계된 분산형 스트리밍 플랫폼입니다.

• 데이터 파이프라인 간소화
• 스트리밍 패턴의 대량 데이터 처리
• 실시간 및 일괄 처리 시스템 지원
• 수평적 대규모 스케일링

먼저 Apache Kafka에 대해서 살펴본 뒤 Azure HDInsight에서의 Kafka에 대해 알아보겠습니다.

Kafka 구성 요소

Kafka의 작동 방식을 알아보기 전에 Kafka의 주요 구성 요소의 역할과 해당 요소들이 어떤 방식으로 결합하여 뛰어난 성능의 스케일링과 내결함성을 갖춘 메시지 시스템을 제공하는지 알아보겠습니다.

브로커

Kafka는 클러스터형 서비스이며 단일 Kafka 클러스터는 broker라고도 합니다. broker는 생산자로부터 메시지를 수신하고 이러한 메시지를 디스크에 저장합니다. 또한 broker는 소비자의 페치 요청에 대응합니다. broker의 클러스터 내에서 하나의 broker가 컨트롤러 역할을 하며 관리 작업을 담당하고 broker에 파티션을 할당합니다.

메시지

Kafka 클러스터의 데이터 단위입니다. 대부분의 인스턴스에 있는 메시지는 키 값 쌍입니다.

토픽 및 파티션

토픽 및 파티션은 Kafka의 메시지 범주입니다. 토픽은 일반적으로 개선해야 할 여러 파티션으로 나뉘며 권장 파티션은 최소 3개입니다. 메시지는 추가만 가능한 방식으로 토픽 파티션에 기록됩니다. 파티션이 여러 broker에 추가로 복제되므로 broker 오류 시 중복성이 개선됩니다. 파티션은 여러 broker 간에 데이터를 분할할 수 있도록 하기 때문에 토픽을 병렬로 읽게 할 수 있습니다. 모든 읽기-쓰기 요청을 처리하는 리더 복제본이 있고 팔로워는 리더에서 복제됩니다. 리더가 실패한 경우 복제본 중 하나가 리더가 됩니다.

생산자 및 소비자

생산자와 소비자는 Kafka 시스템에서 메시지를 생성하고 사용하는 클라이언트입니다. 생산자는 새 메시지를 게시하고 특정 토픽으로 보냅니다. 또한 소비자는 특정 토픽 파티션에 쓰도록 설계될 수 있습니다. 그러면 소비자는 하나 이상의 토픽을 구독하고 해당 토픽에서 메시지를 읽습니다.

소비자 그룹

하나 이상의 소비자가 그룹으로 함께 작업하고 메시지를 그룹으로 사용할 수 있습니다. 소비자 수가 토픽 파티션의 수와 같으면 각 소비자는 단일 토픽 파티션에서 소비하여 병렬 처리를 생성합니다.

보존

Kafka의 메시지는 미리 정의된 기간 동안 Kafka 클러스터에 지속적으로 보존될 수 있습니다. 보존 한도에 도달하면 Kafka는 해당 메시지를 만료시키고 삭제할 수 있습니다.

상쇄

오프셋은 단순히 파티션에서 메시지의 위치입니다. 메시지가 처리되는 동안 파티션에서 현재 위치를 업데이트 하는 것을 커밋이라고 합니다. 메시지를 처리한 후 Kafka는 메시지의 오프셋을 특수 내부 Kafka 토픽으로 커밋합니다. 생산자가 파티션에 메시지를 게시하면 리더에게 전달됩니다. 리더가 커밋 로그에 메시지를 추가하고 메시지 오프셋을 증가 시킵니다. 메시지 오프셋은 토픽 내에서 메시지를 식별하는 방법입니다. 메시지가 클러스터로 커밋된 후에만 소비자가 메시지를 사용할 수 있습니다.

Zookeeper

Zookeeper는 조정 서비스이며 Kafka 클러스터에서 Zookeeper는 클러스터 상태의 동기화된 보기를 제공합니다. Kafka은 Zookeeper를 사용하여 Broker 및 토픽 파티션 간의 리더를 선정합니다. Kafka은 Zookeeper를 사용하여 클러스터를 구성하는 Kafka Broker를 위한 서비스 검색을 관리합니다. Zookeeper는 토폴로지의 변경 내용을 Kafka로 보냅니다. 따라서 클러스터의 각 노드는 새 Broker의 조인 및 종료, 토픽의 제거 또는 추가 시기를 알 수 있습니다.

이를 통해 어떤 결과가 나타날까요?

애플리케이션(생산자라고도 함)은 Kafka broker에 메시지를 보내며 이러한 메시지는 하나 이상의 소비자에 의해 처리됩니다. 클러스터의 메시지는 토픽별로 분류됩니다. 예를 들어 고객이 판매 등과 관련된 모든 메시지를 보내는 “판매” 토픽을 만들 수 있습니다. 토픽이 메시지의 증가와 함께 증가함에 따라 파티션으로 분할되고 이러한 파티션은 중복성을 위해 Kafka Broker에 추가로 복제됩니다. 파티션은 리더와 팔로워로 분류됩니다. 리더 파티션은 작성되고 읽히지만 팔로워 파티션은 리더의 상태를 따라잡는 단순한 복제본입니다. 어떤 파티션을 읽고 쓸지 결정하기 위해서 생산자와 소비자는 어떤 파티션이 리더로 설계되었지 알아야 합니다. Zookeeper 노드는 Kafka 클러스터의 상태를 관리하고, 무엇보다 파티션 리더를 선정하여 해당 정보를 소비자에게 제공합니다.
Kafka는 파티션이 있는 메시지가 들어온 순서대로 정렬되도록 보장합니다. 특정 메시지는 파티션 내에서의 위치인 오프셋을 통해 명확하게 식별할 수 있습니다. 소비자는 파티션에서 메시지를 읽고 처리 후에는 메시지가 성공적으로 처리되었음을 나타내는 오프셋을 커밋합니다. Kafka는 모든 레코드를 디스크에 저장하고 메시지 지속성을 유지합니다. 소비자가 방해를 받아 프로세스가 중지되는 경우 Kafka는 미리 정해진 보존 기간 동안 메시지를 보존하고 다시 온라인으로 전환되면 중단 전 상태에서 커밋된 오프셋에서 프로세스를 다시 시작할 수 있습니다.

Kafka 토픽

Kafka 토픽은 메시지를 저장하고 게시하는 피드 또는 큐입니다. 생산자는 토픽에 메시지를 푸시하고, 소비자는 토픽에서 메시지를 읽습니다. Kafka Broker의 각 노드에는 여러 토픽이 포함될 수 있습니다.

Azure HDInsight에서 Kafka를 사용하는 이점은 무엇인가요?

오픈 소스 버전의 Kafka는 다양한 기능을 제공하지만 이를 설정하는 데 많은 작업을 수행해야 합니다. Azure HDInsight는 Azure에 최고의 오픈 소스 분석 프레임 워크를 제공하고, 고객은 몇 주 또는 몇 달이 아닌 몇 분 내로 오픈 소스 클러스터를 쉽게 설치하고 곧바로 사용할 수 있습니다. HDInsight는 다음과 같은 이점을 제공하는 엔터프라이즈이기도 합니다.

• 단순화된 구성 프로세스를 제공하는 관리되는 서비스입니다. Microsoft에서는 테스트를 거쳐 해당 구성을 지원합니다.
• Microsoft는 Spark 및 Kafka 작동 시간에 99.9%의 Service Level Agreement(서비스 수준 약정)(SLA)를 제공 합니다.
• Azure Managed Disks를 Kafka에 대한 백업 저장소로 사용합니다. Managed Disks는 여러 Kafka Broker와 함께 Kafka Broker 당 최대 16TB의 스토리지를 제공할 수 있습니다.
• HDInsight는 VNet을 통한 최고의 엔터프라이즈 보안, Apache Ranger를 통한 세분화된 보안, 그리고 미사용 데이터에 대한 Bring Your Own Key(BYOK) 암호화를 제공합니다.
• HIPAA, SOC 및 PCI 준수
• 동일한 VNet의 자동 ARM(Azure Resource Manager) 템플릿을 통해 Spark 및 Storage를 사용하여 엔드투엔드 스트리밍 파이프라인을 배포할 수 있습니다.
• 기본 클러스터의 토픽에서 레코드를 사용하고 보조 클러스터에 로컬 복사본을 만들 수 있는 Kafka MirrorMaker를 사용하 여 고가용성을 달성할 수 있습니다.
• HDInsight를 통해 클러스터를 만든 후 작업자 노드 수(Kafka-브로커를 호스트하는)를 변경할 수 있습니다. 크기 조정은 Azure Portal, Azure PowerShell 및 기타 Azure 관리 인터페이스에서 수행할 수 있습니다. Kafka의 경우 크기 조정 작업 후 파티션 복제본의 균형을 다시 조정해야 합니다. 파티션 균형을 다시 조정하면 Kafka가 새 작업자 노드 수를 활용할 수 있습니다.
• Azure Monitor 로그를 사용하여 HDInsight에서 Kafka를 모니터링할 수 있습니다. Azure Monitor 로그는 디스크 및 NIC 메트릭과 같은 가상 머신 수준의 정보와 Kafka의 JMX 메트릭을 표시합니다.