Я новичок в облачной архитектуре, но имею приличный опыт разработки приложений. Прямо сейчас я работаю над тем, чтобы сделать большой вычислительный конвейер более доступным для 5-10 пользователей через веб-приложение, и настраиваю все это в AWS.
Моя текущая реализация представляет собой легковесное веб-приложение React, которое использует два API и бэкэнд MySQL, позволяющий пользователям ставить задания в очередь с параметрами и получать доступ к конечным результатам через веб-приложение или из электронных писем, отправляемых пользователям после завершения выполнения.
В середине этого конвейера находится зависимость от фирменного программного обеспечения, которому нужна очень мощная машина для вычисления этих шагов (64 ГБ ОЗУ, 16 ядер, 1 ТБ HDD) и которое может работать до 1,5 дней только для этого одного шага. Это мое самое узкое место всего конвейера.
Чтобы максимально сэкономить на расходах, я пытаюсь сделать узкое место/часть обслуживания масштабируемым/экономически эффективным, имея несколько «агентов» экземпляра EC2, которые можно включать, выполнять шаги, отправлять электронное письмо, записывать данные в базу данных веб-приложения, а затем останавливать экземпляр с помощью лямбда-функций AWS, которые будут запускаться действием из веб-приложения.
Я планирую разместить один экземпляр EC2 для веб-приложения, 2 API и сервер MySQL, поскольку параллелизм/масштабируемость в этой части очень малы. У меня также будет еще 1-3 экземпляра для служб узкого места, чтобы разделить параллельные запуски от 5-10 пользователей, что может позволить до 3 запусков тяжелого шага одновременно.
Поскольку службы узкого места требуют похожих файлов для запуска программ, а входные данные для этих шагов иногда могут быть размером файлов 150 ГБ, я думаю использовать хранилище EFS или S3 для хранения входных данных, чтобы мне нужно было беспокоиться только о передаче входных файлов в одно место, которое можно было бы использовать совместно с экземплярами EC2, и мне не нужно было бы обеспечивать их запуск для выполнения шага передачи. Это одна ручная часть, которую я также не придумал, как лучше автоматизировать, поскольку размеры файлов очень велики.
У меня такие вопросы: звучит ли моя настройка разумно, и видите ли вы какие-либо пробелы в моих идеях реализации? В настоящее время я использую хранилище EBS для экземпляров служб, но я хочу минимизировать входные местоположения для передач/обслуживания 150 ГБ. Я также не уверен в разнице между S3 и EFS, поскольку они оба, похоже, монтируются в несколько экземпляров, но какой из них мне следует использовать? И имеет ли смысл хранить веб-приложение, API и базу данных на одном экземпляре EC2, если мне нужно, чтобы сервисные могли записывать в базу данных после того, как они будут выполнены? Этот экземпляр будет включен все время.
Спасибо за помощь и простите меня, если я сказал что-то наивное.
решение1
Ваша настройка звучит разумно. Я бы посоветовал вам рассмотреть возможность использования API Gateway для «хостинга» вашего API и подумать, подойдет ли он вам. Вы также можете рассмотреть возможность размещения высоконагруженных экземпляров EC2 в Autoscaling Group и заставить свой элемент управления Lambda взаимодействовать с ним, а не напрямую с экземплярами.
S3 и EFS — это разные решения для хранения данных. S3 — это объектное хранилище, а EFS — файловое хранилище. S3 не совсем монтируется, хотя может быть представлено так, как будто это происходит через разные утилиты. Будь топравильныйИспользование S3 или EFS зависит от того, как вы используете файлы, находящиеся там.
Для вашей базы данных вы можете рассмотреть возможность перехода на RDS, возможно, с использованием класса экземпляра burstable или одного из вариантов serverless. Но это будет зависеть от вашего бюджета и варианта использования.
решение2
В целом в облаке лучше попробовать использовать сервисы, а не серверы. Вам нужно следить за стоимостью, но это может сделать решения более надежными, быстрыми и более соответствующими.
У меня есть пара мыслей по поводу вашей рабочей нагрузки:
- Можно ли использовать оркестратор вроде AWS Step functions, вызывающий множество лямбда-функций AWS для выполнения вычислений? Я отмечаю, что лямбда, вероятно, является самым дорогим вычислительным временем на AWS, так что, возможно, не идеально. При правильно установленных ограничениях и подходящей рабочей нагрузке, возможно, вы могли бы запустить 10 000 лямбда-функций и выполнить работу параллельно за 15 минут.
- Вместо EFS / S3 как насчет создания золотого образа EC2 / AMI, а затем для каждого задания запускать точечный / динамический экземпляр EC2, достаточно большой, чтобы выполнить обработку для этого одного задания, закрывающегося по его завершении? Lambda, возможно, могла бы организовать задание на основе событий какого-либо типа? Это позволило бы избежать расходов на передачу данных - хотя не уверен, взимается ли они с EBS / S3 или нет. Точечные вычисления довольно дешевы, и если вы правильно выберете свой регион / AZ / размер экземпляра, прерывания должны быть редкими. Прерванные экземпляры закрываются, а том EBS сохраняется, поэтому это будет работать лучше, если ваше задание регулярно записывается на диск и может быть перезапущено.
Я бы, наверное, также потратил некоторое время на оптимизацию этой огромной работы.