есть ли лучший способ обрабатывать более 100-200 файлов в секунду?
У меня есть проблема, которая в настоящее время сталкивается с ограничениями облачных вычислений с точки зрения IOPS и CPU. Идея состоит в том, чтобы внедрить эти системы в долгосрочной перспективе, но я думаю, что ее можно спроектировать лучше, чтобы лучше использовать доступные ресурсы.
Приложение A записывает в файл от 100 до 200+ файлов в секунду. система. Эта файловая система раньше была удаленно смонтированной файловой системой, но теперь она пишется локально, чтобы получить максимально возможное количество операций ввода-вывода в секунду. В настоящее время мы записываем данные в блочное хранилище со скоростью около 200–300 МБ / с.
Приложение B удаленно монтирует эту файловую систему, анализирует эти файлы и помещает данные в базу данных MySQL. После выполнения этой функции он удаляет файл. Это приложение очень загружает процессор. Мы работаем над перезаписью на более эффективном, многопоточном языке.
Мы работаем над тем, чтобы сделать синтаксические анализаторы более эффективными, но пока нам нужно найти способ улучшить весь процесс записи / чтения.
Если У меня более 10 серверов синтаксического анализа, работающих с файлами, это вызывает достаточно ожидания ввода-вывода на сервере приложения A, чтобы опрокинуть его. Если у нас есть центральный файловый сервер, он не может обрабатывать IOPS, что приводит к чрезвычайно высокой средней нагрузке.
Есть ли лучшие варианты, чем запись / чтение из файловой системы?
Я ограничен предложениями облачных продуктов. прямо сейчас и масштабирование нашего нынешнего решения там, где мы должны быть, обойдется нам более чем в 1 миллион долларов в год.
Вместо записи во множество файлов, возможно, вы могли бы отправить эти порции данных одному процессу (или кластеру), который последовательно записывает их в какой-то архивный файл. Может быть, tar может подойти. Запись 300 МБ / с в один файл не представляет большой нагрузки даже для жесткого диска.
Также обратите внимание на наличие чего-то другого, кроме удаленного монтирования файла. Большое количество пользователей сетевой файловой системы для чтения и записи предполагает проблемы с блокировкой, особенно на узлах каталогов. Возможно, вам было бы лучше, если бы какой-нибудь исполнитель заданий на исходной машине собирал файлы и отправлял их в какой-то серверный процесс. Например. HTTP PUT прямо к процессам, которые записывают в базу данных.
Просмотрите предложения очереди заданий. Например. RabbitMQ. Похоже, вы делаете что-то подходящее для такой архитектуры.
Похоже на вопрос экзамена по AWS Architect Pro. Кажется, довольно просто решить проблемы масштаба и цены. Есть много вариантов, вот первый, который пришел мне в голову.
Если бы вы сказали, какое облако вы используете, вы, вероятно, получили бы лучший совет. Большинство облаков предлагают аналогичные функции, так что вы, вероятно, будете в порядке, какую бы из них вы ни использовали. Вы можете использовать AWS S3 и SQS независимо от того, в каком облаке вы работаете, но вам следует использовать встроенные в ваше облако функции, чтобы снизить расходы. Пропускная способность может быть дорогостоящей, а задержка может иметь значение.
- Храните файлы записывающего приложения в частной корзине S3. S3 будет масштабироваться настолько, насколько вам нужно. Будьте осторожны с именами файлов - если вы сделаете это неправильно, вы сами узкое место. Прочтите это .
- Поместите сообщение в очередь сообщений SQS с указанием местоположения файла на S3, плюс любые другие команды
- Настройте базу данных RDS, если вам нужна база данных.
- Создайте группу спотовых экземпляров с автоматическим масштабированием, которая читает из очереди и обрабатывает файл. Масштабируйте его по размеру очереди, который является встроенной метрикой. Если ваше приложение не является многопоточным и вы можете запускать только один экземпляр на сервере, используйте много небольших экземпляров.
- У вас может быть вторая группа экземпляров с автоматическим масштабированием по запросу, которая масштабируется при более высоких порогах, чем группа спотовых экземпляров. Это, вероятно, немного сложно / неудобно, и я не уверен на 100%, как это сделать.
Используя спотовые экземпляры и S3, а не экземпляры по запросу и файловые системы, я ожидаю, что ваш счет должен значительно снизиться ]. Чтобы использовать SQS и S3, потребуется немного времени на разработку, но не так много, API хороши, и есть много примеров.