Рекомендации по архитектуре AWS: несколько инстансов EC2 с общей базой данных/файловой системой с динамическим запуском и остановкой

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

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

В середине этого конвейера находится зависимость от проприетарного программного обеспечения, которому требуется очень здоровенная машина для вычисления этих шагов (64 ГБ ОЗУ, 16 ядер, 1 ТБ жесткий диск), и которое может работать до 1,5 дней только для этого одного шага. Это мое самое большое узкое место во всем трубопроводе.

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

Я планирую разместить один экземпляр EC2 для веб-приложения, 2 API и сервер MySQL, поскольку параллелизм/масштабируемость в этой части очень малы. У меня также будет еще 1-3 экземпляра для узких мест, чтобы совместно использовать одновременные запуски от 5-10 пользователей, что может позволить одновременно выполнять до 3 запусков тяжелого шага.

Поскольку узким местам сервисов требуются аналогичные файлы для запуска программ, а входные данные для этих шагов иногда могут иметь размер файла 150 ГБ, я думаю об использовании хранилища EFS или S3 для хранения входных данных, так что мне нужно беспокоиться только о передаче входных данных. файлы в одно место, которое можно было бы совместно использовать между инстансами EC2, и мне не нужно было бы гарантировать, что они запущены для выполнения шага передачи. Это одна ручная часть, которую я также не нашел, как сделать ее более автоматизированной, поскольку размеры файлов очень велики.

Мои вопросы: звучит ли моя установка разумно, и видите ли вы какие-либо пробелы в моих идеях реализации? В настоящее время я использую хранилище EBS для экземпляров службы, но я хочу свести к минимуму места ввода для передачи/обслуживания 150 ГБ. Я также не уверен в разнице между S3 и EFS, поскольку они оба кажутся монтируемыми в несколько экземпляров, но какой из них мне следует использовать? И имеет ли смысл хранить веб-приложение, API и базу данных в одном экземпляре EC2, если мне нужны служебные, способные записывать в базу данных после их завершения? Этот экземпляр будет включен все время.

Спасибо за вашу помощь и простите меня, если я сказал что-то наивное.

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

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

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

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

У меня есть пара мыслей о вашей рабочей нагрузке:

• Можно ли использовать оркестратор, например функции AWS Step, вызывающие множество лямбда-функций AWS для выполнения вычислений? Я отмечаю, что лямбда, вероятно, является самым дорогим временем вычислений на AWS, поэтому, возможно, не идеально. С правильными ограничениями и подходящей рабочей нагрузкой, возможно, вы могли бы запустить 10 000 лямбда-выражений и выполнить работу параллельно за 15 минут.
• Вместо EFS / S3, как насчет создания золотого образа EC2 / AMI, а затем для каждого задания, запускающего спотовый / динамический экземпляр EC2, достаточно большой, чтобы выполнить обработку для этого одного задания, которое будет закрыто, когда оно будет выполнено? Lambda может организовать работу на основе событий какого-то типа? Это позволит избежать платы за передачу данных — хотя не уверен, взимается ли она с EBS / S3 или нет. Спотовые вычисления довольно дешевы, и если вы правильно выберете регион/зону доступности/размер инстанса, перебои будут происходить редко. Прерванные экземпляры закрываются, а том EBS сохраняется, поэтому это будет работать лучше, если ваше задание будет регулярно записываться на диск и может быть перезапущено.

Я бы, наверное, также потратил некоторое время на оптимизацию этой огромной работы.