Б Бёрнс - Распределенные системы. Паттерны проектирования

Важно, однако, понимать, что объем накладных расходов реализации паттерна Scatter/Gather растет с увеличением количества терминальных узлов. Поэтому, несмотря на их не-большой объем, с ростом степени распараллеливания расходы на них со временем могут превысить расходы на реализацию бизнес-логики приложения. А это значит, что рост производи-тельности за счет распараллеливания носит асимптотический характер.

Помимо того что добавление терминальных узлов может и не ускорить обработку запросов, Scatter/Gather-системы также подвержены «эффекту отстающего». Чтобы понять причину этого, важно помнить, что в Scatter/Gather-системе корневой узел сможет отправить ответ конечному пользователю не ранее, чем дождется ответа от всех терминальных узлов. По-скольку необходимо получить данные от всех узлов, общее время обработки запроса определяется временем обработки запроса самым медленным узлом. Попытаемся понять, как это влияет на производительность, и рассмотрим сервис, в ко-тором 99-й процентиль задержки составляет 2 секунды. Это значит, что в среднем один из 100 запросов будет обработан с задержкой 2 секунды и более. Иными словами, обработка запроса займет 2 секунды и более с вероятностью 1 %. На пер-вый взгляд, это совершенно приемлемо, так как только один из 100 запросов будет обрабатываться медленно. Но в систе-Глава 7. Паттерн Scatter/Gather 131

мах, построенных по принципу Scatter/Gather, дела обстоят несколько иначе. Поскольку время обработки запроса опре-деляется самым медленным ответом, нам приходится рассма-тривать не один запрос, а все запросы, распределенные между

терминальными узлами системы.

Посмотрим, что произойдет, если распределить запросы на пять терминальных узлов. Вероятность того, что обработка за-проса одним из терминальных узлов займет 2 секунды и более, равна 5 % (0,99 × 0,99 × 0,99 × 0,99 × 0,99 = 0,95). А это значит, что 99-й процентиль задержки единичного запроса становится 95-м процентилем задержки всей Scatter/Gather-системы. Даль-ше — хуже: если распределить нагрузку на 100 терминальных узлов, то общая средняя задержка обработки почти наверняка составит 2 секунды.

Из перечисленных выше проблем можно сделать несколько выводов:

‰ ‰ в силу накладных расходов, имеющих место в каждом узле, повышение степени параллелизма не всегда ускоряет работу системы;

‰ ‰ в силу «эффекта отстающего» повышение степени паралле-лизма не всегда ускоряет работу системы;

‰ ‰ 99-й процентиль производительности системы в Scatter/ Gather-системах имеет существенно большее значение, не-жели в других классах систем, так как один пользователь-ский запрос превращается во множество запросов к сервису. «Эффект отстающего» влияет и на доступность системы. Если запрос распределяется на 100 терминальных узлов, а вероят-ность отказа любого из узлов равна 1 %, то почти наверняка ни один из запросов пользователей не будет успешно обра-

ботан.

132Часть II. Паттерны проектирования обслуживающих систем Масштабирование

Scatter/Gather-систем с учетом надежности и производительности Как и в случае с другими шардированными системами, наличие единственной копии шардированной Scatter/Gather-системы — не лучшее архитектурное решение. Если в единственном экзем-пляре шарда происходит отказ, все Scatter/Gather-запросы будут отклоняться на время его недоступности, поскольку в рамках паттерна Scatter/Gather все запросы должны обрабатываться всеми терминальными узлами. Модернизация системы также сделает часть узлов временно недоступными, а значит, обновить систему при наличии запросов от пользователей тоже не полу-чится. Наконец, вычислительная мощность системы в целом будет ограничена вычислительными возможностями каждого отдельного узла.

В конечном итоге все указанные факторы ограничивают мас-штабируемость вашей системы. Как уже было рассмотрено в предыдущих разделах, нельзя просто увеличить количество шардов, чтобы повысить вычислительную мощность системы, построенной на основе паттерна Scatter/Gather. С учетом проблем с надежностью и масштабируемостью кор-ректным будет реплицировать каждый отдельный шард. Таким образом, терминальные узлы будут реализованы не в виде от-дельных шардов, а в виде реплицированных сервисов. Схема реплицированного шардированного паттерна Scatter/Gather изображена на рис. 7.4.

Нагрузка на терминальный узел системы равномерно распре-деляется между исправными репликами шарда. Это значит, что отказ реплик шарда не приведет к видимому отказу сер-виса. Кроме того, в каждом реплицированном шарде можно Глава 7. Паттерн Scatter/Gather 133

Рис. 7.4. Scatter/Gather-система с шардированием и репликациейобновлять по одной реплике за раз, а значит, систему можно обновлять и под нагрузкой. В зависимости от того, насколько быстро нужно выполнять обновление, можно даже параллельно обновлять несколько реплик, находящихся в разных шардах. 8 Функции и событийно-ориентированная

обработка

До настоящего момента мы рассматривали проектирование длительно работающих систем. Серверы, обрабатывающие пользовательские запросы, работают постоянно. Такой подход годится для высоконагруженных приложений, требующих большого объема памяти или фоновой обработки данных. Есть класс приложений, которые запускаются нена-долго — для обработки одного запроса или для того, чтобы отреагировать на конкретное событие. Такой запросно- или событийно-ориентированный подход к проектированию при-ложений начал в последнее время получать распространение по мере того, как крупные провайдеры стали предлагать продукты типа «функция как сервис» (function-as-a-service, FaaS). С не-давних пор реализации FaaS начали работать на оркестраторах кластеров в частных облачных и физических средах. В этой Глава 8. Функции и событийно-ориентированная обработка 135главе описываются новые архитектуры, возникающие в рамках данного подхода. В большинстве случаев FaaS представляет собой компонент более крупной архитектуры, а не самостоя-тельное решение.

бессерверные вычисления применимы к широкому спектру сервисов. К примеру, многопользовательские оркестраторы контейнеров («контейнер как сервис») являются бессер-верными, но не являются событийно-ориентированными. И наоборот, FaaS-сервис с открытым исходным кодом, работающий на кластере физических компьютеров, при-надлежащих вам и управляемых вами, является событийно-ориентированным, но не является бессерверным. Понима-ние этого различия позволяет вам определить, подходит ли для вашего приложения событийно-ориентированная