Назад | Перейти на главную страницу

Облачная архитектура AWS

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

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

Я планировал использовать AWS beanstalk для веб-приложения, но для приложения обработки я не уверен, какую стратегию использовать. Я думал об использовании очереди (SQS) для отправки заданий по обработке и помещения приложения обработки в группу автоматического масштабирования EC2.

Файлы большие (несколько ГБ), а обработка сильно ограничена вводом-выводом, поэтому перед обработкой файлы будут скопированы с s3 на локальный SSD на машине обработки.

Другое соображение:

Вопрос: это хорошая архитектура? Какие-то важные детали мне не хватает? Есть какие-нибудь советы о том, как начать работу с AWS?

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

Высокая масштабируемость без сервера

Было бы использовать API-шлюз и настроить функцию Lambda, чтобы фактически выполнять тяжелую работу, это означает, что когда вы ничего не обрабатываете, вы не тратите деньги на запуск системы, которая ничего не делает.

Вы можете прочитать об этом здесь: https://docs.aws.amazon.com/apigateway/latest/developerguide/getting-started-with-lambda-integration.html

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

После этого ваша Lambda сможет обрабатывать загрузку по мере необходимости.

Рентабельность для постоянной обработки нескольких штук за раз

Будет настроен блок EC2, который читает из очереди SQS и обрабатывает их один за другим, и вы настраиваете свое приложение, которое после загрузки в S3 помещается в очередь SQS.

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

Это означает, что если загрузка выполняется нечасто, возможно, вы используете EC2, который ничего не делает. В зависимости от размера вашего экземпляра EC2 вы можете запускать свое обрабатывающее приложение несколько раз. Например, если это был PHP, а вы выбрали 4-ядерный EC2, вы могли бы запустить PHP-скрипт 4 раза параллельно в этом окне.

Вопрос по базе данных

Первый вариант устраняет необходимость обработки базы данных заданий, поскольку они поступают через API-шлюз. но по-прежнему может подключиться к RDS, если вам это нужно, через библиотеки NodeJS Lambda. Второй вариант также устраняет необходимость в подключении системы выгрузки, поскольку она может использовать очередь SQS, но при необходимости вы можете подключиться к RDS так же, как и к любому другому приложению.

Если вы хотите использовать базу данных для обработки всего этого вместо очереди SQS или у вас есть другая причина для использования базы данных, вы можете настроить RDS в VPC по умолчанию и использовать группы безопасности для прав доступа, это не масштабируется. (IP-адреса)

Вы можете использовать второй вариант и просто не использовать очередь SQS.

Если вам нужно запустить RDS в нескольких зонах доступности в одном регионе, вы можете сделать это, настроив RDS во всех 3 зонах доступности, настроив несколько зон доступности, тогда любой экземпляр EC2 в том же регионе сможет получить к нему доступ (это дает вам высокая доступность).

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

Ноты

Если вам нужна мультирегиональная мульти-зона доступности для сверхвысокой доступности, я настоятельно рекомендую перед созданием RDS использовать экземпляры T2.nano, на которых запущен кастомный дистрибутив Linux Amazons в EC2, для тестирования пинга в регионах через пиринг, который может быть довольно сложным в настройке. все пиринги и убедитесь, что они работают, исправьте процесс для 2 регионов, затем добавьте другие регионы один за другим, убедившись, что все остальные регионы могут пинговать новый регион.