Googlе представил новую облачную платформу
Компания Google объявила об окончании тестирования платформы Google Cloud, которая отныне становится общедоступной. Были озвучены возможности платформы и обязательства компании перед клиентами, которые планируют ее использовать.
В рамках соглашения, которое обязаны подписывать Google и ее клиент, компания гарантирует бесперебойную работу платформы с коэффициентом доступности 99,95%. В случае несоблюдения этого значения, она обязуется возмещать часть оплаты за последующие периоды использования платформы. Например, если фактический коэффициент доступности составит менее 95%, клиенту будет возмещено 50% оплаты за текущий период.
В Google сообщили, что стоимость обычных виртуальных машин снижена на 10% в сравнении со стоимостью в период тестирования, однако конкретные цены не назвали. Для этого необходимо подать заявку.
Кроме того, клиентам было предложено три новых типа виртуальных машин. Наиболее мощная конфигурация включает 16 ядер и 104 ГБ оперативной памяти. В Google считают, что такие конфигурации будут полезны тем, кому необходима дополнительная вычислительная мощность.
Google присоединился к Amazon и Microsoft с собственной облачной платформой
Google Cloud считается альтернативой Amazon Web Services, однако, по мнению TechCrunch, платформа Google пока не может тягаться с лидером рынка по разнообразию типов ВМ. Например, она не предлагает виртуальные машины с видеоускорителями, которые бы позволяли быстрее производить графические вычисления.
Лидером и пионером рынка IaaS-решений является Amazon. В компании утверждают, что ее облаком пользуются «сотни тысяч» клиентов, в числе которых, например, видеосервис Netflix. В 2008 г. он прекратил развивать собственные дата-центры и с 2010 г. полностью базируется на облаке Amazon.
Переход на облачную платформу Google Cloud (Google Cloud Platform – GCP)
[Часть 1 из 2]
Блог Hike появился 12 декабря 2012 года, и читателей тогда было совсем немного. К 2016 году мы достигли цифр в 100 миллионов зарегистрированных пользователей и 40 миллиардов сообщений ежемесячно. Но такой рост обозначил проблему, связанную с масштабированием нашей инфраструктуры. Для ее устранения нам нужна была высокопроизводительная платформа по приемлемой цене. В 2016 и 2017 годах мы столкнулись с многочисленными перебоями в работе, с этим нужно было срочно что-то делать, поэтому мы начали рассматривать различные варианты.
Нам нужна была такая облачная платформа, которая помогла бы быстро создавать, тестировать и развертывать приложения в масштабируемой и надежной облачной среде. На первый взгляд может показаться, что все крупные облачные платформы схожи во многих отношениях, однако у них есть несколько принципиальных различий.
Мы разделим эту публикацию на 2 части:
Подтверждение концепции
Мы начали с доказательства правильности концепции, в рамках которого рассматривали совместимость существующей инфраструктуры с сервисами, предлагаемыми облачной платформой Google Cloud, а также планировали элементы для будущего развития.
Ключевые области в рамках подтверждения концепции:
⊹ Балансировщик нагрузки
⊹ Вычислительная машина
⊹ Работа в сети и брандмауэры
⊹ Безопасность
⊹ Доступность облачных ресурсов
⊹ Большие данные
⊹ Тарификация
Подтверждение концепции включало в себя тестирование и проверку пропускной способности виртуальных машин/сети/балансировщика нагрузки, а также стабильности, масштабируемости, безопасности, мониторинга, тарификации, больших данных и сервисов машинного обучения. В июне 2017 года мы приняли важное решение о переносе всей инфраструктуры на облачную платформу Google Cloud.
Мы хотели выбрать облачную платформу, способную справиться с бесчисленными проблемами, с которыми мы столкнулись:
⊹ Балансировщик нагрузки:
У нас было множество проблем, связанных с управлением локальными кластерами HAProxy для обработки нескольких десятков миллионов подключений активных пользователей ежедневно. Глобальный балансировщик нагрузки (GLB) решил множество наших проблем.
Используя глобальную балансировку нагрузки GCP, один IP-адрес anycast может пересылать до 1 миллиона запросов в секунду на различные сервера GCP, такие как Группы управляемых экземпляров (Managed Instance Groups – MIG), и для этого не требуется «предварительного прогрева». Наше общее время отклика улучшилось в 1,7–2 раза, поскольку GLB использует реализацию пула, которая позволяет распределять трафик по множеству источников.
⊹ Вычислительная машина:
В самих по себе вычислительных машинах не было больших проблем, но нам нужна была высокопроизводительная платформа по приемлемой цене. Общая пропускная способность виртуальных машин Google увеличилась в 1,3-1,5 раза, что позволило сократить общее количество запущенных экземпляров виртуальных машин.
Тесты Redis проводились с кластером из 6 экземпляров (8 ядер, 30 ГБ каждый). На основе приведенных ниже результатов мы пришли к выводу, что GCP обеспечивает повышение производительности до 48% (в среднем) для большинства операций REDIS и до 77% для конкретных операций REDIS.
Сервис облачных вычислений Google Compute Engine (GCE) обеспечил дополнительные преимущества в управлении нашей инфраструктурой благодаря использованию следующего:
● Группа управляемых экземпляров (MIG): MIG помогают нам поддерживать работу служб приложений в надежной среде с многозональными функциями вместо выделения ресурсов для каждой зоны. MIG автоматически идентифицирует и корректирует неработоспособные экземпляры в группе для обеспечения оптимальной работы всех экземпляров.
● Динамическая миграция: Динамическая миграция помогает поддерживать работу экземпляров виртуальных машин даже в случае сбоя хост-системы, например, при обновлении программного обеспечения или оборудования. Работая с нашим предыдущим облачным партнером, мы получали уведомление о запланированном событии технического обслуживания и были вынуждены останавливать и запускать виртуальную машину, чтобы перейти на работоспособную виртуальную машину.
● Пользовательские виртуальные машины: В рамках GCP мы можем создавать собственные виртуальные машины с необходимыми для конкретных рабочих нагрузок вычислительной мощностью процессора и объемом памяти.
⊹ Работа в сети и брандмауэры:
Управлять несколькими сетями и правилами брандмауэра непросто и может привести к риску. Сетевой VPC GCP по умолчанию является глобальным и обеспечивает межрегиональную связь без дополнительной настройки и без изменений пропускной способности сети. Правила брандмауэра обеспечивают гибкость в рамках VPC для проектов, использующих имя правила тегов.
Для сети с низкой задержкой и более высокой пропускной способностью мы были вынуждены выбирать дорогостоящие экземпляры с пропускной способность в 10Гбит/с и активировали расширенные сети на этих экземплярах.
⊹ Безопасность:
Безопасность — самый важный аспект для любого поставщика облачных сервисов. В прошлом безопасность была либо недоступна для большинства сервисов, либо была лишь дополнительным вариантом.
Облачные сервисы Google по умолчанию зашифрованы. Для защиты данных GCP использует несколько уровней шифрования. Использование нескольких уровней шифрования обеспечивает защиту резервируемых данных и позволяет выбрать оптимальный подход, основанный на требованиях приложений, например, использование сервиса Identity-Aware Proxy и шифрование неактивных данных по умолчанию.
Кроме того, GCP закрывает недавние катастрофические уязвимости, основанные на спекулятивном выполнении, в подавляющем большинстве современных процессоров (Meltdown, Spectre). Google разработал новый метод бинарной модификации, называемый Retpoline, который позволяет обойти эту проблему и прозрачно внести изменения во всю работающую инфраструктуру незаметно для пользователей.
⊹ Доступность облачных ресурсов:
Доступность ресурсов GCP отличается от таковой у других поставщиков облачных решений, так как большинство ресурсов GCP, включая панель управления, являются либо зональными, либо региональными. Нам приходилось управлять несколькими VPC для отдельных проектов из отдельных учетных записей, которым требовались пиринг VPC или VPN-соединение для частного подключения. Нам также приходилось держать копию образа в отдельной учетной записи.
В облаке Google Cloud большинство ресурсов являются либо глобальными, либо региональными. К таким ресурсам относятся панель управления (где мы можем видеть все виртуальные машины нашего проекта на одном экране), образы дисков, контейнеры для хранения данных (несколько регионов в рамках континента), VPC (но отдельные подсети являются региональными), глобальная балансировка нагрузки, публикация и подписка и т. д.
⊹ Большие данные:
Мы перешли от монолитной, трудноуправляемой аналитической конфигурации к полностью управляемой системе с BQ, что привело к улучшениям в трех областях:
● Увеличение скорости обработки запросов до 50 раз.
● Полностью управляемые системы обработки данных с автоматическим масштабированием.
● Время обработки данных сократилось с часов до 15 минут.
⊹ Тарификация:
Было трудно сравнивать различных поставщиков облачных сервисов, поскольку многие сервисы не были похожи или сопоставимы, различались для разных сценариев использования и зависели от уникальных сценариев использования.
Преимущества GCP:
● Скидки за длительное использование: Применяются при нарастающем использовании виртуальных машин при достижении определенных пороговых значений. Мы можем автоматически получить скидку до 30% на рабочие нагрузки, которые выполняются в течение большей части учетного месяца.
● Поминутная тарификация: При выделении виртуальной машины в GCE взимается плата за минимальный период 10 минут, после чего начинается поминутная тарификация за фактическое использование виртуальной машины. Это обеспечивает значительное снижение затрат, поскольку нам не приходится оплачивать полный час, даже если экземпляр машины работает менее часа.
● Превосходное оборудование, меньшее количество экземпляров: Мы обнаружили, что почти для всех уровней и приложений с помощью GCP можно выполнять ту же рабочую нагрузку с одинаковой производительностью, но меньшим количеством экземпляров.
● Обязательство, а не резервирование: Еще одним фактором является подход GCP к цене экземпляров виртуальных машин. В AWS основным способом сокращения затрат на экземпляр виртуальной машины является покупка зарезервированных экземпляров сроком на 1–3 года. Если рабочая нагрузка требовала изменения конфигурации виртуальной машины или данный экземпляр был нам не нужен, нам приходилось продавать его на рынке зарезервированных экземпляров по более низкой цене. В GCP есть «Скидка за обязательство по использованию», которая действует при резервировании ресурсов процессора и памяти, при этом не имеет значения, какие экземпляры виртуальной машины мы используем.
Заключение:
Исходя из этого подробного анализа, мы решили перейти на GCP и начали работать над схемой перехода и контрольными списками. В следующей статье мы расскажем о том, что узнали в ходе выполнения этого проекта.
GCP: Разбор вычислительного стека Google Cloud Platform
Перевод статьи подготовлен специально для студентов курса «Облачные сервисы».
Интересно развиваться в данном направлении? Смотрите запись профессионального мастер-класса «AWS EC2 сервис», который провёл Егор Зуев — TeamLead в компании InBit и автор образовательной программы в OTUS.
Google Cloud Platform (GCP) предлагает множество сервисов, и в частности вычислительный стек, который содержит Google Compute Engine (GCE), Google Kubernetes Engine (ранее — Container Engine) (GKE), Google App Engine (GAE) и Google Cloud Functions (GCF). Все эти сервисы имеют крутые названия, но могут быть не совсем очевидными в отношении их функций и того, что делает их уникальными по отношению друг к другу. Эта статья предназначена для тех, кто только знакомится с облачными концепциями, в частности с облачными сервисами и GCP.
1. Вычислительный стек
Вычислительный стек можно рассматривать как многоуровневую абстракцию над тем, что может предоставить компьютерная система. Этот стек восходит (moves up) от «голого железа» (bare metal), относящегося к фактическим аппаратным компонентам компьютера, вплоть до функций (functions), которые представляют собой наименьшую единицу вычисления. Что важно отметить в отношении стека, так это то, что сервисы агрегируются при перемещении вверх по стеку, например, раздел «приложения» (apps), показанный на рисунке 1 ниже, должен содержать все базовые компоненты контейнеров (containers), виртуальных машин (virtual machines) и железа. Таким же образом компонент виртуальных машин должен содержать железо внутри для работы.
Рисунок 1: Вычислительный стек | Изображение получено из Google Cloud
Эта модель, показанная на рисунке 1, является основой для описания предложений от облачных провайдеров. Таким образом, некоторые провайдеры могут предоставлять только, например, контейнеры и услуги ниже качеством по стеку, а другие — все, что показано на рисунке 1.
— Если вы знакомы с облачными сервисами, переходите к разделу 3, чтобы ознакомиться с эквивалентом GCP
— Если вам нужна только сводка по облачным сервисам, переходите к разделу 2.4
2. Облачные сервисы
Мир облачных вычислений очень разнообразен. Облачные провайдеры предлагают множество услуг, адаптированных к различным требованиям клиентов. Возможно, вы слышали о таких терминах, как IaaS, PaaS, SaaS, FaaS, KaaS и т.д. со всеми буквами алфавита, за которыми следует «aaS». Несмотря на странное соглашение об именовании, они образуют набор сервисов облачных провайдеров. Я констатирую, что есть 3 основных предложения «как услуга» (as a Service), которые облачные провайдеры почти всегда предоставляют.
Это IaaS, PaaS и SaaS, которые обозначают соответственно инфраструктуру как услугу (Infrastructure as a Service), платформу как услугу (Platform as a Service) и программное обеспечение как услугу (Software as a Service). Важно визуализировать облачные сервисы как уровни предоставляемых услуг. Это означает, что когда вы поднимаетесь или спускаетесь с уровня на уровень, вы, как клиент, пересекаете различные варианты обслуживания, которые либо добавляются, либо убираются из основного предложения. Лучше всего рассматривать это как пирамиду, как показано на рисунке 2.
Рисунок 2: Пирамида «aaS» | Изображение получено из Ruby Garage
2.1 Инфраструктура как услуга (IaaS)
Это самый низкий уровень, который может предложить поставщик облачных услуг, и он включает провайдера облачных вычислений, поставляющего «голую» инфраструктуру, включая промежуточное программное обеспечение, сетевые кабели, процессоры, графические процессоры, оперативную память, внешнее хранилище, серверы и образы базовых операционных систем, например, Debian Linux, CentOS, Windows и т. д.
Если закажите у поставщика облачных услуг IaaS предложение, то это то, что вы должны ожидать получить. За вами, как за клиентом, остается сборка этих частей для ведения вашего бизнеса. Степень того, с чем вам придется работать, может варьироваться от поставщика к поставщику, но, как правило, вы просто получаете аппаратное обеспечение и ОС, а остальное за вами. Примерами IaaS являются AWS Elastic Compute, Microsoft Azure и GCE.
Некоторым людям может не понравиться тот факт, что им приходится устанавливать образы ОС и заниматься сетью, балансировкой нагрузки или заботиться о том, какой тип процессора идеально подходит для их рабочей нагрузки. Именно здесь мы двигаемся вверх по пирамиде к PaaS.
2.2 Платформа как услуга (PaaS)
PaaS включает в себя только поставщика облачных услуг, предлагающего определенную платформу, на которой пользователи могут создавать приложения. Это абстракция над IaaS, означающая, что поставщик облака берет на себя все детали типов ЦП, памяти, ОЗУ, хранилища, сетей и т. д. Как показано на рисунке 2, вы, как клиент, имеете небольшой контроль над реальной платформой, поскольку облачный провайдер занимается всеми деталями инфраструктуры за вас. Вы запрашиваете выбранную платформу и собираете на ней проект. Примерам PaaS являютс Heroku.
Для кого-то это может быть слишком высокий уровень, так как он не обязательно хочет собирать проект на указанной платформе, а скорее нуждается в наборе сервисов непосредственно от поставщика облачных услуг. Здесь на сцену выходит SaaS.
2.3 Программное обеспечение как услуга (SaaS)
SaaS представляет собой наиболее распространенные сервисы, предоставляемые поставщиками облачных услуг. Они предназначены для конечных пользователей и доступны главным образом через веб-сайты, например Gmail, Google Docs, Dropbox и т. д. Что касается Google Cloud, есть несколько предложений вне их вычислительного стека, которые являются SaaS. К ним относятся Data Studio, Big Query и т. д.
2.4 Сводка по облачным сервисам
| Составляющие | IaaS | PaaS | SaaS |
|---|---|---|---|
| Что вы получаете | Вы получаете инфраструктуру и платите соответственно. Свободу использовать или устанавливать любое ПО, ОС или их композицию. | Здесь вы получаете то, что вы запрашиваете. ПО, железо, ОС, веб-среду. Вы получаете готовую к использованию платформу и платите соответственно. | Здесь вам не нужно ни о чем беспокоиться. Вам предоставляется предустановленный настроенный в соответствии с вашими требования пакет, и вам остается только заплатить соответственно. |
| Значение | Базовый уровень вычислений | Верхушка IaaS | Это по сути полный пакет услуг |
| Технические сложности | Необходимы технические знания | Вам дана базовая конфигурация, но все еще необходимы знания предметной области. | Не нужно заморачиваться с техническими деталями. Поставщик SaaS предоставляет все. |
| С чем работает | Виртуальные машины, хранилища, серверы, сеть, балансировщики нагрузки и т.д. | Среды выполнения (как java runtime), базы данных (как mySQL, Oracle), веб серверы (как tomcat и т. д.) | Приложения наподобие почтовых сервисов (Gmail, Yahoo mail и т. д.), сайтов социального взаимодействия (Facebook и т. д.) |
| Граф популярности | Популярно среди высококвалифицированных разработчиков, исследователей, которым требуется индивидуальная настройка в соответствии с их требованиями или областью исследований | Наиболее популярно среди разработчиков, поскольку они могут сосредоточиться на разработке своих приложений или скриптов. Им не нужно беспокоиться о загрузке трафика или управлении сервером и т. д. | Наиболее популярно среди обычных потребителей или компаний, которые используют программное обеспечение, такое как электронная почта, файлообменники, социальные сети, так как им не нужно беспокоиться о технических деталях |
Рисунок 3: Сводка основных облачных предложений | Изображение предоставлено Amir at Blog Specia
3. Вычислительный пакет Google Cloud Platform
Рассмотрев типичные предложения облачных провайдеров в разделе 2, мы можем сопоставить их с предложениями Google Cloud.
3.1 Google Compute Engine (GCE) — IaaS
Рисунок 4: Иконка Google Compute Engine (GCE)
GCE — это IaaS предложение от Google. С GCE вы можете свободно создавать виртуальные машины, распределять ресурсы процессора и памяти, выбирать тип хранилища, например SSD или HDD, а также объем памяти. Это почти так же, как если бы вы создали свой собственный компьютер/рабочую станцию и занимались всеми деталями его работы.
В GCE вы можете выбрать от микро инстанций с 0,3-ядерным процессорами и 1 ГБ ОЗУ до 96-ядерных монстров с более чем 300 ГБ ОЗУ. Вы также можете создавать виртуальные машины нестандартного размера для своих рабочих нагрузок. Для тех, кто заинтересовался — это виртуальные машины, которые вы можете собрать.
3.2. Google Kubernetes Engine (GKE) — (Caas / Kaas)
Рисунок 5: Иконка Google Kubernetes Engine (GKE)
GKE — это уникальное вычислительное предложение от GCP, которое представляет собой абстракцию над Compute Engine. В более общем смысле GKE можно отнести к категории «Контейнер как услуга» (CaaS), иногда называемой «Kubernetes как услуга» (KaaS), который позволяет клиентам легко запускать свои Docker-контейнеры в полностью управляемой среде Kubernetes. Для тех, кто не знаком с контейнерами, контейнеры помогают модульно формировать сервисы/приложения, поэтому разные контейнеры могут содержать разные сервисы, например, один контейнер может размещать интерфейс вашего веб-приложения, а другой может содержать его серверную часть. Kubernetes выполняет автоматизацию, координацию, управление и развертывание ваших контейнеров. Больше информации здесь.
3.3 Google App Engine (GAE) — (PaaS)
Рисунок 6: Иконка Google App Engine (GAE)
Как упомянуто в разделе 2.2, PaaS находится выше IaaS, и в случае GCP его также можно рассматривать как предложение над GKE. GAE — это специализированный Google PaaS, и как они сами лучше всего описывают себя — «несите ваш код, а мы позаботимся обо всем остальном».
Это гарантирует, что клиенты, использующие GAE, не должны иметь дело с базовым аппаратным/промежуточным программным обеспечением, и уже могут иметь предварительно настроенную платформу, готовую к работе; все, что им нужно сделать, это предоставить код, необходимый для его запуска.
GAE автоматически обрабатывает масштабирование, чтобы удовлетворить нагрузку и спрос со стороны пользователей, что означает, что если ваш сайт, продающий цветы, внезапно достигнет пика, потому что приближается день святого Валентина, GAE будет обрабатывать масштабирование базовой инфраструктуры, чтобы удовлетворить спрос и гарантировать, что ваш веб-сайт не упадет из-за возросшего спроса. Это означает, что вы платите именно за те ресурсы, которые требуются вашему приложению в данный момент.
GAE использует Kubernetes или его встроенную версию, чтобы справиться со всем этим, чтобы вам не пришлось об этом заботиться. GAE лучше всего подходит для компаний, которые не заинтересованы в базовой инфраструктуре и заботятся только о том, чтобы их приложение было доступно наилучшим образом.
По моему мнению, GAE — это лучшее место для старта, если вы разработчик с отличной идеей, но не хотите заниматься рутинной работой по настройке серверов, балансировкой нагрузки и всей другой трудоемкой devops/SRE работой. Со временем вы могли бы попробовать GKE и GCE, но это только мое мнение.
Дисклеймер: AppEngine используется для веб-приложений, а не мобильных приложений.
3.4 Google Cloud Functions — (FaaS)
Рисунок 7: Иконка Google Cloud Functions (GCF)
Надеюсь, вы заметили тенденцию, проанализировав предыдущие предложения. Чем выше вы поднимаетесь по лестнице вычислительных решений GCP, тем меньше вам нужно беспокоится о базовых технологиях. Эта пирамида завершается наименьшей возможной единицей вычисления, функцией, как показано в разделе 1.
GCF является относительно новым GCP-предложением, которое все еще находится на стадии бета-тестирования (на момент написания этой статьи). Облачные функции позволяют определенным функциям, написанным разработчиком, запускаться по какому-либо событию.
Они управляются событиями и лежат в основе модного слова «безсерверный», то есть не знают серверов. Облачные функции очень просты и имеют много разных применений, которые требуют событийного мышления. Например, каждый раз, когда новый пользователь регистрируется, может быть запущена облачная функция, чтобы предупредить разработчиков.
На фабрике, когда определенный датчик достигает определенного значения, он может запустить облачную функцию, которая выполняет некоторую обработку информации, или уведомляет некоторый обслуживающий персонал и т. д.
Заключение
В этой статье мы говорили о различных облачных предложениях, например IaaS, PaaS и т. д., и как стек вычислений Google реализует эти различные уровни. Мы видели, что уровни абстракции при переходе из одной категории услуг в другую, например, IaaS в Paas, требуют меньше знаний о лежащей в основе.
Для бизнеса это обеспечивает критически важную гибкость, которая не только отвечает его оперативным целям, но также удовлетворяет другим ключевым областям, таким как безопасность и стоимость. Обобщая:
Compute Engine — позволяет вам создать свою собственную виртуальную машину, выделяя определенные аппаратные ресурсы, например, ОЗУ, процессор, память. Он так же достаточно практичный и низкоуровневый.
Kubernetes Engine — это шаг выше по сравнению с Compute Engine, который позволяет вам использовать Kubernetes и контейнеры для управления вашим приложением, позволяя при необходимости масштабировать его.
App Engine — это шаг выше по сравнению с Kubernetes Engine, позволяющий вам сосредоточиться только на своем коде, в то время как Google обеспечивает все требования базовой платформы.
Cloud-Functions — это вершина вычислительной пирамиды, позволяющая написать простую функцию, которая при запуске использует всю базовую инфраструктуру для вычисления и возврата результата.
