패스트캠퍼스 환급챌린지 14일차 : 한번에 끝내는 KafkaEcosystem 강의 후기

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

 

---

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

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

공부 시작

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

공부 종료

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

클립14

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

와 어렵지만 잼있었다.

---

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

심화공부 3번째로, 기본에 찍먹했던 Replica Recovery의 심화과정이다.

요약

 Replica Recovery 과정

• 브로커 장애 시 새로운 리더 선출
• 메시지 복제 및 커밋 과정
• High Water Mark 진행
•  

acks 설정의 중요성

• acks=all 와 acks=1을 비교한다.
• 하늘과 땅차이 ㅎ
• 데이터 유실 방지를 위한 acks=all 설정이 무조건 필요해 보인다
  
  • 심화 강의에서는 지금까지 없었던 복잡한 장애 상황을 보여주는데..
    이경우에도 acks=이라면.. 복잡한 과정 및 중복이 발생하더라도 데이터 유실없이 성공한다

가용성과 내구성 관련 파라미터

• unclean.leader.election.enable
  • ISR 리스트에 없는 리플리카를 리더로 선출할지 에 대한 옵션
  • 기본값은 false
  • true로 한다면..? .. 제대로 follow하지 못한 (ISR에 끼지도 못한 ) broker를 리더로?? 무조건 데이터 유실 확정!
• min.insync.replicas
  • 최소 요구되는 ISR 개수에 대한 옵션
    • 기본값: 1
    • ISR이 min.insync.replicas보다 적게 된다면?
      • Producer가 NotEnoughReplicas 예외 수신
    • Producer에서 ask = all과 함께 사용할 때 더 강력한 보장

Replica Recovery에 대한 심화강의인데 아주 좋다. 다른데서 한번도 보지 못한 복잡한 케이스를
단순하게 설명하는데 이해가 잘된다.
기본개념시 찍먹했던 용어들도 처음에 다시 짚어주는 부분 아주 좋다.

가용성과 내구성 관련 파라미터들에 대한 설명도 매우 유익하다
 unclean.leader.election.enable, min.insync.replicas, replication.factor 등의 설정이 시스템의 안정성과 성능에 어떤 영향을 미치는지 이해할 수  있다.
acks 설정의 중요성 심화에서  acks=all과 acks=1의 차이를 비교하면서, 데이터의 안정성과 시스템의 성능 사이의 트레이드오프를 고려해야 한다는 점을 (기존에도 알았었지만)다시 한번 고민 포인트임을 인지하게 된다..그리고 실제 프로젝트에서는 어떤 기준으로 이 설정을 선택해야 할지 또 다시 고민 하는데..

슬라이드11번에서 딱! 내가 원하는 완전한 설정값이 나왔다. 아주 기뻤다.
데이터 유실을 방지하기 위한 설정과 가용성을 높이기 위한 설정의 차이첨과 함께
해당 설정이 나와서.. .이대로 테스트하면 될 것 같다.

이번 심화 과정을 통해 Replica Recovery에 대해서 더 알게 되었다. 생각했던 것보다 더 복잡한 내부 동작 원리가 존재함을 배울 수 있었다. 그리고 그동안에 나왔던 데이터유실 방지 설정과 가용성을 높이기 위한 설정값이 실제로 공개되는 부분이 너무 좋다.

하지만 역시나 저런 설정값이 어떻게 도출 되었는지는 여전히 아리송 하다..
게다가.. 만약에 네트워크 장애들로 여러 리더가 동시에 존재하게 된다면 어떻게 될까?

왜 공부를 하는데... 더 모르는게 많아질까...