3.5 KiB
3.5 KiB
260309 23장애시 24서버 임시진입면승격 아이디어
tags: [infra, 23-server, 24-server, failover, ingress, ideas]
상위 원칙:
문제
- 현재 외부 진입은 공유기
80/443이 23 서버를 바라보고, 23 서버에서nginx -> robeing-gateway -> 24 실행계구조로 동작한다. - 이 구조는 역할 분리에는 맞지만, 23 서버 장애 시 외부 진입이 한 번에 끊기는 단일 장애 지점 문제가 있다.
gateway만 24로 옮기면 제어면과 실행면이 다시 섞이므로 구조상 이득이 작다.
목표
- 평시에는
23=진입/제어,24=실행구조를 유지한다. - 다만 23 서버 장애 시에는 24 서버가 임시로
nginx + gateway역할까지 승격 받아 외부 서비스 연속성을 제공할 수 있게 한다. - 이 구조를 상시 운영이 아니라 장애 대응용
임시 진입면 승격아이디어로 남긴다.
가능한 방향
1. 24 서버 대기 nginx + gateway 준비
- 24 서버에 평소에는 외부 미노출 상태의
nginx,gateway구성을 미리 준비한다. - 23 장애 시 공유기
80/443포워딩만 24로 바꿔 임시 승격한다. - 장점: 현재 구조를 크게 깨지 않고 연속성을 높일 수 있다.
- 단점: 공유기 전환, 인증서, upstream 동기화 절차를 따로 관리해야 한다.
2. 외부 진입면 완전 이중화
- 23과 24 모두가 상시 외부 진입을 받을 수 있게 하고, 장애 시 자동 또는 반자동 전환한다.
- 장점: 더 강한 연속성 확보 가능
- 단점: 인증서, DNS, 헬스체크, 데이터 동기화, 운영 복잡도가 크게 증가한다.
3. 수동 런북 기반 반자동 전환
- 24 서버에 최소한의 대기 구성을 두고, 장애 시 문서화된 런북에 따라 사람이 포워딩과 서비스 승격을 수행한다.
- 장점: 초기 구현 부담이 가장 낮다.
- 단점: 사람 개입 속도와 정확도에 의존한다.
권장 방향
- 1차는
수동 런북 기반 반자동 전환으로 시작하는 것이 현실적이다. - 운영 리허설이 쌓이면
24 서버 대기 nginx + gateway 준비까지 올리고, 그다음에야 자동화 여부를 판단하는 것이 맞다. - 핵심은
gateway를 24로 상시 이전하는 것이 아니라,23 장애 시 24가 임시 진입면을 대신할 준비를 갖추는 것이다.
먼저 확인할 것
- 공유기에서
80/443포워딩 대상을 장애 시 신속히 바꿀 수 있는지 - 24 서버에
nginx, 인증서, gateway 설정을 동일하게 재현할 수 있는지 - 23의
auth-server,DB,OpenSearch까지 장애 범위에 포함되는지, 아니면 진입면만 죽는 시나리오인지 - 장애 시 24가 직접 바라봐야 할 upstream과 SSOT 환경값이 무엇인지
- 장애 리허설을 어떤 주기로 수행할지