MSA Phase 4. Service to Service Communication

서론

사전 이론

• 해당 링크에는 선택과정과 큰 틀에 대한 이론이 정립되어 있다. 한번 보고 오면 도움이 될 것이다.
  • https://velog.io/@devty/엉금엉금-Kafka-도입기
• 앞으로는 공부할 때 해당 라이브러리, 플랫폼, 툴 등에 대한 아키텍처를 먼저 확인 후에 전체적인 flow을 이해하고 코드를 작성하는 것으로 공부 방법을 바꿨다.
  • 왜냐하면, 전체적인 cycle을 모르고 개발하는 것과 조금이라도 알고 가는 것에 대한 개발 시간 차이가 너무나도 많이 나기에 공부 방법을 바꿔보았다.

본론

Kafka를 도입하게된 계기

• 서버간 통신에 여러 툴들이 있는데 대게 2가지를 많이 사용한다.
  1. Kafka
  2. Rabbit MQ
• 2개 중 Kafka를 선택한 이유는
  1. 대용량 데이터 처리 능력
     • Kafka는 대용량의 데이터 스트림을 처리할 수 있는 능력이 뛰어나고, 높은 처리량을 자랑한다.
     • RabbitMQ는 큰 데이터 부하 하에서는 메모리 부하와 성능 저하를 겪을 수 있으며, 카프카보다는 작은 규모의 메시징 시스템에 더 적합합니다.
  2. 내구성과 데이터 안정성
     • Kafka는 데이터를 디스크에 저장하고, 복제 기능을 제공함으로써 높은 내구성과 데이터 안정성을 보장합니다. 이는 서버 장애 시에도 데이터 손실을 최소화합니다.
     • RabbitMQ도 데이터의 지속성을 제공하지만, 큰 데이터 부하에서는 카프카만큼의 내구성을 제공하기 어렵습니다.
  3. 확장성
     • Kafka는 카프카는 분산 시스템으로 설계되어 확장이 용이합니다. 이러한 특성은 데이터 볼륨이 늘어나면서 시스템을 확장해야 하는 빅 데이터 환경에서 매우 유용합니다.
     • RabbitMQ도 일정 수준의 확장성을 제공하지만, 카프카의 수준에는 미치지 못합니다.
• 위 같은 내용으로 인해 Kafka를 사용하게 되었다.
• 하지만 RabbitMQ도 좋은 통신 툴이다.
  1. Kafka는 설정이 매우 복잡하지만 RabbitMQ는 비교적 간단하게 설정이 가능하다.
  2. Kafka는 모니터링이 어려운점이 있지만 RabbitMQ는 내장된 관리 UI를 통해 모니터링이 가능하다.

Kafka Architecture

• 카프카 아키텍처에서 나오는 여러 영어 단어들이 눈에 보일 것이다.
  1. Producer
  2. Message Broker
  3. Topic
  4. Partition
  5. Zookeeper
  6. Consumer
• 사전 내용에서 설명한 것은 빼고 나머지 내용에 대해 디테일하게 아래에서 설명하겠다.

kakfa란?

• 아파치 카프카(Apache Kafka)는 분산 스트리밍 플랫폼이며 데이터 파이프 라인을 만들 때 주로 사용되는 오픈소스 솔루션이다.
• 대용량의 실시간 로그처리에 특화되어 있는 솔루션이며 데이터를 유실없이 안전하게 전달하는 것이 주목적인 메세지 시스템에서 Fault-Tolerant한 안정적인 아키텍처와 빠른 퍼포먼스로 데이터를 처리할 수 있습니다.
• 분산형 메세징 시스템으로 메세지를 토픽으로 분류하고, 이 토픽을 클러스터 내 여러 브로커 서버에 분산 저장한다.

Kafka Cluster란?

• 카프카 시스템은 하나 이상의 브로커 서버로 구성된 클러스터 형태로 동작한다.
• 데이터 저장, 분산 처리, 그리고 장애 복구를 제공하는 등의 작업을 수행한다.

Zookeeper란?

• 카프카 클러스터의 설정, 리더 선출, 그리고 클러스터 상태 관리 등을 담당하는 분산 조정 서비스이다.
• 클러스터의 메타데이터 관리, 브로커 서버 상태 모니터링, 그리고 클러스터 설정 관리 등을 수행한다.

Broker란?

• 카프카 클러스터 내의 각 서버를 브로커라고 한다.
• 브로커는 메시지를 저장하고, 소비자에게 메시지를 전달하는 역할을 합니다.

Partition란?

• 토픽은 여러 파티션으로 나뉘어질 수 있으며, 각 파티션은 메시지의 순서를 유지하는 독립적인 엔터티입니다.
• 파티션을 통해 데이터를 병렬 처리할 수 있어, 시스템의 확장성을 향상시킵니다.
• 각 파티션 내에서 메시지의 순서를 보장합니다.

적절한 주키퍼 개수

• 주키퍼 인스턴스는 일반적으로 1개 또는 여러개가 될 수 있다.
• 실제로 운영 환경에서는 주키퍼 앙상블을 구성하여 고가용성을 유지하기 위해 3개 또는 5개의 주키퍼 인스턴스를 사용하는 것이 일반적입니다.
  • 주키퍼 인스턴스 개수가 3, 5개로 홀수인데 그 이유는 과반수라는 개념 때문이다.
  • 과반수를 유지하기 위해 홀수 개의 주키퍼 서버가 필요하며, 이를 통해 클러스터 내의 서버 중 과반수가 동의해야 변경사항이 커밋이 된다.

토픽과 파티션에 대한 관계

• 위 사진을 보면 그 전에 설명했던 적절한 주키퍼 개수에 대한 사진을 인용했다.
• 지금 토픽으로 등록되어있는 것은 Foo, Bar 이렇게 두개가 존재하고 있다.
• 사진에 맨 왼쪽 Broker1에 대해서 설명하겠다.
  • 일단 먼저 Broker(브로커)는 메세지를 저장하고 보내주는 역할을 한다.
  • Broker1에는 어플리케이션 및 카프카에서 설정한 토픽을 등록해주고 등록된 토픽을 파티션에 개수만큼 복제를 해준다.
  • 여기서 파티션에 대한 복제 이야기가 나오는데 지금은 1개의 토픽을 3개의 파티션으로 복제해주었는데 그 이유는 아래와 같다.
    1. 각 파티션은 독립적으로 처리가 가능하므로 병렬처리가 가능하다.
    2. 트래픽이 증가하면 추가 파티션을 쉽게 추가할 수 있어서 확장성에 용이하다.
• Broker1은 또한 Broker2, Broker3에 대해 같은 내용이다. Broker를 복제해서 여러개로 사용하는 이유도 아래와 같다.
  1. 여러 브로커를 사용하면 데이터와 작업 부하를 여러 서버에 분산할 수 있다. → 분산처리 가능
  2. 하나의 브로커가 실패하더라도, 카프카 클러스트의 다른 브로커들이 계속 작동하여 시스템 다운타임을 최소화가 가능하다.
  3. 트래픽이 증가함에 따라 새로운 브로커를 쉽게 추가 가능하여 확정성에 용이하다.

파티션 Offest

• 카프카에서 Offset은 특정 파티션 내에서 메시지의 고유 식별자 역할을 한다.
• Offset은 메시지가 파티션에 추가될 때마다 증가하는 정수 값으로, 메시지의 순서를 나타내며, 이를 통해 어디까지 메시지를 읽었는지를 추적할 수 있다.
• 컨슈머(Consumer)가 메시지를 읽을 때, 어디서부터 메시지를 읽을 것인지를 결정하기 위해 오프셋 값을 사용한다.
• 이렇게 함으로써, 컨슈머는 이전에 읽은 메시지와 중복되지 않게 새 메시지만을 읽을 수 있으며, 어떤 메시지가 처리되었는지를 정확하게 알 수 있다.

결론

후기

• 저번에 Kafka를 공부할 땐 일단 구현부터 하고 보았다.
  • 사실 위에 있는 이론적인 부분이라던지 돌아가는 Flow를 모르고 개발했다.
• 그래서 그런지 많이 이해 안 되는 부분이 있었는데 이번에 제대로 공부해서 몰랐던 부분에 대해서 많이 이해하게 되었다.
• Kafka는 정말 잘 쓰게 된다면 트래픽에 비례해서 확장성에 용이하고 분산 및 벙렬 처리에 좋은 툴이 될 것 같다.