Переносите приложение в облако? Вот что вам нужно знать – CloudSavvy IT

Shutterstock / флоксии

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

Что делает облако таким полезным?

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

Однако современные облачные провайдеры, такие как Amazon Web Services (AWS), Google Cloud Platform, Microsoft Azure и Digital Ocean (DO), предлагают гораздо больше, чем просто серверы за определенную плату. Они сделали это своим бизнесом, чтобы повысить эффективность своих операций и предоставить разработчикам простые в использовании инструменты, которые значительно упрощают создание приложений.

Например, запуск ваших серверов в облаке может действительно сэкономить вам деньги. В то время как выделенные серверы, конечно, будут дороже по принципу «ядро за ядром» (так как все собираются несколько разметить свои продукты), такие провайдеры, как AWS, имеют передовые системы автоматического масштабирования. Это позволяет полностью автоматизировать процесс жизненного цикла сервера, создавая и уничтожая новые серверы по мере колебаний спроса, часто по несколько раз в день. Вместо того, чтобы платить за пиковую мощность, вы можете уменьшить масштаб в нерабочее время и сэкономить деньги в целом.

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

Облако также экономит деньги за счет автоматизации задач. Например, AWS Relational Database Service (RDS) – это полностью управляемая служба SQL, которая автоматизирует большую часть работы по управлению базами данных. Возможно, вы уже заплатили кому-то за выполнение этих задач на ваших собственных серверах; если бы вы использовали RDS, этот человек мог бы управлять большим количеством баз данных и тратить остальное время более эффективно.

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

Например, служба DNS AWS, Route 53, поддерживает проверки работоспособности, которые контролируют ваше оборудование и автоматически переключают трафик на уровне DNS, если сервер перестает отвечать. Группы автоматического масштабирования также поддерживают проверки работоспособности и могут полностью завершить работу и заменить сервер, если у него возникнут проблемы.

Модернизация вашей архитектуры с помощью облачных решений

Shutterstock / Ashalatha

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

Например, многие старые приложения спроектированы так, чтобы быть «монолитными», т. Е. Упакованными в одну большую программу, которая запускается на вашем сервере. Эта программа может взаимодействовать с локальной или удаленной базой данных, обрабатывать входящие веб-запросы, выполнять запросы, выполнять поиск информации, обрабатывать очереди и все остальное, что требуется для вашего варианта использования.

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

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

Какие услуги мне следует искать?

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

Мы обсудим некоторые сервисы AWS, поскольку они являются лидерами отрасли, особенно по количеству предлагаемых услуг. Однако у большинства из них есть аналогичные продукты, доступные у других облачных провайдеров, таких как Azure, GCP и Digital Ocean.

Облачное хранилище объектов (S3)

В большинстве локальных решений используется хранилище на уровне блоков, то есть объекты хранятся в виде файлов на дисках и становятся доступными по сети. Однако масштабы таких поставщиков, как AWS, позволяют хранить огромное количество файлов в их Simple Storage Service (S3).

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

Например, предположим, что ваше приложение разрешает загружаемый пользователем контент. Хранение изображений в S3 было бы отличным вариантом, и вы даже можете сделать их доступными через Интернет с помощью сети доставки контента AWS CloudFront.

Переход на хранилище на основе S3 – это немного сложный процесс, но есть гибридные решения, такие как AWS Storage Gateway.

Облачные функции

Облачные функции, такие как Lambda, невероятно полезны – они позволяют запускать код в облаке, не думая о серверах. Просто запросите выполнение функции напрямую или через API, например AWS API Gateway, и она будет поставлена ​​в очередь и запущена на серверах Lambda.

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

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

Балансировщики нагрузки и автоматическое масштабирование

Балансировщики нагрузки – это сетевые устройства, которые разделяют трафик между серверами. Традиционно вам приходилось настраивать сервер и настраивать его самостоятельно с помощью такой программы, как HAProxy. В AWS они встроены в сеть, и вам просто нужно включить их и платить за них ежемесячную плату.

Автоматическое масштабирование – это еще одна функция, которая построена на балансировщиках нагрузки. Вместо того, чтобы ваш список серверов был статическим, он основан на потребностях трафика. Серверы будут добавляться и удаляться из пула по мере необходимости.

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

Если есть что-то, что мы рекомендуем всем настроить, так это автоматическое масштабирование ваших основных сервисов EC2.

Автоматизированные конвейеры CI / CD

Shutterstock / Ribkhan

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

По сути, вы отправляете фиксацию в Github (или любой другой репозиторий, который вы используете), и такую ​​службу, как AWS CodePipeline запускает сервер сборки. Этот сервер создает и тестирует ваше приложение, и в случае успеха отправляет готовую сборку на ваши серверы для обновления. Если у вас настроено автоматическое масштабирование, это можно сделать с помощью сине-зеленого развертывания с возможностью быстрого и легкого отката при необходимости.

Встроенная сеть доставки контента (CDN)

Наличие CDN может значительно ускорить время доставки. Поскольку AWS по сути является всемирной вычислительной супердержавой, их CDN имеет граничные узлы по всему миру. Многие другие облачные провайдеры имеют аналогичные решения; Cloud CDN от Google является одним из самых быстрых и гибких, поскольку Google фактически контролирует большую часть инфраструктуры, составляющей Интернет.

Можете ли вы мигрировать без простоев?

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

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

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

Первый вариант прост для небольших развертываний и упрощается благодаря таким сервисам, как AWS Application Migration Service, который может быстро переместить парк серверов на EC2. Скорее всего, вам все еще понадобятся обновления кода и конфигурация, но он может переместить всю вашу сеть в тестовую среду, где вы сможете все настроить, а затем выполнить переключение, когда будете готовы.

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