docs: 📝 [Chapter 07] 신뢰성 있는 데이터 전달 (장애상황 시나리오)

_posts/kafka/2025-01-04-chapter07.md

@@ -22,15 +22,15 @@ tags: [카프카 핵심가이드]
 
 ## **3. 시나리오2: 카프카 브로커1(`kafka-docker-kafka-1`) 장애 발생 🚫**
 
-1. `localhost:9092`에서 실행 중인 `kafka-docker-kafka-1` 컨테이너가 장애를 발생시키거나 종료됨
+1. `localhost:9092`에서 실행 중인 `kafka-docker-kafka-1` 컨테이너가 장애가 발생하거나 종료됨
 2. 프로듀서와 컨슈머는 여전히 `localhost:9093` 브로커에 연결하여 메시지를 주고받을 수 있음
 3. 메타데이터 갱신이 이루어져 클라이언트는 새로운 브로커 정보를 인식하고, 장애가 발생한 브로커를 제외한 상태에서 정상적으로 작업을 계속할 수 있음
 4. 카프카 클러스터는 장애가 발생한 브로커의 파티션 리더를 `localhost:9093`에 있는 브로커로 전환함
 5. 이로써 클러스터는 장애 발생 후에도 정상적으로 메시지를 처리할 수 있음
 
 ## **4. 시나리오 3: 카프카 브로커 1 복구 🔄**
 
-1. `localhost:9092`에서 실행 중인 `kafka-docker-kafka-1` 컨테이너가 복구되거나 재시작됨
+1. `localhost:9092`에서 실행 중인 `kafka-docker-kafka-1` 컨테이너가 복구되거나 다시 시작됨
 2. 클라이언트는 `localhost:9092` 브로커를 다시 사용할 수 있게 되며, 메시지 전송과 수신이 정상적으로 이루어짐
 3. 복구된 브로커는 카프카 클러스터의 일부로 자동으로 다시 참여함
 
@@ -309,12 +309,13 @@ spring:
 **기대와 다른 결과가 발생한 원인 분석 (추측 🤔)**
 
 - **메타데이터 갱신 지연**
-  - 클라이언트가 장애 브로커(`localhost:9092`)를 감지하고 다른 브로커(`localhost:9093`)로 전환하려면 메타데이터가 최신 상태여야 하지만, 갱신이 지연되어 전환 실패
-  - 메타데이터 갱신 주기가 너무 길거나, 갱신 요청이 장애로 인해 처리되지 않았을 가능성
+  - 클라이언트가 장애 브로커를 감지한 후 다른 브로커로 전환하려면 최신 메타데이터가 필요함
+  - 장애로 인해 메타데이터 갱신 요청이 처리되지 않았을 수도 있음
 
 - **파티션 리더 전환 실패**
-  - `localhost:9093`이 새로운 파티션 리더로 전환되지 않았거나, 클라이언트가 새로운 리더 정보를 받지 못해 메시지 전송 실패
-  - 이는 클러스터 내부의 리더 선출 지연 또는 클라이언트 메타데이터 갱신 실패 때문일 가능성
+  - `localhost:9093`이 새로운 파티션 리더로 전환되지 않았을 가능성이 있음
+  - 클라이언트가 새로운 리더 정보를 받지 못해 메시지 전송에 실패했을 수 있음
+    - 이는 클러스터 내부의 리더 선출 지연 또는 클라이언트 메타데이터 갱신 실패 때문일 가능성 있음
 
 
 ## **8. 시나리오3 실행 - 카프카 브로커1 복구 🔧**
@@ -466,9 +467,12 @@ Disconnecting from node 0 due to request timeout
 request.timeout.ms: 600000
 ```
 
-**예상결과** : 브로커의 응답 지연이 60초 이내일 경우 타임아웃 오류가 발생하지 않음
+**예상결과**
+- 네트워크 지연이 30초라고 가정하고 브로커의 응답 지연 임계값을 60초로 설정했음
+- 타임아웃 오류 발생안하지 않을까..?
 
-**[실패] 타임아웃 오류 발생** → 이론적으로는 될 것 같았는데.. 안된다
+**기대와 다른 결과**
+- 타임아웃 오류 발생
 
 ```bash
 org.apache.kafka.common.errors.DisconnectException: null