Добрый день!
Коллеги в комментариях дали верные советы: финальный ответ даст только нагрузочное тестирование, и SeaweedFS действительно стоит рассмотреть в будущем за его производительность.
Но если говорить конкретно про вашу предложенную архитектуру с MinIO, то в ней есть несколько неочевидных, но критически важных мест, которые могут привести к потере данных при такой нагрузке.
Если кратко: в текущем виде конфигурация, скорее всего, не выдержит, но ее можно доработать, чтобы она справилась.
Первое слабое место: Сеть и Балансировщик
Вы абсолютно правы, что вынесли балансировщик отдельно. Но при 60 000 одновременных клиентов он станет вашей главной точкой отказа.
Проблема: Один IPv4-адрес на балансировщике может обслуживать не более ~65 000 одновременных TCP-соединений (это теоретический предел количества портов). Ваши 60 000 клиентов подходят к этому пределу вплотную. Любые дополнительные служебные соединения или небольшая погрешность приведут к тому, что новые клиенты просто не смогут подключиться.
Решение: Вам необходимо как минимум два балансировщика (например, два HAProxy на отдельных VM), каждый со своим собственным публичным IP-адресом. На уровне DNS вы настраиваете Round Robin для вашего домена S3, чтобы клиенты случайным образом распределялись между этими двумя IP. Это разделит нагрузку и решит проблему с исчерпанием портов.
Второе слабое место: CPU и Erasure Coding
Вы выбрали Erasure Coding (EC) 8+4. Это отличный выбор для долгосрочного и экономичного хранения данных. Но для вашей задачи — короткий, интенсивный всплеск записи — это худший из возможных вариантов.
Проблема: Erasure Coding — это очень ресурсоемкая по CPU операция. При записи каждого объекта MinIO придется "на лету" вычислять 4 блока четности, что создаст колоссальную, избыточную нагрузку на процессоры и станет главным виновником замедления всего процесса.
Решение: Откажитесь от EC. Учитывая, что вам не нужно долго хранить данные, а важна только надежность записи, вам идеально подойдет стандартная репликация. А еще лучше и дешевле, учитывая вашу задачу — запустить каждый из 4-х инстансов MinIO в standalone-режиме. Риск отказа одного из четырех серверов именно в короткий промежуток загрузки минимален, а производительность и экономия будут максимальными.
Ответы на ваши прямые вопросы:
Выдержит ли такая конфигурация MinIO 60 000 одновременных клиентов?
С предложенными мной изменениями (2+ балансировщика и отключение Erasure Coding) — да, выдержит.
Есть ли ограничение на количество одновременных соединений/транзакций в MinIO?
Само приложение MinIO не имеет жесткого лимита, но оно всегда упирается в ограничения операционной системы (количество файловых дескрипторов, лимиты TCP-стека) и железа. Главное ограничение, как я описал выше, — это количество доступных портов на одном IP-адресе вашего балансировщика.
Есть ли известные узкие места в такой архитектуре?
Да. Это балансировщик (решается несколькими IP) и CPU (решается отключением Erasure Coding). Также критически важна надежность самих клиентов: ваш sender-service на Go обязательно должен иметь встроенную логику повторных попыток (retry) с экспоненциальной задержкой. Если PUT-запрос не удался, клиент должен попробовать еще раз через секунду, потом через три, и так далее. Это и есть ваша главная гарантия от потери файлов.
Рекомендуемая архитектура для вашей задачи на мой взгляд:
Балансировщики: 2 x HAProxy на отдельных VM с двумя публичными IP. DNS Round Robin.
Ноды MinIO: 4 ноды, как вы и планировали, но каждый инстанс MinIO запущен в режиме standalone (без EC).
Диски: 12 SSD — отличный выбор для быстрой обработки метаданных.
Клиент sender-service: Обязательная реализация логики retry.
И, как правильно заметили коллеги из комментариев, финальный ответ даст только нагрузочное тестирование.
