@Sazoks

Правильно ли я понял свойства распределенных систем?

Осторожно, много букв!

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

Свойства
  1. Масштабируемость
    Одно из главных свойств распределенных систем, т.к. у каждой системы есть пользователи. С течением времени, если проект успешен, кол-во пользователей будет расти. Следовательно, будет расти нагрузка (входящий трафик). Поэтому важно проектировать систему так, чтобы мы могли увеличивать производительность системы пропорционально добавляемым ресурсам. Здесь в принципе все понятно.
  2. Доступность
    Здесь уже появляется неоднозначность.
    • Доступность (CAP). Каждый запрос к системе завершается откликом, но без гарантии, что данные являются самыми актуальными.
    • Высокая доступность (HA). Это описание мне нравится больше, т.к. оно менее абстрактное и более приближено к реальности. Грубо говоря, это значение в %, характеризующее вероятность доступности системы в произвольный момент времени. Вычисляется по весьма простой формуле: Доступность (%) = (1 - MTTR / MTBF)*100, где MTTR (Mean time to repair) - среднее время ремонта после отказа (в год), MTBF (Mean time between failure) - среднее время между отказами (в год)

    В общем, если исходить из второго определения, то все становится понятно. Чем меньше % доступности, скажем, в год, тем хуже сервис, пользователи уходят, бизнес теряет деньги. Тут кстати вопрос: под отказом имеется в виду отказ вообще всей системы или только какой-то части?
    А с доступностью из CAP вообще непонятно. Например, если взять компромисс между Availability и Consistency на примере какого-нибудь кластера. Вот мы делаем запись в какой-то узел и хотим получить ответ, что запись добавилась. Но мы будем ждать, пока эта запись не продублируется во все другие узлы и они не подтвердят, что сохранили себе запись. По идее, здесь мы поддерживаем согласованность, жертвуя.. доступностью? Но ведь нет же! Мы все равно получим ответ. Определение доступности из CAP вообще ничего не говорит про задержку (latency). Выходит, что мы жертвуем не доступность, а чем-то другим? В общем, мне очень не нравится формулировка из CAP, но в целом я понимаю смысл и посыл, заложенный в этой теореме. Хотелось бы как-то разобраться именно в формулировках.
  3. Отказоустойчивость
    Next level доступности. Система не допускает простоя в принципе и каждый компонент проектируется с этим расчетом. Т.к. каждый компонент в системе способен продолжать работать и нормально функционировать, даже если "под капотом" отвалится какой-то сервис, сгорит диск и так далее. В большинстве случаев это обеспечивается за счет избыточности (как в случае и с надежностью, в принципе).
  4. Надежность
    Для меня надежность включает следующие аспекты:
    • Корректность. Пользователь должен быть уверен, что получит корректный ответ на свой запрос. Если пользователь через раз будет получать на запрос 2+2 ответ 5, с сервисом явно что-то не так, доверия к нему нет. Т.е. пользователь должен быть уверен, что он может положиться на систему.
    • Конфиденциальность. Пользователь уверен, что данные из системы не утекут.
    • Сохранность. Пользователь уверен, что данные надежно сохранены в системе и не потеряются (что-то вроде durability из ACID).

  5. Управляемость
    Это свойство влияет напрямую на доступность. Если система сложная, плохо настроен мониторинг (логи, трейсы, алерты), нет или просто неудобные инструменты для управления инфраструктурой, все это будет отнимать время на ремонт в случае отказа.
  6. Производительность
    Если брать производительность какого-то эндпоинта, то тут все понятно: это просто время обработки одного запроса. Можно провести небольшое тестирование, собрать метрику по этому эндпоинту, взять среднее арифметическое и вот тебе производительность для конкретно этого эндпоинта. Здесь вопрос в том, как мерить общую производительность сервиса? Брать среднюю производительность по всем эндпоинтам? Но тогда мы не учитываем интенсивность запросов к каждому эндпоинту, ведь может быть такое, что на один эндпоинт 100rps, а на другой 2rpm.
    В целом, производительность можно увеличить, сменив ЯП, масштабировав вертикально, снизив кол-во синхронных запросов к другим сервисам, оптимизировав код.
  7. Пропускная способность
    Согласно википедии - кол-во обрабатываемых единиц за единицу времени. Если, допустим, производительность у нас 0.33(3) секунды (т.е. 1 запрос за 0.33(3) секунды), тогда пропускная способность (умножаем числитель и знаменатель на 3) будет равна 3 запрос за 1 секунду, т.е. 3rps. Выходит, пропускная способность напрямую зависит от производительности. Пропускную способность можно увеличить, распараллелив обработку (горизонтальное масштабирование или процессы и потоки в рамках одного сервиса).
  8. Задержка
    На задержка напрямую зависит от пропускной способности (производительности) и канала связи. Чем ближе сервер к пользователю, тем меньше задержка.
  9. Стоимость
    Стоимость разработки, железа и поддержки. Зависит от сложности и масштаба системы.


Резюмируя вопросы:
  1. Допускает ли High Availability полный отказ системы или только отказ каких-то компонент с точки зрения функциональности, а не экземпляров?
  2. Какая правильная и полная формулировка Availability из CAP? Единственное, как я смог притянуть за уши с существующей формулировкой. Обеспечивая бОльшую согласованность мы выполняем больше операций и задержка увеличивается (синхронные запросы между сервисами, например). Если увеличивается задержка, то, в рамках сервиса, уменьшается его производительность (время обработки одного запроса). Уменьшается производительность - уменьшается пропускная способность, что в свою очередь может привести если не к отказу, то увеличению задержки у пользователя и, возможно, к потере сетевых пакетов. С точки зрения пользователя это уже отказ. Вот если это так, тогда вопросов к формулировке нет.
  3. Отказоустойчивая система не допускает потери функциональности вообще?
  4. Как, в двух словах хотя бы, проводится измерение производительности и пропускной способности сервиса?


Заранее спасибо.
  • Вопрос задан
  • 89 просмотров
Решения вопроса 2
vabka
@vabka
Токсичный шарпист
1. Ты запутался из-за того что ты смешал CAP с измеряемыми характеристиками (пропускная способность, доступность, итд)

Доступность
Здесь уже появляется неоднозначность.

Это примерно такая же неоднозначность, как в слове "замок".
Воспринимай это как разные слова из разных контекстов.
HA - это про малое количество сбоев, которые приводят к нулевой доступности.
A из CAP - это про сохранении доступности при выпадении узлов из кластера (если забыть про A, то можно сделать строго консистентную систему из нескольких узлов даже в случае потери связи между узлами - просто вся система будет отключаться)


По идее, здесь мы поддерживаем согласованность, жертвуя.. доступностью? Но ведь нет же! Мы все равно получим ответ.

Да, мы жертвуем доступностью, так как ответ мы не получим, если какой-то узел выпал из кластера => операция записи просто не будет выполнена.
Хотя в реальной жизни мы сразу получим ответ вида "запрос не может быть обработан. Почините кластер"
Пример такой системы - etcd, в которой ты заранее указываешь размер кластера и если кластер не может придти в состояние кворума (доступно N/2+1 узел, где N-количество узлов), то весь кластер переходит в аварийный режим без возможности чтения или записи.
Таким образом гарантируется консистентность даже на отвалившихся от кластера узлах.


Определение доступности из CAP вообще ничего не говорит про задержку (latency).

Потому что CAP не про это.


Резюмируя вопросы:


1. Просто читаем определение:

High availability (HA) is a system's capability to provide services to end users without going down for a specified period of time. High availability minimizes or (ideally) eliminates service downtime regardless of what incident the company runs into (a power outage, hardware failure, unresponsive apps, lost connection with the cloud provider, etc.).

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


Какая правильная и полная формулировка Availability из CAP?

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

доступность (англ. availability) — любой запрос к распределённой системе завершается откликом, однако без гарантии, что ответы всех узлов системы совпадают;

Любой запрос - любой запрос чтения или записи к любому из работающих узлов системы.
Завершается откликом - значит тебе дают какой-то ответ, который не является ошибкой.
Пример доступной, но не консистентной системы управления кадрами:
Запрос: "Какая зарплата у Иванова?"
Узел 1: 1000 долларов
Узел 2: две тысячи долларов
Узел 3: Иванов у нас не работает

Пример такой же системы, но в которой действует принцип консистентность:
Запрос: Иванов уволен?
Узел 1,2,3: Ошибка: кластер в аварийном режиме.
Либо:
Узел 1,2,3: Иванов не уволен.
Либо:
Узел 1,2: Иванов не уволен
Узел 3: Ошибка: отсутствует кворум.

Запрос: Уволить Иванова.
Узел 1,2,3: Ошибка: кластер в аварийном режиме. Доступно только чтение.
Либо:
Как в третьем варианте, если возможна запись при наличии кворума.


Единственное, как я смог притянуть за уши с существующей формулировкой.

CAP не про это.


Отказоустойчивая система не допускает потери функциональности вообще?

Пуленепробиваемое стекло не допускает пробития пулями вообще?)
В случае катастрофического отказа - возможно всё.


Как, в двух словах хотя бы, проводится измерение производительности и пропускной способности сервиса?

Два слова: нагрузочное тестирование.

Теперь все дополнения тут:

Конфиденциальность. Пользователь уверен, что данные из системы не утекут.

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


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

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


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

Я бы поспорил насчёт среднего арифметического )


Здесь вопрос в том, как мерить общую производительность сервиса?

Никак, ведь нет никакой "общей производительности".
Нагрузочное тестирование существует, но его проводят в профиле какой-то конкретной нагрузки/сценария.

Например в банковской системе могут проводить нагрузочную систему по нескольким сценариям:
1. "Чёрная пятница" - резко увеличивается количество карточных операций.
2. "Реклама у крупного блогера" - резко увеличилось количество запросов на выпуск новой карты. Нужно проверить, как вообще выдержит сервис, отвечающий за эмбоссинг.
3. "Экономике в стране «очень плохо»" - смотрим как выдержит клиринг при большом количестве межбанковских переводов.

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


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

Или добавив пакетную обработку.


На задержка напрямую зависит от пропускной способности (производительности) и канала связи. Чем ближе сервер к пользователю, тем меньше задержка.

А вот и нет.
У нас вполне может быть узкий канал с низкой задержкой или же широкий канал с большой задержкой.
А ещё задержка - это время обработки запроса твоей собственной системой.
Например твой сервис вполне может иметь большой latency, но и большой throughput и наоборот.
Ответ написан
AshBlade
@AshBlade
Просто хочу быть счастливым
Допускает ли High Availability полный отказ системы или только отказ каких-то компонент с точки зрения функциональности, а не экземпляров?

Доступность исчисляется относительно внешнего клиента - может или нет получить доступ к сервису. Здесь без разницы, что для этого используется кластеризация, бэкапы, стендбаи и т.д.
Главное - это то, как систему видит пользователь. Собственно, все SLA на так и рассчитываются.
Какая правильная и полная формулировка Availability из CAP?

На сколько я помню, эту теорему в свое время критиковали и продолжают за неясность определения. Но если в кратце, доступность здесь означает, что ты получишь ответ, даже если связь с другими узлами кластера пропадет. Если в кратце, доступность = можешь получить ответ хоть когда-нибудь.
Пример:
1. Есть кластер из 2 Postgres мастеров. Связь между ними пропадает и запросы они принимать не могут. Это НЕ Availability, т.к. нам важна консистентность
2. Если кластер из 2 Postgres узлов - мастер и слейв. Даже если связь между ними пропадет, то запросы они принимать смогут, но данные могут быть в не согласованном состоянии (мастер принял несколько UPDATE/INSERT/DELETE, а слейв о них не знает). Это Availability, но Consistency мы потеряли
3. Если кластер из 2 Mongo узлов. Там используется свой протокол, который позволяет системе быть доступной, даже если связь между мастерами потеряется. Это Availability, но согласованность может потеряться
P.S. в последнем используются специальные распределенные структуры данных (чтобы каждый узел мог модифицировать свою версию, а потом смержить с другими узлами)
Отказоустойчивая система не допускает потери функциональности вообще?

Отказоустойчивость - это не дискретная (0 или 1), а непрерывная характеристика. Здесь лучше думать в ключе SLA (99, 99.9, 99.999 т.д.), т.к. никакая система не может быть полностью отказоустойчивой. Но в целом да - отказоустойчивость значит, что функциональность должна работать и клиент может ее использовать.
Как, в двух словах хотя бы, проводится измерение производительности и пропускной способности сервиса?

1+ слово - тестирование (нагрузочное, объемное и т.д.)
Здесь нельзя вычислить формулами, сколько и что сможем обслужить. Только экспериментом числа получать.

UPD: если хочешь призму, чтобы смотреть на распределенные системы, то вот тут скачай "Распределенные системы" от Таненбаума - https://www.distributed-systems.net/index.php/book...
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы