Вопросы по архитектуре для Autoscale Moodle на платформе Google Cloud Platform
Мы настраиваем Moodle для нашей LMS и проектируем его для автоматического масштабирования.
Вот текущие спецификации стека:
-Приложение Moodle (приложение + данные) встроено в изображение и запущено в группу управляемых экземпляров
-Cloud SQL для базы данных (MySQL 5.7 подключен через Cloud SQL Proxy)
-Cloud Load Balancer - балансировка нагрузки HTTPS с управляемой группой экземпляров в качестве бэкэнд + привязка сеанса включена
Вопросов:
Нужен ли мне Redis / Memcached для сеанса? Или достаточно ли привязки к сеансу балансировщика нагрузки?
Я подумываю использовать Cloud Filestore для папки Data. Можно ли это порекомендовать по сравнению с другим Compute Engine?
Меня больше беспокоит кеш сеанса и кеш содержимого для будущего увеличения пользователей. Что бы вы порекомендовали добавить в смесь? Любые советы по CI / CD также будут полезны.
Ответы 2
Итак, я не могу правильно ответить на эти вопросы без дополнительной информации о вашем варианте использования. Во всяком случае, вот мой лучший :)
Насколько плохим, по вашему мнению, является принуждение некоторых пользователей к повторному входу в систему, когда машина удаляется из группы управляемых экземпляров? В связи с этим, насколько резким, по вашему мнению, будет ваш трафик? Сколько пользователей сможет обслуживать машина, прежде чем принудительно запустит автомасштабирование, и другие машины будут добавлены или удалены в / из пула (то есть, насколько динамичный, по вашему мнению, должно быть у вашего приложения)? Отвечая на эти вопросы, вы должны получить представление. Кроме того, почему бы не использовать Datastore / Firestore для пользовательских сессий? Несколько десятков миллисекунд задержки не должны нарушать ощущение резкий вашего приложения.
Cloud Filestore использует NFS, и вы можете столкнуться с некоторыми особенностями NFS. Вы будете в порядке с этим? Кроме того, какова приемлемая задержка? Насколько велики блоки данных, которые вы будете сохранять? Если они достаточно малы, вы очень чувствительны к задержкам и хотите атомарности в операциях чтения / записи, которые вы можете использовать в Cloud BigTable. Если задержка не так критична, Google Cloud Storage может сделать это за вас, но вы также потеряете атомарность.
Google Cloud CDN кажется тем, что вам нужно, при условии, что вы можете правильно настроить заголовки. Это управляемый сервис, поэтому в нем есть все, что вам нужно, и он дешев по сравнению с обслуживанием вещей из вашего приложения / Google Cloud Storage / ...
Cloud Builder кажется простым вариантом, если вы не хотите поддерживать более сложные вещи, которые еще не поддерживаются.
Пожалуйста, предоставьте более подробную информацию, чтобы я мог отредактировать и сфокусировать свой ответ.
2. Единственное, что меня сейчас беспокоит в Cloud Filestore, это крутой минимум 1 ТБ или 2,5 ТБ для базового и стандартного соответственно. Пока что мы хотели бы свести затраты к минимуму, и я не предвижу, что объем данных приложения сразу вырастет до 1 ТБ. 3. Согласитесь с этим. Однако для кеширования сеанса вы бы порекомендовали Cloud Memorystore (1 ГБ)? 4. Я посмотрю с Cloud Builder. Вы думаете, что использовать Дженкинса с ним - это излишне? Шаблоны меняются редко. Обычно добавляются курсы, которые, как я ожидаю, будут сохранены в данных приложения на сервере NFS.
есть исследование для автомасштабирования, использование хранилища памяти redis показывает большую пропускную способность сети от кеш-сервера, по сравнению с вычислительным механизмом с установленным redis. Moodle autoscaling на облачной платформе Google
Что касается данных moodle, он показывает, что вычислительный движок с NFS должен иметь достаточную производительность для сравнения, чем файловое хранилище, намного дороже, так как скорость также зависит от размера диска.
Я использую эту топологию для реализации Автоматическое масштабирование топологии Moodle на GCP
Привет, marcyb5st, спасибо за ответ. Вот мои ответы: 1. Если повторный вход произойдет по крайней мере через час бездействия, это будет приемлемо. Максимальное количество зарегистрированных пользователей - около 1000. Я предполагаю, что число одновременных пользователей не может превышать 100. Для автомасштабирования я бы основывал его на 70% загрузке ЦП (хотя я думаю, что файлы SCORM будут напрямую передаваться в Cloud SQL через GCE). Что касается Datastore / Firestore, я не хочу усложнять приложение дополнительным кодированием, поскольку это будет наше первое развертывание Moodle в компании.