'2025/03/14'에 해당되는 글 1건

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

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

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

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

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

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

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

이번 강의는 Apache Kafka의 복제(Replication) 메커니즘에 대해 설명하고 있다.. (점점 어렵다... 이게 기초인가..)

요약

Broker 장애 대비 방법 : Replication

• Partition을 복제하여 다른 Broker에 복제본(Replicas)을 만들어 장애에 대비한다.
• 이 부분은 DB Replication과 유사한 부분이 있어서 이해가 쉬웠다.

Leader and Follower

• 각 Partition에는 Leader와 Follower가 존재한다.
• DB Replication의 Master-slave와 비슷(절대 같지 않다. 그냥 개념으로써 이해하자)
• Producer는 Leader에만 쓰고 Consumer는 Leader에서만 읽는다..
• Leader에 장애가 발생하면 Follower 중 새로운 Leader를 선출한다.
• Producer와 Consumer는 새로운 Leader에서 계속 작업을 진행한다.

Partition Leader에 대한 자동 분산(Auto Leader Rebalancing)

• 하나의 Broker에 Leader가 몰린다면? → 리더 불균형(Leader Imbalance)
  • 해당 Broker에 모든 프로듀서와 컨슈머가 붙게 된다
    위에서 말했듯이 Producer와 Consumer는 Leader에서만 작업하기 때문.
     → 해당 Broker는 부하 집중된 Hot SPOT이 되어버림
  • 나머지 장비들은 ? 노는 장비가들이 되어버림
• Auto Leader Rebalancing 
  • Partition Leader를 자동으로 분산
  • 특정 Broker에 부하가 집중되는 것을 막아 Hot Spot을 방지
  • 주요 옵션
    
    • `auto.leader.rebalance.enable`: 자동 분산 활성화 옵션[기본값 : enable]
    • `leader.imbalance.check.interval.seconds`: 리밸런싱 체크 주기 설정→ Leader Imbalance 체크 [기본값 300초]
    • `leader.imbalance.per.broker.percentage`:
      • 브로커별 허용 가능한 불균형 비율을 지정
      • 이를 초과하면 자동으로 리밸런싱이 트리거
      • 기본값 : 10
      • Leader Imbalance가 10%를 넘어가면 리밸런싱 작업 시작

Rack Awareness

• 복제본을 다른 Rack에 분산 → Rack 장애 대비
• Broker의 묶음이므로 Rack이 될 수 있지만 AZ(Avaliable Zone)으로 장애 대비를 할 수도 있다.
• 동일한 Rack 혹은 AZ의 Broker에 동일한 "rack name" 지정
• 복제본(Replica-?leader/Follower)는 최대한 Rack 혹은 AZ간에 균형을 유지하며 장애를 대비한다

그동안엔 학습후기에 요약을 적으면서 다시 정리가 되었는데..오늘은 정리를 해도 안들어온다..

• 카프카 복제 메커니즘에 대한 개요 소개  혹은 찍먹 정도인데.. 개념이 아리송하다.. 
• 카프카가 장애에 대비하는 부분은 DB 레플리카와 비슷한 부분이 있어서 그런식으로 이해했다.
• 데이터가 복제되면 저장공간이 더 많이 필요하고 follower에서 읽어가는 부분에서 네트워크 트래픽도 선형적으로 증가할 거 같은데
  이것은 어떻게 대응하는 걸까? 어떻게 최적화하지..? 계속 고민만 생긴다.
• 장애가 발생했을 때 새로운 Leader를 선출할때 어떤 기준에서 선출하는지는 아직 설명되지 않았다.
• 자동 분산[Rebalance]도 신기하다. 이게 Default라는 게 대단..이 값들은 이 기본값들을 그대로 써도 되는지도 궁금하다.
• Rack Awareness라는 개념도 대단하다. 마치 AWS나 Azure의 AZ처럼 데이터 센터의 물리적 구조까지 고려해서 복제본을 배치할 수 있다는 부분이 대단하다. 반대로 그 부분 까지도 고민하고 신경을 써야한다는 점에서는 짜증이 난다.
• 역시 대규모 시스템은 그냥 이뤄지지 않는다.
• 언젠가 대규모 시스템을 직접 설계하고 구현하고 싶다는 부분에서 해당 강의 수강을 시작했는데..
  사실 벌써 기가 죽은 부분도 존재한다... 좋은 기술인데 아직은 어렵고 낯설다..