Настройка отказоустойчивой архитектуры в Yandex Cloud

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

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

Чтобы настроить и протестировать архитектуру:

1. Подготовьте облако к работе.
2. Настройте тестовый стенд.
3. Выполните тестовые сценарии.

Если созданные ресурсы вам больше не нужны, удалите их.

Подготовьте облако к работеПодготовьте облако к работе

Необходимые платные ресурсыНеобходимые платные ресурсы

В стоимость поддержки отказоустойчивой архитектуры Yandex Cloud входит:

• Плата за диски и постоянно запущенные ВМ (см. тарифы Yandex Compute Cloud).
• Плата за постоянно запущенный кластер Yandex Managed Service for PostgreSQL (см. тарифы Managed Service for PostgreSQL).
• Плата за использование динамического или статического публичного IP-адреса (см. тарифы Yandex Virtual Private Cloud).

Настройте тестовый стендНастройте тестовый стенд

Описание тестового стенда:

• Приложение упаковано в Docker-образ и загружено в Yandex Container Registry.

  Docker-образы развернуты на четырех ВМ на основе Container Optimized Image. ВМ объединены в группу и расположены в двух различных зонах доступности.

• Кластер БД работает под управлением сервиса Managed Service for PostgreSQL и состоит из двух хостов, расположенных в различных зонах доступности.

• Нагрузка генерируется приложением Load Testing Tool из Yandex Cloud Marketplace и подается на Yandex Network Load Balancer. Сетевой балансировщик нагрузки распределяет трафик по ВМ.

Подготовьте контейнеры приложения TodoListПодготовьте контейнеры приложения TodoList

Чтобы подготовить приложение для запуска в Yandex Cloud:

1. Скачайте и распакуйте репозиторий с исходным кодом демо-приложения, Terraform-спецификациями и скриптом для имитации сбоя приложения.

2. Перейдите в репозиторий:

   cd yandex-cloud-fault-tolerance-demo-master/app
   

3. Аутентифицируйтесь в Container Registry:

   yc container registry configure-docker
   

4. Создайте реестр:

   yc container registry create --name todo-registry
   

5. Создайте Docker-образ с тегом v1:

   docker build . --tag cr.yandex/<идентификатор_реестра>/todo-demo:v1 --platform linux/amd64
   

6. Создайте Docker-образ с тегом v2 (для проверки сценария обновления приложения):

   docker build . --build-arg COLOR_SCHEME=dark --tag cr.yandex/<идентификатор_реестра>/todo-demo:v2 --platform linux/amd64
   

7. Загрузите Docker-образы в Container Registry:

   docker push cr.yandex/<идентификатор_реестра>/todo-demo:v1
   docker push cr.yandex/<идентификатор_реестра>/todo-demo:v2
   

Разверните инфраструктуруРазверните инфраструктуру

Чтобы подготовить окружение для запуска приложения в Yandex Cloud:

1. Установите Terraform.

2. Перейдите в директорию со спецификацией окружения:

   cd ../terraform/app
   

3. Инициализируйте Terraform в директории со спецификацией:

   terraform init
   

4. Сохраните идентификатор каталога в переменную YC_FOLDER и IAM-токен — в переменную YC_TOKEN:

   export YC_FOLDER=<идентификатор_каталога>
   export YC_TOKEN=$(yc iam create-token)
   

5. Сгенерируйте ключ для подключения к виртуальной машине по SSH:

   ssh-keygen -t ed25519
   

6. В файле app/todo-service.tf укажите путь к публичному SSH-ключу (значение по умолчанию ~/.ssh/id_ed25519.pub).

7. Проверьте квоты в облаке, чтобы была возможность развернуть требуемые ресурсы.

   Информация о количестве создаваемых ресурсов

   Будут созданы следующие ресурсы:

   • Сеть Virtual Private Cloud с тремя подсетями во всех зонах доступности.
   • Два сервисных аккаунта:
     • Сервисный аккаунт для управления группой ВМ с ролью editor.
     • Сервисный аккаунт для скачивания Docker-образа на ВМ с ролью container-registry.images.puller.
   • Группа ВМ из четырех ВМ на базе Container Optimized Image в зонах доступности ru-central1-b и ru-central1-d.
   • Кластер Managed Service for PostgreSQL с двумя хостами в зонах доступности ru-central1-b и ru-central1-d.
   • Сетевой балансировщик нагрузки для распределения трафика по ВМ группы.

8. Разверните и запустите приложение:

   terraform apply -var yc_folder=$YC_FOLDER -var yc_token=$YC_TOKEN -var user=$USER
   

   Где:

   • yc_folder — каталог, в котором будет развернуто приложение.
   • yc_token — IAM-токен пользователя, от имени которого будет развернуто приложение.

Для доступа к приложению перейдите по адресу lb_address, полученному в результате выполнения terraform apply.

Подготовьте и запустите приложение Load Testing ToolПодготовьте и запустите приложение Load Testing Tool

1. Перейдите в директорию со спецификацией Load Testing Tool:

   cd ../tank
   

2. Инициализируйте Terraform в директории со спецификацией Load Testing Tool:

   terraform init
   

3. В файле tank/main.tf укажите путь к публичному и приватному SSH-ключам (значения по умолчанию ~/.ssh/id_ed25519.pub и ~/.ssh/id_ed25519).

4. Разверните и запустите ВМ:

   terraform apply -var yc_folder=$YC_FOLDER -var yc_token=$YC_TOKEN -var user=$USER -var overload_token=<overload_token>
   

   Где:

   • yc_folder — каталог, в котором будет развернуто Load Testing Tool.
   • yc_token— IAM-токен пользователя, от имени которого будет развернуто Load Testing Tool.
   • overload_token — токен для подключения к <overload.yandex.net>. Для получения токена нужно аутентифицироваться, после чего нажать справа вверху на свой профиль и в выпадающем меню выбрать My api token.

5. Подключитесь к созданной ВМ по SSH. Адрес для подключения указан в выводе команды terraform apply:

   ssh <имя_пользователя>@<IP-адрес_ВМ>
   

6. Запустите Load Testing Tool:

   sudo yandex-tank -c load.yaml
   

7. Перейдите в <overload.yandex.net> и найдите там запущенную нагрузку: Public tests → show my tests only.

Выполнение сценариевВыполнение сценариев

Сбой ВМСбой ВМ

Как проявляется сбой: недоступна ВМ с приложением.

Возможные причины:

• Падение физического хоста, на котором была запущена ВМ.
• По ошибке удалена ВМ с приложением.

Для имитации сбоя удалите одну из ВМ группы:

Реакция тестового стенда:

1. Сетевой балансировщик нагрузки и Instance Groups получают информацию о сбое ВМ и выводят ее из балансировки — трафик перестает поступать на эту ВМ и распределяется между оставшимися ВМ в группе.
2. Instance Groups автоматически восстанавливается:
   1. Удаляет недоступную ВМ (в этом сценарии ВМ уже удалена, шаг будет пропущен).
   2. Создает новую ВМ.
   3. Ожидает запуска приложения на созданной ВМ.
   4. Добавляет ВМ в балансировку.

Балансировщику нагрузки и Instance Groups требуется некоторое время, чтобы обнаружить проблему и отключить подачу трафика на неисправную ВМ. Из-за этого возможно появление ошибок Connection Timeout (HTTP-код 0 на графиках Quantities и HTTP codes в мониторинге Load Testing Tool).

После выведения недоступной ВМ из балансировки пользовательская нагрузка обрабатывается корректно.

Сбой приложенияСбой приложения

Как проявляется сбой: приложение не отвечает вовремя или работает некорректно с точки зрения пользователя.

Возможные причины:

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

В соответствии с настройками проверки состояния Instance Groups опрашивает ВМ группы по HTTP-протоколу. При нормальной работе обращение к конечной точке /healthy возвращается HTTP-код 200. Иначе Instance Groups запускает процедуру восстановления.

Для имитации сбоя в репозитории yandex-cloud-fault-tolerance-demo-master запустите скрипт:

fail_random_host.sh <идентификатор_группы_ВМ>

Случайная ВМ из группы начнет возвращать HTTP-код 503.

Реакция тестового стенда:

1. Instance Groups получает информацию о сбое приложения и выводит ВМ из балансировки — трафик перестает поступать на эту ВМ и распределяется между оставшимися ВМ в группе.
2. Instance Groups автоматически восстанавливается:
   1. Перезагружает неисправную ВМ.
   2. Ожидает запуска приложения на созданной ВМ.
   3. Добавляет ВМ в балансировку.

Instance Groups несколько раз опрашивает ВМ прежде чем отключить трафик и запустить восстановление. Из-за этого возможно появление ошибок Service Unavailable (HTTP-код 503 на графиках Quantities и HTTP codes в мониторинге Load Testing Tool).

После выведения неисправной ВМ из балансировки пользовательская нагрузка обрабатывается корректно.

Отключение зоны доступностиОтключение зоны доступности

Как проявляется сбой: недоступны несколько ВМ в одной зоне.

Возможные причины:

• Перебои в работе дата-центра.
• Плановые технические работы в дата-центре.

Чтобы перенести ресурсы в другой дата-центр:

Реакция тестового стенда:

1. Instance Groups выводит из балансировки ВМ в зоне доступности ru-central1-b.
2. Выведенные ВМ удаляются, одновременно с этим создаются ВМ в зоне ru-central1-d.
3. Instance Groups добавляет созданные ВМ в балансировку.

Количество одновременно создаваемых и удаляемых ВМ определяется политикой развертывания.

Во время выведения ВМ из балансировки возможно появление ошибок Connection Timeout (HTTP-код 0 на графиках Quantities и HTTP codes в мониторинге Load Testing Tool).

После выведения ВМ из балансировки пользовательская нагрузка обрабатывается корректно.

Обновление приложенияОбновление приложения

Чтобы обновить приложение:

Реакция тестового стенда:

1. Instance Groups выводит из балансировки две ВМ с устаревшей версией приложения (статус таких ВМ RUNNING_OUTDATED).
2. Удаляет выведенные ВМ, одновременно с этим создает ВМ с новой версией приложения.
3. Добавляет созданные ВМ в балансировку.
4. Действия повторяются для оставшихся двух ВМ с устаревшей версией приложения.

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

Количество одновременно создаваемых и удаляемых ВМ определяется политикой развертывания.

Во время выведения ВМ из балансировки возможно появление ошибок Connection Timeout (HTTP-код 0 на графиках Quantities и HTTP codes в мониторинге Load Testing Tool).

После выведения ВМ из балансировки пользовательская нагрузка обрабатывается корректно.

Масштабирование конфигурации БДМасштабирование конфигурации БД

Масштабирование БД может потребоваться, если:

• Производительности хостов в кластере не хватает для обработки запросов.
• Для данных требуется хранилище большего объема.

Чтобы масштабировать конфигурацию:

Managed Service for PostgreSQL запустит операцию изменения кластера.

При переключении между мастером и репликой (в начале и в конце процесса изменения) возможно появление ошибок Internal Server Error (HTTP-код 500 на графиках Quantities и HTTP codes в мониторинге Load Testing Tool).

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

Удаление приложений и окруженияУдаление приложений и окружения

Чтобы удалить приложение Load Testing Tool, перейдите в каталог yandex-cloud-fault-tolerance-demo-master/terraform/tank и выполните следующую команду:

terraform destroy -var yc_folder=$YC_FOLDER -var yc_token=$YC_TOKEN -var user=$USER -var overload_token=not-used

Чтобы удалить приложение TodoList, перейдите в каталог yandex-cloud-fault-tolerance-demo-master/terraform/app и выполните следующую команду:

terraform destroy -var yc_folder=$YC_FOLDER -var yc_token=$YC_TOKEN -var user=$USER