Выпусти это! Разработка и развертывание готового программного обеспечения

Майкл Т. Нигард, 2007, ISBN: 978-0-9787-3921-8

Мой дайджест и обзор книги.

Рассмотрение

Из книг, которые я прочитал,  выпусти это!  это то, что мне нужно прочитать всем «старшим» разработчикам (вместе с чем-то вроде « Архитектурные решения для предприятий: шаблоны для высокопроизводительных интернет-систем» ). Особенно первую часть о стабильности с ее шаблонами и анти-шаблонами необходимо прочитать. Не зная и не применяя их, мы создаем системы, которые реагируют на такие проблемы, как сухая саванна или горящая спичка. Рядом с предыдущей главой я также обнаружил, что очень ценно прозрачность № 17, особенно метрики и дизайн OpsDB и практики наблюдения.

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

Дополнительные ссылки

• Выпусти это! слайды:  http://gotocon.com/dl/jaoo-sydney-2009/slides/MichaelT.Nygard_FailureComesInFlavoursPart2.pdf
• https://github.com/Netflix/Hystrix/
• Команда зависимости Netflix рассказывает об использовании автоматических выключателей и ограничении пула потоков http://techblog.netflix.com/2012/02/fault-tolerance-in-high-volume.html
• Руководство по MSDN для облачных приложений: шаблоны проектирования  — автоматический выключатель и многие другие очень полезные шаблоны

стабильность

Стабильность х долголетия ошибок

Стабильность антипаттернов

Точки интеграции

Точка интеграции = вызов БД, WS,…. Риск стабильности № 1.

• Каждый в конечном итоге потерпит неудачу
• Много возможных ошибок: сеть, приложение,…
• Симптомы: нарушение протокола, медленный ответ, зависание, внезапно закрытые соединения,…
• Будьте осторожны, чтобы избежать каскадных сбоев, когда в удаленной системе возникают проблемы — автоматический выключатель, тайм-ауты, разъединение промежуточного программного обеспечения, рукопожатие; используйте Test Harness для тестирования
• Пример: в соединениях отказано (поймать: может потребоваться  много  времени, чтобы выяснить, что вы не можете подключиться, например, когда он прослушивает, но не может обработать запросы или когда ACK не приходят и он продолжает повторять попытки); брандмауэр может выбросить старое соединение, никому не сказав, молча отбрасывая пакеты

Цепные реакции

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

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

Каскадные сбои

= проблемы в одном слое вызывают проблемы у абонентов — часто из-за истощенных пулов ресурсов

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

пользователей

• Пользователи используют память => минимизируют размер сеанса, используют сеанс только для кэширования, чтобы вы могли очистить его содержимое, если объем памяти будет ограничен (и заново создавать при необходимости). F.ex. в Java используйте SoftReferences. Остерегайтесь того, что сеанс длится до последнего взаимодействия + время ожидания, которое по умолчанию составляет 30 минут (умножьте это на слишком много пользователей…)
• Пользователи делают странные, случайные вещи, не ожидайте, что они будут вести себя так, как вы ожидаете; если будет слабое место, они его найдут
• Вредные пользователи всегда в курсе последних событий, предотвращают внедрение SQL и т. Д.
• Иногда пользователи приходят в действительно, очень большие мобы => зависания, тупики, непонятные условия гонки; запустить специальные стресс-тесты, чтобы забить глубокие ссылки или горячие URL
• Остерегайтесь искусственных пользователей, таких как боты и индексирующие пауки — они делают много запросов в одно мгновение, могут игнорировать куки (=> каждый из них приводит к новому сеансу)

Заблокированные темы

• f.ex. При извлечении ресурсов из пула соединений, работе с кешами или реестрами объектов, совершении вызовов во внешние системы или синхронизации потоков
• Шаблон заблокированных потоков является непосредственной причиной большинства сбоев; привести к цепным реакциям и каскадным сбоям
• Исследовать пулы ресурсов — потоки часто блокируются на них; f.ex. тупик в БД или неправильная обработка исключений (и, следовательно, сбой соединения)
• Используйте проверенные примитивы для параллелизма вместо создания своих собственных (см.  java.util.concurrent)
• Защищайтесь с помощью таймаутов, чтобы тупик не длился вечно — всегда используйте их
• Остерегайтесь кода, который вы не видите — например, в библиотеках

Атаки самоотречения

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

• Будьте в курсе — убедитесь, что если есть маркетинговая кампания, вы об этом знаете. Убедитесь, что он не использует глубокие ссылки (в обход вашего кеширующего прокси), следите за нашими встроенными идентификаторами сеансов в URL. Создайте статические страницы «посадочной зоны» для первого клика из этих предложений.
• Защита общих ресурсов в случае скачков трафика. Не упустите повышенную нагрузку на интерфейс, вызывающую экспоненциально увеличивающуюся обработку.
• Ожидайте быстрое перераспределение (то есть широкое и широкое распространение) любого интересного или ценного предложения — такого понятия, как распространение среди ограниченного набора пользователей, не существует.

Масштабирующие эффекты

То, что работало в небольших масштабах, приводит к проблемам при масштабировании системы. Всякий раз, когда у нас есть отношения «многие к одному» или «многие к немногим», мы можем столкнуться с проблемами, когда увеличивается сторона «больше», например сбой БД при переходе от 2 БД AS — 1 к 10 БД AS — 1. Распространенной проблемой является двухточечное общение.

• Изучите различия в масштабах между производственной средой и средой контроля качества, чтобы определить эффекты масштабирования — шаблоны, которые отлично работают в небольших средах или в средах «один на один», могут замедляться или полностью отказывать при переходе к рабочим размерам
• Следите за двухточечным общением — оно плохо масштабируется, так как число соединений увеличивается по мере увеличения площади участников
• Не упустите общие ресурсы — они могут быть узким местом, ограничением емкости и угрозой стабильности. Если у вас есть, стресс-тест это сильно. Удостоверьтесь, что его клиенты продолжат работать, если это замедляется или блокируется.

Несбалансированные возможности

UC — это особый случай Scaling Effects: одна сторона отношения масштабируется намного больше, чем другая сторона. Пример: многие веб-серверы, которые обычно обслуживают в основном статический контент и только несколько динамических страниц, предоставляемых внутренними серверами; если структура трафика (рабочая нагрузка) внезапно изменится, т. е. многие пользователи переходят к динамическим функциональным возможностям, внешние серверы затопят несколько внутренних. Возможно, было бы нецелесообразно сопоставлять их возможности для редких всплесков, поэтому создайте их обоих, чтобы они были устойчивыми перед лицом цунами запросов. Для внешнего интерфейса автоматический выключатель поможет сбросить давление на внутреннем конце, когда отклики замедляются или в соединениях отказывают. Для серверной части используйте Handshaking, чтобы сообщить клиенту о необходимости дросселировать запросы. Также рассмотрите возможность перегородки зарезервировать емкость на сервере для других типов транзакций.

• Изучите, сравните количество серверов и потоков, особенно в Prod vs. QA
• Наблюдайте за близкими эффектами масштабирования и пользователями
• Подчеркните обе стороны интерфейса; если вы бьете серверную часть с 10 * большим количеством запросов, чем в историческом максимуме, для самой дорогой транзакции, произойдет ли сбой или замедлится и в конечном итоге восстановится? Что делает интерфейс, когда сервер перестает отвечать или становится очень медленным?

Медленные ответы

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

• Медленные отклики запускают каскадные сбои, восходящая система слишком замедляется и становится уязвимой для проблем стабильности
• Для веб-сайтов медленные ответы вызывают больше трафика, так как пользователи нажимают «перезагрузить»
• Рассмотрим Fail Fast — например, если ваш SLA требует ответа в 100 мс, а скользящее среднее за последние 20 вызовов превышает его, вы можете начать отклонять запросы (для этого должна быть подготовлена ​​вышестоящая система)
• Охота на утечки памяти или нехватку ресурсов (например, слишком мало соединений с БД)

SLA Inversion

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

Решение: 1) Отсоедините от систем более низкого SLA, чтобы ваше приложение могло продолжать работать без них, изящно ухудшаться. Развязка промежуточного программного обеспечения отлично подходит для этого. По крайней мере, используйте автоматические выключатели для защиты от ваших зависимостей. 2) Определить реалистичный SLA и вместо всей системы сосредоточиться на доступности определенных функций / функций с их зависимостями.

Пример: разрешить клиентам продолжать покупки, даже если расписание доставки недоступно.

• Для каждой службы ваша система зависит от доступности транспортного уровня, служб имен (DNS) и протоколов уровня приложений, и любой из них может дать сбой.
• Если построено наивно, вероятность отказа вашей системы является общей вероятностью отказа в любом компоненте или услуге, поэтому P (вверх) = (1 — P (внутренний отказ)) * P (зависимость 1 вверх) *… * P ( Зависимость N вверх). Таким образом, для пяти зависимостей с доступностью 99,9% мы можем получить не более 99,5%.

Неограниченные наборы результатов

«Дизайн со скептицизмом, и вы достигнете. Спросите: «Что может сделать система X, чтобы причинить мне боль?» а затем придумайте способ уклоняться, нырять, опускаться, нырять и уклоняться от любого рывка, который выкинет ваш предполагаемый союзник. p95 Одной из этих систем является ваша БД — что если она вдруг возвращает 5M строк вместо обычных сотен?

• Используйте реалистичные объемы данных в тестировании / dev
• Не полагайтесь на производителей данных для создания ограниченного объема данных
• Установите ограничения для других протоколов уровня приложений: вызовы WS, RMI, XML-RPC и т. Д. — все они уязвимы для возврата огромных коллекций объектов, что потребляет слишком много памяти (и продолжает работать еще долго после того, как пользователь потерял интерес)
• Неограниченные наборы результатов являются частой причиной медленных ответов; они могут возникнуть в результате нарушения устойчивого состояния

Шаблоны стабильности

Использовать тайм-ауты

Редко хочется ждать вечно (или много минут).

• Применить к точкам интеграции, заблокированным потокам и медленным ответам; они препятствуют тому, чтобы вызовы I.Points становились заблокированными T. и таким образом предотвращали Cascading Failure.
• Совместите с автоматическим выключателем (срабатывает при слишком большом количестве) и Fail Fast (чтобы сообщить вызывающим абонентам, что вы не можете обрабатывать запросы).
• Подайте заявку на восстановление после неожиданных сбоев — когда операция занимает слишком много времени, нам иногда все равно, почему, нам просто нужно сдаться и продолжать двигаться
• Рассмотрим отложенные повторные попытки — проблемы с сетью или удаленной системой, вызывающие их, не будут решены сразу, поэтому немедленные повторные попытки только усугубляют ситуацию и заставляют пользователя еще дольше ждать неизбежного ответа на сбой.

Пример HttpClient: RequestConfig.custom()
.setConnectionRequestTimeout(1000).setConnectTimeout(1000).setSocketTimeout(1000).build();

Выключатель

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

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

• Не делайте этого, если это больно — CB является фундаментальной схемой защиты вашей системы от всевозможных проблем точек интеграции. Когда с ними возникнут трудности, перестаньте их называть!
• Используйте вместе с таймаутами
• Выставлять, отслеживать и сообщать об изменениях своего состояния в Ops

 Страница шаблона автоматического выключателя MSDN довольно хороша. Представление Мартина Фаулера Circuit Breaker  с простым примером реализации на Ruby и полезными ссылками.

try { ... }
finally {
if (stmt != null) stmt.close();
if (conn != null) conn.close();
}

         *|-|*
     /-1-Node-*-(needs)*-Feature
   *|
Observation-*-1-Observation Type
    |
    - one of Measurement, Event, Status

    /-1-ObservationType
   1|
Expectation-*-1-ExpectationType
    |
    - one of NominalRange, ExpectedTime, ExpectedStatus