Update Technology Post "AWS EC2 기반 부하 테스트를 진행하며 시스템 아키텍처 및 성능 개선하기"

Author: devFancy

_posts/2025-12-30-spring-boot-coupon-system-performance-improvement.md

@@ -521,6 +521,23 @@ Consumer Lag이 10만 단위에서 1천 단위로 개선되어 유입 속도와
 - Topic 설정: 브로커가 2대인 상황에서 데이터 무결성을 보장하기 위해 `replication.factor=2`, `min.insync.replicas=2`로 설정했습니다.
   이를 통해 브로커 한 대가 다운되더라도 데이터가 유실되지 않도록 조치했습니다.
 
+> 2026.01.30 추가 - 2개의 브로커 구성 시 `min.insync.replicas` 설정의 문제점과 해결 방안
+
+- 문제 상황 및 원인 분석: 운영 환경에서 브로커 2대 중 1대가 다운되면, 프로듀서가 메시지를 보낼 때 다음과 같은 상황이 발생하게 됩니다.
+  - 브로커 1대가 다운됨에 따라, 해당 토픽의 ISR(In-Sync Replicas, 동기화된 레플리카) 개수가 **1개**로 줄어듭니다.
+  - 이때 리더 브로커는 설정된 `min.insync.replicas=2` 조건과 현재 ISR 개수(1개)를 비교합니다.
+  - 결과적으로 현재 ISR는 1개이고, 최소 요구 조건(2개)을 충족하지 못하므로, 브로커는 프로듀서의 쓰기 요청을 거부합니다.
+- 에러 로그 확인: 이런 경우 프로듀서 쪽인 API 서버에서 다음과 같은 예외가 발생하며 서비스 장애로 이어지게 됩니다. (브로커 -> 프로듀서에게 에러를 뱉음)
+  - Error Message: `org.apache.kafka.common.errors.NotEnoughReplicasException: Messages are rejected since there are fewer in-sync replicas than required.`
+  - 결과적으로 안정성을 위해 브로커를 2대로 늘렸음에도 불구하고, 설정값을 잘못했기 때문에 단일 브로커일 때보다 가용성이 떨어지는 **역설적인 상황**이 발생하게 됩니다.
+
+- 해결 방안: 이를 해결하기 위해서는 현재 **`t3.medium` 이라는 한정된 자원**(최대 브로커 2대)에서 다음과 같이 해당 방안을 떠올려볼 수 있습니다.
+  - 브로커 2대 환경에서 가용성을 보장하려면 **`min.insync.replicas` 값이 반드시 1이여야 합니다.** 이렇게 하면 브로커 1대가 죽더라도 남은 1대가 메시지를 받아내므로 서비스 중단을 막을 수 있습니다.
+  - 참고) 가장 이상적인 방법은 브로커를 3대로 증설(`replication.factor=3`, `min.insync.replicas=2`)하는 것입니다.
+  - 하지만 이는 트래픽 규모와 인프라 비용을 고려해야 하므로, 향후 서비스 성장에 맞춰 서버 사양 증설과 함께 고려하기로 결정했습니다.
+
+---
+
 두 번째로 프로듀서와 컨슈머의 Config 값을 튜닝하여 안정성을 높였습니다.
 
 - Producer: `batch.size`를 64KB에서 32KB로, `linger.ms`를 10ms에서 5ms로 줄여, 처리량보다는 전송 지연 시간을 줄이는 방향으로 조정했습니다.