Хабрахабр

[Перевод] Переход на облачную платформу Google Cloud (Google Cloud Platform – GCP)

[Часть 1 из 2]

К 2016 году мы достигли цифр в 100 миллионов зарегистрированных пользователей и 40 миллиардов сообщений ежемесячно. Блог Hike появился 12 декабря 2012 года, и читателей тогда было совсем немного. Для ее устранения нам нужна была высокопроизводительная платформа по приемлемой цене. Но такой рост обозначил проблему, связанную с масштабированием нашей инфраструктуры. В 2016 и 2017 годах мы столкнулись с многочисленными перебоями в работе, с этим нужно было срочно что-то делать, поэтому мы начали рассматривать различные варианты.

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

Мы разделим эту публикацию на 2 части:

  1. Причина для выбора GCP
  2. Переход на GCP без простоев

Подтверждение концепции

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

Ключевые области в рамках подтверждения концепции:

⊹ Балансировщик нагрузки
⊹ Вычислительная машина
⊹ Работа в сети и брандмауэры
⊹ Безопасность
⊹ Доступность облачных ресурсов
⊹ Большие данные
⊹ Тарификация

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

Мы хотели выбрать облачную платформу, способную справиться с бесчисленными проблемами, с которыми мы столкнулись:

⊹ Балансировщик нагрузки:

Глобальный балансировщик нагрузки (GLB) решил множество наших проблем. У нас было множество проблем, связанных с управлением локальными кластерами HAProxy для обработки нескольких десятков миллионов подключений активных пользователей ежедневно.

Наше общее время отклика улучшилось в 1,7–2 раза, поскольку GLB использует реализацию пула, которая позволяет распределять трафик по множеству источников. Используя глобальную балансировку нагрузки GCP, один IP-адрес anycast может пересылать до 1 миллиона запросов в секунду на различные сервера GCP, такие как Группы управляемых экземпляров (Managed Instance Groups – MIG), и для этого не требуется «предварительного прогрева».

⊹ Вычислительная машина:

Общая пропускная способность виртуальных машин Google увеличилась в 1,3-1,5 раза, что позволило сократить общее количество запущенных экземпляров виртуальных машин. В самих по себе вычислительных машинах не было больших проблем, но нам нужна была высокопроизводительная платформа по приемлемой цене.

На основе приведенных ниже результатов мы пришли к выводу, что GCP обеспечивает повышение производительности до 48% (в среднем) для большинства операций REDIS и до 77% для конкретных операций REDIS. Тесты Redis проводились с кластером из 6 экземпляров (8 ядер, 30 ГБ каждый).

redis-benchmark -h -p 6379 -d 2048 -r 15 -q -n 10000000 -c 100

Сервис облачных вычислений Google Compute Engine (GCE) обеспечил дополнительные преимущества в управлении нашей инфраструктурой благодаря использованию следующего:

MIG автоматически идентифицирует и корректирует неработоспособные экземпляры в группе для обеспечения оптимальной работы всех экземпляров. ● Группа управляемых экземпляров (MIG): MIG помогают нам поддерживать работу служб приложений в надежной среде с многозональными функциями вместо выделения ресурсов для каждой зоны.

Работая с нашим предыдущим облачным партнером, мы получали уведомление о запланированном событии технического обслуживания и были вынуждены останавливать и запускать виртуальную машину, чтобы перейти на работоспособную виртуальную машину. ● Динамическая миграция: Динамическая миграция помогает поддерживать работу экземпляров виртуальных машин даже в случае сбоя хост-системы, например, при обновлении программного обеспечения или оборудования.

Пользовательские виртуальные машины: В рамках GCP мы можем создавать собственные виртуальные машины с необходимыми для конкретных рабочих нагрузок вычислительной мощностью процессора и объемом памяти.

⊹ Работа в сети и брандмауэры:

Сетевой VPC GCP по умолчанию является глобальным и обеспечивает межрегиональную связь без дополнительной настройки и без изменений пропускной способности сети. Управлять несколькими сетями и правилами брандмауэра непросто и может привести к риску. Правила брандмауэра обеспечивают гибкость в рамках VPC для проектов, использующих имя правила тегов.

Для сети с низкой задержкой и более высокой пропускной способностью мы были вынуждены выбирать дорогостоящие экземпляры с пропускной способность в 10Гбит/с и активировали расширенные сети на этих экземплярах.

⊹ Безопасность:

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

Для защиты данных GCP использует несколько уровней шифрования. Облачные сервисы Google по умолчанию зашифрованы. Использование нескольких уровней шифрования обеспечивает защиту резервируемых данных и позволяет выбрать оптимальный подход, основанный на требованиях приложений, например, использование сервиса Identity-Aware Proxy и шифрование неактивных данных по умолчанию.

Google разработал новый метод бинарной модификации, называемый Retpoline, который позволяет обойти эту проблему и прозрачно внести изменения во всю работающую инфраструктуру незаметно для пользователей. Кроме того, GCP закрывает недавние катастрофические уязвимости, основанные на спекулятивном выполнении, в подавляющем большинстве современных процессоров (Meltdown, Spectre).

⊹ Доступность облачных ресурсов:

Нам приходилось управлять несколькими VPC для отдельных проектов из отдельных учетных записей, которым требовались пиринг VPC или VPN-соединение для частного подключения. Доступность ресурсов GCP отличается от таковой у других поставщиков облачных решений, так как большинство ресурсов GCP, включая панель управления, являются либо зональными, либо региональными. Нам также приходилось держать копию образа в отдельной учетной записи.

К таким ресурсам относятся панель управления (где мы можем видеть все виртуальные машины нашего проекта на одном экране), образы дисков, контейнеры для хранения данных (несколько регионов в рамках континента), VPC (но отдельные подсети являются региональными), глобальная балансировка нагрузки, публикация и подписка и т. В облаке Google Cloud большинство ресурсов являются либо глобальными, либо региональными. д.

⊹ Большие данные:

Мы перешли от монолитной, трудноуправляемой аналитической конфигурации к полностью управляемой системе с BQ, что привело к улучшениям в трех областях:

● Увеличение скорости обработки запросов до 50 раз.

● Полностью управляемые системы обработки данных с автоматическим масштабированием.

● Время обработки данных сократилось с часов до 15 минут.

⊹ Тарификация:

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

Преимущества GCP:

Мы можем автоматически получить скидку до 30% на рабочие нагрузки, которые выполняются в течение большей части учетного месяца. ● Скидки за длительное использование: Применяются при нарастающем использовании виртуальных машин при достижении определенных пороговых значений.

Это обеспечивает значительное снижение затрат, поскольку нам не приходится оплачивать полный час, даже если экземпляр машины работает менее часа. ● Поминутная тарификация: При выделении виртуальной машины в GCE взимается плата за минимальный период 10 минут, после чего начинается поминутная тарификация за фактическое использование виртуальной машины.

Превосходное оборудование, меньшее количество экземпляров: Мы обнаружили, что почти для всех уровней и приложений с помощью GCP можно выполнять ту же рабочую нагрузку с одинаковой производительностью, но меньшим количеством экземпляров.

В AWS основным способом сокращения затрат на экземпляр виртуальной машины является покупка зарезервированных экземпляров сроком на 1–3 года. ● Обязательство, а не резервирование: Еще одним фактором является подход GCP к цене экземпляров виртуальных машин. В GCP есть «Скидка за обязательство по использованию», которая действует при резервировании ресурсов процессора и памяти, при этом не имеет значения, какие экземпляры виртуальной машины мы используем. Если рабочая нагрузка требовала изменения конфигурации виртуальной машины или данный экземпляр был нам не нужен, нам приходилось продавать его на рынке зарезервированных экземпляров по более низкой цене.

Заключение:

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть