본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
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를 사용할 때 실제로 성능이 얼마나 향상되는지 수치로 나오면 좋을텐데..
 그리고 이런 복잡한 리밸런싱 과정에서 발생할 수 있는 에러 상황은 어떻게 처리하는지도 알려주었으면 좋겠는데..

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

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