[ 고지 사항 (Disclaimer) ]
본 컨텐츠는 고객의 편의를 위하여 AWS 서비스 설명을 위해 제작, 제공된 것입니다. 만약 AWS 사이트와 컨텐츠 상에서 차이나 불일치가 있을 경우 AWS 사이트 (AWS.amazon.com)가 우선합니다. 또한 AWS 사이트 상에서 한글 번역문과 영어 원문에 차이나 불일치가 있을 경우(번역의 지체로 인한 경우 등 포함), 영어 원문이 우선합니다.
본 문서는 Hybrid Cloud DNS Options for Amazon VPC (2019년, 영문) 내용에 기반하여 작성 되었습니다.
이 문서는 정보 제공의 목적으로만 제공됩니다. 본 문서의 발행일 당시 AWS의 현재 제품 오퍼링 및 실행방법 등을 설명하며, 예고 없이 변경될 수 있습니다. 고객은 본 문서에 포함된 정보나 AWS 제품 또는 서비스의 사용을 독립적으로 평가할 책임이 있으며, 각 정보 및 제품은 명시적이든 묵시적이든 어떠한 종류의 보증 없이 “있는 그대로” 제공됩니다. 본 문서는 AWS, 그 자회사, 공급업체 또는 라이선스 제공자로부터 어떠한 보증, 표현, 계약 약속, 조건 또는 보장을 구성하지 않습니다. 고객에 대한 AWS의 책임 및 의무는 AWS 계약에 의해 관리되며 본 문서는 AWS와 고객 사이의 어떠한 계약에도 속하지 않으며 계약을 변경하지도 않습니다.
© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
본 문서는 총 4부로 구성되어 있으며 이 글은 3부입니다.
1부 링크 : Amazon VPC용 하이브리드 클라우드 DNS 옵션 1/4
분산 조건부 전달자
Route 53 솔루션을 사용하면 하이브리드 DNS 아키텍처를 실행하는 데 따르는 복잡성을 피할 수 있지만 VPC 내에서 조건부 전달자를 사용하도록 DNS 인프라를 구성하는 것이 좋습니다. 자신의 전달자를 실행하도록 선택할 수 있는 한 가지 이유는 DNS 쿼리를 기록하는 것입니다. DNS 로깅 (추가 고려 사항)을 참조하여 이것이 적합한지 확인하십시오.
이 솔루션에는 두 가지 옵션이 있습니다. 고도로 분산 된 전달자라고 하는 첫 번째 옵션은 Route 53 솔루션이 제공하는 규모를 모방하려는 모든 환경 인스턴스에서 전달자를 실행하는 방법에 대해 설명합니다. 대체를 사용하는 구역 전달 자라고 하는 두 번째 옵션은 전달자를 특정 가용 영역 및 해당 인스턴스에 지역화 하는 전략을 제시합니다.
다음 표는 이 두 가지 옵션과 그에 대한 자세한 설명입니다.
고도로 분산 된 전달자
이 옵션은 전달자를 분산시키고 환경의 모든 인스턴스에서 소형 경량 DNS 전달자를 실행합니다. 전달자는 실행중인 인스턴스의 DNS 요구 만 처리하도록 구성되어 병목 현상과 중앙 인스턴스 집합에 대한 종속성이 제거됩니다.
이 솔루션의 구현 및 관리 복잡성을 감안할 때 성숙한 구성 관리 솔루션을 사용하는 것이 좋습니다.
다음 다이어그램은이 솔루션이 단일 VPC에서 작동하는 방식을 보여줍니다.
Route 53 솔루션과 마찬가지로이 솔루션을 사용하면 모든 단일 인스턴스가 네트워크 인터페이스 당 1024 PPS 제한을 사용하여 Route 53 Resolver를 최대한 활용할 수 있습니다. 이 솔루션은 또한 추가 인스턴스가 추가됨에 따라 확장되며 단일 또는 다중 VPC 설정을 사용하는지에 관계없이 동일한 방식으로 작동합니다. DNS 인프라는 대기 시간이 짧으며 개별 전달자와 같은 DNS 구성 요소의 장애는 설계의 분리 된 특성으로 인해 전체 차량에 영향을 미치지 않습니다.
이 솔루션은 특히 환경이 성장함에 따라 구현 및 관리 복잡성을 초래합니다. Amazon EC2 사용자 데이터를 사용하여 인스턴스 시작 시 구성 파일을 관리하고 수정할 수 있습니다. 인스턴스 시작 후 Amazon EC2 Run Command 또는 AWS OpsWorks for Chef Automate를 사용하여 구성 파일을 배포하고 유지 관리 할 수 있습니다.
이러한 솔루션의 구현은 이 백서의 범위를 벗어나지만 구성 파일과 상태를 대규모로 관리 할 수 있는 유연성과 성능을 제공한다는 점을 알아야합니다. 유연성이 클수록 복잡성이 커집니다. 사내 DevOps 인력의 필요성을 포함하여 추가 운영 비용을 고려하십시오.
대체를 사용하는 영역 전달자
환경의 각 인스턴스에서 전달자를 관리 및 구현하지 않고 조건부 전달자 인스턴스를 하이브리드 DNS 아키텍처의 중심으로 사용하려면 이 옵션을 고려해야 합니다.
이 옵션의 경우 가용 영역의 인스턴스를 현지화하여 Amazon VPC의 동일한 가용 영역에 있는 조건부 전달자에게만 쿼리를 전달합니다. Linux Resolver 섹션에서 논의 된 이유 때문에 각 인스턴스는 다음 다이어그램과 같이 resolv.conf에 최대 3 개의 DNS 서버를 가질 수 있습니다.
가용 영역 A의 세 인스턴스 중 하나가 실패하면 다른 두 인스턴스가 계속 DNS 트래픽을 제공합니다. 전달자가 단일 장애 지점 인 동일한 상위 하드웨어에서 실행되지 않도록 하려면 배치 그룹을 사용해야합니다. 별도의 상위 하드웨어를 확보하기 위해 이러한 유형의 장애 도메인을 피하기 위해 Amazon Elastic Cloud Compute 배치 그룹을 설정하고 활용할 수 있습니다.
가용 영역 A에있는 3 개의 DNS 전달자가 동시에 실패하면 가용 영역 A의 인스턴스는 다른 가용 영역에 전달자가 있는지 알지 못하므로 DNS 요청을 확인하지 못합니다. 이렇게 하면 영향이 여러 가용 영역으로 확산되는 것을 방지하고 다른 가용 영역이 계속 정상적으로 작동합니다.
현재 설정 한 DHCP 옵션이 VPC 전체에 적용됩니다. 따라서 각 가용 영역의 인스턴스에 대해 로컬 인 DNS 서버 목록을 자체 관리해야 합니다. 또한 가용 영역의 모든 인스턴스에 대해 resolv.conf에서 동일한 순서의 DNS 서버를 사용하지 않는 것이 좋습니다. 목록의 첫 번째 서버에 부담을 주고 네트워크 인터페이스 당 PPS를 위반하는 것에 더 가까워집니다. 한도. 각 Linux 인스턴스에는 리졸버가 3 개만 있을 수 있지만 리졸버 목록을 직접 관리하는 경우 가용 영역 당 원하는 만큼의 리졸버를 가질 수 있습니다. 각 인스턴스는 확인자 목록에서 3 개의 임의의 확인 자로 구성되어야 합니다.
여러 계정 및 VPC에서 DNS 관리 확장
많은 조직에서 AWS 모범 사례에 따라 여러 계정으로 클라우드 환경을 구축하는 경향이 있습니다. 단일 VPC에서 호스팅 되는 여러 계정으로 공유 VPC를 사용하여 리소스를 공유하거나 VPC가 단일 계정에 연결되어있는 보다 전통적인 모델을 사용하는 경우 아키텍처를 고려해야합니다. 이 백서는 보다 전통적인 모델에 중점을 둡니다.
공유 VPC에 대한 자세한 내용은 공유 VPC 작업을 참조하십시오.
계정과 VPC가 여러 개인 경우 폭발 반경과 세분화 된 계정 수준 청구가 줄어들지 만 DNS 인프라가 더 복잡해질 수 있습니다. Route 53의 PHZ (Private Hosted Zone)를 VPC 및 계정과 연결하는 기능은 중앙 집중식 및 분산 형 아키텍처 모두에서 이러한 복잡성을 줄이는 데 도움이 됩니다. 이 섹션에서는 중앙 집중식 설계와 분산형 설계 패러다임을 모두 설명합니다.
Multi-Account Centralized
이러한 유형의 아키텍처에서는 Route 53 프라이빗 호스팅 영역 (PHZ)이 공유 서비스 VPC에서 중앙 집중화 됩니다. 이를 통해 중앙 DNS 관리가 가능하며 인바운드 Route 53 리졸버 엔드 포인트가 프라이빗 호스팅 영역을 기본적으로 쿼리 할 수 있습니다. 따라서 VPC-to-VPC DNS 확인이 필요하지 않습니다. 다행히 PHZ는 여러 VPC와 연결될 수 있습니다. 간단한 CLI 또는 API 요청으로 각 PHZ를 공유 서비스 VPC 외부의 계정에 있는 VPC와 연결할 수 있습니다.
교차 계정 PHZ 공유에 대한 자세한 내용은 Amazon VPC와 다른 AWS 계정으로 생성 한 프라이빗 호스팅 영역 연결을 참조하십시오.
이 아키텍처는 중앙 집중화를 제공하지만 계정 소유자가 자신의 DNS 레코드를 변경하고 수정할 수 있도록 각 VPC에 각 계정 내에 호스팅 된 자체 FQDN (정규화 된 도메인 이름)이 있어야 할 수 있습니다. 다음 섹션에서는이 디자인 패러다임을 달성하는 방법에 대한 자세한 정보를 제공합니다.
다중 계정 분산
조직은 DNS 소유권 및 관리를 각 AWS 계정에 위임할 수 있습니다. 이것은 제어의 분산화와 특정 계정으로의 실패에 대한 폭발 반경을 분리하는 이점을 가질 수 있습니다. 이 시나리오에서는 계정간에 PHZ를 VPC에 연결하는 기능이 다시 유용하게 됩니다. 각 VPC는 자체 PHZ를 보유한 후 여러 계정 및 리전에서 여러 다른 VPC와 연결할 수 있습니다. 이 아키텍처는 그림 7에 나와 있습니다. 온-프레미스 환경에서 통합 된 해결을 위해서는 공유 서비스 VPC가 PHZ를 호스팅하는 각 VPC와 연결 되기만 하면 됩니다.
대체 접근법
대체 방법은 EC2 인스턴스에 DNS 프록시 서버를 배포하거나 Active Directory DNS 서버에 응답하는 것입니다. 이 중앙 집중화는 바람직했지만 Route 53 Resolver 사용의 이점을 활용하지 않았으며 가용성 및 제약 조건을 유발할 수 있습니다.
마찬가지로 일반적인 안티 패턴은 Route 53 Resolver 엔드 포인트를 사용하여 공유 서비스 VPC 또는 Transit Gateway 내에서 DNS 관리를 중앙 집중화 하는 것입니다. 공유 서비스 VPC에서 인바운드 및 아웃 바운드 엔드 포인트를 생성 한 다음 대상이 중앙 집중식 VPC에서 인바운드 엔드 포인트의 IP 주소 인 전달 규칙을 생성하면 됩니다. 이러한 규칙은 다른 VPC와 연결되며 중앙 VPC의 인바운드 엔드 포인트를 사용하여 DNS 쿼리를 해결합니다. 이렇게 하면 스포크 VPC가 중앙 VPC의 DNS보기를 사용할 수 있습니다. 예를 들어 중앙 VPC에 EFS 마운트가있는 경우 스포크 VPC는 파일 시스템이 마운트 된 VPC의 인바운드 엔드 포인트로 쿼리를 전달하여 EFS 마운트의 DNS 이름을 확인할 수 있습니다.
이 방법은 바람직하지 않습니다. PHZ의 계정 간 공유는 가용성이 높으며 쿼리 전달보다 비용이 적게 듭니다. PHZ 공유는 가용 영역 격리를 유지하기 때문입니다. 즉, VPC A의 쿼리는 VPC A의 로컬 가용 영역에 의해 응답되는 반면 VPC B의 쿼리는 VPC B의 로컬 가용 영역에 의해 응답됩니다. VPC A에서 가용성 문제가 발생하는 경우 VPC B의 쿼리는 두 개의 서로 다른 가용 영역에 있는 한 영향을 받지 않습니다. PHZ를 VPC와 연결하는 데 추가 비용이 들지 않으며 1000 개 이상의 영역과 VPC를 공유 할 수 있습니다.
쿼리 전달은 AWS 네트워크 외부에 있는 다른 DNS 확인자에게 쿼리를 보내는 데 최적화되어 있습니다. 재귀 적 DNS 조회를 통해 일반적으로 표시되지 않을 때 서로 다른 네트워크의 DNS 확인자가 서로 액세스 할 수 있는 방법을 제공합니다. 다른 VPC에 대한 로컬 DNS 응답을 해결하기 위해 쿼리 전달을 사용하기로 선택한 경우이 DNS보기를 원하는 모든 VPC에 대한 엔드 포인트를 가져와야 합니다. 또한 엔드 포인트를 사용하여 VPC 간 쿼리에 응답하면 앞에서 언급 한 가용 영역 격리가 중단됩니다. 즉, 로컬 가용 영역 내에서 쿼리를 해결하는 각 VPC 대신 단일 VPC의 가용성에 따라 여러 VPC를 만들었습니다.
한계와 관련하여 각 엔드 포인트 탄력적 네트워크 인터페이스의 한계는 QPS가 10,000이지만, 엔드 포인트를 사용하여 DNS 관리를 중앙 집중화하려는 경우 여러 서버간에 쿼리로드를 분배하는 대신 더 많은 쿼리 볼륨을 중앙 VPC로 전달한다는 점을 명심하십시오. 이 안티 패턴은 일반적으로 권장되지 않습니다.
조직에 가장 적합한 솔루션 선택
이러한 각 솔루션에는 여러 가지 장점과 단점이 있습니다. 조직에 적합한 솔루션을 선택하는 것은 각 작업의 특정 요구 사항에 따라 다릅니다. 특정 워크로드의 요구를 충족시키기 위해 다른 VPC에서 다른 솔루션을 실행하도록 선택할 수 있습니다. 다음 표에는 조직에 가장 적합한 것을 평가하는 데 사용할 수 있는 기준이 요약되어 있습니다. 여기에는 구현의 복잡성, 관리 오버 헤드, 솔루션의 가용성, 네트워크 인터페이스 제한 당 PPS에 도달 할 가능성 및 솔루션 비용이 포함됩니다.
- 비용은 인프라와 운영 비용의 조합입니다.
빌드업웍스에서 AWS 무료 컨설팅을 진행합니다.
AWS에 대하여 궁금하신 내용이 있으시거나, 도입을 검토 중이시라면 편하게 신청해주세요.
