<aside> 1️⃣ Kafka 파티션의 중요성

</aside>

1. 고가용성

   

   • Broker 1, 2, 3: Kafka 브로커이다. 각 브로커는 파티션의 리더나 팔로워(복제본)을 가질 수 있다.
   • Partition 1, 2: 토픽의 파티션이다. 각 파티션은 하나의 리더와 하나 이상의 팔로워(복제본)을 가질 수 있다.
   • Consumer A, B: 데이터를 읽는 컨슈머다. 여러 컨슈머가 다른 브로커의 파티션에서 동시에 데이터를 읽을 수 있다.
   • Replication: 파티션의 데이터가 다른 브로커로 복제되는 과정이다. 이를 통해 고가용성이 보장된다.
   • Read: 컨슈머가 파티션에서 데이터를 읽는 과정이다.

• 고가용성이 중요한 이유
  • 데이터 손실 방지:
    • 하나의 브로커가 실패하더라도, 다른 브로커에 복제된 파티션 덕분에 데이터 손실을 방지할 수 있다.
  • 서비스 지속성:
    • 리더가 실패할 경우, 팔로워 중 하나가 리더 역할을 자동으로 수행하므로 서비스 중단 없이 지속된다.
  • 장애 복구:
    • 복제 메커니즘과 리더-팔로워 구조를 통해 장애 발생 시 빠르고 안정적으로 복구할 수 있다.
  • 비즈니스 연속성:
    • 고가용성은 특히 장애 상황에서 빠른 복구와 지속적인 서비스 제공이 필요한 비즈니스 환경에서 중요하다.

1. 쓰기/읽기 성능 향상

   

   • 파티션과 브로커의 분산 구조
     • 위 그림에서 볼 수 있듯이, **Topic 1**이라는 같은 토픽이 **Broker 1**과 **Broker 2**에 분산되어 있다. **Broker 1**에는 **Topic 1: Partition 1**이, **Broker 2**에는 **Topic 1: Partition 2**가 위치하고 있다.
   • 병렬 처리의 장점
     • 위의 그림에서 볼 수 있듯이, 파티션 1은 브로커 1에, 파티션 2는 브로커 2에 위치하고 있다. 이렇게 되면, 컨슈머 A는 파티션 1에서, 컨슈머 B는 파티션 2에서 동시에 데이터를 읽을 수 있다. 이로 인해 데이터 처리 속도가 빨라지고, 시스템의 처리 능력이 증가한다.
   • 확장성
     • 파티션의 수를 증가시키면, 더 많은 컨슈머가 동시에 데이터를 처리할 수 있게 되어, 시스템이 더 큰 규모의 데이터와 트래픽을 처리할 수 있게 된다.
   • 유연성
     • 이러한 방식으로, 파티션과 브로커를 적절히 구성하면, 성능과 확장성을 동시에 달성할 수 있다. 이는 비즈니스 요구사항과 시스템 규모에 따라 유연하게 조정할 수 있어, 매우 효율적인 데이터 처리가 가능하다.

2. 순서 보장

   

   • 파티션과 브로커의 분산 구조:
     • Kafka에서는 하나의 토픽(Topic 1)을 여러 파티션으로 나눌 수 있다. 그리고 이 파티션들은 각각 다른 브로커에 위치할 수 있다.
     • 그림에서 볼 수 있듯이, 파티션 1은 브로커 1에, 파티션 2는 브로커 2에 위치하고 있다.
   • 순서 보장:
     • 각 파티션 내에서는 메시지의 순서가 보장된다. 따라서 시계열 데이터나 로그 데이터, 트랜잭션 데이터 등 순서가 중요한 데이터를 안정적으로 처리할 수 있다.

<aside> 2️⃣ Kafka 파티션의 주의점

</aside>

1. 키 선택:
   • 프로듀서가 데이터를 파티션에 할당할 때 사용하는 키를 신중하게 선택해야 한다.
   • 잘못된 키 선택은 데이터 분산이 불균형해질 수 있다. 이는 특정 브로커에 부하가 집중되는 결과를 초래할 수 있다.
   • 해결방법: 키 선택 전략을 명확하게 정의하고, 가능하면 키의 해시 분포가 균일하게 되도록 설계해야 한다.
2. 컨슈머 그룹:
   • 하나의 컨슈머 그룹 내에서는 컨슈머의 수가 파티션 수보다 많을 수 없다.
   • 그렇지 않으면 일부 컨슈머는 데이터를 처리하지 못할 것이다. 이는 리소스의 비효율적인 사용을 초래할 수 있다.
   • 해결방법: 컨슈머 그룹을 설계할 때, 파티션 수와 컨슈머 수를 균형 있게 맞춰야 한다.
3. 파티션 재배치:
   • 파티션의 수를 늘리는 것은 쉽지만 줄이는 것은 복잡하고 위험할 수 있다.
   • 따라서 초기 설계 단계에서 파티션 수를 신중하게 결정해야 한다. 잘못된 파티션 수 설정은 데이터 재배치나 브로커 재구성을 필요로 할 수 있다.
   • 해결방법: 초기에는 파티션 수를 보수적으로 설정하고, 시스템의 성장과 함께 필요에 따라 조정하는 것이 좋다.

<aside> 3️⃣ 파티션 저장과 복제란?

</aside>

• 파티션 저장

  • 특정 토픽의 메시지가 특정 파티션에 저장된다.
  • 예를 들어, orders 토픽의 메시지가 파티션 0에 저장될 수 있다.

• 파티션 복제

  • 저장된 메시지가 다른 브로커의 동일한 파티션으로 복사된다.
  • 이렇게 하면 브로커가 실패할 경우에도 데이터 손실을 방지할 수 있다.

• 왜 복제가 필요한가?

  • 복제는 높은 가용성과 데이터 내구성을 위해 필요하다.
  • 예를 들어, 브로커 1이 다운되거나 장애가 발생하면 브로커 2와 3에서 해당 파티션의 복제본을 사용할 수 있다.

• 파티션과 브로커

  • 파티션 0, 1, 2가 각각 브로커 1, 2, 3에 저장될 수 있다.

    

  • 이 파티션들은 다른 브로커의 동일한 파티션으로 복제될 수 있다.

  • 예를 들어, **Partition 0**이 **Broker 1**에 원본으로 존재하면, 그 복제본이 아래의 그림과 같이 **Broker 2**와 **Broker 3**에도 존재할 수 있다.

  

  • 그림에서 표시된 TOPIC B1, TOPIC B2, **TOPIC B3**은 각각 Broker 1, Broker 2, **Broker 3**에 저장된 동일한 **TOPIC**의 복제본이다. 즉, 모두 같은 **TOPIC**이다.

• 리더와 팔로워

  • 리더(Leader)

    • 각 파티션에는 하나의 리더가 있으며, 모든 읽기와 쓰기 연산은 이 리더를 통해 이루어진다.
    • 예를 들어, **Partition 0**의 리더가 **Broker 1**이면, 이 파티션에 대한 모든 데이터 작업은 **Broker 1**을 통해 처리된다.

  • 팔로워(Follower)

    • 리더를 제외한 나머지 복제본을 팔로워라고 한다.
    • 팔로워는 리더의 데이터를 복제하여 가용성을 높인다.
    • 예를 들어, **Partition 0**의 팔로워가 **Broker 2**와 **Broker 3**이면, 이 브로커들은 **Broker 1**의 데이터를 복제한다.

    

  • 리더(Leader)와 팔로워(Follower) 관계

    • 각 파티션에는 하나의 리더가 있으며, 모든 읽기와 쓰기 연산은 이 리더를 통해 이루어진다.
    • 리더를 제외한 나머지 복제본을 팔로워라고 한다.
    • 팔로워는 리더의 데이터를 복제하여 가용성을 높인다.

• ISR(In-Sync Replicas)

  • 정의: ISR은 리더와 데이터가 동일하게 동기화된 상태인 팔로워의 목록을 의미한다.
  • 용도: ISR 목록에 있는 팔로워만이 새로운 리더로 선출될 수 있다. 이를 통해 데이터의 일관성을 유지한다.
  • 예시: 만약 **Broker 1**이 장애가 발생하거나 다운되면, ISR 목록에 있는 **Broker 2**나 Broker 3 중 하나가 새로운 리더로 선출될 수 있다.

  

• 이렇게 하면, 하나의 브로커가 실패하더라도 다른 브로커에서 데이터를 복구할 수 있다. 이는 높은 가용성과 데이터 내구성을 보장한다.

<aside> 4️⃣ 파티션의 순서 보장

</aside>