Kafka용 API Gateway 사용의 이점 탐구

Yuan Bao

March 31, 2023

Technology

Kafka 간단 소개

Kafka는 원래 LinkedIn에서 Zookeeper 조정에 의존하고 여러 파티션과 복제본을 포함하는 분산 메시징 시스템으로 만들어졌습니다. 이후 Apache Software Foundation에 기부되었습니다. 뛰어난 처리량, 지속성, 수평 확장 능력 덕분에 Kafka는 업계에서 널리 채택된 분산 스트림 처리 플랫폼이 되었습니다.

Kafka는 세 가지 주요 사용 사례가 있습니다:

  • 메시징 시스템: 이는 가장 일반적인 사용 사례로, 백엔드 마이크로서비스 간의 메시지 통신에 사용됩니다. Kafka는 시스템 분리, 트래픽 형성, 비동기 통신을 가능하게 합니다.
  • 스토리지 시스템: Kafka는 메시지를 디스크에 저장하고 다중 복제 기능을 포함하고 있어 데이터 지속성 시스템으로 사용하기에 적합합니다. 이는 데이터 손실 위험을 크게 줄입니다.
  • 스트림 처리 플랫폼: Kafka는 윈도우, 조인, 변환과 같은 작업을 포함한 스트림 처리를 위한 포괄적인 라이브러리를 제공합니다.

Kafka의 기술 아키텍처

표준 Kafka 클러스터는 여러 Producer, Consumer, Broker 및 Zookeeper 클러스터로 구성됩니다. Zookeeper는 Kafka 클러스터의 핵심 제어 구성 요소로, 클러스터 메타데이터와 컨트롤러 선출을 관리합니다. Producer는 메시지를 Broker로 보내고, Broker는 메시지를 디스크에 저장하며, Consumer는 Broker에서 메시지를 구독하고 소비합니다.

핵심 개념

Kafka 토픽과 파티션

Kafka에서 메시지는 토픽으로 분류됩니다. Producer는 일반적으로 메시지를 보낼 때 토픽을 지정하고, Consumer는 일반적으로 토픽을 구독하여 메시지를 소비합니다.

토픽은 일반적으로 여러 파티션으로 구성되며, 각 파티션에는 서로 다른 메시지가 포함됩니다. 메시지가 Kafka로 전송되면 파티션 규칙에 따라 적절한 파티션에 저장됩니다. 적절한 파티션 규칙을 설정함으로써 메시지를 서로 다른 파티션에 균등하게 분배할 수 있습니다.

Producer와 Consumer

Producer는 메시지를 보내는 주체로, 메시지를 생성하고 Kafka 브로커로 보내는 역할을 합니다.

Consumer는 메시지를 받는 주체로, Kafka 클러스터의 브로커에 연결하고 특정 토픽을 구독하여 메시지를 소비하는 역할을 합니다.

Kafka Broker

Broker는 Kafka의 독립적인 노드 또는 인스턴스로 간주될 수 있습니다. Kafka 클러스터는 하나 이상의 Broker로 구성됩니다.

kafka cluster

Kafka에 API 게이트웨이가 필요한 이유

대부분의 경우, 백엔드 마이크로서비스 간의 메시지 시스템으로 Kafka를 사용할 때 개발자는 프로젝트에서 사용하는 언어에 따라 다른 Kafka SDK를 선택하여 Producer 또는 Consumer 클라이언트를 개발해야 합니다.

그러나 이 접근 방식은 클라이언트가 Kafka에 직접 연결해야 하는 경우와 같은 특정 시나리오에서 제한이 있습니다. 이러한 경우 호출자와 Kafka 사이에 API 게이트웨이를 추가하면 서비스를 분리할 수 있습니다. 이렇게 하면 호출자가 Kafka 또는 특정 통신 프로토콜에 대해 걱정할 필요가 없어 호출 비용이 줄어듭니다. 또한 API 게이트웨이는 Kafka가 노출하는 API에 대한 보안 지원 및 트래픽 제어 기능을 제공하여 Kafka 서비스의 안정성을 보장할 수 있습니다.

Kafka에 직접 연결

Kafka에 직접 연결하면 메시지 큐 미들웨어로 사용할 때 여러 제한과 위험이 발생할 수 있습니다:

  1. 서로 다른 Consumer는 Kafka의 통신 프로토콜에 적응해야 합니다.
  2. Kafka는 노출된 API의 보안, 트래픽 제어 및 기타 문제에 대한 솔루션을 제공하지 않습니다. 속도 제한 정책이 없으면 일부 Producer 또는 Consumer가 과도한 컴퓨팅 파워와 대역폭을 소비할 수 있습니다.
  3. Consumer와 Producer 모두 Kafka 클러스터 토폴로지를 알고 있어야 하며, Kafka 클러스터의 변경에 영향을 받을 수 있습니다.

API 게이트웨이가 Kafka의 사용성을 향상시킴

통신 프로토콜 변환

API 게이트웨이가 Kafka를 프록시할 때 클라이언트는 HTTP 프로토콜을 사용하여 API 게이트웨이와 통신하고, API 게이트웨이는 Kafka의 프로토콜을 사용하여 Kafka와 통신합니다. API 게이트웨이는 클라이언트의 메시지를 Kafka의 프로토콜로 변환하여 클라이언트가 서로 다른 Kafka 메시지 프로토콜에 적응할 필요가 없게 합니다. 이는 개발 비용을 크게 줄이고 사용을 더 편리하게 만듭니다.

속도 제한

리소스가 제한적일 때 Kafka 노드의 서비스 용량도 제한됩니다. 이 한도를 초과하면 서비스가 중단되고 연쇄 반응이 발생할 수 있습니다. 속도 제한은 이를 방지할 수 있습니다. 전통적인 Kafka 아키텍처에서 클라이언트는 SDK를 통해 Kafka와 통신합니다. 그러나 클라이언트나 요청 수가 많으면 Kafka 노드의 머신 부하에 영향을 미치고 Kafka 기능의 안정성에 영향을 줄 수 있습니다. 아키텍처에 API 게이트웨이를 추가하면 API 게이트웨이가 이 분야에서 뛰어나기 때문에 Kafka 클러스터에 다양한 차원의 속도 제한 기능 지원을 쉽게 추가할 수 있습니다. 이러한 기능은 다음과 같습니다:

  • 고정 시간 창 알고리즘을 사용하여 단일 클라이언트가 지정된 시간 프레임 내에 서비스에 요청할 수 있는 총 횟수를 제한합니다.
  • 단일 클라이언트가 단일 서비스에 동시에 요청할 수 있는 횟수를 제한합니다.
  • 누출 버킷 알고리즘을 사용하여 단일 클라이언트의 서비스 요청 속도를 제한합니다.

이러한 속도 제한 기능을 구현함으로써 Kafka 노드를 효과적으로 보호하여 안정성을 보장할 수 있습니다.

인증 지원

인증은 API 게이트웨이의 강력한 기능 중 하나입니다. 전통적인 Kafka 아키텍처에서 대부분의 Kafka 포트는 내부 네트워크 내에서 접근됩니다. 공용 네트워크에서 접근이 필요한 경우 복잡한 구성이 필요하여 보안을 보장해야 합니다. API 게이트웨이의 인증 기능을 사용하여 Kafka를 프록시할 때 Kafka가 노출된 포트를 보호하면서도 클라이언트 접근을 선택적으로 허용하거나 거부할 수 있습니다.

모니터링 기능

현재 Kafka를 위한 많은 모니터링 제품이 있습니다. 예를 들어 Kafka Eagle, Kafka Monitor, Kafka Manager 등이 있습니다. 각각 장단점이 있으며, 보편적인 모니터링 기능을 달성하기는 어렵고 맞춤화 비용이 상대적으로 높습니다. 또한 내부 모니터링 시스템과 통합하기가 어려울 수 있습니다. Kafka 모니터링 시스템을 처음부터 구축하는 것도 비용이 많이 들며, Kafka의 모니터링 정보는 많은 측면을 다루고 있고 Kafka 자체가 제공하는 모니터링 지표는 Java Management Extension(JMX)을 통해 복잡한 처리가 필요합니다.

아키텍처에 API 게이트웨이를 추가하면 클라이언트와 API 게이트웨이 간의 통신이 HTTP 프로토콜을 기반으로 합니다. 결과적으로 HTTP 프로토콜을 기반으로 한 모니터링 소프트웨어 생태계가 매우 풍부합니다. 이를 통해 매우 낮은 비용으로 Kafka 서비스에 대한 포괄적인 관찰 가능성을 제공할 수 있습니다.

Kafka 롤링 업그레이드

Kafka 서비스는 브로커 주소를 통해 노출되며, Producer와 Consumer는 Kafka 클러스터에 연결하기 위해 구성 정보에 이 주소를 제공해야 합니다. 주소 목록은 일반적으로 host1:port1, host2:port2 형식으로 되어 있으며, 하나 이상의 주소를 쉼표로 구분하여 포함할 수 있습니다.

그러나 이 구성 방식에는 제한이 있습니다: Kafka 브로커 주소가 고정되어 있어야 하고 서비스가 안정적으로 유지되어야 합니다. Kafka 클라이언트는 모든 브로커 주소가 사용 가능하다고 가정하고 무작위로 하나를 선택하여 사용합니다. 이는 롤링 업그레이드 중에 문제를 일으킬 수 있으며, 클라이언트는 어떤 브로커를 사용해야 하는지 알지 못하고 브로커 주소를 변경하려면 모든 Producer와 Consumer 클라이언트가 변경해야 합니다.

Kafka를 위한 API 게이트웨이를 사용하면 브로커 주소를 게이트웨이 계층에서 구성할 수 있으며, 클라이언트는 더 이상 Kafka 브로커의 구체적인 세부 사항에 집중할 필요가 없습니다. 브로커 주소가 변경되더라도 클라이언트는 영향을 받지 않습니다. 이렇게 하면 클라이언트에 영향을 주지 않고 Kafka를 쉽게 롤링 업그레이드할 수 있습니다.

요약

따라서 Kafka에 API 게이트웨이를 추가하면 API 게이트웨이의 풍부한 기능을 통해 Kafka 서비스에 대한 속도 제한, 인증, 모니터링, 롤링 업그레이드 기능을 쉽게 제공할 수 있습니다.

Apache APISIX를 사용하여 Kafka 확장

Apache APISIX는 Apache Software Foundation의 고성능 실시간 API 게이트웨이입니다. 로드 밸런싱, 동적 업스트림, 카나리 릴리스, 서킷 브레이커, 인증, 관찰 가능성과 같은 다양한 정교한 트래픽 관리 기능을 제공합니다. API 게이트웨이로서 APISIX는 기업이 API 및 마이크로서비스 트래픽을 빠르고 안전하게 처리할 수 있도록 도와주며, Kubernetes Ingress 및 서비스 메시에서 널리 사용됩니다. Kafka 서비스 앞에 APISIX 계층을 추가함으로써 기업은 플랫폼의 풍부한 플러그인 시스템을 활용하여 메시지 프록시, 로그 전달, 속도 제한, 모니터링 및 기타 기능을 활성화할 수 있습니다. APISIX를 사용하면 클라이언트에서 서버로의 남북 트래픽과 기업 마이크로서비스 간의 동서 트래픽을 효과적으로 처리할 수 있습니다.

APISIX and Kafka

Kafka 메시지 프록시

APISIX는 Kafka 메시지를 프록시하는 기능을 제공합니다. 클라이언트는 APISIX와 직접 통신할 수 있으며, APISIX는 클라이언트와 Kafka 간의 메시지 프로토콜 변환을 처리합니다.

APISIX에서 Kafka 프록시 기능을 활성화하려면 아래와 같이 라우트를 추가하면 됩니다:

curl -X PUT 'http://127.0.0.1:9180/apisix/admin/routes/Kafka' \
    -H 'X-API-KEY: <api-key>' \
    -H 'Content-Type: application/json' \
    -d '{
    "uri": "/Kafka",
    "plugins": {
        "Kafka-proxy": {
            "sasl": {
                "username": "user",
                "password": "pwd"
            }
        },
        "limit-count": {
            "count": 2,
            "time_window": 60,
            "rejected_code": 503,
            "key_type": "var",
            "key": "remote_addr"
        }
    },
    "upstream": {
        "nodes": {
            "Kafka-server1:9092": 1,
            "Kafka-server2:9092": 1,
            "Kafka-server3:9092": 1
        },
        "type": "none",
        "scheme": "Kafka"
    }
}'

이 요청은 APISIX에 URI /Kafka로 라우트를 생성하며, 이 라우트는 세 개의 Kafka 브로커 노드를 업스트림 서비스로 연결합니다. kafka-proxy 플러그인은 Kafka 요청에 SASL/PLAIN 인증을 추가하는 데 사용됩니다. APISIX의 구성은 핫 업데이트를 지원하므로 Kafka 브로커를 수정할 때 API 게이트웨이를 재시작하거나 클라이언트를 방해할 필요가 없습니다.

또한, 이 라우트에 대해 limit-count 플러그인이 활성화되어 속도 제한을 지원합니다. 플러그인의 구성은 60초 간격으로 두 개의 요청만 통과할 수 있도록 지정하며, 추가 요청은 APISIX에 의해 503 상태 코드로 거부됩니다.

로그 전달

APISIX의 kafka-logger 플러그인을 사용하면 로그를 JSON 객체로 Apache Kafka 클러스터에 전달할 수 있습니다.

다음은 구성 예시입니다:

curl http://127.0.0.1:9180/apisix/admin/routes/1 \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "plugins": {
       "kafka-logger": {
            "brokers" : [
              {
                "host" :"127.0.0.1",
                "port" : 9092
              },
              {
                "host" :"127.0.0.1",
                "port" : 9093
              }
            ],
           "kafka_topic" : "test2",
           "key" : "key1"
       }
    },
    "upstream": {
       "nodes": {
           "127.0.0.1:1980": 1
       },
       "type": "roundrobin"
    },
    "uri": "/hello"
}'

APISIX는 Kafka 메시지를 프록시하는 기능 외에도 다양한 플러그인을 통해 추적, 메트릭, 로깅 기능을 제공하여 관찰 가능성의 모든 측면을 다룹니다. APISIX에서 간단한 플러그인 구성을 통해 Prometheus, Skywalking 등 다른 관찰 가능성 서비스와의 통합이 가능하여 Kafka 클러스터의 모니터링 기능을 강화할 수 있습니다.

요약

이 글은 Kafka에 API 게이트웨이를 구현하는 장점을 강조하고, Apache APISIX를 사례로 들어 Kafka에 속도 제한, 인증, 모니터링, 롤링 업그레이드와 같은 기능을 제공하는 방법을 보여줍니다.

Tags:
APISIX Basics
Plugin