Apache Kafka와 요청-응답 통신

1. Apache Kafka와 요청-응답 통신

출처

• 메시지 교환 패턴을 사용하는 경우(사용하지 않는 경우)

• 동기 및 비동기 통신의 차이점

• CQRS 및 이벤트 소싱과 비교한 장단점

• 데이터 스트리밍 인프라 내에서 요청-응답을 구현하는 방법

2. 요청-응답(Request-Response) 메시지 교환 패턴이란?

• 요청-응답은 컴퓨터 가 네트워크에서 서로 통신하는 데 사용하는 기본 방법 중 하나입니다.

  1. 첫 번째 응용 프로그램은 일부 데이터에 대한 요청을 보냅니다.

  2. 두 번째 응용 프로그램은 요청에 응답합니다 .

• 요청자가 요청 메시지를 응답 시스템으로 보내고 응답 시스템은 요청을 수신하여 처리하여 궁극적으로 응답으로 메시지를 반환하는 메시지 교환 패턴 입니다.

• 요청-응답은 비효율적이며 사용 사례에 따라 많은 지연이 발생할 수 있습니다 . HTTP 또는 더 나은 gRPC는 일부 사용 사례에 적합합니다.

• 요청-응답 은 스트리밍 데이터용 Kafka로 CQRS( 명령 및 쿼리 책임 분리) 패턴으로 "대체"됩니다 .

  • JMS는 상태 기능을 제공하지 않고 이벤트 소싱 기능이 없기 때문에 CQRS는 JMS API에서 불가능합니다.

3. 요청-응답(HTTP) vs 데이터 스트리밍(Kafka)

• 요청-응답(HTTP)

  • 일반적으로 동기식

  • 포인트 투 포인트

  • 높은 대기 시간(데이터 스트리밍에 비해)

  • 사전 정의된 API

• 데이터 스트리밍(카프카)

  • 연속 처리

  • 종종 비동기식

  • 이벤트 기반

  • 짧은 대기 시간

  • 범용 이벤트

• 대부분의 아키텍처는 점대점 통신 (예: 서버와 모바일 앱 간) 을 위한 요청-응답 과 지속적인 데이터 처리를 위한 데이터 스트리밍이 필요합니다.

이를 염두에 두고 HTTP가 Kafka와 함께 사용되는 사용 사례를 살펴보겠습니다.

4. 동기 통신 대 비동기 통신

• 요청 - 응답 메시지 교환 패턴은 종종 순전히 동기적으로 구현 됩니다.

  • 그러나 요청-응답 은 비동기식으로 구현될 수도 있으며 응답은 알 수 없는 나중 시간에 반환됩니다.

• REST, 메시지 큐, 데이터 스트리밍과 같은 메시지 교환의 가장 일반적인 예를 살펴보겠습니다.

동기식 Restful API(HTTP)

• 웹 서비스는 애플리케이션 개발 및 엔터프라이즈 애플리케이션 통합에서 동기 통신의 기본 기술입니다.

  • 수년 전에는 WSDL과 SOAP가 지배적이었지만 REST/HTTP는 오늘날 거의 모든 웹 서비스의 통신 표준입니다.

    REST와 SOAP는 각기 다른 두 가지의 온라인 데이터 전송 방식입니다.
    둘 다 웹 애플리케이션 간 데이터 통신을 허용하는 애플리케이션 프로그래밍 인터페이스(Application Programming Interface, API)를 구축하는 방법을 정의합니다.

    • REST(Representational State Transfer)는 아키텍처 원칙 세트
    • SOAP(Simple Object Access Protocol)는 World Wide Web Consortium(W3C)에서 유지관리하는 공식 프로토콜입니다.
      • 즉, SOAP는 프로토콜이지만, REST는 프로토콜이 아니라는 점이 주요 차이점
        출처

  
  

• REST(Representational state transfer)는 소프트웨어 산업 전반에 걸쳐 채택되어 왔으며 안정적인 상태 비저장 웹 API를 생성하기 위해 널리 인정되는 일련의 지침입니다.

  • REST 제약 조건을 준수하는 웹 API는 비공식적으로 RESTful로 설명됩니다.

  • RESTful 웹 API는 일반적으로 HTTP 메서드를 기반으로 합니다.

• HTTP를 통한 동기 웹 서비스 호출은 연결을 열린 상태로 유지하고 응답이 전달되거나 제한 시간이 만료될 때까지 기다립니다.

  • HTTP 웹 서비스의 대기 시간은 상대적으로 높습니다.

  • HTTP를 사용할 때 각 요청-응답 반복에 대해 TCP 연결을 설정하고 해제해야 합니다.

  • 명확하게 말하면 대기 시간은 여전히 많은 사용 사례에 충분합니다.

• 단점은 HTTP 요청이 대기열 요청의 헤드가 처리되기를 기다리는 것을 차단할 수 있고 미해결 HTTP 요청이 너무 많은 경우 서버에 HTTP 회로 차단기를 설정해야 할 수 있다는 것입니다.

비동기식 메시지 큐(IBM MQ, RabbitMQ)

• 메시지 대기열 패러다임은 게시자/가입자 디자인 패턴의 형제이며 일반적으로 보다 광범위한 메시지 지향 미들웨어 시스템의 한 부분입니다.

  • 대부분의 메시징 시스템은 API(예: JMS)에서 게시자/가입자 및 메시지 대기열 모델을 모두 지원합니다.

• 생산자와 소비자는 서로 분리되어 비동기식으로 통신합니다.

  • 메시지 대기열은 성공적으로 소비될 때까지 이벤트를 저장합니다.

  • 대부분의 메시지 대기열 미들웨어 제품은 기본 제공 요청-응답 API를 제공 합니다.

    • 통신은 비동기식 입니다.

    • 구현에서는 상관 관계 ID를 사용합니다.

• 요청-응답 API(예: JMS)는 요청에서 응답 대상 엔드포인트를 가져와 소비자가 사용할 요청에서 참조되는 임시 대기열 또는 주제를 생성합니다.

  • ID는 단일 요청자와 요청을 구분하는 데 사용됩니다.

  • 이러한 대기열 또는 주제는 요청자가 응답에 대한 세션과 함께 활성 상태인 동안에만 사용할 수 있습니다.

임시 대기열이나 이러한 구현은 Kafka에서 의미가 없습니다.
Kafka는 그런 식으로 작동하지 않습니다. 그 결과 Kafka 클러스터에 너무 많은 파티션과 주제가 있었습니다. 확장성과 성능 문제가 그 결과였습니다.

비동기 데이터 스트리밍(Apache Kafka)

• 데이터 스트리밍은 데이터 소스에서 수집된 이벤트를 지속적으로 처리합니다.

  • 이러한 데이터는 모든 데이터에 액세스하지 않고도 스트림 처리 기술을 사용하여 점진적으로 처리해야 합니다.

• 비동기 통신 패러다임은 메시지 대기열과 같습니다.

  • 메시지 대기열과 달리 데이터 스트리밍은 이벤트의 장기 저장과 기록 정보의 재생성을 제공 합니다.

  • 그 결과 생산자와 소비자 사이의 진정한 분리가 이루어집니다.

• 대부분의 Apache Kafka 배포에서 통신 패러다임과 대기 시간 기능이 매우 다른 여러 생산자와 소비자가 이벤트를 보내고 읽습니다.

  • Apache Kafka는 기본 제공 요청-응답 API를 제공하지 않습니다.

    • 일부 사람들이 생각하는 것처럼 이것이 반드시 나쁜 것은 아닙니다. 데이터 스트리밍은 다양한 디자인 패턴을 제공합니다. 메시징 시스템에서 요청-응답 패턴의 절충점을 살펴보고 데이터 스트리밍 세계에 더 적합한 대체 접근 방식을 이해해 보겠습니다.

    이 게시물에서는 Kafka를 사용하여 비동기식 또는 동기식 요청-응답을 구현하는 방법도 살펴봅니다 .

5. 요청-응답 대 CQRS 및 이벤트 소싱

• CQRS(Command and Query Responsibility Segregation, 명령과 조회의 책임 분리) 에 따르면 모든 메서드는 작업을 수행하는 명령이나 호출자에게 데이터를 반환하는 쿼리 중 하나여야 합니다

  • 서비스는 서로 분리됩니다.

• 이벤트 소싱

  • 엔터티가 직접 직렬화 또는 개체 관계형 매핑을 사용하여 내부 상태를 추적하지 않고 이벤트를 읽고 이벤트 저장소에 커밋 하는 아키텍처 패턴입니다.

  • 이벤트 소싱이 CQRS 및 도메인 기반 설계와 결합 되면 집계 루트는 명령의 유효성을 검사하고 적용한 다음(종종 명령 처리기에서 인스턴스 메서드를 호출하여) 이벤트를 게시하는 역할을 합니다.

• CQRS를 사용하면 모든 관련 이벤트 메시지에 대해 상태가 업데이트됩니다. 따라서 상태는 항상 알려져 있습니다.

  • 구체화된 뷰(예: Kafka Streams의 KTable)에 저장된 상태를 쿼리하는 것이 효율적입니다.

  • 요청-응답을 통해 서버는 모든 요청의 상태를 계산하거나 결정해야 합니다.

  • CQRS를 사용 하면 해당 발생 시점의 상태 쿼리 수에 관계없이 한 번만 계산/업데이트 됩니다.

• 이러한 원칙은 데이터 스트리밍 세계에 완벽하게 들어 맞습니다.

  • Apache Kafka는 수신 이벤트를 변경할 수 없는 커밋 로그에 추가하는 분산 스토리지입니다.

  • 이벤트의 진정한 디커플링 및 재생 가능성은 기본적으로 Kafka 인프라에 구축되어 있습니다.

  • 도메인 기반 설계를 사용하는 대부분의 최신 마이크로서비스 아키텍처는 REST 또는 MQ가 아닌 Apache Kafka로 구축됩니다.

6. Apache Kafka를 사용한 동기 및 비동기 요청-응답

• 이벤트 소싱이 있는 CQRS 는 Kafka 세계의 대부분의 사용 사례에 가장 적합한 패턴입니다.

• 정말로 필요하지 않다면 Kafka와 함께 요청-응답 개념을 사용하지 마십시오! Kafka는 스트리밍 데이터와 다양한 생산자와 소비자 간의 진정한 디커플링을 위해 구축되었습니다.

• 이는 트랜잭션 워크로드의 경우에도 마찬가지입니다.

  • 트랜잭션에는 동기 통신이 필요하지 않습니다.

  • Kafka API는 미션 크리티컬 트랜잭션을 지원합니다 (비록 비동기적이고 본질적으로 분산됨).

    • 은행 지불 에 대해 생각해 보십시오. 이는 결코 동기적이지 않으며 조직 내 및 조직 전반에 걸쳐 많은 독립 이벤트가 있는 복잡한 비즈니스 프로세스입니다.

• 새로운 Kafka 애플리케이션을 구축할 때 요청-응답이 첫 번째 아이디어가 되어서는 안 된다고 설명했지만 이것이 불가능하다는 의미는 아닙니다.

  • 때로는 문제를 해결하는 데 더 좋고, 간단하거나, 더 빠른 접근 방식입니다. 따라서 Kafka를 사용한 동기 및 비동기 요청-응답 구현 의 예를 살펴보겠습니다.

• 요청-응답 패턴은 Kafka로 구현할 수 있습니다.

  • 하지만 다르게. JMS 메시지 브로커(임시 대기열 등 포함)에서처럼 수행하려고 하면 궁극적으로 Kafka 클러스터가 종료됩니다(다르게 작동하기 때문에).

  • 그럼에도 불구하고 사용된 개념은 상관 ID와 같이 JMS API에서와 같이 후드 아래에서 동일합니다.

Apache Kafka를 사용한 비동기식 요청-응답

Spring

• Spring 프로젝트 와 Kafka Spring Boot Kafka 템플릿 라이브러리에는 Kafka로 빌드된 비동기 요청-회신 패턴 의 좋은 예가 있습니다.

  "org.springframework.kafka.requestreply.ReplyingKafkaTemplate "을 확인하십시오.

  • Kafka API를 사용하여 요청/응답 애플리케이션을 쉽게 생성합니다.

    • 예를 들어 JMS API를 사용하는 경우 작성하기가 더 복잡한 비동기 요청/응답 을 구현하기 때문에 이 예제는 흥미롭습니다.

• Spring의 장점은 사용하기 쉬운 템플릿과 메서드 서명을 사용할 수 있다는 것 입니다.

  • 프레임워크 를 사용하면 사용자 지정 코드 없이 디자인 패턴을 사용하여 구현할 수 있습니다.

  • 예를 들어 다음은 Kafka를 사용한 요청-응답을 위한 두 가지 Java 메서드입니다.

    • RequestReplyFuture<K, V, R> sendAndReceive (ProducerRecord<K, V> 레코드) ;

    • RequestReplyFuture<K, V, R> sendAndReceive (ProducerRecord<K, V> 레코드, 응답 시간 종료) ;

• 결과는 ListenableFuture 비동기식으로 결과(또는 시간 초과의 경우 예외)로 채워집니다.

• sendFuture 결과는 호출한 결과인 속성도 있습니다.

  • KafkaTemplate.send()이 미래를 사용하여 보내기 작업의 결과를 결정할 수 있습니다.

Apache Kafka를 사용한 동기식 요청-응답

• Spring Kafka 템플릿을 사용한 동기 요청/응답

  • 예제는 결과를 반환하기 위해 동기 요청-응답 동작으로 두 숫자의 합을 계산하는 Kafka 서비스를 보여줍니다.

• Spring은 자동으로 생산자 레코드에 상관 ID를 설정합니다 .

  • 이 상관 ID는 @SendTo소비자 측의 주석에 의해 있는 그대로 반환됩니다.

• Kafka 템플릿에 대한 Spring 문서에는 Kafka의 요청/회신 패턴에 대한 많은 세부 정보와 코드 예제가 있습니다.

  • Spring을 사용하면 요청/응답 패턴을 Kafka로 구현하는 것이 매우 간단합니다.

  • Spring을 사용하지 않는 경우 프레임워크에서 Kafka로 요청-응답을 수행하는 방법을 배울 수 있습니다.

7. 데이터 스트리밍과 REST API의 결합

• 위의 예는 Apache Kafka로 요청-응답 패턴을 구현하는 방법을 보여주었습니다.

  • 그럼에도 불구하고 여전히 차선책에 불과하며 스트리밍 데이터에 대한 안티 패턴인 경우가 많습니다.

• 데이터 스트리밍과 요청-응답 REST API는 종종 두 세계를 최대한 활용하기 위해 결합됩니다.

Apache Kafka 및 API 관리

• 매우 일반적인 접근 방식은 Kafka 에코시스템을 사용하여 실시간으로 대규모 애플리케이션을 구현한 다음 API 관리 계층을 맨 위에 배치하여 이벤트를 외부 세계 (다른 내부 비즈니스 도메인 또는 B2B 타사 애플리케이션)에 API로 노출하는 것입니다.

• 다음은 SAP 데이터를 연결하는 예입니다.

  • SAP에는 Kafka Connect 커넥터, REST/HTTP, 독점 API 또는 타사 미들웨어를 포함하여 Kafka와의 통합을 위한 수십 가지 옵션이 있습니다.

• 스트리밍 데이터 허브로 데이터를 가져오는 방법에 관계없이 오른쪽에서 Kafka REST API는 HTTP를 통해 이벤트를 노출하는 데 사용됩니다 .

  • API Management 솔루션은 Kafka 인터페이스를 기반으로 보안 및 수익 창출/청구 요구 사항을 처리 합니다 .

8. Apache Kafka를 사용한 내부 및 외부 데이터 공유를 위한 스트림 교환

• API, 요청-응답 통신, Kafka 간의 관계에 대해 논의한 후 시장의 중요한 트렌드인 Data Mesh(유행어)와 실시간 데이터 공유를 위한 스트림 교환(문제 해결사)을 살펴보겠습니다.

• Data Mesh는 요즘 많은 화제를 불러일으키고 있는 새로운 아키텍처 패러다임입니다. 데이터 메시를 구축하는 데 완벽한 단일 기술은 없습니다 .

  • Apache Kafka와 같은 개방적이고 확장 가능한 분산형 실시간 플랫폼은 종종 비즈니스 문제를 해결하기 위해 다른 많은 데이터 플랫폼으로 보완되는 Data Mesh 인프라의 핵심입니다.

• 요청-응답 및 REST API를 중간에 사용하는 대신 스트림 네이티브 데이터 공유는 많은 사용 사례에서 자연스러운 진화입니다.

데이터 스트리밍과 요청-응답을 함께 사용

• 대부분의 아키텍처는 점대점 통신 (예: 서버와 모바일 앱 간) 을 위한 요청-응답 과 지속적인 데이터 처리를 위한 데이터 스트리밍이 필요합니다 .

• Apache Kafka를 사용하여 동기 및 비동기 요청-응답 통신을 구현할 수 있습니다.

  • 그러나 CQRS 및 이벤트 소싱은 대부분의 경우 데이터 스트리밍에 더 좋고 자연스러운 접근 방식입니다.

  • 다양한 옵션과 장단점을 이해하고 작업에 적합한 도구(이 경우 올바른 디자인 패턴)를 사용하십시오.

사용 예제

• 참조 1

• 참조 2