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

## Типы приложений
Двухуровневые веб-приложения состоят из веб-сервера, на котором выполняется приложение, и базы данных для хранения данных приложения. Запуск Linux, Apache, MySQL и PHP, обычно называемый стеком LAMP, является распространенным примером двухуровневого веб-приложения. Различия в дистрибутиве Linux, программном обеспечении веб-сервера, базе данных или языке программирования влияют на технические детали любой миграции, но общий обзор и этапы миграции одинаковы.

## Этапы миграции
Облачные миграции происходят в следующие четыре фазы

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

На современных предприятиях существует множество различных приложений: от приложений для клиентов до приложений для бэк-офиса, инструментов для разработчиков и экспериментальных приложений. Перемещение всех этих приложений одновременно и одним и тем же способом было бы рискованным и неэффективным.

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

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

- Приложения, которые нельзя перемещать. Некоторые приложения, которые могут не подходить для миграции, работают на специализированном или более старом оборудовании, имеют деловые или нормативные требования, обязывающие их оставаться в вашем центре обработки данных, или имеют сложные лицензионные требования, которые не Â не позволять им перемещаться в облако

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

 Фундамент
Спроектируйте и спланируйте конкретные детали для развертывания новой облачной среды. Это включает:
- Облачная архитектура и модель безопасности для обеспечения основы инфраструктуры для ваших рабочих нагрузок.

Сетевые ресурсы для обеспечения безопасной и надежной связи между приложениями. Это требует тщательного планирования для управления идентификацией и доступом (IAM), дизайна виртуального частного облака (VPC) и методов внешнего доступа.

Конечные технологии и инструменты, на которых будут работать ваши рабочие нагрузки

Учет управления зависимостями, сроков и методов перемещения данных

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

 Оптимизация
Проверьте, соответствуют ли решения и предположения, сделанные вами на этапах оценки и основания, реальности после этапа миграции. Вы определяете любые изменения, которые могут вам понадобиться. Подумайте, как изучить другие облачные варианты, такие как переход от инфраструктуры как услуги (IaaS) к платформе как услуги (PaaS) или воспользоваться преимуществами предложений управляемых услуг. В зависимости от результатов этапа оптимизации вы можете начать цикл снова, чтобы внести изменения или модификации. Всегда начинайте с этапа оценки и используйте свой опыт для повышения эффективности с каждой итерацией.

## Типы миграций
Три наиболее распространенные стратегии переноса приложений в облако описаны в следующих разделах.

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

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

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

Еще одна вариация этой стратегии — улучшаться и двигаться одним движением. Если оба уровня вашего веб-приложения размещены на виртуальных машинах, вы можете использовать Migrate to Containers для автоматического перемещения и преобразования этих виртуальных машин в контейнеры, работающие на Google Kubernetes Engine (GKE).

 Сорвать и заменить
Использовать
*копировать и заменить*, когда вы хотите создать новое решение в облаке, и
закрыть текущую версию локального решения. Это обычно используется
при соблюдении следующих условий:
- Существующее приложение не стоит поддерживать в облаке ни с технической, ни с финансовой точки зрения.

- Лицензирование программного обеспечения в облаке запрещено или нецелесообразно

- Приложение вообще перестает удовлетворять потребности бизнеса

Поскольку копирование и замена требует перезаписи приложения с нуля, это не рассматривается в этом руководстве по миграции.

## Фаза оценки
Прежде чем начинать любую миграцию, вы должны иметь полное представление о своей отправной точке.

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

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

- Веб-сервер: точный пакет программного обеспечения, номер версии, пакеты или другие модификации программного обеспечения, а также все файлы конфигурации и правила для программного обеспечения веб-сервера.

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

- Среды выполнения: точные версии всех внутренних и внешних сред.

 Аппаратные ресурсы системы
Для уровней веб-сервера и базы данных ответьте на следующие вопросы:
- Сколько серверов работает сейчас?
- Каково общее распределение ЦП, включая поколение, тип архитектуры и скорость?
- Какие объемы оперативной памяти и дискового пространства выделяются каждому серверу? Используются ли жесткие диски или твердотельные накопители? RAID?

- Каково текущее использование, среднее использование и пиковое использование ЦП, ОЗУ и дискового пространства? Посмотрите на свой средний и пиковый уровень в контексте вашего конкретного использования в бизнесе. Например, компании, поддерживающей Олимпийские игры, может потребоваться оглянуться на два года назад, чтобы увидеть, как выглядит истинный пик, в то время как другие приложения могут иметь более стабильную скорость выполнения. Посмотрите на график наиболее типичного варианта использования для среднего значения и график наиболее интенсивного использования для пикового значения. Также ищите модели циклического использования, такие как выходные, вечера и рабочие дни.  - Какая стратегия резервного копирования, репликации или сегментирования используется для базы данных и как это влияет на требования к дисковому пространству и количество необходимых серверов?  Сетевые ресурсы Проанализируйте сетевую архитектуру, которая позволяет вашему приложению функционировать. Убедитесь, что у вас есть точные и актуальные схемы логической и физической топологии сети инфраструктуры, поддерживающей ваше приложение. На диаграммах должны быть четко обозначены все соединения, зависимости и сетевые службы.  Ответьте на следующие вопросы: - Как клиенты получают доступ к вашему приложению? Через веб-браузер? Напрямую через IP-адрес? Через мобильное приложение? Используете виртуальное частное сетевое соединение? - Есть ли у вас список всех применимых сертификатов SSL/TLS и ключей шифрования? - Где размещены все применимые сертификаты SSL/TLS? Когда они истекают? Как вы продлеваете сертификаты? Как получить новые сертификаты? Есть ли у вас доступ ко всем текущим сертификатам? - Есть ли у вас список всех применимых доменов, поддерживающих приложение? - Где размещены эти домены? Когда они истекают? Как вы их продлеваете? Есть ли у вас доступ к учетным записям, которые контролируют регистрацию? - Где размещен и контролируется ваш DNS? - Есть ли у вас доступ ко всем системам и инструментам, которые контролируют DNS? Каковы текущие сопоставления CNAME и IP для каждого домена, и есть ли у вас резервная копия? - Каковы ваши настройки времени жизни DNS (TTL)? - Какое место в архитектуре занимают ваши брандмауэры и другие устройства сетевого доступа и контроля? Какие правила сейчас действуют для разрешения или запрета трафика? Кто несет ответственность и какова процедура изменения или обновления этих правил? - Пользуетесь ли вы какими-либо внешними сетевыми сервисами? Например, провайдер сети доставки контента (CDN) или распределенная служба защиты от атак типа «отказ в обслуживании» (DDoS)? ## Фундаментальный этап Google Cloud предлагает множество вариантов выполнения рабочих нагрузок вычислений и баз данных для многоуровневых приложений, таких как LAMP. В этом разделе представлены эти параметры и объясняется, почему вы можете выбрать один из них.   Варианты, ориентированные на вычисления  Вычислительный движок Compute Engine — это предложение IaaS, позволяющее запускать виртуальную машину (ВМ) в облаке Google. Вы можете установить веб-фреймворки, серверное программное обеспечение, базы данных и любое другое программное обеспечение, которое поддерживает ваша операционная система. Если вы используете собственное приложение LAMP на «голом железе», на виртуальной машине, в центре обработки данных или у другого облачного провайдера, этот вариант может близко, если не точно, реплицировать ваш существующий сервер. Этот вариант предлагает наибольший контроль над конфигурацией операционной системы и настройками программного обеспечения веб-сервера. Compute Engine обеспечивает глубокий контроль над типами машин, группами экземпляров, вариантами хранения, балансировщиками нагрузки и многими другими деталями. См. полную документацию Compute Engine для получения дополнительных кратких руководств, руководств и многого другого.  Перенос вашего приложения непосредственно в Compute Engine – наиболее распространенный метод поэтапной миграции. Инструкции по сопоставлению локальных ресурсов с Compute Engine см. в разделе Рекомендации по переносу виртуальных машин на Compute Engine.   Менеджер облачного развертывания Google Cloud Marketplace также предлагает простую установку LAMP через Deployment Manager.Вы можете запустить сервер с уже установленными и настроенными Debian Linux, Apache, MySQL, PHP и phpMyAdmin в настройках по умолчанию.Вы получаете полностью функционирующий веб-сервер и учетные данные для установки MySQL всего за несколько минутGoogle Kubernetes EngineGKE — это управляемая, готовая к работе среда для развертывания контейнерных приложений.Используя GKE, вы перестаете управлять операционной системой, помещая в контейнер программное обеспечение веб-сервера.Например, веб-серверы Apache и NGINX доступны из каждого общедоступного репозитория контейнеров.Если вы используете контейнеры для запуска рабочих нагрузок в своей среде, GKE — это эффективный сервис для поддержки аналогичного рабочего процесса развертывания и тестирования при переносе рабочей нагрузки LAMP в Google Cloud.Если вы не используете контейнеры, рассмотрите возможность использования GKE для более быстрого развертывания и восстановления, большей эффективности использования ресурсов и избавления от необходимости управлять базовой операционной системой и виртуальной машинойДля Дополнительные сведения об управлении приложениями-контейнерами в масштабе см. в документации GKE, содержащей краткие руководства, руководства, концепции, практические руководства и другие ресурсы, которые помогут вам приступить к работеПеремещение локального приложения LAMP на GKE — это миграция по принципу «улучшение и перемещение», а переход с самоуправляемой инфраструктуры на основе контейнеров — постепенная миграцияApp EngineApp Engine — это бессерверная платформа для создания масштабируемых приложений.В зависимости от типа приложения, которое вы используете, App Engine может устранить необходимость в управлении серверами, контейнерами или развертываниями, позволяя вашим разработчикам сосредоточиться на написании кода и снижая сложность управления любой базовой инфраструктурой.Не все рабочие нагрузки являются хорошими кандидатами для переноса на App Engine, но те, которые позволяют, снижают стоимость и сложность при одновременном повышении скорости масштабирования и отказоустойчивости приложения под нагрузкойApp Engine поставляется в двух вариантах: стандартная среда охватывает различные языки (включая PHP для нашего приложения LAMP), а гибкая среда позволяет больше настраивать среды выполнения, производительность и инфраструктуру.Изучите документацию по выбранному вами языку, чтобы узнать большеПараметры базы данных
 Самоуправляемый на Compute Engine
Вы можете установить MySQL, PostgreSQL или любую другую базу данных на основе SQL на экземпляр Compute Engine. Это обеспечивает тот же уровень контроля, который вы имели бы при запуске MySQL на рабочей станции, на сервере в центре обработки данных или в качестве виртуальной машины в другом облачном провайдере. Когда вы запускаете свою базу данных на виртуальной машине, вы несете ответственность за настройку, мониторинг и поддержку аварийного переключения, репликации, секционирования и высокой доступности.

Вы можете рассматривать базу данных как вычислительную рабочую нагрузку, учитывая ЦП, ОЗУ и дисковое пространство, чтобы обеспечить достаточное количество ресурсов для надежной работы приложения.

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

 Облачный SQL
Cloud SQL — это полностью управляемая служба базы данных, которая переносит установку, настройку и обслуживание вашей базы данных в Google Cloud. Он автоматизирует резервное копирование, репликацию, исправления и обновления и позволяет вам сосредоточиться на своем приложении. Базы данных Cloud SQL могут использоваться рабочими нагрузками, выполняемыми в любых вычислительных службах Google, включая Compute Engine, GKE и App Engine. Если вам не нужен глубокий уровень контроля над вашей базой данных MySQL, Cloud SQL — это простой в настройке и полнофункциональный вариант для выполнения рабочей нагрузки LAMP.

Cloud SQL может изначально запускать и поддерживать MySQL и PostgreSQL. Если вы выполняете миграцию с одной из этих баз данных на Cloud SQL, это миграция с подъемом и сдвигом. Если вы изучаете новые методы репликации, стратегию резервного копирования или простоту управления своей инфраструктурой, это может быть миграция по принципу «улучшайте и перемещайте».

 Другие варианты хранения
Облачное хранилище — это масштабируемое, полностью управляемое, высоконадежное и экономичное хранилище объектов или BLOB-объектов, которое идеально подходит для хранения изображений, статических ресурсов и других неструктурированных данных. Облачное хранилище можно использовать для размещения статического веб-сайта, но оно не предназначено для хранения содержимого активной базы данных. Это также идеальное место для хранения объектов резервного копирования и аварийного восстановления, а также данных для потоковой передачи.

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

 пожарный магазин

Firestore — это полностью управляемая, бессерверная, облачная база данных документов NoSQL, которая упрощает хранение, синхронизацию и запрос данных для ваших мобильных, веб-приложений и приложений Интернета вещей (IoT) в глобальном масштабе. Его клиентские библиотеки обеспечивают синхронизацию в реальном времени и автономную поддержку, а функции безопасности и интеграция с Firebase и Google Cloud ускоряют создание действительно бессерверных приложений. Если в вашем приложении есть контент, который мог бы выиграть от формата NoSQL, например профили пользователей, каталоги продуктов или состояние игры, вам следует изучить Firestore на этапе оптимизации миграции.

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

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

Google Cloud предлагает множество других вариантов хранения для поддержки различных рабочих нагрузок.

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

 Поднимите и сдвиньте: Compute Engine
Первый шаг к началу миграции с переносом и переносом — создание совместимой многоуровневой службы в Compute Engine. Хотя есть много подходов к этому; следующие три наиболее распространены:
- Ручная настройка. Запустите виртуальную машину с нужной операционной системой, затем вручную обновите репозитории, установите и настройте программное обеспечение, а также подготовьте и настройте базу данных и среду выполнения вручную. Этот подход обеспечивает высокий уровень контроля, но требует больше времени, более подвержен ошибкам и менее воспроизводим, чем другие методы.

- Автоматизированный. Используйте Migrate to VMs, чтобы перенести стек виртуальных машин (в указанном порядке) из локальной среды в автоматически подготовленные и настроенные виртуальные машины нужного размера в Compute Engine.

- Облачный рынок. Запустите предварительно настроенный стек LAMP в своем проекте Google Cloud. Обязательно убедитесь, что предоставленные версии операционной системы и программного обеспечения будут работать с вашим приложением. Изучите документацию Cloud Marketplace, чтобы узнать больше

- Автоматическое развертывание. Создавайте готовые к работе виртуальные машины, используя концепции непрерывной интеграции/непрерывного развертывания и различные инструменты управления конфигурацией (Chef, Puppet, Ansible, Salt), инструменты инфраструктуры как кода (Deployment Manager, Terraform) и платформы автоматизации (Cloud Build). Автоматизированное развертывание позволяет использовать тестируемые, повторяемые и автоматизированные методы для развертывания виртуальных машин и программного обеспечения, которые соответствуют потребностям вашего приложения и управления.
 Улучшайте и перемещайте: GKE и Cloud SQLЧтобы перейти на решение с управляемым контейнером, вы должны сначала создать основу для вашего кластера и решения с управляемым SQLЗапуск кластера GKEСоздание кластера в GKE и управление этим кластером — это первые шаги.Используйте информацию, полученную на этапах оценки и основания, для определения размера и настройки исходного кластера, а также для применения рекомендаций по усилению безопасностиПараметры запуска Cloud SQLИспользование информацию базы данных, полученную на этапах оценки и создания основы, создайте новый экземпляр Cloud SQL и следуйте другим инструкциям по созданию базы данных для вашего приложения.Google предоставляет список лучших практик Cloud SQL, руководства по настройке высокой доступности и другие руководства по горизонтальному масштабированию.Изучите варианты подключения Google Kubernetes Engine к Cloud SQL и выберите вариант, подходящий для вашего приложения и уровня опытаБессерверное улучшение и перемещение: App Engine и Cloud SQLЕсли вы решите перенести свое приложение LAMP на бессерверную платформу, вам может потребоваться изменить приложение, чтобы оно поддерживало App Engine.Каждое приложение отличается от других, и существует множество стратегий.Начните со следующего:— получите обзор архитектуры микросервисов в App Engine— поймите, как создать и назвать разработку, тестирование, контроль качества, подготовку , и рабочие среды с микросервисами в App Engine— Узнайте о передовых методах разработки API для взаимодействия между микросервисами— Узнайте о передовых методах повышения производительности микросервисовВ зависимости от вашего организационного и личного опыта и знакомства с выполнением бессерверного кода, бессерверная стратегия улучшения и перемещения может занять значительно больше времени, чем варианты подъема и переноса.Однако предоставление вам лучших бессерверных решений может стать огромным преимуществом для вашей организации## Этап оптимизацииПосле того, как ваше приложение будет запущено в Google Cloud, вы можете проверить свои предположения и решения, сделанные на предыдущих трех этапах.Полная миграция может занять много времени, и многие детали могут измениться в процессе.Оптимизация охватывает многие области, но вот несколько общих категорийОптимизация затратПереход от локальной среды к облаку меняет то, как вы тратите деньги на приложения , услуги и инфраструктура.Вы можете выполнить оценку устаревшей локальной службы и после миграции обнаружить, что современное оборудование, более быстрая память и новые архитектуры ЦП работают с ней более эффективно.Это может означать, что ваши виртуальные машины имеют избыточное выделение ресурсов и тратят деньги впустую.Вы можете исследовать использование вытесняемых экземпляров виртуальных машин в Compute Engine.Возможно, вам не нужно столько балансировщиков нагрузки, как вы думали, или вам удалось очистить базу данных во время переезда, и теперь у вас есть место, которое вы не используете.Поиск способов сэкономить деньги и снизить эксплуатационные расходы в облаке может превратиться в оплачиваемую работу на полный рабочий день.Google Cloud имеет ряд инструментов управления затратами, которые могут помочь вам понять цены на облакоАвтоматизацияПравильная автоматизация вычислительных рабочих нагрузок в облаке может привести к увеличению затратпреимущества экономии и повышения эффективностиDeployment Manager – это продукт Google Cloud, разработанный для помощи в создании облачныхресурсов и управлении ими с помощью простых шаблоновСценарии сgcloud— это вариант, если вы предпочитаете писать свои собственные средства автоматизации.Хотя финансовыепреимущества связаны с автоматизацией, другие преимущества включают следующее:— стандартные и повторяемые процессы для снижения частоты ошибок— контролируемое отслеживание для соответствия требованиям и управления— более глубокое понимание того, как работает ваше приложение, как оно ломается и как это исправитьАвтоматизация увеличивает время безотказной работы, снижая зависимость от предупреждений и времени реакции человека, снижает технический долг за счет документирования рабочего процесса и позволяет вашим инженерам меньше сосредотачиваться на поддержании работоспособности и больше на создании более качественных продуктов, инструментов и услуг.Эти концепции лежат в основе проектирования надежности сайта (SRE).Google Cloud предлагает бесплатную онлайн-книгу по проектированию надежности сайтов, а также рабочую книгу SRE, содержащую практические примеры и тематические исследованияРазделение вашей инфраструктуры и кодаВы много раз разделяете службы по мере роста приложения.Разделение подключенных сервисов и знание способов их независимого масштабирования повышает доступность и надежность ваших приложений.Обычно этот процесс состоит из трех шагов:— везде внедряйте инфраструктуру как код (IaC).Внедряя IaC и процессы управления конфигурацией, вы получаете отслеживаемые, проверяемые и воспроизводимые строительные блоки для обеспечения и настройки всей вашей инфраструктуры.— Разделите существующие сервисы на микросервисы.Используйте ПО промежуточного слоя, ориентированное на сообщения, такое как Pub/Sub, чтобы позволить каждой микрослужбе быть собственным доменом сбоя.— Начать перенос служб с инфраструктуры как службы на платформу как службу , или даже функционирует как сервис или бессерверный как сервис.Переход от «монолитного кода и инфраструктуры» к «несвязанным микросервисам, эффективно работающим во всем спектре IaaS» — ценная цель, которая потребует времени, усилий и самоотверженностиНастройка производительностиНастройка производительности может дать значительный выигрыш в использовании системы и времени отклика.Каждая рабочая нагрузка имеет свой метод настройки производительности, от файлов конфигурации программного обеспечения до настройки флагов ядра.Для приложений LAMP настройка производительности обычно подпадает под три категории:- Настройка облака, сети и операционной системы:
- 5 шагов к повышению производительности сети Google Cloud помогут вам понять, как получить максимальную отдачу от сети Google Cloud.

- Оптимизация TCP для производительности сети в Google Cloud может помочь, если у вас есть особые требования к задержке TCP.

- Оптимизация производительности постоянных дисков и локальных твердотельных накопителей может помочь вам узнать об архитектуре для тяжелых рабочих нагрузок IOPS.

- Повышение производительности Compute Engine может повысить производительность приложений API при взаимодействии с другими API и сервисами Google Cloud.

- Настройка веб-сервера:
- Настройка производительности Apache и настройка производительности NGINX или общий поиск в Google по запросу «настройка производительности вашего веб-сервера» приведет вас в правильном направлении.

Настройка базы данных:
## Что дальше
- Настройка LAMP на Compute Engine

- Разверните стек LAMP

– Узнайте больше о выполнении вычислительных рабочих нагрузок в Compute Engine или GKE.

Подключить GKE к Cloud SQL

Подробнее о миграции на виртуальные машины и миграции на контейнеры

Создавайте масштабируемые приложения на полностью управляемой бессерверной платформе с помощью App Engine.

Узнайте больше о параметрах базы данных в Google Cloud

Ознакомьтесь с эталонными архитектурами, диаграммами, учебными пособиями и рекомендациями по работе с Google Cloud. Загляните в наш Центр облачной архитектуры.