feat: 다중 애플리케이션 인스턴스와 Nginx Failover 구성

[KimGyeongLock]

변경 사항

• Spring Boot 애플리케이션을 App1, App2 두 인스턴스로 구성
• Nginx Round Robin 기반 요청 분산 적용
• GET 리다이렉트 요청의 upstream 장애 시 다른 인스턴스로 재시도
• 각 App에 서로 다른 Snowflake nodeId 할당
  • App1: nodeId=1
  • App2: nodeId=2
• Prometheus에서 App 인스턴스별 지표 수집
• 다중 인스턴스 ID 생성 및 App Failover 테스트 추가

Snowflake 다중 인스턴스 검증

두 애플리케이션에 서로 다른 nodeId를 할당하고
Nginx를 통해 동시 생성 요청을 전달했다.

테스트 과정에서 Docker 환경의 시스템 시간이 일시적으로 역행하는
Clock Rollback을 확인했다.

• App1: 8ms
• App2: 4ms

이전 timestamp로 ID를 생성하지 않고 작은 시간 역행에서는
시계가 마지막 생성 시각까지 복구되기를 제한된 시간 동안 기다리도록 처리했다.

큰 시간 역행은 ID 중복 위험을 방지하기 위해 실패 처리한다.

Failover 실험

100 VU로 GET Redirect 요청을 지속하면서 App1을 중단하고 다시 실행했다.

• 0~30초: App1, App2 정상
• 30~60초: App1 중단
• 60초 이후: App1 재시작 및 복구

결과

지표	결과
요청 수	446,850
평균 RPS	3,723.29
평균 응답 시간	26.68ms
p95	67.40ms
최대 응답 시간	2,922.56ms
실패율	0%
Check 성공률	100%

App1 장애 중 Prometheus up 값이 0으로 변경됐고,
App2가 단독으로 요청을 처리했다.

App1이 중단된 상태에서도 전체 요청 실패율 0%를 유지했으며,
App1 복구 후 다시 요청 처리에 참여하는 것을 확인했다.

설계 판단

POST 생성 요청은 upstream에서 처리된 이후 응답만 유실될 경우
다른 App으로 자동 재시도하면 중복 생성 가능성이 있다.

따라서 Nginx의 장애 시 자동 재시도는 멱등한 GET 리다이렉트 요청을 중심으로 적용했다.

한계

• Nginx와 MySQL은 여전히 단일 인스턴스로 SPOF가 남아 있음
• 로컬 Docker 환경에서 수행한 실험으로 실제 독립 서버 장애를 재현한 것은 아님
• Redis 자체의 고가용성 구성은 이번 범위에서 제외