Вы развернули приложение Rails на VPS или в Heroku. Трафик начинает поступать по мере интереса к сборкам вашего приложения. Далее идет вирусный. Тогда ваше приложение вылетает …
Много было обсуждено о масштабируемости или иным образом Rails. Принято считать, что из-за большого объема трафика происходит сбой не самого веб-приложения, а просто нехватка аппаратных ресурсов. Итак, какие есть варианты для масштабирования вашего приложения на VPS? А что насчет Героку? Посмотрим…
Во-первых, что Rails может помочь?
Лучший совет предполагает, что мы должны включать кэширование страниц для наших приложений Rails везде, где можем. У нас есть статья на Rubysource, которая предоставляет много информации о HTTP-кэшировании.
Суть в том, что кэширование страницы помогает с нагрузкой на сервер, потому что обычный цикл запроса / ответа проходит так:
- Запрос от клиента
- Апач передает просьбу сказать, дворняга
- Дворняга отправляет ответ Apache
- Ответ отправляется клиенту
Mongrel может обрабатывать около 20-50 запросов в секунду, что хорошо для 2 миллионов обращений в день или около того. Включив кэширование страниц, Apache может обслуживать кэшированные страницы (обычно) из общедоступного каталога нашего приложения без необходимости дальнейшего запроса к Mongrel.
Есть три варианта, которые мы можем использовать с Rails:
1. Кэширование страниц
При включенном кэшировании страниц веб-сервер (Apache или nginx) может полностью избежать стека Rails. Это будет работать только для некоторых сценариев — его нельзя использовать, например, для страниц, требующих аутентификации.
2. Кеширование действий
Кэширование действий решает проблему, упомянутую выше, отправляя запросы в стек Rails. Пакет действий, настроенный до использования фильтров, может быть запущен до обслуживания кэша. Это мощная функция, потому что это означает, что аутентификация может выполняться до того, как страница будет обслуживаться из кэшированной копии.
3. Фрагмент кеширования
Кэширование фрагментов позволяет заключать часть представления в блок кеша и обслуживать его из каждого кеша.
Например, если у вас была часть представления, содержащая список сообщений в блоге, вы хотите кэшировать этот список:
| <table> | |
| <% cache do %> | |
| <% @posts.each do |post| %> | |
| <tr> | |
| <td><strong><%= post.title %></strong></td> | |
| </tr> | |
| <tr> | |
| <td><em>Posted: <%= post.created_at.strftime(‘%a %d %B %Y — %H:%M’) %></em></td> | |
| </tr> | |
| <tr> | |
| <td><%= post.content %>… [ <%= link_to ‘Read Post’, post %> ]</td> | |
| </tr> | |
| <% end %> | |
| <% end %> | |
| </table> |
by Также можно кэшировать несколько фрагментов, установив : action_suffix .
Рекомендуется использовать эти параметры в целом, но когда мы начнем исследовать параметры масштабирования, вы увидите, что есть и другая причина.
Масштабирование — вопросы аппаратного обеспечения
При рассмотрении вопросов масштабируемости необходимо учитывать два аспекта:
- Емкость — для достижения эффективного распределения нагрузки лучшим способом является увеличение емкости за счет добавления аппаратного обеспечения. По мере увеличения нагрузки добавление дополнительного оборудования поможет распределить нагрузку и поддерживать стабильность для конечных пользователей.
- Избыточность — в этом контексте избыточность означает, что, если сервер выходит из строя, он не разрушает всю систему. Вместо этого он просто уменьшает емкость на сумму, которую он добавил в первую очередь.
Такое сочетание регулировки емкости и избыточности обычно достигается за счет балансировки нагрузки .
Масштабирование приложения, развернутого на VPS
Итак, вы развернули свое приложение на виртуальном частном сервере (VPS). Что-то вроде Linode или Webbynode, например. Параметры масштабирования доступны для большинства услуг VPS-хостинга. У Linode есть полный набор опций балансировки нагрузки, поэтому давайте посмотрим, что можно сделать.
Начиная
Linode использует так называемые NodeBalancers, которые прослушивают общедоступный IP-адрес для входящих соединений. Вы можете применять наборы правил, которые используются для настройки того, какой внутренний узел (их может быть больше одного) будет отправлено соединение. NodeBalancers также может оценивать входящий запрос и принимать решения на основе его содержимого.
Есть одно осложнение, хотя. Если ваше приложение использует сеансы, они должны быть направлены на узел, на котором выполняется приложение. Linode NodeBalancers решают эту проблему, потому что их можно настроить так, чтобы один и тот же клиент приземлялся на одном и том же внутреннем узле.
Важная оговорка
Большинство VPS-хостингов предлагают некоторую форму масштабирования, возможно, не до такой же глубины, как Linode, но она будет там. Будьте осторожны с ценой, хотя. Например, для работы NodeBalancers у вас есть статический IP-адрес. Это включает добавление, по общему признанию, небольшой стоимости к вашему ежемесячному счету Настоящим хитом является применение NodeBalancer. Чтобы включить его, нужно дополнительно 19,95 долларов в месяц. Это сверх вашей обычной ежемесячной платы.
Шаги для настройки NodeBalancer
Предполагая, что вы приобрели статический IP-адрес и добавили NodeBalancer в свою учетную запись, теперь вы можете настроить его. Основные шаги:
- Вы выбираете порт для Balancer для прослушивания. Порт 80 прекрасно подходит для регулярного веб-трафика.
- На экране конфигурации есть несколько параметров, например, привязка сеанса к решению проблемы сеанса, описанной ранее. Вы также можете установить интервал проверки, который определяет количество секунд между проверками работоспособности. Эти параметры четко объяснены на экране конфигурации.
- Затем вы указываете внутреннему узлу частный IP-адрес вашего веб-сервера.
- После того, как все обновится, вы сможете перейти на IP-адрес NodeBalancer и увидеть свое веб-приложение, как и раньше.
Это процедура для добавления одного дополнительного внутреннего узла. Если вашему приложению нужно больше, вам нужно будет купить другое и следовать той же процедуре.
Вы можете заметить, что это может очень дорого обойтись, но также стоит отметить, что вам потребуется серьезный трафик, чтобы подумать о покупке дополнительных NodeBalancers.
Как насчет Heroku?
Heroku предлагает несколько хороших вариантов масштабирования, которые можно определить как два варианта:
- Веб-динос
- Рабочий динам
Веб-dynos позволяет вашему приложению обрабатывать больше одновременных HTTP-запросов, в то время как рабочие dynos позволяют обрабатывать больше заданий одновременно. Они также предлагают различные решения для баз данных, чтобы помочь с кэшированием запросов тоже. Если вы испытываете замедление, связанное с обработкой данных, добавление большего количества веб-dyno может усугубить проблему. Оптимизация запросов будет первым шагом к решению этой проблемы.
Вы можете применить параметры масштабирования из командной строки. Например, чтобы применить веб-dynos, вы просто делаете:
heroku ps:scale web=2 Или применять рабочие и веб-процессы:
heroku ps:scale web=2 worker=1
ценообразование
Это тоже довольно быстро становится дорогим. Например, если у вас есть 2 веб-динамо и 1 работник, это будет стоить вам 71 доллар в месяц. Добавьте кэш базы данных 400 Мб, и это еще 50 долларов в месяц.
Опять же, эту стоимость можно считать минимальной, если у вас есть производственное веб-приложение, которое хорошо выполняет свои задачи.
В заключение…
Если вы развернули на VPS, масштабирование вашего приложения стало проще с помощью менеджера или панели управления администратора, которую обычно предоставляют службы VPS. Это действительно вопрос добавления дополнительных ресурсов и их оплаты. Параметры конфигурации хорошо объяснены (конечно, в случае с Линоде), поэтому увеличение ресурсов — это не техническая проблема, которая когда-то была.
Облачные сервисы, такие как Heroku и Webbynode, также упрощают масштабирование (или уменьшение) в зависимости от того, что говорит вам ваш мониторинг трафика. Таким образом, единственная задача сейчас, это привлечь этот трафик!