화면 유지보수를 생각해봤어요.

화면이 어떻게 나오는지 유지하고 싶어서 많이 찾아봤어요.
사용 빈도가 높지는 않지만 정기적으로 대규모로 발표할 때가 적당하다고 생각합니다.
또 고장 발생 시 상대방에게 처리 중이라고 알릴 수 있어 이용자의 불안도 어느 정도 해소될 수 있다.
간단해 보이지만 사실 여러 가지 선택이 있기 때문에 조사한 내용을 하나하나 적어보겠습니다.
당사는 React,Next입니다.js 기반의 웹 응용 프로그램이기 때문에 주로 이런 상황에서의 모델이다.

전면 베이스(React 또는 Next.js 전제)

React + CloudFront + S3 + WAF

WAF를 클라우드 헬프데스크에 부착하는 방법입니다.
WAF의 사용자 정의 오류 응답에 따라 CloudFront는 다른 S3 구간에서 유지보수 페이지를 가져와 되돌려줍니다.

WAF 부착만 가능하며 조작이 간편함

프런트엔드 작업 필요 없음

서버 측 작업 시간 없음

Next.js + Vercel

Next.Vercel에 js를 배치한 경우Vercel은 유지 관리 모드를 지원하지 않으므로 직접 수행할 수 있습니다.

원본 파일에 유지보수 페이지를 만듭니다.

환경 변수에 NEXT 추가MAINT_MODE 등의 변수를 설정하고 boolean 등을 설정합니다.

이 값에 따라 분기 처리를 하고 쓰기를 유지보수 페이지로 옮깁니다.

유지 관리 모드로 설정한 경우 Vercel에서 환경 변수의 값을 덮어쓴 후 디버깅합니다.

조작에 시간이 걸리기 때문에 개발자가 유지 보수 과정에서 정식 환경을 확인할 수 없는 화면이 병목이다.

API 기반(ALB 사전 요구 사항)

ALB + ECS(orEC2)

ALB 다람쥐 규칙 및 고정 응답 기능을 사용하여 503을 반환하는 방법입니다.
수리 모드에서는 다람쥐 규칙의 우선순위만 바꿀 수 있다.

도메인당 규칙 결정

전환이 좀 번거롭습니다

ALB + WAF + ECS(orEC2)

ALB에 WAF를 첨부하는 모드에서 503으로 돌아가면 WAF 작업이 수행됩니다.

도메인당 규칙 결정

특정 IP 허용

WAF 부착만 가능하며 조작이 간편함

여러 플랫폼이 공유하는 API인 경우 WAF 설정만으로 간편하게 관리할 수 있음

감상

모든 서비스가 공통된 API 서버를 사용한다면 ALB의 고정 응답이나 WAF 첨부 파일이 비교적 수월할 것입니다.
요청원의 호스트를 축소하면 서비스를 한정할 수 있고, IP 화이트리스트를 설정하면 개발자가 유지보수 과정에서도 화면을 볼 수 있어 가능하면 API 서비스에서 진행한다.
각기 장점과 단점이 있지만 많이 배웠어요.

참고 자료