DNS와 그 작동 방식에는 IT의 모든 측면에서 더 많은 오해, 범례, 미신 및 신화가 수반 될 수 있습니다.

우리가 변화의 “전파”에 대해 이야기 할 때 우리가 본질적으로 거짓말을하거나 (또는 ​​적어도 과도하게 단순화하고 있음) 알고있는 사람들조차도이 용어를 사용하여 매우 간단하고 간단한 것을 동시에 설명하는 경향이 있습니다 … 그러나 설명하기가 어렵고 전파 자체 와는 관련이 없지만 캐싱 및 네거티브 캐싱과 관련된 모든 것은 시스템 작동 방식의 필수 구성 요소입니다. 본질적으로 실제 “전파”와 반대되는 내부-아웃 (in-out)-밀기 –

짧은 TTL에 대한 모든 걱정과 수고를 위해, 그들은 단순히 시험해 보는 것이 당신의 관심사에있을 수있을 정도로 더 자주 일하는 경향이 있습니다. $ {day_job}에 사이트가 “오래된”플랫폼에서 “새로운”플랫폼으로 마이그레이션 될 때 인프라의 어떤 것도 공유되지 않는 방식으로 마이그레이션되고 있음을 의미합니다. 이러한 마이그레이션의 첫 단계는 이전 TTL을 60 배로 떨어 뜨려 이전 TTL에 여러 배수가 없어서 TTL이 짧은 이러한 과도 적 RR이 “전파됨”을 합리적으로 보장합니다. ” 컷을 할 준비가되면 인터넷을 통해 새로운 시스템에 트래픽을 고정하기 위해 기존 밸런서를 ¹로 재구성하여 밸런서가 더 이상 여러 내부 시스템의 밸런싱을 수행하지 않고 “

그런 다음 DNS를 컷 오버하고 새 밸런서와 이전을 봅니다.

나는 전환이 얼마나 빨리 일어나는지 항상 기쁘게 생각합니다. 유인물은 거의 항상 검색 스파이더와 오래된 레코드에 대한 예측이 불가능한 타사 “상태 확인”사이트 인 것 같습니다.

그러나 예측 가능한 세 가지 시나리오가 있습니다. 사용자의 브라우저 창이 열린 상태로 유지되면 이미 발견 된 주소에 고정되는 경향이 있으며 모든 브라우저 창이 닫힐 때까지 지속되는 경우가 많습니다.

그러나 위의 설명에서 문제에 대한 해결책을 찾을 수 있습니다. “로드 밸런서”-구체적으로 말하면 리버스 프록시는 노출 된 DNS 레코드가 가리키는 시스템 일 수 있습니다.

리버스 프록시는 요청을 올바른 대상 IP 주소로 전달합니다.이 주소는 실제 백엔드 서버를 가리키는 짧은 TTL을 가진 두 번째 “더미”호스트 이름을 사용하여 확인됩니다. ³ 프록시는 항상 더미 DNS를 입력하면 신속하고 완벽한 전환이 보장됩니다.

단점은 불필요한 추가 인프라를 통해 트래픽을 라우팅하거나 여러 네트워크 경계를 넘어서 전송하는 데 더 많은 비용을 지불 할 수 있다는 것입니다.

이러한 규모의 기능을 전 세계적으로 제공하는 서비스가 있으며 가장 친숙한 서비스는 CloudFront입니다. (아마도 내가 한 작은 테스트가 올바르게 작동한다는 것을 나타내며 다른 것들이 있다고 확신하기 때문에 Cloudflare는 정확히 동일한 목적을 수행합니다.)

기본적으로 CDN으로 판매되었지만 CloudFront는 선택적 으로 응답 캐싱 기능을 갖춘 글로벌 역 프록시 프록시 네트워크의 핵심 입니다. 경우 www.example.comCloudFront를하고 CloudFront를 포인트는 이러한 요청 전달하도록 구성되어 backend.example.com및 대한 DNS 레코드를 backend.example.com사용하는 짧은 TTL을 그 명예가하는 짧은 TTL 것을 때문에, 다음 CloudFront를가 옳은 일을 할 것입니다. 백엔드 레코드가 변경되면 TTL이 종료 될 때까지 트래픽이 모두 마이그레이션됩니다.

CloudFront를 가리키는 전면 레코드의 TTL과 브라우저 및 캐싱 리졸버가이를 존중하는지 여부는 중요하지 않습니다. 백엔드 대상을 변경할 때 www.example.com레코드를 변경할 필요가 없기 때문에 “인터넷”이라는 개념 www.example.com백엔드 시스템의 위치에 상관없이 올바른 대상과 관련하여 일관성이 있습니다.

이것은 나에게 원래 서버의 IP에 대한 변경을 “따라야”할 필요가없는 브라우저를 줄여서 문제를 완전히 해결합니다.

tl; dr : 요청을 실제 웹 서버의 프록시 역할을하는 시스템으로 라우팅하여 프록시 구성 만 브라우저 기반 DNS가 아닌 원래 서버 IP의 변경을 수용하면됩니다.

CloudFront는 또한 전면에 부과하는 일부 DNS 마법에 의해 대기 시간을 최소화 하므로 www.example.com쿼리하는 브라우저의 위치를 ​​기반으로 가장 최적의 CloudFront 엣지 로케이션 을 해결 www.example.com하므로 트래픽이 불필요하게 회로적인 경로를 취할 가능성이 최소화됩니다. 브라우저에서 가장자리, 원점까지 …하지만이 부분은 투명하고 자동이며 질문의 범위를 벗어납니다.

물론 오리지널 서버 또는 전송의로드를 줄임으로써 컨텐츠 캐싱도 가치가있을 수 있습니다. 오리진 서버가 ADSL 회로에있는 CloudFront에서 웹 사이트를 구성했으며 ADSL은 본질적으로 업스트림 대역폭으로 제한되어 있습니다. 컨텐츠를 가져 오기 위해 CloudFront가 연결되는 오리진 서버는 AWS 에코 시스템 내부의 서버 일 필요는 없습니다.

¹ 실제로 여러 노드가있는 경우 밸런서를 단일 엔티티로 말합니다. 밸런서가 ELB 인 경우 밸런서 뒤의 시스템은 더미 앱 서버 역할을하며 ELB가 자체적으로이를 수행 할 수 없으므로 새 플랫폼의 밸런서에 실제 헤어핀을 수행합니다.

² 이전 밸런서에 대한 새로운 밸런서의 유일한 지식은 이전 밸런서의 X-Forwarded-For를 신뢰해야하며 이전 밸런서의 소스 주소에 대해 IP 기반 속도 제한을 수행해서는 안된다는 것입니다.

³ 프록시가 사용자가 제어하는 ​​하나 이상의 서버 인 경우 뒷면에서 DNS를 사용하지 않고 프록시 구성에서 IP 주소를 사용하는 옵션을 사용할 수 있지만 이후에 논의되는 호스팅 / 분배 시나리오에는 DNS의 두 번째 계층이 필요합니다 .

답변