Недавно компания Onebip перевела большую часть своей серверной базы из миланских центров обработки данных в несколько зон доступности на веб-сервисах Amazon. В то время как легко создать новый сервис в облаке, Onebip работал и работал много лет до этой миграции, и нашим системным администраторам приходилось работать в обычных условиях, чтобы не потерять данные и не прерывать работу сервиса. Будучи платежной системой, каждая минута простоя напрямую приводит к потере денег.
Вот пересказ опыта смены физического оборудования на виртуальное, установленное в другой стране, когда оно работает каждый день. Я наблюдал это с точки зрения разработчика, поэтому, пожалуйста, приставайте к аккаунтам в Твиттере, связанным выше, если вы хотите узнать больше. 🙂
Архитектура
Архитектура Onebip состоит из (почти) совместно используемых серверов, на которых работают приложения PHP. Приложения работают с несколькими базами данных (MySQL и MongoDB), которые вместо этого содержат состояние покупок, подписок и остатков клиентов.
Таким образом, первым шагом был запуск нескольких веб-серверов в новом виртуальном частном облаке и запуск его в одних и тех же базах данных. Связь между дата-центрами была гарантирована парой каналов VPN.
Одна только эта задача занимала системных администраторов в течение нескольких недель, поскольку они должны были не только гарантировать безопасный канал между центрами обработки данных, но и гарантировать, что весь трафик выходит с тех же IP-адресов, что и раньше. Мы работаем с несколькими сотнями операторов мобильной связи, которые занесли в белый список адреса нашего дата-центра; Связь с ними напрямую из нового VPC не собиралась работать, и обновление их белых списков все еще в процессе.
Например, один оператор вставляет зашифрованные заголовки в запросы HTTP (явно не HTTPS) для идентификации номера телефона. Тем не менее, он делает это только на нескольких доменах, таких как onebip.com, которые имеют коммерческое соглашение с ним. Более того, у него есть список IP-адресов, для обновления которых требуются месяцы: если серверы за этим доменом меняются, вы больше не получите этот заголовок.
Более того, к сожалению, не было никаких ограничений в общении с базами данных при разработке приложения, когда оно впервые запускалось в едином центре обработки данных (и не было возможности его использования). Болтливые веб-серверы выполняли множество запросов SELECT и INSERT, устанавливая трафик туда и обратно между двумя центрами обработки данных даже для обслуживания отдельных запросов (наша страница оплаты). Когда вы размещаете веб-серверы и базы данных в разных странах, вы можете ожидать этого.
Таким образом, процесс загрузки страницы из AWS прошел следующим образом:
Client -> Milan load balancers --VPN-> AWS in Ireland -*> Milan databases
Знак * обозначает большое количество запросов к базе данных по отношению к другим каналам, где каждый запрос передается только один раз. По сути, для простой страницы PHP, которая не подключалась к базам данных, размещенным в AWS, мы говорили о 200 мс после оптимизации, описанной ниже; для одного, только подключающегося к ним, мы говорили о времени загрузки от 800 до 1200 мс.
2 недели оптимизации
По сути, наша страница оплаты при доступе через веб-серверы AWS была непригодна из-за высокого времени загрузки, которое в худшем случае составляло от менее 5 секунд до более 10 секунд. Эта проблема не только делала страницу непригодной для использования, но и беспокоила нас о том, сколько пропускной способности должно быть занято в VPN-соединениях.
Поэтому мы решили оптимизировать чат между веб-серверами и базой данных с учетом нескольких стратегий:
- кеширование : установка Memcache на каждый локальный веб-сервер и сохранение на нем кэшируемых данных. Существует много примеров данных с TTL часов или дней, таких как секретные ключи продавца, параметры конфигурации службы подписки или API-интерфейсы поиска, такие как ответы TeraWurfl.
- использование вторичных серверов : в MySQL и MongoDB может быть несколько вторичных серверов в качестве асинхронных реплик. Данные с TTL как минимум минут, такие как отчеты, могут легко ориентироваться на реплику, которая хранится в том же центре обработки данных, что и веб-серверы. В то время как с MySQL вы можете явно запросить вторичный сервер на уровне приложения, в MongoDB
- Обновите до PHP 5.4 (между прочим), чтобы ускорить вычисления, даже если это не было узким местом.
- API без сохранения состояния : для некоторых из URL-адресов, наиболее сильно пострадавших от клиентов, таких как наша служба обнаружения телефонных номеров, мы портировали их с хранения промежуточной информации в коллекции MongoDB для передачи зашифрованной строки запроса до следующего перенаправления.
- Явные перенаправления в центр обработки данных в Милане : мы настраиваем виртуальный хост italy.onebip.com для прямых клиентов, чьи IP-адреса принадлежали проблемным операторам. Клиент оставался там только на время чтения зашифрованных заголовков носителя, а затем вернулся на onebip.com, который мог обслуживаться любым веб-сервером и любым IP-адресом.
После этих раундов оптимизации мы бежали в почти приемлемое время. Но высокое время загрузки напрямую влияет на коэффициент конверсии, поэтому использование веб-серверов на Amazon по-прежнему недопустимо …
Продолжение следует
Мы остались с веб-серверами, которые общались с базами данных в другой стране Европы, с высокой степенью оптимизации, но все же намного медленнее, чем оригинальный центр обработки данных; исходящий трафик по-прежнему проходит через Милан, в то время как входящий трафик в большинстве случаев (к счастью) может поступать непосредственно на балансировщики нагрузки AWS. Во второй части мы увидим, как наши системные администраторы подготовили большой шаг к одновременному использованию первичных баз данных и веб-серверов.