문제상황
- 사이트 점검상황일때 기존에 접속해있던 사람들과, 새로 접속하는 사람들을 모조리 점검페이지로 리다이렉트 시켜야함
- 점검 페이지는 점검시간을 포함해야함
- was 서버가 죽거나 배포중인 상황에도 동작해야함
- 인스턴스가 죽어도 동작해야함
- Elastic Beanstalk을 사용하여 Elb가 있고 auto scaling이 되어있음 - FE가 Spa 임
어떻게 하면 좋을까?
1번 아이디어
우선 처음 생각한 방법은 인스턴스가 죽지않는다는 가정하에,
인스턴스 내에 html 점검 파일을 하나만든다.
쉘스크립트도 하나만든다음에 인자로 점검 시작시간, 끝나는시간을 받은후 명령어를 입력했을때 nginx에게 시그널을 주고 (직접 혹은 특정위치에 파일을 생성해서 파일 여부에 따라서 nginx가 판단하는 등) html 파일에 시작, 끝나는 시간을 넣는다.
모든 요청전 Nginx가 쉘스크립트의 실행 여부를 판단한후 점검이라고 판단되면 html파일을 반환한다.
-> 문제점은 다음과같았다
- 애초에 프론트가 spa여서 html을 받아도 브라우저에서 해당 html을 로드하지않는다.
- 인스턴스가 죽으면 동작안한다.
2번 아이디어
점검중인 status를 확인하는 별도의 인스턴스를 생성한후 모든 요청을 해당 서버를 한번 거쳐서 확인한다.
점검확인 방법은 백엔드 인스턴스와의 별도의 통신보다는 개발자가 db에 점검 데이터를 밀어넣으면 그걸 체크한다.
단 redis 같은걸 이용해서 인메모리 방식으로 db부하를 줄인다.
-> 문제점
방법은 심플하지만 일단 너무 인스턴스 하나를 통채로 만드는게 너무 불필요하고, 모든 요청을 점검서버가 확인한후 request url 및 data를 다시 백엔드 서버로 리다이렉트해줘야하는데 만들기 귀찮다.
3번 아이디어
인스턴스를 새로 띄우는건 너무 과한거같으니 람다를 이용해서 해보자.
-> 매호출마다 람다가 사용되는데 비용이 ec2보다 더많이든다.. 포기
4번 아이디어
그냥 프론트 코드를 에러페이지 하나만 있는걸로 재배포해버리면 되지않냐. 그러면 무조건 새로 접속한 사람들은 에러페이지 밖에 없으니깐 그쪽으로 가지않냐? 맞는말이다.
근데 이거의 문제는 기존에 계속 접속해있던사람들의 경우는 배포되기 전 메인 프론트코드가 이미 마운트된 상태기때문에 백엔드 서버에 접근할수가있음.
5번아이디어
route 53의 가중치 라우팅을 이용해서 점검중일경우는 메인서버에 0, 점검중이 아닐때는 255를 준다음 점검중 일때만 람다가 처리하게 만들면되지않냐?
하지만 결국 spa여서 점검 페이지를 제공하는거는 프론트의 정적파일이어야하고, html을 보내면 안되니깐 503 status랑 시작시간, 점검시간만 넘겨주면
프론트엔드의 미들웨어가 503 에러를 캐치해서 점검페이지로 보내면되진않냐?
-> 말되긴하다.
따라서 람다의 경우 503에러랑 점검 시작시간, 마감시간만 넘겨주면 프론트가 알아서 처리하면된다.
spa기 때문에 첫 로드때 소스를 브라우저에서 다 가져올테니깐 메인서버가 죽어도 점검페이지로 리다이렉트가 가능하다.
-> 문제점
근데 너무 개발자가 귀찮은게, route 53에 들어가서 가중치도 바꿔야하고, 람다함수의 시작,마감시간도 직접 수정해야함.
따라서 이 모든 과정을 aws cli에서 명령어로 처리하게 만들기 위해서
route 53의 가중치 바꾸는걸 람다에서 같이 수행하게 만든다음, 해당 람다를 cli에서 호출하고 시작,마감시간을 인자로 주면되지않겠냐?
라는 생각에 도달함. 근데 가민히 생각해보니깐 이것도 귀찮아서 고민을 더해봤다.
6번아이디어
cloudfront에 function이 있음. 근데 얘가 할수있는 일은 cloudfront로 들어오는 request 혹은 response 를 가로채서 특정 헤더나, 내용을 붙인다음 origin 혹은 브라우저에게 넘겨줄수있음. 오 그렇다면 그냥 route에서 가중치 라우팅 할필요없이 모든 점검 관련된거를 cloudfront function에서 판단하고 점검인경우 그냥 직접 브라우저에게 Response 객체를 만들어서 503 에러를 반환하면 되는거아닌가? 정답이다.
이렇게 하면 cli를 쓰지않아도 cloudfunction에만 접근해서 시작시간, 점검시간, 점검상태를 넘겨주면 알아서 점검일때 503을 반환할것이다!!
따라서 EB 앞단에 cloudfront를 붙이고, route 53이 cloudfront를 바라보게 만든다면 문제가 해결된다...!!
트래픽 흐름
아키텍처는 그렇다면 다음과같이 그려볼 수 있다.
이와 관련된 세팅구성 방법은 다음 글에서 다루겠다.
