Поделиться через

Перспектива фреймворка Well-Architected в диспетчере трафика Azure

  • Статья

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

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

Важный

Как использовать это руководство

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

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

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

области технологий

В этом обзоре рассматриваются взаимосвязанные решения для следующего ресурса Azure:

  • Диспетчер трафика

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

Заметка

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

По сравнению с Azure Front Door, Traffic Manager легче в настройке, конфигурации и обслуживании. Диспетчер трафика не имеет конечной точки, которую можно контролировать напрямую. В отличие от Front Door, который обрабатывает запросы клиентов, диспетчер трафика подключает только клиентов к конечной точке рабочей нагрузки.

Но эта простота поставляется с компромиссами, которые могут привести к сложностям в архитектуре. Например, может потребоваться реализовать дополнительные меры безопасности для блокировки типов атак Open Worldwide Application Security Project (OWASP). Брандмауэр веб-приложения (WAF) в Azure Front Door или шлюзе приложений Azure предоставляет эту возможность. Или вы можете добавить кэш, который может ускорить доставку содержимого, но добавляет сложность, так как необходимо управлять хранилищем данных.

Дополнительные сведения см. в документе Перспектива фреймворка наAzure Front DoorWell-Architected.

Надёжность

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

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

Контрольный список дизайна

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

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

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

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

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

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

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

  • Оцените длительность кэширования ответов DNS. Параметр времени жизни (TTL) для запросов DNS в Traffic Manager определяет, сколько времени нижестоящие резолверы DNS кэшируют ответы DNS. Срок жизни по умолчанию может привести к более длительному кэшированию, чем необходимо, что может привести к простою, если конечная точка завершается ошибкой. Уменьшите время жизни TTL, чтобы увеличить частоту обновлений кэша. Этот метод может помочь снизить время простоя, но увеличивает частоту запросов к DNS.

  • Избегайте отправки трафика в неработоспособные или скомпрометированные экземпляры. Просмотрите встроенные функции проверки работоспособности в диспетчере трафика.

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

    Для других приложений диспетчер трафика использует протокол управления передачей (TCP) для определения доступности конечной точки.

    Дополнительные сведения см. в статье Шаблон мониторинга конечных точек работоспособности и Анализ проб диспетчера трафика.

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

  • Включите конечные точки в тестирование на отказоустойчивость. Имитируйте недоступные конечные точки, чтобы узнать, как диспетчер трафика обрабатывает сбои. Предположим, что рабочая нагрузка использует подсистему балансировки нагрузки, например Шлюз приложений в частной виртуальной сети. Правила группы безопасности сети (NSG) можно использовать в Azure Chaos Studio для имитации сбоев конечной точки. Вы можете заблокировать доступ к подсети, в которой находится шлюз приложений.

Рекомендации

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

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

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

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

— Не включите AlwaysServe, которая отключает мониторинг конечных точек и отправляет запросы в конечную точку независимо от состояния работоспособности.
— задайте значение probing interval. Рассмотрим компромисс между тем, насколько быстро можно обнаружить сбои и количество запросов к конечной точке. Количество запросов может быть значительным, так как Traffic Manager — это глобальная служба, которая одновременно пингуется из разных локаций.
— задайте значение probe timeout. Рассмотрим, в течение какого времени ждать, прежде чем объявлять конечную точку неисправной. Включите ложные срабатывания в число сбоев.		 Проверки работоспособности обеспечивают, что только здоровые экземпляры обслуживают запросы пользователей. Они также помогают определить, не являются ли сбои непереходящими и насколько быстро должно происходить переключение на резерв.

Безопасность

Цель компонента "Безопасность" — обеспечить конфиденциальности, целостности и доступности гарантии рабочей нагрузки.

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

Контрольный список дизайна

  • Просмотрите базовые показатели безопасности. Чтобы повысить уровень безопасности, просмотрите базовые показатели безопасности для диспетчера трафика.

  • Запретить несанкционированное изменение маршрутизации трафика. Учитывайте профили диспетчера трафика как критически важные ресурсы рабочей нагрузки, так как они содержат параметры конфигурации для маршрутизации трафика. Доступ к этим профилям должны иметь только авторизованные идентификаторы. Реализуйте управления доступом на основе ролей (RBAC) на уровне управления, чтобы ограничить такие задачи, как создание, удаление или изменение ресурсов. Только уполномоченные лица должны иметь полномочия для включения или отключения точек подключения. Несанкционированный доступ может привести к изменениям конфигурации и потенциально перенаправляет трафик в вредоносные реализации.

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

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

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

    Дополнительные сведения см. в разделе Предотвращение неактивных записей DNS.

Рекомендации

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

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

Оптимизация затрат

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

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

Контрольный список проектирования

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

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

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

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

Рекомендации

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

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

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

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

Операционное превосходство

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

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

Контрольный список для проектирования

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

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

  • Реализация операций аварийного восстановления. Реализация аварийного восстановления может быть разработана для перенаправки сетевого или веб-трафика с основного сайта на сайт резервного копирования. Этот метод аварийного восстановления можно реализовать с помощью Azure DNS и диспетчера трафика Azure (DNS). В случае аварии, если основная конечная точка становится поврежденной, диспетчер трафика перенаправляет трафик в здоровую вторичную конечную точку. По умолчанию Traffic Manager приоритизирует основную конечную точку, но его также можно настроить с дополнительными резервными конечными точками или балансировщиками нагрузки для распределения трафика. Дополнительные сведения см. в статье Настройка аварийного восстановления и обнаружения сбоев.

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

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

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

Рекомендации

Рекомендация Выгода
Включить журналы диагностики для профиля диспетчера трафика.

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

Эффективность производительности

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

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

Контрольный список для проектирования

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

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

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

    Дополнительные сведения см. в рекомендации по повышению производительности диспетчера трафика.

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

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

Рекомендации

Рекомендация Выгода
Используйте метод маршрутизации производительности при наличии конечных точек в разных географических расположениях. Этот метод определяет приоритет отправки трафика в конечную точку с наименьшей задержкой. Этот метод помогает обеспечить быструю службу для пользователей.
Используйте специализированные средства для оптимизации производительности. Измеряйте производительность запросов DNS. Чтобы проанализировать производительность трафика, используйте панели мониторинга представления трафика или REST APIтепловой карты. Средства измерения задержки DNS выполняют полный поиск DNS и предоставляют данные о производительности. Эти данные можно использовать для задания длительности TTL и оптимизации производительности.
Объедините методы трафика с вложенными профилями для оптимальной производительности в зависимости от ваших требований к рабочей нагрузке. Оптимизированный метод маршрутизации помогает убедиться, что трафик направляется на самые быстрые и ближайшие конечные точки. Такой подход помогает повысить производительность приложений и взаимодействие с пользователем.
Используйте функцию реальных измерений пользователей, чтобы просмотреть измерения задержки сети для регионов Azure. Эта функция доступна без дополнительных затрат. Вы можете принимать решения по маршрутизации на основе данных для направления запросов в регион Azure, который обеспечивает наименьшую задержку.
Задайте более высокое значение для интервала TTL DNS . Клиенты могут кэшировать результаты в течение более длительного периода времени, что сокращает потребность в разрешении DNS каждый раз.

Политики Azure

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

  • Журналы ресурсов включены для отслеживания действий.
  • Журналы для профилей диспетчера трафика отправляются в Центры событий Azure.

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

Рекомендации помощника по Azure

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

Компромиссы

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

надежность и эффективность производительности

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

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

надежности и оптимизации затрат

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

Следующий шаг

Рассмотрим следующие ресурсы, демонстрирующие рекомендации в этой статье.