topic·partition 변경이 매우 많습니다. KRaft metadata 로그와 controller의 병목을 어떻게 관찰하나요?
꼬리 질문을 독립 문항으로 확장했습니다. 원래 문항에서 맥락 보기 →
잠깐, 답변을 보기 전에
먼저 내 말로 설명해 볼까요?
답변과 점검 포인트 펼치기답변 접기
01
구두 답변
정의를 외우기보다, 원리와 조건을 연결해 설명해 보세요.
metadata 변경은 controller의 합의 로그·상태 전파·broker 반영에 부하를 줄 수 있습니다. 데이터 생산 TPS와 topic 생성·partition 변화율을 별도 지표로 봅니다.
많은 작은 topic·잦은 churn이 메모리·디스크·복구 시간에 미치는 영향을 측정합니다. controller 과반 장애와 data leader 장애를 나누어 시험하고 quota·변경 예산을 둡니다. 버전별 기능·운영 권장을 확인합니다.
02
득점 포인트
이해가 드러나는 지점을 확인해 보세요.
- metadata 변경은 controller의 합의 로그·상태 전파·broker 반영에 부하를 줄 수 있습니다. 데이터 생산 TPS와 topic 생성·partition 변화율을 별도 지표로 봅니다.
- 버전별 기능·운영 권장을 확인합니다.
03
감점 포인트
놓치기 쉬운 조건과 오해를 짚어 보세요.
- 다음 핵심 구분을 반대로 설명하거나 성립 조건을 생략한다: metadata 변경은 controller의 합의 로그·상태 전파·broker 반영에 부하를 줄 수 있습니다.
04
더 파고들 거리
하나 더 질문하며 이해의 범위를 넓혀 보세요.
득점·감점 포인트는 학습용 자기 점검 기준이며, 특정 회사의 실제 채점표가 아닙니다.
원리부터 공부하고 싶다면
답변을 보충하는 개념·예제·슈도코드를 읽어 보세요.