마이크로서비스, Apache Kafka 및 도메인 기반 설계

마이크로서비스는 DDD(Domain-Driven Design)와 공생 관계를 가지고 있습니다. 즉, 비즈니스 도메인이 소프트웨어에서 신중하게 모델링되고 시간이 지남에 따라 진화하는 설계 접근 방식으로, 시스템을 작동시키는 배관과는 별개입니다. ^{이 패턴이 Apache Kafka®} 와 함께 현장에서 점점 더 많이 나타나는 것을 봅니다.

이 프로젝트에서 마이크로서비스 아키텍처는 Kafka를 이벤트 스트리밍 플랫폼으로 사용합니다. 도메인 중심 설계는 애플리케이션이 수행해야 하는 다양한 비즈니스 프로세스를 나타내는 다양한 경계 컨텍스트를 정의하는 데 사용됩니다. 이들은 이벤트와 함께 결합되어 각 경계 컨텍스트를 다운스트림에서 발생하는 컨텍스트와 분리하는 단방향 종속성 그래프를 생성하여 풍부한 이벤트 스트리밍 비즈니스 애플리케이션을 생성합니다.

이 블로그 게시물에서는 Apache Kafka가 다른 기존 미들웨어를 대체할 뿐만 아니라 Kafka Streams, ksqlDB 및 Kafka Connect와 같은 Kafka 네이티브 API 및 DDD를 사용하여 마이크로서비스 자체를 구축하는 등 마이크로서비스 아키텍처의 사실상 표준이자 백본이 된 이유에 대해 설명합니다.

마이크로서비스

오늘날 다양한 맥락에서 사용되는 용어인 마이크로서비스 를 사용 하여 민첩하고 유연한 아키텍처를 만드는 것에 대해 모두 이야기하고 있습니다.

마이크로서비스는 무료 점심은 아니지만 디커플링을 비롯한 많은 이점을 제공합니다. 디커플링은 분산된 아키텍처를 형성하기 위해 비즈니스 기능을 중심으로 시스템을 구성하는 프로세스입니다. 스마트 엔드포인트 및 덤 파이프는 다음을 보장합니다.

마이크로서비스로 구축된 애플리케이션은 가능한 한 분리되고 응집력이 있는 것을 목표로 합니다. 자체 도메인 논리[비즈니스 문제의 해당 부분에 적용]를 소유하고 고전적인 Unix 의미에서 필터 역할을 더 많이 합니다(요청 수신, 논리 적용). 적절하고 응답을 생성합니다.마틴 파울러

Apache Kafka – 마이크로서비스용 이벤트 스트리밍 플랫폼

마이크로서비스 아키텍처를 구축하기 위해 어떤 기술을 사용해야 합니까? 이것은 두 부분으로 대답할 수 있습니다.

1. 마이크로서비스는 서로 어떻게 통신해야 합니까?

마이크로 서비스 통신을 고려할 때 대부분의 사람들이 시작하는 접근 방식은 REST, 즉 동기식 HTTP(S) 호출을 통한 통신입니다. 이것은 많은 사용 사례에서 잘 작동합니다. 그러나 요청-응답 패턴은 발신자와 수신자 및 수신자와 발신자를 모두 연결하는 지점간 연결을 생성하므로 다른 구성 요소에 영향을 주지 않고 한 구성 요소를 변경하기 어렵습니다.

이 때문에 많은 설계자는 미들웨어를 마이크로서비스 통신의 백본으로 사용하여 분리되고 확장 가능하며 가용성이 높은 시스템을 만듭니다. 미들웨어는 사용자 정의 글루 코드 또는 프레임워크, RabbitMQ와 같은 메시징 시스템, Talend와 같은 ETL 도구, WSO2와 같은 ESB 또는 Apache Kafka와 같은 이벤트 스트리밍 플랫폼 등 무엇이든 될 수 있습니다.

2. 어떤 미들웨어를 사용합니까(있는 경우)?

Apache Kafka가 마이크로서비스의 사실상 표준이 된 주된 이유는 다음과 같은 세 가지 강력한 개념의 조합 때문입니다.

1. 메시지 대기열 또는 엔터프라이즈 메시징 시스템과 유사한 이벤트 스트림 게시 및 구독
2. 내결함성 방식으로 이벤트 스트림 저장
3. 발생하는 이벤트 스트림을 실시간으로 처리

이러한 세 가지 기둥이 하나의 분산 이벤트 스트리밍 플랫폼에 구축되어 있어 다양한 마이크로서비스(예: 생산자 및 소비자)를 안정적이고 확장 가능하며 내결함성이 있는 방식으로 분리할 수 있습니다.

MQ, ETL 또는 ESB 도구와 같은 기존 미들웨어와 비교하여 Apache Kafka의 이점을 더 잘 이해하려면 Apache Kafka vs. Enterprise Service Bus – Friends, Enemies or Frenemies? 를 참조하세요.

이제 Apache Kafka와 같은 이벤트 스트리밍 플랫폼이 도메인 기반 설계와 어떻게 관련되어 있는지 이해해 보겠습니다.

마이크로서비스 구축 및 분리를 위한 DDD(Domain-Driven Design)

DDD(Domain-Driven Design)는 Eric Evans의 책에서 처음 만들어졌으며 복잡한 비즈니스 도메인이 있는 시스템을 구축하는 데 사용되는 접근 방식입니다. 따라서 DDD를 인프라 소프트웨어나 구축 라우터, 프록시 또는 캐싱 레이어에 적용하지 않고 대신 실제 비즈니스 문제를 해결하는 비즈니스 소프트웨어에 적용합니다. 비즈니스 모델링 방식을 비즈니스를 함께 묶는 배관 코드와 분리하는 훌륭한 기술입니다. 소프트웨어 자체에서 이 두 가지를 분리하면 시간이 지남에 따라 구현을 더 쉽게 설계, 모델링, 구축 및 발전시킬 수 있습니다.

DDD는 다음 전제에 구축됩니다.

• 도메인 전문가와의 상호 작용을 통해 도메인 측면에서 도메인 모델 캡처
• 코드에 도메인 용어 포함
• 다른 도메인, 기술 하위 도메인 등에 의한 손상으로부터 도메인 지식을 보호합니다.

이 논의에서 DDD의 주요 개념은 제한된 컨텍스트 입니다. 대규모 프로젝트에는 다양한 도메인 모델과 제한된 컨텍스트가 있는 경우가 많습니다. 그러나 서로 다른 경계 컨텍스트의 코드가 결합되면 소프트웨어가 버그가 있고 신뢰할 수 없으며 이해하기 어려울 수 있습니다. 팀 구성원 간의 의사 소통이 혼란스러워지고 어떤 맥락에서 모델을 적용하지 않아야 하는지 명확하지 않은 경우가 많습니다.

따라서 DDD는 모델이 적용되는 컨텍스트를 명시적으로 정의하도록 규정합니다. 우리는 해당 모델을 소유한 팀, 애플리케이션의 특정 부분 내에서의 사용, 코드 기반 및 데이터베이스 스키마와 같은 물리적 표현 측면에서 경계를 설정해야 합니다. 이러한 경계 내에서 모델을 엄격하게 일관되게 유지하면 단일 경계 컨텍스트에 대한 걱정만 필요하기 때문에 각 부분을 구현하고 이해하기가 더 간단해집니다. 우리는 다른 사람에게서 유출되었을 수 있는 코드로 인해 주의가 산만하거나 혼란스러워하지 않습니다. Dan North가 말했듯이: 머리에 맞는 코드를 작성하십시오 .

이벤트 스트리밍 플랫폼과 관련하여 다음과 같이 보일 수 있습니다.

여기에서 각 마이크로 서비스에는 고유한 경계 컨텍스트가 있습니다. 기술 관점에서 여기에는 다양한 API, 프레임워크, 통신 프로토콜 및 데이터 저장소가 포함될 수 있습니다. 일부는 요청-응답 패턴을 따르고 다른 일부는 해결해야 하는 문제에 따라 이벤트를 사용합니다. 그럼에도 불구하고 각각은 별도의 경계 컨텍스트가 되며 해당 모델, 비즈니스 프로세스 및 다른 사람과 공유하는 데이터 간에 별도의 도메인 모델과 매핑을 모두 갖습니다.

그렇다면 왜 Kafka가 적합할까요?

Apache Kafka 및 도메인 기반 마이크로서비스

Apache Kafka는 메시징과 스토리지를 결합하여 다양한 생산자와 소비자가 완전히 분리되도록 합니다.

• 서버 측(Kafka 브로커, ZooKeeper 및 Confluent Schema Registry)은 비즈니스 애플리케이션에서 분리될 수 있습니다.
• 생산자는 자신이 만든 이벤트를 누가 소비하는지 모르거나 신경 쓰지 않습니다. Kafka는 백프레셔, 확장성 및 고가용성을 처리합니다.
• 생산자는 소비자가 침체되어 있는 동안 생산할 수 있습니다.
• 새로운 소비자는 이전 타임스탬프에서 이벤트 소비를 시작해야 하는 경우에도 언제든지 추가할 수 있습니다.
• 소비자는 자신의 속도로 데이터를 처리할 수 있습니다(배치 또는 실시간).
• 소비자는 데이터를 계속해서 재처리할 수 있습니다(예: 다른 분석 모델을 훈련시키거나 오류 또는 데이터 손상으로부터 복구하기 위해).

이러한 특성을 통해 각 프로젝트 팀은 책임, SLA, 버전 관리 및 기술 선택을 포함하여 고유한 도메인을 소유합니다.

이는 비즈니스 애플리케이션뿐만 아니라 내부 셀프 서비스 제공을 위한 Kafka 클러스터를 소유한 회사 IT 팀 내 운영에도 적용될 수 있습니다. Kafka 클러스터 배포는 Kubernetes 및 Confluent Operator 와 같은 PaaS 인프라에서 실행되는 경우가 많습니다 . Confluent Cloud 와 같은 관리 서비스를 활용하는 클라우드 배포에서는 일반적으로 이러한 인프라 팀이 필요하지 않습니다.

도메인 모델, 제한된 컨텍스트 및 유비쿼터스 언어

위에서 논의한 바와 같이, 도메인 주도 설계(DDD)의 핵심 요소 중 하나는 비즈니스 문제를 독립적인 경계 컨텍스트의 모음으로 분리하는 것입니다. 각 컨텍스트에는 필요한 데이터, 수행해야 하는 비즈니스 운영 및 각각을 설명하는 데 사용되는 언어를 소프트웨어에서 완전히 캡슐화하는 도메인 모델이 있습니다. 그러나 한 경계 컨텍스트의 도메인 모델은 다른 컨텍스트의 도메인 모델과 어떤 관련이 있습니까? 한 모델의 변경이 다른 모델의 도메인 모델에 부정적인 영향을 미치지 않도록 하려면 어떻게 해야 합니까?

대답은 DDD가 부패 방지 계층이라고 부르는 것을 사용하는 것입니다. 도메인 모델에서 사용되는 데이터를 서로 다른 마이크로서비스 또는 서로 다른 경계 컨텍스트 간에 전송되는 데이터에 매핑하는 계층입니다. 이 패턴은 구현에 구애받지 않습니다. 즉, 서비스가 이벤트를 통해 또는 요청-응답 프로토콜을 통해 통신하는지 여부에 관계없이 사용할 수 있습니다. 두 경우 모두 일반적으로 유선 형식이 있습니다(REST 끝점에서 데이터를 반환하는 데 사용되는 스키마 또는 스키마 레지스트리 에 저장된 Avro 메시지와 같은 이벤트를 설명하는 데 사용되는 스키마 ).

반부패 계층에는 두 가지 목표가 있습니다.

1. 도메인 모델을 변경으로부터 보호합니다.
2. 이는 컨텍스트 간의 경계를 캡슐화하여 기술적인 의미(메시지의 필드 A가 모델의 필드 B에 매핑되지만 DDD의 유비쿼터스 언어 측면에서도)에서 이벤트 스키마 의 상대방 이 고객에게 매핑하는 방법을 설명합니다 . 도메인 모델

각 제한된 컨텍스트에서 모델의 진화를 위해 함께 결합하는 인터페이스는 팀이 거쳐야 하는 디자인 프로세스의 중요한 부분입니다. 이것은 항상 개발자가 단독으로 구축한 것이 아니라 시스템을 소유한 비즈니스 이해 관계자와 함께 개발되는 유비쿼터스 언어를 먼저 구축하여 수행해야 합니다.

Apache Kafka, Kafka Streams, ksqlDB 및 Kafka Connect를 사용하여 도메인 연결

아직 논의하지 않은 한 가지 중요한 사항이 있습니다. Apache Kafka는 단순한 메시징 시스템이나 통합 계층이 아니라 이벤트 스트리밍 플랫폼입니다. 즉, 마이크로서비스를 분리하는 미들웨어를 제공할 뿐만 아니라 클라이언트 코드에서 분할, 조인, 필터 및 요약과 같은 복잡한 데이터 작업을 수행할 수 있습니다. 다음은 ThinkWorks에서 설명하는 Apache Kafka와 기존 미들웨어 간의 또 다른 주요 차이점입니다.

...우리는 일부 조직 에서 커넥터 및 스트림 프로세서와 같은 Kafka 에코시스템 구성 요소를 제품 또는 서비스 팀과 함께 사용하도록 허용하는 대신 중앙 집중화하여 Kafka로 ESB 안티패턴을 재생성 하는 것을 보고 있습니다. 이것은 점점 더 많은 논리, 오케스트레이션 및 변환이 중앙 관리되는 ESB에 투입되어 중앙 집중식 팀에 상당한 종속성을 생성하는 심각한 문제가 있는 ESB 반패턴을 상기시킵니다. 우리는 이 결함이 있는 패턴의 추가 구현을 단념하기 위해 이것을 호출합니다.Kafka로 ESB 안티패턴 재생성

이 점이 중요합니다. ESB는 복잡한 논리, 오케스트레이션 및 변환을 일시적으로 통합한 것이 아니라 구축 중인 비즈니스 프로세스에 필요했기 때문에 통합되었습니다. ThinkWorks가 제기하는 문제는 이러한 프로세스가 어떤 식으로든 어렵거나 불필요하다는 것이 아니라, 프로세스를 소유해야 하는 응용 프로그램의 범위를 벗어나 중앙 집중식 인프라로 밀어넣었다는 것입니다. 이러한 중앙 집중식 인프라와 중앙 집중식 비즈니스 논리로 인해 현대적이고 민첩한 소프트웨어 프로젝트에서 원하지 않는 모든 것이 진화하기 어려운 취약한 소프트웨어가 되었습니다.

이벤트 스트리밍 시스템은 다른 방식으로 이에 접근합니다. 그들은 벙어리(그러나 확장성이 뛰어난) 파이프와 스마트 필터로 구축되었지만 가장 주목할 만한 것은 필터가 이전보다 훨씬 강력하고 기능적이라는 것입니다. 마이크로 서비스에 내장된 필터는 최신 스트림 처리 엔진의 모든 기능을 갖추고 있습니다. 중앙 집중식 논리가 없습니다. 모든 것이 완전히 분산되어 있습니다. 즉, 경계가 지정된 각 컨텍스트는 고유한 비즈니스 로직, 오케스트레이션, 변환 등을 소유합니다.

따라서 Kafka를 중추 신경계로 사용하면 스트리밍 처리 도구에서 제공하는 더 높은 추상화를 사용하여 서로 다른 경계 컨텍스트에서 생성된 모델을 매핑할 수 있습니다.

이를 통해 DDD와 함께 제공되는 모든 좋은 기능을 활용할 수 있지만 ESB에서 발생하는 번거로움 없이 전체 비즈니스 프로세스의 긴밀하게 연결된 중앙 집중식 관리가 가능합니다.

각 마이크로서비스를 구현하기로 선택하는 방법은 전적으로 작업을 수행하는 팀에 달려 있습니다. 마이크로 서비스는 통신만 중재하는 REST 또는 JMS와 같은 간단한 기술 인터페이스를 사용하도록 선택할 수 있습니다. 대안으로, 데이터의 이벤트 스트림을 조작하고 내부 모델에 매핑하기 위해 후드 아래에서 스트림 처리의 전체 기능을 활용하는 실제 이벤트 스트리밍 마이크로서비스를 구축할 수 있습니다.

위의 예에는 다양한 마이크로서비스가 있습니다. 일부는 REST를 사용(예: 마이크로서비스와 UI 간 통신)하고 일부는 Kafka Streams 또는 ksqlDB를 사용하여 서로 다른 소스의 이벤트를 함께 조인합니다. 다른 사람들은 Kafka Connect를 사용하여 이벤트를 추가로 조작하거나 이벤트 소싱 패턴 을 통해 직접 사용할 수 있는 데이터베이스로 이벤트를 푸시합니다 . 이 기술 구현은 다른 마이크로 서비스 및 사용 기술에 관계없이 각 마이크로 서비스에 대해 수행할 수 있습니다.

이와 같은 시스템을 구축하는 방법

REST, gRPC 또는 기타 요청-응답 프로토콜을 사용하여 분리된 이벤트 스트리밍 마이크로서비스를 구축하는 것은 다소 명백합니다. 그러나 많은 사람들에게 이벤트가 있는 시스템을 구축하려면 더 큰 개념적 도약이 필요합니다. 이벤트는 다양한 방식으로 시스템을 구축하는 데 사용할 수 있습니다. 그들은 화재 및 잊어 버린 메시징으로 사용할 수 있지만 공동 작업을 위한 수단으로도 사용할 수 있습니다. Ben Stopford의 블로그 게시물 Build Services on Backbone of Events 는 이러한 패턴에 대해 더 자세히 설명합니다.

또한 상태를 관리하는 방법도 선택해야 합니다. 이것은 Kafka Connect와 같은 기술을 사용하거나 Kafka Streams API를 사용하는 관리형 서비스를 사용하여 데이터베이스에서 수행할 수 있습니다. 상태 저장 이벤트 스트리밍 마이크로서비스 구축에 대한 자세한 내용은 Ben Stopford의 블로그 게시물 Building a Microservices Ecosystem with Kafka Streams and ksqlDB 에서 찾을 수 있습니다 .

Connect, Kafka Streams 및 마이크로서비스가 어떻게 결합되는지에 대한 보다 포괄적인 보기를 위해 플레이 상태를 요약한 Yeva Byzek 의 훌륭한 게시물 이 있습니다. 마지막으로 마이크로서비스 생태계를 구축하는 것은 퍼즐의 첫 번째 부분일 뿐입니다. 일단 구축되면 계측, 제어 및 작동해야 합니다. 여기 에서 방법을 알아 보세요 .

Confluent 플랫폼 전체에서 역할 기반 액세스 제어를 허용하는 Confluent의 RBAC 기능도 언급할 가치가 있습니다. 각 도메인 팀이 액세스할 수 있는 리소스(예: Kafka 주제, 스키마 레지스트리 또는 커넥터)를 자세히 구성할 수 있습니다.

가장 적합한 아키텍처를 선택하기만 하면 됩니다. 예를 들어 각 Kafka Connect 클러스터를 담당 도메인 팀이 운영하도록 하거나 Kafka Connect를 Kafka 클러스터의 일부로 호스트하고 팀이 커넥터를 배포하도록 허용할 수 있습니다.

DDD 기술을 사용하여 마이크로 서비스 기반 시스템을 구축하고 실행하기 위한 이 풍부한 도구가 도움이 되기를 바랍니다.

Apache Kafka + 도메인 기반 설계(DDD) = 분리된 이벤트 스트리밍 마이크로서비스

마이크로서비스 아키텍처를 구성하는 방법에는 여러 가지가 있지만 DDD(도메인 중심 설계)에 설명된 기술은 의심할 여지 없이 가장 강력한 기술 중 일부입니다. 특히 복잡한 비즈니스 도메인(예: 의료, 금융, 보험, 소매).

DDD에서 찾을 수 있는 많은 설계 원칙은 이 게시물의 범위를 벗어나는 몇 가지를 포함하여 이벤트 기반 시스템에 직접 적용할 수 있지만 가장 일반적인 기술 문제를 강조했습니다. 애플리케이션을 제한된 컨텍스트로 분리하는 방법, 왜 이러한 별도의 컨텍스트가 중요하고 도메인 모델이 필요한 이유, 이것이 메시징, Apache Kafka 및 이벤트 사용과 어떻게 관련되는지.

오늘날 사용할 수 있는 풍부한 도구 세트를 통해 마이크로 서비스 아키텍처는 이벤트 스트리밍 플랫폼을 사용하여 각 마이크로 서비스를 다음 마이크로 서비스와 분리함으로써 많은 이점을 얻을 수 있습니다. 구현은 전체 이벤트 스트리밍 비즈니스 애플리케이션에 대한 요청 기반의 단순한 이벤트 기반 시스템일 수 있습니다. 그들은 또한 이러한 다양한 패턴을 혼합할 수 있습니다. DDD는 유비쿼터스 언어, 경계 컨텍스트, 스키마 및 부패 방지 계층과 같은 각 부분 간의 상호 작용을 관리하는 데 필수적인 기술을 제공합니다. 우리가 보았듯이 이벤트와 메시징은 이러한 시스템이 실제로 잘 작동하도록 하는 핵심 요소를 제공합니다.

https://www.confluent.io/blog/microservices-apache-kafka-domain-driven-design/