Практический пример: почему я использую облачную инфраструктуру AWS для своих продуктов

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

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

Требования

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

1. Безопасность
2. Масштабируемость

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

Обзор концепций безопасности AWS

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

Хотя LEVELS был молодым продуктом, когда они обратились к Toptal за консультационными услугами AWS, они были готовы довериться AWS и знали, что им нужна современная безопасность с их инфраструктурой, поскольку они очень заботятся о пользовательских данных и конфиденциальности. Кроме того, они планируют поддерживать обработку кредитных карт в будущем, поэтому они знали, что в какой-то момент им потребуется обеспечить соответствие PCI-DSS.

Виртуальное частное облако (VPC)

Безопасность в AWS начинается с создания вашего собственного Amazon Virtual Private Cloud (VPC) — выделенной виртуальной сети, в которой размещаются ваши ресурсы AWS и которая логически изолирована от других виртуальных сетей в облаке AWS. VPC получает собственный диапазон IP-адресов, полностью настраиваемые подсети, таблицы маршрутизации, списки контроля доступа к сети и группы безопасности (по сути, брандмауэр).

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

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

Изоляция доступа на уровне VPC

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

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

Модель безопасности хранилища активов

Активы хранятся в объектном хранилище Amazon Simple Storage Service (S3) . Инфраструктура хранения S3 полностью независима от VPC, и ее модель безопасности отличается. Хранилище организовано в отдельные корзины S3 для каждой среды и/или классов активов, защищая каждую корзину соответствующими правами доступа.

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

Каждый из них получает отдельный сегмент S3.

Управление секретами приложений

В AWS есть зашифрованное хранилище параметров AWS Systems Manager или AWS Secrets Manager , которые представляют собой управляемые службы «ключ-значение», предназначенные для безопасного хранения секретов (подробнее можно узнать в Linux Academy и 1Strategy).

AWS управляет базовыми ключами шифрования и выполняет шифрование/дешифрование. К самим секретам могут применяться политики разрешений на чтение и запись на основе префиксов ключей как для инфраструктуры, так и для пользователей (серверов и разработчиков соответственно).

SSH-доступ к серверу

SSH-доступ к серверам в полностью автоматизированной и неизменной среде вообще не нужен. Журналы можно извлекать и отправлять в специальные службы ведения журналов, мониторинг также переносится в специальную службу мониторинга. Тем не менее, время от времени может потребоваться доступ по SSH для проверки конфигурации и отладки.

Чтобы ограничить поверхность атаки серверов, порт SSH не подвергается воздействию общедоступной сети. Доступ к серверам осуществляется через хост-бастион, выделенную машину, обеспечивающую внешний доступ по SSH, дополнительно защищенную за счет внесения в белый список только разрешенного диапазона IP-адресов на брандмауэре. Доступ контролируется путем развертывания открытых SSH-ключей пользователей в соответствующих ящиках (вход с паролем отключен). Такая установка предлагает довольно устойчивые ворота для злоумышленников.

Доступ к базе данных

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

Аналогичный подход можно использовать, используя ту же инфраструктуру узла-бастиона с туннелированием SSH. Нужен двойной SSH-туннель, один к хосту-бастиону, а через него еще один к серверу, имеющему доступ к БД (хост-бастион не имеет доступа к серверу БД). Через этот второй туннель теперь доступно соединение клиентской машины пользователя с сервером базы данных.

Обзор концепций масштабируемости AWS

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

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

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

Amazon Elastic Compute Cloud (EC2)

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

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

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

Сервис реляционных баз данных Amazon (RDS)

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

В следующей итерации, когда появился движок MySQL версии 5.7, инфраструктура была обновлена ​​до сервиса Amazon Aurora MySQL . Несмотря на то, что Aurora полностью управляема, она не является автоматически масштабируемым решением. Он предлагает автоматическое масштабирование хранилища, избегая проблем с планированием емкости. Но архитектору решения по-прежнему необходимо выбрать размер вычислительного экземпляра.

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

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

Управляемые сервисы AWS

Помимо этих двух компонентов, остальная часть системы выигрывает от механизмов автоматического масштабирования полностью управляемых сервисов AWS. Это Elastic Load Balancing (ELB), Amazon Simple Queue Service (SQS), хранилище объектов Amazon S3, функции AWS Lambda и Amazon Simple Notification Service (SNS), где от архитектора не требуется особых усилий по масштабированию.

Изменяемая и неизменяемая инфраструктура

Мы признаем два подхода к работе с инфраструктурой серверов: изменяемая инфраструктура, в которой серверы устанавливаются и постоянно обновляются и модифицируются на месте; и неизменяемая инфраструктура, в которой серверы никогда не изменяются после предоставления, а любые изменения конфигурации или обновления серверов обрабатываются путем предоставления новых серверов из общего образа или сценария установки, заменяя старые.

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

Дополнительные сведения об изменяемой и неизменяемой инфраструктуре можно найти в блоге HashiCorp.

Обзор архитектуры

Технически LEVELS — это мобильное приложение и веб-приложение с серверной частью REST API и некоторыми фоновыми службами — довольно типичное приложение в настоящее время. В связи с этим была предложена и настроена следующая инфраструктура:

Изоляция виртуальной сети — Amazon VPC

Диаграмма визуализирует структуру одной среды в ее VPC. Другие среды имеют ту же структуру (с балансировщиком нагрузки приложений (ALB) и кластером Amazon Aurora, общими для непроизводственных сред в их VPC, но сетевые настройки точно такие же).

VPC настраивается для четырех зон доступности в регионе AWS для обеспечения отказоустойчивости. Подсети и группы безопасности со списками контроля доступа к сети позволяют удовлетворить требования безопасности и контроля доступа.

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

Вычисления

LEVELS запускает традиционный REST API с некоторыми фоновыми рабочими процессами для логики приложения, происходящей в фоновом режиме. Оба они работают как динамические группы простых инстансов EC2, полностью автоматизированных с помощью Auto Scaling Groups. Управляемый сервис Amazon SQS используется для распределения фоновых задач (заданий), что позволяет избежать необходимости запуска, обслуживания и масштабирования собственного сервера MQ.

Есть также некоторые служебные задачи, не имеющие общей бизнес-логики с остальной частью приложения, например обработка изображений. Такие типы задач очень хорошо выполняются на AWS Lambda , поскольку Lambdas обладают неограниченной горизонтальной масштабируемостью и предлагают непревзойденную параллельную обработку по сравнению с рабочими серверами.

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

Балансировка нагрузки может быть достигнута вручную с помощью Nginx или HAProxy, но выбор Amazon Elastic Load Balancing (ELB) дает дополнительные преимущества, поскольку инфраструктура балансировки нагрузки автоматически масштабируется, обладает высокой доступностью и отказоустойчивостью.

Используется разновидность Application Load Balancer (ALB) ELB, в которой используется маршрутизация уровня HTTP, доступная в балансировщике нагрузки. Новые экземпляры, добавленные в парк, автоматически регистрируются в ALB с помощью механизмов платформы AWS. ALB также постоянно отслеживает доступность экземпляров. Он может отменять регистрацию и прекращать работу неработоспособных экземпляров, запуская автоматическое масштабирование для замены их новыми. Благодаря этому взаимодействию между ними достигается автоматическое восстановление флота EC2.

Хранилище данных приложений

Хранилище данных приложения представляет собой кластер Amazon Aurora MySQL , состоящий из главного экземпляра и нескольких экземпляров реплик чтения. В случае сбоя главного экземпляра одна из реплик чтения автоматически становится новым главным экземпляром. Сконфигурированный таким образом, он удовлетворяет требуемому требованию отказоустойчивости.

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

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

Хранение и обслуживание активов

LEVELS принимает загруженный пользователями контент, который необходимо сохранить. Хранилище объектов Amazon S3 вполне предсказуемо является сервисом, который позаботится об этой задаче. Существуют также активы приложения (элементы пользовательского интерфейса — изображения, значки, шрифты), которые необходимо сделать доступными для клиентского приложения, чтобы они также сохранялись в S3. Предлагая автоматическое резервное копирование загруженных данных посредством репликации их внутреннего хранилища, S3 по умолчанию обеспечивает надежность данных.

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

Наконец, веб-приложение, работающее в браузере, также представляет собой набор статических ресурсов — инфраструктура сборки Continuous Integration компилирует код JavaScript и также сохраняет каждую сборку в S3.

После безопасного хранения всех этих ресурсов в S3 их можно обслуживать напрямую, поскольку S3 предоставляет общедоступный HTTP-интерфейс, или через CDN Amazon CloudFront . CloudFront делает ресурсы географически распределенными, уменьшая задержку для конечных пользователей, а также включает поддержку HTTPS для обслуживания статических ресурсов.

Предоставление инфраструктуры и управление ею

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

Инструменты

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

Одним из таких инструментов является AWS CloudFormation , разработанный и поддерживаемый AWS. Еще одним из них является Terraform от HashiCorp — немного более гибкий выбор, предлагающий несколько поставщиков платформ, но здесь он интересен в основном из-за философии неизменного подхода к инфраструктуре Terraform. В соответствии с тем, как работает инфраструктура LEVELS, Terraform вместе с Packer для предоставления базовых образов AMI оказались отличным выбором.

Инфраструктурная документация

Дополнительным преимуществом инструмента автоматизации является то, что он не требует подробной документации по инфраструктуре, которая рано или поздно устаревает. Парадигма инструмента подготовки «Инфраструктура как код» (IaC) дублируется как документация, что позволяет всегда быть в курсе фактической инфраструктуры. Тогда достаточно иметь обзор высокого уровня, который с меньшей вероятностью будет изменен и относительно легко поддерживать с возможными изменениями, задокументированными на стороне.

Последние мысли

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

Что касается безопасности, AWS Cloud хранит все данные и все ресурсы в частной сети внутри одного и того же облака. Никакие конфиденциальные данные никогда не требуются для перемещения по общедоступной сети. Внешний доступ предоставляется с детальными разрешениями для доверенных систем поддержки (CI/CD, внешний мониторинг или оповещение), ограничивая область доступа только ресурсами, необходимыми для их роли во всей системе.

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

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

Дальнейшее чтение в блоге Toptal Engineering:

• Делайте домашнее задание: 7 советов по экзамену на сертифицированного архитектора решений AWS
• Terraform против CloudFormation: подробное руководство
• Ведение журнала SSH и управление сеансами с помощью AWS SSM
• Работа с поддержкой TypeScript и Jest: учебное пособие по AWS SAM