ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [카프카 프로토콜 이해하기] 1. 네트워크
    개발자 라이프/카프카 2021. 9. 12. 23:13
    반응형

    들어가며

     카프카의 브로커는 중앙에서 수많은 클라이언트와 네트워크 요청/응답을 주고받습니다. 예를 들어, 프로듀싱/컨슈밍 할 파티션 찾기, 메시지 프로듀싱과 컨슈밍, 컨슈머 그룹 Join과 Sync 등이 있습니다. 그럼에도 불구하고 카프카는 매우 빠른 처리량으로 유명합니다. 이렇게 카프카의 브로커와 클라이언트가 빠른 네트워크 요청/응답을 주고받을 수 있는 것은 카프카의 요청/응답에 대한 네트워크 구성 방식 때문일 텐데요. 이번 글은 이러한 카프카의 네트워크 특징을 살펴봅니다. 

     참고로 이번 글은 카프카 프로토콜 공식문서의 Network 단락을 기반으로 합니다. 틀린 부분이 있다면 댓글 부탁드립니다.

    네트워크

     카프카의 네트워크는 아래와 같은 특징을 가집니다.

    • Binary Protocol (바이너리 프로토콜)
    • 하나의 브로커에 대한 하나의 커넥션 유지
    • 클라이언트의 Non-Blocking IO

    이 특징들을 살펴보며 카프카의 네트워크가 어떻게 효율적으로 구성되어 있는지 살펴봅니다.

    Binary Protocol (바이너리 프로토콜)

     카프카는 TCP를 기반한 바이너리 프로토콜을 사용합니다. 바이너리 프로토콜은 값을 바이트로써 사용하는 프로토콜입니다. 이는 값을 사람이 읽기 쉬운(Human-readable) 문자로 사용하는 텍스트 프로토콜(Text Protocol)과 반대의 방법입니다. 값을 바이트로 표현하기 때문에 사람이 직접 읽기엔 어려우나, 컴퓨터 입장에선 별도의 인코딩/디코딩이 필요 없으므로 빠르게 읽고 처리할 수 있다는 장점이 있습니다.

     카프카는 바이너리 프로토콜을 이용하기 위해 모든 API에 대한 요청과 응답 메시지의 바이트 구성을 정의했습니다. 그래서 모든 메시지는 특정한 바이트 사이즈를 가지고, 또 프로토콜 기본 타입(Protocol Primitive Type)으로 지정된 값들로 API 요청/응답 메시지의 내용을 표현합니다.

    Wireshark로 ApiVersions API 요청에 대한 패킷 내용을 확인해본 모습.

     예를 들어, 위 그림처럼 ApiVersions API에 대한 요청은 바이트 배열로 구성되어 있으며, 각 바이트는 그 위치에 따라 카프카 프로토콜에서 정의한 의미를 가지게 됩니다. 즉, 붉은색으로 강조된 부분은 API Key에 대한 값을 가지고 있는 바이트이며, 해당 바이트는 ApiVersions에 대한 Key 값인 18(16진수로는 12) 값을 가지고 있는 것을 확인할 수 있습니다.

    하나의 브로커에 대한 커넥션 유지

     클라이언트는 브로커와 소켓 연결을 구성하고, 그 연결을 통해 요청 메시지를 쓰고 응답 메시지를 읽습니다. 그리고 이 과정은 TCP 연결이 유지된 상태에서 진행됩니다. 이렇게 유지된 상태의 연결을 통해 요청/응답을 하는 방법은 개별 TCP 통신에서의 handshake 과정을 생략할 수 있습니다. 이는 많은 요청을 보내는 카프카 환경에서 효율적인 네트워크 통신을 가능하게 해 줍니다.

     그리고 클라이언트는 필요한 리소스가 위치한 다수의 브로커와 통신할 필요가 있습니다. 예를 들어, 컨슈머가 컨슘 할 토픽 파티션이 하나 이상일 때, 그 토픽 파티션들이 위치한 브로커는 하나 이상일 수 있습니다. 그러나 클라이언트는 하나의 브로커에 대해 여러 연결을 유지할 필요는 없습니다. 

    컨슈머를 띄웠다 종료했을 때의 네트워크 패킷들의 모습. 특정 브로커에 대해 하나의 TCP 연결을 구성하여 ApiVersions, Metadata, FindCoordinator 요청이 이뤄졌다.

    클라이언트의 Non-Blocking IO

     클라이언트는 non-blocking IO 방식으로 요청 파이프라인을 구성할 수 있으며, 이는 높은 처리량을 위한 대중적인 방식입니다. 즉, 클라이언트는 응답을 대기하지 않더라도 계속 요청을 보낼 수 있습니다. 이는 응답이 오지 않은 요청을 OS 소켓 버퍼에 저장할 수 있기 때문입니다.

    출처 : https://medium.com/coderscorner/tale-of-client-server-and-socket-a6ef54a74763

     추가로 브로커는 하나의 TCP 연결 안에서 응답은 요청의 순서대로 반환합니다. 따라서 브로커는 연결 별로 요청을 순서대로 하나씩 처리합니다. 그리고 브로커는 요청의 최대 크기를 설정할 수 있으며, 이 크기를 넘는 요청이 들어오는 경우 소켓 연결은 끊어집니다.

    마무리

     이번 글을 통해 카프카의 네트워크 통신에 어떤 특징이 있는지 살펴봤습니다. 다음 글에서는 파티셔닝 전략과 배치 방식의 통신에 대한 내용을 정리해보겠습니다.

    참고

     

    Apache Kafka

    Apache Kafka: A Distributed Streaming Platform.

    kafka.apache.org

     

     

    Communication protocol - Wikipedia

    From Wikipedia, the free encyclopedia Jump to navigation Jump to search System for exchanging messages between computing systems A communication protocol is a system of rules that allows two or more entities of a communications system to transmit informati

    en.wikipedia.org

     

    반응형

    댓글

Designed by Tistory.