Влітку традиційно знижується і купівельна активність, і інтенсивність зміни інфраструктури веб-проектів, говорить Капітан Очевидність. Просто тому, що навіть айтішники, трапляється, ходять у відпустку. І CТО теж. Тим важче тим, хто залишається на посаді, але зараз не про це: можливо, саме тому літо — найкращий період для того, щоб не поспішаючи обміркувати існуючу схему резервування та скласти план її поліпшення. І в цьому вам буде корисний досвід Єгора Андрєєва з , Про який він розповів на конференції .
При будівництві резервних майданчиків, при резервуванні є кілька пасток, які можна потрапити. А траплятися в них зовсім не можна. І губить нас у всьому цьому, як і багато в чому іншому, перфекціонізм і… ліньки. Ми намагаємося зробити все-все ідеально, а ідеально робити не потрібно! Потрібно робити лише певні речі, але зробити їх правильно, довести остаточно, щоб вони нормально працювали.
Failover — це якась така весела фанова штука «щоб було»; це річ, яка має зробити рівно одне — зменшити час простою, щоб сервіс, компанія втрачала менше грошей. І у всіх методах резервування я пропоную думати у такому контексті: де гроші?
Перша пастка: коли ми будуємо великі надійні системи і займаємося резервуванням - ми зменшуємо кількість аварій. Це страшна помилка. Коли ми займаємося резервуванням, кількість аварій ми швидше за все підвищуємо. І якщо ми зробимо все правильно, то разом ми час простою зменшимо. Аварій буде більше, але вони відбуватимуться із меншими витратами. Адже що таке резервування? - Це ускладнення системи. Будь-яке ускладнення — це погано: у нас з'являється більше гвинтиків, більше шестерень, словом, більше елементів — і, отже, вищий шанс на поломку. І вони справді розламаються. І ламатимуться частіше. Простий приклад: скажімо, у нас є сайт, з PHP, MySQL. І його терміново слід зарезервувати.
Штош(с) Беремо другий майданчик, будуємо ідентичну систему... Складність стає вдвічі більшою — у нас дві сутності. А ще ми зверху накочуємо певну логіку перенесення даних з одного майданчика на інший - тобто реплікація даних, копіювання статики і таке інше. Так ось, логіка реплікації - вона зазвичай дуже складна, і отже, сукупна складність системи може бути не в 2, а 3, 5, 10 разів більше.
Друга пастка: коли ми будуємо по-справжньому великі складні системи, ми фантазуємо, що ж хочемо отримати в результаті. Вуаля: ми хочемо отримати супернадійну систему, яка працює взагалі без простою, перемикається за півсекунди (а краще взагалі миттєво), і починаємо втілювати мрії у реальність. Але тут теж є нюанс: чим менший бажаний час перемикання, тим складнішою виходить логіка системи. Чим складніше нам доведеться робити цю логіку, тим частіше система ламатиметься. І можна потрапити в дуже неприємну ситуацію: ми всіма силами намагаємося час простою зменшити, а насправді ми все ускладнюємо, і коли щось іде не так, час простою зрештою буде більшим. Тут часто ловиш себе на думці: ось… краще б не резервували. Краще б воно одне працювало і зі зрозумілим часом простою.
Як можна із цим боротися? Треба перестати собі брехати, перестати собі лестити, що ми тут зараз будуватимемо космоліт, але адекватно розуміти, скільки проект може полежати. І під цей максимальний час ми вибиратимемо, якими, власне, методами підвищуватимемо надійність нашої системи.
Саме час для «історій із ж»… із життя, звичайно ж.
Приклад номер один
Подайте сайт-візитку трубопрокатного заводу №1 міста N. На ній написано величезними літерами — ТРУБОПРОКАТНИЙ ЗАВОД №1. Трохи нижче – слоган: «Наші труби – найкругліші труби в N». І знизу номер телефону генерального директора та його ім'я. Розуміємо, що треба резервувати — це дуже важлива штука! Починаємо розбиратися, із чого складається. Html-статика - тобто пара картинок, де генеральний, власне, за столом у лазні зі своїм партнером обговорюють якусь чергову угоду. Починаємо думати про час простою. На думку спадає: лежати там треба п'ять хвилин, не більше. І тут питання: а скільки з цього нашого сайту було продажу взагалі? Скільки? Що означає «нуль»? А то й означає: тому що всі чотири угоди за минулий рік генеральний зробив за тим самим столом, з тими ж людьми, з якими вони ходять у лазню сидять за столом. І розуміємо, що навіть якщо день полежить сайт — страшного нічого не буде.
Виходячи із вступних, є день на підняття цієї історії. Починаємо думати про схему резервування. І вибираємо ідеальну схему для резервування для даного прикладу: ми резервування не використовуємо. Ось ця вся штука піднімається будь-яким адміном за півгодини з перекурами. Поставити веб-сервер, покласти файли – все. Воно запрацює. Ні за чим не слід стежити, нічого не потрібно приділяти особливої уваги. Тобто висновок з прикладу номер один досить очевидний: сервіси, які не потрібно резервувати — резервувати не потрібно.
Приклад номер два
Блог компанії: спеціально навчені пишуть туди новини, ось ми взяли участь у такій виставці, а ось ми випустили ще новий продукт і так далі. Припустимо, це стандартний PHP з WordPress, невелика база даних та трохи статики. В голову, звичайно, знову спадає, що лежати в жодному разі не можна — «не більше п'яти хвилин!», Ось це все. Але подумаємо далі. Що робить цей блог? Туди приходять з Яндекса, з Гугла за якимись запитами, органікою. Здорово. А продаж якось взагалі з ним пов'язаний? Прозріння: не особливо. Рекламний трафік йде на основний сайт, який на іншій машині. Починаємо думати про схему резервування бложека. По-хорошому, за кілька годин його треба підняти, і до цього було б непогано підготуватися. Розумним буде взяти в іншому дата-центрі машину, на неї вкотити оточення, тобто веб-сервер, PHP, WordPress, MySQL і залишити це лежати притушеним. У момент, коли ми розуміємо, що все зламалося, потрібно зробити дві речі - розкотити дамп mysql на 50 метрів, він пролетить там за хвилину і розкотити там якусь кількість картинок з бекапу. Це теж там не бозна-скільки. Таким чином, за півгодини вся ця штука піднімається. Жодних реплікацій, або прости господи, автоматичного failover'a. Висновок: те, що ми можемо швидко розкотити з бекапу – резервувати не потрібно.
Приклад номер три, складніше
Інтернет магазин. PhP з open heart трошки підпиляний, mysql із солідною базою. Досить багато статики (адже в інтернет-магазині є красиві HD-картиночки і таке інше), Redis для сесії та Elasticsearch для пошуку. Починаємо думати про час простою. І тут, звісно, очевидно, що день безболісно інтернет-магазин валятися не може. Адже що довше він лежить, то більше грошей ми втрачаємо. Варто пришвидшитися. А наскільки? Гадаю, якщо ми годину полежимо, то ніхто не збожеволіє. Так, ми щось втратимо, але почнемо старатися — буде лише гірше. Визначаємо схему простою, допустимого на годину.
Як все це можна зарезервувати? Машина потрібна у будь-якому разі: година часу – це досить мало. Mysql: тут вже потрібна реплікація, жива реплікація, тому що за годину 100 гб у дамп, швидше за все, не увіллється. Статика, картиночки: знову ж таки, за годину 500 гб може не встигнути влитися. Отже, краще відразу картинки копіювати. Redis: ось тут цікавіше. У Redis сесії лежать просто взяти і поховати ми його не можемо. Тому що це буде не дуже добре: всі користувачі виявляться розлогі, кошики очищеними і так далі. Люди будуть змушені заново вводити свій логін та пароль, і багато народу може відколотися та покупку не завершити. Знову ж таки, конверсія впаде. З іншого боку, Redis прям один в один актуальний, з останніми користувачами, що залогінілися, напевно, теж не потрібен. І добрий компроміс - взяти Redis і відновити його з бекапу, вчорашнього, або, якщо він у вас щогодини робиться, - годинної давності. Благо відновлення його з бекапу - це копіювання одного файлу. А найцікавіша історія – це Elasticsearch. Хто колись піднімав реплікацію MySQL? Хто колись піднімав реплікацію Elasticsearch? І у кого вона згодом працювала нормально? Я до чого: бачимо в нашій системі сутність. Вона ніби корисна — але вона складна.
Складна в тому сенсі, що наші колег-інженери не мають досвіду роботи з нею. Або є негативний досвід. Або ми розуміємо, що поки що це досить нова технологія з нюансами чи вогкістю. Думаємо ... Млинець, elastic теж здоровий, його з бекапу теж довго відновлювати, що робити? Розуміємо, що elastic у нашому випадку використовується для пошуку. А як продає наш інтернет-магазин? Ідемо до маркетологів, питаємо, взагалі звідки люди приходять. Вони відповідають: «90% з Яндекс-маркету приходять прямо до картки товару». І чи купують, чи ні. Отже, пошук потрібний 10% користувачів. А тримати реплікацію elastic'a, особливо між різними дата-центрами у різних зонах, — там справді багато нюансів. Який вихід? Ми беремо elastic на резервованому майданчику та нічого з ним не робимо. Якщо справа затягнеться, то ми її колись потім, можливо, піднімемо, але це не точно. Власне, висновок плюс-мінус колишній: сервіси, які на гроші не впливають, ми знову ж таки не резервуємо. Щоб схема залишалася простіше.
Приклад номер чотири, ще складніше
Інтегратор: продаж квітів, виклик таксі, продаж товарів, загалом, чого завгодно. Серйозна штука, яка працює 24/7 на велику кількість користувачів. З повноцінним цікавим стеком, де є цікаві бази, рішення, високе навантаження, і найголовніше, лежати йому понад 5 хвилин боляче. Не тільки й не стільки тому, що люди не куплять, а тому, що люди побачать, що ця штука не працює, засмутяться і можуть взагалі вдруге не прийти.
Окей. П'ять хвилин. Що з цим робитимемо? У цьому випадку ми по-дорослому, на всі гроші будуємо справжній резервний майданчик, з реплікацією всього і вся, і можливо, навіть автоматизуємо максимум перемикання на цей майданчик. І на додаток до цього потрібно не забути зробити одну важливу річ: власне, написати регламент перемикання. Регламент, навіть якщо у вас автоматизовано все і вся, може бути дуже простим. З серії «запустити ось такий сценарій ansible», «в route 53 натиснути таку галку» і так далі — але це має бути якийсь точний список з дій.
І начебто все зрозуміло. Реплікацію переключити — тривіальне завдання, чи вона сама перемкнеться. Переписати доменне ім'я в dns — із тієї ж серії. Біда в тому, що коли падає подібний проект, починається паніка, і навіть найсильніші, бородаті адміни можуть бути піддані їй. Без чіткої інструкції «відкрий термінал, зайди сюди, адресу нашого сервера, як і раніше, ось такий» термін у 5 хвилин, відведених на реанімацію, витримати складно. Ну і плюс, коли ми цим регламентом користуємось, легко відфіксувати якісь зміни в інфраструктурі, наприклад, і відповідним чином змінити регламент.
Ну, а якщо система резервування дуже складна і в якийсь момент ми припустилися помилки, то ми можемо укласти і наш резервний майданчик, а також дані перетворити на гарбуз на обох майданчиках - це буде зовсім сумно.
Приклад номер п'ять, повний хардкор
Міжнародний сервіс з сотнею мільйонів користувачів по всьому світу. Всі таймзони, які тільки є, високі на максималках, лежати взагалі ніяк не можна. Хвилина і буде сумно. Що робити? Резервувати, знову ж таки, за повною програмою. Зробили все, про що говорив у попередньому прикладі, і ще трохи більше. Ідеальний світ, і наша інфраструктура - вона за всіма поняттями девопса IaaC. Тобто все взагалі в git, і тільки натискай кнопку.
Чого бракує? Одного – навчань. Без них не можна. Здається, у нас все ідеально, у нас узагалі все під контролем. Кнопку натискаємо все відбувається. Навіть якщо це так — ми розуміємо, що так воно не буває — наша система взаємодіє з якимись іншими системами. Наприклад, це dns від route 53, s3-сховища, інтеграція з якимись api. Все передбачити в цьому умоглядному експерименті ми не зможемо. І поки ми реально не смикнемо рубильник — не дізнаємося, запрацює воно чи ні.
На цьому, мабуть, все. Не лінуйтеся і не перестарайтеся. І нехай буде з вами uptime!
Джерело: habr.com