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