HighLoad.org – блог о высоких нагрузках
HighLoad.org > Балансировка трафика основанная на ГЕО-информации и кэширование на CNBC.COM

Балансировка трафика основанная на ГЕО-информации и кэширование на CNBC.COM
2010-02-15 17:04 my_fess 
CNBC, как многие другие большие сайты, использует CDN для доставки контента. С недавних пор мы начали искать улучшения этой модели. У нас были следующие критерии:
  • Улучшить время ответа.
  • Получить более хороший контроль над трафиком (отчеты в реальном времени, управление изменениями и предупреждениями).
  • Лучше использовать внутренние дата-центры и их инфраструктуры.
  • Оградить пользователей от любых проблем в текущей инфраструктуре.
  • Снизить затраты.
После исследования рынка, мы выбрали два продавца: Dyn (Dynamic Network Services) и aiCache. У нас уже был год богатого опыта работы с aiCache (поиск для CNBC), а Dyn был новым продавцом для нас. Мы начали строить наши взаимоотношения летом 2009 года на конференции Velocity. Dyn недавно начал предоставлять решение для балансировки нагрузки на основе гео-информации DNS, используя Anycast и распределенную природу их DNS существования, таким образом предоставляя ключевой компонент, именно который нам был нужен: направлять пользователей к географически ближайшей к ним отправной точке. Правила балансировки нагрузки могут быть очень гибкими. Например:
  • Отправить 70% трафика Южного Побережья США в точку A, 30% в CDN.
  • Отправить 50% трафика Западного Побережья США в точку B, 25% в C, и оставшиеся в CDN.
  • Отправить всю Европу в точку D.
  • Отправить всю Азию в CDN.
Dyn также на своем гибком и удобном для использования портале предлагает набор дополнительных сервисов, таких как: автоматический мониторинг, преодоление отказов, предупреждения и отчеты по трафику. Сейчас я ненаучным языком объясню как Anycast работает. В принципе, для отправки пользователя в географически ближайшую точку необходимо иметь представление, где находится пользователь. Традиционным способом является запросить информацию из базы данных, трансформируя IP адрес в местоположение. Такие базы данных широко распространены и используются в различных продуктах,включая гео-таргетированную рекламу. Сильно отличающийся, менее точный, путь решения той же проблемы — использование интернет маршрутизации (протокол BGP) для перенаправления маршрутов в теже IP адреса из множества имеющихся точек. Например, представим, что мы имеем 4 DNS кластера, каждый кластер содержит 4 узла с IP адресами 1.1.1.1, 1.1.1.2, 1.1.1.3 и 1.1.1.4. Каждый кластер расположен в одной из главных точек: Восточном Побережье США, Западном Побережье США, один в Европе и один в Азии. Из каждого местоположения, один из них направляет с помощью BGP в туже подсеть с нашим DNS серверами в ней. Миссия выполнена! С помощью магии маршрутизации, DNS запросы пользователей из Азии пойдут в DNS сервера, находящиеся в Азии, запросы из Европы пойдут в Европу и так далее. Теперь ясно, как знания о местоположение запрашивающего могут быть использованы, чтобы направлять трафик в конкретное, географически-определенное место. Мы используем низкое значение настройки DNS TTL, таким образом мы можем гарантировать, что любые изменения DNS войдут в силу в допустимый короткий интервал времени. Посмотрим на это с другой стороны: пользователь хочет посетить www.cnbc.com, его браузер запрашивает DNS разрешение имени для www.cnbc.com. DNS запрос естественно пойдет к ближайшему кластеру Dyn DNS. Кластер DNS серверов имеет некоторые предположения о местоположение. Основываясь на этом, DNS сервер делает выводы, что запросы исходят от пользователей в той же самой географической зоне и, основываясь на это и на набор правил, которым мы его сконфигурировали, он направляет запрашивающего пользователя в соответствующую точку для www.cnbc.com. Для отправных точек на Восточном и Западном Побережье США мы выбрали наши собственные дата-центры, каждый с многогигабитной шириной выходного канала. Для доставки трафика решение было простым — мы решили использовать движки кеширования от aiCache, которые мы использовали почти год для других проектов. Все что нам понадобилось для доставки всего трафика для наших пользователей в США — это всего лишь четыре 1RU блэйд сервера, по два в каждое место. Последняя версия aiCache v6 была протестирована на выполнение 250,000 RPS на обычном сервере HP DL360. aiCahce работает на любом Linux дистрибутиве, включая наш традиционный RedHat 5.x. В нашем случае, запросы к www.cnbc.com в пике достигают 3000 RPS, таким образом у нас есть большой запас производительности для любого возможного пика трафика. В итоге мы получили следующие результаты:
  • У нас получилось снизить время загрузки страницы почти на 1 секунду (это около 30%)
  • Нагрузка на инфраструктуру нашей CMS упала более чем на 80%, несомненно положительно повлияв на стабильность всего окружения CMS.
  • Сейчас у нас есть полное, обновляемое в реальном времени, представление о трафике: RPS, время ответа, число соединений, закешированные ответы и тд.
  • Сейчас мы можем генерировать отчеты, графики (Zabbix) и предупреждения по любым параметрам трафика и все это в реальном времени!
  • Наш CDN трафик снизился на 80% - и вместе с этим на 80% снизились затраты на CDN.
  • Сейчас мы лучше используем мощности наших дата-центров.
  • Сейчас мы можем моментально воздействовать на наши правила кэширования и распределения нагрузки.
  • Мы отлавливаем и перенаправляем мобильных клиентов прямо на aiCache, избавляя сервер CMS от нежелательных хитов.
Мы до сих пор просто на всякий случай имеем сконфигурированный CDN для большей безопасности. В итоге: Dynamic от DNS и решение для балансировки нагрузки основанное на гео-информации DNS и aiCahce доказали, что для одного из главных финансовых новостных сайтов кэширующее программное обеспечение может снизить на 30% время ответа, сэкономить деньги, получить мониторинг в реальном времени, позволить настраивать генерацию отчетов и предупреждений.

Автор статьи: Rashid Karimov Дата: 6 февраля 2010


комментарии [0]  | комментировать

  © 2010-2018 HIGHLOAD