p5. Consumer

Consumer

• Partition으로부터 Record를 가져온다. 
• Consumer는 각각 고유의 속도로 Commit Log로부터 순서대로 Read를 수행
• 다른 Consumer Group에 속한 Consumer들은 서로 관련이 없으며, Commit Log에 있는 Event(Message)를 동시에 다른 위치에서 Read할 수 있다.

 

Consumer Offset

• Consumer Group이 읽은 위치를 표시한다. Consumer가 자동이나 수동으로 데이터를 읽은 위치를 commit하여 다시 읽음을 방지한다.
• __consumer_offsets 이라는 Internal Topic에서 Consumer Offset을 저장하여 관리한다.

 

Multi-Partition with Single Consumer

Consumer가 하나인 경우, 모든 Partition에서 Consume한다.

예를 들어, 4개의 Partition으로 구성된 Topic의 데이터를 사용하는 Single Consumer가 있는 경우, 이 Consumer는 Topic의 모든 Partition에서 모든 Record를 Consume한다.

 

Consuming as a Group

동일한 group.id로 구성된 모든 Consumer들은 하나의 Consumer Group을 형성한다.

• 4개의 파티션이 있는 Topic을 Consume하는 4개의 Consumer가 하나의 Consumer Group에 있다면, 각 Consumer는 정확히 하나의 Partition에서 Record를 Consume한다.
• Partition은 항상 Consumer Group 내의 하나의 Consumer에 의해서만 사용된다.
• Consumer는 주어진 Topic에서 0개 이상의 많은 Partition을 사용할 수 있다.

 

Multi Consumer Group

• 동일한 group.id로 구성된 모든 Consumer들은 하나의 Consumer Group을 형성한다.
• Consumer Group의 Consumer들은 작업량을 어느정도 균등하게 분할한다.
• 동일한 Topic에서 Consume하는 여러 Consumer Group이 있을 수 있다.

 

 

Key를 사용하면 Partition 별 동일한 Key를 가지는 메시지를 저장

같은 Key라면 같은 Partition에 저장된다는 의미이다. 다음 그림을 보자.

• Key가 AAA인 경우 P0에 저장된다.

• Key가 BBB인 경우 P1에 저장된다.

• Key가 CCC인 경우 P2에 저장된다.

• Key가 DDD인 경우 P3에 저장된다.

 

이렇듯, Partition이 여러개인 경우 모든 메시지에 대한 전체 순서는 보장이 불가능하다. Key가 무엇이냐에 따라 각각 다른 파티션에 저장될테니 말이다. 

• 파티션 별로 순서는 보장이 되지만, 소비하는 Consumer 입장에서는 각 파티션에 있는 모든 데이터를 가져왔을 때 그 전체 순서를 보장할 수 없다.

 

파티션을 1개로 구성하면 모든 메시지에서도 전체 순서가 보장 가능하지만 이 경우, 처리량 저하가 일어난다. 근데 과연 1개로 구성해서 모든 메시지에서 전체 순서 보장을 해야하는 경우가 얼마나 많을까? 대부분의 경우, Key로 구분할 수 있는 메시지들의 순서 보장이 필요한 경우가 많다. 예를 들어, 주문 테이블에 주문 데이터를 넣을 때 이 주문 데이터를 카프카에 이벤트로 전송한다고 해보자. 주문 데이터에는 주문 시간이라는 명확한 순서를 알 수 있는 정보가 들어있는데 굳이 한 파티션에 모든 주문 데이터를 순서대로 넣을 필요가 있을까? 그렇지 않다. 

 

그래서, 대부분의 경우, 전체 순서를 보장할 필요가 없고 많은 데이터를 처리해야 한다면 멀티 파티션을 사용해서 처리량 증가에 초점을 맞추면 된다. 근데 만약, 운영중에 처리량 증가를 더 효율적으로 하겠다고 파티션 개수를 변경하면 어떻게 될까? 동일한 파티션은 순서가 보장이 됐었는데 이젠 동일한 파티션이어도 순서가 보장되지 않는다. 왜냐하면, 파티션이 늘어나면 해시값을 구할 때 사용하는 파티션의 수가 달라진다.

Hash(Key) % partition 개수

이런 공식으로 해시값을 구하는데, 3개였던 파티션이 4개로 늘어나면 같은 키라고 해도 파티션 수를 바꾼 이후부터 다른 파티션에 들어갈 수 있기 때문에, 운영중에는 파티션 개수를 변경하면 안된다. 

 

Consumer Failure

• 4개의 파티션이 있는 Topic을 Consume하는 4개의 Consumer가 하나의 Consumer Group에 있다면, 각 Consumer는 정확히 하나의 Partition에서 Record를 Consume한다.
• Partition은 항상 Consumer Group 내의 하나의 Consumer에 의해서만 사용된다.
• Consumer는 주어진 Topic에서 0개 이상의 많은 Partition을 사용할 수 있다.

• 위 그림과 같이 P3을 처리하는 Consumer 3번이 죽으면 어떻게 될까?

• Consumer Group 내의 다른 Consumer가 실패한 Consumer를 대신하여 Partition에서 데이터를 가져와서 처리한다.
• Partition은 항상 Consumer Group 내의 하나의 Consumer에 의해서만 사용된다.
• Consumer는 주어진 Topic에서 0개 이상의 많은 Partition을 사용할 수 있다.

 

정리를 하자면

• Consumer가 자동이나 수동으로 데이터를 읽은 위치를 Commit하여 다시 읽음을 방지한다.
• __consumer_offsets 이라는 Internal Topic에서 Consumer Offset을 저장하여 관리한다.
• 동일한 group.id로 구성된 모든 Consumer들은 하나의 Consumer Group을 형성한다.
• 다른 Consumer Group의 Consumer들은 분리되어 독립적으로 작동한다.
• 동일한 Key를 가진 메시지는 동일한 파티션에만 전달되어 Key 레벨의 순서 보장이 가능하다.
• Key 선택이 잘못되면 작업 부하가 고르지 않을 수 있다.
• Consumer Group 내의 다른 Consumer가 실패한 Consumer를 대신하여 Partition에서 데이터를 가져와서 처리한다.