Что такое RUM?
Думаю многие знакомы с RUM, он же Real User Monitoring. Но, если нет, то существует два типа замеров производительности вашего сайта:
• Synthetic. Этот функционал делают миллион разных “пингалок”: Pingdom, site24x7, StatusCake, Pingdom, Uptimerobot, etc. Они C разных локаций заходят к вам на сайт, и условно через
curl -H 'Cache-Control: no-cache' -Lw "DNS Lookup: %{time_namelookup} seconds \nRedirects: %{time_redirect} seconds with %{num_redirects} redirects \nFirst Byte: %{time_starttransfer} seconds \nConnect Time: %{time_connect} seconds \nTotal Time: %{time_total} seconds\n" -so /dev/null http://apple.com/рисуют вам эти же значения в красивый UI. Все ок, но локации как правило статические, так же они находятся в датацентрах, что совсем не тоже самое, что юзерский интернет.
• RUM. Это подключаемая к вам на сайт js-библиотека, которая при каждой загрузке страницы отправляет кучу перфоманс данных в сторону коллектора, и вам рисуют красивые данные в UI. Только точность тут гораздо выше, т.к. собирается все это прямо в браузере клиента, со всеми его особенностями той самой Last mile.
Вроде понятно. Причем тут DNS?
Зайдем издалека, и поговорим с желтой 🦆 о вот какой проблеме.
- Уточка, хочу стать поближе и побыстрее к своим клиентам? Что посоветуешь?
- Уточка: конечно же подключить CDN!
- А какой CDN подключаем? Akamai, CloudFront, Google, CloudFlare? Кто из них будет лучше для всех регионов сразу и даже стран?
- Уточка: а давай подключим все сразу?
- А давай! Правда все еще непонятно какой CDN для какой страны использовать! Кто там у нас лучше всех перформит в Индии?
- Уточка: но CDN же крутые, они используют Anycast, он все сам разрулит!
- Хм, но меньшее количество хопов ≠ лучшее latency!
- Уточка: ....ладно, что же делать?
И вот тут в игру вступает DNS Traffic Steering based on RUM. В свой(не обязательно) сайт ставляем js-ку, но, очень обрезанную по-сравнению с классическим RUM. Меряем мы только latency и какие-то еще performance штуки до ближайших точек PoP ваших CDN в этом регионе, берем эти цифры и отправляем в сторону вашего коллектора, условного хадупа. Обрабатываем данные, и постоянно перестраиваем “таблицу маршрутизации” на основании того, кто лучше перформит конкретно в этой локации, соотвественно, кого и в какую точку отправлять с помощью наших днсов. Как пример, для Ирландии мы выставили использовать Akamai и CloudFlare, и вот флара взяла и отправила точку на обслуживание, и весь трафик у них начал ходить через Лондон, latency увеличилась, и все органически перетечет в Akamai. Причем настолько быстро насколько низкие у вас TTL. Тоже самое сработает при полном отказе одного из CDN, да такое тоже бывает 😉
Самые внимательные спросят: так ведь мы уже зашли на сайт, резолвы где-то там позади?
По-факту замер RUM и клиентские резолвы не обязательно связаны. В целом, есть всего два сценария:
- Клиент использует EDNS, и присылает вместе с днс реквестом свою сабнет сеть, а значит и Autonomous System (AS). В базе резолвера за счет других клиентов уже есть перфоманс информация о вашей AS, и вам сразу же отдают правильные ip адреса PoP, CDN и прочее, используя т.н. “таблицу маршрутизации”, которая обновляется постоянно, практически реал-тайм.
- Клиент не использует EDNS, тогда берется IP резолвера например и отдается лучший вариант из агрегированной статистики для клиентов, которые находятся за этим резолвером и уже присылали какую-то статистику. Не редко крупные провайдеры могут шарить между собой обезличенные базы, чтобы лучше покрывать такие кейсы. А также вы можете принести свои данные, или community-sourced, чтобы лучше управлять своим трафиком.
Пруфов не предоставлю, т.к. давно было, но тот же AWS CloudFront на заре своего запуска использовал данные RUM, которые они собирали с Amazon.com, и таким образом сильно повысили качество своего CDN.