У цій статті зібрані деякі загальні шаблони, які допомагають інженерам працювати з масштабними сервісами, до яких запитують мільйони користувачів.
На досвід автора, це не вичерпний список, але дійсно ефективні поради. Тож почнемо.
Перекладено за підтримки .
Початковий рівень
Наведені нижче заходи відносно прості у реалізації, але дають високу віддачу. Якщо ви раніше їх не робили, то будете здивовані значними покращеннями.
Інфраструктура як код
Перша частина порад у тому, щоб реалізувати інфраструктуру як код. Це означає, що у вас має бути програмний спосіб розгортання всієї інфраструктури. Звучить хитромудро, але насправді ми говоримо про наступний код:
Розгортання 100 віртуальних машин
- з Ubuntu
- 2 ГБ RAM на кожній
- у них буде наступний код
- з такими параметрами
Ви можете відстежувати зміни в інфраструктурі та швидко повертатися до них за допомогою системи керування версіями.
Модерніст у мені каже, що можна використовувати Kubernetes/Docker, щоб зробити все вище перераховане, і він має рацію.
Крім того, забезпечити автоматизацію можна за допомогою Chef, Puppet або Terraform.
Безперервна інтеграція та доставка
Для створення сервісу, що масштабується, важлива наявність конвеєра складання і тесту для кожного пул-реквеста. Навіть якщо тест найпростіший, він принаймні гарантує, що код, який ви деплоїте, компілюється.
Щоразу на цьому етапі ви відповідаєте на запитання: Чи буде моя збірка компілюватися і проходити тести, чи валідна вона? Це може здатися низькою планкою, але вирішує багато проблем.
Немає нічого прекраснішого, ніж бачити ці галочки
Для цієї технології можете оцінити Github, CircleCI чи Jenkins.
Балансувальники навантаження
Отже, ми хочемо запустити балансувальник навантаження, щоб перенаправляти трафік, та забезпечити рівне навантаження на всіх вузлах або роботу сервісу у разі збою:
Балансувальник навантаження, як правило, добре допомагає розподіляти трафік. Найкращою практикою є надмірне балансування, щоб у вас не було єдиної точки відмови.
Зазвичай балансувальники навантаження налаштовуються в тій хмарі, якою ви користуєтесь.
RayID, сorrelation ID або UUID для запитів
Вам колись зустрічалася помилка в додатку з повідомленням на кшталт такого: "Щось пішло не так. Збережіть цей ID і надішліть його до нашої служби підтримки»?
Унікальний ідентифікатор, correlation ID, RayID або будь-який з варіантів є унікальним ідентифікатором, який дозволяє відстежувати запит протягом його життєвого циклу. Це дозволяє відстежити весь шлях запиту на логах.
Користувач робить запит до системи A, потім А зв'язується з B, та зв'язується з C, зберігає X і потім запит повертається A
Якби ви віддалено підключилися до віртуальних машин і спробували простежити шлях запиту (і вручну співвіднести, які відбуваються виклики), то збожеволіли б. Наявність унікального ідентифікатора значно полегшує життя. Це одна з найпростіших речей, яку можна зробити, щоб заощадити час зі зростанням сервісу.
Середній рівень
Тут поради складніші за попередні, але правильні інструменти полегшують завдання, забезпечуючи окупність інвестицій навіть для малих та середніх компаній.
Централізоване ведення журналів
Вітаю! Ви розгорнули 100 віртуальних машин. Наступного дня генеральний директор приходить та скаржиться на помилку, яку отримав під час тестування сервісу. Він повідомляє відповідний ідентифікатор, про який ми говорили вище, але вам доведеться переглядати журнали 100 машин, щоб знайти ту, що викликала збій. І її потрібно знайти до завтрашньої презентації.
Хоча це звучить як кумедна пригода, однак, краще переконатися, що ви маєте можливість пошуку по всіх журналах з одного місця. Я вирішив завдання централізації журналів за допомогою вбудованої функціональності стеку ELK: тут підтримується збір журналів із можливістю пошуку. Це дійсно допоможе вирішити проблему пошуку конкретного журналу. Як бонус ви можете створювати діаграми тощо кумедні штуки.
Функціональність стеку ELK
Агенти моніторингу
Тепер, коли вашу службу введено в дію, потрібно переконатися, що вона працює без збоїв. Найкращий спосіб зробити це - запустити кілька агентів, які працюють паралельно і перевіряють, що вона працює та виконуються базові операції.
На цьому етапі ви перевіряєте, що запущене складання добре почувається і нормально працює.
Для невеликих та середніх проектів я рекомендую Postman для моніторингу та документування API. Але в цілому просто слід переконатися, що ви маєте спосіб дізнатися, коли стався збій, і отримати своєчасне оповіщення.
Автомасштабування в залежності від навантаження
Це дуже просто. Якщо у вас є віртуальна машина, яка обслуговує запити, і вона наближається до того, що 80% пам'яті зайнято, можна збільшити її ресурси, або додати в кластер більше віртуальних машин. Автоматичне виконання цих операцій чудово підходить для еластичної зміни потужності під навантаженням. Але ви завжди повинні бути обережні в тому, скільки грошей витрачаєте і встановити розумні ліміти.
У більшості хмарних служб можна настроїти автоматичне масштабування за допомогою більшої кількості серверів або потужніших серверів.
Система експериментів
Хорошим способом безпечно розгорнути оновлення стане можливість протестувати щось для 1% користувачів протягом години. Ви, звичайно, бачили такі механізми у дії. Наприклад, Facebook показує частині аудиторії інший колір або змінює розмір шрифту, щоб переглянути, як користувачі сприймають зміни. Це називають A/B тестуванням.
Навіть випуск нової функції можна запустити як експеримент, та був визначити, як її випускати. Також ви отримуєте можливість "згадувати" або змінювати конфігурацію на льоту з урахуванням функції, що викликає деградацію вашого сервісу.
Просунутий рівень
Тут поради, які досить складно реалізувати. Ймовірно, вам знадобиться трохи більше ресурсів, тому невеликій або середній компанії буде важко з цим впоратися.
Синьо-зелені розгортання
Це те, що я називаю «ерлангівським» способом розгортання. Erlang почали широко використовувати, коли з'явилися телефонні компанії. Для маршрутизації телефонних дзвінків почали використовувати програмні комутатори. Основне завдання програмного забезпечення цих комутаторів полягало в тому, щоб не скидати виклики під час оновлення системи. Erlang має чудовий спосіб завантаження нового модуля без падіння попереднього.
Цей крок залежить від наявності балансувальника навантаження. Уявимо, що у вас є версія N вашого програмного забезпечення, а потім ви хочете розгорнути версію N+1.
Ви могли б просто зупинити службу та розгорнути наступну версію в той час, який вважаєте зручним для ваших користувачів, та отримати деякий час простою. Але припустимо, що у вас дійсно Суворі умови SLA. Так, SLA 99,99% означає, що ви можете йти в офлайн лише на 52 хвилини на рік.
Якщо ви дійсно хочете досягти таких показників, потрібно два деплої одночасно:
- той, який є зараз (N);
- наступна версія (N+1).
Ви вказуєте балансувальнику навантаження перенаправити відсоток трафіку на нову версію (N+1), тоді як самі активно відстежуєте регресію.
Тут ми маємо зелений деплой N, який нормально працює. Ми намагаємося перейти до наступної версії цього деплою
Спочатку ми надсилаємо дійсно невеликий тест, щоб подивитися, чи працює наш деплой N+1 з невеликою кількістю трафіку:
Нарешті, у нас є набір автоматичних перевірок, які ми зрештою запускаємо доти, доки наше розгортання не буде завершено. Якщо ви дуже дуже обережні, також можете зберегти своє розгортання N назавжди для швидкого відкату у разі поганої регресії:
Якщо хочете перейти на ще більш сучасний рівень, нехай все в синьо-зеленому деплої виконується автоматично.
Виявлення аномалій та автоматичне пом'якшення наслідків
Враховуючи, що у вас централізоване ведення журналів та гарний збір логів, вже можна ставити більш високі цілі. Наприклад, проактивно прогнозувати збої. На моніторах та в журналах відстежуються функції та будуються різні діаграми — і можна заздалегідь передбачити, що піде не так:
З виявленням аномалій ви починаєте вивчати деякі підказки, які видає сервіс. Наприклад, сплеск навантаження на CPU може підказати, що жорсткий диск виходить з ладу, а сплеск кількості запитів означає масштабування. Такі статистичні дані дозволяють зробити сервіс проактивним.
Отримуючи такі аналітичні дані, ви можете масштабуватись у будь-якому вимірі, проактивно та реактивно змінювати характеристики машин, баз даних, з'єднань та інших ресурсів.
От і все!
Цей список пріоритетів позбавить вас багатьох проблем, якщо ви піднімаєте хмарний сервіс.
Автор оригінальної статті запрошує читачів залишати свої коментарі та вносити зміни. Стаття розповсюджується як open source, пул-реквести автор .
Що ще почитати на тему:
Джерело: habr.com