Для важных платформ, ориентированных на клиента, высокая доступность — первоочередная задача. Однако доступность — постоянно движущаяся цель. Чем больше используется платформа, тем доступнее она должна быть, обеспечивая согласованную производительность и правильное выполнение задачи.
Я расскажу вам о стратегии дизайна, уникальной для платформ, требующих как высокой масштабируемости, так и высокой доступности. Эта стратегия проектирования предусматривает сокращение баз данных и устранение необходимости в их использовании.
Зачем оптимизировать базу данных
Базы данных являются необходимостью, когда дело касается архитектуры IT. С одной стороны, они обеспечивают постоянное хранение и извлечение данных — как больших, так и малых. С другой стороны, они становятся сложностью.
Одним из важных правил проектирования платформ высокой доступности является постоянная минимизация сложности. Сложности возникают в разных формах, которые часто создают большие проблемы.
Существует множество типов баз данных, каждая из которых уникальна. Их объединяет то, что они увеличивают сложность платформы. Давайте разберемся, как это происходит.
Операционные знания
Знание баз данных — общий навык в современном техническом мире, а администрирование и использование базы данных — дисциплина. Если платформа использует базу данных, которая требует высокой доступности, то на платформе должны быть инженеры, которые управляют базой данных и эффективно ее используют.
Для большинства платформ инженеры — не проблема. Достаточно нескольких экспертов по базам данных, так как их можно распределить на разные платформы. Однако в масштабе это более сложная задача.
Если платформа должна быть доступна, использование инженеров проблематично. Когда инженеры сосредоточены на нескольких платформах, они не фокусируются ни на одной из них, и решить проблемы становится сложнее. Что еще хуже, по мере масштабирования инженеры могут быть не в состоянии сосредоточиться на активных мерах по выявлению проблем до того, как они станут причинами простоев.
Часто инженеры закреплены за платформами, которые должны быть постоянно доступны. В таких случаях важно поддерживать базовый набор навыков в команде инженеров. Чем больше навыков требуется, тем сложнее поддерживать безопасный уровень эксплуатационных знаний.
Производительность
Другая сложность, создаваемая базами данных, — производительность самой базы данных. Когда платформа только создается, большое внимание уделяется повышению производительности. Иногда это означает настройку, а иногда база данных просто работает «из коробки» (в зависимости от используемой базы данных).
Если постоянно не держать во внимании необходимость измерения и настройки производительности базы данных, производительность в конечном итоге становится хуже. Кто-то может заметить эти изменения, а если нет, они, как правило, проявляются в виде эксплуатационных проблем.
Например, приложение начинает требовать больше времени для определенных запросов или, что еще хуже, запросы сбрасываются по истечении времени ожидания, а конечные пользователи больше не могут использовать эту услугу.
Такое очень часто случается. Можно преждевременно определять и предотвращать эти проблемы, но затем мы вернемся к базовому уровню операционных знаний и навыков.
Модернизация может требовать усилий
Модернизация базы данных производства может быть довольно трудной. В то время как некоторые базы данных требуют меньших усилий при обновлении, для большинства это очень сложный процесс. Независимо от того, нужно ли экспортировать или импортировать базу данных или время простоя, необходимое для обновления, эти виды деятельности очень утомительны, не способствуют автоматизации и в целом подвержены ошибкам.
Опытные инженеры смогут предотвратить ошибки, однако это отвлечет квалифицированных специалистов от других задач, которые могут быть более значимыми.
Репликация данных и отказоустойчивость
Устойчивость данных — самый сложный аспект работы с высокодоступной платформой. Это верно, говорим ли мы о базах данных или о любой другой системе хранения данных.
Хотя существует несколько новых баз данных с открытым исходным кодом, которые интегрировали репликацию данных в базовый продукт. Репликация всегда влекла значительные затраты на обслуживание и мониторинг.
Один из сложных аспектов репликации данных — общее время автоматического перехода на другой ресурс (необходимость для многих платформ высокой доступности) и синхронизация данных. Если вы используете стратегию асинхронной репликации данных с автоматическим отказоустойчивым приложением, можно использовать трафик приложения во вторичной системе до того, как данные будут доступны.
С другой стороны, синхронная репликация данных привносит в повседневную работу свой набор проблем. Резервные копии — еще одна трудность. При вводе резервных копий нужно их протестировать, а после поддерживать так же, как и любой другой компонент платформы.
Сокращение сложности за счет сокращения использования базы данных
Важно помнить, что чем сложнее платформа, тем сложнее поддерживать доступность.
Во многих случаях высокая доступность — это сложность. Иногда приходится осложнять приложение для обеспечения высокой доступности платформы. Ключ к снижению сложности — поиск возможных компромиссов.
В этом суть философии базы данных. Если можно уменьшить сложность приложения, уменьшив потребность в базе данных, это принесет пользу платформе.
Чтобы решить эту проблему, давайте рассмотрим случай, в котором зависимость от баз данных может быть уменьшена или устранена.
Типичная реализация с высокой доступностью
Вариант использования, который мы рассмотрим, представляет собой базовый REST API, который обеспечивает функциональность конвертации валют. Этот тип REST API чрезвычайно распространен среди финансовых приложений.
Типичная реализация REST API, такой как эта, будет простым приложением с бэкендом базы данных. Не принимая во внимание потребность в высокой доступности для этого приложения, одного экземпляра приложения и одного экземпляра базы данных будет более чем достаточно (рисунок 1).
Рисунок 1
Однако при развертывании этого типа приложений в высокодоступной среде дизайн немного изменится, чтобы приложение было доступно в нескольких центрах обработки данных.
Рисунок 2
На рисунке 2 показано типичное активно-пассивное многосайтовое развертывание, где база данных находится на основном сайте и получает обновления и реплицированную базу данных на вторичном сайте. Этот тип развертывания является достаточно стандартным для обеспечения высокой доступности. Однако, добавив эту репликацию данных, мы добавили дополнительный слой к нашему дизайну.
Что произойдет, если эта репликация не удалась и необходим переход на вторичный сайт? Будет ли эта служба затем возвращать неверные результаты?
Перемещение БД вниз по стеку
Репликация данных — одна из самых сложных задач, связанных с управлением базой данных. Одна из стратегий предотвращения проблем заключается в том, чтобы переместить сложность репликации данных и управления дальше в стек, добавив слои для компенсации отказа.
Рисунок 3
На рисунке 3 показан другой подход к многосайтовому развертыванию. В этой реализации есть два основных компонента: приложение и API данных.
Вместо того чтобы напрямую обращаться к базе данных, приложение периодически вызывает службу API данных для получения их и самых больших данных валютного преобразования. Поскольку этот тип данных, как правило, мал по объему, приложение может просто хранить возвращенные данные в памяти в течение заранее определенного временного интервала.
При таком подходе тонкости взаимодействия с базой данных и управления ими переносятся на уровень API данных, позволяя приложению свободно сосредоточиться на выполнении преобразования валюты. Если уровень API данных или база данных должны были снизиться, используя эту стратегию, конечный пользователь не испытал бы никакого влияния. Поскольку приложение использует данные валютного преобразования в памяти, можно сохранить основную функцию приложения доступной, пока база данных и уровень API данных недоступны.
С помощью этой стратегии устранять необходимость в базе данных не обязательно. Скорее, стратегия является единой системой, которая делает работу с платформой менее рискованной.
Устранить репликацию
Другим методом уменьшения сложностей, возникающих при репликации данных, является перенос методологии репликации данных из самой базы данных (рисунок 4).
Рисунок 4
Во многих случаях данные валютного преобразования предоставляются из внешних источников. Конвертация валют редко происходит локально. На рисунке 4 показана расширенная версия многосайтового развертывания. Однако она отличается тем, что в ней нет репликации данных.
Простая стратегия для приложений — отделение каждого экземпляра приложения друг от друга.
Эта концепция работает с API конверсии валют, полагаясь на каждый экземпляр приложения для запроса или получения актуальных данных конвертации валют и хранения данных в изолированном экземпляре базы данных. Поскольку каждый экземпляр делает это самостоятельно, нет необходимости реплицировать данные на уровне базы данных. Этот тип архитектуры полезен для приложений, которые выполняют в основном операции чтения. Операции чтения будут иметь преимущество в производительности благодаря наличию базы данных, локализованной для каждого экземпляра приложения.
Единственный минус этой стратегии в том, что иногда экземпляр приложения может возвращать различную информацию. Это можно предотвратить, включив проверки и противовесы в архитектуру приложения.
С помощью такой стратегии можно упростить управление репликацией базы данных, но при этом будет осложнена другая область.
Нет базы данных
Этот метод похож на архитектуру базы данных без разделения ресурсов, за исключением того, что она на шаг впереди. Если данные пересчета валют собираются независимо каждым экземпляром приложения, почему бы просто не хранить эти данные в памяти, а не в базе данных? Это позволило бы полностью исключить необходимость в базе данных (рисунок 5).
Рисунок 5
Эта стратегия популярна среди приложений с низким значением задержки. Такие типы приложений часто измеряются временем отклика. Получая данные прямо из памяти, приложение с малой задержкой может сохранять десятки или даже сотни миллисекунд, устраняя вызовы сети и базы данных.
Другим преимуществом такого подхода является то, что он масштабируется горизонтально. Чем меньше зависимость от приложения в других системах, тем лучше она может масштабироваться для удовлетворения требований масштабируемости. Без базы данных API может масштабироваться просто за счет увеличения количества экземпляров приложений.
Хотя эта стратегия имеет наименьшую сложность, ее трудно реализовать. Она работает с простым API конверсии валют, потому что данные валютного преобразования генерируются вне приложения. Оно просто используется и распространяется. Даже с помощью простого примера API можно увидеть, что этот подход имеет несколько проблем.
Например, всякий раз, когда процесс перезапускается, приложение сначала вспоминает данные конвертации валюты для хранения в памяти. Это может быть проблематично, если источник данных недоступен после перезапуска приложения. С этой стратегией важно обеспечить минимальное количество экземпляров приложений, которые всегда доступны, и учитывать возможность отсутствия источников данных в течение длительного периода времени.
Поскольку эта стратегия не полагается на базу данных, она не подходит для каждого приложения. Приложения, которые генерируют уникальные данные и предоставляют данные через API, не смогут реализовать стратегию без базы данных.
Вывод
Инженеры склонны обесценивать стратегии, которые уникальны для одной платформы. При разработке важных систем, требующих высокой доступности, важно думать за пределами традиционной архитектуры IT-архитектуры.
В случае примера с конвертацией валют мы можем уменьшить сложность приложения, ставя под сомнение необходимость в базе данных. Дополнительным преимуществом удаления базы данных является то, что мы также можем распространять входящие запросы в нескольких центрах обработки данных. Таким образом, мы уменьшаем не только сложность управления нашей средой, но и сложность управления автоматическим отказоустойчивостью или аварийным восстановлением.
Однако, как и в любом случае, реализация этих стратегий сопряжена с компромиссами. То, что работает на одной платформе, может не соответствовать другой. Иногда эти проблемы являются не технологическими, а реализационными.
Наша цель состоит не в том, чтобы обязательно исключить все базы данных, а в том, чтобы решить, действительно ли база данных необходима для платформы.
Не используйте базы данных, если они не требуются.