Google Cloud Platform глазами .NET разработчика

💡 Усі статті, обговорення, новини про .NET — в одному місці. Приєднуйтесь до .NET спільноти!

Привет! Меня зовут Назарий Таран, я .NET Developer в NIX. На протяжении шести лет я разрабатываю Web-приложения с применением стека .NET. В этой статье я бы хотел поделиться своим опытом использования Google Cloud Platform. Материал будет полезен тем, кто хочет познакомиться с GCP и иметь базовое представление о возможностях этой платформы, но уже работал с каким-либо аналогичным облаком.

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

С чего началось мое знакомство с GCP

Год назад к нам пришел заказчик с такой задачей: написать небольшое приложение с использованием .NET стека на базе GCP, что является не «классическим» вариантом, если вы разрабатываете систему на .NET.

По данным Canalys, доля Google на рынке облачных провайдеров во втором квартале 2021 года составила 8%, хотя в конце 2018-го показатель не превышал 5%. Рост не самый стремительный, но уверенный. И чем дальше, тем наверняка будет выше популярность Google Cloud Platform среди разработчиков любого стека.

Обычно в прошлом мы старались предлагать клиентам Azure — более нативную для этой экосистемы платформу, в которой у нас был бОльший опыт. Но в данном случае заказчик точно знал, чего хочет. Поэтому нам пришлось разобраться в новом для себя поприще. В этой статье я попытаюсь кратко познакомить и вас с Google Cloud Platform, сравнивая его с Azure и передавая эмоции и мысли, возникшие у меня в процессе разработки.

Bird’s-eye view на GCP

Для удобного доступа к ресурсам на GCP лучше всего посетить ее веб-портал. Он выполнен в фирменном стиле Google — material design, где на главной странице располагается настраиваемый dashboard. Слева в меню можно начать работу с интересующим нас ресурсом на GCP.

Первое, на что следует обратить внимание — способ организации ресурсов. В GCP есть понятие «проекта» — это некий контейнер, в котором мы будет размещать логически связанные ресурсы. Проект имеет имя, номер и уникальный ID. Проекты можно объединять в директории, которые в свою очередь принадлежат организации. Таким образом мы можем удобно упорядочить наши ресурсы, а также возможность настроить security policies так, чтобы человек имел доступ только к тем ресурсам, которые ему нужны. Такая структура мне понравилась больше, нежели resource groups в Azure.

Ресурсы в GCP могут быть глобальными, региональными либо зональными. Глобальные — доступны любому ресурсу в любой локации в рамках проекта. Региональные — в пределах одного региона (например, регион europe-west 1), каждый из которых дополнительно состоит из нескольких зон (к примеру, europe-west1-b, europe-west1-c, europe-west1-d). Зональные ресурсы, как можно догадаться из названия, доступны только в рамках одной конкретной зоны. Давайте же рассмотрим, какие ресурсы нам предоставляет GCP.

Виртуальные машины и сети

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

Можно создать виртуальную машину любой конфигурации по железу с выбором vCPU, RAM, наличием GPU и выбором операционной системы. Существует и опция создать машину с собственного образа. К ней можно приатачить диск для хранения данных с возможностью выбора типа диска, различных бекап-опций и прочего. Можно задать startup-script, который будет выполняться при старте виртуалки. На таких виртуалках я могу размещать все что угодно: веб-сервер, сервер базы данных, какие-то рекуррентные job-ы и т.д.

Интересными здесь являются Instance Template и Managed Instance Group. Instance Template — это переиспользуемый шаблон виртуалки, который позволяет сэкономить время на создании новых экземпляров. Там указаны все вышеперечисленные параметры, не нужно заново все вбивать. Managed Instance Group — это набор виртуальных машин, которые можно настроить для Load Balancing-а. Новые инстанци автоматически будут создаваться по выбранному шаблону и так же автоматически будут удаляться.

В некоторых ситуациях полезной будет фича preemptible VM instances. Это такие виртуальные машины, которые Compute Engine может остановить, если потребуется больше ресурсов на другие задачи. Google рекомендует рассмотреть этот вариант, и в случае необходимости сэкономить в деньгах, поскольку такие VM обходятся дешевле на ~60%.

Говоря о виртуалках, нельзя не упомянуть сети, в которых они будут расположены, а конкретно — о Virtual Private Cloud (VPC). По умолчанию при создании проекта Google создает за вас одну дефолтную VPC, в которой будут все ваши ресурсы. Внутри VPC вы можете создавать региональные подсети, рулы файервола, полиси. Можно ограничить доступ. Это полноценная сетка, которую вы настраиваете под ваши потребности.

Managed-сервисы

В проекте, о котором я говорил в начале, мы хотели по максимуму использовать managed-сервисы, которые предоставляет GCP, чтобы избежать издержек с поддержкой инфраструктуры. Рассмотрим, что мы использовали.

App Engine

App Engine представляет собой PaaS-сервис для хостинга веб-приложений, ближайшим аналогом которого в Azure является App Service. Все, о чем вы заботитесь — это код, остальное берет на себя App Engine. Каждое веб-приложение здесь — это отдельный «сервис» со своей кодовой базой и конфигурацией. GCP различает т.н. Standard Environment и Flexible Environment. Standard запускается в некой песочнице, где предопределен набор рантаймов (.NET-а среди них нет 🙃). Там не поддерживаются веб-сокеты, фоновые процессы, ограничены фоновые потоки и есть своя модель биллинга — присутствует free tier. Все, что выше этого tier-а, далее подвергается биллингу за инстансы\часы. Flexible Environment лишен всех вышеперечисленных недостатков. Весь код выполняется внутри docker-контейнера, который в свою очередь выполняется на Compute Engine инстансе, размер которого вы выбираете и за который, собственно, вам выписывают чек.

Мне понравилось, как реализовано версионирование сервисов в App Engine. При деплое вы указываете поле version для сервиса. Можно создать новую версию, а можно задеплоить в существующую. Таким образом у вас мгновенно доступны все версии, которые задеплоины, и в любой момент можно быстро откатиться к предыдущей версии, если что-то пошло не так при релизе. Функция traffic splitter дает возможность разделить трафик между версиями, что может быть удобно для тестирования или A\B тестирования. Однако стоит учитывать, что чем больше версий вы храните, тем больше денег заплатите :)

С автомасштабированием в App Engine все в порядке. В случае увеличения нагрузки нужное количество инстансов поднимется автоматически. Единственный нюанс в том, что во Flexible Environment это происходит немного дольше, поэтому Google рекомендует использовать Standard Environment для резких скачков в нагрузке на приложение.

В нашем случае мы использовали Flexible Environment как минимум из-за того, что необходим был .NET и сокеты. На сайте присутствовала фича наподобие «Кто сейчас онлайн» в таких продуктах Google как Documents и Spreadsheet.

Cloud Run

Другим способом размещения веб-приложений в GCP, который позволяет не думать об инфраструктуре, является Cloud Run. Это сервис для деплоя stateless HTTP-контейнеров, для которого вам не понадобится Kubernetes Cluster. Приложения можно писать на любой технологии. Ограничений нет, поскольку это просто контейнер, который вы билдите и деплоите в Cloud Run.

Как и в случае с App Engine, GCP автоматически увеличивает количество инстансов сервиса Cloud Run. Или же наоборот — вообще не держит никаких инстансов, если нагрузки нет. Это в свою очередь позволяет оптимизировать косты.

При помощи Cloud Run часто реализовывают background job-ы. В этом случае Cloud Run непосредственно выполняет работу, а тригерится она при помощи сервиса Cloud Scheduler. Вызывать его может HTTP-endpoint по крону. При этом стоит учитывать, что время на выполнение запроса в Cloud Run ограничено в час. Об этом также важно помнить, если вы хотите использовать веб сокеты. Веб-сокет соединение в Cloud Run рассматривается как long-running HTTP-запрос и подпадает под это ограничение. Клиент, использующий это веб-сокет соединение, должен иметь логику реконнекта (хотя она на самом деле должна быть в любом случае).

Data Storage

GCP предоставляет множество разных вариантов для хранения данных — от простого статического хранения блобов до сложной аналитики Big Data. Для нас желанным был Microsoft SQL Server, предпочтительно managed service, чтобы не поднимать его на виртуалках и не заморачиваться потом с maintanence, бекапами и прочим.

К счастью, такой вариант есть — Cloud SQL! Это managed инстансы реляционных БД, пользуясь которыми вы не думаете о том, что storage capacity исчерпан. Вы не возитесь с долгой настройкой репликаций и безопасностью. На выбор доступны MySql, PostgreSQL и MS SQL Server версии 2019 и 2017.

GCP предоставляет более мощный вариант для реляционных баз — Cloud Spanner. Это globally available решение, SLA которого 99.999% с автоматическим шардингом, способное выдержать петабайты данных. Не наш юзкейс, но выглядит интересно.

Для нереляционных решений GCP предлагает Firestore и Bigtable. Оба являют собой Key-Value Pair хранилище, но Bigtable позиционируется как более high-performance хранилище для большого объема данных и аналитики.

Для статических файлов мы выбрали Cloud Storage — аналог Blob Storage в Azure. Блобы в Cloud Storage хранятся в бакетах, которые можно сделать публичными. Для оптимизации доставки контента мы «прикрутили» дополнительно Cloud CDN, что является более оптимальным способом доставки контента пользователю. CDN можно настроить не только на Storage bucket, но и на Compute Engine инстансы и даже на App Engine-эндпоинты.

Краткий гайд по выбору хранилища в GCP приведен на картинке ниже от самого же Google:

Messaging

Если мне нужен был managed брокер сообщений, то в Azure я использовал проверенный временем сервис Service Bus. В GCP также есть свой брокер для Pub/Sub модели, который так и называется — Cloud Pub/Sub.

Pub/Sub модель пригодится, когда потребуется организовать асинхронную коммуникацию между компонентами системы. Как это работает? Каждый подписчик получает уведомление о том, что происходит событие, и может по-своему на него реагировать. Асинхронная модель позволяет улучшить производительность системы и легко масштабируется. Если к вам прилетает больше событий, достаточно увеличить количество инстансов подписчиков, чтобы успевать обрабатывать все событие.

При работе с Cloud Pub/Sub необходимо базово знать о Topic и Subscription. Создавая Topic, мы определяем контейнер для сообщений, которые будут слушать подписчики. Создавая Topic, указываем обязательный параметр — имя. Также нам предлагается создать Subscription, а также по умолчанию и несколько других вариантов:

• Use a schema. Фича Pub/Sub, позволяющая определять формат сообщения, который будет отправляться в топик. Если издатель попытается отправить сообщение, которое не соответствует выбранной схеме, то получит ошибку. Это помогает нам прописать дата-контракт между сервисами и принудить их соблюдать этот контракт.
• Set message retention duration. Платная фича, которая помогает задать время хранения сообщения в топике. Будет полезна, когда потребуется получить ранее отправленные сообщения, например для репроцессинга.
• Use a customer-managed encryption key. По умолчанию все сообщения в топике шифруются ключом, который менеджится GCP. Данная функция позволяет при необходимости использовать собственный ключ. Пригодиться это может, допустим, в рамках соблюдения security policy компании.

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

• Delivery Type — может быть Pull или Push. Если выбран метод Push, сообщение будет доставлено как только оно попадет в топик. А если выбрали Pull, то подписчик сам должен запросить сообщение.
• Message Retention Duration — время, в течении которого будут храниться необработанные сообщения.
• Expiration Period — время, спустя которое подписка будет удалена в случае неактивности. Также можно указать Never Expire.
• Acknowledgment deadline — то есть то, насколько долго Pub/Sub будет ждать, пока подписчик отметит сообщение как обработанное, иначе оно будет помечено как необработанное.
• Subscription FIlter — фича, которая мне очень понравилась. Позволяет получать не все сообщения, прилетающие в топик, а только те, которые подпадают под определённый нами фильтр. В начале знакомства с Google Cloud Platform мне было интересно, есть ли такая фича. Поскольку я проводил аналогию с Azure Service Bus, где она присутствует.
• Message Ordering — позволяет настроить Pub/Sub таким образом, чтобы сообщения были доставлены в том же порядке, в котором их запаблишили. Для этого также необходимо будет отправлять с каждым сообщением ordering key.
• Dead lettering — используется в том случае, когда количество попыток обработать сообщение исчерпано. Тогда оно отправляется в отдельный dead letter queue.

GCP предоставляет так называемый Pub/Sub Lite. По сути тот же сервис, но он позиционируется как более экономный вариант. Если вам необходим Pub/Sub в рамках одной зоны, а не глобально доступный сервис, то стоит обратить внимание на Pub/Sub Lite. В таком случае он может вам подходить больше.

Cloud Functions

Братом-близнецом Cloud функций в Azure является сервис Azure Functions. Как и Cloud Run и App Engine, он относится к серверлес подходу, когда вы не беспокоитесь о подноготной инфраструктуры, а фокусируетесь на коде. Такие функции, как правило, хороши для пиковых нагрузок на систему. Они очень быстро масштабируются и стоят дешево.

Традиционно для такого вида сервиса, чтобы запустить функции, понадобится триггер. В GCP есть как «классические» триггеры (HTTP, Pub\Sub и Cloud Storage), так и специальные гугловские (Cloud Firestore, Firebase Authentication и другие, т.к. Google постоянно экспериментирует и добавляет что-то новое). Скорее всего вас заинтересуют первые три:

• HTTP — функция, которая по сути просто API эндпоинт;
• Pub\Sub — функция, которая обрабатывает сообщения из определенного Pub\Sub-топика;
• Cloud Storage — логика, которая должна выполняться при любых операциях с файлами в сторедже.

Языки/платформы, на которых может быть написана ваша функция, следующие: Ruby (2.6, 2.7), Python (3.8, 3.9), Node.js (10, 12, 14, 16), Go (1.13, 1.16), PHP 7.4, Java 11 и .NET Core 3.1. Последнего на момент работы над приложением, о котором я писал выше, не было. Поэтому мы с командой решили написать нужные нам функции на Node.js. В GCP не хватало Time-триггера, чтобы можно было функции запускать по времени. Да и в целом, если сравнивать с Azure функциями, то они мне нравятся больше. Выглядит как более зрелый продукт.

Identity Management

Перейдем к авторизации. Меня при знакомстве с GCP интересовало, есть ли здесь что-то похожее на Azure Active Directory B2C. Требовался полноценный OAuth-сервер с поддержкой Single sign-on из коробки, который легко поднять и кастомизировать и к которому без проблем можно подключиться. В GCP мы нашли три базовых варианта:

• Firebase. В некотором роде это отдельная платформа, которая включает в себя много других функций для end-to-end разработки (хранилище данных, аутентификация, хостинг). Популярное решение для бэкенда мобилок. Пользователи нашего приложения хранятся в базе Firebase-а, можно настроить двухфакторную аутентификацию. Минусом для меня было то, что из коробки нет функционала полноценного OAuth-сервера, где была бы отдельная страница авторизации с redirect url и прочим. При использовании Firebase либо юзер вводит креды прямо в клиенте, либо можно настроить сторонних провайдеров по типу Google, Facebook. Если нужен единый портал для авторизации всех продуктов, эта опция отпадает.
• Identity Platform. Базируется на Firebase. По сути это он и есть, «под капотом» абсолютно та же функциональность. Однако Identity Platform поддерживает Multi-tenant, что не умеет сам Firebase. Также в нем есть возможность добавить кастомный identity provider. Допустим, у вас есть свой сервер авторизации. Вы вносите необходимые настройки в Identity Platform и затем сможете использовать его похожим образом, как Google или Facebook, добавив опцию авторизации в клиенте. Все еще не то, что мне нужно было :(
• Identity Aware Proxy. Этот сервис является в свою очередь надстройкой над Identity Platform. Фишка в том, что я могу сконфигурировать мой App Engine, Cloud Run или Cloud Function таким образом, чтобы сервис использовал этот Identity Aware Proxy, блокируя доступ неавторизованному юзеру. Это будет сделано автоматически, никакого кода писать не нужно. Пользователь в таком случае будет перенаправлен на страницу логина, которую мы укажем при развертывании IAP, и после успешной авторизации обратно — куда он стучался. Как и подобает Proxy, оно контролирует доступ к нашему сервису с помощью дополнительной «обертки», которая отвечает за авторизацию. Я попробовал этот инструмент и из недостатков могу отметить, что все равно нужно эту страницу логина делать самому. Да и токен, который выдает IAP, содержит не полную инфу о юзере. К тому же он передается не в Authorization хедере, а в кастомном. Сам Google говорит, что вы мол проверяйте этот токен в ваших сервисах для надёжности. Хотя выше я писал, что код можно не писать вообще.

В конечном итоге мы реализовали свой OAuth сервер на основе Identity Server 4 и захостили его под App Engine. Это дало нам больше контроля и меньше проблем.

Мониторинг

Нельзя обойти вниманием и вопросы мониторинга. Приложения постоянно ломаются, что-то идет не так, и необходимо иметь под рукой инструменты для диагностирования проблем. Для этого в GCP есть Cloud Operations, который включает в себя несколько сервисов: Logging, Monitoring, Error Reporting, Trace, Profiler, Debugger. Эта функциональность появилась в GCP благодаря приобретению компании Stackdriver и их одноименного продукта для мониторинга. Предлагаю кратко ознакомиться с каждым из инструментов:

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

Инструмент Log Router поможет вам перенаправить те или иные логи в другое хранилище, например в BigQuery, Storage bucket или даже в Pub\Sub топик. По умолчанию все логи хранятся в Log bucket, который имеет retention period для оптимизации костов. Логи старше retention period не будут храниться в лог бакете.

• Error reporting — собирает все ошибки из платформы на одном скрине и статистику их появления. Благодаря этому вы видите все ошибки в одном месте и можете предпринять соответствующие действия для их устранения.

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

• Cloud Monitoring — end-to-end решение для системных метрик, мониторинга производительности системы и различного рода health check-ов.

В этом сервисе вы можете создавать кастомные дашборды, на которых будут агрегироваться самые разные показатели ваших ресурсов в облаке (скорость ответов HTTP-сервисов, CPU и memory usage выбранных виртуальных машин, количество таблиц в SQL-базе данных и многое другое). Полезной будет и Alert Policies — функция создания правил, по которым вам будут приходить уведомления о том, что что-то пошло не так. Например, если место на диске закончилось или количество ошибок HTTP-ответов какого-то сервиса превысило заданное вами значение.

• Cloud Profiler — инструмент, который поможет получать различного рода инсайты из приложения, запущенного в проде.

При помощи этого инструмента вы можете узнать, какой метод в приложении выполняется дольше всего или какой участок кода съедает больше всего оперативной памяти. Для использования Cloud Profiler нужно настроить его в коде. То есть не просто одной кнопочкой все включается. Но не переживайте, Google предоставляет инструкции, как это сделать и что нужно указать при интеграции в Cloud Profiler.

Доступен такой инструмент далеко не всем. Только приложения на Java, Golang, Node.js и Python работают с ним. Для поиска проблем с производительностью можете рассмотреть и другой вариант — Cloud Trace. Его не надо настраивать в коде и он доступен для всех платформ.

• Cloud Debugger — позволяет отлаживать приложение на проде. Для использования нужно указать путь к исходному коду приложения. Доступны варианты исходников из GitHub, Bitbucket, GitLab и встроенного в GCP Cloud Source Repository.

Другие полезные сервисы

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

Google Kubernetes Engine (GKE) — kubernetes кластеры, которые легко поднять и управлять ими. Для этого Google предлагает удобные инструменты, а также dashboard для ваших кластеров.

Выбирая GCP, вы получаете обширные инструменты для Data Engineering. Такие сервисы как DataFlow, DataPrep и DataProc помогут решить задачи построения ETL процессов и подготовки данных для дальнейшего машинного обучения. Хранилище BigQuery послужит хорошим Data Warehouse решением для хранения и обработки больших объемов данных. Looker — в прошлом независимый инструмент, а с 2019 года приобретенный Google — является частью GCP и BI платформой как альтернатива MS Power BI и Tableau.

Имеется в Google Cloud Platform и широкий выбор AI-инструментов. В частности, тех, которые работают с ML-моделями или используют готовые модели и предоставляют REST API, решая распространенные ML задачи. К первому относится GCP API Platform, где вы можете писать модели, тренировать их и деплоить, имея под рукой удобные инструменты для менеджмента процесса. Ко второму типу относятся сервисы Vision, Translation, Speech to Text, которыми можно пользоваться для решения давно известных ML-задач.

Среди доступных domain-specific сервисов есть такие, как Financial Services и Healthcare. Кстати, Cloud Healthcare API будут особенно полезны с учетом роста этой отрасли за последние 2 года. Данный сервис являет собой готовое хранилище медицинских данных с доступом через FHIR-протокол.

Заключение

Какие у меня остались впечатления после использования GCP? Несмотря на то, что по сравнению с конкурентами эта платформа менее зрелая, но стремительно развивается, у меня нет ощущения, что на GCP невозможно построить какую-либо систему. Примером тому — большие успешные проекты, которые уже используют GCP — Spotify, PayPal, Twitter и многие другие. Вне зависимости от выбранной технологии для построения систем Google Cloud Platform предоставляет широкий набор инструментов для всех. Тот, кто знаком с любым другим облаком, довольно быстро сориентируется в GCP. Вы также почти всегда найдете сервисы с аналогичным функционалом, который раньше использовали в более привычной вам среде.

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