Продажи: 1-800-867-1389
Развернуть Свернуть

Безаварийность. Рекомендации по устойчивой облачной архитектуре

Обновлено: Июнь 2014 г.

Авторы: Марк Меркьюри (Marc Mercuri), Ульрик Хоманн (Ulrich Homann), Марк Симмс (Mark Simms), Джейсон Вэскотт (Jason Wescott) и Эндрю Таунхилл (Andrew Townhill)

Рецензенты: Майкл Томасси (Michael Thomassy), Курт Питерсон (Curt Peterson), Стюарт Озер (Stuart Ozer), Фрэн Доэрти (Fran Dougherty), Тим О'Брайен (Tim O’Brien), Хэтэй Туна (Hatay Tuna), Патрик Батлер Монтерде (Patrick Butler Monterde), Марк Коттке (Mark Kottke), Льюис Кертис (Lewis Curtis), Уильям Беллами (William Bellamy)

Дата публикации: июнь 2014 г.

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

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

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

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

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

В этом документе рассматриваются вопросы разработки масштабируемых и гибких систем.

Документ включает следующие разделы:

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

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

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

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

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

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

Приложения обычно состоят из нескольких рабочих нагрузок.

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

Чтобы лучше понять, что такое гибкость, полезно рассмотреть это понятие в контексте сценариев. Вот несколько примеров типовых сценариев.

  • Служба спортивных данных

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

  • Веб-сайт электронной коммерции

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

  • Социальные сети

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

  • Web

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

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

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

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

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

Модель жизненного цикла приложения определяет ожидаемое поведение приложения во время работы. На разных этапах и в разное время приложение предъявляет разные требования к системе как на функциональном уровне, так и на уровне масштабирования. Модель жизненного цикла будет это отражать.

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

Рисунок 1. Примеры жизненного цикла в разных отраслях и сценариях

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

  • Пиковое количество запросов во время праздников.

  • Растущее число налоговых деклараций по мере приближения срока уплаты налогов.

  • В утренние и вечерние часы-пик.

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

Многие организации учитывают эти типы сценариев и связанные жизненные циклы сценариев.

Декомпозиция позволяет иметь разные внутренние соглашения об уровне обслуживания на уровне рабочей нагрузки. Примером этого является API спортивных данных с целевым соглашением об уровне обслуживания 99,99 %. Тем не менее API можно разделить на две рабочих нагрузки: “Счет+комментарий в прямом эфире" и “Статистика команды, игрока и лиги”

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

Рис. 2

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

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

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

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

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

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

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

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

  • доступными и функциональными;

  • гибкими и быстро восстанавливаемыми после сбоя;

  • надежными в состоянии сбоя;

  • легко масштабируемыми посредством репликации;

  • автоматизированными.

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

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

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

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

Службы общедоступной облачной платформы

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

Вопросы, которые следует учитывать для этого типа службы:

  • Разрешает ли данная служба только определенное число запросов к API службы?

  • Ограничивает ли API службы частоту запросов к приложениям?

  • Ограничивает ли API службы число серверов, которые могут обращаться к ее приложениям?

  • Существует ли открытая информация о том, как служба реализует установленные задачи доступности?

  • Как эта служба сообщает о своем состоянии исправности?

  • Каковы основные положения соглашения об уровне обслуживания?

  • Есть ли у платформы службы, эквивалентные тем, которые предоставляются сторонними поставщиками?

Бесплатные службы сторонних поставщиков

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

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

Вопросы, которые следует учитывать для этого типа службы:

  • Разрешает ли данная служба только определенное число запросов к API службы?

  • Ограничивает ли данная служба частоту запросов к API службы?

  • Ограничивает ли API службы число серверов, которые могут обращаться к ее приложениям?

  • Существует ли открытая информация о том, как служба реализует установленные задачи доступности?

  • Как эта служба сообщает о своем состоянии исправности?

  • Каковы основные положения соглашения об уровне обслуживания?

  • Разрешает ли служба использовать необходимые функции или данные, расположенные у других поставщиков служб?

  • Предоставляет ли служба совместимый интерфейс для взаимодействия с другими поставщиками (напрямую или посредством промежуточного слоя)?

  • Есть ли у платформы службы, эквивалентные тем, которые предоставляются сторонними поставщиками?

Коммерческие службы сторонних поставщиков

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

Вопросы, которые следует учитывать для этого типа службы:

  • Разрешает ли данная служба только определенное число запросов к API службы?

  • Ограничивает ли данная служба частоту запросов к API службы?

  • Ограничивает ли API службы число серверов, которые могут обращаться к ее приложениям?

  • Существует ли открытая информация о том, как служба реализует установленные задачи доступности?

  • Как эта служба сообщает о своем состоянии исправности?

  • Каковы основные положения соглашения об уровне обслуживания?

  • Разрешает ли служба использовать необходимые функции или данные, расположенные у других поставщиков служб?

  • Предоставляет ли служба совместимый интерфейс для взаимодействия с другими поставщиками (напрямую или посредством промежуточного слоя)?

  • Есть ли у платформы службы, эквивалентные тем, которые предоставляются сторонними поставщиками?

Облачные службы сообщества

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

Вопросы, которые следует учитывать для этого типа службы:

  • Разрешает ли данная служба только определенное число запросов к API службы?

  • Ограничивает ли данная служба частоту запросов к API службы?

  • Ограничивает ли API службы число серверов, которые могут обращаться к ее приложениям?

  • Существует ли открытая информация о том, как служба реализует установленные задачи доступности?

  • Как эта служба сообщает о своем состоянии исправности?

  • Каковы основные положения соглашения об уровне обслуживания?

  • Может ли член сообщества пересмотреть соглашение об уровне обслуживания?

  • Разрешает ли служба использовать необходимые функции или данные, расположенные у других поставщиков служб?

  • Предоставляет ли служба совместимый интерфейс для взаимодействия с другими поставщиками (напрямую или посредством промежуточного слоя)?

  • Есть ли у платформы службы, эквивалентные тем, которые предоставляются сторонними поставщиками?

Основные внутренние корпоративные облачные службы

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

Вопросы, которые следует учитывать для этого типа службы:

  • Разрешает ли данная служба только определенное число запросов к API службы?

  • Ограничивает ли данная служба частоту запросов к API службы?

  • Ограничивает ли API службы число серверов, которые могут обращаться к ее приложениям?

  • Существует ли открытая информация о том, как служба реализует установленные задачи доступности?

  • Как эта служба сообщает о своем состоянии исправности?

  • Каковы основные положения соглашения об уровне обслуживания?

  • Может ли член организации пересмотреть соглашение об уровне обслуживания?

  • Разрешает ли служба использовать необходимые функции или данные, расположенные у других поставщиков служб?

  • Предоставляет ли служба совместимый интерфейс для взаимодействия с другими поставщиками (напрямую или посредством промежуточного слоя)?

  • Есть ли у платформы службы, эквивалентные тем, которые предоставляются сторонними поставщиками?

Основные облачные службы внутренних подразделений и департаментов

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

Вопросы, которые следует учитывать для этого типа службы:

  • Разрешает ли данная служба только определенное число запросов к API службы?

  • Ограничивает ли данная служба частоту запросов к API службы?

  • Ограничивает ли API службы число серверов, которые могут обращаться к ее приложениям?

  • Существует ли открытая информация о том, как служба реализует установленные задачи доступности?

  • Как эта служба сообщает о своем состоянии исправности?

  • Каковы основные положения соглашения об уровне обслуживания?

  • Может ли работник подразделения пересмотреть соглашение об уровне обслуживания?

  • Разрешает ли служба использовать необходимые функции или данные, расположенные у других поставщиков служб?

  • Предоставляет ли служба совместимый интерфейс для взаимодействия с другими поставщиками (напрямую или посредством промежуточного слоя)?

  • Есть ли у платформы службы, эквивалентные тем, которые предоставляются сторонними поставщиками?

Действительный процент доступности многокомпонентной службы

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

Доступность обычно выражается в процентных долях времени непрерывной работы в течение года. Выражаемый процент доступности называется количеством “девяток". Например, 99,9 представляет службу с “тремя девятками”, а 99,999 представляет службу с “пятью девятками".

 

Процент доступности

Время простоя за год

Время простоя за месяц

Время простоя за неделю

90 % («одна девятка»)

36,5 дней

72 часа

16,8 часа

95%

18,25 дней

36 часа

8,4 часа

97%

10,96 дней

21,6 часа

5,04 часа

98%

7,30 дней

14,4 часа

3,36 часа

99 % («две девятки»)

3,65 дней

7,20 часа

1,68 часа

99.5%

1,83 дней

3,60 часа

50,4 минут

99.8%

17,52 часа

86,23 минут

20,16 минут

99,9 % («три девятки»)

8,76 часа

43,2 минут

10,1 минут

99.95%

4,38 часа

21,56 минут

5,04 минут

99,99 % («четыре девятки»)

52,56 минут

4,32 минут

1,01 минут

99,999 % («пять девяток»)

5,26 минут

25,9 секунд

6,05 секунд

99,9999 % («шесть девяток»)

31,5 секунд

2,59 секунд

0,605 секунд

99,99999 % («семь девяток»)

3,15 секунд

0,259 секунд

0,0605 секунд

С обозначением доступности многокомпонентных служб в «девятках» связано распространенное заблуждение. Часто предполагается, что если какая-либо служба включает 5 служб, для каждой из которых по соглашению об уровне обслуживания гарантируется доступность 99,99 %, то результирующий процент доступности многокомпонентной службы будет равен 99,99. На самом деле это не так.

Рис. 3. Связь времени простоя с более распространенным обозначением в «девятках»

Совокупное соглашение об уровне обслуживания представляет собой результат вычисления, которое учитывает время простоя за год. Служба, для которой в соглашении об уровне обслуживания предписаны «четыре девятки» (99,99 %), может находиться вне сети не менее 52,56 минуты.

Если свести 5 служб с соглашением об уровне обслуживания 99,99 % вместе, то получается, что время простоя соглашения об уровне обслуживания может достигать 262,8 минуты или 4,38 часа. Это сокращает доступность до 99,95 % до того, как будет написана хотя бы одна строка кода!

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

noteПримечание
Некоторые службы могут предоставлять другие уровни обслуживания для разных цен или бизнес-партнеров.

Рассмотрите API спортивных данных, упомянутый ранее. Пользователи играют только в определенные дни и только в течение определенного количества часов. В это время соглашение об уровне обслуживания будет составлять 100 %. Если игры не запланированы, рабочая нагрузка будет иметь соглашение об уровне обслуживания 0 %. Шаблон жизненного цикла рабочей нагрузки “Статистика команды, игрока, лиги” более согласованный. Также для этой нагрузки существует требование всегда иметь соглашение об уровне обслуживания 99 %.

Рис. 4

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

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

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

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

Примеры точек сбоя:

  • подключения к базе данных;

  • подключения к веб-сайтам;

  • файлы конфигурации;

  • разделы реестра.

Категории распространенных точек сбоя:

  • списки управления доступом;

  • доступ к базам данных;

  • доступ к внешним веб-сайтам или службам;

  • Транзакции

  • Конфигурация

  • Емкость

  • Сеть

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

Примеры режимов сбоя:

  • отсутствующий файл конфигурации;

  • трафик значительно превышает возможности ресурса;

  • достигнут максимальный объем базы данных.

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

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

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

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

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

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

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

Чаще всего приходится устранять временные сбои. Так как ни одна служба не может обеспечить доступность в течение 100 % времени, следует предположить, что иногда попытки подключиться к службе, от которой зависит рабочая нагрузка, будут неудачными. Невозможность соединения со службой или сбои по одной из служб могут быть кратковременными (менее секунды) или постоянными (сбой на стороне поставщика).

Постепенное замедление производительности

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

Замечания по высокому уровню обслуживания для постепенного ухудшения качества обслуживания

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

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

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

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

  • Если выполнение запроса не критично для сценария, обработайте сбой, используя простое упущение.

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

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

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

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

Рекомендации по обработке временных сбоев

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

  • Логика повторных попыток

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

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

  • Экспоненциальное уменьшение числа запросов

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

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

    Такой подход называется экспоненциальным уменьшением числа запросов.

  • Идемпотентность

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

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

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

  • Методы компенсации

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

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

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

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

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

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

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

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

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

Размыкатель сети будет иметь три состояния: закрытое, открытое и полуоткрытое.

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

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

В полуоткрытом состоянии часть запросов будет направляться по обычному пути. Если они будут выполнены успешно, размыкатель цепи переключится в закрытое состояние. Если эта часть запросов завершится сбоем, размыкатель цепи вернется к открытому состоянию.

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

  • Размыкатель цепи может вызывать разные ограничения или разное время в открытом состоянии в зависимости от типа вызываемого исключения операции.

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

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

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

    • переход в открытое состояние при сбое только одного сегмента;

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

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

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

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

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

Пример размыкателя цепи: Netflix

Netflix, компания по потоковой передаче медиаконтента, часто приводится в качестве наиболее удачного примера устойчивой архитектуры. Специалисты компании называют несколько критериев, входящих в состав «автомата защиты». Его обсуждения в блоге Netflix Tech Blog. Они включают в себя следующее.

  1. Истечение времени ожидания для запроса к удаленной службе.

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

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

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

В той же записи блога команда Netflix указывает, что «автомат защиты» для каждой из их служб реализует переход на резервные варианты согласно одному из трех следующих подходов.

  1. Настраиваемый резервный метод — клиентская библиотека службы предоставляет вызываемый метод перехода на резерв. Либо для создания ответа перехода на резерв используются локально доступные на API-сервере данные (например, куки-файл или локальный кэш).

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

  3. Быстрый отказ — если данные обязательны или отсутствует подходящий резервный метод, клиенту возвращается код ответа 5xx. Этот подход ориентирован на сохранение работоспособности API-серверов и на возможность быстрого восстановления, когда затронутые службы возобновляют работу в сети, но это достигается за счет отрицательного влияния на взаимодействие клиента с пользователем.

Для выполнения соглашения об уровне обслуживания (SLA) организация должна определить, как она будет работать с двумя категориями нестандартных пользователей — с доверенными сторонами и с недобросовестными сторонами.

Доверенные стороны и список разрешений

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

  • Третьи стороны с нестандартными соглашениями

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

  • Список разрешений

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

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

  • Обработка недобросовестных сторон

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

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

  • Регулирование выделяемых ресурсов

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

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

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

  • Черный список

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

    Включение в список блокировок, как и в список разрешений, обычно производится либо по API-ключам, либо по диапазонам IP-адресов.

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

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

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

В сообществе DevOps существует мем — мультипликационный персонаж, который говорит: «Автоматизируйте все». В облаке доступ к большинству служб предоставляется через интерфейс API. Для большинства задач — от средств разработки до виртуализированной инфраструктуры, от служб платформ до решений, предоставляемых в формате SaaS (программное обеспечение как услуга) — можно написать скрипты.

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

Автоматизация развертывания

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

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

  • Изменения документов.

  • Разрешение на управление версиями.

  • Предоставление контроля доступа на основе ролей.

  • Обеспечение резервного копирования контента.

  • Предоставление единого истинного источника.

Создание и автоматизация окружения тестирования

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

Автоматизация архивирования и очистки данных

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

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

Используйте API-интерфейсы, доступные в связанных продуктах и услугах, для автоматизации реализации этих требований.

При построении устойчивой архитектуры важно понимание принципов доменов ошибок и доменов обновления.

Домены сбоя

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

Домены обновления

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

Обновления могут происходить на следующих уровнях.

  • Уровень низкоуровневой оболочки («обновление HostOS»).

  • Уровень операционной системы («обновление гостевой ОС»).

  • В результате развертывания приложения или обновления службы в среде.

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

Устойчивость во время сбоя домена сбоя во время обновления

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

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

Локальные решения часто задействовали избыточность и для обеспечения доступности и масштабируемости. С точки зрения доступности избыточные центры обработки данных позволили повысить вероятность обеспечения непрерывной деятельности в случае отказов инфраструктуры в определенном центре обработки данных или в секторе центра.

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

noteПримечание
Устойчивость данных, которая включает в себя избыточность, описывается в отдельном разделе главы «Реализация подхода к устойчивости данных».

Избыточность и облако

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

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

Избыточность развертывания

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

Если развертывание выполняется по схеме PaaS (платформа как услуга), то большая часть этой задачи может решаться самой платформой. Для модели IaaS (инфраструктура как услуга) это будет не так.

  • Развертывание N ролей в центре обработки данных

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

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

  • Развертывание в нескольких центрах обработки данных

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

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

    1. Полностью избыточные развертывания в нескольких центрах обработки данных

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

    2. Частичное развертывание во вторичных центрах обработки данных для отработки отказа

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

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

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

    3. Разделенные по нескольким центрам обработки данных развертывания с резервными узлами

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

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

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

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

Избыточность поставщиков

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

Исходя из соглашений об уровне обслуживания (SLA) для решения, также может быть желательным внедрение избыточности поставщиков. Для решения этой задачи необходимо определить, какие развертываемые в облаке продукты или облачные службы могут работать на многих облачных платформах. Например, Microsoft SQL Server может развертываться в виртуальной машине в предложениях IaaS (инфраструктуры как услуги) большинства поставщиков.

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

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

Локальная избыточность

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

Исходя из соглашений об уровне обслуживания (SLA) для решений, также может быть разумным реализовать локальную избыточность. Для реализации этой задачи необходимо определить, какие частные, развертываемые в облаке продукты или облачные службы будут работать с различными типами облаков. Как и в случае с избыточностью поставщиков, Microsoft SQL Server может служить хорошим примером продукта, допускающего локальное развертывание или развертывание в предложении IaaS (инфраструктура как услуга).

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

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

Подходы к конфигурации избыточности

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

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

  2. Активный/пассивный — предоставляет для каждого узла полностью избыточный экземпляр, который активируется в сети только при отказе связанного с ним основного узла. Для этой конфигурации обычно требуется максимальное количество дополнительного оборудования.

  3. N+1 — предоставляет один дополнительный узел, который активируется в сети в случае отказа другого узла и начинает выполнять его функции. В случае разнородной конфигурации программного обеспечения на каждом из основных узлов дополнительный узел должен обеспечивать возможность выполнения ролей каждого из первичных узлов. Это обычно относится к кластерам, в которых одновременно выполняется несколько служб; в случае одной службы эта конфигурация вырождается в обычную «активный/пассивный».

  4. N+M — в случаях, когда один кластер управляет многими службами, наличие одного выделенного резервного узла может не обеспечивать достаточную избыточность. В этом случае реализуется и доступно более одного (M) резервного сервера. Число резервных серверов является компромиссом между требованиями к экономичности и надежности.

  5. N-к-1 — позволяет резервному узлу временно стать активным, пока не будет восстановлен или не вернется в сеть исходный узел, после чего необходимо произвести обратную отработку отказа, чтобы восстановить высокий уровень доступности.

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

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

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

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

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

Декомпозиция и секционирование

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

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

Стратегии секционирования часто могут основываться на выбранных технологиях.

При определении стратегии также важно идентифицировать нестандартных пользователей, для которых может потребоваться измененная или параллельная стратегия. Например, если вы разрабатывали сайт социальной сети, обычный пользователь мог иметь 500 подключения, тогда как знаменитость — 5 000 000.

Если сайт предназначен для 100 млн пользователей, из которых знаменитости составляют менее 50 000, основная стратегия секционирования будет оптимизирована для стандартного пользователя. Управление знаменитостями будет происходить по-другому. Тогда как большое количество пользователей можно объединить в группу одного раздела, знаменитость следует поместить в собственный раздел.

Основные сведения о трех «V»

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

Популярный подход «трех "V"», разработанный компанией Gartner, учитывает три различных аспекта данных. Основные сведения о взаимосвязи этих трех «V» с вашими данными помогут принять осведомленное решение по стратегии секционирования.

  • Объем (Volume)

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

  • Скорость (Velocity)

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

  • Разнообразие (Variety)

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

Горизонтальное секционирование

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

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

Рис. 5. Пример горизонтального секционирования по фамилии

Вертикальное секционирование

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

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

Рис. 6. Пример вертикального секционирования

Гибридное секционирование

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

Пример подхода показан на рис. 6, где вертикальное секционирование, рассмотренное ранее, дополняется использованием преимуществ горизонтального секционирования метаданных клиента.

Рис. 7. Пример горизонтального секционирования

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

Эти сетевые границы подробно описаны ниже; чтобы обеспечить контекст, примером платформы служит Azure.

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

  2. Границы служб представляют зависимости от функциональности, предоставляемой другими службами. Типичными примерами может служить среда SQL для доступа к реляционным базам данных и к службе Service Bus для поддержки обмена сообщениями pub/sub. В Azure, к примеру, границы служб назначаются через сеть: зависимость службы может не быть частью той же сети или среды контроллера структуры. Это может произойти, но для любого защищенного приложения должно конструктивно предполагаться, что любая зависимость службы размещена в другой сети, управляемой другим контроллером структуры.


    Рис. 8

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

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

Кэширование

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

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

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

Кэширование устройств

Хотя кэширование устройств не является важным аспектом инициативы FailSafe, оно является одним из самых эффективных способов повышения удобства использования и устойчивости любого приложения из устройств и служб. Существуют многочисленные способы предоставления услуг кэширования на уровне устройств или клиентов, начиная со спецификации HTML5, которая определяет собственные функции кэширования, реализованные во всех стандартных браузерах, и заканчивая локальными экземплярами баз данных, такими как SQL Server Compact Edition или подобными.

Распределенное кэширование

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

  • Информационные модели, оптимизированные для кэширования

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

    Кэшированные данные по своей природе являются устаревшими, т. е. это данные, не всегда являющиеся актуальными. Яркий пример кэшированных данных (хотя и относящийся к другой сфере) — это каталог товаров, который рассылается тысячам домовладельцев. Данные, используемые при публикации каталога товаров, были актуальными на момент публикации. Как только каталог вышел из печатного станка, данные в нем устарели, поскольку производственный процесс занимает определенное время. Так как кэшированные данные устаревают, атрибуты данных относительно стабильности и сингулярности являются критическими для схемы кэширования.

    • Стабильность. Данные, имеющие недвусмысленную интерпретацию в пространстве и времени. Часто под этим подразумеваются значения неизменяемых данных. Например, большинство предприятий не применяют идентификаторы заказчиков или номера SKU повторно. Другая возможность создания стабильной базы — указывать срок хранения существующих данных. Пример каталога товаров, упомянутый выше, очень подходит. Обычно розничные компании принимают заказы по любому каталогу в течение двух периодов публикации. Если каталог публикуется 4 раза в год, то данные в каталоге товаров являются стабильными в течение 6 месяцев, при этом их можно использовать для обработки информации, в том числе для размещения и исполнения заказов.

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

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

      Выделяемые данные, в соответствии с приведенным выше описанием, являются операционными данными или данными сеанса.

      С учетом этих двух характеристик можно составить следующую схему.


      Рис. 9

  • Информационное моделирование

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

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

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

      Хорошим примером того, как сокрытие информации используется для эффективного повышения параллелизма, является разница между типичной ERP-системой и тем, как Amazon.com управляет большинством складских процессов. В типичной реализации ERP-системы таблица складского учета является одной из самых перегруженных или «горячих» таблиц (если предположить, что реализована реляционная база данных). ERP-приложение обычно пытается заблокировать реестр товаров до того момента, когда пользователь закончит работу, и в момент начала бизнес-операции предоставляет приложению точный счетчик реестра. Некоторые системы, например SAP, не блокируют базу данных, но используют блокировку приложения в системе управления очередями. Были разработаны многочисленные методы на уровне базы данных для устранения этой перегрузки: оптимистическое управление параллелизмом, чтение «грязных» данных и т. д. Ни один из них не работает действительно безукоризненно, все имеют те или иные побочные эффекты. В некоторых случаях действительно требуется заблокировать таблицу, но число подобных случаев должно быть минимальным.

      Решение проблемы от Amazon.com гораздо проще: пользователю предоставляется цель уровня обслуживания (SLO), которую пользователь может принять или отклонить. Цель уровня служб представляла собой «обычно доступное множество в течение N часов», при этом пользователь не видел реального количества доступных книг или других товаров, однако получал общие сведения о доступности. Блокировка базы данных не требовалась. Фактически не требовалось и само подключение к базе данных. Если система не может выполнить цель SLO, покупатель получает электронное сообщение с извинениями и предложением обновления цели SLO.

    • Взаимозаменяемые ресурсы. В словаре дается следующее определение взаимозаменяемости: «Взаимозаменяемое (особенно о товарах) — предоставляющее возможность полной или частичной замены на что-либо схожее по характеристикам или типу». Если целью является повышение эффективности доступа к общим данным, то суть идеи заключается в использовании информационного моделирования как способа взаимодействия пользователя с взаимозаменяемым экземпляром данных вместо определенного экземпляра. В качестве примера можно привести бронирование номера в отеле. Можно указать множество деталей, в том числе количество кроватей, вид на океан, номер для курящих или некурящих и т. д., не указывая при этом номер «123». При использовании такого моделирования можно кэшировать информацию о пулах взаимозаменяемых данных, исполнять бизнес-процессы относительно пула и только после фактического заезда выдавать конкретный номер из пула. Гибридные модели с удалением определенного номера из пула в начале процесса заезда также возможны.

  • Управление кэшем

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

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

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

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

Хотя такая платформа, как Azure, гарантирует сохранение множества копий данных (для некоторых служб возможно также геодублирование), однако сохраняемые данные зависят от приложения, рабочей нагрузки и служб компонентов. Если приложение выполнит какое-либо действие и повредит данные, платформа сохранит несколько копий таких данных.

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

Корректировка на уровне приложения

  • Идемпотентность

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

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

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

  • Действия рабочей нагрузки и метод компенсации

    Помимо идемпотентности, есть смысл предусмотреть логику компенсации.

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

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

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

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

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

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

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

Резервные копии

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

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

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

  • Реляционные базы данных

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

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

    1. Полное резервное копирование. Предусматривает резервное копирование всего хранилища. Полное резервное копирование должно выполняться по расписанию в соответствии с объемом данных и скоростью их изменения. Полная резервная копия — это полный набор данных, которые могут потребоваться в соответствии с соглашением об уровне обслуживания для службы. Механизмы для этого типа резервного копирования предоставляются поставщиком базы данных или службы базы данных либо ее экосистемой.

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

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

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

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

      Шаблоны синхронизации могут быть следующими:

      — центр обработки данных с центром обработки данных определенного облачного поставщика;

      — центр обработки данных с центром обработки данных в облаке поставщиков;

      — центр обработки данных с центром обработки данных из локального хранилища к определенному облачному поставщику;

      — синхронизация центра обработки данных с устройством по определенным пользовательским срезам данных.

  • Сегментированные реляционные базы данных

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

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

  • Хранилища данных NoSQL

    Предусмотреть политику резервного копирования рекомендуется не только для реляционных хранилищ данных, но и для хранилищ данных NoSQL (не только SQL). Наиболее популярная форма баз данных NoSQL обеспечивается основными облачными поставщиками и основывается на хранении пар «ключ-значение» высокого уровня доступности, которые также называют табличным хранилищем.

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

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

    В зависимости от возникающих задач реплику можно разместить у того же облачного поставщика, в том же дата-центре или в том же хранилище данных, не связанном с SQL. Реплика также может располагаться в другом дата-центре, у другого облачного поставщика или в хранилище данных NoSQL другого типа. Необходимость такого размещения во многом обуславливается желаемым соглашением об уровне обслуживания и соображениями соответствия специфическим требованиям.

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

    noteПримечание
    Таблица подстановки становится потенциальным камнем преткновения, поэтому гибкое планирование должно предусматривать реплику такой таблицы.

  • Хранилище больших двоичных объектов

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

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

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

  • Восстановление резервной копии

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

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

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

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

Надлежащее использование сети доставки контента

Распространенное заблуждение заключается в том, что некоторые считают сети доставки контента панацеей для масштабирования. В одном случае заказчик был уверен, что это было верное решение для магазина книг в сети. Оказалось, что это не так. С чем было связано это заблуждение? В каталоге на миллион книг есть небольшое подмножество наиболее популярных книг (так называемых «хитов») и огромный список книг, по которым запросы поступают крайне непредсказуемо. Наиболее популярные книги копировались на локальный узел при первом запросе и обеспечивали низкозатратное локальное масштабирование и удобство работы пользователя. Длинный список менее популярных книг по каждому запросу копировался дважды: один раз на локальный узел и после этого заказчику, так как нерегулярные запросы приводили к регулярному истечению срока действия содержимого. Это доказывает, что неверное использование сети доставки контента создает обратный эффект — более медленное и более затратное решение.

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

Группы разработчиков часто забывают об «исправности» приложения, а иногда совсем не принимают ее во внимание. В результате службы часто начинают работать только в двух известных состояниях: включена или выключена. Разработчики гибких служб должны предусматривать такие модели производительности, которые определяли бы критерии производительности приложений, состояние, сбой и зависимость производительности.

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

Определение характеристик

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

Определение интерфейсов

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

  • Рассылка сведений о состоянии подписанным партнерским службам.

    Служба должна передавать сведения об исправности подписанным партнерским службам. Сведения о состоянии должны быть краткими и содержать всю необходимую базовую информацию.

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

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

  • Разработка интерфейсов для доставки телеметрических данных

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

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

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

  • Разработка интерфейсов для получения от службы дополнительных сведений о состоянии производительности

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

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

  • Разработка интерфейсов для устранения ошибок на уровне службы и приложения

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

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

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

Телеметрия — это «процесс использования специального оборудования для оценки чего-либо (например. давления, скорости или температуры) и отправки их по радио в другое место».

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

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

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

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

Телеметрия инфраструктуры включает сведения об исправности базовой инфраструктуры системы. Сюда могут входить данные о ресурсах, такие как ЦП, память, сеть, доступная емкость и т. д.

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

Сначала определите, является целью сбора данных проинформировать или инициировать действие. Вопрос, который нужно задать, — «как быстро следует реагировать?» Вы будете использовать данные в режиме реального времени для возможной инициации действия? Или вы будете использовать данные в месячном отчете по анализу тенденций? Ответы на эти вопросы позволят найти метод телеметрии и технологии, использованные в архитектуре.

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

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

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

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

После определения метода телеметрии перейдите к характеристикам сигнала.

Можно классифицировать сигнал как непрерывный или скрытый. Примером непрерывного сигнала являются данные событий в режиме реального времени. Записи файла журнала — это часть скрытого сигнала.

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

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

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

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

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

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

На этих устройствах могут быть разные типы подключений (WiFi, LTE, 4G, 3G ит. д.), и эти подключения могут изменяться. Подключение устройства в настоящий момент важно для определения того, какие данные следует передать. В сценариях, где подключение ненадежно или у него низкая скорость, политика может установить приоритет для передаваемой телеметрии.

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

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

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

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

Рис. 10

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

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

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

  • Устранение неполадок.

  • Аварийное устранение неполадок на сайте в режиме реального времени.

  • Обучение новых сотрудников по работе с операциями.

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

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

Рис. 11

Рис. 12

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

См. также

Была ли вам полезна эта информация?
(1500 символов осталось)
Спасибо за ваш отзыв
Показ:
© 2014 Microsoft