Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases

Ведущий предупреждает: выпуск необычный — вместо книги читают White Paper от Amazon, и, в отличие от книжек, успевают обозреть его за один раз. По словам Александра, статья вышла «по-моему, лет шесть назад, в семнадцатом году»; частей в ней одиннадцать, но основное сосредоточено в первых восьми. Amazon начинает с классических реляционных баз, придуманных тридцать-сорок лет назад: слоёный пирог из обработки запросов, транзакций, логов и стораджа на одной машине. Реплицировать его можно целиком или передавать изменения лога, но уровень хранения, кэшей и логов остаётся на каждой ноде. Отсюда идея отрезать нижнюю часть: в распределённых системах принято отделять компьют, и тогда узкое место переезжает с диска в сеть между базой и стораджем. Мешают, по статье, синхронные операции — промах мимо кэша с чтением с диска и коммит транзакции. Один из участников просит не говорить здесь «шардирование»: речь про репликацию по сегментам и про protection groups.

Один из гостей добавляет то, чего в статье нет: под стандартной базой лежит очень большое и дорогое блочное хранилище, из-за него база становится дорогим объектом, и много на ней не заработаешь — экономика, подозревает он, была не последним мотивом. Кворумы разбирает Александр. В классической схеме, чтобы пережить выпадение одной ноды, берут три и следят, чтобы кворумы чтения и записи пересекались на ноде, знающей о последней записи. У Amazon рамка шире: внутри региона есть зоны доступности, связанные быстрой сетью, и сбои внутри зоны коррелированы: отключилось питание — и все ноды зоны ушли. Цель — пережить потерю целой зоны плюс ещё одной ноды, отсюда запись кворумом 4 из 6 и чтение 3 из 6. После выпадения зоны писать ещё можно; если добавляется сбой на одной ноде, писать уже нельзя, но читать можно, и данные не потеряны.

Пишут не целым томом, а сегментами по 10 гигабайт: сеть быстрая, и сегмент можно быстро восстановить где потребуется. Шесть сегментов, раскиданных по трём зонам доступности, образуют protection group, а из групп собирается том — то, что раньше лежало внутри одного диска, теперь размазано слоем по блочному хранилищу. Участники подчёркивают: дизайн исходит не из теоретических выкладок, а из времени ремонта — как часто ты падаешь и как быстро чинишься. Отсюда неожиданный дивиденд: горячую ноду достаточно пометить как требующую починки, и система увезёт сегменты в другое место, так что механизм восстановления после сбоев превращается в способ менять конфигурацию и накатывать патчи операционной системы, раскатывая обновления порознь, чтобы меньше задеть пользователей. На шести нодах одну можно возить почти безнаказанно: если в этот момент падает зона, чтение остаётся, а запись возвращается, как только сегмент переехал.

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

С сетевым хранилищем пропадает кэш страниц операционной системы, поэтому префетч приходится явно переносить в базу — в сканирование индексов и таблиц и в код вакуума. Путь записи Виталий проходит по шагам: запись попадает в очередь в памяти, пишется на диск, и только тогда узел отвечает, что персистировал, — плюс один в кворум записи. Применение идёт фоном: на предыдущую версию страницы накладываются закодированные изменения, сформулированные как «добавить такую-то запись» или «сделать сплит страницы B-дерева»; старые снапшоты подчищаются, скраб проверяет данные, а недостающее узел запрашивает у соседей. Отсюда запомнившаяся фраза, по словам рассказчика, из третьей части: лог и есть база данных — для корректности материализация не нужна, но если она не успевает, при чтении берут ближайший снапшот и доигрывают оставшиеся записи онлайн. Восстановление строится от классического ARIES, расшифровку которого Александр не помнит: redo после сбоя и откат незавершённых транзакций. В Aurora проигрывание лога уезжает в сторадж и на реплики, а undo остаётся — он важнее для MySQL с явными файлами undo, тогда как в PostgreSQL старые версии строк лежат прямо в блоке таблицы.

Четвёртая часть набита трёхбуквенными сокращениями, начиная с LSN, который праймари выдаёт записям лога; у Александра «закончилась оперативная память», он выписал себе страничку с расшифровками и дочитывал статью с ней, а заодно нарисовал схему: внутри транзакции живут мини-транзакции, и последняя LSN мини-транзакции служит точкой консистентности. Виталий напоминает, что LSN статья не изобретает — в обычных базах это не единица-двойка-тройка, а байтовые офсеты в виртуальном файле со всеми логами. Александр ждал магии про мультилидер, а нашёл одну возрастающую последовательность и одного мастера. Виталий добавляет: мультимастер для MySQL в Amazon делали, но похоронили, решив, что приходившие за ним хотели другого. Рядом живёт LSN allocation limit — как талоны в очереди, которых нельзя напечатать больше разрешённого; предел, если рассказчик не путает, десять миллионов. В бенчмарках Aurora сравнивают с MySQL 5.6: с ростом толщины узла она масштабируется почти линейно, а MySQL уже нет. Александра развеселило, что на двух соседних диаграммах меняется шрифт, а на реальной нагрузке отставание реплики падает, по его словам, с секунд до примерно пяти миллисекунд.