English· Español· Deutsch· Nederlands· Français· 日本語· ქართული· 繁體中文· 简体中文· Português· Русский· العربية· हिन्दी· Italiano· 한국어· Polski· Svenska· Türkçe· Українська· Tiếng Việt· Bahasa Indonesia

un

гость
1 / ?
назад к урокам

Узкое место, выявленное до прибытия трафика

Коэффициент посредничества (Betweenness Centrality)

Для каждой пары узлов в графе существует кратчайший путь между ними. Коэффициент посредничества узла N = доля всех кратчайших путей, проходящих через N.

Узел с высоким коэффициентом посредничества лежит на пути между многими другими парами узлов. Если он замедляется, замедляется множество потоков. Если он выходит из строя, множество потоков прерывается.

Архитектурная интерпретация: узлы с высоким коэффициентом посредничества — это те, на которые каждый архитектурный обзор должен обращать особое внимание. Они одновременно являются узкими местами, однократными точками отказа (SPOF) и критичными по пропускной способности компонентами. К ним обычно относятся:

- Провайдер DNS (между каждым клиентом и каждой службой)

- Прокси-сервер входящего трафика (между каждым клиентом и каждым бэкендом)

- Основной узел базы данных (между каждым бэкендом и каждой операцией чтения)

- Служба аутентификации (между каждым пользователем и каждым разрешенным действием)

Обнаружение без измерений: одной только топологии графа достаточно, чтобы идентифицировать узлы с высокой центральностью посредничества. Вам не нужны данные о трафике; вам нужен архитектурный диаграмма. Узел, который находится между многими парами других узлов, является структурно критическим.

Операционное следствие: узлам с высокой центральностью посредничества следует уделять непропорционально большое внимание в плане инвестиций в (1) запас мощности, (2) избыточность, (3) наблюдаемость и (4) сценарии реагирования на инциденты.

Центральность посредничества: выделенный узел находится на большинстве кратчайших путей

В системе есть: 100 внешних клиентов -> 1 DNS -> 1 провайдер CDN -> 3 обратных прокси -> 12 реплик бэкенда -> {1 основной узел БД, 2 узла кэша, 5 внешних API-эндпоинтов}. Расставьте эти классы узлов по убыванию центральности посредничества (от самой высокой к самой низкой) и объясните, почему два верхних места заслуживают особого внимания.

Наименьший разрез отключает наименьший сегмент

Теорема о минимальном разрезе простыми словами

Минимальный разрез (min-cut) между двумя узлами в графе = наименьшее количество рёбер (или узлов), которые необходимо удалить, чтобы разорвать связь между ними.

Операционная интерпретация: минимальный разрез ограничивает худший сценарий масштаба распространения сбоя (blast radius). Если минимальный разрез между «клиентами» и «базой данных» составляет 1 ребро (один прокси), то потеря этого ребра отключает всех клиентов от базы данных. Если минимальный разрез равен 5, для полного разрыва связи необходимо одновременная потеря 5 компонентов; это плохое везение, но риск ограничен.

Проектирование с учётом масштаба распространения сбоя: увеличивайте минимальный разрез на каждом важном границе. Несколько прокси; несколько узлов кэша; несколько сетевых путей между ЦОД. Каждое добавление увеличивает минимальный разрез на 1.

Паттерн «шлюз» (bulkhead) в терминах графов: разделение ресурсов на отдельные подграфы, не имеющие общего минимального разреза друг с другом. Сбой внутри одного подграфа не может распространиться на другие, так как рёбра между ними отсутствуют.

Диаметр определяет расстояние распространения сбоя

Диаметр графа = самая длинная кратчайшая связь между любыми двумя узлами.

Распространение сбоя: когда узел выходит из строя и повторные запросы (retries) возвращаются, они затрагивают вышестоящие узлы на расстоянии до диаметра. В системе с диаметром 3 (клиент -> прокси -> бэкенд -> БД) сбой в БД затрагивает 3 вышестоящих уровня в шторме повторных запросов.

Следствие: меньший диаметр = более быстрое сдерживание сбоя, но также и большая концентрация узлов. У каждого дизайна есть свои компромиссы.

Минимальный разрез как граница радиуса взрыва; диаметр как расстояние распространения

Вычисление минимального разреза для реальной архитектуры

Архитектура: 1 DNS, 1 CDN, 3 обратных прокси, 12 реплик бэкенда, 1 основной узел БД.

Вычислите (или оцените) минимальный разрез на трех границах: (1) между внешними клиентами и уровнем обратных прокси; (2) между уровнем обратных прокси и уровнем бэкенда; (3) между уровнем бэкенда и основным узлом БД. Для каждой границы укажите, что выходит из строя при превышении этого минимального разреза.

Аудит режимов отказа с помощью метрик графа

Синтез

Теперь вы можете определять узлы с высокой междуцентральностью, вычислять минимальный разрез на каждой границе и оценивать расстояние распространения отказа с помощью диаметра.

Примените все три метода.

Система: 50 клиентских конечных точек -> 1 DNS -> 2 узла CDN -> 4 обратных прокси -> 16 реплик бэкенда -> { кластер БД (1 основной + 2 резервных), кластер Redis (5 узлов), 3 внешних API }.

Проведите аудит системы: (1) назовите узел с наибольшей междуцентральностью, (2) вычислите минимальный разрез на наиболее критичной границе и (3) предложите два конкретных архитектурных изменения (каждое из которых должно увеличивать минимальный разрез, и для каждого укажите, какую именно границу оно укрепляет).

Сопроводительные заметки

Сопроводительные заметки

Этот урок по геометрии переосмысливает основной урок Режимы отказов и радиус поражения с помощью метрик графов (показатель посредственности, минимальный разрез, диаметр).

Финальный сопроводительный материал, geometry_of_observability_and_capacity, рассматривает ячейки Вороного для зон обслуживания CDN-узлов (PoP), нижний предел задержки, определяемый скоростью света в «треугольнике задержки», и кривую массового обслуживания, повторно рассмотренную на уровне прокси.

Отличная работа.