Назад

# Конспект доклада "Хьюстон, у нас проблема. Дизайн систем на отказ / Василий Пантюхин". Tags: cloud, архитектура, конспект Видео: [Хьюстон, у нас проблема. Дизайн систем на отказ / Василий Пантюхин (Amazon Web Services)](https://www.youtube.com/watch?v=RxWVxr4uUpI) Презентация: [pdf](https://drive.google.com/file/d/1rATSPFM2v7bOyJ9q8nVYjEI9OYgJ8xE5/view) При построении архитектуры, а особенно архитектуры, которая подвержена большому росту - такой как архитектура облака, требуется учитывать все известные проблемы эксплуатации, а так же учитывать все возможные проблемы, вероятность которых предполагается крайне малой. Запас прочности и надежные архитектурыне решения позволят пережить и локализовать проблему, и сделать так, чтобы большая часть клиентов этого и не заметила. Речь пойдет про Control Plane - слой управления. Теги автора: - Мы котроллируем факап, а не он нас. - Минимизируем радиус взрыва (ущерб от факапа). #### 1. Isolation and Pacing. Изоляция и приоритезация. **Смысл:** задачи в очередях нужно приоритезировать. **Кейс автора:** есть очередь задач: создать новый сервис/переконфигурировать сервис и т.п. Упало много сервисов и в очереди появилось много задач "переустанови сервис" -> воркеры 100% заняты восстановлением. Штатные запросы клиентов ждут в очереди дольше обычного (и не дожидаются). **Применение паттерна:** разделить события на разные очереди или сортировать задачи по приоритету. Даже если в очереди много задач восстановления, обслуживать клиентские задачи вне очереди: их обычно на порядок меньше - это сильно не повлияет на скорость восстановления, но клиенты получат что хотели как будто никаких проблем нет. #### 2. Constant work. Константная единица работы. **Смысл:** сделать так, чтобы количество "работы" не зависило от количества изменений. **Кейс автора:** в случае падения инстанса, создается задача в очереди, которая переконфигурирует DNS-записи и удаляет нерабочий инстанс. В случае массового факапа очередь переполняется, создается высокая нагрузка на переконфигурирование DNS, появляются дубли задач в очереди. **Применение паттерна:** (**обратный опрос**) вместо того, чтобы переконфигурировать DNS-сервера, сделать так чтобы DNS-сервера сами знали статус инстансов и сами меняли записи DNS. Т.к. они будут постоянно опрашивать статусы всех инстансов - массовое их падение на количество "работы DNS-сервера" не повлияет. **Другой вариант:** (**постоянная работа**) сделать так, что изменения на DNS-сервера делаются постоянно, специальным демоном, каждые 10 секунд. Т.е. не важно, были ли изменения и насколько они массовые - даже если ничего не изменилось он обновляет конфиги. Минусы: лишняя нагрузка и 10ти секундная задержка применения конфига (не подходит для быстрых действий). #### 3. Preemptive scaling. Превентивное скалирование. **Смысл:** держать запас прочности инстансов более 50% **Кейс автора:** было 2 реплики с распределением нагрузки 50/50. Один инстанс упал и нагрузка на второй инстанс увеличилась вдвое. Т.к. это облако, второй инстанс начинает процесс "скалирования" - увеличивает себе ресурсы в 2 раза, но это процесс не мгновенный, а при массовых сбоях (отказ одного из ДЦ) - все вешается на кучу процессов скалирования и перебалансировки. **Применение паттерна:** не нагружать инстанс более чем на 40%. Пользователи падения практически не будут замечать, не будет деградации сервиса. Будет перерасход ресурсов, но это плата за "страховку на случай факапов". #### 4. Cell-based architecture. **Смысл:** использовать микросервисы.^W^W Сделать типовую "единицу поставки" приложения, рассчитать ее системные требования и сколько нагрузки она выдерживает. Клиентов обслуживать распределенным набором этих сервисов. **Плюсы:** - можно тестировать, т.к. можно нагрузить тестовый стенд потоком нагрузки, сравнимым с потоком который приходит на этот инстанс в продакшене - горизонтальное масштабирование сервиса - в случае аварий можно контроллировать ущерб - с помощью правильного шардирования можно решать проблемы надежности, шумных соседей и т.д. - проще мониторить, т.к. известны характиристики **Минусы:** - сложно правильно отшардировать и выбрать размер шарда #### 5. Multi-tenancy. **Смысл:** если используется многоуровневая система (например, слой фронтенд-серверов и слой бакенд-серверов) не выстраивать их в виде дереа (front_1 & front_2 -> back_1; front_3 & front_4 -> back_2), а сделать связь многие ко многим. **Картинки объяснят лучше меня:**   #### 6. Shuffle sharding. Перемешанное шардирование. **Смысл:** случайно распределяем клиентов по нескольким шардам. Т.к. у нас есть проблемы утилизации и "шумных соседей" (кто-то генерирует минимальную нагрузку, а кто-то очень высокую), случайное распределение клиентов по шардам, при достаточном количестве шардов, "размажет" нагрузку и шанс что все шарды одного клиента попадут на проблемный инстанс стремится к нулю. **Картинки объяснят лучше меня:**  1. Шумный сосед перегружает систему, страдает клиент который делит с ним шарды.  2. Распределяем клиентов по шардам "случайно".  3. Шумный сосед делает перегруз, но этого никто практически не замечает. 4. ??? 5. PROFIT! #### 7. Small fleet calls big fleet. Малый флот вызывает большой флот. **Смысл:** вместо того, чтобы думать "пулить конфиг с инстансов или пушить на них внешней системой", нужно понять какой "флот" инстансов больше: у системы1 или системы2. Заниматсья связью должна та система, которая меньше, т.к. иначе больший "флот" в случае массовой переконфигурации просто зафлудит меньший. Этот паттерн сочитается с паттерном "Constant work". **Кейс автора:** есть большая группа фронт-серверов и группа бакенд-серверов. Есть сервис, с которого "фронты" забирают информацию по роутингу - к каким бакендам они должны отправлять запросы. Однажды большая пачка "фронтов" (большой флот) падает и переинициализируется, генерируют большое количество запросов на сервис конфигурации (малый флот) и он ложится. **Применение паттерна:** так как серверов конфигурации меньше - они "малый флот", а "фронты" - большой. Значит не "фронты" должны забирать конфигурацию, а наоборот. Тогда не важно сколько фронт-серверов потребуют инициализации - это не зафлудит малый сервис. #### 8. Load shedding. **Смысл:** с определенного количества запросов, латентность ответа начинает увеличиваться по экспоненте. В случае большой нагрузки, все клинеты начнут отваливаться по таймауту, не дождавшись ответа, а сервис будет делать "пустую работу", генерируя ответ для уже отвалившихся клиентов. Зная, или замерив максимальное количество запросов с приемлемым временем ответа, записываем этот лимит в код и отбрасываем все ответы, сверх лимита. Некоторые клиенты будут получать отказ (что лечится политикой ретраев), но часть клиентов получат приемлимое обслуживание. **Картинка:**  Помнится, эту тему хорошо раскрыл Константин Осипов в докладе [Принципы и приёмы обработки очередей](https://www.youtube.com/watch?v=CvT1v7xiRS0) По теме настройки таймаутов на серверах - доклад [Тонкая настройка балансировки нагрузки / Николай Сивко](https://www.youtube.com/watch?v=2-j2ADWFkkE) #### 9. (из части QA) active master-master **Смысл:** если у вас в системе есть 2 мастера, активный и запасной - лучше оба сделать активными и поделить между ними нагрузку. Т.к. в случае факапа может оказаться, что запасной мастер не работает, что переключение на него занимает много времени и прочие радости. А если он активный - то это практически 100% гарантия что все будет ОК.