Введение
С технологиями, которые мы имеем сегодня, существует множество вариантов размещения веб-сайта. Мы особенно заинтересованы в бессерверных вычислениях и решили запустить наш сайт именно таким образом. Когда мы выбрали Google Cloud Platform, мы не смогли найти бессерверную реляционную систему баз данных. Наше приложение Java Spring Boot было создано для использования реляционной базы данных, поэтому переход на другое предложение баз данных был не тем, что мы хотели делать в данный момент. Архитектура, которую мы выбрали для реализации, состояла из следующих сервисов GCP.
- Облачная CDN для распространения и кэширования
- Облачный DNS для регистрации и маршрутизации DNS
- Облачная балансировка нагрузки для распределения
- Cloud Run для логики бэкенда
- Cloud SQL для постоянного хранения данных
- Cloud Storage для статического хостинга веб-сайтов
Этот сервис Cloud SQL является единственной бессерверной частью архитектуры.
Справочная информация
Наша команда хорошо знакома с Amazon Web Services, но мы хотели изучить другие облака, чтобы получить эти знания и провести личное сравнение. Мы считаем, что если мы просто останемся в своей зоне комфорта, то никогда не сможем по-настоящему развиваться. Кроме того, мы можем упустить лучшую альтернативу, если нам не хватит смелости изучить наши возможности. Горькая правда заключается в том, что не существует однозначного поставщика облачных услуг, который был бы лучше остальных. Вы можете ранжировать облачных провайдеров по различным аспектам и встряхнуть результаты. Облачный провайдер, которого вы решите использовать, должен быть тем, который обеспечивает наибольшую ценность для проекта, над которым вы работаете.
Развертывание инфраструктуры
При изучении вариантов развертывания архитектуры мы вкратце рассмотрели Google Cloud Deployment Manager. После дальнейшего изучения мы решили использовать Terraform. Было очевидно, что Cloud Deployment Manager не имеет необходимой поддержки для типов ресурсов, которые мы пытались создать. Многие из поддерживаемых типов ресурсов все еще находились в бета-версии.
https://cloud.google.com/deployment-manager/docs/configuration/supported-resource-types
Terraform имел полную поддержку всех необходимых ресурсов, перечисленных выше. Мы использовали Terraform Cloud для отслеживания изменений конфигурации и хранения состояния.
Развертывание кода
Мы поняли, что если не автоматизировать развертывание кода, то наши развернутые ресурсы быстро устареют. Продолжая пробовать что-то новое, мы решили использовать Google Cloud Build для автоматизации кода. С учетом отсутствия изменений в нашем коде этот подход оказался для нас бесплатным. Мы создали триггер сборки, который будет следить за нашим репозиторием GitHub, и создали файл cloudbuild.yaml, который настраивал задание сборки. В документации утверждалось, что необходим только Dockerfile, однако на практике мы не смогли заставить его работать. Нам потребовалось создать yaml-файл для Cloud Build, чтобы успешно обновить ревизию на Cloud Run.
options:
logging: CLOUD_LOGGING_ONLY
steps:
- name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', 'gcr.io/$PROJECT_ID/rest-java:$COMMIT_SHA', '.']
timeout: 300s
- name: 'gcr.io/cloud-builders/docker'
args: ['push', 'gcr.io/$PROJECT_ID/rest-java:$COMMIT_SHA']
timeout: 300s
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
entrypoint: gcloud
args: ['run', 'deploy', 'rest-java', '--image', 'gcr.io/$PROJECT_ID/rest-java:$COMMIT_SHA', '--region', 'us-central1']
timeout: 300s
Предложения бессерверных реляционных баз данных
При обсуждении решения по базе данных для нашего приложения мы искали масштабируемую бессерверную базу данных, которая не будет выставлять нам счета за время простоя. На ум сразу же пришли такие варианты, как AWS Athena, AWS Aurora Serverless и Azure Cosmos DB. Мы полагали, что у GCP есть сопоставимый сервис, но не смогли его найти. Даже после изучения документации по сравнению облачных сервисов GCP мы так и не смогли найти ни одного предложения бессерверной реляционной базы данных. По этим причинам мы пошли по пути наименьшего сопротивления и решили использовать микроэкземпляр Cloud SQL для MySQL.
Операционная производительность
Запустив наше базовое приложение на GCP в течение нескольких месяцев, мы остались довольны производительностью и стабильностью архитектуры. Наши настройки масштабирования Cloud Run были намеренно установлены на низком уровне, чтобы соответствовать ожиданиям приложения, а также чтобы избежать потенциального шока от фиаско автомасштабирования. Как и AWS App Runner и AWS Lambda, мы столкнулись с задержками холодного старта при масштабировании с нуля. Мы могли бы попытаться обойти эту проблему с помощью автоматических триггеров или постоянно работающих экземпляров. Однако для нашего случая холодный старт не был проблемой. Нам также показалось, что обеспечение постоянно работающих экземпляров противоречит цели бессерверного сервиса. Можно ли считать сервис «бессерверным», если он не может масштабироваться до нуля, чтобы вы не платили за простаивающие вычисления? Мы ответили отрицательно.
Эксплуатационные расходы
Мы обнаружили, что затраты на GCP сопоставимы с AWS, когда услуги сопоставлены один к одному. Однако, поскольку CDN-сервис AWS CloudFront является отдельным продуктом, на AWS возможна более простая и дешевая альтернативная архитектура. Служба GCP CDN Cloud CDN требует использования параллельно с их службой Cloud Load Balancer, минимальная операционная стоимость которой составляет ~$18/месяц, даже при отсутствии трафика. Наконец, наш экземпляр Cloud SQL также оплачивается почасово, что обходится нам примерно в ~$9/месяц. Эта сумма в ~27 долларов не кажется большой, но она значительно увеличивается при сравнении с бессерверными приложениями с низким трафиком, которые стоили бы копейки при размещении у другого облачного провайдера.
Заключение
В итоге мы рады, что исследовали этот путь. Наш глубокий анализ этого проекта подтвердил, что GCP не является идеальным хостинговым решением для нас. Минусы для этого бессерверного приложения с низким трафиком перевешивают плюсы. Мы могли бы построить более простое приложение на AWS со следующими изменениями, которые улучшили бы масштабируемость и снизили стоимость. Использование CloudFront в качестве CDN устраняет необходимость в использовании дорогостоящего сервиса балансировки нагрузки. Использование Aurora Serverless предоставляет нам реляционную базу данных, которая может масштабироваться до нуля, так что мы не платим за время простоя. Правда, Aurora Serverless может столкнуться с замедлением времени отклика на запросы при масштабировании, но мы считаем, что это стоит экономии средств. Наконец, Aurora Serverless обеспечит возможность масштабирования, превышающую производительность, которую мы могли бы достичь с нашим единственным экземпляром Cloud SQL, и обеспечит высокую доступность, чтобы мы не беспокоились о единой точке отказа базы данных. Возможно, в будущем мы снова обратимся к GCP для другого случая использования.
Если вам понравился этот материал, возможно, вы захотите угостить меня кофе или связаться со мной на LinkedIn.