Надежность в сложных системах: анот

nadezhnost v slozhnyh sistemah anot

Сегодня мы рассмотрим статью под названием «Надежность в сложных системах», опубликованную в 2001 году Стивеном Д. Грибблом. Все цитаты и цифры взяты из бумаги.

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

«Общая парадигма проектирования» относится к практике прогнозирования среды, в которой система будет работать, и режимам ее сбоев. В документе утверждается, что система будет иметь дело с условиями, не предусмотренными, когда она станет более сложной, поэтому ее следует разработать так, чтобы изящно справляться с неудачами. В статье исследуются эти идеи с помощью «распределенных структур данных (DDD), масштабируемого кластерного сервера хранения».

По своей природе, большие системы функционируют благодаря сложному взаимодействию многих компонентов. Это взаимодействие приводит к повсеместному сцеплению элементов системы; эта связь может быть сильной (например, пакеты, посылаемые между смежными маршрутизаторами в сети) или едва заметными (например, синхронизация рекламных объявлений маршрутизации в глобальной сети).

Общей характеристикой таких больших систем есть то, что называется эффектом бабочки. Это относится к небольшому неожиданному нарушению в системе в результате сложного взаимодействия различных компонентов, что вызывает широкие изменения.

Общей целью проектирования системы является надежность: способность системы правильно работать в разных условиях и выходить из строя в неожиданной ситуации. Статья выступает против общепринятой модели попытки предусмотреть определенный набор условий работы системы и ее архитектуры, чтобы хорошо работать в только те условия.

Кроме того, фактически невозможно предусмотреть все возмущения, которые испытывает система в результате изменений условий окружающей среды, таких как аппаратные сбои, всплески нагрузки или внедрение неправильного программного обеспечения. Учитывая это, мы считаем, что любая система, пытающаяся получить надежность исключительно с помощью предварительного познания, подвержена хрупкости.

DDS: практический пример

Вышеизложенная гипотеза исследуется с помощью масштабированной системы хранения на основе кластеров, распределенных структур данных (DDD) — «виртуальной хэш-таблицы высокой емкости с высокой пропускной способностью, которая разделена и реплицирована на многих отдельных узлах хранения, называемых блоками».

pCMHFuUnLdELprmvHYYW8ZuJ4F-3bKymp1YJ

Эта система была построена с использованием философии прогнозного проектирования, как описано выше.

Опираясь на большой опыт работы с такими системами, мы попытались обосновать поведение программных компонентов, алгоритмов, протоколов и аппаратных элементов системы, а также получаемые рабочие нагрузки.

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

Далее мы поговорим о нескольких таких аномалиях.

Трешивание по сбору мусора и ограниченная синхронность

Разработчики системы использовали тайм-ауты для обнаружения сбоя компонентов в системе. Если определенный компонент не соответствовал в течение указанного времени, то он считался мертвым. Они предполагали ограниченную синхронность в системе.

DDS был реализован на Java, потому использовал сбор мусора. Собиратель мусора в нашей JVM был собирателем «обознач и подметай»; в результате, поскольку больше активных объектов находилось в куче JVM, продолжительность работы сборщика мусора для восстановления фиксированного объема памяти увеличилась.

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

9dhVsogmVj7xeTLMrAC-MB4iE7RjXYZE2hXF

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

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

Однако это предположение было нарушено, когда они столкнулись с условием гонки в своем коде, которая повлекла утечку памяти, не влияя на правильность.

Каждый раз, когда мы запускали нашу систему, мы стремились запускать все блоки одновременно. Учитывая примерно сбалансированную нагрузку по всей системе, все блоки исчерпают пространство в куче почти одновременно, через несколько дней после их запуска. Мы также предположили, что наши автоматические механизмы восстановления после отказа усугубили эту ситуацию, увеличивая нагрузку на реплику после сбоя однорангового узла, увеличивая скорость, с которой реплика пропускала память.

Поскольку все реплики подвергались равномерной нагрузке без учета снижения производительности и других проблем, это создало связь между репликами и…

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

Непроверенные зависимости и остановка ошибок

Основываясь на предположении, что если время ожидания компонента истекло, он произошел из строя, разработчики также допустили «сбой-стоп», то есть вышедший из строя компонент не возобновит работу через некоторое время. Блоки в системе выполняли всю работу с длительной задержкой (дисковый ввод/вывод) асинхронным способом.

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

Хотя эта ошибка возникла из-за нашей собственной неспособности проверить поведение используемого нами кода, она служит для демонстрации того, что низкоуровневое взаимодействие между независимо созданными компонентами может иметь серьезные последствия для общего поведения системы. Очень незначительное изменение в поведении привело к нарушению нашего предположения об остановке отказов во всем кластере, что привело к повреждению данных в нашей системе.

На пути к надежным системам

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

Несколько решений, которые могут помочь нам сделать более надежные системы:

Систематическое избыточное обеспечение

При приближении к точке насыщения системы, как правило, становятся хрупкими, пытаясь приспособиться к неожиданному поведению. Один из способов борьбы с этим – умышленное чрезмерное обеспечение системы.

eOxFAEt5Vdd1dOchH6GpyfpXb2-ZXKOHLcwx

Однако это имеет свои проблемы: это приводит к недостаточному использованию ресурсов. Это также требует прогнозирования ожидаемой рабочей среды и, следовательно, точки насыщения системы. В большинстве случаев это невозможно сделать точно.

Используйте контроль допуска

Другая техника состоит в том, чтобы начать отклонять нагрузку, когда система начинает приближаться к точке насыщения. Однако для этого нужно предусмотреть точку насыщения — то, что не всегда возможно, особенно в больших системах, имеющих много переменных, способствующих этому.

Отклонение запросов также потребляет некие ресурсы системы. Сервисы, разработанные на основе контроля доступа, обычно имеют два режима работы: обычный, при котором запросы обрабатываются, и чрезвычайно упрощенный режим, при котором они отклоняются.

Встройте в систему интроспекцию

Интроспективная система – это система, в которой возможность мониторинга системы разработана с самого начала.

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

Введите адаптивность, замкнув контур управления

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

Эти системы включают результаты интроспекции и пытаются динамически адаптировать управляющие переменные, чтобы система работала в стабильном или хорошо производительном режиме.

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

План на провал

Сложные системы должны ожидать неудачи и, соответственно, планировать их.

Несколько приемов для этого:

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

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

Эта другая парадигма проектирования — это парадигма, в которой системам предоставляется наилучший шанс на стабильное поведение (из-за таких методов как чрезмерное обеспечение, контроль допуска и интроспекция), а также способность адаптироваться к неожиданным ситуациям (рассматривая интроспекцию как обратную связь к замкнутому контуру. управление). В конце концов, системы должны быть разработаны так, чтобы утонченно справляться с отказами, поскольку сложность, кажется, приводит к неизбежной непредсказуемости.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *