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