Як ми налаштували наше серверне обладнання так, щоб використовувати на 60% менше обчислювальних потужностей і обробляти більше конкуруючих запитів, без якого-небудь простою або змін в коді.

Два роки тому в One Mighty Roar ми помітили, що один з неосновних проектів, існуючий в компанії з перших днів, генерує значну частину трафіку, незважаючи на те, що в нього ніхто не заглядав вже сто років. Кілька місяців ми витрачали близько 20% нашого часу, які незабаром вилилися в 120% часу, перенастраивая You Rather, ми переробляли все, починаючи з самого заснування, створювали API і писали відразу додатки під iOS і під Android.

У підсумку, You Rather показав чудові результати, отримав серйозне визнання спільноти і став чудовим проектом, предметом гордості всієї команди One Mighty Roar. Але, як більшість неосновних проектів, він втратив свою позицію в списку пріоритетів коли відкрилися інші нові можливості і перспективи.

Наприкінці цього літа нашою метою стало дати проекту You Rather друге дихання. Першим кроком стала відмова від застарілого HTTP-сервера Apache на користь Nginx. Ми використовуємо Nginx для 99% наших проектів протягом більше декількох років і ніколи не шкодували про це (сервер Nginx написаний російським розробником – Ігорем Сисоєвим – прим. перекладача). Однак, більшу частину нашої роботи з Nginx становив досвід написання файлів конфігурації для нових сайтів і серверів, і ми жодного разу не переписували старі конфігураційні файли для сайтів, що знаходяться в продакшені.

В кінцевому підсумку, лише за вечір ми перенесли сайт з більш ніж 400 активними пользователеями, які переглядали більше 1000 сторінок в секунду з Apache на Nginx, причому не було ні секунди простою сайту.

Збираючи пил

Що б у читача було уявлення про ситуації: ми – фанати AWS. You Rather використовує кожну крупицю стека AWS від EC2 до EBS, до Route 53, до S3. Для того що б отримати тестове оточення в якому ми змогли б вести розробку, ми скопіювали наш поточний AMI з сайту You Rather і підняли новий інстанси, на якому ми могли волю пробувати наші трюки і хакі.

Проста команда yum install nginx дозволила отримати готовий працюючий Nginx на нашому сервері з CentOS без зайвої витрати часу. Крок один: завершено.

Для початку ми підсунули системі нашу стандартну, перевірену конфігурацію для Nginx:

server {
# Port declaration
listen 80 default_server;
listen ssl 443;
# Server name and aliases
server_name nginx-test.yourather.com;
# Root directory and default index
root /var/www/path/of/yourather/src/;
# Catch-all
location / {
try_files $uri $uri/ /index.php?$args;
}
# Pass the PHP scripts to the PHP-FPM socket
location ~ .php$ {
include fastcgi_params;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
# PHP-FPM (unix socket)
fastcgi_pass unix:/tmp/php5-fpm.sock;
}
}

І ось, майже все… просто запрацювало. Виявилося, що ми спочатку зробили більшу частину роботи, встановлюючи AMI з працюючими Apache і PHP, переключення і підняття на Nginx не викликало проблем. Крок два: завершено.

Поліпшення продуктивності

Nginx має кілька очевидних переваг порівняно з Apache коли справа стосується шару сервера додатків, однак Nginx – не основна причина поліпшення продуктивності сайту You Rather. Щоб побачити, чому це так, давайте з’ясуємо, що ж тут по-справжньому важливо, і що відрізняє саме You Rather.

Чим реально хороший Nginx – так це тим, що він не обробляє файли «.htaccess». Ці файли покликані полегшувати установку на хостинг разом з іншими проектами або на невиділені сервери, і обхід файлових деректорий в пошуку таких файлів відбувається при кожному запиті, що стає дорого в плані ресурсів. Nginx, навпаки, завантажує всі конфіги під час першого старту, і все, приємної роботи.

Іншим місцем, де був великий потенціал для поліпшення продуктивності було взаємодію нашого веб-сервера і PHP. Наша тодішня реалізація You Rather використовувала mod_php разом з Apache. Хоча первісна установка і налаштування Apache і mod_php була швидкою і простою, великий недолік цього підходу у тому, що PHP створює процесу на кожен запит. Вибір на користь PHP-FPM замість mod_php дав нам значний приріст продуктивності.

Тоді як mod_php інтерпретував PHP як частина процесу Apache і швидко пожирав багато ресурсів CPU і пам’яті, PHP-FPM може бути дуже тонко настроєний і дати величезну перевагу в продуктивності. PHP-FPM використовує процеси PHP, грамотно запускає і зупиняє процеси, Unix сокети, використовують гранульований менеджмент процесів. Все це дозволило нам повністю грамотно налаштувати використання ресурсів на сервері. Тепер, поверх всіх цих налаштувань ми можемо змінювати конфігурацію для Nginx, не зачіпаючи PHP-FPM і навпаки – це не призведе до поломки ні того, ні іншого.

У якості останньої контрольної заходи для поліпшення продуктивності PHP ми додали opcode кеш. Протестувавши Zend OPCache і APC ми з’ясували, що OPCCache краще по всіх параметрах: підвищує швидкість обробки PHP і в цілому зменшує споживання пам’яті.

Крок три: завершено.

Навантажувальне тестування

Один приємний бонус, який ми отримали в результаті трафіку з You Rather – це тестування наших додатків під високим навантаженням. Кожен божий день ми відчуваємо великий стрибкоподібне зростання трафіку посилання в соцмережах, з-за агрегаторів (див. Слэшдот-ефект (англ. Slashdot effect) — потужний сплеск відвідуваності веб-сайту, зазвичай невеликого, після того, як посилання на цей ресурс з’являлася на стрічці новин популярного мережевого видання чи блогу.) або з-за функ в онлайн-магазині додатків. Ми активно використовуємо для тестування роботи під навантаженням дві тулзы: Siege і ab. Тут ми здебільшого використовували Siege.

Так як Nginx обслуговував наш сайт прямо в инстансе де ми вели розробку, настав час навантажити сервер щоб побачити, як він впорається з обробкою трафіку. За допомогою Siege ми змогли побачити який рівень навантаження може обробити одиничний інстанси. Величезна перевага Siege — це здатність навантажити эндпоинт конкуруючими сполуками, а це чудово підходить для симуляції реальної роботи You Rather. Це легко досягається виконанням команди:

siege -t 1M -c 20 http://nginx-test.yourather.com/

Ми эмулировали роботу 20 конкуруючих користувачів (з 20), які надсилали запити на сайт в нашому инстансе в режимі нон-стоп протягом хвилини (-t 1M). Siege надає чудову аналітику як під час виконання тестування так і за його результатами. Все виглядало відмінно з самого початку тестування. Завантаженість сервера була набагато менше, ніж на старому Apache AMI і час відгуку було в цілому менше.

Ми продовжили грати з налаштуваннями Siege, варіюючи кількість конкуруючих підключень від 10 до 100 і більше (порада: не використовуйте більше 75 підключень, все зламається), навантажували різні эндпоинты, наприклад сторінку профілю користувача, сторінку незвичайного питання і навіть сторінку 404.

Ми порівняли результати роботи Siege для инстанса з Nginx з результатами для поточного сайту, що працює під Apache у контрольному инстансе. Якщо коротко: інстанси з Nginx виконував на 100% більше транзакцій, час відгуку на кожну транзакцію було на 50% менше. І навіть краще: ми побачили найвищі показники на сервер Nginx під час тестування. Сервер обробляв запити like a boss, злегка отъедая CPU, обробляючи обрушивающийся потік сполук. Nginx, безсумнівно, давав сайту так необхідне прискорення.

Вихід у світ (Going Live)

Користуючись всім пишністю, що з себе представляє AWS ми вже мали балансировщики навантаження для нашого сайту, так само як і групи для автоматичного масштабування, і правила для відключення неробочих инстансов і підняття нових у разі необхідності. Ми всіма можливими способами намагаємося підтримувати сайт доступним як можна більше часу, і підняття нових инстансов під високим навантаженням може стати дорогою операцією.

Так як ми створили новий AMI для розгортання нового сайту, настав час настроїти авто-масштабовану групу, щоб підняти новий інстанси з нового AMI. Використовуючи AWS CLI все, що ми зробили – це встановили групу для підняття нового инстанса з нового AMI. Далі, ми виставили в якості номери бажаного инстанса для групи безпечний номер, який, як ми знали, не повинен був привести до падіння сайту. Цим самим ми оставлили простір для одночасного співіснування инстансов Apache і Nginx і балансування «пліч о пліч».

as-set-desired-capacity yr-production —desired-capacity 4 —honor-cooldown

Починаючи з цього моменту, ми повільно відключали старі инстансы на Apache один за іншим вручну, дозволяючи групі авто-масштабування піднімати нові инстансы на Nginx натомість відключаються. При цьому, згідно з Google Analytics, ми щосекунди мали тисячі переглядів сторінок і викликів API в реальному часі, включаючи нові сервера Nginx.

Зрештою, жодного сервера Apache не залишилося під навантаженням, і ми почали зменшувати кількість бажаних инстансов в групі. Почали c 4 і потім до 3… 2… Ми, можливо, могли б залишити тільки одну серверну стійку, але для власного заспокоєння залишили дві.

Через тиждень ми зробили якусь подобу пост-мортем аналізу і подивилися на показники. Вважаю, що перехід на Nginx відбувся:

Як ми зробили це: мільйони переглядів сторінок на день, на 60% менше серверних ресурсів

Наше число инстансов, яке раніше варіювалося, тепер більш-менш постійно, і так вже протягом декількох тижнів:

Як ми зробили це: мільйони переглядів сторінок на день, на 60% менше серверних ресурсів

Тепер ми обробляємо мільйони переглядів сторінок і викликів API за допомогою двох инстансов на Nginx, при цьому даунтайм 0% протягом повних трьох тижнів. Пробач, Apache, шляху назад немає.

Переклад статті «How We Did It: Millions of Daily Pageviews, 60% Less Server Resources» був підготовлений дружною командою проекту Сайтостроение від А до Я.