Простой способ защиты от HTTP DDoS — включить syn-cookies и заблокировать подонков. Но что делать если атакует 5к-10к хостов да еще и с динамическими IP? Тут нам на помощь придет frontend-backend архитектура c промежуточным кэшированием! Почему с промежуточным кэшированием? А потому что в моем случае от шквала запросов от frontend'а backend умирал унося за собой систему.

Данная статья достаточно подробно показывает, как можно перейти на разработку сайтов Друпал с серьезной стрессоустойчивостью и возможностью обрабатывать большой трафик.

Это мой первый опыт подобной настройки, но как будет далее видно из статистики достаточно удачно справляющийся со своей основной задачей — ускорением работы сайта. Интересно будет услышать и увидеть настройки, дополнительные материалы от всех кто сталкивался с подобными задачами, так как в рунете пока еще мало свободной и качественной информации по этой теме относительно системы Друпал.

Довольно долго для разработки я использовал связку Drupal + Nginx с настройками сервера по умолчанию:

server {
listen 62.xxx.xx.xx:80;
server_name mysite.com www.mysite.com;
rewrite>^(/manager/.*)$>https://$host$1>permanent;
location ~* ^/(webstat/|awstats|webmail/|myadmin/|manimg/) {
proxy_pass 62.xxx.xx.xx:8080;
proxy_redirect mysite.com:8080/ /;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
}
location / {
proxy_pass mysite.com:8080;
proxy_redirect mysite.com:8080/ /;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
}
location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar)$ {
root /home/pathto/drupal613;
access_log /home/httpd-logs/mysite.com.access.log;
error_page 404 = @fallback;
}
location @fallback {
proxy_pass 62.xxx.xx.xx:8080;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
}
}

Английский разработчик Эван Лейт (Ewan Leith) опубликовал пошаговую инструкцию, как поднять виртуальный микросервер на Amazon, Linode или другом облачном хостинге, который сможет крутить блог WordPress и выдерживать 10 миллионов хитов в сутки (отчёт составлен с помощью Blitz.io), при этом будет стоить всего пятнадцать долларов в месяц.

Инструкция описывает, как последовательно установить Ubuntu 11.10 (Oneiric), MySQL, PHP с PHP FPM, APC и модулем MySQL, Nginx с конфигурацией для WordPress, ну и сам WordPress. После этого сервер работает ещё довольно медленно, но всё меняет установка W3 Total Cache и Varnish, которые вместе с Nginx способны сотворить настоящее чудо.

Выполнить действия из инструкции способен даже человек, не являющийся техническим специалистом.

В ответ на этот этот топик решил написать свои соображения по тому, как стоит строить кластер для высоко нагруженных проектов.

Топик очень хорош. Очень приятно почитать подобное с точки зрения разработчика.

По роду деятельности я занимаюсь предоставлением хостинг услуг. 90% моей работы составляет настройка и администрирование серверов для тяжеленных магазинов, написанных на движке magento. Поэтому производительности уделяю очень много внимания.

За время работы у меня выработалось некое виденье идеального кластера для тяжеловесных проектов. Это:

— 2 WEB сервера

— 1 DB сервер

— 1 балансировщик нагрузки.

Совсем не ново, но соображения связаны именно с балансировщиком нагрузки

Достаточно давно мне на глаза попались следующие статьи по этой тематике:

• nginx, memcached и SSI
• Nginx + Memcached + SSI — кеширование страниц и блоков (partials)
• Кеширование страниц — ускоряем сайт в 100 раз (Varnish + ESI)

С PHP я дружу, поэтому попробовал примеры и убедился, что это работает. Но всё это имело «фатальные недостатки» :) — PHP, а я фанат Python и по работе занимаюсь в основном бэкендом. Серьёзно говоря, применить на практике это не представлялось возможным.

Однако в начале года поступило предложение поучаствовать в одном амбициозном проекте, изначально подразумевающий HiLoad и прочие плюшки из этой оперы. Пока составлялись бизнес-планы, искались инвесторы и тому подобные дела, я решил изучит вопросы которые на мой взгляд пригодились бы в этой работе, в том числе и вопросы кэширования.

В первую очередь было реализовано черновое решение для моего любимого фрэймворка Flask использующее для кэширования стек Varnish+ESI. Это заработало и даже показало неплохие результаты. Позже пришло понимание, что возможно Varnish «лишний игрок» и всё тоже и даже гибче можно получить на связке Nginx+Memcached+SSI. Был сделан и этот вариант, по производительности особых отличий замечено не было, но последний показался более гибким и управляемым.

Тот проект не вырулил даже на взлетную полосу, или вырулил но без меня. Подумав, я решил «причесать код» и выложить его в OpenSource и на суд общественности.

Сегодня хотим рассказать о том, как строили систему, к которой сейчас обращается более 1 млн. уникальных посетителей в день (без учёта запросов к API), о тонкостях архитектуры, а также о тех граблях и подводных камнях, с которыми пришлось столкнуться. Поехали…

В данной статье я расскажу о том, как я заставил свой блог на WordPress летать за счёт грамотного кэширования, сжатия и другой оптимизации серверной и клиентской сторон. На момент написания статьи характеристики VDS следующие:

CPU: 1 x 2GHz
HDD: 10Gb
RAM: 512Mb
OS: Debian 8 x64

Схема работы системы выглядит следующим образом:

В своей предыдущей статье по оптимизации сайта на WordPress я рассказал об очень эффективном подходе к оптимизации за счёт кэширования страниц. В результате чего для незалогиненных пользователей время ожидания страницы клиентом (исключая время на установление TLS-сессии) сократилось с 820 мс до 30 мс (этот и все последующие замеры проводились с сервера, расположенного в том же городе, что и мой VDS), что, согласитесь, является отличным показателем. Однако, для залогиненных пользователей генерация страницы происходила по-прежнему долго — в среднем 770 мс на сервере. В этой части я расскажу о том, как я сократил это время до 65 мс, при этом полностью сохранив работоспособность пользовательского функционала.

Целью этой и предыдущей статей является моё желание показать возможность оптимизации сайтов не только на WordPress, а вообще любого веб-приложения. Поэтому я использую такое количество инструментов, и так детально разбираю их конфигурацию. Если же Вам просто нужно ускорить WordPress — установите плагин WP Super Cache. Если Вас, как и меня, интересуют технологии, позволяющие оптимизировать любой сайт, а также Вам интересно, что стоит учитывать при разработке веб-приложений, рассчитанных на высокие нагрузки — прошу под кат, но только после прочтения первой части — дорабатывать я буду ту же систему.

В предыдущих частях мы свами подготовили сервер к использованию контейнеров:

→ Часть 1. Установка CoreOS
→ Часть 2. Базовая настройка и настройка безопасности SSH

В этой части мы научимся работать с контейнерами и разворачивать стек приложений за считанные секунды. Но вначале я бы хотел сделать небольшое отступление на поступившие комментарии и замечания.

20 Июля в Киевском офисе Magento прошло открытое мероприятие под названием Magento meetup «Dare to Share», которое могли посетить и в котором могли принять участие любые желающие кому интересна платформа Magento 2 и тема электронной коммерции (eCommerce).

В данном отчете публикуются видео докладов прозвучавших на мероприятии, а также принимаются заявки на выступление в следующем ивенте.

1. Игорь Миняйло, Magento (@iminyaylo on ) — Magento Community Engineering
2. Макс Пронько, The Irish Store (@max_pronko on ) — Автоматизация релизов для Magento 2. Опыт компании The Irish Store
3. Вячеслав Кравчук, Atwix (@slkra on ) — Story of a Transformation (Укр.)
4. Андрей Кравец, Forbytes / Gymgrossisten (@Winfle on ) — Dynamic caching of personalised data in Real Life (Укр.)
5. Александр Козырь, Magecom (@kozyr1av on ) — SOLID-ное программирование на Magento 2

Тезисы докладов можно прочитать под Катом

Drupal 8 – это самый свежий релиз CMS Drupal. Varnish – это HTTP reverse proxy cache, надстройка над вебприложением, которая позволяет кешировать HTTP ответы в ОЗУ сервера.

Когда мы ставим Varnish перед Drupal’ом (либо любым другим вебприложением), схема обработки входящего HTTP запроса трансформируется следующим образом.



Еще во времена Drupal 6 и 7 с помощью Varnish’а было очень удобно кешировать статические ресурсы (рисунки, CSS, JavaScript файлы). Но были пробемы с кешированием HTML страниц – не существовало удобного механизма выборочной инвалидации кеша. Оставалось только либо сознательно отдавать устаревший кеш, либо полностью очищать кеш в Varnish при каких-либо изменениях в Drupal. Оба подхода имели свои недостатки.

After hitting the keyboard buttons for the past 20 minutes, as if he was typing for his life, ghostinushanka turns to me with a half-mad look in his eyes and a sly smile, “Dude, I think I got it.

Look at this” — as he points to one of the characters on screen — “I bet my red hat that if we add what I’ve just sent you here” — as he points to another place in the code — “there will be no error anymore.”
Slightly puzzled and tired I modify the sed expression we’ve been figuring out for some time now, save the file and run systemctl varnish reload. Error message gone…

“Those emails I’ve exchanged with the candidate,” my colleague continues, as his smile changes to a wide and genuine grin, “It suddenly struck me that this is the very same exact problem!”

ghostinushanka, молотив по кнопкам в течение предыдущих 20 минут, как если бы от этого зависела его жизнь, поворачивается ко мне с полу-диким выражением в глазах и хитрой ухмылкой — "Чувак, я кажется понял."

"Посмотри вот сюда," — говорит, показывая на один из символов на экране — "Спорим на мою красную шляпу, что если мы добавим вот сюда то, что я тебе только что послал" — показывая на другой участок кода — "ошибка уже не будет выводиться."

Немного озадаченный и уставший, я изменяю sed выражение, над которым мы какое-то время уже работали, сохраняю файл и запускаю systemctl varnish reload. Сообщение об ошибке исчезло...

"Мейлы, которыми я обменивался с кандидатом," продолжил мой коллега, в то время как его ухмылка перерастает в неподдельную улыбку полную радости, "До меня вдруг дошло что это точно такая же проблема!"