Для создателей таких веб-сервисов «укорочение» хвоста распределения задержек (tail of latency distribution) одновременно с тем, как сложность систмы растет и количество пользователей увеличивается — настоящий вызов. ВрЕменные скачки длительности задержки (не сказывающиеся на системах средних размеров) могут деградировать производительность большой системы при высоких нагрузках. Так же как принципом построения отказоустойчивых систем (fault-tolerant computing) является создание надежного целого из ненадежных частей, крупномасштабные веб-сервисы должны создавать предсказуемо реагирующее целое из менее предсказуемых частей; такие системы мы называем «устойчевыми к хвостовым задержкам» («latency tail-tolerant») или просто «хвостоустойчевые» («tail-tolerant»). Далее будут указаны наиболее распространенные причины больших задержек в крупномасштабных сервисах и описаны методы, которые позволяют смягчить их воздействие на производительность системы. В большинстве случаев хвостоустойчевые системы могут использовать ресурсы уже развернутые для достижения отказоустойчивости, что в итоге снижает дополнительные накладные расходы.
Откуда берется вариативность?
Вариативность времени ответа, ведущая к большим хвостовым задержкам (длинному хвосту расределения задержек) в отдельных компонентах системы, может возникать по следующим причинам:
Общие ресурсы
Машины могут совместно использоваться несколькими разными приложениями, борющимеся за общий ресурсы(ЦПУ, кеш процессора, память, сеть), плюс ко всему, внутри самого приложения может также происходить борьба за общие ресурсы;
Демоны (daemons)
Фоновые демоны может и используют, в среднем, ограниченное количество ресурсов, но в момент диспетчиризации (when scheduled) они могут генерировать мульти-милисекундные скачки;
Глобальные общие ресурсы
Приложения, работающие на разных машинах могут соревноваться за глобальные ресурсы (свичи, общая файловая система);
Эксплуатационная активность (maintenance activities)
Фоновая активность (периодическое сжатие логов в BigTable, сборка мусора в языках со сборкой мусора и т.п.) может вызывать периодические скачки времени задержки;
Очереди
Многоуровненвые очереди в промежуточных серверах и свичах только усиливают вариативность.
На вариативность также влияет и железо:
Ограничения по мощности
Современные ЦПУ спроектированы так, чтобы иметь возможноть временно работать над свои средним мощностным диапазоном, при этом борясь с перегревом за счет режима пропуска тактов (throttling), если такая активность продолжается долго;
Сборка мусора
SSD диски дают нам очень быстрый случайный доступ на чтение, но необходимость периодической сборки большого количества блоков данных может увеличить задержку на чтение буквально в 100 раз, даже при щадящем уромне активности на запись;
Управление потреблением энергии
Энергосберегающие режимы во многих типах устройств действительно позволяют сэкономить определенное количество энергии, но при этом увеличивают время задержки, когда устройство переходит из неактивного в активный режим.
Вариативность на уровне отдельных компонентов, усиливающееся при масштабировании
Общепринятая техника снижения времени задержки в крупномасштабных сервисах — распараллеливание промежуточных операций на нескольких машинах, при этом каждая промежуточная операция «соседствует» (co-located) с порцией общего большого набора данных. Распараллеливание происходит путем разветвления (fanning out) запроса от корневого сервера к листовым серверам, а затем слияния ответов дерева распределения запроса (request-distribution tree). Эти промежуточные операции должны выполняться за строго определенный промежуток времени, дабы веб-сервис ощущался быстрореагирующим.
Вариативность распределения задержек отдельных компонентов усиливается в масштабе всей системы; например, рассмотрим систему, где каждый сервер в 99% процентах случаев отвечает за 10 мс, а в оставшемся проценте — больше 1 секунды. Если запрос пользователя обрабатывается одним таким сервером, то только один из 100 ответов будет медленным (более секунды). Картинка ниже показывает, как задержка на уровне сервера в этом сценарии зависит от (весьма низкой) доли длительных запросов. Если пользовательский запрос должен собрать ответы от 100 таких серверов, то 63% ( (1 — 0.99^100)*100 ) пользовательских запросов займут больше чем 1 секунду («х» на графике). Даже если несколькосекундный ответ случается только раз на 10000 запросов, для сервиса с 2000 таких серверов практически каждый 5ый пользователь будет ждать дольше секунды («о» на графике).
Таблица 1 показывает проведенные измерения для одного из сервисов Google, логика работы которого схожа с приведенным выше сценарием. Корневой сервер распределяет запрос через промежуточные серверы на очень большое количество листовых серверов. Таблица демонстрирует зависимость разветвленности системы и распределение задержек. 99-ый перцентиль задержек для одного случайного запроса, измеренные на коневом сервере, составляет 10 мс. Однако, 99-ый перцентиль задержек для всех запросов — 140 мс, а 99-ый перцентиль задержек для 95% запросов — 70мс, т.е. ожидание самых медленных 5% запросов вносит половину времени задержки в 99-ый перцентиль. Методы, фокусирующие свое внимание на этих самых меделнных запросах, могут весьма значительно повлиять на производительность всей системы.
Грамотное распределение ресурсов и аккуратное проектирование системы могут быть дать эффект на всех уровнях и во всех компонентах системы, ослабив влияние основных причин вариативности задержек.
Устранение вариативности времени задержек отдельных компонентов
В этом могут помочь следующие инженерные решения:
Разделение сервисов на классы и внедрение высокоуровневых очередей
Разделение сервисов на классы может быть использовано в том случае, когда преференции при диспетчировании запросов будут отдаваться запросам, которые ждет пользователь. Также необходимо поддерживать низкоуровневые очереди короткими, чтобы высокоуровневые политики быстрее вступали в силу (Keep low-level queues short so higher-level policies take effect more quickly); например, сервера, отвечающие за хранение данных, в кластерной файловой система Google поддерживают для некоторых операций свою собственную очередь запросов к диску, в обход очереди операционной системы. Подобные очереди позволяют серверу обслуживать высокоприоритетные запросы от пользователя раньше, чем длительные запросы на обработку больших порций данных (batch operations).
Снижение блокировок из-за головы очереди (head-of-line blocking)
Высокоуровневые сервисы могут обрабатывать запросы весьма разнящейся «тяжести». Поэтому иногда полезно разбивать «тяжелые» запросы на множество запроов «полечге» (небольшой длительности выполнения), дабы другие запросы тоже получили возможность выполнится; например, поисковая система Google пользуется этой методикой и она позволяет не дать малому числу вычислительно дорогих запросов внести значительные задержки в выполнение большого числа дешевых запросов.
Управление фоновой активностью и синхронизация девиаций (synchronized disruption)
Фоновые задачи могут создавать значительную нагрузку на ЦПУ, диск или сеть; например, сжатие логов или сборка мусора. Троттлинг, разбиение тяжелых задач на мелкие и вызов таких задач в периоды низкой общей нагрузки, — способны, при совместном применении, значительно снизить влияние фоновых задач на задержки в обработке пользовательских запросов. Для крупных разветвленных систем в некторых случаях может оказаться полезной синхронизация фоновых задач, выполняющихся на различных машинах. Такая синхронизация дает краткий скачок активности на всех машинах одновременно, замедляя только те запросы, которые происходили во время этого скачка. А без синхронизации на различных машинах будут постоянно запускаться фоновые задачи, увеличивая хвостовые задержки для всех запросов.
Нигде выше не упоминалось кеширование. Хоть кеширование может быть очень полезно, а для некоторых систем просто необходимо, оно непосредственно не борется с хвостовыми задержками, кроме конфигураций, где все рабочие данные находятся в кеше.
Как жить с вариативностью задержек
Инженерные подходы, описанные выше, неотъемлимы при построении высокопроизводительных интерактивных сервисов, но масштаб и сложность современных веб-сервисов не дает возможности целиком искоренить вариативность задержек. Даже если некое идеальное поведение может быть достигнуто в изолированных системах, в реальных системах с разделяемыми ресурсами флуктуации производительности находятся вне контроля прикладных разработчиков. Поэтому Google считает, что весьма полезно выработать хвостоустойчевые методы, которые позволят замаскировать или просто обойти определенные виды девиаций во времени задержки, вместо того, чтобы пытаться избаваться от них всех сразу. Мы разделяем такие методы на два основных класса. Первый соответсвует техникам мнгновенного реагирования, имеющим место во время выполнения запроса (within-request immediate-response techniques), т.е. техникам действующим в масштабах десятков милисекунд, до того, как вступили в действие более серьезные и длительные методы. Второй соответствует техникам более долговременным, оперирующим в масштабе нескольких запросов (cross-request long-term adaptations), т.е. они занимают десятки секунд, а то и минуты, по времени и предназначены, для того чтобы нивелировать долговременные девиации во времени задержки.
Кратковременные меры в рамках одного запроса
Большое число веб-сервисов использует репликацию данных в целях обеспечения дополнительной пропускной способности (throughput capacity) и доступности (availability) в случае отказов оборудования. Такой подход особенно эффективен, когда большая часть нагрузки — чтение слабо-консистентных массивов данных (loosely consistent datasets); например, сервис проверки правописания (spelling-correction), который обновляет свои данные раз в день, но при этом обслуживает тысячи запросов в секунду. Или например, распределенные файловые системы могут иметь несколько реплик одной порции данных (data chunk), каждая из которых может быть использована для обслуживания запросов на чтение. Методы, приведенные ниже, показывают, как репликацию можно использовать для снижения вариативности времени задержек в рамках одного выскоуровневого запроса:
Хедж запросы (hedged requests)
Простой способ снизить вариативность задержки — повторить исходный запрос на несколько реплик и в качестве результата использовать первый пришедший ответ. Мы называем такие запросы «хедж запросами», потому что клиент сначала отправляет запрос на реплику, которую считает наиболее подходящей, а затем, после небольшой задержки, начинает отправлять вторичные запросы. Клиент попросту отказывается от ответов, которые пришли после первого. И хотя реализация «в лоб» этого метода добавляет неприемлимую нагрузку на систему, существует множество вариантов исполнения, которые дают серьезное снижение времени задержки, при этом только слегка повышая нагрузку. Так например, можно откладывать рассылку вторичных запросов до тех пор пока время ожидания первого запроса не привысит 95-ый перцентиль задержки для этого класса запросов. Такой подход ведет к увеличению нагрузки только для 5% запросов, в тоже время значительно укорачивает хвост распределения задержек. Этот метод работает, потому что источником задержки является не конкретный запрос и его особенности, а, скорее всего, некие другие формы помех. Например, в Google бенчмарке, где считываются значения 1000 ключей, хранящихся в таблице BigTable, распределенной на 100 серверов, рассылка хедж запросов после 10 мс задержки снижает 99.9-ый перцентиль задержки по получению всей 1000 ключей с 1800 мс до 74 мс, при этом рассылается только на 2% больше запросов. Накладные расходы на хедж запросы могут быть снижены и далее путем задания им более низкого приоритета, чем основным запросам.
Связанные запросы (tied requests)
Хедж запросы помимо всего прочего обладают следующей особенностью: существует временное окно, в рамках которого несколько серверов могут выполнить один и тот же запрос, который окажется излишним. От такого эффекта можно избавиться, отложив рассылку хедж запросов до истечения 95-го перцентиля ожидаемой задержки, но такой подход может помочь только малой доле запросов. Введение же более агрессивной рассылки хедж запросов, с учетом небольшого потребления ресурсов, трубует существования возможности быстрой отмены запросов при необходимости.
Распространенным источником вариативности задержек являются очереди, откладывающие выполнение запроса. Для многих сервисов, после того, как запрос диспетчировался (покинул очередь) и начал исполнение, вариативность времени завершения значительно снижается. По словам Mitzenmacher’a: возможность клиента выбирать между двумя серверами в момент времени постановки запроса в очередь, основываясь на соответсвующих длинах очередей, экспоненциально улучшает балансировку нагрузки по сравнению с рандомизированной схемой. Мы же предлагаем не выбирать, а ставить запрос в несколько очередей одновременно, при этом позволяя серверам изменить статусы соответсвующих копий на других серверах. Мы называем такие запросы, где сервер обновляет статусы таких же запросов на других серверах, «связанными запросами». Простейшый пример связанного запроса: клиент рассылает запросы на два различных сервера, при этом помечая каждый из запросов id’шником другого сервера. Когда один из запросов начинает выполняться, сервер отсылает сообщение по отмене этого запроса на другой сервер. Соответсвующий запрос на другом сервере, если он до сих пор в очереди, может быть отменен немедленно, либо можно значительно снизить его приоритет.
Сущестует короткое окно, размером в среднюю задержку передачи сообщения по сети, в течение которого оба сервера могут начать исполнять запрос, отослав сообщения об отмене на другой сервер. Такое часто случается в случае, если очереди на обоих серверах пусты. Поэтому клиенту необходимо ввести некую задержку, размером в 2 средних времени задержки передачи сообщения по сети (1мс или меньше для современных датацентров), между отправкой первого и второго запроса.
Реализация Google’ом этой методики в контексте кластерной распределенной файловой системы эффективна уменьшает и медиану распределения задержек и хвост. В Таблица 2 отображены замеры времени обработки запросов на чтение в BigTable, в случае когда данные не кешируются в памяти и должны быть прочитаны с диска; каждая порция данных реплицирована 3 раза на различных серверах. В таблице указаны задержки на чтение, в случае, когда использовались связанные запросы и без использования оных. Рассмотрены два сценария: в первом случае кластер, на котором запускался бенчмарк, изолирован, поэтому вариативность задержек в основном исходит от внутренних помех и регулярной эксплуатационной активности кластера. Для этого случая рассылка связанных запросов с интервалом в 1 мс снизила медиану распределения задержек на 16% и была весьма эффективна в укорочивании хвоста распределения, снизив 99.9-ый перцентиль на 40%. Второй сценраий похож на первый во всем, кроме того что в кластере запущена задача по сортировке большого объема данных, конкурирущая с задачей бенчмарки за ресурсы. Хотя общие задержки в данном случае выше из-за дополнительной нагрузки на систему, достигнуты такие же показатели по снижению задержек, что и в предыдущем сценарии. Задержки, при использовании связанных запросов в условиях конкурентой работы задачи по сортировке, практически не отличаются от задержек в изолированном кластере, где не используются связанные запросы вовсе. Связанные запросы позволяют консолидировать всю работу в одном кластере, что в результате дает серьезное снижение вычислительных издержек. В обоих сценариях, представленных в Таблице 2, накладные расходы (связанные с диском) на использование связанных запросы составли меньше 1%, а, следовательно, стратегия расслыки сообщений об отмене эффективно исключает необходимость избыточных чтений с диска.
Альтернативой хедж и связанным запросам является метод, в рамках которого сначала проверяются очереди удаленных серверов, а затем запросы рассылаются на менее загруженные сервера. Это может быть выгодно, но по 3 причинам это менее эффективно, чем рассмотренные выше методы: уровень загрузки может измениться в период времени между проверкой очереди и отсылкой запроса; оценить время обработки запроса может быть весьма проблематично в условиях вариативности характеристик системы и железа; а также клиенты могут создать узкое место (hot spot), одновременно выбрав один и тот же (наименее загруженный) сервер. Distributed Shortest-Positioning Time First system (понимайте как хотите — прим. переводчика), так вот, эта система использует другой подход, в котором изначальный запрос посылается на один сервер и рассылается на реплики только в том случае, если в кеше этого самого сервера нет ответа на пришедший запрос, плюс, так же используются сообщения по отмене связанных запросов.
Стоит отметить, что представленный выше метод не ограничен простыми схемами кодирования и подходит, в том числе, и для более сложных (например, для кодов Рида — Соломона), где основной запрос отправляется на машину с необходимым блоком данных и если после краткого ожидания ответ не получен, рассылаются запросы на реплики, ответы которых позволят воссоздать необходимые данные.
Отметим также, что класс методов, описанных в данной части, эффективен только если феномен вариативности обычно не затрагивает несколько реплик, необходимых запросу. Мы считаем, что нескоррелированность подобных событий скорее присуща крупномасштабным системам (We expect such uncorrelated phenomena are rather common in large-scale systems.)
Долговременные меры в рамках нескольких запросов
Теперь обратимся к методам, призванным к снижению вариативности задержек, вызванной феноменами более широкого спектра (такими как вариативность времени работы различных сервисов и разбалансировка нагрузки). Хотя многие системы и пытаются распределать данные так, чтобы все порции были эквивалентны, статическое привязывание этих порций к различным машинам может оказаться не очень практичным по следующим двум причинам: во-первых, производительность машин не постоянна во времени, а загруженность неравномерна — по причинам, описанным выше (глобальные ресурсы, троттлинг). Во-вторых, статическая привязка может вызвать разбалансировку нагрузки, так как одна из порций данных может вдруг стать очень популярной, увлечив нагрузку на ту машину, где она хранится.
Микро-партиции
Для борьбы с разбалансировкой системы Google создают гораздо больше партиций, чем реальных машин в данной системе, а затем динамически осущетвляют привязку (и балансировку) партиций на сущетсвующие машины. В этом случае балансировка представляет из себя просто передачу ответсвенности за ту или иную партицию какой-либо из машин. При среднем — 20 партиций на машину, система может увеличивать нагрузку на каждую машину прибавками по 5% при этом делать это за 1/20 того времени, что понадобилось бы в случае статического отображения партиций на машины по принципу 1-к-1 (With an average of, say, 20 partitions per machine, the system can shed load in roughly 5% increments and in 1/20th the time it would take if the system simply had a one-to-one mapping of partitions to machines). Распределенная система BigTable хранит данные в тАблетах (tablets) так, что каждая реальная машина управляет 20-1000 таблетов одновременно. Восстановление после неполадок также ускоряется за счет использования микро-партиций, т.к. каждая из множества машин, оставшихся в строю, просто берет на себя одну из партиций сломанной машины. Такой способ использования микро-партиций схож со способом использования виртуальных серверов, описанным в работе Stoica и с методом партиционирования виртуальных процессоров (virtual-processor-partitioning), описанным у DeWitt.
Выборочная репикация
Улучшением методики микро-партиций является возможность детектировать или даже предскзывать, какие объекты могут в будущем стать причиной разбалансировки и затем создавать дополнительные реплики таких объектов. Системы балансировки нагрузки могут использовать эти дополнительные реплики, чтобы размазать нагрузку, создаваемую этими популярными объектами, по нескольким машинам без необходимости перемещать куда-то микро-партиции. Поисковая система Google использует этот подход, создавая несколько дополнительных копий популярных и важных документов в виде нескольких дополнительных микро-партиций. В некоторые периоды эволюции поисковой системы она также создавала дополнительные микро-партиции документов на определенных языках и изменяла коэффициент репликации этих микропартиций в течении дня в зависимости от смеси запросов, поступающих в систему. Эта смесь запросов может меняться внезапно, если например обесточили датацентр в Азии и большая часть запросов на местных языках перенаправляется в датацентры в Северной Америке.
Испытательный срок, основанный на времени задержки (Latency-induced probation)
Наблюдая за распределением времени ответа различных машин в системе, промежуточные серверы могу определить ситуацию, когда производительность системы может повыситься, если исключить (отправить на испытательный срок) одну медленную машину. Причина замедления часто бывает временной и заметна лишь при больших нагрузках: скачок активности ЦПУ или сторонний сетевой трафик (interference from unrelated networking traffic ). Однако, система продолжает отправлять запросы на испытываемую машину, собирая статистику по времени ответа, дабы вернуть ее в строй, когда проблемы исчезнут. Вообще говоря такая ситуация, когда уменьшение времени задержки происходит за счет исключения машин из системы, находящейся под нагрузкой, по-своему особенная.
Крупные информационно-поисковые системы
В крупных информационно-поисковых системах (ИПС) скорость больше, чем мера производительности. Это ключевая метрика качества, т.к. возвращать хорошие результаты быстро лучше, чем возвращать отличные результаты медленно. К таким система применяются следующие две методики:
Достаточно хорошо
В крупных ИПС, когда большая часть всех листовых серверов дала ответ на запрос, пользователю можно вернуть слегка неточный («достаточно хороший») результат взамен маленького времени задержки. То, что конкретный листовой сервер содержит наиболее точный ответ на запрос, возможно менее чем в одном из 1000 запросов, при этом шансы на такое событие снижаются еще больше, если реплицировать наиболее важные документы корпуса на нескольких листовых серверах. Так как ожидание медленных серверов может повысить время ответа всей системы до неприемлимых значений, ИПС Google настроена отвечать достаточно хорошими результатами, когда определенная часть поискового корпуса была просмотрена, при этом система следит за тем, чтобы такие ситуации были редки. Также этот метод предполагает игнорирование не самых важных подсистем в целях обеспечения быстроты реагирования; например, результаты работы рекламной системы и системы проверки правописания запросто игнорируются для поисковых запросов обрабатывающихся долго.
Запросы стукачи (canary requests)
Еще одной проблемой в сильно разветвленных системах является то, что очередной запрос может затронуть еще неопробованную ранее часть кода, вызвав серьезные задержки или ошибки на тысячах серверов одновременно. Чтобы предотвратить такие скоррелированные отказы ИПС Google использует так называемые «запросы стукачи»; вместо того, чтобы сразу посылать запрос на тысячи серверов, корневой сервер посылает его сначала одному или двум листовым серверам. Остальные сервера получают запрос только, если корневой сервер получает успешный ответ от стукачей за приемлимое время. Если серевер отвечает ошибкой или перестает отвечать вообше, во время обработки запроса стукача, система помечает запрос как опасный и предотвращает дальнейшее его исполнение на других серверах. Зарпосы стукачи являются своеобразнной мерой устойчивости бекэндов в случае возникновения ошибок, которые трудно предсказать, а также в случае DOS-атак.
Фаза рассылки запросов стукачей добавляет совсем чуть-чуть к итоговому времени задержки, потому что системе нужно ждать ответа только от одного сервера, что обеспечивает куда меньшую вариативность нежели ожидание ответа от всех серверов в сильно разветвленной системе. Сравните первый и последний столбцы в Таблице 1. Несмотря на небольшую прибавку во времени задержки в случае использования запросов стукачей, такие запросы используются во всех поисковых системах Google в добавок той надежности, что они предоставляют сами по себе.
Мутации
Методы, которые мы обсуждали выше, применимы в основном для операций, которые не производят критических изменений в состоянии системы, что охватывает широкий спектр серисов, работающих с большим количеством данных. Управлять вариативностью задержки для операций, меняющих (мутирующих) состояние системы легче по нескольким причинам: во-первых, масштаб критических, с точки зрения времени задержки, модификаций достаточно мал. Во-вторых, обновления могут осуществляться уже после ответа пользователю. В-третьих, многие серивисы могут быть структурированы так, чтобы выдерживать неконсистентные модели обновления (tolerate inconsistent update models for (inherently more latency-tolerant) mutations). И, наконец, те сервисы, которые нуждаются в консистентных обновлениях используют алгоритмы, основанные на кворуме ( Paxos алгоритм Lamport’а), т.к. эти алгоритмы должны сделать коммит только в 3-5 реплик — они хвостоустойчивы по определению.
Тренды в железе и их эффект
Вариативность на уровне железа в будущем, вероятно, будет куда более высокой засчет более агрессивной оптимизации энергопотребления и сложностях тех.процесса на субмикронном уровне, что в итоге дает гетерогенность на уровне железа. Гетерогенность железа вкупе с возрастающими масштабами обслуживаемых систем сделает, со временем, снижение вариативности задержек с помощью ПО еще более важной задачей. К счастью, несколько новых железячных трендов увеличат эффективность способов борьбы с вариативностью задержек. Например, повышение бисекционной полосы пропускания (bisection bandwidth) в датацентрах и оптимизация сетевых интерфейсов, снижающая издержкии на одно сообщение (per-message overheads) (как например, remote direct-memory access), снизят стоимость связанных запросов, обеспечивая возможность того, что запросы на отмену будут получены вовремя, дабы избежать излишней работы. Снижение издержек на обработку одного сообщения естественным образом улучшит мультиплексирование и позволит избежать блокировок из-за головы очереди.
Заключение
Создание вычислительно-интенсивных при этом плавных в использовании интерактивных облачных сервисов следующего поколения требует создания масштабных быстрореагирующих вычислительных систем, которые только начинают появляться. С ростом системы попытки просто убрать все источники вариативности производительности не помогут сделать систему быстрореагирующей. Методы обеспечения отказоустойчивости были разрабтаны в свое время, т.к. гарантировать безотказную работу системы, достигшей определенного уровня сложности, просто невозможно. Также и методы обеспечения хвостоустойчивости разработаны специально для крупномасштабных сервисов, т.к. удаление всех источников вариативности тоже невозможно. Хотя техники, фокусирующиеся на определенном источнике вариативности времени задержки, могут быть весьма полезны, общие методы обеспечения хвостоустойчивости снижают время задержки вне зависимости от их причины. Эти методы позволяют разработчикам продолжать оптимизировать систему под задачи, для которых она предназачена непосредственно, при этом давая устойчивость работы в непредвиденных ситуациях. Здесь мы описали некоторые из хвостоустойчивых методик, которые показали себя полезными в системах, созданных в Google. Их важность только возрастет со временем, вместе с ростом потребности современных Интернет сервисов в сложных датацентр-масштабных вычислительных системах и увеличением вариативности производительности используемого в них железа.
В то время как самые мощные хвостоустойчивые методы требует дополнительных ресурсов, накладные расходы от их использования остаются весьма умеренными, порой они даже сводятся к нулю, если эти методы опираются на уже существующую инфраструктуру по обеспечению отказоустойчивости, при этом давая значительное cнижение времени задержки. Плюс ко всему, эти методы могут быть инкапсулированы в базовые библиотеки или подсистемы, что значительно упрощает структуру создаваемых приложений. Помимо обеспечения малого времени задержки в условиях крупных масштабов системы, они позволяют добиться большей загрузки (КПД) системы без принесения в жертву скорости реакции системы.
ссылка на оригинал статьи http://habrahabr.ru/post/168031/
Добавить комментарий