Словник для балансування навантаження і маршрутизації трафіку

Розмови про балансування навантаження швидко стають неточними — «це дивно маршрутизує трафік» не говорить колегі, чи є проблема перевіркою стану, алгоритмом маршрутизації або схожістю сеансів. Цей словник постійно з’ являється у викликах інциденту, обговореннях планування обсягу і переглядах архітектури, отже, важливо знати, який саме механізм використовується для швидкого виправлення.

Фундаментальні поняття

1. Балансування навантаження

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

** Використання: ** “Балансер навантаження надсилає непропорційно багато трафіку до одного екземпляра — це зазвичай ознака того, що його перевірка стану або алгоритм маршрутизації потребують перегляду.”

Проверка здоров’я

Періодичне зондування, яке балансувальник навантаження надсилає до кожного сервера, щоб визначити, чи є він достатньо здоровим для отримання трафіку, автоматично вилучаючи з обміну нездорові екземпляри.

** Використання: ** *“Ця копія продовжувала отримувати трафік під час повільного перезапуску, оскільки кінцева точка перевірки стану повернула успіх до того, як програма фактично завершила ініціалізацію.” *

3. Сервер

Індивідуальний сервер або екземпляр служби, до якого балансувальник навантаження пересилає запити, іноді називається « початковий сервер » у контексті налаштування, наприклад, Nginx.

** Використання: ** * « Ми додали до пулу новий сервер, але забуємо оновити шлях перевірки стану, отже балансувальник навантаження не позначає його як готовий ». *

Четвертий раунд

Алгоритм балансування навантаження, який розподіляє запити послідовно і рівномірно між всіма доступними серверами, незалежно від поточного навантаження кожного з серверів.

** Використання: ** *“Рівномірне розподілювання працює добре, оскільки всі наші екземпляри мають однакову пропускну здатність, але це не буде працювати добре зі змішаним парком з екземплярами різних розмірів.” *

5. Найменше зв’язків

Алгоритм балансування навантаження, який маршрутизує кожен новий запит до сервера, який обробляє найменше активних з’ єднань. Цей алгоритм корисний, коли час обробки запиту значно змінюється.

** Використання: ** * « Ми переключилися на найменше з’ єднань, оскільки деякі з наших запитів тривають набагато довше, ніж інші, а послідовне надсилання нових запитів до вже зайнятих екземплярів ». *

Маршрутизація та розподіл

6-й. Схожість сеансів (липкі сеанси)

Налаштування, за якого балансувальник навантаження маршрутизує всі запити від одного клієнта до одного екземпляра сервера, зазвичай, для збереження стану сеансу у пам’ яті.

** Використання: ** *“Ми покладаємося на прилиплі сеанси, оскільки дані сеансу живуть у пам’ яті кожного екземпляра — без афінності, користувач може бути відкинутою до екземпляра, який не має їх сеансу.” *

Відмовний перехід

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

** Використання: ** * “Відновлення роботи було запущено протягом декількох секунд після того, як первинний екземпляр не зміг виконати перевірку стану, і трафік було переведено у режим очікування без відкидання запитів.” *

Автоматический выключатель

Шаблон, який припиняє надсилання запитів до залежності, що зазнала невдачі, після досягнення певного порогу невдач, надаючи час для відновлення замість того, щоб продовжувати перевантажувати її трафіком.

** Використання: ** * “Відключення було викликано після того, як частота помилок залежності перевищила наш поріг, що фактично захищає решту системи від каскадних збоїв.” *

9. Обмеження швидкості

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

** Використання: ** “Ми обмежуємо швидкість цієї кінцевої точки на ключ API, після того, як одна неправильна спроба клієнта майже перенаситила весь кластер.”

10. Формування руху

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

** Використання: ** “Ми використовуємо формування трафіку, щоб спочатку відправляти лише 5% запитів до нової версії, поступово збільшуючи їх кількість, коли ми переконаємося, що вона поводиться правильно.”

Схеми розгортання

11. розгортання канарій

Стратегія розгортання, за якої нова версія отримує невеликий відсоток виробничого трафіку, що дозволяє виявити проблеми перед повним розгортанням.

** Використання: ** * “Ми виявили цю регресію під час стадії розгортання канарки, коли вона впливала лише на п’ ять відсотків трафіку, задовго до того, як вона дійшла до всіх.” *

12-й. Розгорнути синьо-зелене

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

** Використання: ** “З сині- зеленим розгортанням, відновлення цього поганого випуску було лише питанням переключення балансувальника навантаження назад до попереднього середовища — не потрібно перерозгортання.”

13. Зважена маршрутизація

Стратегія розподілу трафіку, за якої різні сервери або версії отримують різні частки трафіку на основі присвоєних ваги, а не рівномірного розподілу.

** Використання: ** “Ми використовуємо ваганий маршрутизацію для відсилання 90% трафіку до стабільної версії і 10% до експериментальної, поки ми перевіряємо її.”

14-й. Дренування (з’єднання дренажу)

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

** Використання: ** “Ми увімкнули витоку з’ єднання перед тим, як вивести цей екземпляр з циклу, тому запити у польоті завершуються, а не відкидаються у середині відповіді.”

15-й. Маршрутизація за затримкою

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

** Використання: ** “Маршрутизація за затримкою автоматично відправляє європейських користувачів до нашого регіону Франкфурт, без потреби в будь- якій логіці з боку клієнта для вибору найближчої кінцевої точки.”

Ключеві моменти

• Назвіть конкретний механізм (перевірка стану, алгоритм маршрутизації, спорідненість сеансів), замість того, щоб описувати поведінку трафіку лише нечітко, як « дивне » або « пошкоджене »
• Відрізняти круговий облік від найменшої кількості з’ єднань навмисно, на основі того, чи значно змінюється час обробки запитів у різних потоках.
• Використовуйте словосполучення « канарець » і « синьо- зелений » для розгортання, коли пропонуєте стратегію розгортання, оскільки вони дійсно відображають різні ризики і компроміси щодо відновлення.
• Згадайте про витоку з’ єднання, коли обговорюватиметься, як вилучити екземпляри з повороту, щоб уникнути раптового відкидання запитів у потоці.
• Досягнення для автоматичних виключень і обмеження швидкості як окремі, допоміжні захисні шаблони — один захищає від невдалих залежностей, інший захищає від перевантаження клієнта.

На практиці: Навігація Nuance в командному спілкуванні

Зрозуміти термінологію навколо балансування навантаження і маршрутизації трафіку - це тільки половина битви. Справжній виклик для людей, для яких англійська не є рідною мовою, часто полягає в тому, як ви поширюєте ці поняття в технічній команді. Це не просто знати, що «схожість сеансів» означає направлення користувачів на той же сервер, але також мати можливість пояснити * чому * це важливо, або запропонувати альтернативний підхід чітко і впевнено. Давайте розглянемо кілька сценаріїв.

Під час перегляду коду нової можливості, що реалізує алгоритм балансування навантаження по кругу, ваш старший інженер може залишити коментар: « Ця реалізація не має детальної інтеграції перевірки стану; покладатися лише на використання ЦП — це небезпечна стратегія. Нам потрібно забезпечити активне виявлення порушень серверів. Ключовим тут є не тільки розуміння слів «крихка стратегія», але й усвідомлення наслідків – що поточний підхід схильний до невдач і вимагає більш надійного моніторингу. Це про відповідь з чимось на зразок, “Я розумію вашу занепокоєність щодо медичних перевірок. Я додав скрипт для періодичного ping кожного сервера і запису у журнал всіх випадків, коли сервер не відповідає. Це забезпечує більш негайний цикл зворотного зв’ язку, ніж просто використання процесора. ” Зауважте формулювання: підтвердження початкового коментаря (« Я розумію… »), пояснення * того, що * ви зробили (« Я додав … »), і вказати переваги (« Це забезпечує … »).

Інша ситуація може виникнути у описі запитів на звантаження, що стосуються зміни правил маршрутизації трафіку. Припустимо, ви вводите зважене коло. Менш докладний опис може виглядати так: « Оновлено алгоритм балансування навантаження для використання ваги ». Це занадто нечітке описування! Ефективнішим підходом було б: «Вреалізовано зважене розподіл трафіку по кругу по всіх трьох серверах застосунків. Ваги налаштовуються на основі об’ єму сервера і поточного обсягу запитів, вимірюваних нашою системою моніторингу. Це дозволяє нам динамічно пристосовуватися до коливань попиту, забезпечуючи оптимальну продуктивність під час періодів піку. ” Знову ж таки, це про передачі * чому * зміна була зроблена - для ефективної обробки динамічних навантажень - і забезпечення контексту для технічних деталей.

Нарешті, подумайте про розмови Slack. Можливо, ви отримаєте повідомлення: « Сервер 2 перевантажений! Що відбувається?» Проста відповідь на зразок « Перевірити використання процесора » не є достатньою. Більш лаконічною відповіддю було б: «Дай мені розслідувати. Я запускаю kubectl top pods -n my-app, щоб побачити, які підсистеми споживають найбільше ресурсів, і за кілька хвилин я оновлю вас своїми результатами. » Це демонструє активне дослідження і надає чітку графіку для розв’ язання проблеми за допомогою знайомих інструментів командного рядка у професійному контексті.

Ось приклад того, як ви можете використовувати kubectl top pods для діагностики проблем з ресурсами:

kubectl top pods -n my-app

За допомогою цієї команди можна отримати статистику використання процесора і пам’ яті для всіх підсистем у просторі назв my-app, що надасть вам негайні дані для побудови відповіді. Сфокусування на ясних, контекстуальних поясненнях — демонстрація * розуміння * основних принципів — значно поліпшить вашу здатність ефективно співпрацювати з технічною командою.