애니캐스트와 유니캐스트: 각각의 경우에 어느 것을 선택하는 것이 더 낫습니까?

아마도 많은 사람들이 Anycast에 대해 들어보셨을 것입니다. 이 네트워크 주소 지정 및 라우팅 방법에서는 단일 IP 주소가 네트워크의 여러 서버에 할당됩니다. 이러한 서버는 서로 멀리 떨어진 데이터 센터에 위치할 수도 있습니다. Anycast의 아이디어는 요청 소스의 위치에 따라 가장 가까운(네트워크 토폴로지, 더 정확하게는 BGP 라우팅 프로토콜에 따라) 서버로 데이터를 전송한다는 것입니다. 이렇게 하면 네트워크 홉 수와 대기 시간을 줄일 수 있습니다.

기본적으로 전 세계 여러 데이터 센터에서 동일한 경로가 광고됩니다. 따라서 클라이언트는 BGP 경로를 기반으로 "최적"과 "가장 가까운" 데이터 센터로 전송됩니다. 왜 애니캐스트인가? 유니캐스트 대신 애니캐스트를 사용하는 이유는 무엇입니까?

유니캐스트는 웹 서버가 하나이고 트래픽 양이 적당한 사이트에 매우 적합합니다. 그러나 서비스에 수백만 명의 가입자가 있는 경우 일반적으로 각각 동일한 IP 주소를 가진 많은 웹 서버를 사용합니다. 이러한 서버는 요청을 최적으로 처리하기 위해 지리적으로 분산되어 있습니다.

이 시나리오에서 Anycast는 성능을 향상시키고(트래픽은 최소한의 지연으로 사용자에게 전송됨) 서비스의 안정성(백업 서버 덕분에)을 보장하며 로드 밸런싱을 수행합니다. 여러 서버로 라우팅하면 서버 간에 로드가 효과적으로 분산되어 속도가 향상됩니다. 사이트의.

사업자는 Anycast 및 DNS를 기반으로 클라이언트에게 다양한 유형의 로드 밸런싱을 제공합니다. 클라이언트는 사이트의 지리적 위치에 따라 요청이 전송될 IP 주소를 지정할 수 있습니다. 이를 통해 사용자 요청을 보다 유연하게 배포할 수 있습니다.

예를 들어 하루에 100건의 요청을 처리하는 온라인 상점이나 인기 블로그와 같이 로드(사용자)를 분산해야 하는 여러 사이트가 있다고 가정해 보겠습니다. 사용자가 특정 사이트에 액세스하는 지역을 제한하려면 Geo 커뮤니티 옵션을 사용할 수 있습니다. 이를 통해 운영자가 경로를 광고할 지역을 제한할 수 있습니다.

애니캐스트와 유니캐스트: 차이점

Anycast는 DNS(Domain Name System) 및 CDN(Content Delivery Networks)과 같은 애플리케이션에서 자주 사용되어 네트워크 성능을 향상시키는 라우팅 결정을 가능하게 합니다. 콘텐츠 전송 네트워크는 대용량 트래픽을 처리하기 때문에 Anycast를 사용하며, Anycast는 이 경우 여러 가지 이점을 제공합니다(자세한 내용은 아래 참조). DNS에서 Anycast를 사용하면 서비스의 안정성과 내결함성 수준을 크게 높일 수 있습니다.

Anycast IP에서는 BGP를 사용할 때 특정 호스트에 대한 경로가 여러 개 있습니다. 이는 실제로 대기 시간이 짧은 연결을 설정하는 데 사용되는 여러 데이터 센터의 호스트 복사본입니다.

따라서 Anycast 네트워크에서는 동일한 IP 주소가 서로 다른 위치에서 광고되고 네트워크는 경로의 "비용"을 기반으로 사용자의 요청을 어디로 라우팅할지 결정합니다. 예를 들어 BGP는 데이터 전송을 위한 최단 경로를 결정하는 데 자주 사용됩니다. 사용자가 Anycast 요청을 보내면 BGP는 네트워크에서 사용 가능한 Anycast 서버에 대한 최적의 경로를 결정합니다.

애니캐스트의 장점

지연 시간 줄이기
Anycast를 사용하는 시스템은 가장 가까운 서버에서 데이터를 수신할 수 있으므로 사용자 요청을 처리할 때 대기 시간을 줄일 수 있습니다. 즉, 사용자는 항상 "가장 가까운"(라우팅 프로토콜 관점에서) DNS 서버에 연결됩니다. 결과적으로 Anycast는 클라이언트와 서버 간의 네트워크 거리를 줄여 상호 작용 시간을 줄입니다. 이는 대기 시간을 줄일 뿐만 아니라 로드 밸런싱도 제공합니다.

속도

트래픽이 가장 가까운 노드로 라우팅되고 클라이언트와 노드 사이의 대기 시간이 줄어들기 때문에 클라이언트가 어디에서 정보를 요청하든지 전송 속도가 최적화됩니다.

안정성 및 내결함성 향상

전 세계 여러 서버가 동일한 IP를 사용하는 경우 서버 중 하나에 장애가 발생하거나 연결이 끊어지면 트래픽이 가장 가까운 서버로 리디렉션됩니다. 결과적으로 Anycast는 서비스의 탄력성을 높이고 더 나은 네트워크 액세스/대기 시간/속도를 제공합니다. 

따라서 예를 들어 Anycast는 사용자가 여러 서버를 지속적으로 사용할 수 있도록 하여 DNS 안정성을 향상시킵니다. 노드에 장애가 발생하면 수동 개입이나 재구성 없이 사용자 요청이 다른 DNS 서버로 리디렉션됩니다. Anycast는 문제가 있는 사이트의 경로를 간단히 제거함으로써 다른 사이트로의 사실상 투명한 전환을 제공합니다. 

로드 밸런싱

Anycast에서는 네트워크 트래픽이 여러 서버에 분산됩니다. 즉, 로드 밸런서 역할을 하여 단일 서버가 대량의 트래픽을 수신하지 못하도록 합니다. 예를 들어 요청 소스로부터 동일한 지리적 거리에 여러 네트워크 노드가 있는 경우 로드 밸런싱을 사용할 수 있습니다. 이 경우 로드는 노드 간에 분산됩니다.

DoS 공격의 영향 감소 

Anycast의 또 다른 특징은 DDoS 저항입니다. DDoS 공격은 엄청난 양의 요청으로 해당 네트워크의 모든 서버를 압도해야 하기 때문에 Anycast 시스템을 다운시킬 수 없을 것입니다. 

DDoS 공격은 종종 봇넷을 사용하는데, 이는 너무 많은 트래픽을 생성하여 공격받는 서버에 과부하를 줄 수 있습니다. 이 상황에서 Anycast를 사용하면 각 서버가 공격의 일부를 "흡수"하여 특정 서버의 부하를 줄일 수 있다는 이점이 있습니다. 서비스 거부 공격은 서버에 국한될 가능성이 높으며 전체 서비스에 영향을 미치지 않습니다.

높은 수평 확장성

Anycast 시스템은 트래픽이 많은 서비스에 적합합니다. Anycast를 사용하는 서비스에서 증가된 트래픽을 처리하기 위해 새 서버가 필요한 경우 이를 처리하기 위해 네트워크에 새 서버를 추가할 수 있습니다. 새 사이트나 기존 사이트에 배치할 수 있습니다. 

특정 위치에서 트래픽이 크게 증가하는 경우 서버를 추가하면 해당 사이트의 로드 균형을 맞추는 데 도움이 됩니다. 새로운 사이트에 서버를 추가하면 일부 사용자를 위한 새로운 최단 경로가 생성되어 대기 시간을 줄이는 데 도움이 됩니다. 두 가지 방법 모두 네트워크에서 새 서버를 사용할 수 있게 되면 서비스의 안정성을 향상시키는 데도 도움이 됩니다. 이렇게 하면 서버가 오버로드된 경우 오버로드된 서버 요청의 일부를 수락할 수 있는 위치에 다른 서버를 배포하기만 하면 됩니다. 이를 위해서는 클라이언트 측의 구성이 필요하지 않습니다. 

이 방법을 통해서만 서버에 10Gbps 또는 25Gbps 포트가 몇 개만 있을 때 테라비트 규모의 트래픽과 매우 많은 수의 사용자에게 서비스를 제공할 수 있습니다. 하나의 IP 주소를 가진 100개의 호스트를 사용하면 테라비트 규모의 트래픽을 처리할 수 있습니다.

간편한 구성 관리

위에서 언급했듯이 Anycast의 흥미로운 용도는 DNS입니다. 네트워크 노드에 여러 개의 서로 다른 DNS 서버를 배치할 수 있지만 하나의 DNS 주소를 사용하십시오. 소스 위치에 따라 요청은 가장 가까운 노드로 라우팅됩니다. 이는 DNS 서버 오류가 발생할 경우 일부 트래픽 균형 조정 및 중복성을 제공합니다. 이렇게 하면 위치에 따라 다른 DNS 서버를 구성하는 대신 하나의 DNS 서버 구성을 모든 노드에 전파할 수 있습니다.

애니캐스트 네트워크는 거리뿐만 아니라 서버 존재 여부, 설정된 연결 수와 같은 매개변수에 따라 요청을 라우팅하도록 구성할 수 있습니다. 또는 응답 시간.

Anycast 기술을 사용하기 위해 클라이언트 측에 특별한 서버, 네트워크 또는 특별한 구성 요소가 필요하지 않습니다. 그러나 Anycast에는 단점도 있습니다. 구현은 추가 장비, 신뢰할 수 있는 공급자 및 적절한 트래픽 라우팅이 필요한 복잡한 작업이라고 생각됩니다.

순수한 소스에서 아름다움까지

Anycast는 가장 적은 홉을 기반으로 사용자를 라우팅하지만 이것이 반드시 가장 낮은 지연 시간을 의미하는 것은 아닙니다. 지연 시간은 XNUMX번보다 XNUMX번의 전환이 더 길 수 있기 때문에 더 복잡한 지표입니다.

예: 대륙 간 통신에는 대기 시간이 매우 긴 단일 홉이 포함될 수 있습니다.

Anycast는 주로 DNS와 같은 UDP 기반 서비스에 사용됩니다. 사용자 요청은 BGP 경로를 기반으로 "최적" 및 "가장 가까운" 데이터 센터로 라우팅됩니다.

예: Anycast DNS IP 주소가 123.10.10.10인 DNS 클라이언트 워크스테이션은 동일한 Anycast IP 주소를 사용하여 배포된 세 개의 DNS 이름 서버 중 가장 가까운 DNS 확인을 수행합니다. 라우터 R1 또는 서버 A가 실패하면 DNS 클라이언트 패킷은 라우터 R2 및 R3을 통해 다음으로 가장 가까운 DNS 서버로 자동 전달됩니다. 또한 서버 A에 대한 경로가 라우팅 테이블에서 제거되어 해당 네임서버를 더 이상 사용할 수 없게 됩니다.

배포 시나리오

사용자가 연결하는 서버를 결정하는 데 사용되는 두 가지 일반적인 체계가 있습니다.

• 애니캐스트 네트워크 계층. 사용자를 가장 가까운 서버에 연결합니다. 여기서는 사용자에서 서버까지의 네트워크 경로가 중요합니다.
• 애플리케이션 레벨 애니캐스트. 이 구성표에는 서버 가용성, 응답 시간, 연결 수 등을 포함하여 더 많은 계산된 지표가 있습니다. 이는 네트워크 통계를 제공하는 외부 모니터에 따라 다릅니다.

Anycast 기반 CDN

이제 콘텐츠 전송 네트워크에서 Anycast를 사용하는 방법으로 돌아가 보겠습니다. Anycast는 확실히 흥미로운 네트워킹 개념이며 차세대 CDN 제공업체 사이에서 점점 더 많은 수용을 얻고 있습니다.

CDN은 고가용성과 짧은 대기 시간으로 최종 사용자에게 콘텐츠를 제공하는 분산형 서버 네트워크입니다. 콘텐츠 전달 네트워크는 오늘날 많은 온라인 미디어 서비스의 중추로서 중요한 역할을 하고 있으며, 소비자는 느린 다운로드 속도에 점점 더 관대해지지 않고 있습니다. 비디오 및 음성 애플리케이션은 특히 네트워크 지터 및 대기 시간에 민감합니다.

CDN은 모든 서버를 하나의 네트워크로 연결하고 콘텐츠를 더 빠르게 로드합니다. 때로는 사용자의 대기 시간을 5~6초 정도 줄이는 것이 가능합니다. CDN의 목적은 최종 사용자에게 가장 가까운 서버에서 콘텐츠를 제공하여 전달을 최적화하는 것입니다. 이는 최종 사용자의 위치를 ​​기준으로 가장 가까운 서버를 선택하는 Anycast와 매우 유사합니다. 모든 CDN 서비스 제공업체가 기본적으로 Anycast를 사용하는 것처럼 보이지만 실제로는 그렇지 않습니다.

HTTP/TCP와 같은 프로토콜을 사용하는 애플리케이션은 설정된 연결에 의존합니다. 새로운 Anycast 노드가 선택되면(예: 서버 장애로 인해) 서비스가 중단될 수 있습니다. 이것이 이전에 UDP 및 DNS와 같은 비연결 서비스에 Anycast가 권장되었던 이유입니다. 그러나 Anycast는 연결 지향 프로토콜에서도 잘 작동합니다. 예를 들어 TCP는 Anycast 모드에서 잘 작동합니다.

일부 CDN 제공업체는 Anycast 기반 라우팅을 사용하고 다른 제공업체는 DNS 기반 라우팅을 선호합니다. 즉, 사용자의 DNS 서버 위치에 따라 가장 가까운 서버가 선택됩니다.

하이브리드 및 다중 데이터 센터 인프라는 Anycast 사용의 또 다른 예입니다. 공급자로부터 받은 로드 밸런싱 IP 주소를 사용하면 공급자의 데이터 센터에 있는 다양한 클라이언트 서비스의 IP 주소 간에 로드를 분산할 수 있습니다. 모든 장치 기술 덕분에 트래픽이 많을 때 더 나은 성능과 내결함성을 제공하고 많은 수의 사용자를 처리할 때 응답 시간을 최적화하는 데 도움이 됩니다.

하이브리드 멀티 데이터 센터 인프라에서는 서버 전체 또는 전용 서버의 가상 머신 전체에 트래픽을 분산할 수 있습니다.

따라서 인프라 구축을 위한 다양한 기술 솔루션이 있습니다. 또한 사이트 성능을 최적화하기 위해 그룹의 모든 장치를 대상으로 여러 데이터 센터의 IP 주소에 대한 로드 밸런싱을 구성할 수도 있습니다.

각 데이터 센터에 분산된 각 서버의 "가중치"를 정의하여 자체 규칙에 따라 트래픽을 분산할 수 있습니다. 이 구성은 분산된 서버 파크가 있고 서비스 성능이 고르지 않을 때 특히 유용합니다. 이렇게 하면 트래픽을 더 자주 분산하여 서버 성능을 향상시킬 수 있습니다.

ping 명령을 사용하여 모니터링 시스템을 생성하려면 프로브를 구성할 수 있습니다. 이를 통해 관리자는 자체 모니터링 절차를 정의하고 인프라의 각 구성 요소 상태를 더욱 명확하게 파악할 수 있습니다. 이러한 방식으로 접근성 기준을 정의할 수 있습니다.

하이브리드 인프라 구축이 가능합니다. 때로는 백오피스를 기업 네트워크에 두고 인터페이스 부분을 공급자에게 아웃소싱하는 것이 편리할 때도 있습니다.

로드 밸런싱, 전송된 데이터 암호화, 사이트 방문자와 기업 인프라 간 통신 보안을 위해 SSL 인증서를 추가할 수 있습니다. 데이터 센터 간 로드 밸런싱의 경우 SSL을 사용할 수도 있습니다.

주소 로드 밸런싱이 포함된 Anycast 서비스는 공급자로부터 얻을 수 있습니다. 이 기능은 사용자가 위치를 기반으로 앱과 상호 작용하는 방식을 개선하는 데 도움이 됩니다. 데이터 센터에서 어떤 서비스를 이용할 수 있는지 발표하는 것만으로도 충분하며, 트래픽은 가장 가까운 인프라로 리디렉션됩니다. 예를 들어 프랑스나 북미에 전용 서버가 있는 경우 클라이언트는 네트워크에서 가장 가까운 서버로 연결됩니다.

Anycast 사용 옵션 중 하나는 운영자의 PoP(Point of Presence)를 최적으로 선택하는 것입니다. 주자 예. LinkedIn(러시아에서는 차단됨)은 자사 제품(모바일 및 웹 애플리케이션)의 성능과 속도를 향상시킬 뿐만 아니라 더 빠른 콘텐츠 전달을 위해 네트워크 인프라를 개선하기 위해 노력하고 있습니다. 이러한 동적 콘텐츠 전달을 위해 LinkedIn은 PoP(Point of Presence)를 적극적으로 사용합니다. 애니캐스트는 사용자를 가장 가까운 PoP로 안내하는 데 사용됩니다.

그 이유는 유니캐스트의 경우 LinkedIn PoP마다 고유한 IP 주소가 있기 때문입니다. 그런 다음 사용자는 DNS를 사용하여 지리적 위치를 기반으로 PoP에 할당됩니다. 문제는 DNS를 사용할 때 미국 사용자의 약 30%가 최적이 아닌 PoP로 리디렉션되었다는 것입니다. Anycast의 단계적 구현으로 차선의 PoP 할당이 31%에서 10%로 감소했습니다.

파일럿 테스트의 결과는 그래프에 표시되며, 여기서 Y축은 최적의 PoP 할당 비율입니다. Anycast가 증가함에 따라 미국의 많은 주에서 최적의 PoP를 향한 트래픽 비율이 향상되었습니다.

애니캐스트 네트워크 모니터링

애니캐스트 네트워크는 이론적으로 간단합니다. 여러 물리적 서버에 BGP가 경로를 결정하는 데 사용하는 동일한 IP 주소가 할당됩니다. 그러나 Anycast 플랫폼의 구현과 설계는 복잡하며 내결함성 Anycast 네트워크가 특히 유명합니다. 훨씬 더 어려운 일은 Anycast 네트워크를 효과적으로 모니터링하여 오류를 신속하게 식별하고 격리하는 것입니다.

서비스가 타사 CDN 공급자를 사용하여 콘텐츠를 제공하는 경우 네트워크 성능을 모니터링하고 확인하는 것이 매우 중요합니다. 애니캐스트 기반 CDN 모니터링은 어느 데이터 센터가 콘텐츠를 제공하고 있는지 이해하기 위해 종단 간 대기 시간과 두 번째 홉 성능을 측정하는 데 중점을 둡니다. HTTP 서버 헤더를 분석하는 것은 데이터가 어디서 오는지 확인하는 또 다른 방법입니다.

예: CDN 서버의 위치를 ​​나타내는 HTTP 응답 헤더.

예를 들어 CloudFlare는 요청이 이루어진 데이터 센터에 대한 표시를 포함하는 HTTP 응답 메시지에 자체 CF-Ray 헤더를 사용합니다. Zendesk의 경우 시애틀 지역의 CF-Ray 헤더는 CF-RAY: 2a21675e65fd2a3d-SEA이고, 암스테르담의 경우 CF-RAY: 2a216896b93a0c71-AMS입니다. 또한 HTTP 응답의 HTTP-X 헤더를 사용하여 콘텐츠의 위치를 ​​확인할 수도 있습니다.

기타 주소 지정 방법

사용자 요청을 특정 네트워크 끝점으로 라우팅하는 다른 주소 지정 방법이 있습니다.

유니 캐스트

오늘날 대부분의 인터넷에서는 이 방법을 사용합니다. 유니캐스트 - 유니캐스트 전송, IP 주소는 네트워크의 특정 노드 하나에만 연결됩니다. 이를 일대일 매칭이라고 합니다. 

멀티 캐스트

멀티캐스트는 일대다 또는 다대다 관계를 사용합니다. 멀티캐스트를 사용하면 보낸 사람의 요청을 선택한 다른 끝점으로 동시에 보낼 수 있습니다. 이를 통해 클라이언트는 여러 호스트에서 동시에 파일을 청크로 다운로드할 수 있습니다(오디오 또는 비디오 스트리밍에 유용함). 멀티캐스트는 애니캐스트와 혼동되는 경우가 많지만 애니캐스트는 여러 노드를 사용할 수 있는 경우에도 발신자를 하나의 특정 노드로 연결한다는 점이 가장 큰 차이점입니다.

방송

단일 보낸 사람의 데이터그램은 브로드캐스트 주소와 관련된 모든 끝점으로 전달됩니다. 네트워크는 브로드캐스트(일반적으로 동일한 서브넷에 있음)의 모든 수신자에게 도달할 수 있도록 데이터그램을 자동으로 복제합니다.

지오캐스트

Geocast는 멀티캐스트와 다소 유사합니다. 발신자의 요청이 동시에 여러 엔드포인트로 전송됩니다. 그러나 차이점은 수취인이 지리적 위치에 따라 결정된다는 것입니다. 이는 모바일 Ad Hoc 네트워크용 일부 라우팅 프로토콜에서 사용되는 특수한 형식의 멀티캐스트입니다.

지리적 라우터는 서비스 영역을 계산하고 대략적으로 계산합니다. 서비스 지역을 교환하는 지오라우터는 라우팅 테이블을 구축합니다. 지오라우터 시스템은 계층적 구조를 가지고 있습니다.

유니캐스트, 멀티캐스트 및 브로드캐스트.

Anycast 기술을 사용하면 DNS의 신뢰성, 내결함성 및 보안 수준이 향상됩니다. 이 기술을 사용하여 운영자는 DNS를 기반으로 다양한 유형의 로드 밸런싱을 위한 클라이언트 서비스를 제공합니다. 제어판에서 지리적 위치에 따라 요청이 전송될 IP 주소를 지정할 수 있습니다. 이를 통해 클라이언트는 사용자 요청을 보다 유연하게 배포할 수 있습니다.

일부 운영자는 각 접속 지점(POP)에서 경로 모니터링 기능을 구현합니다. 시스템은 접속 지점에 대한 최단 로컬 및 글로벌 경로를 자동으로 분석하고 가동 중지 시간 없이 대기 시간이 가장 낮은 지리적 위치를 통해 경로를 라우팅합니다.

현재 Anycast는 안정성과 신뢰성에 대한 요구 사항이 높은 고부하 DNS 서비스를 구축하기 위한 가장 안정적이고 신뢰할 수 있는 솔루션입니다.

.ru 도메인은 35개의 노드로 그룹화되고 20개의 Anycast 클라우드에 분산된 XNUMX개의 Anycast DNS 서버를 지원합니다. 이 경우 지리적 특성에 기초한 건축 원리가 사용됩니다. 지오캐스트. DNS 노드를 배치할 때 가장 활동적인 사용자, 노드가 위치한 지점의 러시아 공급자의 최대 집중도, 무료 용량의 가용성 및 용이성과 가까운 지리적으로 분산된 위치로 이동될 것으로 예상됩니다. 사이트와의 상호 작용.

CDN을 구축하는 방법은 무엇입니까?

CDN은 사용자에게 콘텐츠 전달 속도를 높이는 서버 네트워크입니다. 콘텐츠 전달 네트워크 모든 서버를 하나의 네트워크로 통합하고 더 빠른 콘텐츠 로딩을 보장합니다. 서버에서 사용자까지의 거리는 로딩 속도에 중요한 역할을 합니다.

CDN을 사용하면 대상 고객에게 가장 가까운 서버를 사용할 수 있습니다. 이렇게 하면 대기 시간이 줄어들고 모든 방문자의 사이트 콘텐츠 로드 속도가 빨라집니다. 이는 대용량 파일이나 멀티미디어 서비스가 있는 사이트에 특히 중요합니다. CDN의 일반적인 애플리케이션은 전자상거래와 엔터테인먼트입니다.

사용자와 최대한 가까운 CDN 인프라에 구축된 추가 서버의 네트워크는 보다 안정적이고 빠른 데이터 전달에 기여합니다. 통계에 따르면 CDN을 사용하면 CDN이 없는 사이트에 비해 사이트에 액세스할 때 대기 시간이 70% 이상 줄어듭니다.

방법 DNS를 사용하여 CDN 생성? Anycast의 자체 솔루션을 사용하여 CDN을 설정하는 것은 상당히 비용이 많이 드는 프로젝트일 수 있지만 더 저렴한 옵션이 있습니다. 예를 들어, 고유한 IP 주소를 가진 GeoDNS 및 일반 서버를 사용할 수 있습니다. GeoDNS 서비스를 사용하면 DNS 확인자의 위치가 아닌 방문자의 실제 위치를 기반으로 결정이 이루어지는 지리적 위치 기능이 있는 CDN을 만들 수 있습니다. 미국 방문자에게 미국 서버 IP 주소를 표시하도록 DNS 영역을 구성할 수 있지만, 유럽 방문자에게는 유럽 IP 주소가 표시됩니다.

GeoDNS를 사용하면 사용자의 IP 주소에 따라 다른 DNS 응답을 반환할 수 있습니다. 이를 위해 DNS 서버는 요청의 소스 IP 주소에 따라 다른 IP 주소를 반환하도록 구성됩니다. 일반적으로 GeoIP 데이터베이스는 요청이 이루어진 지역을 결정하는 데 사용됩니다. DNS를 사용한 위치정보를 사용하면 근처 사이트의 사용자에게 콘텐츠를 보낼 수 있습니다.

GeoDNS는 DNS 요청을 보낸 클라이언트의 IP 주소 또는 클라이언트 요청을 처리할 때 사용되는 공급자의 재귀 DNS 서버의 IP 주소를 결정합니다. 국가/지역은 클라이언트의 IP 및 GeoIP 데이터베이스에 의해 결정됩니다. 그런 다음 클라이언트는 가장 가까운 CDN 서버의 IP 주소를 얻습니다. GeoDNS 설정에 대해 자세히 알아볼 수 있습니다. 여기에.

애니캐스트 또는 GeoDNS?

Anycast는 글로벌 규모로 콘텐츠를 전달하는 훌륭한 방법이지만 구체성이 부족합니다. 이것이 GeoDNS가 구출되는 곳입니다. 이 서비스를 사용하면 위치에 따라 사용자를 고유한 엔드포인트로 보내는 규칙을 만들 수 있습니다.

예: 유럽의 사용자는 다른 엔드포인트로 연결됩니다.

모든 요청을 삭제하여 도메인에 대한 액세스를 거부할 수도 있습니다. 특히 침입자를 차단하는 빠른 방법입니다.

GeoDNS는 Anycast보다 더 정확한 답변을 제공합니다. Anycast의 경우 최단 경로가 홉 수에 따라 결정되는 경우 GeoDNS에서는 최종 사용자의 라우팅이 물리적 위치에 따라 발생합니다. 이렇게 하면 세부적인 라우팅 규칙을 만들 때 대기 시간이 줄어들고 정확성이 향상됩니다.

도메인으로 이동할 때 브라우저는 가장 가까운 DNS 서버에 접속하며, 도메인에 따라 IP 주소를 발급하여 사이트를 로드합니다. 온라인 상점이 미국과 유럽에서 인기가 있지만 해당 상점의 DNS 서버는 유럽에서만 사용할 수 있다고 가정해 보겠습니다. 그러면 스토어의 서비스를 이용하려는 미국 사용자는 가장 가까운 서버에 요청을 보내야 하며, 서버가 매우 멀리 떨어져 있기 때문에 응답을 기다리는 데 오랜 시간이 걸리며 사이트가 빠르게 로드되지 않습니다.

GeoDNS 서버가 미국에 있으면 사용자는 이미 해당 서버에 액세스하게 됩니다. 응답이 빨라 사이트 로딩 속도에 영향을 미칩니다.

미국에 기존 DNS 서버가 있는 상황에서 미국 사용자가 특정 도메인으로 이동하면 필요한 IP를 제공할 가장 가까운 서버에 연결됩니다. 사용자는 사이트의 콘텐츠가 포함된 서버로 연결되지만, 콘텐츠가 있는 서버가 멀리 떨어져 있기 때문에 빨리 받을 수 없습니다.

캐시된 데이터를 사용하여 미국에서 CDN 서버를 호스팅하는 경우 클라이언트 브라우저가 로드되면 가장 가까운 DNS 서버에 요청을 보내고, 이 서버는 필요한 IP 주소를 다시 보냅니다. IP를 받은 브라우저는 가장 가까운 CDN 서버 및 메인 서버에 접속하고, CDN 서버는 캐시된 콘텐츠를 브라우저에 서비스합니다. 캐시된 콘텐츠가 로드되는 동안 전체 사이트를 로드하기 위해 누락된 파일이 메인 서버로부터 수신됩니다. 결과적으로 메인 서버에서 전송되는 파일 수가 훨씬 적기 때문에 사이트 로딩 시간이 단축됩니다.

특정 IP 주소의 정확한 위치를 결정하는 것이 항상 쉬운 작업은 아닙니다. 많은 요인이 작용하며 IP 주소 범위의 소유자는 이를 세계 반대편에 광고하기로 결정할 수 있습니다(그런 다음 데이터베이스가 도착할 때까지 기다려야 함). 올바른 위치를 얻으려면 업데이트하세요). 때때로 VPS 제공업체는 미국에 있는 것으로 추정되는 주소를 싱가포르의 VPS에 할당합니다.

Anycast 주소를 사용하는 것과 달리 캐싱 서버에 연결하는 동안이 아니라 이름 확인 중에 배포가 수행됩니다. 재귀 서버가 EDNS 클라이언트 서브넷을 지원하지 않는 경우 캐싱 서버에 연결할 사용자 대신 해당 재귀 서버의 위치가 사용됩니다.

DNS의 클라이언트 서브넷은 재귀 DNS 서버가 클라이언트 정보, 특히 GeoDNS 서버가 클라이언트 위치를 보다 정확하게 확인하는 데 사용할 수 있는 네트워크 정보를 보낼 수 있는 방법을 정의하는 DNS(RFC7871)의 확장입니다.

대부분은 ISP의 DNS 서버나 지리적으로 가까운 DNS 서버를 사용하지만, 미국에 있는 누군가가 어떤 이유로 호주에 있는 DNS 확인자를 사용하기로 결정하면 호주에 가장 가까운 IP 서버 주소를 갖게 될 가능성이 높습니다.

GeoDNS를 사용하려면 어떤 경우에는 캐싱 서버와 클라이언트 사이의 거리를 늘릴 수 있으므로 이러한 기능을 알고 있는 것이 중요합니다.

요약: 여러 VPS를 CDN으로 결합하려는 경우 가장 좋은 배포 옵션은 즉시 사용 가능한 GeoDNS + Anycast 기능이 포함된 DNS 서버 번들을 사용하는 것입니다.

출처 : habr.com