Мне нужно иметь возможность делиться загруженным пользователем контентом на нескольких серверах приложений EC2. Я рассмотрел rsync, смонтированный NFS и S3 как возможные варианты обмена этими данными почти в реальном времени. Загруженные и загруженные пользовательские файлы почти всегда имеют размер от 1 до 10 МБ. К некоторым обращаются часто, а к некоторым только один раз, а затем удаляются.
Мой новейший подход предполагает запуск экземпляра EC2 строго как файлового сервера, отдельно от серверов приложений. С помощью этой опции, чтобы пользователь мог загрузить файл, он подключается к одному из серверов приложений, который запрашивает в базе данных данные о файле, который они хотят загрузить. Затем пользователю предлагается загрузить, что подключает его к файловому серверу для загрузки.
Я чувствую, что этот вариант будет быстрее, чем другие мои варианты. Единственный недостаток, который я вижу, это то, что я не могу автоматически масштабировать файловые серверы вверх / вниз. Однако я могу увеличить масштаб и создать столбец в базе данных, в котором указано, на каком файловом сервере находится файл.
Это хороший подход или я что-то упускаю? Кроме того, что является хорошим способом определить, сколько одновременных загрузок / загрузок может происходить на файловом сервере на основе спецификаций сервера и с файлами размером от 1 до 10 МБ, или это лучше всего определить при нагрузочном тестировании?
Также с точки зрения масштабирования, будет ли проблема, если один конкретный файл, расположенный всего на одном файловом сервере, станет чрезвычайно популярным? Решит ли эту проблему использование CDN?
Вы хотите спроектировать свои EC2 так, чтобы на них не было никаких уникальных данных, думайте о них просто как о вычислительных машинах.
У вас есть несколько вариантов.
Масштабируемый и надежный сервис для хранения и извлечения файлов. Он плохо работает как файловая система, поэтому, если вы много читаете и записываете, это не лучшее решение.
Статические файлы (css, js, изображения) могут обслуживаться из CloudFront (который может получать данные из S3 или EC2). Это значительно повышает производительность, поэтому вы можете использовать S3 для получения файлов и их обслуживания из CloudFront.
Вы можете использовать кластер EC2 в качестве сетевого хранилища. Конечно, это немного усложняет вашу настройку и не является самым быстрым решением.
Вы можете разместить свой кэшированный мем или использовать сервис Elasticache. Это решение не является файловым хранилищем, но полезно в качестве высокопроизводительной системы кэширования объектов распределенной памяти.
S3 и CloudFront будут первым вариантом, но если вы обнаружите, что задержка неприемлема, есть и другие.
Если вам подходит один файловый сервер, вы можете перейти на масштабируемую платформу распределенного файлового сервера, например GlusterFS. Это позволяет хранить файлы в нескольких экземплярах EC2 и отображать их как одно монтирование. Вы можете использовать опцию «реплика 2», чтобы создать по 2 копии каждого файла для избыточности. Затем используйте два экземпляра в разных зонах доступности, чтобы повысить доступность. Сами файлы хранятся на любом диске с поддержкой EC2, который включает EBS с выделенным IOPS или даже временный SSD (я делал это раньше - избыточность Gluster делает непостоянство эфемерности менее серьезной проблемой, поэтому вы можете получить преимущества SSD. быстрый ввод-вывод для ваших критически важных данных).
CDN будет для вас лучшим вариантом, если использовать S3 с CloudFront. Я бы порекомендовал децентрализовать пользовательский контент с сервера (ов) приложений, сохраняя нестабильность ваших серверов при увеличении или уменьшении масштаба в вашей архитектуре, что является хорошей практикой проектирования.