КулЛиб - Классная библиотека! Скачать книги бесплатно 

Базы данных. Инжиниринг надежности [Лейн Кэмпбелл] (pdf) читать онлайн

Книга в формате pdf! Изображения и текст могут не отображаться!


 [Настройки текста]  [Cбросить фильтры]
Database Reliability Engineering

Designing and Operating Resilient
Database Systems

Laine Campbell and Charity Majors

Beijing

Boston Farnham Sebastopol

Tokyo

Лейн Кэмпбелл
Черити Мейджорс

Áàçû
äàííûõ
ИНЖИНИРИНГ НАДЕЖНОСТИ

ББК 32.973.233-018.2
УДК 004.65
К98

Кэмпбелл Лейн, Мейджорс Черити
К98 Базы данных. Инжиниринг надежности. — СПб.: Питер, 2020. — 304 с.: ил. — (Серия «Бестселлеры O’Reilly»).
ISBN 978-5-4461-1310-1
В сфере IT произошла настоящая революция — с инфраструктурой стали работать как с кодом.
Этот процесс создает не только новые проблемы, но и возможности для обеспечения безотказной
работы баз данных. Авторы подготовили это практическое руководство для всех, кто желает влиться
в сообщество современных инженеров по обеспечению надежности баз данных (database reliability
engineers, DBRE).

16+ (В соответствии с Федеральным законом от 29 декабря 2010 г. № 436-ФЗ.)

ББК 32.973.233-018.2
УДК 004.65

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

ISBN 978-1491925942 англ.

ISBN 978-5-4461-1310-1

Authorized Russian translation of the English edition of Database Reliability
Engineering (ISBN 9781491925942) © 2018 Laine Campbell and Charity Majors
This translation is published and sold by permission of O’Reilly Media, Inc., which
owns or controls all rights to publish and sell the same
© Перевод на русский язык ООО Издательство «Питер», 2020
© Издание на русском языке, оформление ООО Издательство «Питер», 2020
© Серия «Бестселлеры O’Reilly», 2020

Краткое содержание
Предисловие........................................................................................................................................... 13
Введение................................................................................................................................................... 14
От издательства..................................................................................................................................... 20
Глава 1. Введение в обеспечение надежности базы данных.................................................. 21
Глава 2. Управление уровнем качества обслуживания........................................................... 33
Глава 3. Управление рисками.......................................................................................................... 52
Глава 4. Оперативный контроль..................................................................................................... 72
Глава 5. Инжиниринг инфраструктуры.....................................................................................107
Глава 6. Управление инфраструктурой..................................................................................... 127
Глава 7. Резервное копирование и восстановление ............................................................. 142
Глава 8. Управление релизами......................................................................................................166
Глава 9. Безопасность.......................................................................................................................189
Глава 10. Хранение, индексирование и репликация данных..............................................221
Глава 11. Справочник по видам хранилищ данных...............................................................254
Глава 12. Примеры архитектур данных......................................................................................274
Глава 13. Как обосновать и внедрить DBRE............................................................................292
Об авторах.............................................................................................................................................302
Об обложке............................................................................................................................................303

Оглавление
Предисловие........................................................................................................................................... 13
Введение................................................................................................................................................... 14
Почему мы написали эту книгу................................................................................................. 15
Для кого эта книга.......................................................................................................................... 16
Структура издания......................................................................................................................... 16
Условные обозначения................................................................................................................. 19
От издательства..................................................................................................................................... 20
Глава 1. Введение в обеспечение надежности базы данных.................................................. 21
Основные принципы DBRE....................................................................................................... 22
Защита данных.......................................................................................................................... 22
Самообслуживание как фактор масштабирования..................................................... 24
Избавление от рутины........................................................................................................... 24
Базы данных — это не «особенные снежинки»............................................................. 25
Устранение барьеров между разработкой и эксплуатацией..................................... 26
Обзор работы по сопровождению и эксплуатации............................................................. 27
Иерархия потребностей............................................................................................................... 28
Выживание и безопасность.................................................................................................. 28
Любовь и принадлежность................................................................................................... 29
Уважение.................................................................................................................................... 30
Самоактуализация................................................................................................................... 31
Резюме................................................................................................................................................ 32
Глава 2. Управление уровнем качества обслуживания........................................................... 33
Зачем нужны целевые показатели качества обслуживания............................................ 33
Показатели уровня обслуживания........................................................................................... 35
Задержка..................................................................................................................................... 36
Доступность............................................................................................................................... 36

Оглавление  7

Пропускная способность....................................................................................................... 36
Надежность хранения............................................................................................................ 37
Стоимость — эффективность............................................................................................... 37
Определение целей обслуживания.......................................................................................... 38
Показатели задержки............................................................................................................. 38
Показатели доступности....................................................................................................... 41
Показатели пропускной способности............................................................................... 44
Мониторинг SLO и построение отчетов................................................................................ 46
Мониторинг доступности..................................................................................................... 47
Мониторинг задержки.................................................................................................................. 49
Мониторинг пропускной способности............................................................................. 50
Мониторинг стоимости и эффективности...................................................................... 50
Резюме................................................................................................................................................ 51
Глава 3. Управление рисками.......................................................................................................... 52
Факторы риска................................................................................................................................ 53
Неизвестные факторы и сложность.................................................................................. 53
Наличие ресурсов.................................................................................................................... 54
Человеческий фактор............................................................................................................. 54
Групповые факторы................................................................................................................ 55
Что мы делаем.................................................................................................................................. 56
Чего не надо делать........................................................................................................................ 57
Рабочий процесс: запуск........................................................................................................ 57
Оценка риска для сервиса..................................................................................................... 59
Ревизия архитектуры............................................................................................................. 61
Расстановка приоритетов...................................................................................................... 62
Управление рисками и принятие решений.................................................................... 66
Постепенное совершенствование............................................................................................. 69
Резюме................................................................................................................................................ 71
Глава 4. Оперативный контроль..................................................................................................... 72
Новые правила оперативного контроля................................................................................. 74
Относитесь к системам OpViz как к системам BI........................................................ 75
Тенденции в эфемерных распределенных средах........................................................ 75
Хранение ключевых показателей с высокой детализацией...................................... 77
Сохраняйте простоту архитектуры................................................................................... 78
Структура OpViz............................................................................................................................ 79

8  Оглавление

Входные данные.............................................................................................................................. 80
Телеметрия/показатели........................................................................................................ 82
События...................................................................................................................................... 84
Журнал событий...................................................................................................................... 84
Выходные данные.................................................................................................................... 84
Первоначальный запуск мониторинга.................................................................................... 85
Безопасны ли данные?........................................................................................................... 87
Работает ли сервис?................................................................................................................ 88
Испытывают ли клиенты трудности?............................................................................... 89
Оснащение приложения.............................................................................................................. 90
Контроль выполнения в распределенных системах........................................................... 91
События и журналы................................................................................................................ 92
Оснащение серверов и экземпляров баз данных................................................................. 93
События и журналы................................................................................................................ 94
Оснащение хранилища данных................................................................................................. 95
Уровень соединения с хранилищем данных.................................................................. 96
Контроль внутри базы данных............................................................................................ 99
Объекты базы данных..........................................................................................................104
Запросы к базе данных.........................................................................................................105
Проверки и события базы данных...................................................................................106
Резюме..............................................................................................................................................106
Глава 5. Инжиниринг инфраструктуры.....................................................................................107
Хосты................................................................................................................................................107
Физические серверы.............................................................................................................107
Работа на уровне системы и ядра.....................................................................................108
Сети хранения данных.........................................................................................................120
Преимущества физических серверов..............................................................................120
Недостатки физических серверов....................................................................................120
Виртуализация..............................................................................................................................120
Гипервизор...............................................................................................................................121
Параллелизм............................................................................................................................121
Хранилище...............................................................................................................................122
Примеры использования.....................................................................................................122
Контейнеры....................................................................................................................................123
База данных как сервис..............................................................................................................123
Проблемы DBaaS...................................................................................................................124
DBRE и DBaaS........................................................................................................................125
Резюме..............................................................................................................................................126

Оглавление  9

Глава 6. Управление инфраструктурой..................................................................................... 127
Контроль версий...........................................................................................................................128
Определение конфигурации.....................................................................................................129
Сборка из конфигурации...........................................................................................................131
Поддержка конфигурации........................................................................................................132
Применение определений конфигурации.....................................................................133
Определение и оркестрация инфраструктуры...................................................................134
Определение монолитной инфраструктуры................................................................135
Разделение по вертикали....................................................................................................135
Разделенные уровни (горизонтальные определения)..............................................137
Приемочное тестирование и согласованность...................................................................137
Каталог сервисов..........................................................................................................................138
Собираем все вместе....................................................................................................................139
Среды разработки.........................................................................................................................140
Резюме..............................................................................................................................................141
Глава 7. Резервное копирование и восстановление ............................................................. 142
Основные принципы...................................................................................................................143
Физическое или логическое?............................................................................................143
Автономное или оперативное?..........................................................................................144
Полное, инкрементное и дифференциальное..............................................................144
Соображения по восстановлению данных...........................................................................145
Сценарии восстановления.........................................................................................................145
Сценарии планового восстановления.............................................................................146
Незапланированные сценарии..........................................................................................148
Область действия сценария...............................................................................................151
Последствия сценария.........................................................................................................152
Содержание стратегии восстановления...............................................................................152
Структурный блок № 1: обнаружение............................................................................153
Структурный блок № 2: многоуровневое хранилище..............................................155
Структурный блок № 3: разнообразие инструментария..........................................157
Структурный блок № 4: тестирование...........................................................................159
Определение стратегии восстановления..............................................................................160
Онлайновое быстрое хранилище с полными и инкрементными .
резервными копиями............................................................................................................160
Онлайновое медленное хранилище с полными и инкрементными .
резервными копиями............................................................................................................161
Автономное хранилище.......................................................................................................163
Хранилище объектов............................................................................................................164
Резюме..............................................................................................................................................165

10  Оглавление

Глава 8. Управление релизами......................................................................................................166
Обучение и сотрудничество.....................................................................................................166
Станьте источником знаний..............................................................................................167
Развивайте общение..............................................................................................................168
Знания из конкретной области.........................................................................................168
Сотрудничество......................................................................................................................171
Интеграция.....................................................................................................................................172
Предпосылки...........................................................................................................................173
Тестирование.................................................................................................................................176
Приемы разработки с тестированием.............................................................................176
Тестирование после фиксации в VCS............................................................................177
Тестирование на полном наборе данных.......................................................................178
Нисходящее тестирование..................................................................................................179
Операционные тесты............................................................................................................180
Развертывание...............................................................................................................................181
Миграции и управление версиями..................................................................................181
Анализ последствий..............................................................................................................182
Паттерны миграции..............................................................................................................183
Вручную или автоматически?...........................................................................................187
Резюме..............................................................................................................................................188
Глава 9. Безопасность.......................................................................................................................189
Цель безопасности.......................................................................................................................189
Защита данных от кражи.....................................................................................................190
Защита от целенаправленного повреждения...............................................................190
Защита от случайного повреждения...............................................................................190
Защита данных от раскрытия............................................................................................191
Стандарты соответствия и аудита....................................................................................191
Безопасность базы данных как функция.............................................................................191
Обучение и сотрудничество.....................................................................................................192
Самообслуживание...............................................................................................................193
Интеграция и тестирование...............................................................................................194
Оперативный контроль.......................................................................................................195
Уязвимости и эксплойты...........................................................................................................197
STRIDE.....................................................................................................................................197
DREAD......................................................................................................................................198
Основные меры предосторожности.................................................................................199

Оглавление  11

Отказ в обслуживании.........................................................................................................200
SQL-инъекция.........................................................................................................................204
Сетевые протоколы и протоколы аутентификации..................................................206
Шифрование данных..................................................................................................................207
Финансовые данные.............................................................................................................207
Личные данные о здоровье.................................................................................................208
Данные частных лиц.............................................................................................................208
Военные и правительственные данные..........................................................................208
Конфиденциальные данные и коммерческие тайны.................................................208
Передача данных....................................................................................................................209
Данные, хранящиеся в базе................................................................................................214
Данные в файловой системе..............................................................................................217
Резюме..............................................................................................................................................220
Глава 10. Хранение, индексирование и репликация данных..............................................221
Хранение структуры данных....................................................................................................221
Хранение данных в виде таблиц.......................................................................................222
Отсортированные строковые таблицы .
и журнально-структурированные деревья со слиянием..........................................226
Индексирование.....................................................................................................................229
Журналы и базы данных.....................................................................................................230
Репликация данных.....................................................................................................................230
Репликация с одним ведущим узлом..............................................................................231
Репликация с несколькими ведущими узлами...........................................................246
Резюме..............................................................................................................................................253
Глава 11. Справочник по видам хранилищ данных...............................................................254
Концептуальные особенности хранилища данных..........................................................255
Модель данных.......................................................................................................................255
Транзакции...............................................................................................................................259
BASE...........................................................................................................................................265
Внутренние характеристики хранилища данных.............................................................267
Хранилище...............................................................................................................................267
Вездесущая теорема CAP....................................................................................................268
Компромисс между согласованностью и задержкой.................................................270
Доступность.............................................................................................................................272
Резюме..............................................................................................................................................273

12  Оглавление

Глава 12. Примеры архитектур данных......................................................................................274
Архитектурные компоненты....................................................................................................274
Внешние хранилища данных.............................................................................................274
Уровень доступа к данным.................................................................................................276
Прокси базы данных ............................................................................................................276
Системы обработки событий и сообщений..................................................................279
Кэши и устройства памяти.................................................................................................281
Архитектуры данных...................................................................................................................285
Лямбда и каппа.......................................................................................................................285
Порождение событий...........................................................................................................288
CQRS..........................................................................................................................................289
Резюме..............................................................................................................................................291
Глава 13. Как обосновать и внедрить DBRE............................................................................292
Культура обеспечения надежности баз данных.................................................................293
Разрушение барьеров...........................................................................................................293
Принятие решений на основе данных............................................................................300
Целостность и возможность восстановления данных..............................................300
Резюме..............................................................................................................................................301
Об авторах.............................................................................................................................................302
Об обложке............................................................................................................................................303

Предисловие
Мы сейчас переживаем время беспрецедентных преобразований и потрясений
в индустрии баз данных (БД). Жизненные циклы внедрения технологий ускорились до такой степени, что у кого угодно голова пойдет кругом — и из-за сложных
проблем, и из-за открывающихся возможностей.
Архитектура БД развивается столь быстро, что привычные задачи уже не требуют
решения, а связанные с ними навыки, в которые вложено так много сил, утратили
актуальность. Новые требования безопасности, концепция инфраструктуры как
кода (Infrastructure as Code, IaC), возможности облачных технологий (таких как
база данных как сервис (Database as a Service, DBaaS)) позволили — а фактически
потребовали от нас — переосмыслить пути разработки.
Нам пришлось перейти от традиционных административных задач к процессу,
в котором основное внимание уделяется архитектуре, автоматизации, разработке
программного обеспечения (в широком смысле), непрерывной интеграции и распространению, средствам мониторинга и обслуживания систем. При этом ценность
и значимость данных, которые мы защищали и о которых заботились все это время,
увеличились как минимум на порядок, и нет причин ожидать, что они не будут продолжать расти. Сегодня у нас есть прекрасная возможность внести существенный
вклад в эту сферу.
Несомненно, многие из тех, кто когда-то считали себя выдающимися администраторами БД, сейчас рискуют утратить позиции или даже вовсе остаться за бортом.
Вместе с тем в нашу область приходят новички, которые жаждут новой организационной парадигмы. Решение в обоих случаях одно и то же: с готовностью и радостью
учиться, самосовершенствоваться, сохранять оптимизм, энтузиазм и уверенность,
необходимые для выполнения задачи и доведения ее до конца, несмотря на неизбежные трудности и подводные камни. Эта книга — замечательное достижение.
В ней описан новый подход к проектированию и эксплуатации инфраструктуры
БД, и она представляет собой руководство и сборник идей. В книге все то, что мы
привыкли делать, обсуждается и переосмысливается в новом ключе — как обеспечение надежности БД.
Пол Валле (Paul Vallée), президент
и исполнительный директор компании Pythian

Введение
В этой книге мы надеемся продемонстрировать вам общие принципы для перехода на следующий уровень работы с базами данных — уровень специалиста по
обеспечению надежности баз данных (DBR-инженер, Database Reliability Engineer,
DBRE). Как многим представляется работа администратора баз данных? Любой
программист или системный инженер, сотрудничавший с этими загадочными личностями, имеет, вероятно, свое несколько предвзятое мнение о них.
Традиционно администраторы БД (Database Administrators, DBA) досконально
разбирались во внутреннем устройстве БД, жили и дышали оптимизатором, системой обработки запросов, настройкой и созданием высокопроизводительных
специализированных систем. Когда им это потребовалось, они приобрели и другие
навыки, позволяющие улучшить работу базы данных. Они узнали, как распределять нагрузку между процессорами (Central Processing Units, CPU) компьютеров
и дисками, как настраивать БД для использования особенностей CPU и как оценивать требуемую емкость подсистем хранения.
Когда администраторы БД столкнулись с проблемами области видимости, они
научились строить графы для параметров сущностей, определенных в качестве
ключевых. Столкнувшись с архитектурными ограничениями, узнали об уровнях
кэширования. Встретившись с ограничениями отдельных узлов в системе, они
изучили новые подходы и типовые решения в проектировании, такие как сегментирование данных (sharding), и способствовали разработкам в этом направлении.
В то же время они продолжали осваивать новые методики работы: аннулирование
кэша, перебалансировку данных и непрерывные изменения БД.
Однако администраторы БД долгое время творили в башне из слоновой кости. Они
пользовались другими инструментами, работали на другом оборудовании и писали
на других языках. Администраторы БД писали на SQL, системные инженеры — на
Perl, программисты — на C++, веб-разработчики — на PHP, а сетевые инженеры
предпочитали собственные инструменты. Лишь половина команд пользовалась
хоть каким-то контролем версий, и они, конечно же, не общались между собой
и не заходили на территорию друг друга. Да и как бы они могли это сделать? Это
было бы похоже на пересечение границ другой страны.

Почему мы написали эту книгу  15

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

Почему мы написали эту книгу
Мы мечтали об этой книге около пяти лет. Лейн пришла на должность администратора без какой-либо специальной технической подготовки. Она не была
ни инженером-программистом, ни системным администратором, а решила построить карьеру в технической сфере после ухода из мира музыки и театра. Имея
такой опыт, она легко нашла в базах данных знакомые ей концепции структуры,
гармонии, контрапункта и оркестровки.
С тех пор ей пришлось иметь дело, вероятно, с сотней администраторов БД: нанять,
обучить их и работать с ними. Люди, работающие с базами данных, — очень разношерстная компания. Одни пришли из программирования, другие — из системного администрирования. Есть и такие, кто раньше занимался аналитикой данных
и бизнесом. Однако все они отличались чувством ответственности за безопасность
и доступность данных компании.
Мы исполняли роли управляющих данными с жесткостью, граничащей с нездоровой жестокостью. А еще мы стали связующим звеном между разработчиками программного обеспечения и системными инженерами. Кто-то может сказать, что мы
стали первыми системными инженерами (DevOps), стоящими на стыке областей.
Опыт Черити тесно связан с запуском стартапов и эксплуатационной работой.
За ее плечами славная, хоть и пестрая история быстрого запуска (bootstrapping)
инфраструктур, молниеносного принятия решений, способных создать или
разрушить стартап, рискованных сложных решений в условиях сильно ограниченных ресурсов. В основном плюс-минус успешных. К тому же она оказалась
администратором БД, который любит данные. Она всегда работала в командах
эксплуатации, где не было отдельного администратора БД, поэтому команды
разработчиков и эксплуатации программного обеспечения в итоге делили эту
работу между собой.
Имея столь разное прошлое и уже довольно долго работая с базами данных, мы
признали и приняли тенденции последнего десятилетия. Жизнь администратора
БД часто трудна и незаметна. Теперь у нас есть инструменты и коллективная поддержка, что позволит изменить эту роль, причислить администраторов БД к людям

16  Введение

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

Для кого эта книга
Для всех, кто занимается проектированием, созданием и эксплуатацией надежных
хранилищ данных. Она для вас, если вы разработчик программного обеспечения
и хотите расширить свои познания о БД. Или если вы системный инженер, желающий сделать то же самое. Если вы профессионал в области БД, который хочет
расширить набор навыков, то эта книга будет полезна и вам. А новичку в этой области она поможет составить ясное представление о работе с базами данных.
Мы предполагаем, что у вас уже есть некоторые технические знания в области
администрирования операционных систем Linux/Unix, а также веб-систем и/или
облачных архитектур. Предполагается также, что вы хорошо разбираетесь в одной
из дисциплин — системном администрировании или разработке программного
обеспечения — и заинтересованы в расширении своего технического кругозора
и включении в него новой дисциплины — разработки БД. Либо, в другом варианте,
вы начинаете карьеру в качестве специалиста по проектированию БД и стремитесь
углубить технические знания.
Если же вы руководитель проекта, то книга поможет вам понять, что требуется
для создания хранилищ данных, которые будут лежать в основе ваших сервисов.
Мы твердо убеждены в том, что руководителям необходимо понимать принципы
работы и организации БД, чтобы их команды и проекты были более успешными.
Да, возможно, у вас нет специального технического образования. Может быть,
вы были бизнес-аналитиком и стали администратором БД неожиданно, сменив
специализацию и научившись управлять базами данных. Есть много специалистов
по базам данных, пришедших в эту область через Excel, а не через разработку или
системное администрирование.

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

Структура издания  17

мы углубимся в данные: их моделирование, хранение, тиражирование, доступ к ним
и многое другое. Кроме того, обсудим выбор архитектуры и конвейеры данных. Это
должно быть захватывающе!
Есть веская причина тому, что мы уделяем столь пристальное внимание эксплуатации: вы не станете хорошим инженером по обеспечению надежности БД (DBRE),
не будучи хорошим инженером по надежности вообще (RE). А им вы не станете,
не будучи просто хорошим инженером. Современный DBR-инженер не только хорошо разбирается в основах системного проектирования, но и понимает проблемы
данных, связанные с конкретной предметной областью.
Однако дело в том, что запускать сервисы данных может любой инженер. Сейчас
мы говорим на одном языке. Мы используем одни и те же репозитории, одни и те же
процессы проверки кода. Забота о БД — это расширение инженерной дея­тельности,
взбитые сливки из специальных знаний и умений на вершине торта из функционирующих систем различного масштаба. Точно так же, для того чтобы стать сугубо
сетевым инженером, нужно сначала выучиться на инженера, а затем получить
дополнительные знания о том, как обрабатывать трафик, чего следует опасаться,
каковы современные передовые методики, как оценивать топологию сети и т. д.
Вот краткий перечень того, что вас ожидает.
Глава 1 представляет собой введение в концепцию обеспечения надежности БД.
Мы начнем с основополагающих принципов, перейдем к работе по сопровождению
и эксплуатации — тому центру, вокруг которого вращается DBRE, — и, наконец,
соорудим каркас для возведения концепции DBRE с опорой на пирамиду потребностей Маслоу.
Главу 2 начнем с требований уровня обслуживания сервисов. Они так же важны,
как и требования к характеристикам продукта. В этой главе мы обсудим, что такое
требования уровня обслуживания и как их определить, — что на самом деле легче
сказать, чем сделать. Затем поговорим, как измерить соответствующие параметры
и как работать с ними в динамике.
В главе 3 мы познакомимся с оценкой рисков и управлением ими. После обсуж­
дения основ и рисков вообще перейдем к практическим процессам включения
оценки рисков в разработку систем и БД. Рассмотрим также подводные камни
и различные сложности.
В главе 4 поговорим об оперативном контроле. Обсудим показатели и события.
Вы узнаете, как составить план того, что нужно начать измерять и что повторять
регулярно. Подробно рассмотрим компоненты систем мониторинга и клиентские
приложения, которые взаимодействуют с ними.
В главах 5 и 6 мы углубимся в проектирование инфраструктуры и управление ею.
Обсудим принципы построения хостов для хранилищ данных. Мы погрузимся

18  Введение

в виртуализацию и контейнеризацию, управление конфигурацией, автоматизацию
и оркестрацию, чтобы помочь вам разобраться во всех составных частях, необходимых для построения систем, которые обеспечивают хранение данных и доступ
к ним.
Глава 7 посвящена резервному копированию и восстановлению данных. Это, пожалуй, самое важное для освоения DBE. Потерял данные — все, игра окончена.
Исходя из требований к уровню качества сервиса, мы выбираем подходящие методы резервного копирования и восстановления данных, а также способы масштабирования и проверки этого важного, но часто пропускаемого шага.
В главе 8 мы обсудим управление версиями. Как тестировать, подготавливать
и развертывать изменения в хранилищах данных? Как быть с изменениями в коде
доступа к данным и SQL? Основные темы — развертывание, интеграция и распространение.
Глава 9 посвящена безопасности. Безопасность данных имеет решающее значение для работоспособности компании. В этой главе описаны стратегии планирования безопасности постоянно развивающихся инфраструктур данных и управ­
ления ею.
В главе 10 поговорим о хранении, индексации и репликации данных. Мы обсудим,
как хранятся реляционные данные, а затем сравним их с отсортированными строками и структурированными объединениями деревьев. Рассмотрев разные варианты
индексации, изучим топологии репликации данных.
Глава 11 представляет собой путеводитель в области хранения данных. Здесь мы
рассмотрим множество различных факторов, которые вам предстоит находить
и  учитывать для тех хранилищ данных, что вы будете оценивать или сопровождать.
Сюда входят как концептуальные особенности, имеющие огромное значение для
разработчиков и архитекторов приложений, так и внутренние характеристики,
связанные с физической реализацией хранилищ.
В главе 12 мы рассмотрим некоторые из наиболее распространенных типовых
решений (паттернов), применяемых при проектировании архитектур распределенных БД, и конвейеры, с которыми они связаны. Начнем с архитектурных компонентов, из которых обычно состоит «среда обитания» (экосистема) базы данных,
и познакомимся с обеспечиваемыми ими преимуществами, со связанными с ними
сложностями и с основными принципами их использования. Затем исследуем архитектуры и конвейеры — хотя бы на нескольких примерах.
Наконец, в главе 13 мы обсудим создание культуры обеспечения надежности БД
в организации. Исследуем различные способы, с помощью которых в современной
организации можно превратить специалиста по обеспечению надежности баз данных из администратора в инженера.

Условные обозначения  19

Условные обозначения
В этой книге применяются следующие типографские обозначения.
Курсив
Курсивом выделяются новые термины.
Рубленый шрифт

Им обозначены URL-адреса, адреса электронной почты.
Моноширинный шрифт

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

Этот элемент обозначает совет, подсказку или предложение.

Такой элемент обозначает примечание.

Данный элемент обозначает предупреждение.

От издательства
Ваши замечания, предложения, вопросы отправляйте по адресу comp@piter.com (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.

1

Введение в обеспечение
надежности базы данных

Цель книги — предоставить вам руководство и создать базу для того, чтобы вы
смогли стать действительно отличным инженером по обеспечению надежности БД.
Бен Трейнор (Ben Treynor), вице-президент по разработкам в Google, так говорит
об обеспечении надежности: «SR-инженеры в основном выполняют ту же работу,
которой ранее занималась служба эксплуатации, но их знания и навыки позволяют
разрабатывать и реализовывать автоматизированные решения, заменяющие человеческий труд, и именно такую задачу ставит перед ними компания»1.
Современные специалисты по БД должны быть инженерами, а не администраторами. Мы строим новое. Мы создаем новое. Занимаясь сопровождением систем, мы работаем в одной команде, и любая наша проблема становится общей.
При проектировании, построении и эксплуатации хранилищ производственных
(промышленных) данных и создаваемых внутри них структур мы, как инженеры,
ориентируемся на повторяемые процессы, проверенные знания и экспертные оценки. А как специалисты по надежности БД, мы должны понимать принципы работы
с базами данных и обладать опытом их эксплуатации.
Если вы обратите внимание на компоненты современных инфраструктур, не отвечающие непосредственно за хранение данных (non-storage), то увидите, что
это системы, которые легко создавать, запускать и уничтожать с помощью программных и часто автоматизированных средств. Время жизни этих компонентов
может измеряться днями, а иногда даже часами или минутами. Когда один из них
исчезает, взамен появляется множество других, позволяющих сохранить качество
обслуживания на ожидаемом уровне.
Наша следующая цель — перечислить основные принципы и методики проектирования, создания и эксплуатации хранилищ данных в рамках парадигм обеспечения
надежности и культуры DevOps. Вы можете воспользоваться этими знаниями
и применить их к любой технологии или среде БД, с которой вам придется работать
на любом этапе развития организации.
1

Бейер Б., Джоунс К., Петофф Д., Мёрфи Н. Site Reliability Engineering. Надежность
и безотказность как в Google. — СПб.: Питер, 2019. — С. 38.

22  Глава 1



Введение в обеспечение надежности базы данных

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

Защита данных
Защита данных всегда была и остается основополагающим принципом в работе любого профессионала в области БД. Общепринятый подход подразумевает следующее.
‰‰Строгое разделение обязанностей между инженером-программистом и инже-

нером баз данных.

‰‰Строго определенные и регулярно тестируемые процессы резервного копиро-

вания и восстановления.

‰‰Хорошо организованные и регулярно тестируемые процедуры безопасности.
‰‰Дорогостоящее программное обеспечение для баз данных, гарантирующее вы-

сокий уровень надежности и сохранности данных.

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

В командах, где царит культура сотрудничества, строгое разделение обязанностей
может стать фактором не только обременительным, но даже ограничивающим инновации и скорость реагирования. В главе 8 мы обсудим способы создания систем
поддержки и поговорим о том, как снизить потребность в разделении обязанностей. Кроме того, в такой среде можно больше внимания уделятьтестированию,
автоматизации и минимизации воздействия, а не расширять контроль изменений.
В настоящее время архитекторы и инженеры чаще, чем когда-либо, выбирают
хранилища данных с открытым исходным кодом, а они не способны гарантировать
такую стабильность и надежность хранения, какие прежде обеспечивала система
управления базами данных (СУБД) Oracle. Иногда это дает выигрыш в производительности для команды, нуждающейся в быстром масштабировании. Выбор
правильного хранилища данных и понимание последствий этого выбора мы рассмотрим в главе 11. Мы быстро привыкаем к существованию множества разнообразных
инструментов для работы с данными и к возможности их эффективного выбора.
Базовая система хранения также претерпела значительные изменения. В мире, где
системы часто виртуализируются, проектирование БД часто подразумевает создание сетевого и эфемерного хранилища. Мы подробно обсудим это в главе 5.

Основные принципы DBRE  23

ХРАНЕНИЕ ПРОИЗВОДСТВЕННЫХ ДАННЫХ
В ЭФЕМЕРНЫХ ХРАНИЛИЩАХ
В 2013 году компания Pinterest перевела копии своих баз данных MySQL в эфемерное хранилище на Amazon Web Services (AWS). Эфемерное хранилище, в сущности,
означает, что если отдельное вычисление завершается сбоем или прекращает работу,
то все, что хранилось на диске, теряется. Pinterest выбрала вариант эфемерного хранилища из-за постоянства его пропускной способности и низкой задержки.
Потребовались значительные инвестиции в автоматическое и высоконадежное резервное копирование и восстановление данных, а также в разработку приложений,
позволяющих справиться с потерей кластера при восстановлении узлов. Эфемерное
хранилище не дает возможности создавать моментальные снимки — это означало,
что для восстановления необходимо было распространять по Сети полные копии
базы данных, вместо того чтобы прикрепить моментальный снимок при подготовке
к развертыванию журналов транзакций.
Это свидетельствует о том, что поддерживать надежность и безопасность данных
в эфемерных средах вполне возможно при условии правильной организации процессов и использования правильных инструментов!

Новые принципы защиты данных могут быть такими.
‰‰Ответственность за все общие данные несут все команды разработчиков разной

специализации.

‰‰Стандартизированные и автоматизированные процессы резервного копирова-

ния и восстановления данных проходят одобрение инженерами по обеспечению
надежности БД.

‰‰Стандартизированные политики и процедуры безопасности проходят одобрение

отделом DBRE и отделом безопасности.

‰‰Все политики внедряются путем автоматического распространения и развер-

тывания.

‰‰Хранилище данных выбирается исходя из требований к данным, а оценка по-

требности в надежности их хранения становится частью процесса принятия
решений.

‰‰Ориентироваться следует в первую очередь на автоматизированные процессы,

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

‰‰Внедрение изменений включается в процедуры развертывания и в автоматиза-

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

24  Глава 1



Введение в обеспечение надежности базы данных

Самообслуживание как фактор масштабирования
Талантливый DBR-инженер — более редкий специалист, чем инженер по обеспечению надежности информационных систем (SR-инженер, Site Reliability Engineer,
SRE). Большинство компаний не могут позволить себе содержать более одного или
двух таких специалистов. Таким образом, чтобы они приносили максимальную
пользу, их деятельность должна выражаться в создании систем самообслуживания, которые смогут использовать все другие команды. Устанавливая стандарты
и предоставляя инструменты, эти команды смогут развертывать новые сервисы
и вносить соответствующие изменения в требуемом темпе, не выстаивая в очереди
к и без того перегруженному работой инженеру БД. Вот несколько примеров таких
методов самообслуживания.
‰‰Обеспечить сбор необходимых показателей из хранилищ данных благодаря

предоставлению соответствующих плагинов.

‰‰Создать утилиты резервного копирования и восстановления данных, которые

могут развертываться в новых хранилищах данных.

‰‰Определить эталонные архитектуры и конфигурации для хранилищ данных,

которые прошли одобрение командами эксплуатации и теперь могут развертываться командами разработчиков.

‰‰Определить совместно с отделом безопасности стандарты для развертывания

хранилищ данных.

‰‰Разработать безопасные методы развертывания и тестовые сценарии для вне-

дрения изменений в БД.

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

Избавление от рутины
В командах SRE Google часто используют фразу «избавление от рутины» (toil), которая обсуждается в главе 5 книги Google SRE. В той книге есть такое определение:
«Рутина — это ручная, однообразная, поддающаяся автоматизации оперативная
работа, связанная с поддержкой работающего сервиса. Ее результаты не имеют
ценности в перспективе, а трудоемкость растет линейно по мере роста сервиса»1.
Эффективная автоматизация и стандартизация необходимы для того, чтобы
DBR-инженеров не перегружали рутиной. В этой книге мы приведем несколько
примеров рутины в работе специалистов по обеспечению надежности баз данных
1

Бейер Б., Джоунс К., Петофф Д., Мёрфи Н. Site Reliability Engineering. Надежность
и безотказность как в Google. — СПб.: Питер, 2019. — С. 91.

Основные принципы DBRE  25

и расскажем о методах, позволяющих сократить ее объем. При этом понятие «рутина» остается расплывчатым, о нем существует множество предвзятых мнений,
и у разных людей оно свое. Обсуждая рутину, мы говорим именно о выполняемой
вручную, повторяющейся, нетворческой и неинтересной работе.
ВНЕСЕНИЕ ИЗМЕНЕНИЙ В БАЗУ ДАННЫХ ВРУЧНУЮ
Нередко инженеров БД просят проверить базы данных и внести в них изменения,
которые могут включать в себя модификации таблиц или индексов, добавление,
изменение или удаление данных или любые другие действия. Все считают, что администратор базы данных вносит эти изменения и отслеживает их влияние в режиме
реального времени.
На одном клиентском сайте частота изменений была достаточно велика, и это значительно влияло на его работу. В итоге мы тратили около 20 часов в неделю, внося
изменения во всей среде. Излишне говорить, что несчастный администратор баз данных, который тратил половину рабочей недели на выполнение этих повторя­ющихся
задач, выдохся и уволился.
Столкнувшись с нехваткой ресурсов, руководство наконец позволило команде управления базой данных создать утилиту для автоматизированного применения изменений во всей схеме базы. Инженеры-программисты могли просто однократно запустить ее после того, как инженер базы данных рассмотрел и одобрил очередной набор
изменений. Вскоре все стали доверять этому инструменту для внесения изменений,
что позволило команде DBRE переключиться на интеграцию этих процессов в стек
развертывания продукта.

Базы данных — это не «особенные снежинки»
Наши системы важны не более и не менее, чем любые другие компоненты, обслуживающие запросы бизнеса. Мы должны стремиться к стандартизации, автоматизации и устойчивости. Критически важно понимать, что компоненты кластеров
баз данных — это не священная корова. Мы должны быть готовы потерять любой
компонент и спокойно и эффективно заменить его. Уязвимые хранилища данных
за стеклом в вычислительных центрах остались в прошлом.
Сейчас, чтобы показать разницу между «особенной снежинкой» и стандартным
служебным компонентом, часто используют аналогию с домашними питомцами
и крупным рогатым скотом. Считают, что первым ее употребил Билл Бейкер
(Bill Baker) — инженер Microsoft. Сервер — «домашний питомец» — это тот, кого
вы кормите, за кем ухаживаете, а если он болеет, то заботитесь о его здоровье.
У него даже есть имя. На Travelocity в 2000 году у наших серверов были имена
из сериала о Симпсонах, а два SGI-сервера под управлением Oracle назывались
Patty и Selma.

26  Глава 1



Введение в обеспечение надежности базы данных

У серверов из разряда «крупного рогатого скота» нет имен, а есть номера. Вы не тратите время на их настройку и уж тем более не входите на каждый отдельный хост.
Когда они заболевают, вы просто удаляете их из стада. Если болезней будет слишком
много, то вам, конечно, придется сохранить этих коров, чтобы разобраться в причинах.
Хранилища данных — один из последних оплотов традиции «домашних любимцев». В конце концов, они хранят Важные Данные и просто не могут рассматриваться как расходный материал с коротким сроком службы и полной стандартизацией.
А как быть со специальными правилами репликации для отчетов? Как насчет различных конфигураций серверов-дублеров?

Устранение барьеров между разработкой
и эксплуатацией
Инфраструктура, конфигурации, модели данных и сценарии — все это компоненты
программного обеспечения. Изучайте жизненный цикл разработки программного обеспечения и участвуйте в нем, как любой инженер-программист — пишите
код, тестируйте, выполняйте интеграцию и сборку, тестируйте и развертывайте.
Да, лишнее тестирование не повредит.
К такому изменению парадигмы могут быть не готовы те, кто пришел из эксплуа­
тации и написания скриптов. Может возникнуть своего рода несогласованность
нагрузки между тем, как инженеры-программисты управляют организацией, и тем,
как построены системы и сервисы для нужд этой организации. Компании, занимающиеся созданием программного обеспечения, имеют очень четкие подходы
к разработке, тестированию и развертыванию функций и приложений.
В традиционной среде основной процесс проектирования, создания, тестирования
и развертывания инфраструктуры и сопутствующих сервисов для производства все­
гда состоял из разработки программного обеспечения (Software Engineering, SWE),
проектирования (инжиниринга) систем (System Engineering, SE) и администрирования БД. Необходимость изменения парадигмы подталкивает к устранению описанной
«несогласованности нагрузки», что означает: DBR-инженерам и системным инженерам для выполнения своей работы приходится пользоваться схожими принципами.

Инженеры-программисты должны разбираться в эксплуатации!
От специалистов команды эксплуатации часто требуют: научитесь писать код
или идите домой. Мы с этим согласны, но и обратное должно быть верно. Инженеры-программисты, которых не заставляют вникать в процесс эксплуатации,
а также изучать принципы и методы работы инфраструктуры, будут создавать
нестабильный, неэффективный и потенциально небезопасный код. «Согласование
нагрузки» будет достигнуто только в том случае, если все специалисты окажутся
за одним столом!

Обзор работы по сопровождению и эксплуатации   27

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

Обзор работы по сопровождению
и эксплуатации
Одно из основных направлений деятельности инженера по обеспечению надежности БД — работа по сопровождению и эксплуатации. Это основа и строительный
материал для проектирования, тестирования, сборки и эксплуатации любой системы
с нетривиальными требованиями к масштабированию и надежности. Это означает,
что если вы хотите стать инженером БД, то вам нужно разбираться в этих вещах.
На макроуровне работа по сопровождению не имеет особого значения. Команды
эксплуатации воплощают совокупность всех навыков, знаний и установок, которые
компания выстроила вокруг практики доставки и управления качеством систем
и программного обеспечения. Это неявные и явные ценностные установки, привычки, коллективные знания и системы поощрений. На результат влияют все: от
специалистов из отдела технической поддержки до специалистов по производству
и генерального директора.
Слишком часто это не очень хорошо налажено. Во многих компаниях культура
организации процесса эксплуатации просто ужасна. В результате за работой по
сопровождению закрепляется отпугивающая многих плохая репутация, будь то
эксплуатация системы, базы данных или сети. Несмотря на это, культура процесса эксплуатации является одним из основных показателей того, как организация
решает свою техническую задачу. Поэтому, если вы скажете, что ваша компания
не занимается сопровождением, мы просто не станем с ней связываться.
Возможно, вы разработчик программного обеспечения или сторонник инфраструктуры и платформ как сервиса? Или сомневаетесь, что бесстрашному инженеру
базы данных так уж нужны знания о ее эксплуатации? Не стоит надеяться на то,
что бессерверные вычислительные модели освободят инженеров-программистов
от необходимости думать или заботиться о сопровождении. На самом деле все наоборот. Это дивный новый мир, в котором нет специальных команд эксплуатации,
а разработкой соответствующей поддержки для вас занимаются инженеры Google
SRE и AWS, а также PagerDuty, DataDog и др. Это мир, в котором специалисты
по внедрению должны намного лучше разбираться в работе по сопровождению
и эксплуатации, архитектуре и производительности, чем сейчас.

28  Глава 1



Введение в обеспечение надежности базы данных

Иерархия потребностей
Одна часть наших читателей пришла к этой книге, имея опыт работы на предприя­
тиях, а другая — в стартапах. Приступая к изучению системы, стоит подумать о том,
что бы вы сделали в первый же день, взяв на себя ответственность за эксплуатацию
ее БД. Есть ли у вас резервные копии? Они работают? Вы в этом уверены? Есть ли
реплика, к которой можно откатиться в случае сбоя? Вы знаете, как это сделать?
Подключена ли она к тому же кабелю питания или маршрутизатору, размещена ли
на том же оборудовании и находится ли в той же зоне доступности, что и основная
база данных? Если резервные копии станут каким-либо образом непригодными,
узнаете ли вы об этом? Как именно?
Другими словами, нужно поговорить об иерархии потребностей базы данных.
Для людей существует иерархия потребностей Маслоу — пирамида желаний,
которые должны быть удовлетворены, чтобы мы процветали. К ним относятся
физиологическое выживание, безопасность, любовь и принадлежность, уважение
и самоактуализация. В основе пирамиды лежат базовые потребности, такие как выживание. После удовлетворения каждого уровня можно переходить на следующий:
от выживания — к безопасности, от безопасности — к любви и принадлежности
и т. д. Удовлетворив желания первых четырех уровней, мы достигаем самоактуализации и теперь можем безопасно исследовать, творить и добиваться наиболее
полного выражения своего уникального потенциала. Такова иерархия потребностей для людей. Используем это как метафору для того, что нужно базам данных.

Выживание и безопасность
Наиболее важные потребности вашей базы данных — это резервное копирование,
репликация и восстановление после отказа. У вас есть база данных? Она действующая? Вы можете ее пропинговать? Ваше приложение отвечает? У нее есть резервная копия? Работает ли механизм восстановления? Если вдруг это окажется
не так, как вы об этом узнаете?
Ваши данные в безопасности? Существует ли несколько рабочих копий данных?
Знаете ли вы, как выполнить восстановление после сбоя? Распределены ли копии
данных по нескольким зонам физической доступности, нескольким кабелям питания
или стойкам? Обладают ли резервные копии целостностью? Сможете ли вы восстановить базу по состоянию на определенный момент времени? Если ваши данные
окажутся повреждены, узнаете ли вы об этом? Каким образом? Приготовьтесь
гораздо глубже изучить эти вопросы, когда дойдете до главы, посвященной резервному копированию и восстановлению данных.
Одновременно следует позаботиться о масштабировании. Преждевременное масштабирование — это глупо, но вам необходимо подумать о сегментировании, росте

Иерархия потребностей  29

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

ПАТТЕРНЫ МАСШТАБИРОВАНИЯ
Мы будем довольно часто говорить о масштабировании. Масштабируемость —
это способность системы или сервиса справляться с растущими объемами работы.
Это может быть реальная способность, когда то, что было развернуто, поддерживает
возможность роста, или же потенциальная способность в виде доступных строительных блоков, позволяющих добавлять компоненты и ресурсы, необходимые для
масштабирования. В общем, принято выделять четыре основных пути масштабирования.
• Масштабирование по вертикали посредством распределения ресурсов, иначе называемое вертикальным масштабированием.
• Масштабирование по горизонтали путем добавления систем или сервисов, иначе
называемое горизонтальным масштабированием.
• Разделение рабочей нагрузки на более мелкие функции, чтобы масштабировать
каждую из них по отдельности, также называемое декомпозицией функций.
• Деление некоторой рабочей нагрузки на несколько «разделов», которые одинаковы, не считая различных наборов обрабатываемых данных, также называемое
сегментированием.
Более подробно эти паттерны будут рассмотрены в главе 5.

Любовь и принадлежность
Любовь и принадлежность — это превращение данных в главный объект процессов
разработки программного обеспечения. Речь идет о разрушении границ между
базами данных и остальными системами. Границы носят как технический, так
и культурный характер, поэтому все это можно назвать просто потребностью интеграции разработки и эксплуатации. На верхнем уровне это означает, что управление
базами данных должно выглядеть и быть (насколько это возможно) таким же, как
и управление остальными системами. Это также означает, что вы поощряете культуру плавных переходов и кросс-функциональности. На этапе обеспечения любви
и принадлежности вы постепенно прекращаете заходить в эту систему и выполнять
там обязанности пастуха от имени пользователя root.
Именно в этот момент вы начинаете использовать те же практики проверки и развертывания кода, что и в остальном программном обеспечении. Построение инфраструктуры базы данных и подготовка ее к работе должны быть частью процесса,
реализуемого и для всех остальных архитектурных компонентов. Работа с данными должна соответствовать всем остальным частям приложения, чтобы каждый

30  Глава 1



Введение в обеспечение надежности базы данных

сотрудник компании чувствовал, что он может взаимодействовать со средой базы
данных и поддерживать ее.
Не поддавайтесь желанию заставить своих разработчиков бояться вас. Это довольно
легко сделать и довольно заманчиво, ведь вы наверняка считаете, что будете чувствовать себя увереннее, если станете все контролировать. Но это не так. Всем будет
гораздо лучше, если вы направите эту энергию на построение ограничителей, чтобы
было максимально сложно случайно уничтожить данные. Обучайте людей, дайте
каждому возможность отвечать за изменения, которые он вносит. Даже не упоминайте о предотвращении сбоев — это невозможно. Другими словами, создавайте отказоустойчивые системы и поощряйте всех максимально работать с хранилищем данных.
ОГРАНИЧЕНИЯ В ETSY
Компания Etsy представила инструмент Schemanator для безопасного внесения в БД
изменений, иначе называемых наборами изменений, в свои производственные среды.
Был установлен ряд ограничений и проверок, чтобы применять эти изменения могли
сами разработчики программного обеспечения.
• В определение схем включен эвристический анализ наборов изменений для проверки соответствия стандартам.
• Выполняется тестирование наборов изменений для проверки успешности выполнения сценариев.
• Проводится предстартовая проверка, чтобы показать инженеру текущее состояние
кластера.
• Развертывание изменений выполняется так, чтобы серьезным воздействиям подвергались только неактивные базы.
• Процесс установки разбивается на подзадачи так, чтобы можно было их отменить
в случае возникновения непредсказуемых проблем.
Подробнее об этом читайте в блоге Etsy (http://bit.ly/2zy74uz).

Уважение
Уважение — одна из высочайших потребностей в пирамиде. Для людей это озна­
чает признание со стороны других, а для БД — пригодность для наблюдения и отладки, способность самодиагностики и наличие соответствующего инструментария.
Речь идет о возможности понять ваши системы хранения данных, а также сопоставлять события в стеке. На данном этапе есть два аспекта: один касается того,
как на текущий момент развиваются ваши производственные сервисы, а другой —
влияния человеческого фактора.
Сервисы должны сообщать вам о том, что они включились/отключились или в их
работе возникли ошибки. Вы не должны смотреть на графики, чтобы узнать об

Иерархия потребностей  31

этом. По мере развития сервисов темп внесения изменений несколько замедляется
и траектория становится более предсказуемой. Работая в реальной производственной среде (среде промышленной эксплуатации), вы каждый день будете все больше
узнавать о слабых сторонах системы хранения, об особенностях ее поведения и условиях отказа. Для инфраструктуры данных это время подобно подростковому перио­
ду: больше всего сейчас нужно видение происходящего. Чем сложнее продукт, тем
больше у него «шестеренок» и тем больше циклов проектирования нужно выделить
для разработки инструментов, необходимых для выяснения того, что происходит.
Вам также нужны средства настройки. Нужна возможность снижать качество обслуживания выборочно, а не полностью, например:
‰‰флаги, с помощью которых можно перевести сайт в режим «только для чтения»;
‰‰отключение отдельных функций;
‰‰постановка операций записи в очередь с отложенным применением;
‰‰возможность занести в черный список отдельные «плохие» акторы или клиент-

ские рабочие места.

Потребности работников компании похожи, но не полностью совпадают. Как правило, вскоре после ввода системы в эксплуатацию команды начинают реагировать
слишком активно. Им не будет хватать общего видения ситуации, и они будут
это компенсировать, отслеживая все и вся и слишком часто оповещая друг друга
о разных событиях. Легко перейти от полного отсутствия графиков к буквально
сотням тысяч графиков, 99 % которых совершенно бесполезны. Это не лучший,
а, возможно, даже худший вариант. Если система генерирует так много шума, что
ваши люди не способны найти верный сигнал и вынуждены постоянно отслеживать
файлы журналов и пытаться угадать, что случилось, то это ничуть не лучше или
даже хуже, чем полное отсутствие графиков.
Именно в этот момент можно довести людей до выгорания, постоянно прерывая
их и приучая не обращать внимания и не реагировать на поступающие предупре­
ждения. Если вы хотите, чтобы все работали по запросу, вам нужно еще на ранних
стадиях написать документацию. При запуске системы и активации вызовов вы
выталкиваете людей за пределы их зоны комфорта — помогите им. Напишите минимальную эффективную документацию и перечислите необходимые процедуры.

Самоактуализация
Как уникальны лучшие черты личности каждого человека, так же уникален и уровень самоактуализации хранилища данных в каждой организации. Идеал системы
хранения данных для Facebook не похож на идеальную систему для Pinterest или
GitHub, не говоря уже о крошечном стартапе. Но точно так же, как существуют
модели поведения для здоровых самореализованных людей (они не устраивают
истерики в продуктовом магазине, правильно питаются и занимаются спортом),

32  Глава 1



Введение в обеспечение надежности базы данных

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

Резюме
Переход от других, уже давно известных ролей к DBRE — это смена парадигмы
и в первую очередь новый подход к функциям управления хранилищами данных
в постоянно меняющемся мире. В следующей главе мы начнем подробно изучать
эти функции, отдавая приоритет задачам обслуживания в силу их важности
в повседневной разработке БД. А теперь смело иди вперед, отважный инженер!

2

Управление уровнем
качества обслуживания

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

Зачем нужны целевые показатели качества
обслуживания
Сервисы, которые мы проектируем и создаем, должны удовлетворять набору требований к характеристикам в процессе функционирования. Это часто называют
соглашением о гарантированном уровне качества обслуживания (Service-Level
Agreement, SLA). Однако SLA — это нечто большее, чем просто перечень требований. SLA включают в себя средства возмещения ущерба, способы воздействия
и многое другое, что выходит за рамки этой книги. Итак, мы сосредоточимся на
понятии «целевой уровень качества обслуживания», или «целевой показатель качества обслуживания» (Service-Level Objective, SLO). SLO — это обязательства
архитекторов и операторов, которые определяют структуру и функционирование
системы для выполнения этих обязательств.
Управлять качеством обслуживания сложно! Сократив эту тему до одной главы,
мы многое упростили, но важно понимать нюансы. Приведем несколько примеров,
чтобы проиллюстрировать, почему эта проблема так сложна.
‰‰Вам может показаться, что достаточно сообщить о проценте запросов, кото-

рые были успешно обработаны разработанным вами API. Хорошо… но кто
должен это сообщать? Сам API? Очевидно, это проблема: что случится, если

34  Глава 2



Управление уровнем качества обслуживания

балансировщики нагрузки откажут? А что произойдет, если система вернет
ошибку 200 из базы данных, поскольку ваша система обнаружения сервисов
обнаружила недоступность конкретной базы?
‰‰Или, предположим, вы решите: «Хорошо, будем использовать стороннюю

систему сквозной проверки и подсчитаем, сколько запросов считывают и записывают корректные данные?» Сквозные проверки — отличная вещь, это
лучшее средство оповещения о проблемах надежности. Но проверяют ли они
всю серверную часть?

‰‰Включаете ли вы в свои SLO менее важные сервисы? Ваши клиенты, вероятно,

предпочли бы получить уровень доступности API 99,95 % и уровень доступности продукта пакетной обработки 97 вместо 99,8 % и для API, и для пакетной
обработки.

‰‰Насколько сильно вы контролируете клиентов? Если доступность вашего API

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

‰‰Возможно, вы скажете: «Я просто посчитаю процент ошибок». Но как быть

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

‰‰Может быть, вы получаете правильный результат в 99,999 % случаев, но в 15 %

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

‰‰Что делать, если сайт доступен на 99,999 % для 98 % пользователей, но только

на 30–70 % для остальных 2 % пользователей? Как это вычислить и оценить?

‰‰Что делать, если не работает или работает медленно только один фрагмент

или одна серверная часть? Что, если вследствие ошибки при обновлении были
потеряны 2 % данных? Что, если вы потеряли данные за целый день, но только
для определенных таблиц? Что, если из-за характера этих данных пользователи
никогда не замечали их потерю, но вы сообщили о потере 2 % данных, чем вызвали у всех тревогу и побудили их мигрировать с вашего ресурса? Что, если
эти 2 % потерянных данных фактически состояли из перезаписанных указателей на активы, так что, хотя на самом деле данные не были утеряны, их нельзя
было найти?

‰‰Что, если для некоторых пользователей доступность составляет 95 %, потому что

у них плохой Wi-Fi, старый кабельный Интернет или плохие таблицы маршрутизаторов между их клиентом и вашим сервером? Могут ли они привлечь вас
к ответственности?

Показатели уровня обслуживания  35
‰‰Что, если так происходит с целыми странами? Что ж, тогда, вероятно, за это

вас могут обвинить (например, перегрузку UDP-пакетами DNS у некоторых
провайдеров вы можете исправить).

‰‰Что, если ваш показатель равен 99,97 %, но каждая ошибка приводит к тому,

что весь сайт перестает загружаться? Что делать, если доступность составляет
99,92 %, но каждая страница содержит 1500 компонентов и пользователи почти
никогда не замечают невозможность загрузить крошечный виджет? Какой из
этих вариантов лучше?

‰‰Что лучше, подсчитывать частоту ошибок в данный момент или по временным

интервалам? Или число интервалов (минут или секунд), когда количество
ошибок или задержек превышало порог?
Пять девяток?

Многие используют число 9 для краткого описания доступности. Например, если система спроектирована с доступностью пять девяток, это означает, что она рассчитана
быть доступной 99,999 % времени, тогда как три девятки будут означать 99,9 %.

Вот почему практика проектирования, настройки и адаптации SLO и показателей
доступности с течением времени является проблемой не столько сферы вычислений, сколько социальных наук. Как рассчитать процент доступности, который
точно отражает опыт ваших пользователей, повышает доверие и правильно стимулирует их поведение?
С точки зрения вашей команды, какие бы показатели доступности вы ни сочли
важными для доставки пользователям, эти цифры будут всячески обыгрываться,
хотя бы подсознательно. Именно на эти цифры вы будете обращать внимание,
определяя, становится ли система более или менее надежной и не нужно ли переключить ресурсы с разработки функций на надежность или наоборот.
С точки зрения потребителей, самое важное в показателе — то, чтобы он максимально отражал их опыт. Если у вас есть возможность вычислять показатели для
каждого клиента или среза и разбивать данные на произвольные интервалы измерений — даже с большим количеством элементов, таких как UUID, — это невероятно
эффективно. Именно так сделано в Scuba для Facebook и в Honeycomb.io.

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

36  Глава 2



Управление уровнем качества обслуживания

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

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

Задержка или время отклика?
Тонны чернил и крови были пролиты в дебатах на тему «задержки» и «времени
отклика». Есть мнение, что задержка — это время, требующееся для получения
услуги, тогда как время отклика — это время, необходимое для выполнения запроса.
В этой книге мы используем понятие «задержка» для обозначения общего времени
прохождения запроса от его генерации до получения полезного результата.

Доступность
Обычно доступность выражается в процентах от общего времени, когда система
должна быть доступной. Доступность определяется как способность вернуть ожидаемый ответ запрашивающему клиенту. Обратите внимание: здесь не учитывается
время, поэтому большинство SLO включают в себя и время отклика, и доступность.
После определенной величины задержки систему можно считать недоступной,
даже если запрос все-таки выполняется. Доступность часто выражается в процентах, например 99,9 % для определенного временного окна, в течение которого
проводятся измерения. Для этого результаты всех замеров, сделанных в данном
окне, должны быть собраны в единый показатель.

Пропускная способность
Другим распространенным SLI является пропускная способность, или количество
успешных запросов за определенный период времени, обычно измеряемая в еди-

Показатели уровня обслуживания  37

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

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

Стоимость — эффективность
Показатель «стоимость — эффективность» часто игнорируется или не учитывается
при обсуждении уровня обслуживания. Вместо этого обнаруживается, что он отнесен к бюджету проекта и зачастую не отслеживается как следует. Так или иначе,
общая стоимость услуг для большинства предприятий является критическим
компонентом. В идеале это должно выражаться в стоимости действия, например
просмотра страницы, подписки или покупки.
Организация должна ожидать выполнения следующих действий в рамках операций своих сервисов.
‰‰Новый сервис. Цели SLO определены. В более традиционных моделях это можно

было бы назвать соглашениями на операционном уровне.

‰‰Новые SLO. Установка соответствующего мониторинга для оценки фактических

и желаемых показателей.

‰‰Существующий сервис. Необходимо запланировать регулярные проверки SLO

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

‰‰Выполнение SLO. Регулярные отчеты для указания исторического и текущего

состояния выполнения или нарушения SLO.

‰‰Проблемы с обслуживанием. Портфель проблем, которые повлияли на уровни

обслуживания и их текущее состояние с точки зрения обходных путей и исправлений.

38  Глава 2



Управление уровнем качества обслуживания

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

Показатели задержки
SLO задержки может быть выражен как диапазон значений соответствующего показателя. Например, мы могли бы сказать, что задержка до получения результата
запроса должна быть меньше 100 миллисекунд (что на самом деле обозначает
диапазон от 100 до 0 миллисекунд, если определять обе границы явно). Величина
задержки исключительно важна при взаимодействии с пользователем.

Почему так важна задержка
Медленно или неустойчиво работающие сервисы способны потерять больше клиентов, чем система, которая не работает вообще. Скорость действительно важна
настолько, что, по исследованиям Google Research, введение задержки от 100
до 400 миллисекунд приводит к сокращению поисковых запросов на 0,2–0,6 %
в течение 4–6 недель. Более подробную информацию вы найдете в Speed Matters
по адресу http://googleresearch.blogspot.com/2009/06/speed-matters.html. Вот еще
несколько впечатляющих цифр:
• Amazon: каждые дополнительные 100 миллисекунд задержки сокращают продажи на 1 %;
• Google: увеличение времени загрузки страницы на 500 миллисекунд приводит
к сокращению количества поисковых запросов на 25 %;
• Facebook: замедление загрузки страницы на 500 миллисекунд приводит
к уменьшению трафика на 3 %;
• задержка отклика на 1 секунду снижает удовлетворенность клиентов на 16 %.

SLO доступности можно описать так: задержка выполнения запроса не должна
превышать 100 миллисекунд.
Если оставить нижнюю границу равной 0, это может привести к определенным
проблемам. Специалист по производительности может потратить неделю на то,
чтобы уменьшить время отклика до 10 миллисекунд, но мобильные устройства,
применяющие приложение, обычно не будут иметь доступа к достаточно быстрой

Определение целей обслуживания  39

сети, способной воспользоваться такой оптимизацией. Другими словами, ваш
специалист потратит неделю работы впустую. Мы можем доработать формулировку SLO следующим образом: задержка выполнения запроса должна составлять
от 25 до 100 миллисекунд.
Теперь поговорим о том, как собирают эти данные. Если это делается путем анализа
журналов, то можно взять запросы за 1 минуту и усреднить их. Однако здесь есть
проблема. Большинство сетевых систем показывают распределение случайных
величин задержки с небольшим процентом существенных «отрывов». Это и искажает среднее значение, и маскирует характеристики полной рабочей нагрузки от
инженеров, наблюдающих за системой. Другими словами, агрегирование времени
отклика — это преобразование с потерями.
На самом деле нужно представлять задержку как распределение величин задержек.
Задержки почти никогда не распределены по закону Гаусса или Пуассона, поэтому
средние значения, медианы и среднеквадратичные отклонения в лучшем случае
бесполезны, а в худшем — ложны (http://bravenewgeek.com/everything-you-know-aboutlatency-is-wrong/).
Чтобы лучше понять сказанное, взгляните на рис. 2.1 и 2.2, предоставленные
Circonus — продуктом для мониторинга крупных систем. В блоге Circonus эти
графики используются для демонстрации размывания всплесков — именно это
явление мы обсуждаем. На рис. 2.1 мы построили график средних значений
с большим временным окном для каждого усреднения, чтобы собрать данные
за месяц.

Рис. 2.1. Средние значения задержки с большим окном усреднения

На рис. 2.2 выполняется усреднение по намного более узким временным окнам,
поскольку показаны данные только за 4 часа.
Несмотря на то что набор данных один и тот же, средние значения на рис. 2.1 показывают пик со значением примерно 9,3, а на рис. 2.2 — 14!

40  Глава 2



Управление уровнем качества обслуживания

Рис. 2.2. Средняя задержка с меньшим временным интервалом усреднения

Будьте внимательны, сохраняя средние значения!
Не забывайте сохранять фактические, а нетолько усредненные значения! Если у вас
есть приложение для мониторинга, которое усредняет значения каждую минуту
и не сохраняет реальную полную историю значений, то однажды вам обязательно
понадобится получить среднее значение за 5 минут, используя средние значения
за 1 минуту. Вы получите абсолютно неверные данные, потому что первоначальное усреднение было выполнено с потерями!

Если вы рассматриваете данные, полученные за 1 минуту, как полный набор данных, а не как среднее значение, то, возможно, захотите визуализировать влияние
выбросов (на самом деле вас могут интересовать именно выбросы). Это можно
сделать несколькими способами. Во-первых, можно визуализировать минимальное
и максимальное значения относительно среднего. Можно также отделить выбросы,
отфильтровав для усреднения задержки по определенному критерию, например
только наиболее быстрые 99,9, 99 и 95 % запросов. Если совместить эти три вычисленных значения с результатами усреднения по полной выборке (рис. 2.3) и найти
минимум/максимум, то получим очень хорошее представление о выбросах.
Теперь, продвигаясь дальше, подумаем о нашем SLO с учетом задержки. Если выполнять усреднение каждую минуту независимо от того, каков SLO, то мы не сможем доказать, что достигли цели, поскольку измеряем только средние значения!
Почему бы не сформулировать цель так, чтобы она больше соответствовала реальной рабочей нагрузке? Мы можем изменить SLO следующим образом: в результате измерений в течение 1 минуты задержка для 99 % запросов должна составлять
от 25 до 100 миллисекунд.

Определение целей обслуживания  41

Рис. 2.3. Среднее значение задержки (размер выборки — 100 %),
совмещенное с минимумом и максимумом

Почему же мы все-таки выбираем что-то вроде 99 % вместо 100 %? Распределения
величины задержки имеют тенденцию быть очень мультимодальными. Есть нормальные периоды, а есть крайние случаи, вызванные разнообразными случайностями, встречающимися в сложной распределенной системе, такими как сборка
мусора в Java Virtual Machine (JVM), очистка базы данных, очистка кэша и многое
другое. Таким образом, мы ожидаем определенного процента выбросов и наша цель
при формулировании SLO состоит в том, чтобы определить тот процент выбросов,
который мы готовы терпеть.
Теперь рассмотрим нагрузку. Мы говорим просто о единичном результате, который, например, получаем из вызова API? Или оцениваем визуализацию страницы,
которая представляет собой совокупность многих вызовов, выполняемых в течение
некоторого времени? Если измерять время визуализации страницы, то нам могут
понадобиться как два отдельных показателя время до получения первого отклика
и время до полного ее завершения, поскольку этот процесс может оказаться довольно длительным.

Показатели доступности
Как уже упоминалось, доступность — это доля времени, обычно выражаемая в процентах, в течение которого сервис может отвечать на запросы должным образом.
Например, мы можем потребовать, чтобы система была доступна 99,9 % времени.
Это может звучать так: сервис должен быть доступен 99,9 % времени.
Это дает нам около 526 минут простоя для работы в течение года. Почти 9 часов!
Это какой-то праздник простоя. Вы можете спросить, почему бы просто не потребовать 100 %? Если вы владелец продукта или продавец, то, вероятно, так и сделаете. Считается, что повышение требований с 99 до 99,9 и далее до 99,99 % каждый раз
на порядок увеличивает сложность управления, стоимость системы и трудоемкость

42  Глава 2



Управление уровнем качества обслуживания

ее сопровождения. Кроме того, если это приложение, взаимодействующее через
Интернет или географически удаленное, то можно ожидать, что транспортные
среды будут вносить собственные сбои, которые не дадут воспользоваться более
чем 99,0–99,9 % времени безотказной работы вашей системы.
Нужно также учесть, что разница между 526 отключениями на 1 минуту за год
и одним 526-минутным отключением очень велика. Чем короче время простоя,
тем вероятнее, что большинство пользователей даже не заметят сбоя. Напротив,
восьмичасовой перерыв в работе некоторых служб приводит к появлению новостных статей, тысяч твитов и подрывает доверие пользователей. Имеет смысл
рассматривать доступность вашего сервиса сразу в двух аспектах. Первый из
них — это среднее время между отказами (Mean Time Between Failures, MTBF).
Предотвращение сбоев всегда было приоритетом, то есть чем больше MTBF, тем
лучше. Второй аспект — это среднее время восстановления (Mean Time To Recover,
MTTR). Это время, необходимое для возобновления обслуживания после сбоя.
Чем оно меньше, тем лучше!

Доступность: безотказность или отказоустойчивость?
В последнее десятилетие было много дискуссий о построении устойчивых систем,
которые имеют три специфических свойства:
‰‰низкое MTTR вследствие автоматизированного восстановления для хорошо

контролируемых сценариев отказов;

‰‰ограниченное влияние сбоев благодаря распределенности и избыточности;
‰‰возможность рассматривать сбой как обычный сценарий в системе, для чего не-

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

Обратите внимание: здесь не делается акцент на устранении сбоев. Системы без
сбоев, несмотря на надежность, становятся нестабильными и непрочными. При возникновении сбоя в таких системах команды, которые должны реагировать на
инцидент, скорее всего, окажутся не готовы, и это может значительно усугубить
последствия. Кроме того, имея дело с надежной, но уязвимой системой, пользователи могут ожидать от нее большей надежности, чем та, которая указана в SLO и на
которую был рассчитан сервис. Это означает, что в случае сбоя, даже если условия
SLO не нарушаются, клиенты могут быть очень расстроены.
Вооружившись этими знаниями и оценивая доступность SLO, необходимо задать
себе несколько ключевых вопросов.
‰‰Есть ли обходные пути решения проблем во время простоя? Можете ли вы рабо-

тать в ограниченном режиме, например только чтения? Можно ли использовать
закэшированные ранее данные, пусть даже и устаревшие?

Определение целей обслуживания  43
‰‰Зависит ли допустимость простоя от того, какой процент пользователей он за-

трагивает?

‰‰Какие последствия для пользователей имеют простои разной длительности:

yy один неудачный запрос;
yy 30 секунд;
yy 1 минута;
yy 5 минут;
yy 1 час и больше?
После этого можно пересмотреть и заново оценить базовые SLO доступности,
определив:
‰‰временной интервал;
‰‰максимальную продолжительность инцидента;
‰‰процентную долю затронутых пользователей, по достижении которой система

считается недоступной.

С учетом этого можно определить SLO, например, следующим образом:
‰‰99,9 % доступности в среднем за неделю;
‰‰ни один инцидент не приводит к недоступности более чем на 10,08 минуты;
‰‰учитываются простои, затронувшие более 5 % пользователей.

Проектирование с учетом допустимого времени простоя
На этом новом уровне мы можем разрабатывать такие процессы, как обработка
и преодоление отказов, блокировка базы данных и перезапуск в соответствии с указанными параметрами. Мы можем выполнять непрерывные обновления, которые
затрагивают менее 1 % пользователей. И заблокировать таблицы для построения
индексов, если это занимает менее 10 минут и если на этой неделе еще не было
простоев. Планируя время простоев, а не пытаясь достичь их полного отсутствия,
мы можем более эффективно проектировать систему и допускать некоторые риски
ради обновления и ускорения.
Стоит отметить, что даже в современном мире, где 99,9 % безотказной работы
считается нормой, бывает, что сервисы действительно безболезненно переносят
простои, если те ожидаемы и управляемы. Хотелось бы также видеть допустимым
четырехчасовой простой, если о нем сообщено заранее, а последствия смягчены
ограничением функциональности до режима «только чтение» и распределением
их среди небольших групп пользователей, так как это позволяет избежать многочасовых тщательно спланированных миграций данных, связанных с риском повреждения данных, нарушения конфиденциальности и многого другого.

44  Глава 2



Управление уровнем качества обслуживания

С учетом всего этого вы, возможно, захотите переформулировать SLO доступности,
добавив ограничения на запланированное время простоя, чтобы руководить группой эксплуатации в ходе работы по обслуживанию.
Вот пример SLO доступности, версия 2:
‰‰система доступна в среднем 99,9 % времени в течение недели;
‰‰ни один инцидент не приводит к недоступности более чем на 10,08 минуты;
‰‰учитываются только простои, затронувшие более 5 % пользователей;
‰‰допускается один ежегодный четырехчасовой простой при условии, что:

yy об этом было сообщено пользователям как минимум за две недели;
yy он влияет не более чем на 10 % пользователей одновременно.

Показатели пропускной способности
Пропускная способность как показатель качества обслуживания отражает пиковую
величину нагрузки, которую сервис должен поддерживать, одновременно обеспечивая заданные SLO для задержки и доступности. Вы можете сказать: «Лейн,
Черити, почему мы должны это делать? Разве задержки и доступности не должно
быть достаточно?» На что одна из нас ответила бы: «Отличный вопрос, бравый
скаут!» А потом задумчиво затянулась бы трубкой…
В системе может присутствовать узкое место, «бутылочное горлышко», которое
задает верхнюю границу пропускной способности, не обязательно снижая производительность или доступность. Возможно, в вашей системе есть блокировка,
которая ограничивает вас 50 запросами в секунду (qps). Ответы на них могут быть
короткими и быстрыми, но если такого ответа ожидает 1000 человек, то это уже
проблема. Поскольку измерить сквозную задержку (полное время прохождения
запроса) не всегда возможно, показатели пропускной способности часто служат
дополнительным уровнем проверки работоспособности системы и ее соответствия
потребностям бизнеса.
Как и задержки, показатели пропускной способности подвержены проблемам
усреднения и недостаточной «разрешающей способности» выборки. Пожалуйста,
помните об этом при мониторинге.

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

Определение целей обслуживания  45

страницы, которые нужно доставлять. Если вы поставщик продукта типа «программное обеспечение как услуга» (Software as a Service, SaaS), то имеет смысл выбрать в качестве показателя количество подписок на вашу услугу. Для розничных
продавцов подойдет подсчет транзакций.

Что нужно учесть
Почему вам, инженеру БД, нужно все это знать? Вы управляете только одним
компонентом сервиса, так почему вы должны заботиться об общих требованиях?
В черные дни, когда работа системы нарушена, вашей задачей будет только ваше
хранилище данных и значение будет иметь только ваша способность его обслуживать. Но, будучи частью большой команды, вы получаете прекрасные возможности
влиять на скорость и доступность всего сервиса.
Зная все SLO, вы можете расставить приоритеты по своему усмотрению. Зная,
что SLO задержки составляет 200 миллисекунд, можно предположить, что в это
время включены:
‰‰разрешение адресов DNS;
‰‰балансировка нагрузки;
‰‰перенаправление на http-сервер;
‰‰прикладные функции приложения;
‰‰запросы к базе данных;
‰‰транспортировка данных TCP/IP через океаны и континенты;
‰‰чтение данных с твердотельных устройств (SSD) и жестких дисков.

Итак, если хранилища данных функционируют хорошо и их вклад в задержку
минимален, то следует сосредоточиться на чем-то другом. Если же вы видите, что
SLO в опасности, а сочный фрукт производительности висит достаточно низко,
можете потратить немного времени, чтобы сорвать его.
Собирая все SLO-показатели для вашего нового сервиса, являющегося объектом
внимания, необходимо учесть несколько дополнительных моментов.
‰‰Не переборщите. Мы накапливаем показатели и понимаем почему. Но, пожалуй-

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

‰‰Ориентируйтесь на пользователя. Подумайте, что ваши пользователи сочтут

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

46  Глава 2



Управление уровнем качества обслуживания

‰‰Определение SLO — итеративный процесс. Если у вас есть процесс проверки

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

Используйте SLO, чтобы определить, как вы хотите проектировать сервисы, процессы и инфраструктуру.

Мониторинг SLO и построение отчетов
Теперь, когда у вас есть четко определенные SLO, очень важно следить за тем, что
происходит в реальной жизни и как это соотносится с поставленными идеальными
целями. В этой книге мы еще не говорили об оперативном контроле, но есть некоторые
важные вещи, которые нужно обсудить, прежде чем перейти к следующей теме.
Главная цель мониторинга при управлении уровнем качества обслуживания —
упреждающее выявление и устранение любых потенциальных факторов, которые
могут привести к нарушению SLO. Другими словами, мониторинг нужен не для
того, чтобы узнавать о фактах нарушений в настоящее время. Это как сплав по реке
на каноэ: нам не нужно знать, что на реке есть пороги, если мы на них уже попали.
Мы хотим знать, что из происходящего может указывать на то, что пороги будут
ниже по течению, пока мы еще идем по спокойной воде. Кроме того, мы хотим иметь
возможность предпринять соответствующие действия, чтобы гарантировать, что мы
остаемся в пределах SLO, на которые настроены сами и настроили свои системы.
При мониторинге мы всегда будем полагаться на автоматический сбор и анализ
показателей. Затем результаты этого анализа будут передаваться в программное
обеспечение для автоматического принятия решений и исправления, оповещения
людей-операторов (другими словами, вас) или формулирования задач для дальнейшей работы. Кроме того, вы захотите визуализировать эти данные для анализа
в реальном времени людьми и, возможно, создать панель мониторинга для высокоуровневого отображения текущего состояния. Мы рассмотрим эти три сценария,
когда будем обсуждать отслеживаемые показатели.
Другими словами, предположим, у вас есть допустимые 10,08 минуты простоя
в течение недели и ко вторнику (то есть в течение трех дней) длительность простоев достигла 3 минут из-за событий Stop the World от сборщика мусора Cassandra
Garbage Collection плюс 1 минута после сбоя балансировщика нагрузки. Вы уже
использовали 40 % SLO, осталось еще четыре дня. Похоже, пора настроить сборку
мусора! Получив предупреждение после достижения определенного порогового
значения (30 %), система генерирует электронное письмо о создании нового задания1 для инженера по обеспечению надежности БД, и тот может немедленно
переключиться на решение проблемы.
1

В принятой терминологии ticket. — Примеч. науч. ред.

Мониторинг SLO и построение отчетов  47

Мониторинг доступности
Обратимся к показателю SLO доступности, который мы определили в предыдущем разделе. Как его отследить? Чтобы получить адекватную картину, потребуется мониторинг доступности системы, а также ошибок прикладного характера.
Напомним, что текущая «демонстрационная» версия SLO выглядит следующим
образом:
‰‰99,9 % доступности в среднем в течение недели;
‰‰длительность любого инцидента не превышает 10,08 минуты;
‰‰учитываются только простои, затронувшие более 5 % пользователей;
‰‰допускается один четырехчасовой простой в год, если:

yy пользователи оповещены по крайней мере за две недели до начала простоя;
yy простой влияет не более чем на 10 % пользователей одновременно.
Исторически сложилось так, что сотрудники отдела эксплуатации, как правило,
основное внимание уделяют относительно низкоуровневому мониторингу, который
информирует о доступности системы. Например, они могут следить, активен ли
и доступен ли конкретный хост, а также активны ли и доступны ли размещенные
на нем сервисы. В распределенной системе такой подход быстро становится неприемлемым, поскольку плохо сказывается на прогнозировании доступности
сервисов в целом. Если у нас 1000 виртуальных машин Java, 20 экземпляров базы
данных и 50 веб-серверов, как узнать, влияет ли каждый из этих компонентов на
всю систему и если влияет, то в какой степени?
Исходя из этого, первое, чем следует заняться, — частота ошибок выполнения
запросов пользователей. Это называется также мониторингом реальных пользователей (Real User Monitoring, RUM). Например, когда пользователь отправляет HTTP-запрос из браузера, получает ли он корректный ответ от сервиса?
Если сервис популярен, то таких данных может быть очень много. Например,
важное событие в глобальной службе новостей привлекает более 70 000 обращений к веб-сервису за секунду. Подсчитать частоту появления ошибок для такого
объема данных вполне по силам любому современному процессору. Все эти данные
передаются приложением (например, Apache HTTP-сервером) в демон протоколирования (например, в системный журнал Linux).
Дальнейшие пути извлечения полезных данных системой из этих журналов и передачи их в соответствующие инструменты мониторинга и анализа очень разно­
образны. Пока остановимся на этом и будем считать, что мы сохранили сведения
об успешной работе сервиса и ошибках в рабочем хранилище данных без какоголибо агрегирования или усреднения. Это уже обсуждалось в предыдущем разделе,
но стоит повторить: хранение одних только средних значений приводит к потере
ценной информации.

48  Глава 2



Управление уровнем качества обслуживания

При наличии сохраненных данных можно элементарно определить, превышен ли
однопроцентный порог неуспешных запросов, и если да, то пометить эту секунду
как время простоя. Регулярный подсчет времени простоя можно суммировать,
сравнивать с нашим лимитом 604,8 секунды за неделю и отображать результат на
панели мониторинга в браузерах, на мониторах в сетевом операционном центре,
в офисе или любом другом месте, чтобы все заинтересованные стороны видели,
как работает ваша команда.
В идеале мы хотим иметь возможность использовать эти данные, чтобы предсказать,
приведут ли текущие простои к превышению лимита этой недели. Самая большая
проблема для большинства систем — это изменение рабочей нагрузки в ходе разработки и модернизации продукта. В системе, для которой выпуски обновлений происходят еженедельно, а иногда и ежедневно, любые предыдущие выборки данных
становятся почти бесполезными. Это особенно верно для более старых выборок, по
сравнению со свежими данными, и называется затухающей функцией.
Подробное знакомство с прогнозирующим анализом данных выходит за рамки этой
книги. Но есть множество подходов, которые вы можете использовать уже сейчас,
чтобы предсказать, нарушите ли вы свой SLO на текущей неделе или, возможно,
в будущем. Для этого стоит взять данные за N предыдущих недель (в стабильных
системах N может быть больше, а в условиях непрерывного развертывания обновлений равняться 1) и посмотреть, сколько нарушений SLO произошло за те перио­
ды, для которых время простоя не превышало значение, полученное в текущем
периоде, или меньше его.
Например, скрипт вашего анализа получил текущее время простоя, которое составляет, допустим, 10 секунд за неделю, и длительность этой недели в секундах.
Мы получим 10 секунд простоя на 369 126 секунд в неделе.
Затем можно рассмотреть предыдущие 13 недель, и для каждой недели, когда
время простоя составляло 10 секунд или менее в один и тот же момент недели (от
1 до 369 126 секунд), оценить, произошло ли тогда нарушение SLO. Затем можно
присвоить вес на основе близости предыдущего периода. Например, из этих 13 недель последней неделе присваивается вес 13 баллов, предпоследней — 12 и т. д.
Суммируя веса за те недели, когда произошли нарушения SLO, вы можете подготовить высокоприоритетное задание для команды операционистов и уведомлять
их в чате, если совокупное значение достигнет или превысит 13. Это лишь один
пример того, как обеспечить определенный уровень мониторинга данных, если
у вас нет команды первоклассных аналитиков, у которой достаточно времени
и желания просматривать данные о качестве обслуживания. Здесь целью является
предварительное изучение потенциальной проблемы, прежде чем она возникнет
во время чрезвычайной ситуации, а это будет означать меньше забот и меньшее
снижение доступности.
В дополнение к мониторингу реальных пользователей полезно создать второй набор данных для искусственных тестов. Это называется синтетическим мониторин-

Мониторинг задержки  49

гом. То, что тесты являются искусственными, не означает, что они не идентичны
по активности реальному пользователю. Например, компания транзакционной
электронной почты может инициировать запросы электронной почты от учетных
записей QA, как это делал бы любой другой клиент.
Тестовые наборы и воздействия для синтетического мониторинга должны обеспечивать полное и всестороннее покрытие. Пользователи могут приходить из разных
регионов и быть активными в разное время. Это может привести к появлению
слепых зон, если не отслеживать все возможные регионы и пути выполнения кода
в нашем сервисе. С помощью синтетического мониторинга можно определить те
места, где доступность или задержка ухудшились или нестабильны, и принять
соответствующие меры для предотвращения или смягчения проблем. Примерами
таких мер могут быть добавление емкости хранилищ, запросы на настройку производительности и даже отвод трафика из нестабильной зоны.
С помощью синтетических тестов и RUM можно обнаружить снижение доступности системы и даже предсказать, когда может произойти нарушение SLO. Но это
не поможет, если речь идет о более серьезных воздействиях, вызванных сбоями
системы или нехваткой ресурсов. Одна из важнейших целей, преследуемых при
построении надежного мониторинга, — обеспечить сбор достаточного количества
данных для прогнозирования сбоев и перегрузок до их возникновения.

Мониторинг задержки
Мониторинг задержки очень похож на мониторинг ошибок запросов. Однако если
доступность выражается логическим значением («да» или «нет»), то задержка —
это значение времени, количественная величина, которую нужно измерить, чтобы
оценить, соответствует ли она указанным в SLO ограничениям.

SLO для задержки
Время ожидания для 99 % запросов в течение 1 минуты должно составлять
25–100 миллисекунд.

Как и в случае с телеметрией ошибок, мы предполагаем, что параметры HTTPзапросов были направлены в системный журнал и записаны в хранилище данных
как последовательность событий. Теперь мы можем взять временной интервал,
упорядочить все отсчеты по времени ожидания и исключить 1 % самых длительных запросов. Затем мы усредняем значения в каждом односекундном временном
окне. Если для какого-либо из оставшихся 99 % запросов ожидание превысило
100 миллисекунд, это означает нарушение SLO и это временное окно учитывается
как время простоя.

50  Глава 2



Управление уровнем качества обслуживания

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

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

Мониторинг стоимости и эффективности
Оценка выполнения SLO стоимости и эффективности может стать сложной задачей для мониторинга, потому что не все затраты можно легко описать количественно. Приходится учитывать суммарную стоимость за промежуток времени.
Если вы работаете в облачной среде, в которой выставляются счета за арендуемые
ресурсы, подобно счетам за коммунальные услуги, то можно достаточно легко
оценить расходы на хранилище данных, процессор для вычислений, память и пропускную способность между вычислительными узлами. Если же вы используете
собственные серверы, то вам нужно вычислить затраты на оборудование для всех
машин, выделенных для сервисов, с отдельной оценкой расходов в тех случаях,
когда задействуются общие ресурсы. Цена обычно рассчитывается для достаточно
длительного непрерывного отрезка времени, поэтому может оказаться сложно вычислить затраты за определенные периоды времени, например за час, имея только
ежемесячные отчеты от поставщика услуг.
Для ресурсов с фиксированной стоимостью, таких как вычислительные узлы
и хранилища, вы можете иметь матрицу затрат, полученную от поставщика услуг
или из собственных внутренних БД. На эти данные можно опираться для оценки
предполагаемых затрат при развертывании ресурсов и выведении их из эксплуатации. Для оценки затрат, зависящих от интенсивности использования, таких как
пропускная способность, IOPS и т. п., можно ссылаться на другие показатели, собранные в течение заданного временного интервала.
Вам также необходимо иметь в виду расходы на персонал, который обслуживает
данный сервис. Сюда могут входить инженеры по эксплуатации, базам данных

Резюме  51

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

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

3

Управление
рисками

Работа по сопровождению и эксплуатации — это набор обязательств1 и действия,
направленные на их выполнение. В главе 2 мы обсуждали, как создавать и формулировать эти обязательства, контролировать и документировать их выполнение.
Управление рисками — это то, что мы делаем для выявления, оценки и приоритизации факторов неопределенности, которые могут привести к нарушению наших
обязательств. Это также касается применения ресурсов (технологий, инструментов,
людей и процессов) для мониторинга и снижения вероятности возникновения неопределенностей.
Это не наука о достижении идеала! Цель здесь не в том, чтобы устранить все риски.
Это была бы безумная цель, которая лишь зря поглощала бы ресурсы. Цель состоит в том, чтобы внедрить оценку и снижение рисков во все наши процессы
и постепенно уменьшить воздействие рисков, используя различные методы их
предотвращения и смягчения. Данный процесс должен идти постоянно с учетом
наблюдений за инцидентами, внедрения новых архитектурных компонентов, увеличения или уменьшения эффекта по мере развития организации. Цикл процесса
можно разбить на семь категорий:
‰‰определить возможные опасности/угрозы, создающие операционный риск для

сервиса;

‰‰оценить каждый риск с учетом его вероятности и последствий;
‰‰классифицировать вероятность и последствия рисков;
‰‰определить средства управления для смягчения последствий или снижения

вероятности риска;

‰‰определить приоритетность рисков, с которыми нужно бороться в первую очередь;
‰‰внедрить средства управления и контролировать эффективность;
‰‰повторить процесс.
1

Выраженных в SLO. — Примеч. науч. ред.

Факторы риска  53

Повторяя этот процесс, вы практикуете кайдзен, то есть постоянно совершенствуетесь. И самое важное здесь — оценка рисков, где нужно развивать стратегию
постепенно.

Факторы риска
Качество процессов оценки рисков зависит от множества факторов. Их можно разбить на следующие категории:
‰‰неизвестные факторы и сложность;
‰‰наличие ресурсов;
‰‰человеческий фактор;
‰‰групповые факторы.

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

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

Amazon или Google;
‰‰влияние поставщиков, интегрированных в инфраструктуру;
‰‰обновление кода программистами;
‰‰движения на рынке, создающие всплески нагрузки на систему;
‰‰выше- и нижестоящие сервисы в иерархии;
‰‰патчи, изменения в репозитории и другие постепенно накапливающиеся из-

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

54  Глава 3



Управление рисками

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

Наличие ресурсов
Те из нас, кому приходилось работать в отделе, которому не выделяют достаточно
средств, или в бессистемном стартапе, знают, что получить ресурсы для длительных, работающих на перспективу задач, подобных рассматриваемой, бывает…
скажем так, непросто (слышали про сизифов труд?). Например, у вас может быть
4 часа или даже всего 30 минут в месяц на то, чтобы заняться процессами управления рисками. Поэтому ваша работа должна давать полезный результат — «приносить прибыль». Цена ваших времени и ресурсов, используемых для смягчения
рисков, должна быть меньше цены бездействия. Другими словами, в первую очередь уделяйте время самым вероятным рискам, а также тем, последствия которых
могут оказаться наиболее серьезными. Создавайте устойчивые системы и делайте
выводы из возникающих инцидентов.

Человеческий фактор
Стоит людям начать что-то делать, как возникает множество потенциальных проблем (http://bit.ly/2zyoBmm). Мы все великолепны, но в прилагающихся к нам инструкциях много написанного мелким шрифтом. Вот некоторые моменты, которые
могут испортить дело.
‰‰Синдром бездействия. Многие сотрудники эксплуатационных отделов обнару-

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

‰‰Игнорирование знакомых опасностей. Опытные инженеры часто игнорируют

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

‰‰Страх. Страх как фактор стресса может иметь как положительный, так и отрица-

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

Факторы риска  55

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

на риск — излишний и необоснованный оптимизм. Мы часто верим в лучшее
относительно себя и других членов наших команд и поэтому склонны рассматривать только идеальные ситуации (никто не утомлен, нас не отвлекают другие
инциденты, младшие сотрудники принимают участие в работе). Это касается
не только людей, но и происходящих событий. Приходилось ли вам думать:
«Три диска в один день из строя не выйдут», а потом получить некачественную
партию дисков, с которой именно это и случится?

Обсуждая риски, мы также должны учитывать такие факторы, как утомляемость
и отвлечение на выполняемые вручную восстановительные работы (так сказать,
аврал-пожар). Каждый раз, оценивая трудоемкость и риски, например, при внесении изменений вручную или при исследовании инцидента, мы должны учитывать,
что специалисты-эксплуатационщики, погружающиеся в новую сложную проблему, пришли к нам, возможно, после долгого трудового дня. Может быть, это
и не так, но это тоже нужно учитывать. При разработке средств управления для
уменьшения или устранения рисков также следует учитывать, что тот, кто будет
выполнять ручное восстановление, тоже может быть утомлен или, возможно, тушит
несколько пожаров одновременно.
Усталость от оповещений
Усталость от оповещений (http://bit.ly/2zyfqCv) — это ситуация, когда перегрузка
и усталость возникают из-за слишком большого количества ненужных сообщений.
Вы должны учитывать это, принимая решение о том, сколько предупреждений
(для реагирования и исправления вручную) встроено в процессы мониторинга.
Такая ситуация бывает вызвана ложными срабатываниями (оповещениями
о проблемах, которые на самом деле проблемами не являются, часто из-за плохо настроенных пороговых значений) или тем, что оповещения используются
вместо предупреждений о тенденциях, способных стать опасными в ближайшем
будущем.

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

тому, что группы, как правило, принимают более экстремальные решения, чем

56  Глава 3



Управление рисками

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

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

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

Что мы делаем
Реальность такова, что процесс управления рисками легко может стать чересчур
обременительным. Даже при наличии значительных ресурсов команды все равно
не смогут охватить все потенциальные риски, способные повлиять на доступность, производительность, стабильность и безопасность системы. Имеет смысл
строить процесс повторяющимся и совершенствующимся с течением времени.
Кроме того, предпочтение устойчивости в управлении рисками вместо стремления полностью их устранить позволяет разумно рисковать во имя инноваций
и улучшений.
Мы хотели бы подчеркнуть, что устранение всех рисков — плохая цель. У систем,
не испытывающих стрессовых воздействий, нет стимулов к улучшению и укреплению. В результате они оказываются нестойкими по отношению к неизвестным, не запланированным заранее факторам. Системы, регулярно испытывающие
стрессы и, следовательно, спроектированные с учетом обеспечения устойчивости,
способны успешнее справляться с неизвестными рисками.

Чего не надо делать  57

Есть основания считать, что для систем следует планировать бюджет времени простоя, как в Google, чтобы реализовать новые перспективные возможности, сохраняя
контроль над риском. В Google при бюджете простоя 30 минут за квартал, если это
время не было израсходовано, считают оправданным допустить повышение риска
ради обновления функций, улучшений и усовершенствований. Использовать бюджет простоя для внедрения инноваций, вместо того чтобы полностью уклоняться
от риска, — это превосходно.
Итак, как из этого можно сформировать реальный подход к оценке риска как процесса? Начнем с того, чего делать не надо!

Чего не надо делать
Итак, нам нужно многое принять во внимание! Вот несколько советов, которые
необходимо учесть при изучении процесса управления рисками — пока еще
не поздно:
‰‰не позволяйте субъективным предубеждениям повредить вашему процессу;
‰‰не допускайте, чтобы основным источником оценки риска были анекдоты и са-

рафанное радио;
‰‰не сосредотачивайтесь только на предыдущих инцидентах и проблемах — смо-

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

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

Рабочий процесс: запуск
Независимо от того, является ли сервис новым или наследником существующего,
процесс начинается с запуска. В ходе запуска процесса (рис. 3.1) цель состоит в том,

58  Глава 3



Управление рисками

чтобы распознать основные риски, которые могут поставить под угрозу SLO вашего
сервиса, или наиболее вероятные риски.

Рис. 3.1. Запуск процесса управления рисками

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

Чего не надо делать  59

Оценка риска для сервиса
Вооружившись списком поддерживаемых сервисов и микросервисов, вы должны
сесть за стол вместе с владельцами продукта и оценить допустимость рисков для
каждого из этих сервисов. Вам необходимо ответить на следующие вопросы.
‰‰Каковы SLO доступности и времени ожидания, определенные для данного

сервиса?

‰‰Что представляют собой время простоя или недопустимая задержка для этой

услуги, если:

yy затронуты все клиенты;
yy затронута часть клиентов;
yy сервис работает в режиме ограниченной функциональности (только чтение,
отключены некоторые функции и т. п.);
yy снижена производительность сервиса?
‰‰Какова цена простоя сервиса:

yy какова потеря дохода;
yy каково влияние на лояльность клиентов:
–– это бесплатный или платный сервис;
–– есть ли конкуренты, к которым клиент может легко перейти;
yy есть ли последствия простоя, способные подорвать работу всей компании:
–– потеря данных;
–– нарушение конфиденциальности;
–– простои во время праздника, иного особого события;
–– большая длительность простоя?
Рассмотрим пример. Компания UberPony специализируется на услуге предоставления клиентам пони по вызову, и ею предлагаются следующие шесть сервисов.
1. Регистрация нового клиента.
2. Прием и выполнение заказа на предоставление «пони по требованию».
3. Регистрация водителя пони.
4. Логистика для водителей пони.
5. Выплаты водителю пони.
6. Внутренняя аналитика.
Рассмотрим сервисы «Регистрация клиентов» (табл. 3.1) и «Заказ и выполнение
заказов» (табл. 3.2).

60  Глава 3



Управление рисками

Таблица 3.1. Регистрация клиентов UberPony

SLO доступности

99,90 %

SLO задержки

1 секунда

Количество новых клиентов в день

5000

SLO допустимых ошибок

5

Затраты на инфраструктуру в сутки

13 698 долларов

Затраты на инфраструктуру на 1 доллар дохода

0,003 доллара

Показатель ценности клиента

1000 долларов

Показатель ценности новых клиентов за день (суммарно)

5 000 000 долларов

Пиковое количество обращений клиентов в минуту

100

Отсев клиентов после ошибки

60 %

Пиковое значение потерь за минуту

60 000 долларов

1

Таблица 3.2. Заказ и выполнение заказов в UberPony

SLO доступности

99,90 %

SLO задержки

1 секунда

Количество текущих заказов в день

500 000

SLO допустимых ошибок

500

Затраты на инфраструктуру в сутки

30 000 долларов

Затраты на инфраструктуру в пересчете на 1 доллар дохода

0,006 доллара

Средний доход от одного заказа

10 долларов

Ежедневный доход

5 000 000 долларов

Пиковое количество заказов в минуту

1000

Отмены заказов после ошибки

25 %

Отсев клиентов после ошибки

1%

Пиковое значение потерь дохода за минуту

2500 долларов

Снижение суммарного показателя ценности клиентов
(перспективные потери от отсева клиентов) за минуту

10 000 долларов

Всего потерь за минуту

12 500 долларов

Таким образом, похоже, что проблемы в сервисе регистрации клиентов могут
обойтись нам в 4,8 раза дороже по сравнению с сервисом приема и выполнения
заказов. Получается, 75 % клиентов будут повторять попытку заказа после ошиб1

Англ. customer lifetime value — ожидаемая прибыль от одного клиента в течение всего
жизненного цикла. — Примеч. науч. ред.

Чего не надо делать  61

ки, но только 40 % вернутся, если не смогут зарегистрироваться. Видимо, вместо
этого они с радостью уйдут на UberDonkey. Обратите внимание: мы попытались
учесть такие переменные, как потеря клиента после ошибки заказа и количество
повторных попыток клиентов зарегистрироваться или сделать заказ после ошибки. Это будет непросто без хорошей бизнес-аналитики, но при недостатке данных
можно довольствоваться хотя бы приближенными оценками. Во всяком случае,
это лучше, чем ничего!
Со временем данные будут изменяться и дополняться, поэтому обязательно вовремя обновляйте показатели. Например, если UberDonkey станет более конкурентоспособным и UberPony начнет терять 5 % клиентов из-за ошибки в заказе,
то наши потери за минуту простоя сервиса приема и выполнения заказов внезапно
вырастут до 52 500 долларов, что значительно повысит его приоритет. Тогда нам
будет важнее переключить внимание на этот сервис.

Ревизия архитектуры
Теперь, определив сферу деятельности, проведем ревизию систем и сред, входящих
в сферу нашей ответственность:
‰‰центры обработки данных (ЦОД);
‰‰архитектурные компоненты/уровни (СУБД MySQL, балансировщики нагрузки

Nginx, экземпляры приложений J2EE, сеть, брандмауэр, Hadoop/HDFS, сеть
доставки контента (CDN));

‰‰распределение ролей внутри этого компонента (Writer/Primary, Replica);
‰‰пути и порядок взаимодействия между сервисами (запросы из приложения

в MySQL, из балансировщика нагрузки в приложение, публикация приложения
в Redis);

‰‰задания (извлечение, преобразование и загрузка (ETL), загрузка CDN, обнов-

ление кэша, управление конфигурацией, оркестрация (общая координация),
резервное копирование и восстановление, агрегация журналов).

В табл. 3.3 представлен упрощенный перечень первоочередных сервисов.
Таблица 3.3. Регистрация клиентов UberPony
Компонент

ЦОД 1

ЦОД 2

Фронтальные балансировщики нагрузки

2

2

Веб-серверы

20

20

Балансировщики нагрузки Java

2

2

Java-серверы

10

10

Продолжение 

62  Глава 3



Управление рисками

Таблица 3.3 (продолжение)
Компонент

ЦОД 1

ЦОД 2

Прокси базы данных

2

2

CloudFront CDN

Сервис

Сервис

Кэш-серверы Redis

4

4

Серверы записи кластера MySQL

1

0

Серверы чтения кластера MySQL

2

2

Репликация MySQL

Сервис

Сервис

Обновление CDN

Задание

Задание

Обновление кэша Redis

Задание

Задание

Резервные копии MySQL

Задание

Не определено

Процесс ETL

Задание

Не определено

Хранилище данных RedShift

Сервис

Не определено

Наш следующий шаг — оценить риски в этой архитектуре, которые могут повлиять
на работу сервиса.

Расстановка приоритетов
Как выявить риски, способные привести к нарушению целей SLO, и расставить их
приоритеты? В области управления рисками используется определение риска как
произведение вероятности1 возникновения фактора, приводящего к неблагоприятному исходу, и величины последствий этого исхода.
Пример спектра возможных оценок приведен в табл. 3.4.
Таблица 3.4. Спектр оценки
Вероятность/
последствия

1

Тяжелые

Значительные Умеренные Незначительные

Ничтожно
малые

Почти наверняка Неприемлемый Неприемлемый Высокий

Средний

Приемлемый

Очень вероятно

Неприемлемый Высокий

Высокий

Средний

Приемлемый

Возможно

Неприемлемый Высокий

Средний

Средний

Приемлемый

Маловероятно

Высокий

Средний

Средний

Приемлемый Приемлемый

Редко

Высокий

Средний

Приемлемый Приемлемый Приемлемый

В оригинале здесь likelihood; ниже имеется замечание о сложности толкования понятий
likelihood и probability. — Примеч. науч. ред.

Чего не надо делать  63

Для устранения двусмысленности важно определить возможные значения для
вероятности и цены исхода. Цена может различаться в зависимости от конкретной
предметной области и задачи. Что касается неоднозначности понятий вероятности, ожидаемой вероятности, частоты, то мы предлагаем вам изучить публикацию
Describing probability: The limitations of natural language («Описание вероятности:
ограничения естественного языка», http://www.risk-doctor.com/pdf-files/emeamay05.pdf).
Разделим все вероятности следующим образом (табл. 3.5).
Таблица 3.5. Вероятности
Качественная оценка

Количественная оценка, %

Почти наверняка

> 50

Очень вероятно

26–50

Возможно

11–25

Маловероятно

5–10

Редко

N, у вас есть эффективный кворум, чтобы
гарантировать хотя бы одну корректную операцию чтения после записи.
В нашем примере с тремя узлами это означает, что требуется как минимум два узла
чтения и два узла записи, учитывая, что (2 + 2) > 3. Если потерять два узла, то
останется всего 1 + 1, что равно 2. Это меньше 3, и, таким образом, у вас нет кворума и кластер не должен возвращать данные чтения. Если при чтении двух узлов
приложение получит два разных результата (либо на одном узле данные отсутствуют, либо данные двух узлов расходятся), то будет выполнено восстановление
с использованием выбранных методов разрешения конфликтов. Это называется
разрешением конфликтов при чтении.
Это далеко не все, что вам следует изучить для понимания кворумов и всей теории
и практики распределенных систем. Рекомендуем ознакомиться со следующими
статьями:
‰‰The Load, Capacity and Availability of Quorum Systems (http://bit.ly/2xjZNRZ);
‰‰Quorum Systems: With Applications to Storage and Consensus.

Нестрогие кворумы. Однажды наступит время, когда у вас будут работающие узлы,
но в них не окажется данных, необходимых для получения кворума. Предположим,
что узлы N1, N2 и N3 настроены на запись, причем N2 и N3 отключены, но доступны N1, N4 и N5. На данном этапе система должна перестать разрешать запись этих
данных, пока один узел не будет введен в кластер и не восстановится кворум. Однако если вам важнее продолжить получать записи, то можно допустить нестрогий
кворум для записи. Это означает, что другой узел может начать получать записи.
Как только N2 или N3 возвратятся в кластер, данные могут быть переданы им обратно в процессе направленной отправки (hinted hand-off).
Кворумы — это компромисс между согласованностью и доступностью. Очень важно понимать, как в хранилище данных на самом деле реализованы кворумы.
Вы должны понимать, когда допускается нечеткий кворум и какие кворумы могут
привести к строгой согласованности. Информация из разных источников иногда
вводит в заблуждение, поэтому тестирование реализаций должно стать частью
вашей работы.
Антиэнтропия. Еще одним инструментом для поддержания итоговой согласованности является антиэнтропия. Хранилище данных на основе Dynamo способно
достаточно эффективно поддерживать согласованность в период между восстановлением чтения и направленной отправкой. Но если данные считываются
не очень часто, то несоответствия могут сохраняться достаточно долго. В будущем
это может подвергнуть приложение риску получить устаревшие данные в случае
аварийного переключения. Таким образом, должен существовать метод синхронизации данных в дополнение к обычному механизму. Этот процесс называется
антиэнтропией.

Резюме  253

Примером антиэнтропии является дерево Меркла, которое реализовано в Riak,
Cassandra и Voldemort. Это сбалансированное дерево хешей объектов. Создавая
иерархические деревья, фоновый процесс антиэнтропии может быстро выявить
различие значений между узлами и восстанавливать их. Эти хеш-деревья изменяются при записи и регулярно очищаются и восстанавливаются, чтобы можно было
свести к минимуму риск пропуска противоречивых данных.
Антиэнтропия критически важна для хранилищ данных, в которых содержится
много редко используемых данных. Это хорошее дополнение к направленной
отправке и восстановлению чтения. Убедившись, что для хранилищ данных активирована антиэнтропия, вы обеспечите максимально возможную согласованность
в распределенном хранилище данных.
В деталях реализации этих систем есть существенные различия, однако рекомендации в общем сводятся к обсуждавшемуся ранее. Если предполагать, что ваше
приложение способно справляться с неупорядоченными записями и устаревшими
операциями чтения, система репликации без ведущего узла может обеспечить отличную отказоустойчивость и масштабируемость.
Изучив три наиболее распространенных подхода к реплицируемым хранилищам
данных, вы и ваши коллеги должны получить общее представление о методах распределения данных между несколькими системами. Это позволяет проектировать
системы, которые отвечают потребностям вашей организации в доступности, масштабе, производительности и локальности данных.

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

11

Справочник по видам
хранилищ данных

С технической точки зрения хранилище данных — это именно то, что следует
из названия: хранилище данных, связанное с ним программное обеспечение
и структура, позволяющая хранить, изменять данные и получать к ним доступ.
Но здесь мы будем говорить о хранилищах данных, которые используются в современных организациях для достижения их целей в тех случаях, когда очень
большое количество пользователей получает доступ к очень большим объемам
данных в условиях конкурентности.
Обычно читатели пользуются справочниками по видам различных представителей флоры, фауны и других природных объектов, чтобы их идентифицировать. Наша цель в этой главе — помочь вам понять характеристики различных
хранилищ данных. Мы надеемся, что, вооружившись этой информацией, вы
сможете ближе познакомиться с разными видами хранилищ данных, лучше
понимая различные варианты их использования, а также нюансы их обслуживания.
В этой главе мы начнем с определения характеристик и категорий хранилища
данных, имеющих большое значение для разработчиков приложений, которые
записывают и используют данные. Затем мы подробнее рассмотрим категории,
которые больше заинтересуют архитекторов и операторов хранилищ данных.
Мы считаем, что любой, кто занимается разработкой, проектированием или
эксплуатацией хранилищ данных, должен знать обо всех особенностях конкретного хранилища данных. Однако мы не ставили себе задачу дать вам исчерпывающее описание, поскольку наверняка найдется хранилище данных,
которое где-нибудь используется, но которого не окажется в этом описании.
Вместо этого мы приведем хорошую подборку хранилищ данных и перечислим
инструменты для дальнейшего изучения темы, в зависимости от ваших потребностей и задач.

Концептуальные особенности хранилища данных  255

Концептуальные особенности хранилища данных
Существует множество способов классификации хранилищ данных. Выбранные
вами методы классификации будут зависеть от ваших задач и способов взаимодействия с хранилищем данных. Вы создаете функции в приложениях, которые запрашивают, хранят и изменяют данные? Вы запрашиваете и анализируете данные
для принятия решения? Вы проектируете системы, на которых будет работать
база данных? Вы управляете базой данных, настраиваете или контролируете ее?
Каждой роли соответствует свой вид базы и хранящихся в ней данных.
В мире ORM и бессерверных архитектур, предоставляющих API, наблюдается
тенденция к абстрагированию хранилищ данных от потребителей, которые их
используют. Мы с этим не согласны. Понимание каждой характеристики и соответствующего хранилища данных, которое вы (или кто-то еще) выбираете, имеет
решающее значение для продуктивной работы. Бесплатного сыра не бывает, и каждая привлекательная функция подразумевает достижение некоего компромисса.
Критически важно гарантировать, что команды, работающие с хранилищами данных, будут полностью осведомлены об этом.

Модель данных
Для большинства разработчиков программного обеспечения (SWE) модель данных является одной из самых важных категорий. То, как структурированы данные
и каким образом управляются отношения между ними, имеет решающее значение
для тех, кто создает приложения на основе этих данных. Это также существенно
влияет на управление изменениями и миграциями БД, поскольку разные модели
часто по-разному управляют такими изменениями.
В этом подразделе описаны четыре основных варианта моделей данных: реляционная, «ключ — значение», документная и навигационная, или графовая, модель.
У каждой из них своя сфера применения, свои ограничения и особенности. Реляционная модель до сих пор была самой популярной. Учитывая, что такие хранилища выпускались огромным количеством производителей очень долгое время, эту
модель можно считать наиболее понятным, стабильным и наименее рискованным
из доступных вариантов.

Реляционная модель
Реляционная модель существует с того момента, когда ее первоначально предложил
Э. Ф. Кодд (https://ru.wikipedia.org/wiki/Кодд,_Эдгар), опубликовавший свою статью
A Relational Model of Data for Large Shared Data Banks («Реляционная модель данных

256  Глава 11



Справочник по видам хранилищ данных

для больших совместно используемых банков данных») в 1970 году. Годом ранее
он описал эту модель в корпоративной документации IBM. Поскольку в книге мы
стремимся не столько дать вам полную информацию, сколько помочь понять системы, с которыми вы работаете сегодня, сосредоточимся на применении реляционных
систем в современных организациях.
Главный принцип моделей реляционных баз данных состоит в том, что данные
представляются в виде множества отношений, основанных на уникальных ключах, которые являются основными идентификаторами для фрагмента данных.
Реляционная модель подразумевает согласованность данных между таблицами
с ограничениями на отношения, количество элементов, значения и требованиями
к существующим или несуществующим определенным атрибутам. Реляционная
модель формализована и характеризуется различными уровнями строгости этой
формализации, также известными как нормальные формы. Реальность такова, что
многие из этих теоретических требований отодвигаются на второй план, когда в игру
вступают производительность и конкурентность1.
Хорошо известны такие реляционные базы данных, как Oracle, MySQL, PostgreSQL,
DB2, SQL Server и Sybase. Есть и специализированные альтернативы: Google
Spanner, Amazon RedShift, NuoDB и Firebird. Многие из этих альтернативных систем
классифицируются как NewSQL. Они считаются подклассом систем управления
реляционными базами данных, которые стремятся преодолеть некоторые барьеры
конкурентности и масштабирования, гарантируя при этом согласованность. Мы
подробнее обсудим их далее в главе.
Реляционная модель предлагает хорошо изученный подход к поиску данных.
Благодаря поддержке объединений (джойны, joins), отношений «один ко многим»
и «многие ко многим» разработчики получают высокий уровень гибкости в определении модели данных. Однако это же может привести к гораздо более сложным
подходам при эволюции схемы БД, поскольку добавление, изменение или удаление таблиц, связей и атрибутов может потребовать непростой синхронизации
и перемещения различных частей. Это чревато дорогостоящими и рискованными
изменениями, как было описано в главе 8.
Многие команды разработчиков программного обеспечения предпочитают использовать систему объектно-реляционного управления (Object Relational Management,
ORM), чтобы упростить работу, сопоставляя реляционную модель с объектной,
определенной на программном уровне. Такие ORM могут быть отличными инструментами для ускорения разработки, но их использование также приводит
к некоторым проблемам для команды DBR-инженеров.
1

Codd E. F. The relational model for database management: version 2 // ACM Digital Library.
http://dl.acm.org/citation.cfm?id=77708.

Концептуальные особенности хранилища данных  257

ОРМ И ВЫ
За последнее десятилетие ORM-системы стали совершеннее, и вам как DBREспециалисту больше не нужно с ними осторожничать, как раньше. Тем не менее остаются ошибки, которые необходимо учитывать.
• ORM привязывают операции чтения и записи к таблицам, что усложняет любое
количество оптимизаций части рабочей нагрузки, поскольку влияет на всю рабочую нагрузку.
• ORM могут задерживать выполнение транзакций намного дольше, чем следовало
бы, что сильно влияет на итоговый расход ресурсов из-за широкого использования моментальных снимков.
• ORM могут генерировать огромное количество ненужных запросов.
• ORM могут генерировать сложные и плохо работающие запросы.
Помимо этих очевидных сложностей, одна из самых больших проблем заключается
в том, что ORM абстрагирует базу данных, что исключает возможность совместной работы, необходимой для масштабирования, причем независимо от количества администраторов баз данных (DBA) в организации, которые работают с ORM.
ORM позволяет игнорировать ограничения и усложняет логику. Кроме того, DBRинженерам труднее понимать особенности взаимодействия приложения с хранилищами данных1.

Из-за этого многие разработчики и архитекторы программного обеспечения считают реляционные системы негибкими и не позволяющими повысить скорость
разработки. Однако это далеко не всегда так, и далее в главе мы приведем список
достоинств и недостатков таких систем и опровергнем некоторые мифы о них.1

Модель «ключ — значение»
Модель «ключ — значение» позволяет хранить данные в виде словаря или хеша.
Словарь аналогичен таблице и может содержать любое количество объектов.
В каждом объекте может храниться любое количество атрибутов или полей. Как
и в реляционной базе данных, эти записи однозначно идентифицируются по
ключу. В отличие от реляционных баз данных, здесь нет возможности создать
соответствия между объектами на основе этих ключей.
Хранилище данных типа «ключ — значение» видит объект как блок данных.
По сути, этот блок ничего не знает о данных, которые содержит, поэтому каждый
1

Ireland C. et. al. A Classification of Object-Relational Impedance Mismatch // IEEE Xplore.
http://bit.ly/2zymmQ3.

258  Глава 11



Справочник по видам хранилищ данных

объект может иметь разные поля, вложенные объекты и пр. Такое разнообразие
дорого обходится, в том числе подразумевая вероятность несогласованности, поскольку такие правила не применимы на уровне обычного общего хранилища.
Аналогично недоступны возможности хранилища в отношении типов данных
и индексации. С другой стороны, отсутствуют многие издержки, связанные с управлением различными типами данных, ограничениями и отношениями. Если для
приложения все это некритично, то можно использовать хранилище такого типа.
Хранилища «ключ — значение» бывают самыми разными. Одним из примеров таких хранилищ является Dynamo. В 2007 году издательство Amazon опубликовало
статью Dynamo, где были перечислены методы для создания высокодоступного
распределенного хранилища данных. Среди основанных на Dynamo систем —
Aerospike (http://bit.ly/2zy49Ch), Cassandra (http://bit.ly/2zyAucm), Riak (http://bit.ly/2zxKUsJ)
и Voldemort (http://stanford.io/2zxtrk3). К другим реализациям хранилищ типа «ключ —
значение» относятся Redis, Oracle NoSQL Database и Tokyo Cabinet.

Документная модель
С технической точки зрения документная модель основана на модели «ключ —
значение». Отличие документной модели состоит в том, что база данных содержит
метаданные о структуре документа. Это позволяет оптимизировать тип данных,
вторичную индексацию и пр. В документ-ориентированных хранилищах вся
информация об объекте содержится в одном месте, а не распределена между таблицами. Это позволяет извлекать все данные одним вызовом, без объединений,
которые, хотя и просты, могут потреблять значительное количество ресурсов.
Также обычно устраняется потребность в уровне ORM.
С другой стороны, это означает, что документ-ориентированные хранилища требуют денормализации, если существуют разные представления требуемого объекта.
Это может привести к излишнему увеличению размера базы и проблемам согласованности. Кроме того, для управления данными нужны сторонние инструменты,
поскольку схема БД больше не является самодокументирующейся системой1.

Управление данными
Управление данными — это управление доступностью, целостностью и безопасностью данных, которые сохраняет и использует организация. Перед введением
новых атрибутов данных их следует тщательно изучать и документировать.
Использование JSON для хранения данных позволяет слишком легко вводить
новые атрибуты.

1

Vera H. et. al. Data Modeling for NoSQL Document-Oriented Databases. http://ceur-ws.org/
Vol-1478/paper17.pdf.

Концептуальные особенности хранилища данных  259

Навигационная модель
Развитие навигационных моделей начиналось с иерархических и сетевых баз данных. Сегодня, говоря о навигационных моделях, мы почти всегда подразумеваем
графовую модель данных. В графовой базе данных для представления и хранения
данных и связей между объектами используются узлы, ребра и свойства. Узел
содержит данные об определенном объекте, ребро представляет собой отношение
объекта к другому объекту, а свойства позволяют указывать дополнительные
данные об узле. Поскольку отношения сохраняются непосредственно как часть
данных, можно легко переходить по ссылкам. Часто за один вызов можно получить весь граф.
Графовые хранилища, подобно документ-ориентированным, более точно соответствуют структуре объектно-ориентированных приложений. При их использовании
нет необходимости в объединениях, и они могут оказаться более гибкими с точки
зрения эволюции модели данных. Конечно, это актуально только для тех данных,
которые идеально подходят для запросов, соответствующих графу. Традиционные
запросы могут оказаться гораздо менее производительными1.
Каждая из этих моделей подойдет для конкретного вида приложений. Мы сведем
воедино различные варианты и опишем возможные компромиссы. Для начала рассмотрим поддержку транзакций и особенности реализации.

Транзакции
Способ, которым хранилище данных обрабатывает транзакции, также является
важной характеристикой. Транзакция — это фактически логическая единица работы базы данных, которую можно считать неделимой. Для обеспечения согласованности в хранилище данных все операции в транзакции должны либо выполняться,
либо откатываться.
Возможность верить, что все операции транзакции будут либо зафиксированы,
либо откатаны, значительно упрощает логику обработки ошибок в приложениях
на основе БД. Эти гарантии транзакционной модели позволяют разработчикам
не принимать во внимание определенные виды сбоев и конкурентность, которые
могут потребовать значительных ресурсов и циклов разработки.
Если прежде вы работали преимущественно с традиционными реляционными
хранилищами данных, то, вероятно, принимаете существование транзакций как
должное. Это объясняется тем, что почти все эти хранилища данных основаны на
представленной IBM в 1975 году модели ACID, которая будет описана далее. Все

1

Stonebraker M., Held G. Networks, Hierarchies and Relations in Data Base Management
Systems. http://bit.ly/2zxrbcq.

260  Глава 11



Справочник по видам хранилищ данных

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

ACID
Аббревиатура ACID описывает требования к БД: атомарность (Atomicity), согласованность (Consistency), изолированность (изоляция) (Isolation) и устойчивость
(Durability). Эту аббревиатуру ввели в 1983 году Андреас Рейтер (Andreas Reuter)
..
и Тео Хардер (Theo Harder) (https://en.wikipedia.org/wiki/ACID#cite_note-2), опираясь на
работу Джима Грея (Jim Gray) (https://en.wikipedia.org/wiki/Jim_Gray_(computer_scientist)),
который учел атомарность, согласованность и устойчивость, но не учел изолированность. Эти четыре свойства описывают основные требования к транзакционной
системе, которые повлияли на многие аспекты разработки в СУБД.
При работе с хранилищем данных крайне важно понять, как в нем определены
и реализованы эти концепции, потому что для различных хранилищ характерны
разные особенности. Зная об этом, нам следует разобрать каждое свойство в отдельности и рассмотреть варианты, которые встречаются на практике1.

Атомарность
Под атомарностью понимается гарантия того, что вся транзакция будет либо зафиксирована и записана в хранилище данных, либо откатана. В атомарной базе
данных невозможны такие действия, как частичная запись или откат. В этом контексте атомарность не относится к атомарным операциям, которые встречаются
при разработке программного обеспечения. Этот термин обозначает гарантию
изолированности от конкурентных процессов, наблюдающих за работой в процессе,
а не только до и после получения результатов.
Есть много причин, по которым транзакция может завершиться неудачно и потребовать отката. Например, клиентский процесс может прервать промежуточную
транзакцию или, возможно, может прерваться соединение из-за сбоя сети. Аналогичным образом, при сбоях базы данных, сбоях сервера и многих других операциях
может потребоваться откат частично завершенной транзакции.
В PostgreSQL это реализовано с помощью журнала pg_log. Транзакции записываются в pg_log, и им присваивается одно из состояний: «в процессе», «зафи­
ксирована» или «прервана». Если клиент отменит или откатит транзакцию, она
будет помечена как прерванная. Внутренние процессы также будут периодически
помечать транзакции как прерванные, если у них нет связанных внутренних процессов.
1

Vieira M. et al. Timely ACID Transactions in DBMS. http://bit.ly/2zyR2Rh.

Концептуальные особенности хранилища данных  261

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

Согласованность
Гарантия согласованности — это гарантия того, что любая транзакция переведет
базу данных из одного допустимого состояния в другое. При записи транзакции
предполагается, что она не может нарушить определенные правила. С технической
точки зрения согласованность определяется не на уровне базы данных, а на уровне
приложения. Однако традиционные БД предоставляют разработчикам инструменты для обеспечения такой согласованности. Эти инструменты характеризуются
наличием некоторых ограничений и триггеров. К ограничениям могут относиться
внешние ключи с каскадированием, ограничения на ненулевые значения, ограничения уникальности, ограничения типов и длины данных и даже ограничения на
определенные значения, разрешенные в конкретном поле.
Немного удручает, что согласованность повсеместно используется в базах данных
и программном обеспечении. В теореме CAP тоже используется термин «согласованность», но в другом значении. Этот же термин вы услышите при обсуждении
хеширования и репликации.

Изолированность
Гарантия изолированности — это обещание того, что одновременное выполнение транзакций приведет к тому же состоянию, которое возникло бы, если бы
эти транзакции выполнялись последовательно. В базах данных, отвечающих
ACID, это реализовано сочетанием методов, которые могут включать в себя блокировки записи, блокировки чтения и моментальные снимки. В совокупности
это называется конкурентным управлением. На практике существует несколько
типов конкурентного управления, которые могут привести к различным видам
поведения в базе данных. Более строгие версии могут значительно повлиять
на производительность конкурентных транзакций, в то время как более слабые
способны привести к повышению производительности за счет меньшей изолированности.
Стандарт ANSI/ISO SQL определяет четыре возможных уровня изоляции транз­
акции. Каждый уровень потенциально может обеспечить разные результаты для
одной и той же транзакции. Эти уровни определены с точки зрения трех возможных ситуаций, которые могут быть разрешены или запрещены.

262  Глава 11



Справочник по видам хранилищ данных

‰‰«Грязное» чтение. При «грязном» чтении есть вероятность прочитать незафи­

ксированные («грязные») данные, которые записываются в другой транзакции
от другого клиента.

‰‰Неповторяющееся чтение. При неповторяющемся чтении в контексте транзак-

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

‰‰Фантомное чтение. При фантомном чтении в контексте транзакции, если

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

Чтобы избежать этих явлений, можно использовать четыре возможных уровня
изоляции.
‰‰Чтение незафиксированных данных (Read Uncommitted). Это самый низкий

уровень изоляции. Здесь разрешены «грязное» чтение, «грязная» запись, неповторяющееся и фантомное чтение.

‰‰Чтение фиксированных данных (Read Committed). На этом уровне изоляции

цель состоит в том, чтобы избежать операций «грязного» чтения и «грязной»
записи. Другими словами, не должно быть возможности читать или перезаписывать незафиксированные данные. Некоторые базы данных избегают «грязной»
записи, блокируя запись для выбранных данных. Блокировки записи удерживаются до фиксации данных, а блокировка чтения снимается после выбора
данных. «Грязное» чтение обычно выполняется путем сохранения двух копий
данных, записываемых в транзакции: одной — из более старых зафиксированных данных, которые будут использоваться для чтения из других транзакций,
и второй — из данных, которые были записаны, но не зафиксированы.
Однако при изолированном режиме чтения зафиксированных данных по-преж­
нему можно выполнять неповторяющиеся операции чтения. Если незафи­
ксированные данные будут прочитаны один раз, а затем после фиксации прочитаны снова, то вы увидите разные значения в контексте вашей собственной
транзакции.

‰‰Повторяемое чтение (Repeatable Reads). Чтобы достичь уровня изоляции

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

Концептуальные особенности хранилища данных  263

привести к значительному падению производительности в высококонкурентных системах.
Другой способ добиться этого — использовать изоляцию моментальных снимков. При изоляции моментальных снимков после запуска транзакции клиент
увидит образ базы данных, актуальный на текущий момент. В этом моментальном снимке не будут отображаться дополнительные операции записи, что
позволит получить согласованные, повторяемые операции чтения при длительных запросах. Для изоляции моментального снимка используется блокировка
записи, но не блокировки чтения. Цель состоит в том, чтобы гарантировать, что
при чтении не блокируются источники записи, и наоборот. Поскольку для этого
требуется более двух копий, это называется управлением параллельным доступом с помощью многоверсионности (Multiversion Concurrency Control, MVCC).
При изоляции моментального снимка в случае повторяемого чтения все еще
возможны расхождения при записи. В этой ситуации можно разрешить две записи в один и тот же столбец или несколько столбцов, расположенных подряд,
из двух разных источников, которые прочитали обновляемые столбцы. Это
приводит к появлению строк, которые содержат данные из двух транзакций.
‰‰Упорядочиваемый уровень, или сериализуемость (Serializable). Это самый высо-

кий уровень изоляции, который предназначен для того, чтобы избежать всех
вышеупомянутых явлений. Как и при повторяемом чтении, если используются
блокировки для управления параллельным выполнением операций, то во время
транзакции сохраняются блокировки чтения и записи. Однако здесь есть ряд
дополнений, и стратегия блокировки называется двухфазной блокировкой
(2-phase locking, 2PL).
Двухфазная блокировка может быть общей или монопольной. Несколько читателей могут иметь общие блокировки чтения. Однако, чтобы можно было
получить монопольную блокировку записи, все общие блокировки чтения после
фиксации должны быть сняты. Точно так же, если происходит запись, общие
блокировки чтения не могут быть получены. В этом режиме в средах с высоким уровнем параллелизма транзакции могут часто простаивать в ожидании
блокировки. Это явление называется взаимоблокировкой (deadlock). Кроме того,
для запросов, использующих диапазоны в условиях WHERE, также должны
устанавливаться блокировки диапазона. В ином случае происходят операции
фантомного чтения.
2PL может существенно влиять на задержку транзакций. Когда много транзакций находятся в режиме ожидания, время отклика всей системы может значительно увеличиться. Таким образом, многие системы на практике не реализуют
сериализуемость и придерживаются повторяемого чтения.
Подход без блокировки основан на изоляции моментальных снимков и называется последовательной изоляцией моментальных снимков (Serial Snapshot
Isolation, SSI). Он представляет собой «оптимистичную» сериализацию, при

264  Глава 11



Справочник по видам хранилищ данных

которой база данных ожидает фиксации, чтобы выяснить, не произошли ли
какие-либо действия, приводящие к проблемам сериализации, чаще всего
это конфликт записи. Использование такого подхода позволяет значительно
уменьшить время отклика в системах, для которых нехарактерны нарушения
параллельного выполнения операций. Однако если такие нарушения наблюдаются регулярно, то постоянные откаты и повторные попытки могут значительно
влиять на время отклика.
Поскольку каждый уровень изоляции строже последующего в том смысле, что ни
один более высокий уровень не допускает действие, запрещенное на более низком
уровне, стандарт разрешает СУБД выполнять транзакцию на уровне изоляции,
более строгом, чем запрашиваемый. Таким образом, например, транзакция «чтение
фиксированных данных» может фактически выполняться на уровне изоляции повторяемого чтения.1

ИЗМЕНЧИВОСТЬ ПРИ ИЗОЛЯЦИИ
Как уже упоминалось, хранилища данных значительно различаются между собой по
реализации стандартов изоляции ANSI.
• PostgreSQL — имеет уровни чтения фиксированных данных, повторяемого чтения
и сериализуемости. Использует SSI для сериализации.
• Oracle — есть только возможность чтения зафиксированных данных и сериализуемости. Уровень сериализуемости ближе к повторяемому чтению, чем к действительному уровню сериализуемости.
• MySQL с InnoDB — имеет уровни чтения фиксированных данных, повторяемого
чтения и сериализуемости. Использует 2PL для сериализации, но не находит потерянные обновления1.

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

Устойчивость
Гарантия устойчивости подразумевает, что после того, как транзакция будет выполнена, она так и останется успешно завершенной. Транзакция остается устойчивой
независимо от того, случится ли сбой питания, сбой базы данных, аппаратный сбой
или возникнет любая другая проблема. Очевидно, при работе с БД мы не можем
1

Schwartz B. If Eventual Consistency Seems Hard, Wait Till You Try MVCC. http://bit.ly/­
2zyNy1m.

Концептуальные особенности хранилища данных  265

гарантировать, что используемое оборудование обеспечит такую устойчивость. Как
уже говорилось в главе 5, мы можем предполагать, что база данных синхронизирована с диском, хотя в реальности это далеко не всегда так.
Устойчивость тесно связана с атомарностью, поскольку без первой невозможно
обеспечить вторую. Во многих базах данных предусмотрен журнал упреждающей
записи (Write-Ahead Log, WAL), где фиксируются все записи до того, как они будут записаны на диск. Этот журнал используется для отмены или для повторного
применения транзакции. Если происходит сбой, то при перезапуске база данных
может сверить этот журнал с данными системы и определить, нужно ли отменить,
завершить или проигнорировать транзакцию.
Подобно уровням изоляции, бывают ситуации, когда устойчивость можно и нужно ослаблять, чтобы обеспечивать соответствие требованиям производительности. Для достижения абсолютной устойчивости сброс данных на диск должен
происходить при каждом завершении транзакции. Это весьма затратная процедура, которая не требуется для всех транзакций и записей. Например, в MySQL
можно настроить периодический сброс журнала Innodb, а не после завершения
каждой транзакции. Точно так же можно поступить с журналами репликации1.
Несмотря на то что мы ограничились довольно общим обзором, вам должно быть
понятно, как много деталей скрыто и воспринимается как должное в транзакционных системах. Будучи DBRE-специалистом, вы должны хорошо разбираться в реализациях. Зачастую детали этих реализаций не совсем понятны из документации,
и углубленные тесты с использованием таких инструментов, как Jepsen (https://
github.com/jepsen-io/jepsen) и Hermitage (https://github.com/ept/hermitage), помогут вам
в ваших исследованиях.
Надеемся, приведенной информации вам будет достаточно, чтобы выбрать подходящую конфигурацию и понять, когда стоит ослабить устойчивость или использовать более мягкую изоляцию. В то же время могут оказаться важными знания
о том, когда значения по умолчанию, предлагаемые базой данных, не соответствуют
потребностям ваших приложений.

BASE
Поскольку инженеры всегда искали альтернативы традиционным реляционным
системам, термин BASE начал использоваться как альтернатива для ACID. Аббревиатура BASE расшифровывается как Basically Available, Soft state and Eventual
consistency — «базовая доступность, неустойчивое состояние,согласованность
в конечном счете». Эта концепция описывает нетранзакционные системы, которые
1

Sears R., Brewer E. Segment-Based Recovery: Write-ahead loggin revisited. http://www.vldb.org/
pvldb/2/vldb09-583.pdf.

266  Глава 11



Справочник по видам хранилищ данных

являются распределенными и могут иметь довольно нестандартные возможности
репликации и синхронизации. В отличие от систем ACID, когда система активна
и принимает трафик, у систем BASE может не быть четкого состояния. Аналогично,
поскольку нет необходимости управлять параллельным выполнением операций для
транзакций, пропускная способность записи и параллельность в BASE-системах
могут быть значительно выше за счет атомарности, изоляции и согласованности1.
Рассмотрев модели данных и транзакционные модели, доступные для хранилищ
данных, мы изучили их особенности, наиболее важные для разработчиков. Однако
существует множество других характеристик, которые необходимо учитывать при
выборе не только базы данных, но и всей операционной экосистемы и инфраструктуры, на основе которой используются эти БД (табл. 11.1).
Таблица 11.1. Основные концептуальные характеристики хранилища данных
Характеристика MySQL

Cassandra

MongoDB

Neo4J

Модель данных

Реляционная

Ключ — значение Документная

Навигационная

Готовность
модели

Готова

2008

2007

2010

Отношения
между
объектами

Внешние ключи Нет

DBRefs

Ядро к модели

Атомарность

Поддерживается На уровне
разделения

На уровне
документа

На уровне
объекта

Согласованность Поддерживается Не
(в узле)
поддерживается

Не поддерживается Строгая
согласованность

Согласованность На основании
(в кластере)
репликации

Итоговая
(настраивается)

Итоговая

Изоляция

MVCC

Возможность
сериализации

Чтение
Чтение
незафиксированных зафиксированных
данных
данных

Устойчивость

Для DML, но
не для DDL

Поддерживается, Поддерживается,
настраивается
настраивается

Поддержка
XA-транзакций

Поддерживается,
WAL

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

Roe C. The Question of Database Transaction Processing: An ACID, Base, NoSQL Primer.
http://bit.ly/2zw5Obr.

Внутренние характеристики хранилища данных  267

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

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

Хранилище
Мы подробно рассмотрели хранилища в главе 10. Каждое хранилище предусматривает один или несколько возможных вариантов размещения данных на диске. Это
часто реализовано в форме систем хранения. Механизм хранения определяет чтение и запись данных, блокировку, параллельный доступ к данным и все остальные
процессы, необходимые для управления структурами данных, такими как индексы
B-дерева, журнально-структурированные деревья со слиянием (Log Structured
Merge, LSM) и фильтры Блума.
В некоторых базах данных, таких как MySQL и MongoDB, предлагается несколько вариантов механизмов хранения. Например, в MongoDB можно использовать
MMap, в MMap — WiredTiger либо структуры LSM или RocksDB, основанные на
деревьях LSM. Реализации механизмов хранения значительно различаются, но их
характеристики обычно можно разбить на следующие категории:
‰‰производительность операций записи;
‰‰производительность операций чтения;
‰‰устойчивость операций записи;
‰‰размер хранилища.

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

268  Глава 11



Справочник по видам хранилищ данных

сравнительный анализ и проверка достоверности утверждений об устойчивости
имеют первостепенное значение.

Вездесущая теорема CAP
При обсуждении этих характеристик часто ссылаются на теорему Эрика Брюера
(Eric Brewer), или теорему CAP (рис. 11.1). Она гласит, что в любой распределенной системе можно обеспечить не более двух из трех свойств или гарантий: согласованность (Consistency), доступность (Availability) или устойчивость к разделению
(Partition tolerance). Как и в случае с ACID, эти термины являются обобщенными.
Каждое из этих свойств на практике может иметь или не иметь место. Часто систему обозначают как CP или AP, что означает, что она обеспечивает только два
конкретных свойства из трех. Тем не менее если вы углубитесь в изучение таких
систем, то обнаружите, что реализации каждого конкретного свойства в них являются неполными, поскольку удается достичь лишь частичной доступности или
согласованности1.

Рис. 11.1. Визуализация теоремы CAP, или теоремы Брюера

Теорема CAP призвана помочь разработчикам понять компромисс между согласованностью или доступностью. Разделение сети в распределенных системах
неизбежно. Сети по своей сути ненадежны. В этом случае узлы с одной стороны
1

Kleppmann M. Please stop calling databases CP or AP. http://bit.ly/2zxUA6k.

Внутренние характеристики хранилища данных  269

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

Согласованность
Напомним, что мы обсуждали согласованность (буква C в аббревиатуре ACID)
в подразделе, посвященном транзакциям. Досадно, что согласованность в ACID отличается от согласованности в CAP. В ACID согласованность означает, что транз­
акция сохраняет все правила и ограничения базы данных. В CAP согласованность
означает линеаризуемость. Линеаризуемость гарантирует, что множество операций,
выполняемых над объектом в распределенной базе данных, будет происходить
в режиме реального времени. Поскольку операции могут быть прочитаны и записаны, это означает, что они должны появляться в той последовательности, в какой
выполняются остальными пользователями в системе. Линеаризуемость выступает
гарантией последовательной согласованности в реальном времени1.
Согласованность в ACID, как и согласованность в CAP, не может поддерживаться при разделении сети. Это означает, что транзакционные хранилища данных
на основе ACID в случае разделения сети могут гарантировать непротиворечивость, только жертвуя доступностью2. BASE-системы были разработаны,
помимо прочего, для того, чтобы справляться с разделениями сети без ущерба
для доступности.

Доступность
Доступность в теореме CAP относится к способности обрабатывать запросы. Обычно большинство распределенных систем могут обеспечивать согласованность и доступность. Но перед разделением сети, когда одно подмножество узлов отделяется
от другого, необходимо принять решение о том, как сохранить доступность за счет
согласованности. Конечно, ни одна система не способна поддерживать 100%-ную
доступность в течение длительного времени, и это соответствует тому, что мы говорили ранее о доступности как о непрерывном процессе.

Устойчивость к разделению
Разделение сети — это временный или постоянный разрыв соединения, который приводит к нарушению связи между двумя подмножествами сетевой инфраструктуры.
1

Bailis P. Linearizability versus Serializability. http://bit.ly/2v08Ymd.

2

Brewer E. CAP Twelve Years Later: How the ‘Rules’ Have Changed. http://bit.ly/2psQjuC.

270  Глава 11



Справочник по видам хранилищ данных

По сути, при этом часто создаются два кластера меньшего размера. Каждый из них
может считать себя единственным существующим кластером и допускать продолжение записи. Это приводит к появлению двух различающихся наборов данных и также
называется разделением ведущих узлов (split brain).
Теорема CAP была опубликована для того, чтобы помочь находить компромисс
между согласованностью и доступностью в распределенных хранилищах данных.
На практике разделения сети занимают небольшое количество времени в жизненном цикле хранилища данных. Согласованность и доступность могут и должны
предоставляться одновременно. Однако при разделении сети система должна
иметь возможность обнаруживать это разделение и управлять им, чтобы восстановить согласованность и доступность.
Следует отметить, что в теореме CAP никак не учитывается время отклика (задержка)
и производительность. Время отклика может быть столь же важным, как и доступность, а слишком большое время отклика тоже может быть потенциальной причиной
проблем согласованности. Достаточно длительное время отклика может превысить
допустимый предел, и это вынудит систему перейти в состояние отказа, связанное
с разделением сети. В отношении задержки существует компромисс, на который идут
гораздо чаще, чем для достижения согласованности и доступности. Фактически еще
одна важная причина, по которой возникли системы BASE и движение NoSQL, заключалась в требованиях к повышению производительности при масштабировании.
Теперь, когда мы ознакомились с теоремой CAP, обсудим, как это может повлиять
на нашу систематизацию баз данных. Можно было бы предпочесть концепцию CP
концепции AP, но мы уже обсуждали, насколько упрощен такой подход. Вместо
этого рассмотрим, как распределенные системы поддерживают согласованность
и доступность.

Компромисс между согласованностью и задержкой
Распределенная система считается строго согласованной, если все ее узлы видят все
транзакции в той же последовательности, в которой те были записаны. Другими словами, такая система линеаризуема. В теореме CAP отдельно обсуждается, как распределенное хранилище данных способствует согласованности или доступности в случае
разделения сети. Однако согласованность требуется на протяжении всего жизненного
цикла хранилища данных, и ее нельзя рассматривать только через парадигму CAP1.
Всем хотелось бы иметь строго согласованное распределенное хранилище данных,
но мало кто на самом деле согласится с последствиями, связанными с задержкой
и доступностью. Итак, компромиссы сделаны. В этом подразделе мы рассмотрим
1

Abadi D. Consistency Tradeoffs in Modern Distributed Database System Design. http://
bit.ly/2zxYLiH.

Внутренние характеристики хранилища данных  271

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

полняется асинхронно, полусинхронно или синхронно.

‰‰Отправлять записи на любой узел, который играет роль основного только для

этой транзакции. Репликация выполняется асинхронно, полусинхронно или
синхронно.

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

272  Глава 11



Справочник по видам хранилищ данных

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

Доступность
Кроме согласованности и ее связи с задержкой, у нас есть доступность. Бывает
доступность при разделении сети, как в теореме CAP. Но есть также ежедневная
доступность в условиях сбоев узла, многоузловой сети или всего кластера. Обсуждая доступность в распределенных системах, мы хотим поговорить не просто
о доступности, а об урожайности (yield) и урожае (harvest). Урожайность (http://
mauri­cio.github.io/pwl-harvest-yield/#/20) означает способность получить ответ на ваш
вопрос. Урожай описывает полноту набора данных. Вместо того чтобы просто задать вопрос о том, работает ли система, вы можете оценить, какой подход лучше
использовать при неудаче — уменьшить урожайность или урожай.
Первый вопрос, который нужно задать себе в отношении распределенной системы, — допустимо ли снижение урожая в пользу поддержания урожайности.
Например, допустимо ли доставлять 75 % данных в запросе, если пропускная
способность узла сократилась на 25 %? Если предоставлять большое количество
результатов поиска, это может быть приемлемым. Тогда это обеспечивает большую
устойчивость к сбоям, что может означать снижение коэффициентов репликации
в кольце Cassandra. Аналогично, если урожай должен быть близок к 100 %, нужно
распространять больше копий данных. Это означает не только большее количество
реплик, но и больше зон доступности, в которых должны существовать реплики.
Это также можно увидеть в декомпозиции приложений на подсистемы. Независимо от того, проявляется ли это в функциональном разделении или на уровне
микросервисов, в результате один отказ может быть изолирован от остальной
части системы. Такое разделение часто требует вмешательства программистов,
но это пример снижения урожая для поддержания урожайности.
Понимание механизмов хранения и того, как в хранилище данных реализуются
компромиссы согласованности, доступности и задержки, позволяет изучить

Резюме  273

хранилище данных «изнутри», что дополняет концептуальные особенности,
которые мы уже рассмотрели. Инженеры и архитекторы, отвечающие за производительность и функциональность приложения, больше всего заинтересованы в концептуальных характеристиках. Инженеры по эксплуатации и базам
данных часто стремятся к тому, чтобы внутренние характеристики (табл. 11.2)
соответствовали целевым показателям качества обслуживания (SLO), которые
диктуются бизнесом.
Таблица 11.2. Сводная таблица внутренних характеристик хранилища данных
Характеристика MySQL

Cassandra

MongoDB

Neo4J

Механизмы
хранения

Только LSM

Плагины,
В-деревья и LSM

Собственное
графовое
хранилище

Итоговая
согласованность,
вторичная после
доступности

Главный
приоритет —
согласованность

Главный
приоритет —
согласованность

Плагины,
в основном
В-деревья

Распределенная Главный
согласованность приоритет —
согласованность

Распределенная Вторичная, после Главный
доступность
согласованности приоритет —
доступность

Вторичная, после Вторичная,
согласованности после
согласованности

Задержка

Настраивается
в зависимости от
согласованности

Настраивается
в зависимости от
устойчивости

Оптимизируется
для операций
записи

Оптимизируется
для операций
чтения

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

12

Примеры
архитектур данных

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

Архитектурные компоненты
Каждый из этих компонентов входит в сферу повседневных обязанностей инженера по надежности баз данных (DBRE). Прошли те времена, когда мы могли
игнорировать компоненты, окружающие экосистему данных. Каждый из них
оказывает определенное влияние на общую доступность сервиса, целостность
и согласованность данных. Их невозможно игнорировать при разработке сервисов
и операционных процессов.

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

Архитектурные компоненты  275

имея некий уровень доступа к данным. Исторически многие приложения создавались так, как будто эти базы данных доступны всегда. Это означает, что каждый раз,
когда внешние хранилища данных не работают или настолько заняты, что работают слишком медленно и это влияет на уровень качества обслуживания клиентов,
приложения становятся непригодными для использования.
Традиционно эти системы назывались системами интерактивной транзакционной
обработки (OnLine Transactional Processing, OLTP). Для них было характерно
множество быстрых транзакций, поэтому они предназначались для очень быстрых
запросов, обеспечивали целостность данных при высокой степени параллелизма
и масштабирования в зависимости от количества транзакций, которые они могут
обрабатывать одновременно. Ожидается, что все данные будут обрабатываться
в реальном времени, со всеми необходимыми деталями для поддержки сервисов,
которые их используют. Каждый пользователь или транзакция ищет небольшое
подмножество данных. Это означает, что шаблоны запросов имеют тенденцию
фокусироваться на поиске и доступе к какому-то небольшому подмножеству из
большого множества данных. Для этого решающее значение имеют эффективное
индексирование, изоляция и параллельный доступ, поэтому такие задачи обычно
решаются с помощью реляционных систем.
Внешнее хранилище данных также характеризуется тем, что данные в него вносятся главным образом самими пользователями. Есть также хранилища, ориентированные на пользователя и в основном предназначенные для аналитики. В таких
хранилищах традиционно используется интерактивный анализ данных (OnLine
Analytics Processing, OLAP).
Мы уже обсуждали различные характеристики большинства таких хранилищ
данных: структуру хранения, модель данных, парадигмы ACID/BASE и компромиссы между доступностью, согласованностью и задержкой. Кроме того,
необходимо учитывать общую пригодность к эксплуатации и то, каким образом
хранилища интегрируются с остальной частью экосистемы. К основным характеристикам относятся следующие:
‰‰низкая задержка записи и запросов;
‰‰высокая доступность;
‰‰низкое среднее время восстановления (MTTR);
‰‰возможность масштабирования в зависимости от трафика приложения;
‰‰простая интеграция с приложением и эксплуатационными сервисами.

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

276  Глава 12



Примеры архитектур данных

Уровень доступа к данным
Приложение часто разбивается на уровень представления и уровень бизнеслогики. Уровень бизнес-логики — это то, что также называют уровнем доступа
к данным (Data Access Layer, DAL). Он обеспечивает упрощенный доступ к постоянным хранилищам данных, используемым для чтения и записи компонентов
приложения. Часто проявляется как набор объектов с атрибутами и методами,
которые ссылаются на хранимые процедуры или запросы. Такая абстракция
скрывает сложность хранилища данных от разработчиков программного обеспечения (SWE).
Примером DAL является использование DAO (Data Access Objects). DAO предоставляют интерфейсы доступа к базе данных, соответствующие обращениям приложений к базе данных. Не затрагивая слой хранения данных, разработчики могут
отдельно тестировать доступ к данным. Подобным образом можно подставить
заглушки вместо баз данных и протестировать приложение. Принято считать,
что при этом требуется гораздо больше кодирования в Java Database Connectivity
(JDBC) или в аналогичных интерфейсах. Тем не менее, будучи приближен к базе
данных, он позволяет писать эффективный код, когда требуется обеспечить производительность с помощью специальных методов. Другой нередко проявля­ющийся
недостаток заключается в том, что это требует от разработчика более глубокого
понимания схемы. Хотя мы думаем, что это скорее достоинство и чем лучше разработчики понимают схему, тем лучше для всех.
Еще одним примером DAL является объектно-реляционное отображение (ObjectRelational Mapper, ORM). Как мы уже рассказывали, ORM нам не нравится по
ряду причин. Однако у него есть некоторые преимущества, включая кэширование
и аудит. Очень важно понимать, что именно используют ваши команды программистов и какая гибкость или ограничения вводятся при кодировании и оптимизации
доступа к данным.

Прокси базы данных
Уровень прокси базы данных находится между серверами приложений и внешними хранилищами данных. Некоторые прокси расположены на уровне 4 (Layer 4,
L4) сетевого транспортного уровня и используют доступную там информацию,
чтобы принять решение, как распределять запросы, поступающие от серверов
приложений на серверы баз данных. Сюда входят IP-адреса и порты источника
и приемника в заголовке пакета. Функциональность L4 позволяет распределять
трафик по определенному алгоритму, но при этом не принимаются во внимание
другие факторы, такие как загрузка или задержка репликации.

Архитектурные компоненты  277
Уровни 4 и 7
Говоря об уровнях, мы имеем в виду уровни модели взаимодействия открытых
систем (Open Systems Interconnection, OSI). Эта модель определяет сетевой
стандарт.

Прокси уровня 7 (L7) работает на самом высоком уровне сетевого транспортного
уровня. Это также называется уровнем приложения или в данном случае уровнем
HTTP. На уровне L7 прокси-сервер имеет доступ к значительно большему количеству данных из пакета TCP. Прокси-серверы L7 понимают протокол базы данных
и протокол маршрутизации и имеют широкие возможности по настройке.
Их функции могут включать в себя следующее:
‰‰проверку работоспособности и перенаправление на работоспособные серверы;
‰‰разделение операций чтения и записи и передачу операций чтения в реплики;
‰‰переписывание запросов, которые нельзя настроить в коде, с целью оптимизации.
‰‰кэширование и возвращение кэшированных результатов запроса;
‰‰перенаправление трафика на реплики, на которых нет задержек;
‰‰генерирование метрик по запросам;
‰‰фильтрацию трафика брандмауэром в зависимости от типов запросов или хостов.

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

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

278  Глава 12



Примеры архитектур данных

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

Масштабируемость
Имея хороший уровень прокси, можно значительно улучшить масштабирование.
Мы уже обсуждали паттерны масштабирования, которые включают в себя распределение операций чтения между несколькими репликами. Без прокси тоже
можно выполнять элементарное распределение нагрузки, но без учета нагрузки
и задержки и, следовательно, не так эффективно. Использование прокси-сервера
для распределения операций чтения — очень эффективный подход для распределения большой рабочей нагрузки при чтениях. Это предполагает, что у организации
достаточно денег, чтобы заплатить за все эти реплики, и налажена эффективная
автоматизация для управления ими.
Еще одной задачей, при которой прокси-уровень может улучшить масштабируемость, является сбрасывание нагрузки (load shedding). Многие серверы баз данных
страдают от большого количества одновременных подключений. Прокси-уровень
может играть роль очереди соединений, удерживая большое количество соединений, в то же время позволяя только определенному числу из них выполнять работу в базе данных. Это может показаться нелогичным из-за увеличения задержки
вследствие параллелизма, однако ограничение количества соединений и работы
может обеспечить большую пропускную способность.

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

Архитектурные компоненты  279

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

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

лище;

‰‰выполнить заказы;
‰‰обнаружить мошенничество и проверить транзакцию;
‰‰загрузить данные в кэши или сети доставки контента (Content Delivery Net­

works, CDN);

‰‰откорректировать и опубликовать параметры персонализации.

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

280  Глава 12



Примеры архитектур данных

К другим системам относятся RabbitMQ, Amazon Kinesis и ActiveMQ. В простейшем случае это может быть задача типа «извлечь, преобразовать и загрузить»
(ETL) или задачи, при которых хранилище данных постоянно или периодически
опрашивается на предмет появления новых данных.

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

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

Архитектурные компоненты  281

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

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

Кэши и устройства памяти
Мы уже обсудили, насколько невероятно медленно предоставляется доступ
к диску по сравнению с доступом к памяти. Вот почему мы стремимся сделать так,
чтобы все наборы данных из хранилищ соответствовали структурам памяти, таким
как буферные кэши, вместо того чтобы считывать данные с диска. При этом во
многих организациях просто не предусмотрен бюджет на хранение набора данных
в памяти. В случае данных, размер которых слишком велик для кэша хранилища
данных, стоит обратить внимание на системы кэширования и хранилища, оптимизированные для обработки данных в оперативной памяти (in-memory datastores).
Системы кэширования и хранилища данных для обработки в памяти, по сути,
весьма похожи. Их назначение — хранение данных не на диске, а в оперативной
памяти, что обеспечивает быстрый доступ при чтении. Если данные редко изменяются и вы допускаете возможность эфемерного хранения в памяти, это может
оказаться отличным вариантом. Многие хранилища данных для обработки в памяти обеспечивают длительное хранение благодаря копированию данных на диск с
помощью фоновых процессов, которые асинхронно запускаются из транзакции. Но
это повышает риск потери данных в случае сбоя до того, как они будут сохранены.

282  Глава 12



Примеры архитектур данных

Хранилища данных для обработки в памяти часто имеют дополнительные функции, такие как использование расширенных типов данных, возможность репликации и отработка отказов. Современные хранилища для обработки данных в памяти
также оптимизированы для доступа к данным в оперативной памяти, что может
оказаться быстрее, чем даже работа с набором данных в реляционной системе, которая полностью помещается в кэше базы данных. Кэши баз данных по-прежнему
должны проверять актуальность своих хранилищ и соблюдать требования к параллельному доступу и ACID. Таким образом, хранилище данных в памяти может
оказаться наиболее подходящим вариантом для систем, требующих наименьшего
времени отклика.
Существует три подхода к загрузке кэша данными. Первый подход состоит в том,
чтобы поместить данные в кэш после того, как они будут записаны в постоянное
хранилище наподобие реляционной БД. Второй вариант — одновременная запись
в кэш и долговременное хранилище в режиме двойной записи. Такой подход не
очень надежен из-за возможности сбоя одной из двух записей. Для выполнения
этой работы требуется также проводить валидацию после записи или двухэтапную фиксацию. Последний подход — сначала записать в кэш, а затем разрешить
асинхронное сохранение на диске. Такой вариант также называется сквозной
записью (write-through). Обсудим, как каждый из этих подходов может повлиять
на систему баз данных.

Доступность
Использование кэша может положительно повлиять на доступность, позволяя продолжать чтение даже при сбое хранилища данных. Для приложений с интенсивным чтением это может быть очень полезным. Однако если в системе кэширования
произойдет увеличение емкости и/или сокращение задержек либо случится сбой,
то данные, предназначенные для длительного хранения, могут оказаться не соответствующими трафику, отправляемому обратно. Поддержание доступности на
уровне кэширования становится таким же важным, как обеспечение доступности
в хранилище данных, а это означает, что управление усложняется в два раза.
Еще одна важная проблема — «несметная орда». Она проявляется, когда у всех
серверов кэша есть фрагмент данных, к которому обращаются очень часто и который аннулирован из-за записи или превышения времени отклика. Когда это
происходит, большое количество серверов одновременно отправляют запросы на
чтение в постоянное хранилище, чтобы обновить кэш. Это может привести к конкурентному резервному копированию, которое чревато перегрузкой постоянного
хранилища данных. Когда это происходит, может оказаться невозможным обслуживать операции чтения из кэша или постоянно хранимых данных.

Архитектурные компоненты  283

Есть несколько способов управления «несметной ордой». Довольно легко можно
гарантировать, что простои кэша не будут затрагивать друг друга, хотя это и не
очень масштабируемый подход. Более управляемый вариант состоит в добавлении уровня прокси-кэша, который бы ограничивал прямой доступ к хранилищу
данных. На этом этапе будет уровень постоянного хранения, уровень прокси-кэша и уровень кэша. Как видим, масштабирование может быстро стать довольно
сложным.

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

284  Глава 12



Примеры архитектур данных

Масштабируемость
Одной из основных причин использования кэширования и баз данных в оперативной памяти является масштабирование в соответствии с рабочей нагрузкой,
создаваемой чтением данных. Поэтому действительно, добавив уровень кэширования, можно эффективно увеличить степень масштабирования за счет сложности
среды. Но, как обсуждалось выше, в таком случае успешное достижение целевых
показателей качества обслуживания (SLO) начинает зависеть от этого уровня
кэширования. Если серверы кэша выйдут из строя и информация на них окажется
недействительной или поврежденной, то вы больше не сможете рассчитывать, что
хранилище данных сохранит операции чтения приложения.

Время отклика
Использование уровня кэширования не только обеспечивает масштабируемость,
но и позволяет уменьшить задержку чтения. Это отличное применение кэша или
технологии хранения данных в оперативной памяти, но если кэш-сервер выйдет из
строя, то вы больше не сможете напрямую отслеживать состояние долговременных
хранилищ без рабочего кэш-сервера. Стоит запланировать и выполнять периодические тесты для трафика чтения, обходя кэш в тестовых средах, чтобы увидеть, как
на уровне постоянного хранения данных одновременно обрабатываются рабочие
нагрузки записи и чтения. Если есть вероятность отказа долговременного хранилища в производственной среде, то вы, вероятно, захотите проверить эти сбои
в среде тестирования.
Кэширование и использование хранилищ данных для обработки в памяти характерны для многих успешных архитектур, основанных на данных. Они хорошо сочетаются с промежуточным ПО (middleware), управляемым событиями, способны
существенно повысить масштабируемость и производительность приложения.
Однако они создают дополнительный уровень управления с точки зрения эксплуатационных расходов, риска отказов и риска целостности данных. Это часто упускают
из виду (хотя так делать нельзя) из-за того, что многие системы кэширования чертовски просты в реализации. Ваша задача как DBRE-специалиста — гарантировать
серьезное отношение в организации к ответственности за обеспечение доступности
и целостности этой подсистемы.
Каждый из рассмотренных компонентов играет важную роль в обеспечении доступности, масштабируемости и расширенной функциональности ваших хранилищ
данных. Но каждый из них также увеличивает архитектурную сложность, эксплуатационные зависимости, риск потери данных и проблемы их целостности. Теперь, когда
мы рассмотрели некоторые отдельные компоненты, разберем несколько архитектур,
используемых для передачи данных через клиентские приложения в хранилище
и далее к многочисленным последующим сервисам.

Архитектуры данных  285

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

Лямбда и каппа
Лямбда (Lambda) — это архитектура для обработки больших данных в реальном
времени. Сегодня она повсеместно применяется во многих организациях. Каппа
(Kappa) — это паттерн реагирования, предполагающий стремление к простоте
и использованию преимуществ новейшего программного обеспечения. Сначала
рассмотрим первую архитектуру, а затем обсудим ее изменения.

Лямбда-архитектура
Лямбда-архитектура предназначена для обработки значительных объемов данных;
обработка выполняется быстро, что позволяет обслуживать запросы почти в реальном времени, а также поддерживать длительные вычисления. Лямбда-архитектура
состоит из трех уровней: пакетной обработки (batch processing), обработки в реальном времени (real-time processing) и уровня запросов (query layer), или обслуживающего уровня (рис. 12.1).
Если данные записываются во внешнее хранилище, то можно использовать распределенный журнал, такой как Kafka, чтобы создать распределенный и неизменяемый журнал для уровней обработки лямбда-архитектуры. Некоторые данные
записываются непосредственно в журналы сервисов, а не в хранилище данных.
Потоковые уровни принимают эти данные.
У лямбда-архитектуры есть два уровня обработки, поэтому она поддерживает
быстрые запросы с «достаточно хорошей» быстрой обработкой, а также позволяет
выполнять более полные и точные вычисления. Уровень пакетной обработки часто
выполняется с помощью запросов MapReduce, время ожидания которых просто недопустимо для запросов, выполняемых в реальном или почти в реальном времени.
Типичным хранилищем данных для пакетного уровня является распределенная
файловая система, такая как Apache Hadoop. Затем MapReduce создает пакетные
представления из основного набора данных.

286  Глава 12



Примеры архитектур данных

Рис. 12.1. Лямбда-архитектура

Уровень обработки в реальном времени обрабатывает потоки данных с той скоростью, с которой они поступают, не требуя полноты или абсолютной точности.
Он предоставляет компромисс между качеством данных и задержкой для передачи последних данных приложению. Задача этого уровня — заполнить пробел
в данных, задерживающихся на пакетном уровне. После завершения пакетной
обработки данные с уровня реального времени заменяются данными с пакетного уровня. Обычно это выполняется с помощью технологии Apache Storm или
Spark с поддержкой хранилища данных с малой задержкой наподобие Apache
Cassandra.
Наконец, есть еще обслуживающий уровень, который возвращает данные приложению. Он содержит пакетные представления, созданные на пакетном уровне, и выполняет индексацию для обеспечения запросов с низкой задержкой. Этот уровень
реализуется с использованием HBase, Cassandra, Apache Druid или другого аналогичного хранилища данных.
Кроме результатов с низкой задержкой для уровня реального времени, у этой архитектуры есть и другие преимущества, не в последнюю очередь то, что входные данные
в основном наборе данных остаются неизменными. Это позволяет обрабатывать
данные при изменении кода и бизнес-правил.
Самый важный недостаток этой архитектуры состоит в том, что приходится
поддерживать две отдельные базы кода: одну для реального времени и одну для
уровней пакетной обработки. Эта сложность связана с гораздо более высокими

Архитектуры данных  287

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

Каппа-архитектура
Исходная концепция каппа-архитектуры (рис. 12.2) была впервые описана
Джеем Крепсом (Jay Kreps), когда он работал в LinkedIn. В лямбда-архитектуре для хранения данных используется реляционное хранилище данных или
хранилище NoSQL. В каппа-архитектуре хранилище данных представляет собой неизменяемый журнал, предназначенный только для добавления данных,
такой как Kafka. Уровень обработки в реальном времени передает данные через
вычислительную систему и направляет их во вспомогательные хранилища для
обслуживания. Каппа-архитектура исключает систему пакетной обработки,
ожидая, что система потоковой передачи сможет выполнить все преобразования
и вычисления.

Рис. 12.2. Каппа-архитектура

288  Глава 12



Примеры архитектур данных

Одно из самых больших достоинств каппа-архитектуры — снижение сложности
и эксплуатационных расходов, по сравнению с лямбда-архитектурой, за счет исключения уровня пакетной обработки. Каппа-архитектура также предназначена
для уменьшения сложностей при миграциях и реорганизациях. Если вы захотите
повторно обработать данные, то сможете запустить повторную обработку, протестировать ее и переключиться на нее.
Лямбда- и каппа-архитектура — это примеры паттернов, которые можно использовать для обработки и представления больших объемов данных в режиме реального времени. Далее мы рассмотрим некоторые типовые архитектурные решения,
основанные на данных и созданные как альтернативы традиционному подходу
к приложениям, которые обращаются к своим хранилищам напрямую.

Порождение событий
Порождение событий — это архитектурный паттерн, который полностью меняет
способ извлечения и вставки сохраненных данных. В этом случае уровень абстракции хранилища данных снижается, что обеспечивает гибкость при создании и восстановлении представлений данных.
Архитектурный паттерн порождения событий предполагает, что изменения объектов сохраняются в виде последовательности изменений состояния. Когда состояние изменяется, в журнал добавляется новое событие. В традиционном хранилище
данных изменения деструктивны — предыдущее состояние заменяется текущим.
В модели порождения событий, поскольку все изменения записываются, текущее
состояние приложения может быть восстановлено путем воспроизведения событий
из журнала. Такое хранилище данных называется хранилищем событий.
Это нечто большее, чем просто новый журнал для изменений. Порождение событий
и распределенные журналы — это новый паттерн моделирования данных. Поро­
ждение событий дополняет традиционное хранилище, такое как реляционное или
хранилище типа «ключ — значение», предоставляя более низкий уровень хранения
данных, оперирующий событиями, а не значениями с состоянием, которые могут
быть перезаписаны.
Хранилище событий функционирует не только как распределенный журнал событий и база данных записей, но и как система сообщений, как было показано ранее
в этой главе. Последующие процессы и рабочие потоки могут на них подписаться.
Когда сервис сохраняет событие в хранилище событий, оно доставляется всем заинтересованным подписчикам. Хранилище событий можно реализовать в виде реляционного или NoSQL-хранилища данных либо в распределенном журнале, таком

Архитектуры данных  289

как Kafka. Существует даже специальное хранилище событий EventStore — проект
с открытым исходным кодом, в котором хранятся неизменяемые записи и которое
рассчитано только для добавления данных. Выбор будет во многом определяться
скоростью изменения и тем временем, в течение которого все события должны
храниться до следующего моментального снимка и сжатия.
Порождение событий имеет ряд преимуществ. В отличие от деструктивных изменений данных здесь достаточно провести аудит жизненного цикла объекта. Такое
решение также значительно облегчает отладку и тестирование. Даже если кто-то
случайно удалит таблицу или фрагмент данных в хранилищах событий, все равно
останется распределенный журнал, по которому можно воссоздать все таблицы или
одну из них для определенной сущности (entity). Однако здесь есть ряд проблем.
Не в последнюю очередь это управление изменениями схемы сущностей, потому
что изменение может сделать недействительными предыдущие сохраненные события. Кроме того, может оказаться сложным воссоздавать внешние зависимости
при воспроизведении потока событий.
Благодаря преимуществам порождения событий данный паттерн может найти
применение во многих магазинах, несмотря на то что в их приложениях вместо
хранилища событий все еще используются более традиционные хранилища
данных.

CQRS
Существует подход, отражающий естественный переход от использования хранилища событий в качестве вспомогательной абстракции хранилища к использованию хранилища событий в качестве основного уровня хранения данных. Это
CQRS — разделение ответственности на команды и запросы (Command-QueryResponsibility Segregation). В основе CQRS лежит идея о том, что одни и те же
данные могут быть представлены для потребления с использованием нескольких
моделей или представлений. Такая необходимость в различных моделях исходит
из концепции, что в разных предметных областях разные цели и эти цели требуют
разных контекстов, языков и в итоге разных представлений данных.
CQRS можно реализовать, используя порождение событий. Распределенный
журнал изменений состояния событий позволяет рабочим процессам, подписавшимся на эти события, создавать эффективные представления, которые
затем можно использовать. CQRS может также обеспечивать некоторые другие
полезные варианты поведения. Вместо того чтобы просто создавать новые представления, можно создавать представления этих данных в разных хранилищах,

290  Глава 12



Примеры архитектур данных

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

Резюме  291

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

13

Как обосновать и внедрить
DBRE

На протяжении всей книги мы пытались показать, как со временем менялся
инжиниринг баз данных. Мы перечислили области эксплуатации и разработки,
в которые должен быть вовлечен инженер по обеспечению надежности баз данных
(DBRE), и рассказали о том, с чего начать. Наконец, мы попытались рассказать
вам о современных экосистемах хранения и репликации, о хранилищах данных
и архитектурах, чтобы расширить ваш кругозор.
Мы уверены, что есть насущная необходимость уделить особое внимание надежности как одной из сфер ответственности DBR-инженера, ведь база данных — это
то место, где риск и хаос просто недопустимы. Многое из того, что сейчас стало
обычным явлением в нашей повседневной работе, — виртуализация, инфраструктура как код, контейнеры, бессерверные вычисления и распределенные
системы — возникло в тех вычислительных областях, где риск был допустимым.
Теперь, когда эти технологии используются повсеместно, специалисты, которые
управляют одним из самых ценных ресурсов организации — данными, — должны
найти способы включить базы данных в эти парадигмы.
Значительная часть этой работы все еще относится к области скорее желаемого,
чем действительного. Любая организация очень дорожит своими данными и не
хочет ими рисковать. Таким образом, то, как мы преподносим эти концепции
остальной части организации или как реагируем на действия других, — зависит
только от нашего профессионального уровня. Недостаточно иметь видение и намерение — чтобы достичь успеха, необходимо найти способы представить это
видение другим.
В этой главе мы расскажем, как ввести культуру обеспечения надежности баз
данных в вашей организации сейчас и в будущем. В процессе рассмотрения и обсуждения DBRE к вам будет приходить понимание, в каких направлениях и как
это можно применить к широкому кругу решаемых задач.

Культура обеспечения надежности баз данных  293

Культура обеспечения надежности баз данных
Что такое культура обеспечения надежности баз данных и как ее внедрять?
Есть много процессов, которые, как считается, относятся к культуре обеспечения
надежности, однако при этом не относятся к базам данных как таковым, в том числе:
‰‰создание безобвинительных (не предусматривающих поиска виновных) отчетов

о проблемах («постмортемов»);

‰‰автоматизация повторяющейся, рутинной работы;
‰‰структурированное и рациональное принятие решений.

Все это действительно имеет смысл, и каждый сотрудник организации, занимающийся эксплуатацией или обеспечением надежности информационных систем
(SRE), должен постоянно над этим работать. Но на что мы, как DBRE-специалисты
или люди, которые хотят ими стать, должны обратить особое внимание в своей
деятельности? В этой главе мы рассмотрим подходы, которые позволят нам быть
вовлеченными в процесс, внедрять культуру обеспечения надежности и донести
знания в области DBRE до остальных работников организации.

Разрушение барьеров
Администратор баз данных, который держится обособленно от других специа­
листов, взаимодействующих с хранилищем данных, попросту не может работать
успешно. Чтобы быть эффективными, нам необходимо быть активными членами
команды и партнерами. Это неизбежно связано с той проблемой, что роль базы
данных обычно не очень понятна. На протяжении всей книги мы подчеркивали,
что просто невозможно в полной мере донести понимание роли базы данных до
всех разработчиков и инженеров по эксплуатации, которые будут с ней работать.
В некоторых областях DBRE-специалист может оказаться весьма эффективным
членом универсальной команды. Каждый раз, когда DBR-инженера привлекают
к смежным с его основными обязанностями работам, ему необходимо поставить
цель — предоставить экспертные знания в его области, устранить ограничения на
ресурсы DBRE или узнать больше о работе других, чтобы все могли лучше выполнять задачи, поставленные в организации.

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

294  Глава 13



Как обосновать и внедрить DBRE

хранилище данных, желательно такое, которое уже было хорошо протестировано
и апробировано. Как было изложено в главах 7 и 11, DBRE-специалист должен
хорошо разбираться в хранилищах данных, которые могли бы быть введены в эксплуатацию в организации.
В более крупных организациях, которым требуется самообслуживание для создания и развертывания сервисов, DBRE-специалист обладает особыми полномочиями по определению списка сервисов хранения, переданных на самообслуживание.
Сотрудничая с техническими отделами, DBR-инженер может помочь поддержать
утвержденный порядок использования сервисов из этого списка, работоспособность которых была подтверждена на множестве тестов нагрузочной способности,
граничных случаев, масштабирования, надежности и целостности данных. Порой
он также может допустить самостоятельное создание и развертывание сервисов,
не входящих в этот список (и, соответственно, не проходивших строгие проверки)
или находящихся в этом каталоге на другом уровне, но при условии изменения
соглашений об уровне обслуживания (SLA). Рассмотрим примеры.
‰‰Уровень 1. Хранилище протестировано для базовых сервисов в реальной про-

изводственной среде. Использование паттернов самообслуживания означает,
что специалисты по эксплуатации и DBR-инженеры могут обеспечить SLA
о не более чем 15-минутном интервале реагирования на критические ошибки и
наиболее неотложные проблемы1 и гарантируют максимальные SLA по доступности, задержке, пропускной способности и устойчивости. Реагирование может
состоять в решении проблемы или (чаще) ее распознавании и перенаправлении
соответствующим специалистам (escalation).

‰‰Уровень 2. Хранилище протестировано в производственной среде для некри-

тических сервисов. Это означает, что специалисты по эксплуатации и DBRE
смогут обеспечить 30-минутные SLA времени реагирования на события Sev1
и гарантируют сохранение работоспособности, но со снижением целевых показателей качества обслуживания (SLO) по доступности, задержке, пропускной
способности и устойчивости.
‰‰Уровень 3. В производственной среде хранилище не тестировалось. Специалисты

по эксплуатации и DBRE обеспечивают реагирование настолько оперативно, насколько это возможно, но никаких гарантий SLO не дается. Хранилище должно
полностью поддерживаться командой разработки программного обеспечения.
Если в организации не поддерживаются подобные технологии самообслуживания, то DBRE-специалист должен приложить больше усилий к тому, чтобы все
специалисты знали о тех методах, которые используются при выборе хранилищ
данных и архитектур, и о том значении, которое имеет этот выбор. Несмотря на
1

Severity 1 error, Sev1. — Примеч. науч. ред.

Культура обеспечения надежности баз данных  295

то что преждевременная оптимизация всегда рискованна, одна из самых ценных
вещей, которые предоставляет DBRE, — это гарантии того, что выбор архитектуры хранилища данных не помешает будущему развитию сервиса, если однажды
это хранилище достигнет критической точки масштабирования.
Во многих организациях любой проект начинается с составления обязательного
контрольного списка (технического задания), который включает в себя также
обзор базы данных задолго до того, как проект будет запущен в промышленную
эксплуатацию. Однако в реальной жизни с таким отношением к проекту вы можете слишком долго ждать, и в какой-то момент может оказаться просто поздно
что-либо менять. В этот момент важно искусно проявить дипломатию. Нужно
найти время, чтобы оценить возможности разных хранилищ данных и донести до
остальных рекомендуемые методы, компромиссы и модели для наиболее распространенных хранилищ данных или тех хранилищ, которые будут использоваться
в будущем в организации, — это важный способ показать всем, в чем польза от
DBRE-специалиста. Это также отличный шанс поработать с разработчиками
и архитекторами, собрать и эти данные и сделать их доступными для того, чтобы
привлечь к ним больше внимания. Если делать это каждый раз, когда в обсуждении архитектуры появляется новое хранилище данных, которое вы еще не рассматривали, то ваши коллеги будут охотнее вкладывать ресурсы в оценку хранилища
данных как части проекта, обращаясь к вам как куратору и консультанту. Главное,
чтобы люди увидели в привлечении DBRE пользу, а не ограничения.
Существуют показатели, которые можно использовать, чтобы измерить, в правильном ли направлении движутся DBRE-специалисты и организация в целом.
Вот несколько примеров таких показателей.
‰‰В каком количестве архитектурных проектов участвовали DBRE-специалисты

или использовались утвержденные ими паттерны и типовые решения? (Постмортем.)

‰‰Какое хранилище было использовано и развернуто? (Постмортем.)
‰‰Сколько часов работы DBRE-специалиста затрачено на каждом этапе или сум-

марно в ходе формирования требований к системе? (Постмортем.)

‰‰Показатели доступности, пропускной способности и задержки, сгруппирован-

ные по уровням и механизмам хранения для обеспечения надежности.

Разработка базы данных
Как и в случае с архитектурой, DBRE-специалисты, участвующие в разработке
баз данных с самых ранних этапов цикла проектирования, могут стать фактором,
способствующим успеху проекта. Мы подробно обсуждали эту возможность
и пользу от такого участия в главе 8. Одно из самых больших препятствий для
этого — разработчики, которые забывают обсуждать свои проекты с DBRE. Кроме

296  Глава 13



Как обосновать и внедрить DBRE

того, разработчики могут посчитать, что им такая помощь не нужна. Одна из самых
больших побед в этой борьбе — помочь команде разработчиков увидеть пользу от
работы, выполняемой совместно с DBRE-специалистами.
Задействование DBRE либо на полный рабочий день, либо только в определенные
моменты в жизненном цикле проекта; работа совместно с разработчиками программного обеспечения — это прекрасная возможность помочь программистам
увидеть пользу от взаимодействия с DBRE. Даже если DBR-инженер не особенно
силен в написании кода, его вклад в построение моделей данных, создание доступа
к базе данных и использование функций может оказаться неоценимым, а также он
может помочь выстроить отношения между подразделениями. Сотрудничество
разработчиков с DBRE-специалистами, которые выполняют оценку и реализацию
приложений, управляемых данными или в любой момент доступны для предоставления помощи, может также способствовать развитию отношений, взаимопониманию, распространению межгрупповых знаний, что ускоряет разработку.
Мы также обсудили важность распространения рекомендованных методов и типовых решений для функций, которые создает разработчик и которые требуют интеграции с уровнем данных. Например, можно составить контрольные списки для
используемых моделей, запросов или функций, в отношении которых программист
должен указывать, использовал ли он определенные паттерны и типовые решения.
Эти контрольные списки могут сигнализировать о требованиях, сценариях или
функциях, которые, возможно, придется пересмотреть, прежде чем передавать
продукт в промышленную эксплуатацию.
Существуют показатели, которые можно использовать для оценки того, насколько
DBRE-специалисты и организация в целом продвинулись в этом направлении. Вот
некоторые их примеры:
‰‰количество часов, в течение которых программисты и DBR-инженеры вели

совместную разработку;

‰‰требования и пользовательские сценарии, в формировании которых участво-

вали DBR-инженеры;

‰‰привязанность таких показателей функционирования, как задержка и устойчи-

вость, к использованию DBRE;

‰‰дежурства совместно с разработчиками.

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

Культура обеспечения надежности баз данных  297

что может повлечь значительный риск, или же миграции выполняются без тщательного контроля со стороны DBRE. Как обсуждалось в главе 8, эффективный
способ справиться с этой ситуацией состоит в том, чтобы создать процесс и инструменты, позволяющие разработчикам сделать оптимальный выбор: что может
быть реализовано с помощью обычных механизмов развертывания, что следует
поручить реализовать DBRE-специалистам, а что DBRE-специалисты должны
проверить в случае сомнений.
Самый простой первый шаг — постепенно создать библиотеку эвристик, которые бы указывали, какие изменения являются безопасными, а какие — нет. При
этом узкое место не исчезнет сразу, однако создание соглашений для сборки
такой библиотеки совместно с DBRE-специалистами положит начало процессу.
Периодический пересмотр и проверка результатов применения эвристик и рекомендаций, а также анализ успешных или неуспешных завершений изменений
могут оказаться эффективным средством контроля данного процесса. Это можно
сделать частью обычного послеаварийного анализа изменений, как успешных,
так и неудачных.
Еще один способ постепенно увеличивать автономность отделов разработки —
построить базу данных паттернов миграции, которые могут быть эвристически
применены к предстоящим изменениям. Если делать это во взаимодействии
с разработчиками, то со временем, работая совместно с ними над изменениями, вы
сможете создать постоянно обновляемый документ, который разработчики будут
не только использовать, но и сами дорабатывать. Здесь, как всегда, решающее
значение имеет выполнение послеаварийного анализа и обзоров (постмортемов)
для подтверждения успешности таких моделей.
Эту идею можно развить дальше, определив ограничения для реализаций, которые, согласно эвристикам и паттернам миграции, могут быть выполнены разработчиками. Эти ограничения дадут уверенность всем — разработчикам, службе
эксплуатации, DBR-инженерам и руководству. Чем больше успеха вы будете
демонстрировать и чем сильнее укрепите доверие, тем дальше это может зайти.
Предоставив разработчикам самостоятельность, вы, вероятно, обнаружите, что
ваши отношения с этими специалистами станут гораздо более здоровыми, поскольку вы докажете, что такие отношения приносят скорее пользу, чем являются препятствием. Продолжая делиться своими знаниями в области хранения
данных и доступа к базам данных, вы повысите их эффективность и улучшите
взаимодействие между вами. Это можно сделать индивидуально, работая в паре,
или организовав обучение, например в форме семинаров, обмена знаниями или
с помощью документов.
Никакая активизация общения не изменит тот факт, что некоторые миграции придется выполнять DBRE-специалисту. Но и в этом случае существуют подходы,
которые можно использовать для обучения и поддержки других работников. Опять

298  Глава 13



Как обосновать и внедрить DBRE

же, отличным вариантом в этом случае может быть сотрудничество с инженерами
в процессе планирования и выполнения миграции. Кроме того, может быть очень
полезным сотрудничество с инженерами по эксплуатации, поскольку чем больше
людей сможет помочь и в итоге выполнить сложные промышленные реализации,
тем лучше.
Даже без значительной автоматизации у вас и команды DBRE есть множество
способов вносить изменения более надежно и безошибочно, не останавливая конвейер разработки. После того как будет получено доверие и достигнута хорошая
повторяемость ручных процессов, вы можете продвинуться дальше, вводя новые
технологии, инструменты и код.
Существуют показатели, которые можно использовать для оценки того, насколько
хорошо работают в этом направлении отдельные DBRE-специалисты и подразделение в целом. Вот несколько примеров таких показателей:
‰‰количество часов совместной работы программистов, специалистов по эксплуа­

тации и DBRE в ходе миграции;

‰‰процент миграций, требующих вмешательства DBRE;
‰‰количество успешных и неуспешных миграций и их влияние.

Проектирование и развертывание инфраструктуры
В разделе, посвященном архитектуре, мы обсудили работу с разработчиками по
выбору проверенных и надежных хранилищ данных. Точно так же необходимо
постоянно работать с персоналом по эксплуатации и инфраструктуре, чтобы у этих
специалистов было все нужное не только для размещения хранилищ данных, но
и для их развертывания и обслуживания. В главе 5 мы подробно обсудили различные стороны и этапы этой работы, а в главе 6 — программное обеспечение
и инструменты, необходимые для управления этими инфраструктурами при масштабировании. Но мы все еще находимся на ранних стадиях этого процесса для
хранилищ данных, особенно распределенных.
Как и в случае с производственными реализациями и предоставлением инженерам-программистам большей автономии, основная часть внедрения таких
отношений и процессов сводится к постепенному, поэтапному формированию
доверия. Первые шаги, которые могут принести значительную пользу команде
DBRE и всей организации, — это использование единых репозиториев и систем
управления версиями для хранения сценариев, конфигураций и документации.
Затем можно поработать с командой специалистов по эксплуатации, чтобы начать настройку и развертывание пустых хранилищ данных с использованием
средств управления конфигурацией и оркестрации. Впоследствии вам предстоит
еще заполнить эти хранилища реальными данными, но и это — уже шаг вперед.

Культура обеспечения надежности баз данных  299

При этом, сотрудничая со специалистами по эксплуатации, можно проверить корректность конфигурации, протестировать безопасность, выполнить нагрузочное
тестирование и даже более сложные тесты на целостность и репликацию данных.
Чем глубже вы ознакомите всю команду с тем, как работают базы данных и как
они ломаются, тем лучше. Проверка доступности и поведения при сбоях также
является критически важным тестом, который может потребоваться и другим
подразделениям.
Наконец, можно начать ставить задачи оперативного реагирования персоналу по
эксплуатации и даже ведущим разработчикам по управлению их инфраструктурой.
Благодаря тому что вы и ваша команда зеркально отражаете их и сотрудничаете
с ними, они могут быстро обрести уверенность в работе с этими инфраструктурами
и свести риски к минимуму. Только когда команда по-настоящему будет уверена
в том, что знает все изнутри и снаружи, можно начать автоматизировать более
рискованные компоненты, такие как загрузка данных, изменение репликации и отработка отказов ведущего узла.
Существуют следующие показатели, которые можно использовать для оценки того,
насколько хорошо работают в этом направлении отдельные DBRE-специалисты
и отдел в целом:
‰‰количество компонентов инфраструктуры, которые настраиваются путем

управления конфигурацией;
‰‰количество компонентов инфраструктуры, интегрированных в платформы

оркестрации;
‰‰количество успешных и неудачных инициализаций;
‰‰показатели потребления ресурсов — по всем подсистемам, используемым хра-

нилищами данных;
‰‰доля дежурных смен под руководством не DBRE-специалистов;
‰‰инциденты, не управляемые DBRE-специалистами, и среднее время восстанов-

ления (MTTR);
‰‰количество инцидентов, потребовавших обращения к DBRE.

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

300  Глава 13



Как обосновать и внедрить DBRE

Принятие решений на основе данных
Доверие невозможно сформировать, не имея исчерпывающей информации о последствиях изменений. Цикл Деминга для планирования, выполнения, проверки
и действия требует наблюдаемости и контролируемости, что мы рассмотрели в главе 4. Прежде чем собирать базовые показатели при каждом изменении, не забудьте
четко сформулировать те их них, которые служат для определения успешности
процедуры, а затем наконец выделите время на тщательный анализ результатов.
Использование знаний о SLO организации, как было показано в главах 2 и 3, имеет
решающее значение для понимания изменений, которые необходимо внести, а также показателей и результатов, позволяющих показать остальным потенциальную
пользу от изменений и значимость прикладываемых усилий.
Надеемся, вы работаете в организации, которая уже осознала важность принятия
решений на основе данных и, таким образом, уже внедрила платформу для мониторинга, процессы анализа, а также дисциплину, которой она неуклонно следует. Мы
также надеемся, что в вашей организации уже определены четкие адекватные SLO
для принятия решений. Но если все не так, то вам нужно начать именно с этого,
чтобы иметь возможность продвигаться к более глубоким и потенциально более
далекоидущим изменениям.

Целостность и возможность восстановления данных
В главе 7 мы обсудили важность обеспечения целостности данных и возможности
их восстановления после потери или повреждения. Слишком часто организации
рассматривают это как обязанность DBRE-специалистов, но мы знаем, что силами
одних только DBRE эта задача невыполнима. DBR-инженеры неизменно оказываются чемпионами по количеству выпадающих на них задач по обеспечению
целостности данных. Ваша постоянная ответственность — убедить разработчиков
в важности выделения ресурсов для создания технологических процессов проверки данных и API для восстановления. И если вы счастливо преодолеете барьеры
между архитектурой, разработкой программного обеспечения и неучастием DBRE
в ранних этапах разработки, то обнаружите, что построили прочные отношения
и установили доверие с разработчиками и можете постепенно создавать общую базу
кода и знаний, необходимых для реализации эффективного процесса обеспечения
целостности данных.
Убедить их будет не просто. Как показывает наш опыт, большинство разработчиков считают, что целостность данных — это зона ответственности исключительно DBRE-специалистов. И некоторые подразделения будут препятствовать
разработке процессов валидации и API восстановления. Тогда вам придется искать решения «для бедных», которые будут лишь собирать сведения о проблемах

Резюме  301

целостности данных. Аналогично оценка и фиксация усилий и затрат на ручное
восстановление данных может стать весомым аргументом для руководства, чтобы
начать выделять ресурсы для разработки и внедрения API восстановления и процессов валидации.
Как видите, успешное движение в сторону повышения надежности баз данных
требует постепенных и комплексных организационных изменений. Выбор направлений, в которых ваши усилия принесут наибольшую пользу для всех, — это навык,
требующий здравого смысла и практики. Последующие «точечные» изменения,
приводящие к последовательным улучшениям и способствующие укреплению
доверия, придадут импульс дальнейшему движению. Но все это требует времени,
доверия и множества экспериментов в отношении того, что лучше сработает для
тех уровней риска, которые характерны для вашей организации.

Резюме
Мы хотели бы поблагодарить вас за то, что вы нашли время прочитать эту книгу.
Мы обе очень увлечены построением карьеры в одной из самых утомительных
и неблагодарных областей техники. Несмотря на то что значительная часть этой
книги рассчитана на перспективу и все еще проходит проверку в реальных условиях, мы уверены, что продвижение DBRE может принести огромную пользу
сервисам, управляемым данными, и занимающимся ими отделам.
Надеемся, что вы вдохновитесь на изучение этих процессов в вашей организации
и будете жаждать узнать больше. Мы постарались предоставить вам дополнительные источники для чтения и изучения, поскольку эти подходы и технологии
весьма гибки и подвижны. Но самое главное — мы надеемся, что помогли вам
увидеть возможность перенести проверенную временем роль DBA в современный
мир и в будущее. Роль DBA не исчезает и, независимо от того, являетесь ли вы
в этой области новичком или опытным ветераном, мы хотим, чтобы у вас впереди
была долгая карьера, поскольку вы принесете пользу любой организации, частью
которой являетесь.

Об авторах
Лейн Кэмпбелл (Laine Campbell) работает старшим управляющим (Senior Director)
по проектированию в компании Fastly. Она также была основателем и генеральным
директором PalominoDB/Blackbird — консалтинговой службы,обслуживающей
базы данных ряда компаний, включая Obama for America, Activision Call of Duty,
Adobe Echosign, Technorati, Livejournal и Zendesk. Она имеет 18-летний опыт эксплуатации баз данных и масштабируемых распределенных систем.
Черити Мейджорс (Charity Majors) является генеральным директором и соучредителем компании honeycomb.io. Сочетая в себе точность агрегаторов журналов,
метрики скорости временных рядов и гибкость APM (Application Performance
Metrics), honeycomb представляет собой первый в мире действительно аналитический сервис нового поколения. Ранее Черити была специалистом по эксплуатации
в Parse/Facebook, управляя огромным парком наборов реплик MongoDB, а также
Redis, Cassandra и MySQL. Она также тесно сотрудничала с командой RocksDB
в Facebook, участвуя в разработке и развертывании первой в мире установки
Mongo + Rocks с использованием API подключаемого модуля хранения.

Об обложке
Животное, изображенное на обложке книги, — это суффолк, или суффолкская
лошадь, или суффолкская гнедая. Эта английская порода ломовых лошадей всегда
имеет гнедую масть.
Суффолк был выведен в XVI веке для сельскохозяйственных работ. Породу активно разводили в начале XX столетия, однако в середине века она потеряла популярность из-за механизации сельского хозяйства. Суффолки имеют рост от 1,65
до 1,75 метра и весят около 900 килограммов; они невысоки, но более массивны, чем
лошади других британских племенных пород, таких как клайсдейлы или шайры.
Многие животные, изображенные на обложках книг издательства O’Reilly, находятся под угрозой исчезновения, однако все они важны для мира. Чтобы больше
узнать о том, как им можно помочь, посетите сайт animals.oreilly.com.

Лейн Кэмпбелл, Черити Мейджорс
Базы данных. Инжиниринг надежности
Перевела с английского Е. Сандицкая

Заведующая редакцией
Руководитель проекта
Ведущий редактор
Научный редактор
Литературный редактор
Художественный редактор
Корректоры
Верстка

Ю. Сергиенко
С. Давид
Н. Гринчик
С. Сиротко
Н. Рощина
А. Михеева
Е. Павлович, О. Андриевич
Г. Блинов

Изготовлено в России. Изготовитель: ООО «Прогресс книга».
Место нахождения и фактический адрес: 194044, Россия, г. Санкт-Петербург,
Б. Сампсониевский пр., д. 29А, пом. 52. Тел.: +78127037373.
Дата изготовления: 03.2020. Наименование: книжная продукция. Срок годности: не ограничен.
Налоговая льгота — общероссийский классификатор продукции ОК 034-2014, 58.11.12 —
Книги печатные профессиональные, технические и научные.
Импортер в Беларусь: ООО «ПИТЕР М», 220020, РБ, г. Минск, ул. Тимирязева, д. 121/3, к. 214, тел./факс: 208 80 01.
Подписано в печать 26.02.20. Формат 70×100/16. Бумага офсетная. Усл. п. л. 24,510. Тираж 700. Заказ 0000.
Отпечатано в ОАО «Первая Образцовая типография». Филиал «Чеховский Печатный Двор».
142300, Московская область, г. Чехов, ул. Полиграфистов, 1.
Сайт: www.chpk.ru. E-mail: marketing@chpk.ru
Факс: 8(496) 726-54-10, телефон: (495) 988-63-87