У меня есть сайт обмена ссылками (вроде reddit). Сейчас он размещен на хостинге godaddy deluxe shared. Планирую перенести его на aws.
Я видел вебинар aws по масштабированию до 10 миллионов пользователей. Но по сути там просто говорится, что за пределами определенного предела вы не сможете масштабироваться вертикально, поэтому выбирайте горизонтальное масштабирование с самого начала.
Мне не нужно поддерживать 10 миллионов пользователей. Предположим, что мне нужно поддерживать 100 000 пользователей ежедневно. Максимум, на сайте будет 1000 одновременных пользователей.
Вариант использования
- Пользователи будут размещать ссылки на сайт. Только один из 1000 пользователей будет размещать ссылки.
- Большинство пользователей просто ищут на сайте ссылки, читают описание и т. д.
- Ежедневно на сайте будет появляться около 5000 комментариев.
- Это в основном текстовый сайт.
- На сайте очень мало изображений, кроме аватара пользователя и баннера, оба ограничены 2 МБ. Изображения хранятся в БД.
- Присутствуют обычные функции форума, такие как регистрация, вход в систему, учетная запись и т. д.
Планируемая архитектура
- 1 экземпляр EC2
- 1 экземпляр RDS
- 1 Маршрут 53 Зона
- 1 Эластичный ip
- 1 s3 (только для резервного копирования)
Я планирую масштабировать с помощью этого простого метода - начать с t2.micro, по мере роста базы пользователей просто обновить экземпляр ec2. То же самое касается экземпляров RDS.
Я знаю, что 1 EC2 или RDS делает его единой точкой отказа. Если что-то из этого сломается, я планирую завершить этот экземпляр и запустить идентичный из образа/резервной копии. Меня устроит, если сайт будет отключен на 1 час каждые 30 дней.
Пожалуйста, помните, что мне некому помочь, и это сольная работа. Я могу найти кого-то, кто поможет на стороне aws, если это коснется пользователей.
- Могу ли я таким образом поддерживать 100 000 пользователей?
- На каких контрольных точках мне следует выполнить обновление до следующего экземпляра Ec2 до 100 000 пользователей/1000 одновременных пользователей? (Например, до 5 одновременных пользователей — t2.micro/db.t2.micro, до 40 одновременных пользователей — тип экземпляра EC2 2/тип экземпляра Rds 2 и т. д.)
- Есть ли что-то еще, что я не учел/должен учесть, прежде чем приступить к реализации этого плана?
решение1
Очень сложно сказать, будет ли веб-приложение обрабатывать X клиентов на конкретной системе. Это сильно зависит от многих факторов, включая то, как было написано приложение, используемые фреймворки и т. д.
Лучшим вариантом было бы найти что-то, что вы можете использовать для бенчмаркинга/симуляции использования приложения. Поскольку у вас уже, похоже, запущено веб-приложение, вы можете легко настроить любой размер экземпляра ec2 на короткое время, запустить несколько тестов, а затем выключить его.
Возможность горизонтального масштабирования обеспечит гораздо лучший путь для обработки роста в будущем. Что произойдет, если сайт будет испытывать трудности на более крупных экземплярах или вам нужно будет масштабироваться за пределы 100 000? Вы также можете обнаружить, что простое перемещение на более крупные экземпляры, скорее всего, не вернет линейного увеличения производительности.
Одна вещь, которая действительно выделяется -
Изображения хранятся в базе данных.
Храните изображения и все остальное, для обработки чего вам не нужны серверы приложений, где-нибудь еще. Поскольку вы уже используете стек AWS, S3 — очевидное место для изображений и других статических данных. Не тратьте время сервера приложений на статические ресурсы.