Здравствуйте, Sinclair, Вы писали:

CK>>Мне не нужно от лога к availability переходить, у меня есть мониторинг, в котором это все считается.
S>)
S>1. А мониторинг как работает? Он не делает запросы?
S>2. Вы понимаете, что если мониторинг показывает, что "всё ок", а клиент получает таймаут, то прав клиент, а не мониторинг? Ну, и наоборот — тоже?

В нашем случае используется black-box мониторинг, который работает отдельно от основной инфраструктуры, в нескольких георграфически удаленных регионах, он делает запросы в API и измеряет время отклика. Если заданное количество агентов не получили ответ от сервиса, или получили, но с превышением таймаута, заданного в SLA, поднимается alert, регистрируется начал инцедента. Когда все агенты снова получили ответ, генерируется новый alert и регистрируется окончание инцидента. Есть метрика в графане, которая по этим данным рисует доступность.
Это довольно распространенное решение, datadog и alertra считают availability похожим образом.

S>Мне кажется смешным такая вот бескомпромиссная трактовка Availability. Реальные системы запросто жертвуют доступом к части данных, продолжая работать с тем, что есть.

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

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

Aviasales это агрегатор, поставщик — сторонний вендор, а не часть системы. Хорошим примером ялвяется приложение такси. Представь, что у яндекса накрылся один ДЦ и 1/(количество Дц) клиентов не может использовать сервис, и такая же доля водителей не может принимать и завершать заказы. В результате, компания несет миллионы рублей убытков.

То, о чем ты говоришь, называется graceful service degradation. Хорошая вещь, но в качестве дополнения, а не как единственное поведение в случае проблем.

CK>>1. да, имеет смысл обрабатывать специальным образом
CK>>2. делать недоступной всю систему тоже делать не стоит
CK>>3. делать независимую систему на каждый регион, объясняя это какими-то своими домыслами — неправильно
CK>>4. если решишь подумать, как можно добиться 1. и 2. без 3., то тебе вероятно понадобится САР в твоих рассуждениях
S>Опять косвенные соображения. Мы дождёмся примера применения CAP в рассуждениях архитектора системы? Пока что получается так, что все содержательные мысли образуются без помощи CAP.

Я не могу сделать эти шаги за тебя. Попробуй DDIA прочитать более внимательно что-ли.

Здравствуйте, Sinclair, Вы писали:

CK>>Мне не нужно от лога к availability переходить, у меня есть мониторинг, в котором это все считается.
S>)
S>1. А мониторинг как работает? Он не делает запросы?
S>2. Вы понимаете, что если мониторинг показывает, что "всё ок", а клиент получает таймаут, то прав клиент, а не мониторинг? Ну, и наоборот — тоже?

В нашем случае используется black-box мониторинг, который работает отдельно от основной инфраструктуры, в нескольких георграфически удаленных регионах, он делает запросы в API и измеряет время отклика. Если заданное количество агентов не получили ответ от сервиса, или получили, но с превышением таймаута, заданного в SLA, поднимается alert, регистрируется начал инцедента. Когда все агенты снова получили ответ, генерируется новый alert и регистрируется окончание инцидента. Есть метрика в графане, которая по этим данным рисует доступность.
Это довольно распространенное решение, datadog и alertra считают availability похожим образом.

S>Мне кажется смешным такая вот бескомпромиссная трактовка Availability. Реальные системы запросто жертвуют доступом к части данных, продолжая работать с тем, что есть.

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

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

Aviasales это агрегатор, поставщик — сторонний вендор, а не часть системы. Хорошим примером ялвяется приложение такси. Представь, что у яндекс.такси накрылся один ДЦ и 1/(количество Дц) клиентов не может использовать сервис, и такая же доля водителей не может принимать и завершать заказы. В результате, компания несет миллионы рублей убытков.

То, о чем ты говоришь, называется graceful service degradation. Хорошая вещь, но в качестве дополнения, а не как единственное поведение в случае проблем.

CK>>1. да, имеет смысл обрабатывать специальным образом
CK>>2. делать недоступной всю систему тоже делать не стоит
CK>>3. делать независимую систему на каждый регион, объясняя это какими-то своими домыслами — неправильно
CK>>4. если решишь подумать, как можно добиться 1. и 2. без 3., то тебе вероятно понадобится САР в твоих рассуждениях
S>Опять косвенные соображения. Мы дождёмся примера применения CAP в рассуждениях архитектора системы? Пока что получается так, что все содержательные мысли образуются без помощи CAP.

Я не могу сделать эти шаги за тебя. Попробуй DDIA прочитать более внимательно что-ли.