Узкие места и трейдоффы

Узкое место — один ресурс

Ёмкость системы задаёт её узкое место — единственный ресурс, что насыщается первым при росте нагрузки. Как цепь рвётся в слабейшем звене, вся система встаёт, когда любой единственный ресурс упирается в потолок, сколько бы запаса ни было у других. Добавлять ёмкость где угодно ещё — впустую; нужно найти и расширить связывающее ограничение.

Поэтому, когда дизайн нарисован, пройди путь запроса и спроси на каждом хопе: каков потолок этого компонента и насколько близко к нему нагрузка? Кандидаты-ресурсы всегда из одного короткого списка:

• CPU на сервис-слое — обычно легче всего починить (масштабировать stateless-слой out).
• База — пропускная способность primary на запись, или реплики, или единственного горячего шарда. Чаще всего реальное узкое место, потому что состояние сложно масштабировать (урок vertical-vs-horizontal).
• Горячий ключ или горячий шард — неровная нагрузка, где одна партиция получает непропорциональный трафик, так что средняя утилизация лжёт.
• Сеть/полоса — egress на fan-out или медиа-тяжёлом пути.
• Нижестоящая зависимость — сторонний API, общий лок, единственный координатор (член contention из USL — Universal Scalability Law, закон масштабируемости, учитывающий конкуренцию за ресурсы).

Вместе эти кандидаты образуют полный список мест, где система может согнуться — но без оценки на руках список остаётся триvia. Навык — не перечислить их; это определить, какой из них связывающий для этого дизайна при этой нагрузке, используя оценку из ранее. Узкое место — это ресурс, к превышению которого твоё число на салфетке ближе всего.

Любой дизайн — это набор трейдоффов

Бесплатной архитектуры нет. Каждый выбор покупает одно свойство, тратя другое, и сеньорский сигнал — называть обмен явно, а не делать вид, что дизайн строго лучше. Повторяющиеся оси:

• Согласованность против доступности (обмен CAP/PACELC). Строгая согласованность значит координацию, что стоит доступности при разделении и задержки всегда («else, latency» из PACELC). Согласованность-в-конечном-счёте покупает доступность и низкую задержку ценой устаревших чтений. Скажи, что выбрал и почему этот домен это терпит: «счётчик лайков может быть согласован в конечном счёте; баланс банка нет».
• Задержка против стоимости. Меньше задержка обычно значит больше реплик, больше кэша, больше регионов — всё деньги. Почти любую цель по задержке можно достичь, потратив достаточно; вопрос дизайна — самый дешёвый способ достичь цели, что тебе реально нужна.
• Простота против масштаба. Простейший дизайн, что вытягивает требования, обычно верен; сложность стоит добавлять лишь там, где оценка форсирует. Один Postgres, что влезает в нагрузку, бьёт шардированную мультирегиональную систему, что тебе не нужна (снова ловушка переинженеринга).
• Оптимизация чтения против записи. Можно предвычислить на записи, чтобы чтения были дёшевы (fan-out-on-write), или вычислять на чтении, чтобы записи были дёшевы (fan-out-on-read) — но не оба. Отношение чтение/запись паттерна доступа решает, что.

Эти четыре оси покрывают почти каждое архитектурное решение, что тебе придётся принять. Без называния трейдоффа на каждой твой дизайн — набор утверждений; с ним — инженерия. Ход — сказать обмен вслух: «Я выбираю согласованность-в-конечном-счёте тут, что покупает доступность и низкую задержку чтения; цена — чтения могут быть на пару секунд устаревшими, что приемлемо для ленты, но я пересмотрел бы это для платежей». Это одно предложение — разница между ответом и сильным ответом.

Как обрабатывать «а если 10×?»

Вопрос о масштабе — любимый зонд интервьюера, и он проверяет ровно навык узкого места. Неверный ответ — рефлекторное «добавим серверов». Верный ответ — процедура:

1. Пройди путь и найди новое узкое место. При 10× нагрузке какой ресурс первым пересекает потолок? Пересчитай ключевую оценку (урок оценок): 10× QPS, 10× рост хранилища. Stateless-слой обычно масштабируется out тривиально, так что узкое место почти всегда смещается на stateful-ресурс — primary на запись, горячий шард, кэш, что больше не влезает в RAM.
2. Назови починку для этого конкретного ресурса и новый трейдофф, что она вносит. «Шардинг слоя записи в 10× значит, что кросс-шард запросы дорожают, поэтому я денормализую частое чтение». Каждая починка смещает узкое место в новое место — скажи, куда оно идёт дальше.
3. Скажи, что сломается, если ничего не делать, с механизмом: кривая очередей уходит в вертикаль, ретраи наваливаются, и brownout (частичный отказ — система отвечает, но медленно и с ошибками) каскадом в outage (уроки масштабируемости и каскадных отказов).

Что отличает мидла от сеньора

Тот же дизайн, поданный двумя способами, ложится совершенно по-разному. Мидл подаёт дизайн как набор верных выборов. Сеньор подаёт дизайн как набор осознанных трейдоффов, у каждого названа цена и признана альтернатива. Техническое содержание может быть идентичным — разница в метакогниции: знание того, что ты отдал, когда пересмотрел бы это и при какой нагрузке оно ломается.

Конкретно сеньорские сигналы: определить связывающее узкое место (не «оно медленное», а «primary на запись при 8K/с — это ограничение»); назвать каждый трейдофф с ценой («согласованность-в-конечном-счёте покупает доступность, стоит свежести»); знать режим отказа («за 70% хвост очередей уходит в вертикаль»); и правильно размерить («одного инстанса тут достаточно; шардил бы только за ~10K записей/с»). Уверенность — junior-тель; калиброванная осознанность трейдоффов — сеньорская.