본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
https://bit.ly/4hTSJNB


I. 학습 인증샷 4장 이상 포함

1. 공부시작: 날짜, 시각 다 나오도록

공부 시작

 

ㅇ2. 공부 종료: 날짜 시각 다 나오도록

공부 종료


 

 

3. 1개 클립 수강 (강의장 목록 캡쳐, 수강화면이 보이지 않도록) 1장

강의클립9

4. 학습 인증샷 1장(필기 촬영이나 작업물 촬영)

맞는말이다. 모든 메시지의 전체 보장을 할 필요는 없다. 위의 경우도 각 사용자(key)의 액션만 순서만 보장되면 된다.


II. 학습 후기 700자 이상 (공백 제외)

이번에는 반대로 Consumer에 대한 주요 개념과 특징을 설명한다.

요약

Consumer 기본 개념

  • Consumer는 Commit Log에서 순서대로 데이터를 읽는다.
  • Consumer Offset은 Consumer가 읽은 위치를 표시하며,  `__consumer_offsets` [internal topic] 에 저장된다.

Consumer Group

  • 동일한 group.id를 가진 Consumer들이 하나의 Consumer Group을 형성
  • Consumer Group 내 Consumer들은 파티션을 분배하여 데이터를 컨슈밍한다.
  • 다른 Consumer Group의 Consumer들은 독립적으로 작동하며, 서로 영향을 주지 않는다.

 메시지 순서와 키 사용

  • 파티션이 2개 이상인 경우 전체 메시지 순서 보장이 불가능하다.
    • 컨슈머가 파티션 2개의 데이터를 처리 -> 파티션 2개의 데이터가 서로 섞이게 된다
    • 하지만 전체 메시지의 전체 순서의 보장이 필요한 케이스가 과연 얼마나 되는가?
    • 사실상 각 키 레벨의 순서 보장이 필요한 케이스가 대부분이다.
  • 키를 사용하면 동일한 키를 가진 메시지가 같은 파티션에 저장되어 키 레벨의 순서 보장이 가능
  • 키 선택은 작업 부하 분배에 영향을 미치므로 매우 중요하며 많은 고민이 필요하다

 Consumer Failure와 Rebalancing

  • Consumer 실패 시 Consumer Group 내 다른 Consumer가 해당 파티션을 대신 처리
  • 이를 통해 Consumer Group의 안정성과 가용성이 유지

주요 고려사항

  • 파티션 수와 Consumer 수의 균형을 고려해야 한다
    • 카프카 시스템의 성능과 확장성에 중요한 영향을 미친다
    • 파티션이 적으면
      • 컨슈머 리소스를 충분히 활용하지 못한다
      • 메시지 처리 속도가 느려질 수 있다
    • 파티션이 너무 많으면
      • 컨슈머간 조정 오버헤드가 증가한다
      • 카프카 클러스터 안정성이 떨어진다
    • 적절한 파티션 수는 ??
      • 컨슈머 성능을 모니터링
      • 필요에 따라 조정하며 찾아야 한다
      • 운영시에 바꾸기 힘드므로 운영 전 단계에서 픽스하는게 좋다
  • 키 선택 시 데이터 분배와 순서 보장을 함께 고려해서 고민 필요.
    • 동일한 키를 가진 메시지는 같은 파티션에 전달 된다 → 키 레벨의 순서를 보장
    • 키 선택이 잘못되는 경우 특정 파티션에 데이터가 몰리게 된다 → 작업 부하가 고르지 않음
    • 예시) 사용자의 id를 키로 한다면 사용자별 메시지 순서가 보장
    • 반면 특정 사용자의 활동이 많으면 해당 파티션에 부하가 집중된다
    • 따라서 데이터의 특성과 분포를 고려한 키 선택이 필요하다
  • Consumer Group 설계 시 처리량과 장애 대응을 고려해야 한다
    • Consumer Group을 통해 파티션을 여러 Consumer에 분배 병렬 처리 가능, 높은 처리량 달성
    • 동시에 Consumer Group은 장애 발생 시 자동으로 파티션을 재분배(ReBalancing)하여 시스템의 가용성을 유지
    •  Consumer 수가 너무 많으면 재조정(rebalancing) 빈도가 증가  성능에 영향을 줄 수 있다.
    • Consumer Group 설계 시 예상 처리량, 메시지 복잡도, 그리고 장애 시나리오를 고려하여
      적절한 Consumer 수와 구성을 결정해야 한다.

아니... 너무 어렵다... 운영에 반영하기전에 고려할게 너무 많다...
언어처럼 그냥 배워서 적용할 수 있는게 아니라 굉장히 고민과 시나리오 및 테스트를 많이 해봐야 할듯 하다...

블로그 이미지

감동맨

rkaehdaos의 블로그

,