카프카의 주요 개념: 이벤트, 스트림, 토픽

카프카의 주요 개념: 이벤트, 스트림, 토픽

1. 이벤트 (Event):
   • 이벤트는 어떤 일이 발생했을 때의 상태를 나타내는 불변하는 데이터이다.
   • , 사용자가 특정 버튼을 클릭한 경우, 서버에 요청을 보낸 경우, 결제 트랜잭션이 발생한 경우 등이 이벤트가 될 수 있다.
   • 이 이벤트는 레코드 또는 메시지로 시스템 간에 전송될 수 있으며, 각 이벤트는 특정 시간에 발생한 데이터를 나타낸다.
   • 이벤트는 순차적으로 발생하며, 이를 스트림으로 처리하게 된다.
2. 스트림 (Stream):
   • 스트림은 연관된 이벤트들의 흐름을 의미한다. 여러 개의 이벤트가 순차적으로 발생하고 이를 처리하는 과정이 스트림이라고 할 수 있다.
   • 이벤트들은 시간 순서대로 발생하며, 각 이벤트는 연속적인 데이터 흐름의 일부로 다뤄진다. 즉, 스트림은 여러 개의 관련된 이벤트들이 순차적으로 발생하여 이어지는 흐름이다.
   • 카프카에서는 스트림 처리를 통해 실시간 데이터를 처리하거나, 데이터 파이프라인을 구축할 수 있다.
3. 토픽 (Topic):
   • 카프카에서 토픽은 관련된 이벤트들을 묶어 영속화하는 개념이다.
   • 각 토픽은 이벤트들의 카테고리로, 카프카 클러스터 내에서 각 이벤트 메시지가 해당 토픽에 기록된다.
   • , "사용자 가입", "주문 처리", "로그인 이벤트"와 같은 여러 개의 이벤트가 각각 user_signup, order_processed, user_login 등의 토픽에 묶여 저장될 수 있다.
   • 카프카는 파티션을 통해 각 토픽을 분할하여 저장하므로, 데이터를 효율적으로 분산하고 병렬 처리할 수 있게 한다.

카프카 토픽과 파티션

• 토픽은 카프카에서 데이터를 분류하는 카테고리로, 한 토픽 내에서 관련된 이벤트들이 전송된다. , orders라는 토픽에 모든 주문 이벤트가 저장될 수 있다.
• 파티션 (Partition):
  • 카프카 토픽은 파티션으로 나누어져 있다. 각 파티션은 독립적인 순서대로 기록되는 로그를 유지하며, 데이터를 병렬로 처리할 수 있게 한다.
  • 파티션을 통해 데이터를 여러 서버에 분산시켜 확장성을 제공하고, 각 파티션은 독립적으로 데이터가 기록되고 소비된다.
  • , orders라는 토픽이 3개의 파티션으로 나누어져 있다면, 각 파티션에 주문 이벤트가 저장되며, 이를 각각 독립적으로 처리할 수 있다.

카프카 토픽과 파티션의 주요 역할

1. 데이터 분산:
   • 파티션을 통해 카프카는 데이터를 여러 브로커에 분산하여 저장한다. 이를 통해 데이터의 분산 처리와 확장성이 가능해진다.
2. 병렬 처리:
   • 파티션을 나누면 여러 컨슈머가 병렬로 데이터를 처리할 수 있어 처리 성능이 향상된다.
3. 순서 보장:
   • 각 파티션 내에서는 이벤트의 순서가 보장된다. , 하나의 파티션에 저장된 이벤트는 순차적으로 읽힌다
4. 내구성 및 복구:
   • 카프카는 복제(replication)를 통해 파티션을 여러 브로커에 복제함으로써 데이터의 내구성을 보장한다. 이를 통해 장애 복구가 용이해진다.

예시

• , orders라는 토픽이 있다고 가정할 때:
  • orders 토픽은 3개의 파티션을 가질 수 있으며, 각 파티션은 주문 이벤트가 순차적으로 기록된다.
  • Partition 1에 저장된 데이터는 Partition 1을 구독하는 컨슈머가 읽고, Partition 2에 저장된 데이터는 Partition 2를 구독하는 다른 컨슈머가 읽다.

결론

• 이벤트는 시스템 간에 전송되는 데이터의 단위이고, 스트림은 관련된 이벤트들의 흐름을 나타낸다.
• 토픽은 이벤트들을 묶어 카프카 시스템 내에서 저장되는 카테고리로, 이를 파티션으로 나누어 데이터를 효율적으로 처리하고 저장한다.
• 파티션을 이용해 데이터를 분산 처리하고, 병렬 처리 성능을 향상시키며, 각 파티션 내에서는 데이터의 순서가 보장된다.

 

 

 

 

각 토픽은 관련된 이벤트들이 묶여 저장되고, 이를 통해 데이터 흐름을 관리한다. 

카프카 토픽 (Kafka Topics)과 이벤트 흐름 (Flow of Events)

1. 이벤트 스트림 (Event Stream):

• 카프카에서 이벤트 스트림은 시스템에서 발생한 여러 개의 이벤트들이 시간순으로 연속적으로 발생하는 데이터 흐름이다.
• 이벤트는 불변의 데이터를 나타내며, 시스템 간에 전송되어 처리된다.
• , 주문 처리, 배송 시작, 주문 취소 등의 이벤트들이 발생한다.

2. 카프카의 주요 토픽:

• 카프카에서 이벤트들은 토픽에 저장된다. 각 토픽은 이벤트 카테고리로서 관련된 이벤트들을 묶어서 저장한다.
• 주문(Orders), 배송(Shipments), 주문 수정(Verifications)과 같은 각 이벤트의 흐름은 별도의 토픽에서 관리된다.

예시: 여러 개의 카프카 토픽과 이벤트 흐름

1. Orders Topic (주문 토픽):

• Orders 토픽은 주문 이벤트 스트림을 다룬다.
• 이 스트림은 고객이 주문을 할 때마다 발생하는 여러 이벤트들을 포함한다. , 주문 생성, 주문 상태 변경, 주문 취소 등의 이벤트가 해당 토픽에 기록된다.
• 주문 이벤트는 각 파티션에 저장되며, 각 이벤트는 시간순으로 처리된다.

 

2. Shipments Topic (배송 토픽):

• Shipments 토픽은 배송 이벤트 스트림을 다룬다. 
• 고객이 주문을 완료한 후, 배송이 시작될 때 발생하는 이벤트들을 포함한다. , 배송 시작, 배송 중, 배송 완료 등의 이벤트가 해당 토픽에 기록된다.

 

3. Verifications Topic (주문 검증 토픽):

• Verifications 토픽은 주문 검증 이벤트 스트림을 다룬다.
• 주문 처리 과정에서 검증이 필요한 이벤트들을 포함한다. , 주문 결제 검증, 배송지 검증, 주문 정보 확인 등의 이벤트가 해당 토픽에 기록된다.

 

카프카의 이벤트 흐름

• 카프카 프로듀서는 각 토픽에 이벤트를 발행(publish)한다.
• 각 이벤트는 카프카의 파티션에 저장되며, 이벤트가 시간순으로 기록되어 순차적인 처리가 가능한다.
• 카프카 컨슈머는 각 토픽을 구독하여 이벤트를 읽고 처리한다. 컨슈머는 각 파티션에서 데이터를 읽으며, 여러 컨슈머가 동시에 작업할 수 있어 병렬 처리가 가능하다.

이벤트 스트림 처리

• 각 토픽에 저장된 이벤트들은 실시간으로 처리되고, 특정 이벤트를 필터링하거나 변환하는 작업이 가능다.
• , Orders 토픽에서 주문 생성 이벤트가 발생하면, 이 이벤트는 Shipments 토픽으로 전달되어 배송 시작 이벤트를 유발할 수 있다.

카프카의 특징

1. 내구성: 카프카는 데이터를 디스크에 저장하여 장애가 발생하더라도 데이터를 안전하게 보관한다.
2. 확장성: 카프카는 파티션을 통해 데이터를 여러 브로커에 분산 저장하여 확장성을 제공한다.
3. 병렬 처리: 파티션을 통해 여러 컨슈머가 병렬로 데이터를 읽을 수 있어 성능이 향상된다.

결론

• 카프카의 토픽은 관련된 이벤트들이 묶여 저장되는 카테고리이며, 각 토픽은 이벤트 스트림을 처리하는 중요한 역할을 한다.
• Orders, Shipments, Verifications와 같은 다양한 이벤트 토픽을 사용하여 시스템 간에 데이터를 효율적으로 전송하고, 처리하는 시스템을 구축할 수 있다.
• 카프카는 순차적인 데이터 처리, 병렬 처리, 확장성, 내구성 등 여러 장점을 제공하는 메시지 큐 시스템이다.

 

 

 

 

 

 

카프카의 파티셔닝은 성능과 확장성에서 중요한 역할을 한다. 아래에서 파티셔닝의 주요 효과를 설명하겠다.

1. 수평 확장성 (Horizontal Scalability)

• 파티션 분산: 카프카에서 토픽은 여러 파티션으로 나뉘어 각 브로커에 분산된다. 이는 수평적 확장을 가능하게 한다. 즉, 단일 브로커에서 처리할 수 있는 데이터 양을 넘지 않게 하며, 추가적인 브로커를 추가하여 쉽게 확장할 수 있다.
• 성능 향상: 여러 브로커에 파티션을 분산하면 싱글 브로커보다 훨씬 더 높은 성능을 제공한다. 이렇게 분산된 파티션들은 동시에 처리되므로 전체 시스템의 처리 속도가 향상된다.

2. 병렬 처리 (Parallel Processing)

• 병렬성: 파티션을 여러 개 설정하면, 그만큼 여러 컨슈머 인스턴스가 각기 다른 파티션을 병렬로 처리할 수 있다. 각 파티션은 독립적으로 데이터를 저장하고 처리하므로, 여러 컨슈머가 동시에 메시지를 처리할 수 있어 성능이 대폭 향상된다.
• , 여러 개의 파티션을 설정한 경우 각 컨슈머는 자신의 할당된 파티션에서 메시지를 처리하게 되어, 동시 처리량을 증가시킨다.

3. 높은 메시지 처리량 (High Throughput)

• 메시지 처리 효율: 파티셔닝 덕분에 카프카는 대량의 메시지를 동시에 처리할 수 있다. 각 파티션은 독립적으로 처리되므로, 메시지가 파티션 간에 영향을 주지 않으며, 처리 속도와 처리량이 높아진다. 여러 브로커에서 파티션이 나누어져 처리되기 때문에, 메시지의 처리량이 매우 높다.

4. 복제 (Replication)

• 파티션 복제: 카프카는 각 파티션에 대해 복제본을 여러 개 만들어 데이터의 내구성을 보장한다. 복제본은 여러 브로커에 분산되어 저장된다. , 각 파티션은 최소한 2개의 복제본을 갖다.
• 장애 처리: 만약 브로커가 다운되면, 해당 브로커에서 관리하던 파티션의 복제본이 다른 브로커에서 제공되므로, 시스템의 가용성을 유지할 수 있다. 다운된 브로커가 복구될 때까지 다른 브로커의 복제본이 파티션을 담당한다.

5. 파티션과 컨슈머 간의 관계

• 컨슈머 그룹: 각 컨슈머는 하나의 파티션에서만 데이터를 처리한다. 즉, 각 컨슈머는 자신에게 할당된 파티션의 메시지를 처리하므로, 각 레코드는 하나의 메시지 처리 담당자(컨슈머)에게 할당된다.
• 파티션의 수와 컨슈머 수: 파티션의 수는 컨슈머 그룹 내 컨슈머의 수와 맞춰주는 것이 좋다. 파티션 수가 컨슈머 수보다 적으면 일부 컨슈머는 파티션을 할당받지 못하게 되며, 파티션 수가 많으면 일부 컨슈머는 여러 파티션을 담당하게 된다.

6. 파티션 복제와 장애 처리

• 파티션 복제: 카프카의 파티션은 복제된다. 각 파티션은 최소 하나 이상의 리더와 여러 개의 팔로워를 가진다. 리더는 데이터를 쓰고 읽는 주된 역할을 하며, 팔로워는 리더의 데이터를 복제한다.
• 장애 복구: 브로커가 다운되면, 해당 브로커에 있던 파티션의 복제본이 다른 브로커에서 제공되며, 이로 인해 데이터 손실 없이 서비스를 계속 제공할 수 있다.

결론

• 카프카 파티셔닝은 수평 확장성을 제공하며, 병렬 처리를 통해 시스템 성능을 크게 향상시킨다. 또한, 높은 메시지 처리량과 복제를 통해 높은 가용성과 내구성을 유지할 수 있다.
• 카프카는 파티션을 이용해 여러 브로커에 데이터를 분산 저장하고 처리하므로, 장애 발생 시에도 복제된 데이터를 이용한 자동 복구가 가능하여, 안정성이 확보된다.

 

 

 

 

 

 

 

카프카에서 파티션 키를 사용하는 방법은 데이터를 특정 파티션에 분배하여 순서를 보장하는데 중요한 역할을 한다. 

파티션 키 사용

• 파티션 키 설정: 데이터를 특정 파티션에 할당하려면 파티션 키를 설정한다. , ConsumerId, _id와 같은 고유한 값을 파티션 키로 사용할 수 있다.
• 해싱 함수: 카프카는 파티션 키에 대해 해싱 함수를 사용하여 데이터를 파티션에 할당한다. 즉, 특정 파티션 키에 대해 계산된 해시 값에 따라 메시지가 특정 파티션으로 전달된다.
• 순서 보장: 동일한 파티션 키를 사용하는 모든 레코드는 동일한 파티션에 저장된다. 이를 통해 해당 키와 관련된 메시지들이 순서대로 처리될 수 있다. , 특정 ConsumerId에 대한 이벤트가 항상 동일한 파티션에 저장되므로 순서가 보장된다.

장점

• 순서 보장: 동일한 파티션에 저장되는 메시지는 순서대로 처리되므로, 메시지 순서가 중요한 경우 유용한다. , 주문 처리 시스템에서 각 주문에 대한 처리가 순차적으로 이루어져야 한다면, 주문 ID를 파티션 키로 설정하여 그 순서를 보장할 수 있다.

단점

• 분산 불균형 가능성: 파티션 키가 잘 분산되지 않으면 일부 파티션에 트래픽이 집중될 수 있다. , 특정 ConsumerId가 전체 트래픽의 70% 이상을 차지하는 경우, 그 특정 파티션에 과도한 로드가 발생하게 되며, 결국 브로커의 성능 저하나 다운이 발생할 수 있다.
  • 예시: ConsumerId가 abc123인 메시지가 전체 트래픽의 70%를 차지한다면, abc123에 해당하는 파티션이 다른 파티션들보다 훨씬 많은 메시지를 처리하게 되므로 이 파티션에 부하가 집중될 수 있다.
• 잘못된 분산 확인 필요: 파티션 키가 제대로 분산되지 않으면, 시스템의 성능에 심각한 문제가 생길 수 있다. 따라서 키의 분포를 잘 확인하고 분산이 고르게 이루어지는지 점검하는 것이 중요한다.

분산의 균형 맞추기

• 파티션 키가 잘 분산되도록 하려면, 가능한 한 고유한 값을 사용하고, 특정 값에 트래픽이 집중되지 않도록 설계해야 한다. , ConsumerId와 같은 값이 너무 균일하지 않으면 일부 파티션에 과도한 트래픽이 집중될 수 있다.
• 비슷한 트래픽 패턴을 가진 데이터를 그룹화할 수 있는 복합적인 파티션 키를 고려할 수도 있다. , ConsumerId와 OrderId를 결합하여 파티션 키로 사용하면 더 고르게 분산될 수 있다.

결론

카프카에서 파티션 키를 사용하면 메시지의 순서를 보장할 수 있지만, 분산 불균형이 발생할 수 있다는 단점이 있다. 따라서 파티션 키를 설정할 때 잘 분산되는 키를 선택하고, 트래픽 패턴에 맞게 파티션 키를 설계하는 것이 매우 중요한다. 잘못된 분산이 일어나지 않도록 항상 모니터링하고, 시스템의 성능에 미치는 영향을 확인하는 것이 필요하다.

 

 

 

 

적절한 파티션 수를 결정하는 것은 카프카의 성능을 최적화하고 시스템 확장성을 고려하는 중요한 요소이다. 

 

 

 

1. 목표 처리량에 맞는 파티션 수

파티션 수는 처리할 수 있는 메시지의 양에 영향을 미친다. 따라서, 목표 처리량을 기준으로 파티션 수를 결정하는 것이 중요하다. :

• 예시: 프로듀서가 3개이고, 각 프로듀서가 초당 10개의 메시지를 보낸다고 가정한다. 그러면 전체 메시지 처리량은 초당 30개의 메시지가 된다.
• 파티션 처리 능력: 1개의 파티션이 초당 10개의 메시지를 처리할 수 있다고 가정하면, 이 경우에는 3개의 파티션이 필요한다. 즉, 초당 30개의 메시지를 처리하려면 최소 3개의 파티션이 필요한다.

2. 파티션 수 확장

• 카프카에서 파티션 수는 늘릴 수 있지만, 줄일 수는 없다. 즉, 처음에 적당한 수의 파티션을 설정하고, 시스템 확장에 따라 파티션 수를 점진적으로 늘려주는 것이 효율적이다.
• 확장 시 고려 사항: 파티션을 늘리면 여러 브로커와 컨슈머가 더 많은 메시지를 처리할 수 있게 되어 처리 성능이 향상되지만, 너무 많은 파티션을 만들면 관리 복잡도와 메모리 사용이 늘어날 수 있다.

3. 처리량에 맞는 파티션 수 결정

• 프로듀서의 수: 프로듀서가 보내는 메시지의 수가 많을수록 파티션 수를 늘려야 한다. , 프로듀서가 많아지거나, 각 프로듀서가 보내는 메시지의 수가 많아지면, 이를 수용하기 위해 파티션 수를 증가시켜야 한다.
• 컨슈머의 수: 파티션의 수는 컨슈머 수와도 관련이 있다. 각 컨슈머가 하나의 파티션을 담당하기 때문에, 컨슈머 그룹의 크기에 따라 파티션 수를 맞추는 것이 중요한다. 파티션이 많으면 더 많은 컨슈머가 병렬 처리할 수 있다.

4. 파티션 수 설정 시 유의 사항

• 초기 설정은 적은 수의 파티션으로 시작하는 것이 좋다. 이는 시스템 초기 구축 시 관리 용이성과 자원 사용 최적화를 위해 바람직한다. 그런 후, 시스템 확장에 맞춰 파티션 수를 점진적으로 늘려가는 전략을 사용하는 것이 좋다.
• 불필요한 파티션 수 증가 방지: 과도한 파티션 수 증가는 운영 부담을 키울 수 있기 때문에, 필요 이상으로 파티션을 늘리지 않도록 주의해야 한다. 적절한 성능을 위한 파티션 수를 계산하고, 그 이상을 추가하는 것은 자원의 낭비를 초래할 수 있다.

결론

파티션 수는 목표 처리량을 기준으로 계산하는 것이 가장 중요하다. 시스템의 트래픽이 증가할수록 파티션 수를 늘려주되, 파티션 수는 줄일 수 없으므로 처음에는 적은 수의 파티션으로 시작하여 필요에 따라 확장하는 것이 이상적이다.