Предисловие

Мы сейчас переживаем время беспрецедентных преобразований и потрясений в индустрии баз данных (БД). Жизненные циклы внедрения технологий ускорились до такой степени, что у кого угодно голова пойдет кругом — и из-за сложных проблем, и из-за открывающихся возможностей.

Архитектура БД развивается столь быстро, что привычные задачи уже не требуют решения, а связанные с ними навыки, в которые вложено так много сил, утратили актуальность. Новые требования безопасности, концепция инфраструктуры как кода (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, а сетевые инженеры предпочитали собственные инструменты. Лишь половина команд пользовалась хоть каким-то контролем версий, и они, конечно же, не общались между собой и не заходили на территорию друг друга. Да и как бы они могли это сделать? Это было бы похоже на пересечение границ другой страны.

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

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

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

С тех пор ей пришлось иметь дело, вероятно, с сотней администраторов БД: нанять, обучить их и работать с ними. Люди, работающие с базами данных, — очень разношерстная компания. Одни пришли из программирования, другие — из системного администрирования. Есть и такие, кто раньше занимался аналитикой данных и бизнесом. Однако все они отличались чувством ответственности за безопасность и доступность данных компании.

Мы исполняли роли управляющих данными с жесткостью, граничащей с нездоровой жестокостью. А еще мы стали связующим звеном между разработчиками программного обеспечения и системными инженерами. Кто-то может сказать, что мы стали первыми системными инженерами (DevOps), стоящими на стыке областей.

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

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

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

Для кого эта книга

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

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

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

Да, возможно, у вас нет специального технического образования. Может быть, вы были бизнес-аналитиком и стали администратором БД неожиданно, сменив специализацию и научившись управлять базами данных. Есть много специалистов по базам данных, пришедших в эту область через Excel, а не через разработку или системное администрирование.

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

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

Есть веская причина тому, что мы уделяем столь пристальное внимание эксплуатации: вы не станете хорошим инженером по обеспечению надежности БД (DBRE), не будучи хорошим инженером по надежности вообще (RE). А им вы не станете, не будучи просто хорошим инженером. Современный DBR-инженер не только хорошо разбирается в основах системного проектирования, но и понимает проблемы данных, связанные с конкретной предметной областью.

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

Вот краткий перечень того, что вас ожидает.

Глава 1 представляет собой введение в концепцию обеспечения надежности БД. Мы начнем с основополагающих принципов, перейдем к работе по сопровождению и эксплуатации — тому центру, вокруг которого вращается DBRE, — и, наконец, соорудим каркас для возведения концепции DBRE с опорой на пирамиду потребностей Маслоу.

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

В главе 3 мы познакомимся с оценкой рисков и управлением ими. После обсуж­дения основ и рисков вообще перейдем к практическим процессам включения оценки рисков в разработку систем и БД. Рассмотрим также подводные камни и различные сложности.

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

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

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

В главе 8 мы обсудим управление версиями. Как тестировать, подготавливать и развертывать изменения в хранилищах данных? Как быть с изменениями в коде доступа к данным и SQL? Основные темы — развертывание, интеграция и распространение.

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

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

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

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

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

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

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

Курсив

Курсивом выделяются новые термины.

Рубленый шрифт

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

Моноширинный шрифт

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

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

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

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

От издательства

Ваши замечания, предложения, вопросы отправляйте по адресу comp@piter.com (издательство «Питер», компьютерная редакция).

Мы будем рады узнать ваше мнение!

На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.

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

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

Бен Трейнор (Ben Treynor), вице-президент по разработкам в Google, так говорит об обеспечении надежности: «SR-инженеры в основном выполняют ту же работу, которой ранее занималась служба эксплуатации, но их знания и навыки позволяют разрабатывать и реализовывать автоматизированные решения, заменяющие человеческий труд, и именно такую задачу ставит перед ними компания» [1].

Современные специалисты по БД должны быть инженерами, а не администраторами. Мы строим новое. Мы создаем новое. Занимаясь сопровождением систем, мы работаем в одной команде, и любая наша проблема становится общей. При проектировании, построении и эксплуатации хранилищ производственных (промышленных) данных и создаваемых внутри них структур мы, как инженеры, ориентируемся на повторяемые процессы, проверенные знания и экспертные оценки. А как специалисты по надежности БД, мы должны понимать принципы работы с базами данных и обладать опытом их эксплуатации.

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

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

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

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

Защита данных

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

• Строгое разделение обязанностей между инженером-программистом и инженером баз данных.

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

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

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

• Дорогостоящая базовая система хранения с резервированием всех компонентов.

• Широкомасштабный контроль изменений и административных задач.

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

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

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

Хранение производственных данных в эфемерных хранилищах

В 2013 году компания Pinterest перевела копии своих баз данных MySQL в эфемерное хранилище на Amazon Web Services (AWS). Эфемерное хранилище, в сущности, означает, что если отдельное вычисление завершается сбоем или прекращает работу, то все, что хранилось на диске, теряется. Pinterest выбрала вариант эфемерного хранилища из-за постоянства его пропускной способности и низкой задержки.

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

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

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

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

• Стандартизированные и автоматизированные процессы резервного копирования и восстановления данных проходят одобрение инженерами по обеспечению надежности БД.

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

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

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

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

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

Самообслуживание как фактор масштабирования

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

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

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

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

• Определить совместно с отделом безопасности стандарты для развертывания хранилищ данных.

• Разработать безопасные методы развертывания и тестовые сценарии для внедрения изменений в БД.

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

Избавление от рутины

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

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

Внесение изменений в базу данных вручную

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

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

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

Базы данных — это не «особенные снежинки»

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

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

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

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

Устранение барьеров между разработкой и эксплуатацией

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

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

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

Инженеры-программисты должны разбираться в эксплуатации!

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

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

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

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

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

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

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

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

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

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

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

Выживание и безопасность

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

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

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

Паттерны масштабирования

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

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

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

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

Деление некоторой рабочей нагрузки на несколько «разделов», которые одинаковы, не считая различных наборов обрабатываемых данных, также называемое сегментированием.

Более подробно эти паттерны будут рассмотрены в главе 5.

Любовь и принадлежность

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

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

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

Ограничения в Etsy

Компания Etsy представила инструмент Schemanator для безопасного внесения в БД изменений, иначе называемых наборами изменений, в свои производственные среды. Был установлен ряд ограничений и проверок, чтобы применять эти изменения могли сами разработчики программного обеспечения.

В определение схем включен эвристический анализ наборов изменений для проверки соответствия стандартам.

Выполняется тестирование наборов изменений для проверки успешности выполнения сценариев.

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

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

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

Подробнее об этом читайте в блоге Etsy (http://bit.ly/2zy74uz).

Уважение

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

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

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

• флаги, с помощью которых можно перевести сайт в режим «только для чтения»;

• отключение отдельных функций;

• постановка операций записи в очередь с отложенным применением;

• возможность занести в черный список отдельные «плохие» акторы или клиентские рабочие места.

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

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

Самоактуализация

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

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

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

Резюме

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

---

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

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

Зачем нужны целевые показатели качества обслуживания

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

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

• Вам может показаться, что достаточно сообщить о проценте запросов, которые были успешно обработаны разработанным вами API. Хорошо… но кто должен это сообщать? Сам API? Очевидно, это проблема: что случится, если балансировщики нагрузки откажут? А что произойдет, если система вернет ошибку 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, старый кабельный Интернет или плохие таблицы маршрутизаторов между их клиентом и вашим сервером? Могут ли они привлечь вас к ответственности?

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

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

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

Пять девяток?

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

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

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

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

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

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

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

Задержка

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

Задержка или время отклика?

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

Доступность

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

Пропускная способность

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

Надежность хранения

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

Стоимость — эффективность

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

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

•Новый сервис. Цели SLO определены. В более традиционных моделях это можно было бы назвать соглашениями на операционном уровне.

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

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

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

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

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

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

Показатели задержки

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

Почему так важна задержка

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