'패캠챌린지'에 해당되는 글 20건

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

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

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

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

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

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

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

카프카의 로그 관리에 대한 심화 강의이다. 

요약

 로그 정리 정책 (Log Cleanup Policy)

• Log는 Consume되어도 지우지 않음
  • 많은 Consumer들이 서로 다른 시간에 Log 데이터를 Consume 할 수 있기 때문에
• Broker 혹은 Topic 단위로 Cleanup 정책을 설정함
• log.cleanup.policy 파라미터
  • delete
  • compact
  • delete,compact: 2개 동시 사용
• 현재 Active Segment의 Log는 cleanup 대상이 아님!

삭제 정리 정책 (Delete Cleanup Policy) : Log Segment 삭제 정책

• Log Cleaner Thread가 Segment File을 삭제
• log.cleanup.policy 파라미터
  • delete
• log.retention.ms : log 보관 주기 (기본값 : 7 일)
• log.retention.check.interval.ms : log segment를 체크하는 주기 (기본값 : 5 분)
• segment 파일에 저장된 가장 최신의 메시지가 log.retention.ms 보다 오래된 segment 를 삭제

Topic 메시지 모두 삭제 하는 방법 : retension.ms 활용 : 운영환경에서는 권장하지 않음

1. Producer와 Consumer를 모두 shutdown
2. 명령어를 사용하여 해당 Topic의 retention.ms를 0으로 셋
   
3. Cleanup Thread 가 동작할 동안 대기 (기본값 5분 마다 동작)
4. 메시지 삭제 확인 후, 원래 설정으로 원복

주의) 절대 Log File을 직접 삭제하면 안된다. 카프카 깨짐

압축 정리 정책 (Compact Cleanup Policy)

• 주어진 키의 최신 값만 유지하는 정책
• 파티션별로 특정 키의 최신 값만 유지하며 압축
• 시스템 오류 후 상태 복원에 유용
• 동일한 Key를 가진 메시지가 다른 Partition에 있는 경우
  • 동일한 Key를 가진 여러 메시지가 여전히 있을 수 있음
  • 중복 제거용 기술이 아님

로그 압축 (Log Compaction)

• 키가 있는 메시지에 대해서만 작동
• 압축이 없는 경우 Consumer가 각 키의 최신상태에 도달하기 위해서는 항상 전체 Log를 읽어야 한다.
• 로그 압축을 사용하면 오래된 데이터를 읽지 않아 최종 상태에 빠르게 도달 가능

Tombstone 메시지: Log Compaction시 특정 Key 데이터 삭제

• 목적
  • 논리적 삭제 표시
    • 키는 있지만 값이 null인 메시지로 구성
    • 특정 키에 대한 레코드의 논리적 삭제를 나타낸다.
  • 로그 압축 지원
    • 압축된 토픽에서 이전 값들을 실제로 삭제하는데 사용
    • 로그 압축시 특정 키의 데이터를 삭제하는 매커니즘 제공
    • Compaction 사용시에 Key로 K를 가지는 메시지를 지우려면
      • 동일한 Key(K)에 null value를 가지는 메시지를 Topic으로 보내면 됨
• Consumer는 해당 메시지가 지워지기 전에(기본 1 day), 해당\메시지를 consume할 수 있음
• 메시지를 지우기 전 보관 기간(기본 1 day)은 log.cleaner.delete.retention.ms 로 조정

log라 함은 tomcat의 log, rabbitmq의 log로.. 에러만 처리하고 압축 보관 및 지워야하는 대상으로 여기게 된다.
하지만 절대 직접 지우면 안된다는 말에 ..순간 다시 개념이 떠올랐다.
카프카의 로그는 단순한 에러메시지나 시스템 기록이 아닌 실제로 메시지 자체를 의미한다는 것을...

 로그가 소비되어도 바로 삭제되지 않는다는 것!
여러 소비자가 서로 다른 시간에 로그 데이터를 소비할 수 있기 때문이라고 한다.
이런 특성 때문에 카프카가 다양한 시스템에서 유연하게 사용될 수 있다는 걸 깨달았다.
하지만 그러기 때문에 더더욱 삭제 정리 정책과 압축 정리가 중요해 보인다.


삭제 정책은 단순히 오래된 로그를 지우는 반면, 압축 정책은 각 키의 최신 값만 유지한다는 점이 인상적이다.
특히 압축 정책이 시스템 오류 후 상태를 복원하는 데 유용하다는 설명을 들으면서,
실제 업무에서 어떻게 활용될 수 있을지 상상해보게 되었다. 다만 실제 운영 이슈에서 버그 재현시에는
전체 메시지가 전부 있어야 완전하게 버그 재현이 가능하지 않을까 싶은데..

로그 압축의 동작 원리를 설명하는 부분에서는 조금 햇갈렸다..
Tail과 Head 영역, Cleaner Point 등의 개념이 처음에는 복잡해 보였지만,
강사님이 자세히 설명해주고 그림을 자세히 살펴보니 조금씩 이해가 되기 시작했다.
역시 만족스럽다.

Tombstone 메시지라는 개념도 처음 들어보는 개념이다.
압축 정책을 사용할 때 특정 키의 데이터를 삭제하는 방법이라고 한다..
실제로 null 값을 가진 메시지를 보내서 데이터를 삭제한다는 아이디어는 그 어디서도 볼 수 없는 부분이다.

혹시 몰라서 인터넷을 뒤져보니까.강의처럼 로그 압축 시나리오에서 압축된 토픽에서 오래된 레코드 제거하고 최신상태 유지할때 사용되는
부분이 있었다. 하지만 더 많은 부분은 분산시스템 동기화나 상태기반 어플리케이션의 특정 키 존재 관리에서 사용하는 등 쓰임새가 다양했다. 해당 부분을 설명안하는 것은 아직 필요가 없으니까 안한 것이었다.. 괜히 검색해서.. 더 머리가 복잡해졌다.

실무에서 사용가능한 성능튜닝에 사용할 값들이 (위 필기에서 나온 것처럼) 나오긴 했다. 하지만
어떤 좀더 사용사례들에 대한 여러 값들과 정책 설정 규칙을 알려주면 좋겠다.

그리고 아무래도 위의 내용은 나중 실습 때 실제로 적용해보고 내용을 봐야 내 것이 되지 않을까 싶다.

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

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

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

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

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

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

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

Apache Kafka의 로그 파일 시스템에 대한 심화학습이다.

처음에는 기본개념에서 배웠던 카프카의 기본 구조에 대한 리바이벌 및 상세라.. 요약할 필요가 없어보인다...
처음에는 토픽 파티션 세그먼트의 개념에 대해 다시 설명한다.

이후 로그 세그 먼트 파일의 물리적인 방식에 대해 설명하면서 실제로 어떻게 저장하는지 설명한다.
브로커의 server.properties 파일에서 log.dirs 파라미터로 저장 위치를 지정할 수 있다는 점, 그리고 여러 디렉토리를 지정할 수 있다는 점이 포인트이고 comma로 구분한다는 것도 기억할만하다. 각 토믹과 파티션은 log.dirs 아래에 하위 디렉토리로 구성되는 부분이다.

파티션 디렉토리의 로그 파일들의 파일명에도 의미가 있다. 파일명은 각 offset의 시작 값을 가지고  있다.
따라서 각 파일들 명만 봐도 이 파일이 어느 offset에서 어디까지의 데이터를 저장하고 관리하는지를 알 수 있다.

파티션 디렉토리 안에 있는 여러 종류의 파일들도 처음 알게 되었다.
확장자 혹은 파일명으로 구분 되는 거 같은데 최소 4가지 타입이다.

1. Log Segment File – 메시지와 metadata를 저장(가장 중요)
   1. 해당 세그 먼트 파일의 저장된 첫번째 메시지의 offset이 파일명
2. Index File – 각 메시지의 Offset을 Log Segment 파일의 Byte 위치에 매핑(인덱스)
3. Time-based Index File – 각 메시지의 timestamp를 기반으로 메시지를 검색하는 데 사용(시간 기반 인덱스)
4. Leader Epoch Checkpoint File – Leader Epoch과 관련 Offset 정보를 저장(리더 교체 및 시대 바뀜 정보와 당시 offset)

기본 시간에 배웠던 로그 세그먼트 파일의 롤링 전략에 대해 조금 더 자세히 설명한다.
 log.segment.bytes나 log.roll.ms 같은 파라미터들을 통해 새로운 세그먼트 파일을 만드는 기준을 설정할 수 있다는 점의 복습과 함께
새로운 부분 (인덱스 파일 사이즈도 롤링 대상이 될 수 있다는 부분 등)도 인상적이다.
여전히 실무에서 필요한....이런 설정들이 실제로 시스템의 성능과 관리에 어떤 영향을 미치는지는 알려주지 않는다.

체크포인트 파일이라는 처음 배우는 부분도 나온다.
각 Broker에는 2개의 체크 포인트 파일이 존재하며, 둘다 logs.dirs 디렉토리에 위치한다.

1. replication-offset-checkpoint
   1. 마지막으로 커밋된 메시지의 ID인 High Water Mark
   2. 우리가 계속 Replica 장애에서 보았던 그 High Water Mark가 저장된 곳이다
   3. 시작시 Follower가 이를 사용하여 Commit되지 않은 메시지를 Truncate
2. recovery-point-offset-checkpoint
   1. 데이터가 디스크로 Flush된 지점
   2. 복구 중 Broker는 이 시점 이후의 메시지가 손실되었는지 여부를 확인

심화인데 실무 예시가 없어서... 계속 목마르다.

예를 들어, 실제 대규모 시스템에서는 로그 세그먼트 파일의 크기를 어떻게 설정하는 것이 좋은가? 너무 작게 설정하면 파일이 너무 많아질 것 같고, 너무 크게 설정하면 관리가 어려울 것 같은데, 이런 trade-off를 어떻게 결정하는가?
계속 테스트하면 알 수 있겠지만. 그래도 맨땅에 해딩안하려고 비싼 돈 주고 강의 보는 건데... 좀 알려줘.. ㅠㅠ

또 하나 궁금한 점은, Kafka의 이런 로그 파일 구조가 다른 메시징 시스템과 비교해서 어떤 장단점이 있는지에 대해서다.
적어도 시간 기반 인덱스는 장점이 확 있어 보이지만... 다른 부분에 대한 부분은 설명이 조금 부족해 보인다.

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

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

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

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

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

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

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

지난 시간에 배웠던 여러 방식중에 Sticky 에 대해 더 집중적으로 공부하는 파트이다.

요약

 Consumer Rebalancing Process : 시간 흐름에 따른 Consumer Rebalance 과정

• Consumer들이 JoinGroup 요청을 Group Coordinator 에 보내면서 리밸런싱이 시작
• JoinGroup의 응답이 Consumer들에 전송되고(Group Leader는 Consumer들 정보를 수신)
• 모든 구성원은 Broker에 SyncGroup 요청을 보낸다
  • Group Leader는 각 Consumer의 Partition 할당을 계산한다
  • 계산 결과를 Group Coordinator에게 전송한다
• Broker는 SyncGroup 응답에서 각 Consumer별 Partion 할당을 보낸다.

Eager Rebalancing 프로토콜:  오랫동안 사용되었던 방식 →최대한 단순하게 유지하기 위해 만들어짐

• 각 구성원은 JoinGroup 요청을 보내고 재조정에 참여하기 전에 소유한 모든 Partition을 취소해야 함
• 안전면에서는 좋지만 그룹의 구성원이 재조정 기간 동안 작업을 수행할 수 없는 단점
• "Stop-the-World"프로토콜

Incremental Cooperative Rebalancing Protocol

• 이전 Eager Rebalancing 프로토콜 보다 발전한 방식
• Revoke 할 Partition만 Revoke 하면 되지 않는가!!!
• 이상적인 Consumer Rebalancing 프로토콜
• 문제점 : Consumer는 자신의 파티션중 어느 것이 다른 곳으로 재할당되어야 하는지 알지 못함
•  

Cooperative Sticky Assignor

• Incremental Cooperative Rebalancing Protocol의 문제점 해결 : Rebalancing 2번 수행
  • JoinGroup 요청을 보내면서 시작하지만, 소유한 모든 Partition을 보유하고, 그 정보를 Group Coordinator에게 보냄
  • Group Leader는 원하는 대로 Consumer에 Partition을 할당하지만, 소유권을 이전하는 Partition들만 취소함
  • Partition을 취소한 구성원은 그룹에 ReJoin하여 취소된 Partition을 할당할 수 있도록 두 번째 재조정을 트리거
• Basic Cooperative Rebalancing Protocol:  Apache Kafka 2.4 에서 도입
• Incremental Cooperative Rebalancing Protocol: Apache Kafka 2.5 에서 도입
  • 빈번하게 Rebalancing되는 상황이거나
  • 스케일 인/아웃으로 인한 다운타임이 우려가 된다면,
  •  최신 버전의 Kafka(2.5 이상)기반으로 사용하는 것을 권장

Eager Rebalancing 프로토콜에 대해 배웠을 때는 좀 당황 스러웠다. 설명이 가장 단순하고 안전한 방식이라고 하는데 ... 모든 파티션을 취소하고 다시 할당한다니,  비효율의 끝판왕이 아닌가? 싶었다.
"Stop-the-World" 문제 때문에 실제 운영 환경에서는 문제가 될 수 있다는 걸 보고 걍 머리속에 지워버렸다..

바로 뒤의  Incremental Cooperative Rebalancing Protocol을 배웠을 때 정말 이거다 싶었다
필요한 파티션만 Revoke한다~ 얼마나 효율적인가.

하지만 위의 요약내용대로..  치명적인 이슈가 있었고 그걸 해결한 것이 오늘 주제인 Cooperative Sticky Assignor인 것이다.

처음에는 리밸런싱 2개로 위 치명적인 이슈가 해결된다는게 무슨 소린지 이해가 안되었는데.. 
강사님이 설명을 너무 잘해주셔ㅓㅆ다..  특히 위 필기 캡처에 잠깐 나온
Consumer A, B, C의 예시는 정말 좋은 예시이다.

또한 놀라웠던 부분은 Kafka가 계속해서 발전하고 있다는 것이다.
Apache Kafka 2.4, 2.5 버전에서 이런 새로운 기능들이 추가되었다는 걸 보고,
기술이 얼마나 빠르게 발전하는지 실감했고, 사실 지금은 얼마나 좋은 기능이 나왔을지 또 걱정도 된다..

늘 그렇지만 실무적 궁금증은 늘 목마르다.
Cooperative Sticky Assignor를 사용할 때 실제로 성능이 얼마나 향상되는지 수치로 나오면 좋을텐데..
 그리고 이런 복잡한 리밸런싱 과정에서 발생할 수 있는 에러 상황은 어떻게 처리하는지도 알려주었으면 좋겠는데..

그래도 전체적으로 봤을때  이 강의는  나에게  큰 도움을 주고 있다.
다 돌아다녀도 이렇게 깊은 내용을 이렇게 좋은 예제로 설명하는 것은 처음이다. 
늘 말했지만 패캠 강의답지 않게... 정말 잘만든 강의 같다...
물론 어렵지만.... ㅋ

계속 따라가다보면... 뭔가 배울 수 있을 듯

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

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

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

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

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

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

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

파티션 할당 전략(Partition Assignment Strategy)에 대해 대한 심화 학습이다.

요약

 파티션 할당 전략의 종류:

• RangeAssignor (기본)
• RoundRobinAssignor
• StickyAssignor
• CooperativeStickyAssignor
• 사용자 정의 Assignor

각 할당 전략의 특징:

• RangeAssignor: 토픽별로 작동하며, co-partitioning에 유리
• RoundRobinAssignor: 파티션을 균등하게 분배하지만, 재할당 시 일관성 보장 안 함
• StickyAssignor: 균형적 할당과 기존 할당 유지를 동시에 고려

각 전략의 장단점 비교 및 실제 동작 예시

• 강의 슬라이드에 단계별로 설명이 되어 있는데... 이건 너무 강의 노출인 것 같아.. 적었다 지운다.

파티션 전략에 대한 부분이다.가장 먼저 배운 RangeAssignor는 기본 인데,  토픽별로 작동한다는 게 신기하다.. 특히 'co-partitioning'이라는 개념이 있다는 걸 알게 됐는데, 같은 키를 가진 메시지들을 효율적으로 처리할 수 있다는 점이 포인트 인 것 같다. 실제로 배달 시스템 같은 곳에서 유용하게 쓰일 것 같다.

그 다음으로 배운 RoundRobinAssignor는 이름 그대로 돌아가면서 파티션을 할당하는 방식이다.. 처음에는 이게 제일 공평해 보였는데, 강의를 들으면서 아 존나 멍청했구나라는 걸 인지 했다.. 재할당이 일어날 때 기존 할당을 유지하지 않는다는 점이 단점이다.. 실제 시스템에서는 이런 변경이 성능에 영향을 줄 수 있다는 걸 알게 되고... 실력은 늘었지만..고민할 포인트는 많아졌다..

마지막으로 배운 StickyAssignor가 제일 역시 흥미롭다.. 이름처럼 '끈적끈적하게' 기존 할당을 최대한 유지하면서도 균형을 잡으려고 노력한다는 점이 좋아보인다.. 특히 실제 예시를 통해 설명해주셔서 이해하기 쉬웠다.. 특히 Consumer가 제거되었을 때 어떻게 재할당이 일어나는지 강사님이 보여주신 부분이 좋은 것 같다.

이 강의를 들으면서 가장 놀라웠던 점은 이런 심화내용의 깊은  세부적인 전략들이 실제로 시스템의 성능과 안정성에 큰 영향을 미친다는 것이다. 정말 처음에는 그냥 메시지를 주고받는 게 전부인 줄 알았는데, 이렇게 깊이 들어가보니 카프카가 얼마나 정교하게 설계된 시스템인지 알게 되는 것 같다.

여전히 실무 면에서는 궁금하다.

 예를 들어, 실제 프로덕션 환경에서는 어떤 할당 전략을 주로 사용하는지 궁금하다.
그리고 각 전략별로 성능 차이는 얼마나 날지도? 특히 대규모 시스템에서 이런 차이가 눈에 띄게 나타나는지 알고 싶다..
그래야 회사에 보고를 하고 투입을 하지

또 하나 궁금한 점은 사용자 정의 Assignor에 대한 거예요.
 강의에서는 간단히 언급만 되었는데, 실제로 어떤 경우에 사용자 정의 Assignor를 만들어 사용하는지,
 그리고 어떤 점을 고려해야 하는지 더 자세히 알고 싶어졌다. 실제 여러 예시를 보여줬으면 좋았을 것 같다...
뭐 열심히 배우다가 정 안되면 커뮤니티 질문 하면 되겠지..

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

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

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

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

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

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

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

Consumer Rebalance에 대한 심화 학습이다..

요약

• Consumer의 동작 방식:
  • Partition에서 메시지를 polling하고 offset 정보를 관리
  • 이전 기본 개념 다시 되짚어 보는 시간
• Consumer Group:
  • 동일한 group.id로 구성된 Consumer들이 하나의 그룹을 형성하여 작업량을 분할
  • 컨슈머 그룹의 컨슈머들이 작업량을 어느 정도 균등하게 분할하기에 자동으로 로드발란싱 효과가 이루어진다.
  • 동일한 토픽에서 컨슘하는 여러  컨슈머 그룹이 있을 수 있으며 각각 독립적으로 작동한다
• Partition Assignment:
  •  파티션을 컨슈머에 할당하는 전제조건 
    • 하나의 파티션은 지정된 컨슈머 그룹내의 하나의 컨슈머만 사용
    • 동일한 키를 가진 메시지는 동일한 컨슈머가 사용(파티션 수를 변경하지 않는 한)
    • 컨슈머의 파라미터중에 `partition.assignment.strategy`로 할당 방식 조정
    • 컨슈머 그룹은 그룹 코디네이터라는 프로세스에 의해 관리된다
• Consumer Group Coordination:
  •  Group Coordinator와 Group Leader의 역할을 설명한다
  • 그룹 코디네이터 선택 방법
    • 위에서 말했듯 각 컨슈머는 `group.id`로 카프카 클러스터에 자신을 등록
    • 카프카는 컨슈머 그룹을 만들고 컨슈머의 모든 offset은 컨슈머 offset topic의 하나의 파티션에 저장된다.
    • 이 파티션의 리더 브로커는 컨슈머 그룹의 그룹 코디네이터로 선택

왜  그룹 코디네이터가 직접 파티션을 할당하지 않는가?

• 카프카의 설계 원칙
  • 가능한 한 많은 계산을 클라이언트로 수행하도록
  • 브로커의 부담을 줄이는 것
  • 본연의 업무 집중

이번에는 그룹 Consumer Group Coordination에 대해 배우는게 핵심인 것 같다.
Group Coordinator와 Group Leader가 서로 협력하여 Consumer들에게 Partition을 할당하는 과정이 흥미롭다. 특히 Group Leader가 Partition 할당을 담당한다는 점을 기억하자. 그리고 카프카가 이렇게 클라이언트에게 많은 역할을 위임하는 이유가 Broker의 부담을 줄이기 위해서라는 설명도 납득이 가고 감탄한 부분이다..

Rebalancing에 대한 설명도 매우 좋았다..하지만 불필요한 Rebalancing을 피하는 조건이 너무 까다로운 것 같아 보인다.
Consumer가 그룹에 들어오거나 나가는 등의 변화가 있을 때 Rebalancing이 일어난다는 점을 인지 했고,
그리고 이 과정에서 일시적으로 메시지 처리가 중단될 수 있다는 점을 알게 되서 중요한 고민 포인트임을 인지했다..

Consumer Heartbeats 개념도 보면서 지금 업무에 어떻게 응용할 수 있는지 조금 떠올랐다.

마지막으로, 과도한 Rebalancing을 피하는 방법들을 배웠는데, 엄청 조건이 어렵다.
이 부분은 실제로 적용해보고 싶은데... 특히 Consumer Group 멤버를 고정하는 방법이나 여러 타임아웃 설정을 조정하는 방법들이 궁금하다

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

심화 공부 2번째 시간으로 장애에 대한 깊이 있는 내용을 다루고 있다.

요약

ISR(In-Sync Replicas) 관리

• 메시지가 ISR 리스트의 모든 Replica(복제본)에서 수신되면 Commit된 것으로 간주
• Leader는, Kafka Cluster의 Controller에 의해 모니터링되는, ZooKeeper의 ISR 목록에 대한 변경 사항을 유지
• 리더 브로커가 팔로워의 동기화 상태를 모니터링하며, 지연이 발생한 팔로워를 ISR 목록에서 제거
• n개 복제본 존재 시 n-1개 장애까지 허용 가능

리더 장애시 처리 절차

• 컨트롤러가 새로운 리더 선출
• 새로 선출한 Leader 및 ISR 정보는 ZooKeeper에 기록 → 컨틀롤러 장애로부터 보호하기 위해서
• 클라이언트 메타 데이터 업데이트를 위해 모든 Broker에 전파 → 클러스터 상태 갱신

분산 시스템을 배우며 내 주의력도 분산..

• 카프카의 강의를 들으면 분산 시스템의 복잡성을 배우는 동시에 내 머리속이 복잡해지는 것 같다.
• 계속적으로 주키퍼 클러스터가 나오는데 주키퍼가 없는 모드에서는 어떻게 되는지는 왜 설명을 해주지 않는걸까
• 특히 학습인증샷에 찍은 예제가 좋은데.. 지금까지 다왔던 단순 파티션 장애가 아닌 브로커 장애를 다루고 있다.
  • 4개 브로커, 4개 파티션, 복제 계수 3 환경에서의 장애 시나리오의 예시이며
  •  장애 브로커가 포함된 파티션의 리더 재선출 과정에 대해 다루고 있는데 어렵지만 슬라이드가 좋았다 ㅋ
• 일단 팔로워가 실패하는 것은 전혀 문제가 안된다
• 리더가 실패하는 경우 리더 새선출과 ISR 갱신 , 푸쉬 , 캐싱이 이뤄지는 부분이 핵심
• 리더가 선출 될때까지 해당 파티션을 사용할 수 없게 되는 부분으로 빠른 재선출이 필요해 보인다
• 리더 선출을 담당하는 컨트롤러의 장애시 주키퍼가 컨트롤러를 뽑는다고 기본 개념 시간에 배웠었는데..
  심화시간에는 해당 부분도 나올거라고 기대했는데 해당 부분은 없는 것 같아 아쉬운 부분
• 여튼 결론은 다음과 같아 보인다(맞나..)
  • Follower가 실패하는 경우
    • Leader에 의해 ISR 리스트에서 삭제됨
    • Leader는 새로운 ISR을 사용하여 Commit함
  • Leader가 실패하는 경우
    • Controller는 Follower 중에서 새로운 Leader를 선출
    • Controller는 새 Leader와 ISR 정보를 먼저 ZooKeeper에 Push
    • 그 후  로컬 캐싱을 위해 Broker에 Push

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

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

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

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

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

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

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

심화 첫시간이다. 기본개념에서 짚었던 프로듀서 컴포넌트의 동작방식과 배치 처리, 캐시등에 대해 상세히 설명하고 있다.

요약

Producer ACKS 설정: 0,1 all(-1)

• 프로듀서는 어떻게 카프카가 메시지를 잘 받았는지 알 수 있을까? 에 대한 궁금증이 해결되는 부분이다.
• `acks=0`:
  • 아예 ack가 없음
  • 빠른 전송이 우선이지만 메시지 유실 가능성이 존재한다.
  • 즉, 메시지 손실이 다소 있더라도 빠른 전송이 필요한 경우 사용(이런 경우가 필요할까..ㄷㄷ)
• `acks=1`(기본값):
  • 리더 브로커 확인 후 응답.
  • 리더가 프로듀서에 응답후에, 팔로워가 복제하기전에 리더 장애 시 데이터가 유실된다
  • At most once : 최대 한 번 보장
•  `acks=all`
  • all, -1 모두 동일
  • 메시지가 모든 Replica에 커밋되면 ack를 보냄
  • 모든 복제본 저장 확인하므로 리더 장애시에도 데이터 데이터 안전성 최대
  • 대기 시간이 더 길고 특정 실패 사례에서 반복되는 데이터 발생 가능성
  • At least onece : 최소 한 번  보장

Producer  Batch처리

• 메시지를 모아서 한 번에 전송
• RPC(Remote Procedure Call)수를 줄인다 
• Broker가 처리하는 작업이 줄어들기 때문에 더 처리량이 올라간다.
• 배치 처리 옵션
  • `linger.ms`:
    • 메시지가 함께 배치 처리 될 때까지 대기시간
    • 기본값: 0ms   → 즉시 전송
  • `batch.size`:
    • 보내기 전 배치  최대 크기
    • 기본값: 16KB
  • 일반적인 설정
    • `linger.ms`: 100
    • `batch.size`: 1000000(백만) → 97.77kb ≈ 100kb

메시지 순서 보장

• 가장 관심이 있던 부분이기도 하다.. rabbitmq에서 메시지 순서를 보장하면 완전 처리량이 떨어지기 때문에
• 진행중(in-flight: 네트워크중, bulk에서 묶이고 있는 중)에 여러 요청을 retry → 순서가 변경될 수 있음
• ex:
  • 기본값 `max.in.flight.requests=5` 상태 → batch0~ batch4까지 나감
  • batch0이 실패했지만 batch1이 성공하는 경우 batch1이 먼저 commit log에 추가 되어 순서가 달라짐
  •  
• `enable.idempotence=true` 설정 (강의에 는 실패부분만 있어서 인터넷 검색 겁나게 함)
  
  • Idempotence(멱등성)
  • 프로듀서가 동일한 메시지를 여러번 전송하더라도
    브로커에 해당 메시지가  정확히 한 번만 저장되도록 보장.
  • 중복메시지 방지와, 메세지 순서 보장 
  • 하나의 배치가 실패하면?
    • 같은 파티션으로 들어오는 후속 배치들도 `OutOfOrderSequenceException`과 함께 실패
  • 동작방식
    • 브로커에 고유한 PID 할당
    • 메시지 전송시 순차적 SeqNo
    • 브로커는 각 파티션별로 PID+SeqNo를 Trace → 중복 메시지 거부
  • 재시도 안정성 높음:
    • 네트워크 장애, 브로커 장애가 발생해도 안전하게 재시도 및 중복 없는 데이터 처리
  • 단점
    • 브로커가 PID+SeqNo Trace 및 관리 → 추가적 오버헤드
    • 고성능시 처리량 감소, 지연시간 증가
    • 세션 제한 : 단일 프로듀서 세션내 보장
      
      • 프로듀서가 재시작 되면 새로운 PID가 할당 → 이전 세션의 멱등성이 유지되지 않음
      • 해결법 : Kafka 트랜잭션 기능을 추가적으로 사용(이런 것도 있네...)

Page Cahe

• 메시지는 파티션에 기록되고 파티션은 Log Segment File로 구성된다.
• 성능을 위해 Log Sementsms OS Page Cache에 기록된다
  • OS Page Cache
    • OS에서 Disk I/O를 최적하기 위해 사용되는 영역
    • 파일 읽을 때 캐시에 저장 → 동일 파일 접근시 디스크 대신 메모리에서 읽음 → 속도 향상
    • 쓰기 → 메모리 캐시에 저장 → 배치로 delayed write 
  • 카프카 관점
    • 카프카 브로커가 로그 세그먼트 파일을 i/o 할때 캐시를 통해 디스크 접근 없이 메모리 에서 빠르게 처리
    • 카프카는 로그를 순차적으로 씀 → 배치 디스크 write에서 쓰기 성능 대폭 향상
    • 캐시로 IO가 전체적으로 최소화
    • 주기적 Flush → 데이터 지속성 확보
  • Zero Copy → 고성능
    • 네트워크 버퍼에서 Page Cache로 CPU개입과 User Space 복사 없이 직접 카피
    • 엄청난 처리량, Broker Heap 메모리 절약

2주차..

• 2주차 에 기본개념을 끝내고 심화 1강...
• 파도파도 새로운 것이 엄청 나온다...
• Zero Copy가 정확히 어떤 방식으로 동작하는지 더 자세한 예시가 있었으면 좋았을텐데.. 내가 이해한게 맞는지 모르겠다.
• 기본값이 아닌 일반적인 설정값을 제시해줘서 너무 감사했다..
• 배치 처리 관련 파라미터(linger.ms, batch.size)에 대해 기본값 만 나와있고, 실제로는 해보면서 바꿔가야한다고 했는데..
  실무에서 어떻게 최적화하는지 나중에는 알려주겠지?? 사실 나는 이게 필요한데..마음이 급하다.
  예를 들어서 Iot기기에서 초당 수만 건의 micro메시지를 보낼때와, 커다란 배치 처리의 대용량 로그 파일 전송때 완전 다를 거 같은데
  극단적인 케이스때의 값을 알려주면 도움이 될거 같은데..이건 삽질을 해야 할까?
• 아직까지는 계속 개념 공부라... 넘어야 할 산이 많고, 따라가기도 힘들다.
• 환급챌린지는 단순하게 똭 결과가 나오는 강의가 좋은데.. 너무 어려운 걸 선택했다..
  후회해도 늦었지만..
• 그래도 돈이 무서워서 열심히 하게 되고 있다... 늘 말하듯 강의 질은 좋은 편이다.(패캠답지않게;)

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

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

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

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

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

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

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

이번 강의는 지난 번의 Replicationrhk 연관된 ISR에 대한 내용이다.. (아마도.. 너무 어렵다..)

요약 (앞 강의랑 연관이 되서 개념 정리부터 ..)

Partition Replication 구조

• Leader Partition: 모든 읽기 쓰기 작업 처리
• Follower Partition:  Leader의 Data를 비동기적으로 복제
• ISR
  • In-Sync Replicas
  • 장애 복구를 위해 리더와 팔로워 파티션이 동기화된 상태를 유지하는 메커니즘
  • High Water Mark 까지 동기화가 완료된 Replication Group
  • Leader 장애시 새로운 Leader를 선출하는데 사용
  • 고가용성을 보장

ISR 옵션

• `replica.lag.max.messages`
  • 해당 옵션의 수까지의 차이가 벌어지지 않은 Follower와 Leader를 ISR로
  • 문제점 : 메시지 유입량이 갑자기 늘어날 때
    
    • 예시 : 평상시 초당 3메세지 이하의 부하에 옵션은 5일때
    • 갑자기 초당 10메세지 이상인 경우 Follower는 Peek에 의한 잠깐 지연이 있을 뿐 정상 작동
    • 하지만 Peek에 이한 지연으로 5이상 차이가 나면 OSR로 잘못 판단하게 되어버림
    • 운영중에 불필요한 에러 발생과 그로 인해 불필요한 Retry가 유발된다
• `replica.lag.time.max.ms`
  • 사실상 유일한 옵션
  • 기본값 10초
  • Follower가 Leader로 Fetch 요청을 보내는 인터벌을 체크하고 Follower의 지연 시간을 판단한다.
  • 기본값인 경우 Follower가 Leader로 Fetch 요청을 10초(10000ms)내에만 요청하면 정상으로 판단
  • 벗어나면 ISR에서 제외 → OSR(Out-of-Sync Replica) 상태 전환
  • 컨트롤러가 주키퍼를 통해 ISR 목록 실시간 갱신

컨트롤러(Controller)

• 카프카 클러스터의 브로커 중 하나가 컨트롤러가 된다
• 컨트롤러는 ZooKeeper를 통해 Broker Liveness(죽었는지 살았는지)를 모니터링 한다.
  (그럼 4.2 부터 쓰는 ZooKeeper를 안쓰는 모드에서는 어떻게 하지?
• 컨트롤러나는 리더와 Replica 정보를 클러스터 내의 다른 브로커에게 전달
• 컨트롤러는 ZooKeeper에 Replicas 정보를 유지한 다음
  더 빠른 엑세스를 위해 클러스터의 모든 브로커들에게 동일한 정보를 캐시함
• 컨트롤러가 리더 장애시 Leader Election 수행
• 컨트롤러가 장애가 난다면?
  • 다른 Active 브로커중에서 재선출
  • ZooKeeper가 하게 됨
    

• Message Commit 과정
  • 프로듀서가 리더에 메시지 전송(Log End Offset 증가
  • 팔로워의 Fetcher 스레드가 주기적으로 데이터 가져옴
  • 모든 ISR 구성원이 메시지 수신 시 High Water Mark 이동
  • 커밋된 메시지만 컨슈머가 읽을 수 있음
• 어제 후기 쓸때 딱 궁금해한 ... 그럼 Leader는 어떻게 뽑는가에 대한 답변이다.
• 개념이 생각보다 어렵다...
• 어제는..DB Replica의 개념에서 그냥 복제본을 더 여러개 만드는 정도로 이해했었는데.. 너무 단순하게 생각...
• 실제로는 리더와 팔로워 간의 실시간 동기화 상태를 추적하고 장애 시 빠르게 대응하는 정교한 원리가 숨어있다.
• 특히 메시지 랙의 문제점과  그 해결책으로 `replica.lag.time.max.ms` 설정을 통해
  네트워크 지연을 유연하게 처리하는 부분이 들어온다.
• 강사님이 천천히 설명을 해주는데 진짜 머리에 안들어온다.
  진짜 강의 공유자료인 슬라이드의  그림이 없었다면..아직도 이해를 못했을 듯
• 강의 슬라이드에서 커밋 메시지 과정은 정말 하나하나 슬라이드를 나눠주셔서
  커밋된 메시지와 아직 복제 중인 메시지를 시각적으로 구분하는 방식이 머릿속에 잘 정리되더라.
• 컨슈머가 항상 안전한 데이터만 읽을 수 있도록 보장하는 메커니즘이 녹아 있다.
• 카프카가 복잡한 문제들을 해결하는 것을 알게 되고 학습하게 된건 좋은데 계속 분산 시스템의 복잡성을 더 느끼게 된다.
• 지금 이해 단계인데 따라가기가 버겁다... 과연 내가 따라갈 수 있을 것인가...

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
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처럼 데이터 센터의 물리적 구조까지 고려해서 복제본을 배치할 수 있다는 부분이 대단하다. 반대로 그 부분 까지도 고민하고 신경을 써야한다는 점에서는 짜증이 난다.
• 역시 대규모 시스템은 그냥 이뤄지지 않는다.
• 언젠가 대규모 시스템을 직접 설계하고 구현하고 싶다는 부분에서 해당 강의 수강을 시작했는데..
  사실 벌써 기가 죽은 부분도 존재한다... 좋은 기술인데 아직은 어렵고 낯설다..