[AWS] Route 53 - Routing Policies(라우팅 정책)

Route 53 - Routing Policies

• 라우팅 정책은 Route 53가 DNS 쿼리에 응답하는 것을 돕는다.
• "라우팅"이라는 단어를 혼동하면 안됩니다!
    - 로드 밸런서가 트래픽을 백엔드 EC2 인스턴스로 라우팅하는 것과는 다른 상황이다.
    - 여기서의 라우팅은 DNS 관점이다.
        : DNS는 DNS 쿼리에만 응답하게 되고, 클라이언트들은 이를 통해 HTTP 쿼리 등을 어떻게 처리해야 하는지를 알 수 있게 된다.
        : DNS는 호스트 이름들을 클라이언트가 실제 사용 가능한 엔드 포인트로 변환하는 것을 돕는다.
• Route 53이 지원하는 라우팅 정책
    - Simple(단순)
    - Weighted(가중치 기반)
    - Failover(장애조치)
    - Latency based(지연시간기반)
    - Geolocation(지리적)
    - Muti-Value Answer(다중값응답)
    - Geoproximity(지리근접)

 

Simple(단순)

 

• 일반적으로, 트래픽을 단일 리소스로 보내는 방식이다.
    - 밑의 이미지처럼, 예를들어 클라이언트가 foo.example.com으로 가고자 한다면, Route53이 IP 주소를 알려주는 것이다. 이는 A레코드 주소이다.
• 동일한 레코드에 여러 개의 값을 지정하는 것도 가능하다.
    - DNS에 의해 다중 값을 받은 경우에는 클라이언트 쪽에서 그 중 하나를 무작위로 고르게 된다.
    - 밑의 이미지처럼, 예를 들어 클라이언트가 foo.example.com로 가기를 요청하고, Route 53은 세 개의 IP 주소로 답한다. 이는 A레코드에 임베딩된 주소들이다. 그럼 클라이언트가 셋 중 하나를 골라서 라우팅에 적용한다.
• 단순 라우팅 정책에 별칭 레코드를 함께 사용하면, 하나의 AWS 리소스만을 대상으로 지정할 수 있다.
• 상태 확인은 할 수 없다.

(출처 : 구글이미지)

 

 

Weighted(가중치)

• 이 정책을 사용하면, 가중치를 활용해 요청의 일부 비율을 특정 리소스로 보내는 식의 제어가 가능하다.
    - 밑의 이미지 도면을 보면, 각 레코드에 상대적으로 가중치를 할당하게 된다.
    - 각 레코드로 보내지는 트래픽의 양(%)은 해당 레코드의 가중치를 전체 가중치로 나눈 값이다.
• 한 DNS 이름 하에 있는 다른 레코드들과 비교했을 때, 해당 레코드로 트래픽을 얼마나 보낼지를 나타내는 값이다.
    - DNS 레코드들은 동일한 이름과 유형을 가져야 한다.
• 상태 확인과도 관련될 수 있다.
• 사용 사례
    - 서로 다른 지역들에 걸쳐 로드 밸런싱을 할 때나 적은 양의 트래픽을 보내 새 애플리케이션을 테스트하는 경우에도 사용한다.
• 가중치 0의 값을 보내게 되면, 특정 리소스에 트래픽 보내기를 중단해 가중치를 바꿀 수 있다.
• 만약, 모든 리소스 레코드 가중치의 값이 0인 경우, 모든 레코드가 다시 동일한 가중치를 갖게 된다.

(출처 : 구글이미지)

•  Amazon Route 53이 있고, EC2 인스턴스가 세 개 있는데 70, 20, 그리고 10의 각각 다른 가중치를 할당받아 이 예시에서는 가중치의 합이 100이 되는데 실제로 사용할 때는 이럴 필요가 없다.
• Route 53에서 오는 DNS 응답의 70%가 첫 번째 EC2 인스턴스로 리다이렉팅된다는 의미이다. 20%는 두번째로, 10%는 세 번째 인스턴스로 간다.

 

 

Failover(Active-Passive, 장애조치)

(출처 : 구글이미지)

• 위의 이미지에서 중간에 Route53이 있고, EC2 인스턴스가 있다.
  하나는 기본 EC2 인스턴스이고, 두 번째는 보조 EC2 인스턴스 혹은 재해 복구 EC2 인스턴스이다.
  이 경우에는 상태 확인과 기본 레코드를 연결하는데 필수적이다.
• 상태 확인이 비정상이면
  자동으로 Route53은 2번째의 EC2 인스턴스로 장애 조치하며 결과를 보내기 시작한다.
  그리고 보조 EC2 인스턴스도 상태 확인을 연결할 수 있지만 기본과 보조가 각각 하나씩만 있을 수 있다.
  클라이언트의 DNS 요청은 정상으로 생각되는 리소스를 자동으로 얻는다.
• 기본 인스턴스가 정상이면 Route 53도 기본 레코드로 응답한다.
  하지만 상태 확인이 비정상이면 장애 조치에 도움이 되는 두 번째 레코드의 응답을 자동으로 얻게 된다.

 

 

Latency based(지연시간기반)

• 지연 시간이 가장 짧은, 즉 가장 가까운 리소스로 리다이렉팅을 하는 정책이다.
• 지연 시간에 민감한 웹사이트나 애플리케이션이 있는 경우에 아주 유용한 정책이다.
• 지연 시간은 유저가 레코드로 가장 가까운 식별된 AWS 리전에 연결하기까지 걸리는 시간을 기반으로 측정된다.
    - 만약 유저가 독일에 있고, 미국에 있는 리소스의 지연 시간이 가장 짧다면, 해당 유저는 미국 리전으로 리다이렉팅이 될 것이다.
• 상태 확인과 연결이 가능하다.

(출처 : 구글이미지)

• 두 개의 다른 리전에 애플리케이션을 배포한다고 생각해보자.
    : ap-southeast-1과 us-east-1에 각 하나씩 배포한다. 유저들은 세계 각지에 있으며 Route 53가 지연 시간을 측정한 뒤 지연 시간이 가장 짧은 가까운 거리의 유저들이 us-east-1의 ALB로 연결되고, 다른 유저들은 ap-southeast-1로 연결될 것이다.

 

 

Geolocation(지리적)

• 지연 시간 기반의 정책과는 매우 다르게 사용자의 실제 위치를 기반으로 라우팅한다.
     : 예를 들어, 사용자가 특정 대륙이나 국가 혹은 더 정확하게 미국의 경우에는 어떤 주에 있는지 지정하는 것이며 가장 정확한 위치가 선택되어 그 IP로 라우팅 되는 것이다.
• 일치하는 위치가 없는 경우는 '기본 레코드'를 생성해야 한다.  
• 사용사례
    - 웹 사이트 지역화
    - 콘텐츠 분산 제한
    - 로드 밸런싱 등등
• 이런 레코드는 상태 확인과 연결 할 수 있다.

(출처 : 구글이미지)

• 여러 나라가 있는 유럽의 지도를 가정해보자.
    - 독일의 유저가 독일어 버전의 앱을 포함한 IP로 접속되도록 독일의 지리 레코드를 정의할 수 있다.
    - 프랑스의 경우라면 프랑스어의 버전의 앱을 가진 IP로 가야한다.
    - 그 외의 다른 곳은 앱에서 영어 버전이 포함된 기본 IP로 이동해야 한다.

 

 

Geoproximity(지리근접)

• 사용자와 리소스의 지리적 위치를 기반으로 트래픽을 리소스로 라우팅하도록 한다.
• 편향값을 사용해 특정 위치를 기반으로 리소스를 더 많은 트래픽을 이동하는 것이다.
• 지리적 위치를 변경하려면 편향값을 지정해야 한다.
    - 특정 리소스에 더 많은 트래픽을 보내려면 편향값을 증가시켜서 확장하면 된다.
    - 리소스에 트래픽을 줄이려면 편향값을 음수로 축소시키면 된다.
• 리소스는 다음과 같다.
    - AWS 리소스
        : 특정 AWS 리전 지정
        : 리소스는 AWS의 리소스로 속한 특정 리전을 지정하면 목록에서 자동으로 올바른 라우팅을 계산한다.
    - 비AWS리소스
        : 위도와 경도 지정
        : AWS 리소스가 아닌 온프레미스 데이터 센터인 경우 위도와 경도를 지정해서 AWS가 위치를 파악하도록 해야 한다.
• 편향 활용을 위해 고급 Route53 트래픽 플로우를 사용한다.
• 기억해야될 점!
    - 지리 근접 라우팅은 편향을 증기시켜 한 리전에서 다른 리전으로 트래픽을 보낼 때 유용하다는 것이다.

(출처 : 구글이미지)

• 위의 이미지처러 us-west-1의 리소스와 us-east-1 리소스를 예로 들어보자.
   - 각 리전의 편향값은 0으로 설정되어있다. 이는 미국 전역에 사용자가 이 리소스에 액세스를 시도하며 미국을 둘로 나눈다는 뜻이다.
• 왼쪽의 사용자는 us-west-1로 이동하고, 오른쪽 사용자는 us-east-1로 이동한다.
• 편향이 없기 때문에 이 상황은 아주 간단하다.
• 사용자 위치에서 가장 가까운 리소스 리전으로 이동하는 것이다.

(출처 : 구글이미지)

• 편향으로 인해 동일한 설정이지만, 다른 방식으로 사용자를 다른 리전으로 라우팅할 수 있다.
• 예를 들어, us-west-1과 us-east-1이 있고, us-west-1의 편향값은 0이고, us-east-1의 50이라는 양수의 편향값을 가진다. 그리고 편향으로 해당 리소스에 더 많은 사용자와 트래픽이 발생된다.
    - 이유는 편향으로 2가지 리소스 사이의 분할 선이 조금씩 왼쪽으로 이동하는 것이며, 이는 us-east-1의 편향이 더 높기 때문이다.
• 왼쪽의 사용자는 us-west-1으로 이동하고, 오른쪽 사용자는 us-east-1으로 이동한다는 것이다.
    - 왜 그럴까!? 
        : 전 세계로 리소스를 설정하고 특정 리전에 더 많은 트래픽을 더 보내야 한다고 하면 지리 근접 라우팅 정책을 사용해 특정 리전의 편향을 증가시키면 더 많은 사용자가 생기게 되고 특정 리전에 더 많은 트래픽이 발생하게 된다.

 

 

IP-based Routing(IP 기반)

• 이름에서 알 수 있듯이, 클라이언트 IP 주소를 기반으로 라우팅을 정의한다.
• Route53에서 CIDR 목록을 정의하는데, 클라이언트의 IP 범위이다. 그리고 CIDR에 따라 트래픽을 어느 로케이션으로 보내야 하는지 정한다.
• 성능을 최적화 할 수 있다.
    : IP를 미리 알고 있기 때문이다.
• 네트워크 비용도 절감 할 수 있다.
    : IP가 어디에서 오는지 알기 때문이다.
• 예를 들어, 특정 인터넷 제공업체가 특정 IP 주소 셋을 사용하는 것을 안다면 특정 엔드포인트로 라우팅 할 수 있다.

(출처 : SAA 강의)

• 예를 들어보자. Route 53에서 두 로케이션을 서로 다른 두 CIDR 블록으로 정의해보자.
    - 하나는 203으로 시작하고 다른 하나는 200으로 시작한다. 그러면 IP 범위도 정의된다.
• 로케이션을 레코드에 연결하면 example.com인데
    - 로케이션 1에서는 첫 번째 CIDR 블록을 값 1, 2, 3, 4로 보내고, 두 번째 로케이션에서는 두 번째 CIDR 블록을 5, 6, 7, 8로 보낸다. 이 값들은 두 개의 EC2 인스턴스의 공용 IP를 나타낸다.
• 사용자 A가 로케이션 1 CIDR 블록에 속하는 특정 IP로 들어오면 첫 번째 EC2 인스턴스인 IP 1, 2, 3, 4로 보내진다.
• 사용자 B가 두 번째 로케이션에 속하는 IP 주소로 들어오면 리디렉션 되어 IP 5, 6, 7, 8의 EC2 인스턴스에 대한 DNS 쿼리 응답을 받게 된다.

 

 

Multi-Value(다중 값)

• 트래픽을 다중 리소스로 라우팅할 때 사용한다.
  그래서 Route 53은 다중 값과 리소스를 반환한다.
• 상태확인과 연결하면 다중 값 정책에서 반환되는 유일한 리소스는 정상 상태 확인과 관련이 있다.
• 각각의 다중 값 쿼리에 최대 8개의 정상 레코드가 반환된다.
• ELB와 유사해보이지만 ELB를 대체할 수 없다.
   = 클라이언트 측면의 로드 밸런싱이다.

(출처 : 구글이미지)

• 예시를 들어보자. example.com에서 다중 A 레코드를 설정하고 상태 확인과 연결하자.
    - 클라이언트에서 다중 값 쿼리를 실행하면 최대 8개의 레코드를 수신하게 되고 클라이언트는 하나를 선택한다. 
    - 최소한 상태 확인과 결합하면 반환되는 8개 레코드 중 1개 혹은 최대 8개의 레코드가 정상일 것을 알고 있다. 그래서 클라이언트는 안전한 쿼리를 가질 수 있다.
• 다중 값이 있는 단순한 라우팅의 경우에는 (단순 라우팅 정책은 상태 확인을 허용하지 않기 때문에) 단순 라우팅 정책의 쿼리가 반환하는 리소스 중 하나는 비정상일 가능성이 높다.
    = 이게 바로 다중 값이 조금 더 강력한 레코드 유형인 이유이다.