Облака подобны магической шкатулке — задаешь, что тебе нужно, и ресурсы просто появляются из ниоткуда. Виртуальные машины, базы данных, сеть — все это принадлежит только тебе. Существуют и другие тенанты облака, но в своей Вселенной ты единоличный правитель. Ты уверен, что всегда получишь требуемые ресурсы, ни с кем не считаешься и самостоятельно определяешь, какой будет сеть. Как устроена эта магия, которая заставляет облако эластично выделять ресурсы и полностью изолировать тенанты друг от друга?
Облако AWS это мегасуперсложная система, которая эволюционно развивается с 2006 года. Часть этого развития застал Василий Пантюхин — архитектор Amazon Web Services. Как архитектор он видит изнутри не только конечный результат, но и сложности, которые преодолевает AWS. Чем больше понимания работы системы, тем больше доверия. Поэтому Василий поделится секретами облачных сервисов AWS. Под катом устройство физических серверов AWS, эластичная масштабируемость БД, кастомная база данных Amazon и методы повышения производительности виртуальных машин с одновременным уменьшением их цены. Знание архитектурных подходов Amazon поможет эффективнее использовать сервисы AWS и, возможно, даст новые идеи по построению собственных решений.
О спикере: Василий Пантюхин (Hen) начинал Unix-админом в.ru-компаниях, 6 лет занимался большими железками Sun Microsystem, 11 лет проповедовал дата-центричность мира в EMC. Естественным путем эволюционировал в приватные облака, а в 2017 подался в публичные. Сейчас техническими советами помогает жить и развиваться в облаке AWS.
Дисклеймер: всё, что ниже — это личное мнение Василия, и оно может не совпадать с позицией Amazon Web Services.
Моя первая машина была с «ручкой» — на механической КПП. Это было здорово из-за ощущения, что я могу управлять машиной и полностью контролировать ее. Еще мне нравилось, что я хотя бы примерно понимаю принцип ее работы. Естественно, я представлял устройство коробки достаточно примитивно — примерно как коробку передач на велосипеде.
Все было замечательно, кроме одного — стояния в пробках. Вроде сидишь и ничего не делаешь, но постоянно переключаешь передачи, нажимаешь на сцепление, газ, тормоз — от этого реально устаешь. Проблема пробок частично решилась, когда в семье появилась машина на автомате. За рулем появилось время о чем-то подумать, послушать аудиокнигу.
Еще в моей жизни появилась загадка, потому что я вообще перестал понимать, как работает моя машина. Современный автомобиль — это сложное устройство. Машина адаптируется одновременно к десяткам различных параметров: нажатие на газ, тормоз, стиль вождения, качество дороги. Я уже не понимаю как это работает.
Когда я начал заниматься облаком Amazon, для меня это тоже было тайной. Только эта тайна на порядок выше, потому что в машине один водитель, а в AWS их миллионы. Все пользователи одновременно рулят, нажимают на газ и тормоз. Удивительно, что они едут туда, куда хотят — для меня это чудо! Система автоматически адаптируется, масштабируется и эластично подстраивается под каждого пользователя так, что ему кажется, что он один в этой Вселенной.
Магия немного развеялась, когда позже я пришел работать архитектором в Amazon. Я увидел, с какими проблемами мы сталкиваемся, как их решаем, как развиваем сервисы. С ростом понимания работы системы появляется больше доверия к сервису. Поэтому я хочу поделиться картиной того, что под капотом у облака AWS.
Я выбрал диверсифицированный подход — отобрал 4 интересных сервиса, о которых стоит поговорить.
Оптимизация серверов. Эфемерные облака с физическим воплощением: физические дата-центры, где стоят физические серверы, которые гудят, греются и мигают лампочками.
Серверлесс-функции (Lambda) — наверное, самый масштабируемый сервис в облаке.
Масштабирование базы данных. Расскажу о том, как мы строим свои собственные масштабируемые БД.
Масштабирование сети. Последняя часть, в которой открою устройство нашей сети. Это чудесная вещь — каждый пользователь облака считает, что он в облаке один и вообще не видит других тенантов.
Облако эфемерно. Но у этой эфемерности все же есть физическое воплощение — серверы. Изначально их архитектура была классической. Стандартный x86 чипсет, сетевые карты, Linux, гипервизор Xen, на котором запускались виртуальные машины.
В 2012 году такая архитектура вполне справлялась со своими задачами. Xen — отличный гипервизор, но с одним серьезным недостатком. У него достаточно высокие накладные расходы на эмуляцию устройств. При появлении новых более быстрых сетевых карт или дисков SSD эти накладные расходы становятся слишком высокими. Как же справиться с этой проблемой? Решили работать сразу на двух фронтах — оптимизировать и железо, и гипервизор. Задача очень серьезная.
Сделать все сразу и хорошо не получится. Что такое «хорошо», изначально тоже было непонятно.
Преобразования начались в 2013 г. с самого сложного — сети. В С3 инстансах к стандартной сетевой карте добавили специальную карту Network Accelerator. Она подключалась буквально коротким loopback кабелем на передней панели. Некрасиво, но в облаке не видно. Зато прямое взаимодействие с железом принципиально улучшило jitter и пропускную способность сети.
Дальше решили заняться улучшением доступа к блочному хранению данных EBS — Elastic Block Storage. Это комбинация сети и хранилища. Сложность в том, что если на рынке существовали карты Network Accelerator, то возможности просто купить железо Storage Accelerator не было. Поэтому мы обратились к стартапу Annapurna Labs, который разработал для нас специальные чипы ASIC. Они позволили подключать удаленные тома EBS как устройства NVMe.
В инстансах C4 мы решили две задачи. Первая — реализовали задел на будущее перспективной, но новой на тот момент, технологии NVMe. Вторая — значительно разгрузили центральный процессор переносом обработки запросов к EBS на новую карту. Получилось удачно, поэтому сейчас Annapurna Labs — часть Amazon.
К ноябрю 2017 г. мы поняли, что пришла пора менять и сам гипервизор.
Эволюция инстансов на временной шкале.
Все новые типы виртуальных машин, которые появились с ноября 2017, работают на этом гипервизоре. У железных Bare Metal инстансов нет гипервизора, но их тоже называют Nitro, так как они используют специализированные Nitro-карты.
За следующие два года количество типов Nitro-инстансов превысило пару десятков: A1, C5, M5, T3 и другие.
Типы инстансов.
У них есть три основных компонента: Nitro-гипервизор (о нем говорили выше), чип безопасности и Nitro-карты.
Чип безопасности интегрирован прямо в материнскую плату. Он контролирует множество важных функций, например, контроль загрузки хостовой ОС.
Nitro-карты — их существует четыре типа. Все они разработаны Annapurna Labs и базируются на общих ASIC. Часть их прошивки тоже общая.
Четыре типа Nitro-карт.
Одна из карт предназначена для работы с сетьюVPC. Именно она видна в виртуалках как сетевая карта ENA — Elastic Network Adaptor. Также она инкапсулирует трафик при передаче его через физическую сеть (об этом поговорим во второй части статьи), контролирует файрвол Security Groups, отвечает за маршрутизацию и прочие сетевые вещи.
Отдельные карты работают с блочным хранением EBS и дисками, которые встроены в сервер. Гостевой виртуалке они представляются как NVMe-адаптеры. Также они отвечают за шифрование данных и мониторинг дисков.
Система Nitro-карт, гипервизора и чипа безопасности объединена в сеть SDN или Software Defined Network. За управление этой сетью (Control Plane) отвечает карта-контроллер.
Конечно, мы продолжаем разработку новых ASIC. Например, в конце 2018 г. выпустили чип Inferentia, который позволяет эффективнее работать с задачами машинного обучения.
Чип Inferentia Machine Learning Processor.
Традиционная база данных имеет слоистую структуру. Если сильно упростить, то выделяются следующие уровни.
Слоистая структура базы данных.
Существуют разные способы масштабирования баз данных: шардирование, архитектура Shared Nothing, разделяемые диски.
Однако, все эти методы сохраняют ту же самую монолитную структуру базы данных. Это заметно ограничивает масштабирование. Чтобы решить эту проблему, мы разработали свою собственную БД — Amazon Aurora. Она совместима с MySQL и PostgreSQL.
Основная архитектурная идея — отщепить уровни хранения и логирования от основной БД.
Забегая вперед скажу, что уровень кэширования мы тоже сделали независимым. Архитектура перестает быть монолитом, и мы получаем дополнительные степени свободы в масштабировании отдельных блоков.
Уровни логирования и хранения отделены от базы данных.
Традиционная СУБД записывает данные на систему хранения в виде блоков. В Amazon Aurora мы создали «умное» хранилище, которое может разговаривать на языке redo-логов. Внутри себя хранилище превращает логи в блоки данных, следит за их целостностью и автоматически бэкапит.
Этот подход позволяет реализовать такие интересные вещи как клонирование. Оно работает принципиально быстрее и экономичнее за счет того, что не требует создания полной копии всех данных.
Уровень хранения реализован в виде распределенной системы. Она состоит из очень большого количества физических серверов. Каждый redo-лог обрабатывается и сохраняется одновременно шестью узлами. Это обеспечивает защиту данных и распределение нагрузки.
Масштабирование на чтение можно обеспечить при помощи соответствующих реплик. Распределенное хранилище устраняет необходимость синхронизации между главным инстансом БД, через который мы записываем данные, и остальными репликами. Актуальные данные гарантированно доступны всем репликам.
Единственная проблема — кэширование старых данных на репликах чтения. Но эта задача решается передачей всех redo-логов на реплики по внутренней сети. Если лог в кэше, то он помечается как некорректный и перезаписывается. Если в кэше его нет, то он просто отбрасывается.
С хранилищем разобрались.
Здесь горизонтальное масштабирование сделать гораздо сложнее. Поэтому пойдем проторенной дорожкой классического вертикального масштабирования.
Предположим, что у нас есть приложение, которое общается с СУБД через мастер-ноду.
При вертикальном масштабировании выделяем новую ноду, у которой будет больше процессоров и памяти.
Дальше переключаем приложение со старой мастер-ноды на новую. Возникают проблемы.
Как улучшить ситуацию? Поставить прокси между приложением и мастер-нодой.
Что нам это даст? Теперь все приложения не нужно вручную перенаправлять на новую ноду. Переключение можно сделать под прокси и при этом принципиально быстрее.
Кажется, что проблема решена. Но нет, мы все еще страдаем от необходимости прогревания кэша. К тому же, появилась новая проблема — теперь прокси это потенциальная точка отказа.
Как мы решили эти проблемы?
Оставили прокси. Это не какой-то отдельный инстанс, а целый распределенный флот прокси, через который приложения подключаются к БД. Любую из нод в случае выхода из строя можно заменить практически мгновенно.
Добавили пул теплых нод различного размера. Поэтому при необходимости выделения новой ноды большего или меньшего размера она сразу доступна. Не надо ждать, когда она загрузится.
Весь процесс масштабирования контролируется специальной системой мониторинга. Мониторинг постоянно следит за состоянием текущей мастер-ноды. Если он обнаруживает, например, что нагрузка на процессор достигла критической величины, то извещает пул теплых инстансов о необходимости выделения новой ноды.
Распределенные прокси, теплые инстансы и мониторинг.
Нода требуемой мощности доступна. На нее копируются буферные пулы, и система начинает ожидать безопасного момента для переключения.
Обычно момент для переключения наступает достаточно быстро. Тогда коммуникация между прокси и старой мастер-нодой приостанавливается, все сессии переключаются на новую ноду.
Работа с базой данных возобновляется.
На графике видно, что приостановка действительно очень короткая. На синем графике нагрузка, а на красных ступеньках — моменты масштабирования. Кратковременные провалы в синем графике как раз и есть та самая короткая задержка.
Кстати, Amazon Aurora позволяет совсем сэкономить и выключить БД, когда она не используется, например, на выходных. После остановки нагрузки БД постепенно уменьшает свою мощность и на какое-то время отключается. Когда нагрузка вернется, она опять плавно поднимется.
Облако AWS это мегасуперсложная система, которая эволюционно развивается с 2006 года. Часть этого развития застал Василий Пантюхин — архитектор Amazon Web Services. Как архитектор он видит изнутри не только конечный результат, но и сложности, которые преодолевает AWS. Чем больше понимания работы системы, тем больше доверия. Поэтому Василий поделится секретами облачных сервисов AWS. Под катом устройство физических серверов AWS, эластичная масштабируемость БД, кастомная база данных Amazon и методы повышения производительности виртуальных машин с одновременным уменьшением их цены. Знание архитектурных подходов Amazon поможет эффективнее использовать сервисы AWS и, возможно, даст новые идеи по построению собственных решений.
О спикере: Василий Пантюхин (Hen) начинал Unix-админом в.ru-компаниях, 6 лет занимался большими железками Sun Microsystem, 11 лет проповедовал дата-центричность мира в EMC. Естественным путем эволюционировал в приватные облака, а в 2017 подался в публичные. Сейчас техническими советами помогает жить и развиваться в облаке AWS.
Дисклеймер: всё, что ниже — это личное мнение Василия, и оно может не совпадать с позицией Amazon Web Services.
Почему я рассказываю об устройстве Amazon
Моя первая машина была с «ручкой» — на механической КПП. Это было здорово из-за ощущения, что я могу управлять машиной и полностью контролировать ее. Еще мне нравилось, что я хотя бы примерно понимаю принцип ее работы. Естественно, я представлял устройство коробки достаточно примитивно — примерно как коробку передач на велосипеде.
Все было замечательно, кроме одного — стояния в пробках. Вроде сидишь и ничего не делаешь, но постоянно переключаешь передачи, нажимаешь на сцепление, газ, тормоз — от этого реально устаешь. Проблема пробок частично решилась, когда в семье появилась машина на автомате. За рулем появилось время о чем-то подумать, послушать аудиокнигу.
Еще в моей жизни появилась загадка, потому что я вообще перестал понимать, как работает моя машина. Современный автомобиль — это сложное устройство. Машина адаптируется одновременно к десяткам различных параметров: нажатие на газ, тормоз, стиль вождения, качество дороги. Я уже не понимаю как это работает.
Когда я начал заниматься облаком Amazon, для меня это тоже было тайной. Только эта тайна на порядок выше, потому что в машине один водитель, а в AWS их миллионы. Все пользователи одновременно рулят, нажимают на газ и тормоз. Удивительно, что они едут туда, куда хотят — для меня это чудо! Система автоматически адаптируется, масштабируется и эластично подстраивается под каждого пользователя так, что ему кажется, что он один в этой Вселенной.
Магия немного развеялась, когда позже я пришел работать архитектором в Amazon. Я увидел, с какими проблемами мы сталкиваемся, как их решаем, как развиваем сервисы. С ростом понимания работы системы появляется больше доверия к сервису. Поэтому я хочу поделиться картиной того, что под капотом у облака AWS.
О чем поговорим
Я выбрал диверсифицированный подход — отобрал 4 интересных сервиса, о которых стоит поговорить.
Оптимизация серверов. Эфемерные облака с физическим воплощением: физические дата-центры, где стоят физические серверы, которые гудят, греются и мигают лампочками.
Серверлесс-функции (Lambda) — наверное, самый масштабируемый сервис в облаке.
Масштабирование базы данных. Расскажу о том, как мы строим свои собственные масштабируемые БД.
Масштабирование сети. Последняя часть, в которой открою устройство нашей сети. Это чудесная вещь — каждый пользователь облака считает, что он в облаке один и вообще не видит других тенантов.
Примечание. В этой статье речь пойдет об оптимизации серверов и масштабировании БД. Масштабирование сети рассмотрим в следующей статье. Где же серверлесс-функции? О них вышла отдельная расшифровка «Мал, да удал. Анбоксинг микровиртуалки Firecracker». В ней рассказано о нескольких разных способах масштабирования, и подробно разобрано решение Firecracker — симбиоз лучших качеств виртуальной машины и контейнеров.
Серверы
Облако эфемерно. Но у этой эфемерности все же есть физическое воплощение — серверы. Изначально их архитектура была классической. Стандартный x86 чипсет, сетевые карты, Linux, гипервизор Xen, на котором запускались виртуальные машины.
В 2012 году такая архитектура вполне справлялась со своими задачами. Xen — отличный гипервизор, но с одним серьезным недостатком. У него достаточно высокие накладные расходы на эмуляцию устройств. При появлении новых более быстрых сетевых карт или дисков SSD эти накладные расходы становятся слишком высокими. Как же справиться с этой проблемой? Решили работать сразу на двух фронтах — оптимизировать и железо, и гипервизор. Задача очень серьезная.
Оптимизация железа и гипервизора
Сделать все сразу и хорошо не получится. Что такое «хорошо», изначально тоже было непонятно.
Решили применить эволюционный подход — меняем один важный элемент архитектуры и бросаем его в продакшн.Наступаем на все грабли, выслушиваем жалобы и предложения. Потом изменяем другую компоненту. Так, небольшими инкрементами, кардинально меняем всю архитектуру на основе обратной связи от пользователей и поддержки.
Преобразования начались в 2013 г. с самого сложного — сети. В С3 инстансах к стандартной сетевой карте добавили специальную карту Network Accelerator. Она подключалась буквально коротким loopback кабелем на передней панели. Некрасиво, но в облаке не видно. Зато прямое взаимодействие с железом принципиально улучшило jitter и пропускную способность сети.
Дальше решили заняться улучшением доступа к блочному хранению данных EBS — Elastic Block Storage. Это комбинация сети и хранилища. Сложность в том, что если на рынке существовали карты Network Accelerator, то возможности просто купить железо Storage Accelerator не было. Поэтому мы обратились к стартапу Annapurna Labs, который разработал для нас специальные чипы ASIC. Они позволили подключать удаленные тома EBS как устройства NVMe.
В инстансах C4 мы решили две задачи. Первая — реализовали задел на будущее перспективной, но новой на тот момент, технологии NVMe. Вторая — значительно разгрузили центральный процессор переносом обработки запросов к EBS на новую карту. Получилось удачно, поэтому сейчас Annapurna Labs — часть Amazon.
К ноябрю 2017 г. мы поняли, что пришла пора менять и сам гипервизор.
Новый гипервизор разработали на основе доработанных модулей ядра KVM.Он позволил принципиально уменьшить накладные расходы на эмуляцию устройств и работать напрямую с новыми ASIC. Инстансы С5 были первыми виртуалками, под капотом которых работает новый гипервизор. Мы назвали его Nitro.
Эволюция инстансов на временной шкале.Все новые типы виртуальных машин, которые появились с ноября 2017, работают на этом гипервизоре. У железных Bare Metal инстансов нет гипервизора, но их тоже называют Nitro, так как они используют специализированные Nitro-карты.
За следующие два года количество типов Nitro-инстансов превысило пару десятков: A1, C5, M5, T3 и другие.
Типы инстансов.
Как устроены современные Nitro-машины
У них есть три основных компонента: Nitro-гипервизор (о нем говорили выше), чип безопасности и Nitro-карты.
Чип безопасности интегрирован прямо в материнскую плату. Он контролирует множество важных функций, например, контроль загрузки хостовой ОС.
Nitro-карты — их существует четыре типа. Все они разработаны Annapurna Labs и базируются на общих ASIC. Часть их прошивки тоже общая.
Четыре типа Nitro-карт.
Одна из карт предназначена для работы с сетьюVPC. Именно она видна в виртуалках как сетевая карта ENA — Elastic Network Adaptor. Также она инкапсулирует трафик при передаче его через физическую сеть (об этом поговорим во второй части статьи), контролирует файрвол Security Groups, отвечает за маршрутизацию и прочие сетевые вещи.
Отдельные карты работают с блочным хранением EBS и дисками, которые встроены в сервер. Гостевой виртуалке они представляются как NVMe-адаптеры. Также они отвечают за шифрование данных и мониторинг дисков.
Система Nitro-карт, гипервизора и чипа безопасности объединена в сеть SDN или Software Defined Network. За управление этой сетью (Control Plane) отвечает карта-контроллер.
Конечно, мы продолжаем разработку новых ASIC. Например, в конце 2018 г. выпустили чип Inferentia, который позволяет эффективнее работать с задачами машинного обучения.
Чип Inferentia Machine Learning Processor.
Масштабируемая база данных
Традиционная база данных имеет слоистую структуру. Если сильно упростить, то выделяются следующие уровни.
- SQL — на нем работают диспетчеры клиентов и запросов.
- Обеспечения транзакций — тут все понятно, ACID и все такое.
- Кэширование, которое обеспечивается буферными пулами.
- Логирование — обеспечивает работу с redo-логами. В MySQL они называются Bin Logs, в PosgreSQL — Write Ahead Logs (WAL).
- Хранение – непосредственно запись на диск.
Слоистая структура базы данных.
Существуют разные способы масштабирования баз данных: шардирование, архитектура Shared Nothing, разделяемые диски.
Однако, все эти методы сохраняют ту же самую монолитную структуру базы данных. Это заметно ограничивает масштабирование. Чтобы решить эту проблему, мы разработали свою собственную БД — Amazon Aurora. Она совместима с MySQL и PostgreSQL.
Amazon Aurora
Основная архитектурная идея — отщепить уровни хранения и логирования от основной БД.
Забегая вперед скажу, что уровень кэширования мы тоже сделали независимым. Архитектура перестает быть монолитом, и мы получаем дополнительные степени свободы в масштабировании отдельных блоков.
Уровни логирования и хранения отделены от базы данных.
Традиционная СУБД записывает данные на систему хранения в виде блоков. В Amazon Aurora мы создали «умное» хранилище, которое может разговаривать на языке redo-логов. Внутри себя хранилище превращает логи в блоки данных, следит за их целостностью и автоматически бэкапит.
Этот подход позволяет реализовать такие интересные вещи как клонирование. Оно работает принципиально быстрее и экономичнее за счет того, что не требует создания полной копии всех данных.
Уровень хранения реализован в виде распределенной системы. Она состоит из очень большого количества физических серверов. Каждый redo-лог обрабатывается и сохраняется одновременно шестью узлами. Это обеспечивает защиту данных и распределение нагрузки.
Масштабирование на чтение можно обеспечить при помощи соответствующих реплик. Распределенное хранилище устраняет необходимость синхронизации между главным инстансом БД, через который мы записываем данные, и остальными репликами. Актуальные данные гарантированно доступны всем репликам.
Единственная проблема — кэширование старых данных на репликах чтения. Но эта задача решается передачей всех redo-логов на реплики по внутренней сети. Если лог в кэше, то он помечается как некорректный и перезаписывается. Если в кэше его нет, то он просто отбрасывается.
С хранилищем разобрались.
Как масштабировать уровни СУБД
Здесь горизонтальное масштабирование сделать гораздо сложнее. Поэтому пойдем проторенной дорожкой классического вертикального масштабирования.
Предположим, что у нас есть приложение, которое общается с СУБД через мастер-ноду.
При вертикальном масштабировании выделяем новую ноду, у которой будет больше процессоров и памяти.
Дальше переключаем приложение со старой мастер-ноды на новую. Возникают проблемы.
- Это потребует заметного даунтайма приложения.
- У новой мастер-ноды будет холодный кэш. Производительность БД будет максимальна только после прогрева кэша.
Как улучшить ситуацию? Поставить прокси между приложением и мастер-нодой.
Что нам это даст? Теперь все приложения не нужно вручную перенаправлять на новую ноду. Переключение можно сделать под прокси и при этом принципиально быстрее.
Кажется, что проблема решена. Но нет, мы все еще страдаем от необходимости прогревания кэша. К тому же, появилась новая проблема — теперь прокси это потенциальная точка отказа.
Итоговое решение с Amazon Aurora serverless
Как мы решили эти проблемы?
Оставили прокси. Это не какой-то отдельный инстанс, а целый распределенный флот прокси, через который приложения подключаются к БД. Любую из нод в случае выхода из строя можно заменить практически мгновенно.
Добавили пул теплых нод различного размера. Поэтому при необходимости выделения новой ноды большего или меньшего размера она сразу доступна. Не надо ждать, когда она загрузится.
Весь процесс масштабирования контролируется специальной системой мониторинга. Мониторинг постоянно следит за состоянием текущей мастер-ноды. Если он обнаруживает, например, что нагрузка на процессор достигла критической величины, то извещает пул теплых инстансов о необходимости выделения новой ноды.
Распределенные прокси, теплые инстансы и мониторинг.
Нода требуемой мощности доступна. На нее копируются буферные пулы, и система начинает ожидать безопасного момента для переключения.
Обычно момент для переключения наступает достаточно быстро. Тогда коммуникация между прокси и старой мастер-нодой приостанавливается, все сессии переключаются на новую ноду.
Работа с базой данных возобновляется.
На графике видно, что приостановка действительно очень короткая. На синем графике нагрузка, а на красных ступеньках — моменты масштабирования. Кратковременные провалы в синем графике как раз и есть та самая короткая задержка.
Кстати, Amazon Aurora позволяет совсем сэкономить и выключить БД, когда она не используется, например, на выходных. После остановки нагрузки БД постепенно уменьшает свою мощность и на какое-то время отключается. Когда нагрузка вернется, она опять плавно поднимется.
В следующей части рассказа об устройстве Amazon поговорим о масштабировании сети. Подписывайтесь на рассылку и следите за обновлениями, чтобы не пропустить статью.
На HighLoad++ Василий Пантюхин выступит с докладом «Хьюстон, у нас проблема. Дизайн систем на отказ, паттерны разработки внутренних сервисов облака Amazon». Какие паттерны проектирования распределенных систем используют разработчики Amazon, какие бывают причины отказов сервисов, что такое Cell-based architecture, Constant Work, Shuffle Sharding — будет интересно. До конференции меньше месяца — бронируйте билеты. 24 октября окончательное повышение цен.
