Rote 53에 대해 알아보자 (3)

 

Route 53 포스팅이 자꾸 길어지는데

앞의 내용을 쭉 따라오면 이해하기 쉬울 것이다😀👍

 

#0 라우팅 정책 종류 살펴보기 (2)

 

1. Latency-based(지연 시간 기반 라우팅 정책) :

지연 시간이 가장 짧은, 즉 가장 가까운 리소스로 리다이렉팅을 하는 정책

지연 시간에 민감한 웹사이트나 애플리케이션이 있는 경우에 아주 유용한 정책인데 지연 시간은 유저가 레코드로 가장 가까운 식별된 AWS region에 연결하기까지 걸리는 시간을 기반으로 측정된다.

설명을 위한 이미지

만약 두 개의 다른 region에 애플리케이션을 배포한다고 해보자.

ap-southeast-1과 us-east-1에 각 하나씩 배포한다.

유저는 세계 각지에 있고 Route53에서 지연 시간을 측정한 뒤에 지연 시간이 가장 짧은 가까운 거리의 유저들이 us-east-1의 ALB로 연결되고 다른 유저들은 ap-southeast-1로 연결될 것이다.

 

#1 라우팅 정책 종류 살펴보기 (2) - Health Check(상태 확인)에 관해

2. Health Check(상태 확인 기반 라우팅 정책) :

상태 확인은 주로 공용 리소스에 대한 상태를 확인하는 방법인데 개인 리소스를 확인하는 방법 또한 존재한다.

서로 다른 두 지역에 각 하나씩의 로드 밸런서가 있고 둘은 모두 Public Load Balancer라고 해보자.

그리고 그 둘의 뒤에서 애플리케이션이 작동 중이다. (다중 AZ 셋업)

region 레벨에서 고가용성을 원하는 상황이고 Route53을 이용해 DNS 레코드를 만들 것이다. 그러면 유저가 mydomain.com과 같은 URL을 이용해 접속하며 해당 유저는 가장 가까운 로드 밸런서로 연결시켜줄 것이다. 그런데 만약 한 region이 사용 불가능한 상태가 되면 당연히 그곳으로는 유저를 보내고 싶지 않을텐데 그러기 위해선 Route53에서 Health check을 생성해야 한다..!

두 개의 region에 Health check를 생성하고 두 개의 Health check을 Route53의 레코드와 연결할 수 있게 되는데 DNS의 장애 조치를 자동화하기 위한 작업이고 Endpoint 모니터링하거나 다른 Health check을 모니터링하는 Health check, cloudwatch 경보의 상태를 모니터링하는 Health check 총 세 가지의 Health check가 가능하다!

 

➕) 특정 Endpoint에 어떻게 작동하는지 살펴보기

 

ALB에 대한 eu-west-1의 Health check을 한다고 하면 AWS의 Health check가 전세계로부터 올 것이다.

전세계로부터 15개 정도의 Health check가 오는데 이들은 루트를 설정한 엔트 포인트로 모두 요청을 보낸다. 200 ok코드를 받으면 리소스는 정상으로 간주되고 15개의 Health check이 엔드 포인트의 상태를 확인하고 임계값을 정상 혹은 비정상으로 설정한다. 간격도 설정 가능한데 두 개의 선택지가 있다.

30초마다 정기적으로 확인할 수 있고 돈을 조금 더 보태서 10초마다 할 수도 있다 => 이걸 빠른 Health check라고 한다.

HTTP, HTTPS와 TCP등 많은 프로토콜을 지원하고 18%이상의 Health check가 엔드 포인트를 정상이라고 판단하면 Route53도 이를 정상이라고 간주한다.

...

그리고 네트워크 관점에서 아주 중요한 부분인데

Health check가 우리의 애플리케이션 밸런서나 엔트 포인트에 접근이 가능해야 한다.

따라서 Route53의 Health check IP 주소 범위에서 들어오는 모든 요청을 허용해야 한다!

 

➕➕) Calculated Health Check(계산된 상태 확인) :

상태 확인의 또 다른 유형인 계산된 상태 확인은 따로 다뤄보려고 한다.

Calculated Health Check는 여러 개의 Health Check결과를 하나로 합쳐주는 기능이다.

Route53을 보면 EC2 인스턴스가 세 개 있고 Health Check를 세 개 생성할 수 있다.

이들은 EC2 인스턴스를 하나씩 확인해주는 하위 Health Check가 될 것이다. 이제 이 하위 Health Check를 바탕으로 상위 Health Check를 정의할 수 있는데 이 Health Check들을 모두 합치기 위한 조건은 OR, AND, NOT이다.

하위 Health Check를 256개까지 모니터링할 수 있고 상위 Health Check가 통과하기 위해 몇 개의 Health Check를 통과해야 하는지도 지정할 수 있다. 이를 사용하는 경우로는 예를 들어 Health Check이 실패하는 일 없이 상위 Health Check가 웹사이트를 관리/유지하도록 하는 경우이다.

...

개인 리소스의 Health Check는 어떻게 할 수 있을까?🤷‍♂️

 

Private Hosted Zones

개인의 리소스를 모니터링하는 것은 어려울 수 있는데 모든 Route53의 Health Check가 공용 웹에 있기 때문에 VPC 외부에 있으니 개인 엔드 포인트에 접근이 불가능하다. (개인 VPC나 온프레미스 리소스인 경우에는 그렇다)

그래서 이렇게 CloudWatch 지표를 만들어서 CloudWatch 알람을 할당하는 식으로 이 문제를 해결할 수 있다.

그러면 CloudWatch 경보를 Health Check에 할당할 수 있다. CloudWatch 메트릭을 이용해 개인 서브넷 안에 있는 EC2 ㅇㄴ스턴스를 모니터하는 것이다. 그리고 메트릭이 침해되는 경우 CloudWatch 알람을 생성하게 된다. 그리고 알람이 ALARM상태가 되면 Health Check는 자동으로 비정상이 된다..!

=> 이렇게 하면 개인 리소스에 대한 Health Check를 만든 것이나 다름 없고 가장 흔히 사용하는 사례이니 잘 기억해두면 좋다😀