Привет всем!

Вы, наверное, уже слышали о Карте Интернета. Если нет, то посмотреть на нее можно здесь, а почитать о ней можно в моем предыдущем посте.

В этой статье я бы хотел рассказать, как устроен сайт Карты Интернета, какие технологии обеспечивают его нормальное функционирование и какие шаги пришлось предпринять, чтобы выдержать большой поток посетителей желающих взглянуть на карту.

Работоспособность Карты Интернета поддерживается современными технологиями от интернет-гигантов: отображение карты обеспечивает движок Google Maps от компании Google, обработка веб-запросов осуществляется технологиями .net компании Майкрософт, а хостинг и доставку контента осуществляет платформа Amazon Web Services от компании Амазон. Все три компонента жизненно необходимы для нормальной работы карты.

Далее большая простыня про внутреннюю архитектуру карты: в основном дифирамбы AWS, также будут затронуты вопросы производительности и цены хостинга. Если не боитесь — добро пожаловать под кат.

Amazon CloundFront и Google Maps

Технология Google Maps подразумевает использование тайлов – маленьких картинок 256х256 пикселей, из которых формируется изображение карты. Основной момент, связанный с этими картинками это то, что их реально много. Когда вы видите карту на своем экране с большим разрешением, вся она состоит из этих мелких картинок. Это означает, что сервер должен уметь очень быстро обрабатывать множество запросов и отдавать тайлы одновременно, чтобы клиент не замечал мозаики. Общее количество тайлов необходимое для отображения карты равно sum(4^i), где i пробегает значения от 0 до N, где N это общее количество зумов. В случае Карты Интернета количество зумов равно 14, т.е. общее количество тайлов должно быть приблизительно 358 миллионов. К счастью, эту астрономическую цифру удалось уменьшить до 30 миллионов, отказавшись от генерации пустых тайлов. Если вы откроете консоль браузера, то увидите множество ошибок 403, это как раз они и есть – пропущенные тайлы, но карте этого не видно т.к. если тайла нет, то квадрат заливается черным фоном. Так или иначе, 30 миллионов тайлов это тоже весомая цифра.

Поэтому стандартная схема размещения контента на выделенном сервере, в данном случае, не подходит. Тайлов много, пользователей много, серверов тоже должно быть много и они должны находиться рядом с пользователями, чтобы они не замечали задержки. Иначе пользователи из России будут получать хороший отклик, а пользователи из Японии будут вспоминать время dial-up модемов глядя на вашу карту. К счастью, у Амазона есть решение на этот случай (есть еще у компании Акамай, но речь не о ней). Оно называется CloudFront и представляет из себя глобальную сеть доставки контента (CDN – content delivery network). Вы размещаете свой контент где-нибудь (это называется Origin) и создаете раздачу (Distribution) в CloudFront. Когда пользователь запрашивает ваш контент, CloudFront автоматически находит ближайший к пользователю узел своей сети и, если там еще нет копии ваших данных, то они будут запрошены либо с другого узла, либо с Origin.

Получается, что ваши данные многократно реплицируются и с высокой вероятностью будут доставлены с серверов CloudFront, а не вашего дорого, слабого и ненадежного хранилища. В случае Карты Интернета, подключение CloudFront фактически означало, что данные с моего жесткого диска были физически скопированы в Сингапурский сегмент Simple Storage Service (S3), а потом через консоль AWS была создана раздача (Distribution) в CloudFront, где S3 был указан как источник данных (Origin). Если заглянуть в код страницы Карты Интернета, то можно увидеть что тайлы берутся с адреса CloudFront d2h9tsxwphc7ip.cloudfront.net. Определение ближайшего узла, поддержание контента в актуальном состоянии и все такие вещи CloudFront делает автоматически. Ура!



На картинке можно увидеть, как исходная карта разбивается на тайлы, тайлы уходят на хранение в S3, а оттуда загружаются в CloudFront и уже из его узлов доставляются пользователям.

Amazon RDS

Чтобы обеспечить поиск сайта на карте, нужна база данных, где будет храниться информация о сайтах и их координатах. В данном случае мы имеем MS SQL Express в облаке Амазона. Это называется Сервис Реляционных Баз данных (Relational Database Service – RDS). Нам реляционность особо не нужна т.к. у нас всего одна таблица, но лучше все-таки иметь полноценную базу данных, чем изобретать велосипеды. RDS позволяет использовать не только MS SQL, но также Oracle, MySql и, наверное, что-нибудь еще.

На картинке можно увидеть, как исходная карта превращается в таблицу в базе данных RDS.

Amazon Elastic Beanstalk

Наверное, эта фича в семействе облачных сервисов Амазона поразила меня больше всего. Elastic Beanstalk позволяет буквально одним кликом релизить проект под нагрузкой с минимальным временем или вообще без ухода сайта в offline. Зная как тяжело даются релизы, особенно когда инфраструктура содержит в себе несколько серверов и распределитель нагрузки, я был просто поражен как легко и изящно с этим справляется Elastic Beanstalk! При первом деплое, он создает всю инфраструктуру необходимую для вашего приложения (environment): распределитель нагрузки (Elastic Load Balancer — ELB), вычислительные юниты (Elastic Compute Cloud — EC2) и определяет параметры масштабирования. Грубо если у вас есть один сервер и все запросы идут напрямую к нему, то при достижении некоторого порога ваш сервер перестанет справляться с нагрузкой и, скорее всего, упадет. Иногда он не сможет даже подняться при той нагрузке, на которой раньше прекрасно работал, т.к. чтобы выйти в рабочий режим, обычно, нужно некоторое время, а постоянные запросы не дают этого сделать. В общем, кто воевал тот знает.

Elastic Beanstalk берет все инфраструктурные вопросы на себя. Фактически, можно поставить плагин в MS Visual Studio и забыть о деталях. Он будет сам поддерживать контроль версий, деплоить и т.д. А в случае повышения нагрузки создаст столько EC2 инстансов, сколько необходимо.
На диаграмме Elastic Beanstalk обведен точечной линией, внутри можно увидеть ELB, который принимает входящие запросы и раздает их IIS-ам в EC2 инстансах.

Производительность и цена

Сразу после публикации статьи на сайте Хабрахабр.ру на Карту Интернета пошел поток посетителей. На графике можно увидеть очень резкий рост посещаемости, за первые 6 часов сайт посетило 30 000 человек, а в первый день почти 50 000, в основном из России и стран бывшего СССР. Чувствуя неладное, Elastic Beanstalk создал 10 инстансов EC2 и они хорошо справлялись с задачей. Жалоб на проблемы с доступом к сайту не поступало. Карту можно было смотреть свободно. А вот RDS сразу сдох: сначала поиск стал работать очень медленно, потом с перебоями, а потом совсем перестал. Счет за первый день составил около 200 долларов. Приблизительно 100 за S3+CloudFront и по 50 за EC2 и RDS.

Изучив полученный опыт, я провел оптимизацию и перенастройку параметров автомасштабирования. И это помогло. В течение недели, сайт посещали в среднем 30-50 тысяч человек в день из разных стран мира и ничего не отваливалось. Правда, такого резкого притока, как в первый день тоже не было.

Потом кто-то запостил информацию о Карте на reddit.com и это вызвало взрывной рост посещаемости. За воскресенье сайт посетило около полумиллиона человек и при этом работал всего один small instance EC2 и один small RDS instance. Правда была одна жалоба что карта не загружается, но, я думаю, что это для такой волны это нормально.



А вот и счет за первую неделю

Заключение

Я начал заниматься информационными технологиями, когда слово облачный не имело ничего общего с IT. С тех пор многое изменилось и standalone сервера доживают свой век. Конечно, хостинг в облаке имеет свои минусы (можно спросить у Instagram, например). Но возможность переложить большинство забот на облачный сервис, на мой взгляд, с лихвой окупает все риски. Если вы начинаете разрабатывать свой проект и для вас важны качество, доступность, надежность и масштабируемость то, скорее всего, вам дорога в облако.