로드 밸런서를 갖고 있을 때 로드 밸런서가 실제로 트래픽을 백엔드 EC2 인스턴스로 라우팅하는 것과 전혀 다르며 DNS는 어떤 트래픽도 라우팅하지 않으므로 트래픽이 DNS를 통해서 가지 않음 DNS는 오직 DNS 쿼리에만 응답하며 호스트 네임을 클라이언트가 사용하는 실제 엔드포인트로 변환만 해줌
Route 53은 여러 라우팅 정책을 지원 Simple, Weighted, Failover, Latency based, Geolocation, Multi-Value Answer, Geoproximity
Routing Policies – Simple (단순)
일반적으로 트래픽을 단일 리소스로 라우팅
동일한 레코드에 다중의 값을 명시할 수 있으며 다중의 값이 DNS에 의해 리턴되면 임의의 랜덤 값이 클라이언트나 클라이언트 사이드에 의해 선택됨
예) 클라이언트가 foo.example.com으로 간다고 할 때, Route 53은 11.22.33.44 IP 주소로 가라고 하며, 이는 A 레코드에 해당 예) 클라이언트가 foo.example.com을 요청하고 있으면 Route 53은 A 레코드에 내장되어 있는 세 개의 IP 주소를 답해주고 클라이언트가 하나를 무작위로 선택해 라우팅 대상으로 적용
만약 Alias 레코드를 단순 정책을 통해 활성화했다면 목표 대상으로 AWS 리소스만 특정할 수 있음
상태 확인(Health Check)과는 연관지을 수 없음
<단순 라우팅 정책 실습>
레코드 생성 후 라우팅 정책 선택 A 타입 레코드로 ap-southeast-1 인스턴스를 가져와서 사용하며 TTL은 20으로 설정 그리고 라우팅 정책은 단순 라우팅 정책으로 실행
웹 브라우저에서 레코드 작동 확인 simple.stephanethenteacher.com 도메인을 복사해서 주소창에 넣어 이동해보면 ap-southeast-1b에서 Hello World
클라우드 셸에서 레코드 작동 확인 dig 명령을 사용해 실행하면 동일하게 동작하는 것을 확인할 수 있음
레코드 편집 및 작동 확인 레코드에 여러 IP 주소를 넣기 위해 us-east-1의 값을 가져와서 붙여넣고 저장하면 기존의 TTL이 만료되고 난 뒤에 IP 주소 두 개가 나오게 되며 웹 브라우저와 클라우드 셸을 통해 확인하게 되면 us-east-1과 ap-southeast-1이 둘 다 나오게 됨 즉, 하나의 레코드에 두 개의 IP 주소를 가짐
Routing Policies – Weighted (가중치)
통제 가능한 요청의 특정 비율을 특정 리소스로 보낼 수 있음
예) Route 53이 있고 서로 다른 가중치가 할당된 세 개의 EC2 인스턴스가 존재 Route 53 상의 DNS 응답의 70%는 첫 번째 EC2 인스턴스로, 20%는 두 번째로, 10%는 세 번째로 리다이렉트 된다는 것을 의미
각 레코드에 상대적으로 가중치를 주어야 하며 그럴 경우 트래픽 비율이 각 레코드에 보내지며, 트래픽 비율은 특정 레코드의 가중치 나누기 총 레코드의 가중치 합을 의미 (즉, 총 가중치 중의 비율을 뜻함)
가중치의 합은 반드시 100이어야할 필요가 없으며 그저 DNS 네임에 있는 다른 모든 레코드와 비교했을 때 이 인스턴스로 얼마만큼 보내고자 하는지를 직설적으로 보여줌
이를 동작하기 위해서 DNS 레코드는 반드시 동일한 이름과 타입이여야하며 상태 확인과 연관지을 수 있음
다른 구역 간의 로드 밸런싱이나 적은 양의 트래픽을 통해 새로운 애플리케이션 버전을 테스트하기 위해 사용
만약 가중치를 0으로 설정하면 특정 리소스로의 트래픽 전송을 멈출 수 있으며 시간이 지남에 따라 가중치를 옮길 수도 있음
만약 모든 리소스 레코드가 가중치 0을 가지면 모든 레코드는 동일한 가중치를 가지게 리턴
<가중치 라우팅 정책 실습>
레코드 생성 후 라우팅 정책 선택 A 타입 레코드로 ap-southeast-1 인스턴스를 가져와서 사용하며 TTL은 3으로 설정 그리고 라우팅 정책은 가중치 라우팅 정책으로 실행한 후 가중치는 10으로 지정하며 가중치 레코드 설정에서는 레코드 ID를 설정해 특정 레코드를 식별할 수 있으므로 SOUTHEAST라고 설정 여러 IP 주소를 넣기 위해 us-east-1의 값을 가져와서 붙여넣고 가중치는 70, 나머지는 동일하게, 레코드 ID는 US EAST로 설정, 그리고 eu-central-1의 값을 가져와서 붙여넣고 가중치는 20, 나머지는 동일하게, 레코드 ID는 EU로 설정 그리하여 3개의 레코드를 생성했으며, 세 개의 레코드는 각각 하나의 IP 주소를 가짐
웹 브라우저에서 레코드 작동 확인 weighted.stephanethenteacher.com 도메인을 복사해서 주소창에 넣어 이동해보면 트래픽의 70%는 us-east-1 지역으로 보내지므로 us-east-1에서 응답 하지만 3초에 한 번씩 새로 고침을 하면 가중치에 기반하여 언젠가 다른 지역으로부터 응답을 받게 됨
클라우드 셸에서 레코드 작동 확인 dig 명령을 사용해 실행하면 위와 동일하게 동작하는 것을 확인할 수 있으며 가중치가 가장 큰 곳으로 대부분의 쿼리를 리다이렉트하지만 종종 다른 값이 나오기도 하므로 3초에 한 번씩 새로 고침을 하면 가중치에 기반하여 언젠가 다른 지역으로부터 응답을 받게 됨
Routing Policies – Latency -based (대기 시간)
가장 낮은 지연 시간을 가질, 가장 가까운 리소스를 리다이렉트하는 것
지연 시간이 웹 사이트나 애플리케이션의 문제라면 큰 도움이 됨
사용자들이 얼마나 빨리 레코드의 가장 가깝고 식별된 AWS 구역에 연결할 수 있느냐를 기반으로 측정
예) 만약 미국에 있는 리소스에 대해 가장 낮은 지연 시간을 갖고 있다면 독일에 있는 사용자는 그 곳으로 리다이렉트
상태 확인과 연관지을 수 있음
예) 세계의 서로 다른 두 지점에 애플리케이션이 배치되었고, 사용자는 전 세계에 존재할 때 지연 시간은 Route 53에 의해 평가되며 us-east-1의 ALB에 가장 가깝거나 가장 낮은 지연 시간을 가진 사용자들이 그곳으로 리다이렉트되는 반면, 다른 사용자들은 ap-southeast-1로 리다이렉트
<대기 시간 라우팅 정책 실습>
레코드 생성 후 라우팅 정책 선택 A 타입 레코드로 ap-southeast-1 인스턴스를 가져와서 사용하며 TTL은 300초로 지정 이 IP의 리전이 싱가포르임을 표시하기 위해 리전을 Asia Pacific (Singapore)로 지정 ID를 설정해 특정 레코드를 식별할 수 있으므로 ap-southeast-1라고 설정 그리고 라우팅 정책은 대기(지연) 시간 라우팅 정책으로 실행 여러 IP 주소를 넣기 위해 us-east-1의 값을 가져와서 붙여넣고 나머지는 비슷하게, 레코드 ID는 us-east-1로 설정, 그리고 eu-central-1의 값을 가져와서 붙여넣고 나머지는 비슷하게, 레코드 ID는 eu-central-1로 설정 그리하여 3개의 레코드를 생성했으며, 세 개의 레코드는 각각 하나의 IP 주소를 가짐
웹 브라우저에서 레코드 작동 확인 latency.stephanethenteacher.com 도메인을 복사해서 주소창에 넣어 이동해보면 가까운 곳에 있는 URL로 이동하게 되는데 강의자의 경우 유럽에 있으므로 유럽에 있는 인스턴스인 eu-central-1로 가게 됨
클라우드 셸에서 레코드 작동 확인 dig 명령을 사용해 실행하면 위와 동일하게 동작하는 것을 확인할 수 있음
대기 시간 라우팅 정책의 나머지 지역 작동 여부 확인 VPN을 사용해 위치를 이동해 캐나다로 가서 이용하면 가장 짧은 리전이 미국으로 나오므로 웹 브라우저에 us-east-1가 나타남 또한 VPN을 사용해 위치를 변경하면 노트북의 로컬 DNS 캐시에 있던 TTL도 초기화되므로 새로고침했을 때 바로 자동으로 us-east-1의 새로운 값을 얻을 수 있는 것
Routing Policies – Failover (Active-Passive)
Route 53이 가운데 있고 EC2 인스턴스가 주어졌을 때 첫 번째는 기본 인스턴스이며, 두 번째는 재앙 복구를 위한 보조 인스턴스 이 경우 기본 레코드와상태 확인을 연관시키는 것이 필수적이며만약 상태 확인이 건강하지 않다고 진단하면 Route 53은 자동으로 두 번째 인스턴스로 장애 조치되어 결과를 되돌려 주게 됨 만약 보조 EC2 인스턴스에도 원한다면 상태 확인과 연관지을 수 있으며, 상태 확인은 각 하나씩만 가질 수 있음
클라이언트는 DNS 요청을 할 때 기본 인스턴스가 건강하다면Route 53은 기본 레코드와 함께 자동으로 건강하다고 여겨지는 리소스를 얻도록 응답함 만약 건강하지 않다면 자동으로 두 번째 레코드의 응답을 받게 됨
<장애 조치 라우팅 정책 실습>
레코드 생성 후 라우팅 정책 선택 호스팅 영역에서 레코드를 생성하며 이름으로 failover를 입력하며 A 타입 레코드, TTL은 60초로 eu-central-1로 설정 라우팅 정책은 장애 조치 라우팅 정책으로 설정하며 장애 조치 레코드에는 기본과 보조의 2가지 유형이 존재하므로 기본 레코드를 선택한 뒤 상태 확인과 연결 다른 레코드를 생성을 위해 us-east-1의 값을 가져와서 붙여넣고 나머지는 비슷하게 설정하고 장애 조치 유형은 보조로 선택
웹 브라우저에서 레코드 작동 확인 상태 확인을 보면 레코드와 연결한 두 상태 확인은 정상인 것을 확인할 수 있음 failover.stephanethenteacher.com 도메인을 복사해서 주소창에 넣어 이동해보면 eu-central-1로 가게 됨
장애 조치 테스트를 위한 장애 조치 유발 및 확인 eu-central-1의 리전으로 가서 인스턴스의 보안 그룹 규칙인 80번 포트의 규칙을 삭제하게 되면 상태 검사기에서 인스턴스를 연결할 수 없게 되므로 상태 확인이 비정상이 되어 장애 조치를 테스트할 수 있게 됨 그리하여 failover.stephanethenteacher.com 도메인을 복사해서 주소창에 넣어 이동해보면us-east-1로 가게 됨 이를 통해 장애 조치가 원활하게 실행된 것을 알 수 있음 다시 인스턴스 보안 그룹 규칙을 원래대로 돌려놓게 되면 기본 위치인eu-central-1에서 장애 조치를 실행하게 됨
Routing Policies – Geolocation
실제 사용자의 위치를 기반
만약 사용자가 특정 대륙 또는 국가에서 온다고 하면 가장 정확한 위치가 선택되고 그 IP로 라우트
위치에 매치되는 대상이 없을 경우를 대비하여 디폴트 레코드를 생성
웹 사이트 현지화 작업, 콘텐츠 전송 규제, 로드밸런싱 작업에 사용
예) 여러 국가가 속한 유럽 지도가 주어졌을 때, 독일에 대한 지리 위치 레코드를 정의하여 독일인 사용자들이 앱의 독일어 버전을 담고 있는 IP 11.22.33.44로 가도록 함 만약 프랑스라면 IP 55.66.77.88로 가도록 하며 이는 프랑스어 버전의 앱을 담고 있음 그 외의 다른 지역은 디폴트 IP인 99.11.22.33로 가게 하며 이는 영어 버전의 앱을 담고 있음
<지리적 위치 라우팅 정책 실습>
레코드 생성 후 라우팅 정책 선택 호스팅 영역에서 레코드를 생성하며 A 타입 레코드, TTL은 60초로 ap-southeast-1로 설정 라우팅 정책은 지리적 위치 라우팅 정책으로 설정하며 지리 위치를 아시아 전체로 설정하여 아시아의 모든 사용자는 ap-southeast-1의 EC2 인스턴스로 이동하게 하므로 레코드 ID는 Asia로 설정 여러 IP 주소를 넣기 위해 us-east-1의 값을 가져와서 붙여넣고 나머지는 비슷하게, 레코드 ID는US로 설정, 그리고 eu-central-1의 값을 가져와서 붙여넣고 나머지는 비슷하게, 지리 위치를 기본으로, 레코드 ID는 Default EU로 설정 이는 아시아나 미국과 일치하지 않으면 기본 위치인 eu-central-1로 이동한다는 의미 그리하여 3개의 레코드를 생성했으며, 세 개의 레코드는 각각 하나의 IP 주소를 가짐
웹 브라우저에서 레코드 작동 확인 geo.stephanethenteacher.com 도메인을 복사해서 주소창에 넣어 이동해보면 미국이나 아시아가 아닌 경우 eu-central-1로 가게 됨
지리적 위치 라우팅 정책의 나머지 지역 작동 여부 확인 VPN을 사용해 위치를 이동해 인도로 가서 이용하면 웹 브라우저에 ap-southeast-1이 나타남 또한 VPN을 사용해 위치를 변경하면 노트북의 로컬 DNS 캐시에 있던 TTL도 초기화되므로 새로고침했을 때 바로 자동으로 ap-southeast-1의 새로운 값을 얻을 수 있는 것 멕시코를 선택할 시에는 기본 레코드인 eu-central-1이 나타남
Routing Policies – Geoproximity
사용자와 리소스의 지리적 위치에 근거하여 트래픽을 리소스로 라우트
이 정책을 통해 바이어스라고 불리는 숫자를 사용하여 특정 위치를 기반으로 더 많은 트래픽을 리소스로 옮길 수 있음
지리적 위치의 크기를 변경하기 위해서는 바이어스 값을 명시해야 하며 만약 더 많은 트래픽을 특정 리소스로 보내고자 한다면 바이어스 값을 올려 확장 만약 더 적은 트래픽을 보내고 싶다면 바이어스 값을 음수 값으로 축소
AWS로부터 온 리소스의 경우 그들이 속한 구역을 지정할 수 있으며 자동으로 리스트가 올바른 라우팅을 계산
온프레미스 데이터 센터와 같이 AWS 리소스가 아닌 경우에는 위도와 경도만 명시하여 AWS가 그들의 위치를 인식하도록 함
바이어스를 사용하기 위해서는 고급 Route 53 트래픽 플로우를 사용해야 함
바이어스가 없는 경우) us-west-1에 있는 리소스와 us-east-1에 있는 리소스가 존재하며 바이어스는 두 구역에서 모두 0 미국에 있는 사용자들이 리소스들에 접근하고자 할 경우 미국을 두 부분으로 나누는 선이 생길 것이며 줄의 왼쪽에 위치한 사용자들은 us-west-1로 가고, 오른쪽의 사용자들은 us-east-1로 가게 됨 즉, 사용자의 위치를 기준으로 가장 가까운 리소스 구역에 가는 형태
바이어스가 있는 경우) 동일한 셋업이지만 다른 방법을 통해 사용자들을 다른 구역으로 라우트할 수 있음 바이어스는 그 리소스로 더 많은 사용자와 트래픽이 가도록 하며 us-west-1는 바이어스가 0이고, us-east-1는 바이어스가 50 us-east-1의 바이어스가 더 높으므로 처음 두 개의 리소스를 선으로 분리하는 바이어스는 조금 더 왼쪽으로 가게 되며 줄의 왼쪽에 위치한 사용자들은 us-west-1로 가고, 오른쪽의 사용자들은 us-east-1로 가게 됨
리소스를 전세계에 설정해두고 특정 구역에 더 많은 트래픽을 이동하려고 할 때 이 정책을 사용하여 특정 구역에 있는 바이어스를 증가시키면 더 많은 사용자가 이끌어지고 더 많은 사용자가 그 구역에 이끌어진 트래픽을 가질 수 있음 그러므로 이는 트래픽을 한 구역에서 다른 구역으로 옮기고자 할 때 유용
트래픽 정책 생성 이름은 DemoGeoPolicy로 하며 시작점은 생성하고자 하는 레코드 유형인 A 레코드로 지정하며 특정 규칙와 연결해야 함 특정 규칙에는 가중치, 장애 조치, 지리적, 지연 시간, 다중 값, 지리 근접성 또는 엔드 포인트 규칙이 존재 우리는 지리 근접 규칙을 생성하며 첫 번째 리전으로는 US East로 선택하고 편향 값인 바이어스를 0으로 지정 그리고 이 레코드는 새 엔드 포인트와 연결되기 위해 us-east-1 EC2 인스턴스를 사용 두 번째 리전으로는 ap-southeast-1의 싱가포를 입력 정책을 생성한 후 지리 근접 맵을 통해 입력 값을 기반으로 어떤 사용자가 어떤 인스턴스로 이동하는지 보여줌 편향값을 34로 입력하면 us-east-1의 인스턴스로 리디렉션 되는 면적이 증가하게 되며 음수로 줄이면 반대로 나타나게 됨
편향값 0편향값 34
정책 레코드로 트래픽 정책 배포 트래픽 정책을 생성했으므로 정책 레코드로 트래픽 정책을 호스팅 영역으로 배포해야 함 poximity.stepanetheteacher.com으로 정책 레코드 이름을 설정하고 TTL을 60 설정 이 정책 레코드를 생성하면 월별로 50달러를 내야 함 poximity.stepanetheteacher.com를 웹 브라우저에 입력하면 맵에 따라서 알맞은 곳에 연결되게 됨
Routing Policies – Multi-Value
트래픽을 다중 리소스로 라우트하고자 할 때 사용하며 Route 53은 다중값 또는 다중 리소스를 리턴
이는 상태 확인과 연결될 수 있으며 다중값 정책을 통해 리턴될 리소스는 건강한 상태 확인과 연결된 것만 가능하며 최대 8개의 건강한 레코드가 각 다중값 쿼리에 모두 리턴
예) example.com에 대해 다중 A 레코드를 셋업하고 상태 확인과 연결 다중값 쿼리가 클라이언트에 의해 수행되면 이는 최대 8개의 레코드를 돌려받고 클라이언트는 그 중에 하나를 선택 그리고 상태 확인과 결합함으로써 리턴되는 최대 8개의 값 중 하나가 건강할 것임으로 알 수 있으므로 안전한 쿼리를 가질 수 있음 이와 반대로, 단순 라우팅의 경우 상태 확인이 허용되지 않으므로 리턴된 리소스 중 하나가 건강하지 않을 수 있음 그러므로 다중값이 레코드 타입으로써 능력이 뛰어난 것
<다중값 라우팅 정책 실습>
레코드 생성 후 라우팅 정책 선택 호스팅 영역에서 레코드를 생성하며 A 타입 레코드, TTL은 60초로 us-east-1로 설정하며 레코드 ID는 US로 설정 그리고 라우팅 정책은 다중값 라우팅 정책으로 설정 여러 IP 주소를 넣기 위해 ap-southeast-1의 값을 가져와서 붙여넣고 나머지는 비슷하게, 레코드 ID는 Asia로 설정, 그리고 eu-central-1의 값을 가져와서 붙여넣고 나머지는 비슷하게, 레코드 ID는EU로 설정 그리하여 3개의 레코드를 생성했으며, 세 개의 레코드는 각각 하나의 IP 주소를 가짐
클라우드 셸에서 레코드 작동 확인 dig 명령을 사용해 실행하면 3개의 상태 확인이 제대로 실행되고 있으므로 3개의 응답을 얻을 수 있게 됨
다중값 테스트를 위한 비정상 유발 및 확인 eu-central-1의 상태 확인을 invert health check status을 클릭해 정상에서 비정상 혹은 반대로 상태 반전해 비정상으로 만듦 이후 다시 dig 명령문을 실행하게 되면 2개의 값만 얻을 수 있음
