Трафик и периметр: план балансировщика и периметра
Практический проект: подними реальный балансировщик перед небольшим пулом, докажи, что алгоритм с учётом нагрузки бьёт round-robin при неровном узле, затем спроектируй и измерь политику кэша CDN — hit ratio, TTL и что никогда не должно попасть на разделяемый edge.
Прочитать, что алгоритм с учётом нагрузки бережёт твой хвост и что hit ratio CDN нелинеен, — не то же, что доказать это на работающей системе. Подними реальный балансировщик перед небольшим пулом, впрысни один медленный узел и смотри, как расходятся round-robin и least-response-time — затем спроектируй политику кэша для смешанного приложения и измерь hit ratio, который реально получаешь.
Этот проект делает весь юнит операционным: ты сконфигурируешь реальный балансировщик, продемонстрируешь разницу хвоста задержки между слепым и учитывающим нагрузку алгоритмом, проверишь, что осмысленный health-check выкидывает сломанный узел, а затем спроектируешь политику кэша на ответ и измеришь её hit ratio — включая доказательство того, что никогда не должно достигать разделяемого edge.
Построй небольшой, но реальный периметр трафика: балансировщик (nginx/HAProxy/Envoy или облачный LB) перед пулом одинаковых инстансов приложения, эмпирически продемонстрируй, что алгоритм с учётом нагрузки бережёт хвост задержки там, где round-robin нет, проверь выкидывание по health-check, а затем спроектируй и измерь политику кэша в стиле CDN для смешанного приложения — замыкая петлю между утверждениями юнита и наблюдаемым поведением.
- Работающий балансировщик + пул, достижимый через один адрес, с показанной конфигурацией алгоритма и health-check.
- Два результата нагрузочного теста (round-robin против учёта нагрузки) под одним и тем же впрыснутым медленным узлом, с p50/p99 и пропускной способностью, наглядно показывающие, что p99 round-robin идёт за медленным узлом, а алгоритм с учётом нагрузки держит хвост у здоровых узлов.
- Демонстрация того, что поломка пробимой зависимости узла заставляет балансировщик выкинуть его (логи или метрики), с продолжением трафика на оставшихся узлах и восстановлением, когда узел вылечен.
- Одностраничная таблица политики кэша, покрывающая все пять типов контента с явными Cache-Control/TTL/Vary, и однострочным обоснованием на строку, включая, какие ответы никогда не кэшируемы на разделяемом edge и почему (утечка / корректность / запись).
- Измеренный hit ratio кэша до/после для публичного контента с внесённым изменением, плюс подразумеваемое снижение RPS origin (показывающее понимание нелинейной экономики доли промахов).
- Короткая записка по failover: расчёт запаса N−1 и рекомендуемый размер пула, привязанные к риску давки.
- Добавь консистентное хеширование: поставь кэш-уровень по ключу за балансировщиком, покажи, что хеширование по ключу даёт высокий hit ratio, тогда как least-connections его обрушивает, и измерь, сколько ключей переотображается при добавлении/удалении узла (~1/N).
- Добавь сценарий давки: истеки TTL горячего объекта на многих edge/прокси-кэшах разом, понаблюдай синхронный всплеск origin, затем включи объединение запросов (и/или origin shield) и покажи, что origin видит один запрос вместо многих.
- Сделай шлюз избыточным: гоняй два инстанса балансировщика/шлюза за вышестоящим балансировщиком, убей один под нагрузкой и покажи, что полного сбоя нет — контрастируя с SPOF одного инстанса.
- Добавь джиттер-ретраи в генератор нагрузки и покажи, как синхронные (без джиттера) ретраи при отказе узла ускоряют каскад, тогда как джиттер размазывает нагрузку восстановления и избегает петли обратной связи brownout-в-сбой.
- 01Как эмпирически показать, что алгоритм с учётом нагрузки бережёт хвост задержки?
- 02Что задаёт здравая политика кэша CDN на каждый тип ответа?
- 03Почему измерять hit ratio и считать запас N−1, а не доверять дефолтам?
Этот проект превращает юнит трафика и периметра в повторяемый воркфлоу: подними балансировщик над одинаковым пулом, затем докажи центральное утверждение юнита, впрыснув один медленный узел и показав, что round-robin прикрепляет p99 сервиса к нему, тогда как учитывающий нагрузку алгоритм (least-connections/least-response-time) обходит его. Проверь, что осмысленный health-check — пробящий реальную зависимость, а не статичный 200 — выкидывает сломанный узел и трафик продолжается. Затем спроектируй политику кэша CDN на ответ для смешанного приложения (фингерпринтованные ассеты, публичная страница, страница на пользователя, обязанное быть верным значение, эндпоинт записи), измерь hit ratio до и после улучшения TTL/ключа и переведи его в нелинейное снижение нагрузки origin. Наконец, сделай математику ёмкости failover N−1, чтобы выжившие вобрали потерянный узел без каскада давки. Делать конфигурацию и измерение, а не только читать утверждения, — вся дисциплина: инженер, построивший это однажды, выбирает уровни, алгоритмы, шлюзы и политики кэша намеренно, а не открывает их режимы отказа во время инцидента.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.