기본적인 ELB v2 사이트가 있습니다. 아직 클러스터링이나 아무것도 없습니다. AWS에 익숙하지 않습니다.
내 스택은 nginx / uwsgi / django + 다른 서비스입니다.
어떤 이유에서든 다운 타임이있을 때마다 "죄송합니다. 웹 사이트가 다운되었습니다 ..."스타일 페이지 (계획된 다운 타임을 업데이트 할 수있는 사용자 정의 텍스트는 보너스입니다!)에 대한 생각이 있는지 궁금합니다. 인스턴스가 빨간색입니다. 아마존 이이 기능을 제공하는 것 같지 않습니다. 아무것도 없습니까? 주 인스턴스가 빨간색이거나 다른 경우에만 제공되는 별도의 초소형 인스턴스를 만드는 방법이 있습니까?
감사!
답변:
여기서 간단하고 멋진 솔루션은 ELB를 CloudFront 뒤에 배치하는 것입니다.
오리진 서버 (이 경우 ELB)에서 5XX 오류 (또는 원하는 경우 4XX)가 발생하는 경우 CloudFront는 사용자 지정 오류 페이지를 반환 할 수 있습니다.이 오류 페이지 는 CloudFront를 가리키는 두 번째 오리진을 생성하여 S3 버킷에서 가져 오도록 구성 할 수 있습니다. 버킷에 캐시 동작 라우팅 (예 : 캐시) /errors/static/*을 생성합니다.
이것은 중요한 이유로 인해 Route 53 장애 조치보다 더 효과적입니다. 치명적인 결함입니다. DNS TTL은 관련이 없습니다.
기본적으로 브라우저에 DNS 항목이 있으면 일반적으로 모든 브라우저 창이 닫힐 때까지 계속 사용하려고합니다.
따라서 사이트에 이미 방문한 방문자를 위해 사이트가 중단되면 대체 사이트를 보지 못할 것입니다.
더군다나, 방문자가 다운 된 상태에서 처음으로 사이트를 방문하면 모든 브라우저 창을 닫을 때까지 유지 보수 페이지에 "고착"됩니다.
장애 조치 DNS를 사용하는 경우 장애 조치 대상이 여전히 응용 프로그램 인 경우에만 가능합니다.
필요하지 않은 경우 CloudFront의 캐싱을 해제 할 수 있습니다.
다운 된 상태에서 복구하려는 사이트 망치질을 종료하려면 CloudFront의 오류 캐싱 TTL을 0이 아닌 값으로 구성 할 수도 있습니다. 오류가 발생하는 특정 페이지의 경우 오류 페이지가 계속 표시되며 오류 CachingTTL이 만료 될 때까지 해당 페이지에 대한 추가 요청으로 서버를 방해하지 않습니다.
Route53 DNS 및 장애 조치 라우팅을 사용하십시오 . 단일 페이지 정적 웹 사이트를 호스팅하는 S3 버킷을 얻을 수 있어야합니다. ELB로만 할 수 있다고 생각하지 않습니다.
아마존에는 블로그 게시물이 있습니다 .
업데이트 : Michael이 말했듯이 브라우저 DNS 캐싱에는 단점이 있습니다. 자세한 내용은 그의 대답을 참조하십시오. Route 53은 CloudFront보다 간단한 옵션 일 수 있지만 CF에는 다른 장점, 성능이 있으며 일부 사용 사례에서는 비용을 낮출 수 있습니다.
CloudFront 및 Route53을 포함한 여러 솔루션이 이미 언급되었습니다. CloudFront는 탁월한 솔루션이며 경험상 전혀 속도가 느려지지 않았지만 추가 비용이 발생합니다. Route53에는 이미 언급 한 DNS 캐싱 문제가 있습니다.
ALB가 사용자 정의 오류 페이지를 즉시 지원할 때까지 (발생할 수도 있고 그렇지 않을 수도 있음) 최근 ALB 고정 응답 발표 후 새로운 해결책 이있을 수 있지만 지적하지는 않습니다. 일시적으로 추가하는 Lambda 함수를 설정할 수 있습니다 '오류 페이지'내용으로 고정 된 응답을 제공하는로드 밸런서에 대한 규칙.
Lambda를 작성하는 것 외에도 Route53 상태 확인 또는로드 밸런서 대상 그룹 상태 확인 (아마도 CloudWatch 경보-> SNS를 통해)을 통해 '켜기'및 '끄기'를 트리거 할 수있는 방법을 찾아야합니다. > Lambda).
간단하지는 않지만 일단 설정하면 잘 작동합니다!
@Tim 및 @Micheal이 작성한 것처럼 Route53 DNS 및 페일 오버 라우팅 또는 사용자 지정 오류 페이지 와 함께 CloudFront를 선택할 수 있습니다 . 두 방법 모두 장단점이 있습니다.
Cloudfront를 아직 사용하지 않는 경우 Route53이 더 간단한 솔루션이라고 생각합니다. ELB 통합을위한 더 간단한 방법이 포함 된 AWS에서 업데이트 된 블로그 게시물 을 참조하십시오 .
CloudFront는 설정이 훨씬 복잡하며 모든 업데이트에 약 15 분이 소요됩니다. Cloudfront는 또한 예상대로 캐시하므로 Route 53의 DNS 캐시 문제보다 응답 속도가 느린 지 확실하지 않습니다.
ELB 웹 사이트가 SSL에만 응답하는 경우 AWS 블로그 3에 설명 된대로 간단한 S3 솔루션을 사용할 수 없습니다 . 이 경우 SSL을 추가하기 위해 S3 버킷 앞에 Cloudfront를 추가해야하므로 DNS 장애 라우팅 솔루션이 더욱 복잡해집니다.