Кілька банальних рецептів успішного веб-проекту

1. Кілька банальних рецептів успішного веб-
проекту
Андрій Корнілов
Тернопіль
Березень 2013

2. Про мене
Зараз
Technical Lead @Rebbix, Lviv
VNU Vacature media (Netherlands/Belgium)
В минулому
bitternet.ua, stelex.com (General Electric), markplaats.nl
(eBay classified group), lofty.com, знову markplaats.nl (eBay
classified group), modnakasta.ua
Інтереси
php, python, software engineering stuff

3. Про презентацію
Коротенький огляд специфіки проектів з
високою відвідуваністю та корисних підходів,
які можуть допомогти таким проектам бути
успішнішими

4. Про презентацію
Коротенький огляд специфіки проектів з
високою відвідуваністю та корисних підходів,
які можуть допомогти таким проектам бути
успішнішими
Хоча, можуть і не допомогти - якщо проблеми
лежать за межами software engineering

5. Про дивну назву
На практиці всі підходи та архітектурні рішення
для вебу статичні.
Для більшості проблем давно знайдено
прийнятні рішення.
Девелоперу залишається лише визначити з
проблемою якого саме виду він зіткнувся і
вибрати рішення, яке дозволить вирішити цю
проблему

6. Про дивну назву
При чому рішення це, як правило, не
міститиме ніякого рокет-сайнс

7. ?!???>>!!!...

8. Високо навантажений проект
Таким чином поняття high loaded проекту коже може
трактувати на власний розсуд :-)
В побутовому сенсі - це ресурс, який має високу (wut?)
відвідуваність
Як правило, high loaded проект, з технічної точки зору,
це апаратно-програмний комплекс, який складається з
багатьох взаємодіючих підсистем - тобто розподілена
система, при чому ця система перебуває під впливом
високо конкурентного доступу.

9. Високо навантажений проект
Для ресурсів, які активно використовуються (іншими
словами - високо навантажених), нема поняття "це мало
імовірно, для цього потрібен надзвичайний збіг
обставин, тому це ніколи не станеться"
Підходи до обробки запитів в високо-навантажених
проектах співпадають з підходами теорії масового
обслуговування (звичайні черги, аеропортні черги,
паралельне обслуговування)

10. Часткова коректність
В високо навантаженій системі з багатьма компонентами в
даний момент, швидше за все, є компонент з яким в даний
момент щось не так - не працює реплікація, певний
відсоток даних є не коректним тощо.
Шукайте можливість бути частково доступними -
повертайте якісь результати, навіть якшо ваша система
дає частковий збій.
● Поверніть хоч якісь результати пошуку, якщо не
можете повернути детальні.
● Якщо не можете отримати підтвердження оплати в
банку, позначте замовлення як частково підтверджене і
переходьте до наступного кроку.

11. Часткова цілісність
Маленький чіт - стан системи такий,
яким його бачить користувач.
Якщо користувач не може побачити порушення цілісності
даних - її нема.
Приклад. Якщо ви написали коментар до сторінки і,
практично в той самий момент, хтось її відкрив - не
важливо, щоб він побачив ваш коментар, важливо щоб ви
його побачили. Таке саме можна сказати, наприклад, про
відображення резервації товару в каталозі інтернет
магазину. Часто саме це забезпечує кешування (але не
завжди кеш мість не актуальні дані - залежить від політики
інвалідації)

12. Успішність / Не успішність
Успішність чи не успішність проекту (з точки зору
інженера) залежить від того, які фактори ризику можуть
впливати на цей проект і чи ці фактори (в достатній мірі)
зкомпенсовані

13. Деякі важливі фактори ризику
● людські фактори - загальний рівень команди, помилки
в силу психо-фізичного стану
● технічні фактори
○ адекватна інфраструктура навколо проекту -
документація, тести, метрики коду
○ складність проекту - чим складніша система тим
більша імовірність помилки
○ технічні несподіванки
● фактори залежності і контролю
○ залежність від коду, який ви не контролюєте
○ залежність від систем, які ви не контролюєте

14. Людський фактор
Всі люди - люди*
І, в силу цього, час від часу, роблять помилки. Через хибні
припущення на основі не достатньої інформації. При
написанні коду. При виконанні певних дій (особливо
рутинних)
* (с) моя дружина

15. Людський фактор
Запобіжні підходи
● детальна (і головне - актуальна) документація
● тести (юніт, функціональні etc)
● використання певних практик (кодревью, парне
програмування)
● формальні процедури (регламенти, git-flow)
● автоматизація дій (білд, деплоймент)

16. Технічні фактори
З технічною складністю дозволяє боротися декомпозиція
системи на простіші компоненти
Типові компоненти:
● медіа сервери (media, assets)
● бекінг сервіси (db, cache, queues, search)
● апп-сервери
● бекграунд воркери
Про технічні несподіванки і фактори залежності
поговоримо в одному з наступних розділів презентації -
twelve factor application

17. Shared nothing
Shared nothing архітектура це концепція розподіленого
компьютінгу в які кожна нода є незалежною і
самодостатньою (в плані обчислювальних активностей).
Або більш конкретно - ноди не використовують спільно
пам'ять чи дисковий розділ.
Концепція зараз широко використовується, в основному, в
вебі (хоча започаткована була в середині 80-х для баз
даних) і практично безлімітно скейлиться (що довів
Google). Для веб-додатків стан при цьому зберігають
спеціально призначені backing сервіси
Для баз даних SN знаходить відображення в концепції
шардінгу.

18. Feature flags
Feature flags - реальний спосіб зменшення ризиків при
розгортанні нової функціональності в умовах великого
навантаження
Цю концепцію часто помилково асоціюють лише з A/B
тестуванням. Але, поряд з цим, використання флагів
дозволяє запускати нову функціональність (часто з
непрогнозованим performans ефектом) лише для певної
групи чи відсотку користувачів.
Таким чином можна навіть проводити поступову міграцію
користувачів з однієї платформи на іншу.

19. "Правильні інструменти"
Використовуйте правильні інструменти для кожної із своїх
задач
● З пошуком у великому масиві даних краще справиться
спеціалізований сервер пошуку (SOLR, ElasticSearch,
Sphinx) ніж реляційна база даних
● В якості медіа сервера краще виступить легкий веб
сервер ніж apache
● Мільйон інших прикладів...

20. Метрики
Єдиний спосіб переконатися, що робота зроблена добре і
взагалі все іде добре (в плані тенденцій)
● метрики коду - sonar
● системний моніторинг - munin, zabbix, new relic
● метрики бізнесу (транзакції певного типу) - new relic,
graphite, google analytics
● rum (performance monitoring) - new relic
І навіть передбачити майбутні проблеми
(Навчіться прогнозувати запас ресурсів)

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

22. 12-Factors App
12-factor app це набір правил, які дозволяють:
● Використовувати декларативні формати
конфігурування;
● Мати чіткий "контракт" з операційною системою, за
рахунок чого досягається максимальна портабельність
між середовищами, легке розгортання в клауд;
● Мінімізувати відмінності між розробницьким і
продакшен середовищем;
● Дозволяє масштабувати проект без суттєвих змін
інструментів, архітектури коду і процесу розробки.

23. 12-Factors App
Ця методологія може бути застосована до веб додатків,
написаних з використанням будь-якої мови
програмування, і з використанням будь-якої комбінації
backing services (база даних, черга, кеш тощо)

24. 12-Factors App
Єдина codebase, яка знаходить в системі
контролю версій -
багато регулярних розгортань (deploys)

25. 12-Factors App
● Якщо система складається з кількох
codebases, це не додаток – це розподілена
система. Кожен компонент розподіленої
системи це окремий додаток і має
інтивідуально задовольянти вимогам 12-
factor app.
● Кілька додатків, які використовують
спільний код порушують ці принципи.
Спільний код має бути виділено в
бібліотеку, яка має бути включена в систему
як будь-яка інша залежність.

26. 12-Factors App
Розгортання (deploy) це примірник додатка,
який виконується. Це може бути продакшен
сайт, один чи кілька тестових сайтів, сайт в
робочому середовищі розробника.
Код має бути спільним для всіх розготань, за
виключенням того, що розгорнуті версії коду
можуть різнитися.

27. 12-Factors App
● Додаток ніколи не має робити припущень про систему,
на якій буде виконуватись з точки зору своїх
залежностей, декларує залежності явно і в повній мірі
через dependency declaration manifest.
● Уникайте випадків, коли залежності одного додатку
можуть впливати на інший додаток або на інше
розгортання цього самого додатку. Для цого
використовуйте ізоляцію залежностей.
● Це правило має бути чинним для будь-яких типів
середовищ

28. 12-Factors App
В ruby для декларації залежностей використовуються
Gemfile, для ізоляції залежностей - bundle exec.
В python для декларації залежностей використовуються
pip + requirements.txt, virtualenv - для ізоляції залежностей.
В java-sctipt - bower.
В php - Composer

29. 12-Factors App

30. 12-Factors App
Розробники маніфесту про 12-factor додатки також
наполягають на тому, що не варто покладатися на
наявність в системі будь-яких залежностей. Наприклад
ImageMagick чи curl. Аргументуючи це тим, що не можливо
гарантувати їх наявності взагалі чи наявності сумісної
версії.
На мою думку, такий підхід є перебільшенням, адже
такого роду залежності можна задовільняти з допомогою
таких інструментів як Chef і Puppet (хоча, мушу визнати,
при цьому опускаються вимоги ізоляції залежностей)

31. 12-Factors App
Граф залежностей і конфлікти залежностей
Досить часто залежності можуть перетворитися в коштар.
Особливо, якщо у ваших залежностей є свої, не відомі
вам, і , при цьому, все це знаходиться за межами ваших
можливостей контролю.
Якщо бібліотека, яку ви маєте намір використати,
реалізує якусь просту функціональність - це привід
задуматися, чи потрібна вашому проекту зайва
залежність. Не ставайте залежними від когось, без
достатніх підстав.

32. 12-Factors App
Зберігайте конфігурацію в змінних оточення
Конфігурація додатку це будь-що, що відрізняє одне
розгортання від іншого (за винятком версії коду). Вона
може включати:
● Параметри конекту до backing services (бази даних,
Memcached)
● Параметри конекту до зовнішніх сервісів (Amazon S3,
Twitter API)
● Ім'я хоста тощо

33. 12-Factors App
● Інколи конфігурацію включають в код у вигляді
констант - це не припустимо з точки зору додатку,
який відповідає вимогам 12-Factors App. Адже
конфігурація це єдине, що має відрізняти різні
розгортання додатку. І в жодному разі не код.
● Інший підхід - зберігати конфігурацію в окремих
файлах, за медами коду теж не вітається, оскільки
легко можна припустися помилки і додати їх в
репозиторій, або складно забезпечити ізоляцію
конфігурацій
● Групування конфігурацій по типам середовища -
досить легко може перетворитися в некерований
процес.

34. 12-Factors App
Чітко розділяйте етапи зборки, розгортання і виконання
коду

35. 12-Factors App
Збірка це етап на якому створюється певний артефакт-
набір коду, залежностей, асетів (при потребі компілюється
бінарний файл)
Розгортання об'єднує артефакт, ориманий на етапі
зборки, з відповідним конфігами. Результат - сутність,
готова до виконання в певному середовищі
Виконання - запуск коду в середовищі у вигляді процесу
або набору процесів.
Заборонено вносити зміни в код, який виконується

36. 12-Factors App
Завжди виконуйте свій додаток в середовищі як один
(частіше всього на девелоперському середовищі) або
кілька (частіше всього на продакшен) stateless процесів.
Будь-які дані, які вимагають збереження, мають
зберігатися на stateful backing сервісі - найчастіше в базі
даних.
Локальна пам'ять або файлова система можуть
розцінюватися виключно як короткотерміновий кеш
(наприклад для зкомпільованих темплейтів, завантажених
файлів), при цьому ніколи не робиться припущення що
дані в цьому кеші завжди доступні для наступного
реквеста - адже він може потрапити на інший сервер чи
процес.

37. 12-Factors App
Масштабування через процеси - в twelve-
factor app архітектурі процеси це
основоположний елемент.
З використанням цієї простої концепції
програміст може забезпечити масштабування
в широких межах поділяючи певні типи
навантаження між відповідними процесами.
Наприклад одні типи процесів відповідають за
обробку http запитів, інший тип відповідає за
виконання "довгих" задач в бекграунді.

38. 12-Factors App
Таким чином, щоб проскейлити певний тип навантаження
(у відповідності до концепції shared nothing) треба просто
добавити ще процеси певного типу

39. 12-Factors App
Crash only design
Дизайн процесів має передбачати випадок
того, що процес може раптово припинити сво
є виконання - при цьому всі ресурси, які він
використовував мають бути звільнені, дані з
бекінг сервісів в жодному разі не має бути
пошкоджено, для воркер процесів - не
виконана задача має бути повернута на
виконання іншим процесом

40. 12-Factors App
Розглядайте логи як потік подій
Логи додають візуалізацію поведінки додатка. При
цьому, додаток, розроблений у відповідності з
правилами 12-factor не займаються
обслуговуванням інфраструктури логів (не
відкривають спеціальний лог файл тощо) вони
просто пишуть потік подій в stdout.
Під час локальної розробки програміст бачить цей
потік в терміналі і таким чином спостерігає за
поведінкою додатка.

41. 12-Factors App
На стейджінг і продакшен середовищах кожен
такий потік перехоплюється середовищем,
агрегується з іншими потоками і може бути
відісланий для подальшого зберігання чи
перегляду. Ці подальші дії жодним чином не
відомі самому додатку

42. 12-Factors App
Детальне логування success кейсів - надмірне
Error кейси потрібно логувати якомога
детальніше

43. 12-Factors App
Ваші середовища для розробки, тестування та
продакшен мають бути максимально
уніфіковані
Це дозволить уникнути технічних
несподіванок, про які ми починали говорити
раніше

44. 12-Factors App
Розриви в часі: Розробник може писати код
дні, тижні і навіть місяці перед тим, як код
потрапить на продакшен.
Розриви у відповідальності: Розробник
пише код, DevOps інженер розгортає його.
Розриви в інструментах: Для розробки
використовується Nginx+SQLite+OS X, а на
продакшені - Apache+MySQL+Linux.

45. 12-Factors App
Сучасні інструменти менеджменту пакетів
(homebrew, apt, yum), декларативні
інструменти провіженінгу (Chef і Puppet) в
сукупності з легкими система управління
віртуальними середовищами (Vagrant, kvm)
дозволяють розробнику запускати локально
середовище, яке максимально близьке до
продакшен

46. Адміністративні задачі
Виконуйте адміністративні задачі як специфічний
процес додатка
Адміністративні задачі це задачі, які необхідно виконувати
поряд з основною - обслуговування web запитів. Такі, як:
● міграція схеми бази даних (manage.py syncdb в Django,
rake db:migrate в Rails)
● виконання REPL shell
● виконання одноразових скриптів
Адміністративні функції мають виконуватися з усіма тими
самими обмеженнями, що і звичайний 12-factor додаток - з
тими самим кодом, залежностями, ізоляцією.
Адміністративний код має включатися в код додатку для
уникнення проблем синхронізації версій коду.

47. Посилання
● The Twelve-Factor App - http://www.12factor.net/
● http://devopsreactions.tumblr.com/
● http://www.perfplanet.com/
● http://www.vagrantup.com/

48. Q&A

49. Дякую за увагу!
Андрій Корнілов
Копанія:
Rebbix
Email:
andriy.kornilov@gmail.com