처리뿐만 아니라: Kafka Streams에서 분산 데이터베이스를 만든 방법과 그 결과

헤이 하브르!

우리는 다음에 관한 책을 다음과 같이 상기시킵니다. 카프카 우리는 도서관에 관한 똑같이 흥미로운 작품을 출판했습니다. 카프카 스트림 API.

현재 커뮤니티는 이 강력한 도구의 한계를 배우고 있습니다. 그래서 최근에 기사가 출판되었는데, 그 번역본을 여러분께 소개하고 싶습니다. 저자는 자신의 경험을 바탕으로 Kafka Streams를 분산 데이터 저장소로 전환하는 방법을 알려줍니다. 즐겁게 읽으세요!

아파치 라이브러리 카프카 스트림 Apache Kafka 기반의 분산 스트림 처리를 위해 전 세계 기업에서 사용됩니다. 이 프레임워크에서 과소평가된 측면 중 하나는 스레드 처리를 기반으로 생성된 로컬 상태를 저장할 수 있다는 것입니다.

이 기사에서는 우리 회사가 클라우드 애플리케이션 보안용 제품을 개발할 때 이 기회를 어떻게 수익성 있게 활용했는지 설명하겠습니다. Kafka Streams를 사용하여 우리는 공유 상태 마이크로서비스를 만들었습니다. 각 마이크로서비스는 시스템의 개체 상태에 대한 신뢰할 수 있는 정보의 내결함성과 가용성이 높은 소스 역할을 합니다. 우리에게 이는 신뢰성과 지원 용이성 측면에서 한 단계 더 발전한 것입니다.

단일 중앙 데이터베이스를 사용하여 개체의 형식적 상태를 지원하는 대체 접근 방식에 관심이 있다면 읽어 보십시오. 흥미로울 것입니다.

공유 상태로 작업하는 방식을 바꿔야 할 때라고 생각한 이유

에이전트 보고서(예: 사이트가 공격을 받았는지)를 기반으로 다양한 개체의 상태를 유지해야 합니까? Kafka Streams로 마이그레이션하기 전에는 상태 관리를 위해 단일 중앙 데이터베이스(+ 서비스 API)에 의존하는 경우가 많았습니다. 이 접근 방식에는 단점이 있습니다. 날짜 집중적 상황 일관성과 동기화를 유지하는 것은 정말 어려운 일이 됩니다. 데이터베이스에 병목 현상이 발생하거나 종료될 수 있습니다. 경쟁 조건 그리고 예측불가능성에 시달립니다.

그림 1: 전환 전의 일반적인 분할 상태 시나리오
Kafka 및 Kafka Streams: 에이전트는 API를 통해 뷰를 전달하고 업데이트된 상태는 중앙 데이터베이스를 통해 계산됩니다.

공유 상태 마이크로서비스를 쉽게 생성할 수 있는 Kafka Streams를 만나보세요

약 XNUMX년 전, 우리는 이러한 문제를 해결하기 위해 공유 상태 시나리오를 자세히 살펴보기로 결정했습니다. 우리는 즉시 Kafka Streams를 사용해 보기로 결정했습니다. Kafka Streams가 얼마나 확장 가능하고 가용성이 높으며 내결함성이 있는지, 풍부한 스트리밍 기능(상태 저장 기능을 포함한 변환)이 무엇인지 알고 있습니다. Kafka의 메시징 시스템이 얼마나 성숙하고 안정적이었는지는 말할 것도 없고 우리에게 꼭 필요한 것입니다.

우리가 만든 각 상태 저장 마이크로서비스는 매우 간단한 토폴로지를 사용하는 Kafka Streams 인스턴스 위에 구축되었습니다. 이는 1) 소스 2) 영구 키-값 저장소가 있는 프로세서 3) 싱크로 구성됩니다.

그림 2: 상태 저장 마이크로서비스를 위한 스트리밍 인스턴스의 기본 토폴로지. 여기에는 계획 메타데이터가 포함된 저장소도 있습니다.

이 새로운 접근 방식에서 에이전트는 소스 주제에 제공되는 메시지를 작성하고 소비자(예: 메일 알림 서비스)는 싱크(출력 주제)를 통해 계산된 공유 상태를 수신합니다.

그림 3: 공유 마이크로서비스가 포함된 시나리오에 대한 새로운 예제 작업 흐름: 1) 에이전트는 Kafka 소스 주제에 도착하는 메시지를 생성합니다. 2) 공유 상태가 있는 마이크로서비스(Kafka Streams 사용)가 이를 처리하고 계산된 상태를 최종 Kafka 주제에 씁니다. 그 후 3) 소비자는 새로운 상태를 받아들입니다.

이 내장된 키-값 저장소는 실제로 매우 유용합니다!

위에서 언급했듯이 공유 상태 토폴로지에는 키-값 저장소가 포함되어 있습니다. 우리는 이를 사용하기 위한 몇 가지 옵션을 찾았으며 그 중 두 가지가 아래에 설명되어 있습니다.

옵션 #1: 계산에 키-값 저장소 사용

첫 번째 키-값 저장소에는 계산에 필요한 보조 데이터가 포함되어 있습니다. 예를 들어, 공유 상태가 "과반수 투표" 원칙에 따라 결정되는 경우도 있습니다. 저장소는 일부 개체의 상태에 대한 모든 최신 에이전트 보고서를 보유할 수 있습니다. 그런 다음 한 에이전트 또는 다른 에이전트로부터 새 보고서를 받으면 이를 저장하고 스토리지에서 동일한 개체의 상태에 대한 다른 모든 에이전트의 보고서를 검색하고 계산을 반복할 수 있습니다.
아래 그림 4는 새 메시지를 처리할 수 있도록 키/값 저장소를 프로세서의 처리 메서드에 노출하는 방법을 보여줍니다.

그림 4: 프로세서의 처리 방법에 대한 키-값 저장소에 대한 액세스를 엽니다(이후 공유 상태로 작동하는 모든 스크립트는 해당 방법을 구현해야 함) doProcess)

옵션 #2: Kafka Streams 위에 CRUD API 생성

기본 작업 흐름을 설정한 후 공유 상태 마이크로서비스를 위한 RESTful CRUD API를 작성하기 시작했습니다. 우리는 일부 또는 모든 객체의 상태를 검색할 수 있을 뿐만 아니라 객체의 상태를 설정하거나 제거할 수 있기를 원했습니다(백엔드 지원에 유용함).

모든 상태 가져오기 API를 지원하기 위해 처리 중에 상태를 다시 계산해야 할 때마다 이를 내장된 키-값 저장소에 오랫동안 저장했습니다. 이 경우 아래 목록에 표시된 것처럼 Kafka Streams의 단일 인스턴스를 사용하여 이러한 API를 구현하는 것이 매우 간단해집니다.

그림 5: 내장된 키-값 저장소를 사용하여 객체의 미리 계산된 상태 얻기

API를 통해 객체의 상태를 업데이트하는 것도 구현하기 쉽습니다. 기본적으로 Kafka 생산자를 생성하고 이를 사용하여 새 상태가 포함된 레코드를 만들기만 하면 됩니다. 이렇게 하면 API를 통해 생성된 모든 메시지가 다른 생산자(예: 에이전트)로부터 수신된 메시지와 동일한 방식으로 처리됩니다.

그림 6: Kafka 생산자를 사용하여 객체의 상태를 설정할 수 있습니다.

작은 복잡성: Kafka에는 많은 파티션이 있습니다.

다음으로 우리는 시나리오별로 공유 상태 마이크로서비스 클러스터를 제공하여 처리 로드를 분산하고 가용성을 향상시키고 싶었습니다. 설정은 매우 간편했습니다. 동일한 애플리케이션 ID(및 동일한 부트스트랩 서버)에서 실행되도록 모든 인스턴스를 구성한 후에는 거의 모든 작업이 자동으로 수행되었습니다. 또한 각 소스 주제가 여러 파티션으로 구성되도록 지정하여 각 인스턴스에 해당 파티션의 하위 집합을 할당할 수 있었습니다.

또한 예를 들어 장애 후 복구 시 이 복사본을 다른 인스턴스로 전송할 수 있도록 상태 저장소의 백업 복사본을 만드는 것이 일반적인 관행이라는 점도 언급하겠습니다. Kafka Streams의 각 상태 저장소에 대해 복제된 주제는 변경 로그(로컬 업데이트를 추적함)와 함께 생성됩니다. 따라서 Kafka는 상태 저장소를 지속적으로 백업합니다. 따라서 하나 또는 다른 Kafka Streams 인스턴스에 오류가 발생하는 경우 해당 파티션이 이동되는 다른 인스턴스에서 상태 저장소를 신속하게 복원할 수 있습니다. 우리의 테스트에 따르면 저장소에 수백만 개의 레코드가 있더라도 이 작업은 몇 초 안에 완료되는 것으로 나타났습니다.

상태를 공유하는 단일 마이크로서비스에서 마이크로서비스 클러스터로 이동하면 상태 가져오기 API를 구현하는 것이 덜 간단해집니다. 새로운 상황에서 각 마이크로서비스의 상태 저장소에는 전체 그림(키가 특정 파티션에 매핑된 개체)의 일부만 포함됩니다. 우리는 필요한 개체의 상태가 포함된 인스턴스를 결정해야 했고, 아래와 같이 스레드 메타데이터를 기반으로 이를 수행했습니다.

그림 7: 스트림 메타데이터를 사용하여 원하는 객체의 상태를 쿼리할 인스턴스를 결정합니다. GET ALL API에도 유사한 접근 방식이 사용되었습니다.

주요 결과

Kafka Streams의 상태 저장소는 사실상 분산 데이터베이스 역할을 할 수 있습니다.

• Kafka에서 지속적으로 복제됨
• CRUD API는 이러한 시스템 위에 쉽게 구축될 수 있습니다.
• 여러 파티션을 처리하는 것이 조금 더 복잡합니다.
• 보조 데이터를 저장하기 위해 스트리밍 토폴로지에 하나 이상의 상태 저장소를 추가하는 것도 가능합니다. 이 옵션은 다음 용도로 사용할 수 있습니다.
• 스트림 처리 중 계산에 필요한 데이터의 장기 저장
• 다음에 스트리밍 인스턴스가 프로비저닝될 때 유용할 수 있는 데이터의 장기 저장
• 훨씬 더...

이러한 장점과 기타 장점으로 인해 Kafka Streams는 우리와 같은 분산 시스템에서 전역 상태를 유지하는 데 매우 적합합니다. Kafka Streams는 프로덕션 환경에서 매우 안정적인 것으로 입증되었으며(배포한 이후로 메시지 손실이 거의 없었습니다) Kafka Streams의 기능은 여기서 끝나지 않을 것이라고 확신합니다!

출처 : habr.com