Dictionary

Что означают сервисы и данные в контексте отказоустойчивости на основе репликации?

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

Сервисы (Services)

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

Данные (Data)

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

Пример

Представь, что у тебя есть онлайн-магазин.

• Сервисы: Веб-сайт магазина и база данных с информацией о товарах — это сервисы. Если веб-сайт или база данных выйдут из строя, их реплики (дублирующие сервисы) смогут продолжать обслуживать запросы пользователей.

• Данные: Информация о товарах, заказах и клиентах — это данные. Эти данные хранятся в базе данных. Репликация данных означает, что у тебя есть несколько копий этой базы данных в разных местах. Если одно из хранилищ выйдет из строя, данные не будут потеряны, так как есть другие копии, которые могут использоваться.

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

Почему при строгой согласованности данные обновляются синхронно?

Строгая согласованность (Strong Consistency)

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

Синхронное обновление (Synchronous Update)

Когда система требует строгой согласованности, необходимо обновлять данные синхронно, потому что:

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

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

Почему не асинхронно?

Асинхронное обновление (Asynchronous Update) предполагает, что данные сначала обновляются в одной реплике, а другие реплики могут обновляться позже, когда это станет возможным. В этом случае может возникнуть ситуация, когда разные реплики будут иметь разные версии данных на протяжении некоторого времени, что нарушает строгую согласованность. Такая модель используется для достижения eventual consistency (постепенной согласованности), где система допускает временные несоответствия между репликами, но гарантирует, что все реплики в конечном итоге будут согласованы.

Компромисс между согласованностью и доступностью

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

DAU в качестве прокси

Используя DAU (Daily Active Users) в качестве прокси для пикового времени означает, что мы берем число ежедневно активных пользователей (DAU) и предполагаем, что все эти пользователи отправляют свои запросы одновременно в одну и ту же секунду в течение дня.

Прокси здесь означает "заместитель" или "приближенная оценка". Мы используем DAU в качестве замены для оценки максимальной возможной нагрузки (пиковой нагрузки) на систему в любой момент времени. Таким образом, DAU становится не просто показателем ежедневной активности пользователей, но и приближенной оценкой количества запросов в секунду, которые система может получить в самый загруженный момент.

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

Локальные балансировщики нагрузки (LB)

Локальные балансировщики нагрузки (LB) располагаются внутри дата-центра и играют роль посредника между клиентами и серверами. Они работают как обратный прокси-сервер, что означает, что LB принимает запросы от клиентов, а затем перенаправляет их на один из доступных серверов в пуле. Таким образом, LB помогает распределить нагрузку равномерно, чтобы ни один сервер не был перегружен.

Когда клиенты отправляют запросы, они направляются на виртуальный IP-адрес (VIP), который ассоциируется с LB. LB принимает эти запросы и затем определяет, какой сервер в пуле лучше всего обработает запрос на основе различных факторов, таких как текущая нагрузка на серверы, их доступность и так далее. Это обеспечивает эффективное распределение запросов и улучшает производительность всей системы.

Кворум — это минимальное количество членов, которые должны присутствовать на встрече, чтобы считать её действия действительными.

Кворум в распределённых системах

Кворум — это широко используемая концепция в распределённых системах. Для многих стандартных алгоритмов идея кворума используется для принятия решений.

Давайте разберём концепцию кворума с помощью диаграммы.

Пример:

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

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

Проблема разделённого мозга (split brain) в распределённых системах

Сетевое разделение является неотъемлемой частью любой распределённой системы, и система, которая заявляет о своей распределённости, должна также быть устойчива к разделению. То есть в случае сетевого разделения система должна продолжать работать.

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

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

Заключение

Кворум используется практически во всех алгоритмах, основанных на консенсусе, в распределённых системах. Raft является одним из известных алгоритмов консенсуса, который использует кворум в основе своей логики.

Что такое API сервера? Как они связаны с EC2?

EC2 (Amazon Elastic Compute Cloud) сервер сам по себе не является API сервером, но он может быть настроен для выполнения функций API сервера.

EC2 — это сервис от Amazon Web Services (AWS), который предоставляет виртуальные серверы в облаке. Когда вы создаете EC2-инстанс, вы получаете виртуальную машину, на которой можете установить операционную систему, настроить серверное программное обеспечение и развернуть свои приложения, включая API серверы для обработки end-points.

API сервер — это сервер, который обрабатывает запросы API и предоставляет данные или выполняет операции по запросам клиентов (например, веб-приложений или мобильных приложений). Если вы настроите на EC2-инстансе серверное ПО, например, Node.js, Python Flask, Java Spring или любой другой фреймворк, который предоставляет API, то этот EC2-инстанс может функционировать как API сервер.

В резюме: EC2 — это инфраструктура (сервер), а API сервер — это программное обеспечение, которое может быть запущено на этом сервере.