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

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

S>>Согласен. Но даже получить availability "такую же, как у Data Center" — вполне неплохое достижение для приложения.

CK>чтобы было так же, как у ДЦ, нужно чтобы твое приложение работало вообще без отказов, я слабо представляю как такое возможно

CK>бес попутал, availability конечно
Общепринятое понимание термина availability — это процент успешно выполненных запросов. Если у меня недоступно 1% диапазона ключей, то (в предположении равномерного распределения запрашиваемых данных) availability системы равна 99%.
Эта неожиданная на первый взгляд трактовка как раз и лежит, в частности, в основе географического сегментирования — когда теряется связь с удалёнными узлами, я всё ещё могу работать с локальными данными. Это гораздо лучше, чем полный отказ в обслуживании.

CK>Я про "с т.з. CAP, все CP системы одинаково бесполезны". САР вообще про полезность ничего не говорит, кмк. Не очень понятно как можно вывод о бесполезности из нее сделать.
Полезность — это уже бизнес-интерпретация свойства availability. С точки зрения CAP нет никакой разницы между системами с availability в 90% и в 99.999% — обе не являются available. "Вы пожертвовали availability". Тот факт, что availability в 5 девяток — запредельная для прикладного сервиса величина, теорему никак не меняет.

CK>Ну дык, ты же сам писал — "А с точки зрения инженерной (и бизнеса) availability в 1 девятку очень сильно отличается от availability в 5 девяток", то бишь если с точки зрения бизнеса, нужно иметь пять девяток, то тебе нужно в multidatacenter setup, если бизнес хочет гео-распределенность, ради низкой latency, тоже самое. Требования к системе диктуют tradeoff-ы, которые ты можешь использовать. Поэтому докозательство в духе — вот СР система, которая может в HA, поэтому на практике она ничем не уступает AP системам, по крайней мере с точки зрения пользователя — не работает. Уступает.
Кто сказал "ничем не уступает"??? Чтобы понять, кто кому уступает, надо сначала сравнить реальные показатели consistency и availability.
Ещё раз повторю очевидную мысль: CAP теорема не даёт нам никакого базиса для сравнения систем с различным количеством девяток — просто потому, что в её определении availability нет никаких девяток.
Поэтому я не вполне понимаю, как можно без лукавства привлекать эту теорему для обоснования каких-либо решений. Вот вы приходите ко мне, и говорите: "я предлагаю сделать вот такую AP систему, потому что CAP не даёт нам возможности получить CAP-систему". А я вам отвечаю: "ок, то есть ваша система — она прямо вся такая A, несмотря ни на какие P"? Вы мне: "ой, нет, DC, в котором она развернута, даёт A=99.95%". Тогда я вам говорю: "а нахрена вы мне приносите P-систему, в которой нет ни A ни С? Давайте вы лучше мне сделаете CP-систему, которая имеет A в 99.9%. 0.05% сожрал DC, я даю вам ещё 0.05% A на обеспечение С".

Боюсь, что после этого вам придётся свернуть CAP-теорему в трубочку и заняться реальной service reliability engineering работой.

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

S>Общепринятое понимание термина availability — это процент успешно выполненных запросов. Если у меня недоступно 1% диапазона ключей, то (в предположении равномерного распределения запрашиваемых данных) availability системы равна 99%.

Общепринятое определение availability — количество времени, которое система (либо ее часть) была недоступна.

(525600 − M) ÷ 525600 (где М — время простоя в минутах)

5 минут простоя — пять девяток
60 минут простоя — четыре, итд

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

ты это как-то по особенному понимаешь, при "географическом сегментировании" я хочу иметь доступ ко всем данным, даже если один дц недоступен

S>Полезность — это уже бизнес-интерпретация свойства availability. С точки зрения CAP нет никакой разницы между системами с availability в 90% и в 99.999% — обе не являются available. "Вы пожертвовали availability". Тот факт, что availability в 5 девяток — запредельная для прикладного сервиса величина, теорему никак не меняет.

availability из CAP не имзеряется в девятках, ты это понимаешь, о чем тогда спор?

S>Ещё раз повторю очевидную мысль: CAP теорема не даёт нам никакого базиса для сравнения систем с различным количеством девяток — просто потому, что в её определении availability нет никаких девяток.

с этим я изначально и не спорил

S>Поэтому я не вполне понимаю, как можно без лукавства привлекать эту теорему для обоснования каких-либо решений. Вот вы приходите ко мне, и говорите: "я предлагаю сделать вот такую AP систему, потому что CAP не даёт нам возможности получить CAP-систему". А я вам отвечаю: "ок, то есть ваша система — она прямо вся такая A, несмотря ни на какие P"? Вы мне: "ой, нет, DC, в котором она развернута, даёт A=99.95%". Тогда я вам говорю: "а нахрена вы мне приносите P-систему, в которой нет ни A ни С? Давайте вы лучше мне сделаете CP-систему, которая имеет A в 99.9%. 0.05% сожрал DC, я даю вам ещё 0.05% A на обеспечение С".

опять заворачивание всего в один юзкейс?

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

или вот такой — наш интернет магазин доставляет товары в ЮВА, Европе и Америке, сделай так, чтобы данные хранились и обрабатывались как можно ближе к пользователю

S>Боюсь, что после этого вам придётся свернуть CAP-теорему в трубочку и заняться реальной service reliability engineering работой.

Бедные SRE то тут причем?

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

MA>твой хваленый Raft видимо нихера не работает.

Хочешь обсудить Рафт? Давай обсудим. Итак, когда он не работает?

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

DI>>Во-первых, про роутер ты в своей архитектуре ты ничего не говорил, пока я не указал, что он нужен.
S>Вы как-то ловко подменяете задачу.

И что я подменил?

S>Началось всё, напомню, с вашего безапелляционного заявления о том, что failover cluster невозможно масштабировать.

И это так.

S>Вам показали, как именно его можно масштабировать.

Нет, не показали.

S>Речи о том, что failover cluster — это серебряная пуля, или обязательства нарисовать полную архитектуру, которая обеспечивает CAP для произвольно придуманной прикладной задачи, не было.

Дал заднюю.

DI>>Во-вторых, ссылку то дай, а то пока твое слово против моего и не я должен опровергать, что в книге нет, а ты доказывать. В-третьих, дай-то уж нормальное описание предлагаемой тобой архитектуры, а то пока ты только что-то туманное вбросил.
S>Эти вопросы освещены в главе 6, Partitioning. Страницы с 209 по 216.

Обсуждение есть, а подтверждения твоим словам нет.

S>Все поставленные вами задачи сводятся к rebalancing partitions. Я вам написал пошаговый сценарий перевоза шарда с одной ноды на другую.
S>>>Чем вас не устраивает Raft или модификации Paxos?
DI>>Подожди, давай ты сначала покажешь масштабируемую архитектуру обеспечивающую доступность и консистентность. Пока почему-то ты просто скипаешь мои аргументы.
S>Мне неизвестна единая архитектура, обеспечивающая CAP для произвольного масштаба, и пригодная для произвольной прикладной задачи.

Все? Ожидаемо оказался заборот САР, "чистый шардинг" сдулся. Ну и стоило ли упрямствовать?

S>В целом, направление разработки — именно такое: шардинг + репликация; линки различной степени надёжности для локальных и для глобальных коммуникаций; консенсус для обеспечения C и A (как, например, в SQL Azure, где коммит требует "2 из 3"). Для роутинга выбираются более консервативные алгоритмы консенсуса, т.к. там можно оптимизироваться для "mostly read" нагрузки, и потеря availability в операциях записи нам не так страшна.

Ок

Здравствуйте, chaotic-kotik, Вы писали:
CK>Общепринятое определение availability — количество времени, которое система (либо ее часть) была недоступна.
CK>(525600 − M) ÷ 525600 (где М — время простоя в минутах)
Во-первых, наоборот. Время, когда система была доступна.
Во-вторых, про период ровно в год — это вы взяли один пример, и думаете, что он и есть определение. Очевидно, что он неверный — система, пролежавшая полтора года, по вашей формуле имеет availability равную (-50%).
В-третьих, этот подход (время доступности) — это упрощение, изначально предложенное для систем непрерывного действия (например, электростанций).
Когда мы говорим о программных системах, вообще разговор о "mission capable" не имеет смысла, пока у нас нет входящих запросов. В принципе нет никакого способа отличить рабочую систему от нерабочей, не присылая ей запросов.
Именно на этом построена идея накатывать апдейты во время низкой нагрузки — это позволяет улучшить availability.
Рассуждать об availability распределённой системы как о возможности исполнить любой запрос не имеет смысла — с этой точки зрения, availability системы DNS равна нулю, т.к. в каждый момент времени какой-то из сотен тысяч участвующих в ней серверов обязательно лежит. Работоспособность системы построена как раз на том, что большинство отправляемых запросов таки достигают рабочих серверов; доля запросов, упирающихся в сломанный DNS, относительно мала.

CK>ты это как-то по особенному понимаешь, при "географическом сегментировании" я хочу иметь доступ ко всем данным, даже если один дц недоступен
Ничего особенного в этом нет. Ваше наивное желание не соответствует реальным бизнес требованиям. Не бывает так, чтобы доступ ко всем данным имел одинаковый приоритет; и даже в этом частном случае любой заказчик предпочтёт при сбое иметь доступ к части данных, чем не иметь его вовсе.

CK>availability из CAP не имзеряется в девятках, ты это понимаешь, о чем тогда спор?
О практической применимости CAP.

CK>опять заворачивание всего в один юзкейс?
Это попытка объяснить, что даже тот юзкейс, для которого потенциально можно было бы применить CAP, не работает.
CK>вот тебе другой юзкейс, один поисковик собирает клики пользователей и записывает их в распределенное хранилище, данных прилетает примерно петабайт в день, консистентность не нужна
Не очень понятно, что вы тут называете "консистентностью", и что — "доступностью" И тем не менее — каким образом CAP поможет нам принять какое-то решение в этом случае?
Что такого умного вы сможете сделать, зная CAP, чего вы не могли бы, не имея доказательства CAP?

CK>или вот такой — наш интернет магазин доставляет товары в ЮВА, Европе и Америке, сделай так, чтобы данные хранились и обрабатывались как можно ближе к пользователю
Ок, опять. Что такое "как можно ближе к пользователю"? Тут, конечно, интуитивно понятно, что хочется иметь консистентность на уровне хотя бы "размещённые заказы не теряются", и availability на приемлемом уровне (например, три девятки).
Мотивацией для "ближе к пользователю" могут быть два совершенно разных фактора: один — это response times, которым в современном веб-магазине обычно можно пренебречь, второй — это как раз та самая availability, которую вы отказываетесь понимать. В том смысле, что пользователю из Китая будет совершенно безразлично, что он прямо сейчас не может заказать доставку в Нидерланды, ему важно смочь заказать доставку в своём же регионе.
Т.е. падение связи между серверами Европы и ЮВА имеет смысл обрабатывать специальным образом, а не делать недоступной всю систему. Основой этих рассуждений является понимание того, что заказы на доставку в Китай с клиентским IP в Европе — редкость, как и наоборот; поэтому их сбои меньше влияют на общую Availability.


В вашем пониманиии "общепринятой трактовки надёжности" подобным рассуждениям места нет:

при "географическом сегментировании" я хочу иметь доступ ко всем данным, даже если один дц недоступен

S>>Боюсь, что после этого вам придётся свернуть CAP-теорему в трубочку и заняться реальной service reliability engineering работой.
CK>Бедные SRE то тут причем?
При том, что именно они занимаются вопросами настоящей availability, а не той чуши, которая использована в CAP.

Здравствуйте, Denis Ivlev, Вы писали:
DI>И что я подменил?
С вопроса "принципы масштабирования failover cluster" мы переходим к вопросу разработки всеобъемлющей архитектуры с неизвестными заранее требованиями по масштабу, временам отклика, надёжности, и функциональности.
DI>И это так.
DI>Нет, не показали.
Ну, то есть вся ветка была напрасной.
DI>Обсуждение есть, а подтверждения твоим словам нет.
DI>Все? Ожидаемо оказался заборот САР, "чистый шардинг" сдулся. Ну и стоило ли упрямствовать?
Если вас интересует математическое обоснование построения CAP-системы, то лучше всего почитать работу про совмещение real-time causal consistency с always-on availability. Это гораздо более интересный результат, чем CAP.

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

CK>>Общепринятое определение availability — количество времени, которое система (либо ее часть) была недоступна.
CK>>(525600 − M) ÷ 525600 (где М — время простоя в минутах)
S>Во-первых, наоборот. Время, когда система была доступна.

временной интервал (год, месяц, неделя) минус суммарная продолжительность всех инцидентов, приведших к недоступности сервиса, на этом интервале времени, будешь с этим спорить?

S>Во-вторых, про период ровно в год — это вы взяли один пример, и думаете, что он и есть определение. Очевидно, что он неверный — система, пролежавшая полтора года, по вашей формуле имеет availability равную (-50%).

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

S>В-третьих, этот подход (время доступности) — это упрощение, изначально предложенное для систем непрерывного действия (например, электростанций).

И для сервисов, которые должны работать постоянно, в контексте дискуссии нас именно это интересует, ты сам начал рассуждать про "пять девяток", а теперь утверждаешь что это для электростанций :D

CK>>ты это как-то по особенному понимаешь, при "географическом сегментировании" я хочу иметь доступ ко всем данным, даже если один дц недоступен
S>Ничего особенного в этом нет. Ваше наивное желание не соответствует реальным бизнес требованиям. Не бывает так, чтобы доступ ко всем данным имел одинаковый приоритет; и даже в этом частном случае любой заказчик предпочтёт при сбое иметь доступ к части данных, чем не иметь его вовсе.

Еще раз. Ты это _неправильно_ понимаешь. В АР системе, работающей в нескольких ДЦ, при сбое одного ДЦ, все данные будут доступны. Нормальной практикой является периодическое отключение ДЦ, в рамках тестирования боевой инфраструктуры на resiliency, например.

S>Это попытка объяснить, что даже тот юзкейс, для которого потенциально можно было бы применить CAP, не работает.
S>Что такого умного вы сможете сделать, зная CAP, чего вы не могли бы, не имея доказательства CAP?

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

CK>>или вот такой — наш интернет магазин доставляет товары в ЮВА, Европе и Америке, сделай так, чтобы данные хранились и обрабатывались как можно ближе к пользователю
S>Ок, опять. Что такое "как можно ближе к пользователю"? Тут, конечно, интуитивно понятно, что хочется иметь консистентность на уровне хотя бы "размещённые заказы не теряются", и availability на приемлемом уровне (например, три девятки).

"Ближе к пользователю", это когда у тебя есть три ДЦ, в каждом из которых крутится web frontend, который берет/кладет данные в Cassandra. Cassandra при этом крутится в каждом из этих ДЦ и в каждом из них есть копия всех данных. Недоступность одного из ДЦ не приводит к простою (все товары из БД доступны).

S>Мотивацией для "ближе к пользователю" могут быть два совершенно разных фактора: один — это response times, которым в современном веб-магазине обычно можно пренебречь, второй — это как раз та самая availability, которую вы отказываетесь понимать. В том смысле, что пользователю из Китая будет совершенно безразлично, что он прямо сейчас не может заказать доставку в Нидерланды, ему важно смочь заказать доставку в своём же регионе.

Это пишет человек, который всего несколько сообщений назад рассуждал про "требования бизнеса". У тебя чувак из Нидерландов может заказать что-нибудь в Китае, находясь при этом в Южной Америке. В данном случае, поддержка подобной распределенной архитектуры, это продуктовое решение.

Временем респонза в интернет магазине пренебречь нельзя. Особенно, если у этого магазина есть не только веб морда, но еще и мобильное приложение. Требования к latency в данном случае, это тоже решение продакта, а не программиста.

S>Т.е. падение связи между серверами Европы и ЮВА имеет смысл обрабатывать специальным образом, а не делать недоступной всю систему.

Для этого как раз пригодится САР.

Здравствуйте, chaotic-kotik, Вы писали:
CK>И для сервисов, которые должны работать постоянно, в контексте дискуссии нас именно это интересует, ты сам начал рассуждать про "пять девяток", а теперь утверждаешь что это для электростанций :D
Вот мы сидим и долбим какую-то систему ежесекундными запросами. Из них часть завершается успешно, часть падает с таймаутом или 503. (простейший пример — ping -t).
Каким образом вы от лога результатов перейдёте к "минутам" и "продолжительности инцидентов"? Ну, чтобы вычислить availability?

CK>Еще раз. Ты это _неправильно_ понимаешь. В АР системе, работающей в нескольких ДЦ, при сбое одного ДЦ, все данные будут доступны. Нормальной практикой является периодическое отключение ДЦ, в рамках тестирования боевой инфраструктуры на resiliency, например.


S>>Что такого умного вы сможете сделать, зная CAP, чего вы не могли бы, не имея доказательства CAP?

CK>С помощью CAP я могу понять, что у меня есть трэйдоф, я могу обеспечить целостность (linearizability) или доступность.
Не-не-не, вот эти все "я могу понять, что у меня есть трэйдоф" — не надо. Вы привели конкретный пример — покажите, как именно вы применяете CAP в решении задачи.

CK>"Ближе к пользователю", это когда у тебя есть три ДЦ, в каждом из которых крутится web frontend, который берет/кладет данные в Cassandra. Cassandra при этом крутится в каждом из этих ДЦ и в каждом из них есть копия всех данных. Недоступность одного из ДЦ не приводит к простою (все товары из БД доступны).
CK>Это пишет человек, который всего несколько сообщений назад рассуждал про "требования бизнеса". У тебя чувак из Нидерландов может заказать что-нибудь в Китае, находясь при этом в Южной Америке. В данном случае, поддержка подобной распределенной архитектуры, это продуктовое решение.
Ну так расскажите, зачем вам в этой задаче "ближе к пользователю". Если у вас именно продакт решает, сколько будет DC, то это очень странно. Может, он заодно и СУБД за разработчиков выберет, и ЯП?

CK>Временем респонза в интернет магазине пренебречь нельзя. Особенно, если у этого магазина есть не только веб морда, но еще и мобильное приложение. Требования к latency в данном случае, это тоже решение продакта, а не программиста.
Ну ок. Я, как продакт, пишу вам latency в пределах 2500мс. Вам уже очевидно, что в него укладываются раундтрипы через весь шарик и обратно?
CK>Для этого как раз пригодится САР.
Как именно? Ждём примера.

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

DI>>И что я подменил?
S>С вопроса "принципы масштабирования failover cluster" мы переходим к вопросу разработки всеобъемлющей архитектуры с неизвестными заранее требованиями по масштабу, временам отклика, надёжности, и функциональности.

Мы до этого еще не дошли, застряли на масштабировании failover cluster, ты как-то все время делаешь вид, будто вопрос закрыт и упорно игнорируешь мои доводы, что никакой масштабируемости там нет.

DI>>Все? Ожидаемо оказался заборот САР, "чистый шардинг" сдулся. Ну и стоило ли упрямствовать?
S>Если вас интересует математическое обоснование построения CAP-системы, то лучше всего почитать работу про совмещение real-time causal consistency с always-on availability. Это гораздо более интересный результат, чем CAP.

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

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

S>Вот мы сидим и долбим какую-то систему ежесекундными запросами. Из них часть завершается успешно, часть падает с таймаутом или 503. (простейший пример — ping -t).
S>Каким образом вы от лога результатов перейдёте к "минутам" и "продолжительности инцидентов"? Ну, чтобы вычислить availability?

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

CK>>Еще раз. Ты это _неправильно_ понимаешь. В АР системе, работающей в нескольких ДЦ, при сбое одного ДЦ, все данные будут доступны. Нормальной практикой является периодическое отключение ДЦ, в рамках тестирования боевой инфраструктуры на resiliency, например.
S>

Что именно тебе кажется смешным? Доступность данных при недоступности одного ДЦ или отключение ДЦ для тестирования?

CK>>Для этого как раз пригодится САР.
S>Как именно? Ждём примера.

это было ответом на

SS>Т.е. падение связи между серверами Европы и ЮВА имеет смысл обрабатывать специальным образом, а не делать недоступной всю систему. Основой этих рассуждений является понимание того, что заказы на доставку в Китай с клиентским IP в Европе — редкость, как и наоборот; поэтому их сбои меньше влияют на общую Availability.

1. да, имеет смысл обрабатывать специальным образом
2. делать недоступной всю систему тоже делать не стоит
3. делать независимую систему на каждый регион, объясняя это какими-то своими домыслами — неправильно
4. если решишь подумать, как можно добиться 1. и 2. без 3., то тебе вероятно понадобится САР в твоих рассуждениях

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

CK>временной интервал (год, месяц, неделя) минус суммарная продолжительность всех инцидентов, приведших к недоступности сервиса, на этом интервале времени, будешь с этим спорить?
У вас оно вводится как что-то апостериорное, что не позволяет его вычислять из характеристик компонентов системы.
Ок, предположим, что вы имели ввиду мат. ожидание. Тогда оно пересчитывается в вышеупомянутые девятки однозначным образом, т.е. определения (почти) эквивалетны.

CK>С помощью CAP я могу понять, что у меня есть трэйдоф, я могу обеспечить целостность (linearizability) или доступность. С появлением САР, люди поняли, что пространство возможных решений шире, что привело к созданию алтернативных дизайнов (NoSQL), которые жертвуют линеаризуемостью, но имеют другие интересные свойства. Собственно на этом полезность и заканчивается.
С появлением САР, люди поняли, что пространство возможных решений уже и невозможно одновремено иметь абсолютный С, абсолютный А и абсолютный Р.
(Кто бы спорил. В реальном мире их и по отдельности иметь нельзя.)
С появлением САР (некоторые) люди подумали, что можно не париться с С, т.к. он все равно не достижим, когда хочется А и Р.

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

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

CK>Что именно тебе кажется смешным? Доступность данных при недоступности одного ДЦ или отключение ДЦ для тестирования?
Мне кажется смешным такая вот бескомпромиссная трактовка Availability. Реальные системы запросто жертвуют доступом к части данных, продолжая работать с тем, что есть.
Вот, первое что в голову пришло — aviasales прекрасно продолжают отдавать результаты, даже если связь с одним из поставщиков временно нагибается.


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

Здравствуйте, 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 прочитать более внимательно что-ли.

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

CK>В нашем случае используется black-box мониторинг, который работает отдельно от основной инфраструктуры, в нескольких георграфически удаленных регионах, он делает запросы в API и измеряет время отклика.
Ну вот, то что я предлагаю, вид сбоку.
CK>Если заданное количество агентов не получили ответ от сервиса, или получили, но с превышением таймаута, заданного в SLA, поднимается alert, регистрируется начал инцедента. Когда все агенты снова получили ответ, генерируется новый alert и регистрируется окончание инцидента.
Ну, то есть пока падает меньше выбранного вами процента запросов, вы считаете, что система available.
CK>Есть метрика в графане, которая по этим данным рисует доступность.
CK>Это довольно распространенное решение, datadog и alertra считают availability похожим образом.
То, что вы рассказываете — это попытка получить приближение к "настоящей" формуле availability при отсутствии возможности её прямого измерения.
Когда мы проектируем систему, мы оперируем не black box availability, а предсказываем реальное поведение.
S>>Мне кажется смешным такая вот бескомпромиссная трактовка Availability. Реальные системы запросто жертвуют доступом к части данных, продолжая работать с тем, что есть.
CK>Еще раз, мне интересны распределенные системы в общем и распредленные БД в частности. Мне не очень интересны системы, где можно пожертвовать частью данных, такие как сайты с котиками и онлайн агрегаторы, торгующие авиабилетами. В контектсе баз данных, потеря 1/N данных, при отказе одного из N датацентров — неприемлема.
Нет никакой потери.
CK>Aviasales это агрегатор, поставщик — сторонний вендор, а не часть системы. Хорошим примером ялвяется приложение такси. Представь, что у яндекса накрылся один ДЦ и 1/(количество Дц) клиентов не может использовать сервис, и такая же доля водителей не может принимать и завершать заказы.
Во-первых, не 1/N. А 1/(N в большой степени), потому что тут не "DC накрылся", а произошёл network partition. В итоге клиенты из Новосибирска не могут вызвать такси в Москве. К счастью, таких запросов — 1 на миллион, поэтому почти никто не заметит потери. Нам важно дать возможность клиентам в Нске заказывать машину в Нске, а Москвичам — в Москве. Причины очевидны или надо разжёвывать?
Ну, и конечно же система, которая продолжает принимать заказы из Нска в Москву без гарантии их выполнения (нарушение консистентности) гораздо хуже системы, которая честно говорит "сервис заказа в данном городе временно недоступен, попробуйте позже".
CK>То, о чем ты говоришь, называется graceful service degradation. Хорошая вещь, но в качестве дополнения, а не как единственное поведение в случае проблем.
Речь не о единственности, а о том, какой показатель показывает хорошесть этой вещи. Опять таки, с точки зрения бескомпромиссной availability все эти изобретения бесполезны — они не улучшают измеряемый показатель.
Расскажите, какую именно метрику вы улучшаете при graceful degradation?

CK>Я не могу сделать эти шаги за тебя.
Попробуйте сделать их за себя. Пока что продемонстрировано не больше пользы от CAP, чем от иконы на приборной доске автомобиля.
CK>Попробуй DDIA прочитать более внимательно что-ли.
Я уже почитал. Особенно вдохновляет раздел The Unhelpful CAP Theorem.

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

S>Ну вот, то что я предлагаю, вид сбоку.
ты ничего конкретного пока не предложил

S>Ну, то есть пока падает меньше выбранного вами процента запросов, вы считаете, что система available.
я точно не помню что там SRE наворотили, скорее всего есть гистерезис небольшой (нужно несколько 500 подряд чтобы агент сагрился)

S>Когда мы проектируем систему, мы оперируем не black box availability, а предсказываем реальное поведение.
ты можешь посчитать availability зная MTTF каждого компонента системы, да
это не значит что не нужно измерять
в общем-то, ты спросил как имзерять, я ответил — "Каким образом вы от лога результатов перейдёте к "минутам" и "продолжительности инцидентов"? Ну, чтобы вычислить availability?"

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

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

S>Во-первых, не 1/N. А 1/(N в большой степени), потому что тут не "DC накрылся", а произошёл network partition. В итоге клиенты из Новосибирска не могут вызвать такси в Москве. К счастью, таких запросов — 1 на миллион, поэтому почти никто не заметит потери. Нам важно дать возможность клиентам в Нске заказывать машину в Нске, а Москвичам — в Москве. Причины очевидны или надо разжёвывать?

Почему ты думаешь что клиенты в Москве обслуживаются одним ДЦ? Я думаю процентов 50 клиентов ЯТакси, это Мск и СПб.

S>Ну, и конечно же система, которая продолжает принимать заказы из Нска в Москву без гарантии их выполнения (нарушение консистентности) гораздо хуже системы, которая честно говорит "сервис заказа в данном городе временно недоступен, попробуйте позже".

Еще раз, ты не понимаешь multidatacenter setup. Оно будет нормально работать. В случае ЯТакси, они умеют отрабатывать ситуацию N-1 ДЦ без импакта для пользоватлей. Они проводят учения с отключением одного из боевых ДЦ.

S>Я уже почитал. Особенно вдохновляет раздел The Unhelpful CAP Theorem.
значит читал известно чем (либо читал в переводе и переводили известно чем), потому что там как раз это все расписано

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

S>>Я уже почитал. Особенно вдохновляет раздел The Unhelpful CAP Theorem.
CK>значит читал известно чем (либо читал в переводе и переводили известно чем), потому что там как раз это все расписано

Стр. 337

The Unhelpful CAP Theorem
CAP is sometimes presented as Consistency, Availability, Partition tolerance: pick 2
out of 3. Unfortunately, putting it this way is misleading [32] because network parti‐
tions are a kind of fault, so they aren’t something about which you have a choice: they
will happen whether you like it or not [38].
At times when the network is working correctly, a system can provide both consis‐
tency (linearizability) and total availability. When a network fault occurs, you have to
choose between either linearizability or total availability. Thus, a better way of phras‐
ing CAP would be either Consistent or Available when Partitioned [39]. A more relia‐
ble network needs to make this choice less often, but at some point the choice is
inevitable.
In discussions of CAP there are several contradictory definitions of the term availa‐
bility, and the formalization as a theorem [30] does not match its usual meaning [40].
Many so-called “highly available” (fault-tolerant) systems actually do not meet CAP’s
idiosyncratic definition of availability. All in all, there is a lot of misunderstanding
and confusion around CAP, and it does not help us understand systems better, so
CAP is best avoided.

Здравствуйте, chaotic-kotik, Вы писали:
CK>в общем-то, ты спросил как имзерять, я ответил — "Каким образом вы от лога результатов перейдёте к "минутам" и "продолжительности инцидентов"? Ну, чтобы вычислить availability?"
Вы же понимаете, что смысл ваших действий — это аппроксимировать % упавших клиентских запросов на основании данных о падении мониторящих запросов?

Клиента (и Product Manager) не интересуют показания вашего монитора. Если раунд-робин выбирает сервис, который отдаёт 500, каждый четвёртый раз, а агенту нужно хотя бы 2 500 "подряд", то ваша лампочка будет гореть зелёным, а с т.з. клиента availability будет равна 75%.

CK>если подумать, то есть
CK>у тебя данные хранятся в одном месте, поэтому они становятся недоступными при непродолжительном отказе, а при продолжительном что будет? в дц пожар, твоя стойка сгорела
Вы опять путаете network partition с device loss. "У меня" данные нигде пока что не хранятся; мы пока что обсуждаем только уровень требований к системе.
Я же Product Manager — я вам (архитектору) объясняю что нет, для меня отказ от консистентности гораздо хуже, чем отказ в обслуживании части запросов при network partition.
Что нагрузка устроена нетривиальным образом; поэтому когда мы выбираем между "терять 10% от всех запросов" и "терять 100% от 1% запросов" выбор однозначно в пользу последнего.

CK>Почему ты думаешь что клиенты в Москве обслуживаются одним ДЦ? Я думаю процентов 50 клиентов ЯТакси, это Мск и СПб.
Я привёл абстрактный иллюстративный пример. Ок, давайте рассмотрим Химки — сколько процентов заказов, сделанных из Химок хотят подачу машину в Химках, а сколько — в других районах?

CK>Еще раз, ты не понимаешь multidatacenter setup. Оно будет нормально работать. В случае ЯТакси, они умеют отрабатывать ситуацию N-1 ДЦ без импакта для пользоватлей. Они проводят учения с отключением одного из боевых ДЦ.
Ну, то есть они опровергли CAP теорему, я вас правильно понял? Ведь ни разу такого не было, чтобы одному клиенту назначили две машины и наоборот — то есть consistency у них соблюдена.

CK>значит читал известно чем (либо читал в переводе и переводили известно чем), потому что там как раз это все расписано
"Это всё" — это что?
Давайте с цитатами, что ли.

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

выделил ключевые моменты
A>

A>The Unhelpful CAP Theorem
A>CAP is sometimes presented as Consistency, Availability, Partition tolerance: pick 2
A>out of 3. Unfortunately, putting it this way is misleading [32] because network parti‐
A>tions are a kind of fault, so they aren’t something about which you have a choice: they
A>will happen whether you like it or not [38].
A>At times when the network is working correctly, a system can provide both consis‐
A>tency (linearizability) and total availability. When a network fault occurs, you have to
A>choose between either linearizability or total availability. Thus, a better way of phras‐
A>ing CAP would be either Consistent or Available when Partitioned [39]. A more relia‐
A>ble network needs to make this choice less often, but at some point the choice is
A>inevitable.
A>In discussions of CAP there are several contradictory definitions of the term availa‐
A>bility, and the formalization as a theorem [30] does not match its usual meaning [40].
A>Many so-called “highly available” (fault-tolerant) systems actually do not meet CAP’s
A>idiosyncratic definition of availability. All in all, there is a lot of misunderstanding
A>and confusion around CAP, and it does not help us understand systems better, so
A>CAP is best avoided.

то бишь определение не очень понятно сформулировано, приведен более корректный вариант
в дискуссиях люди несут чушь (ditto)
некоторые системы сложно классифицировать и не очень то нужно, поэтому в этом случае лучше обойтись без CAP

до этого там идет не менее интересный фрагмент, который ты решил не включать, там как раз про полезность

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

CK>>в общем-то, ты спросил как имзерять, я ответил — "Каким образом вы от лога результатов перейдёте к "минутам" и "продолжительности инцидентов"? Ну, чтобы вычислить availability?"
S>Вы же понимаете, что смысл ваших действий — это аппроксимировать % упавших клиентских запросов на основании данных о падении мониторящих запросов?

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

S>Клиента (и Product Manager) не интересуют показания вашего монитора. Если раунд-робин выбирает сервис, который отдаёт 500, каждый четвёртый раз, а агенту нужно хотя бы 2 500 "подряд", то ваша лампочка будет гореть зелёным, а с т.з. клиента availability будет равна 75%.

С чего ты взял что там round-robin DNS?
Ты не понимаешь как работает load balancing, не так ли?

S>Вы опять путаете network partition с device loss. "У меня" данные нигде пока что не хранятся; мы пока что обсуждаем только уровень требований к системе.

я думал мы ту систему из failover cluster-ов обсуждаем, которая волшебным образом натягивается на любую задачу (на самом деле не натягивается)

S>Я же Product Manager — я вам (архитектору) объясняю что нет, для меня отказ от консистентности гораздо хуже, чем отказ в обслуживании части запросов при network partition.
S>Что нагрузка устроена нетривиальным образом; поэтому когда мы выбираем между "терять 10% от всех запросов" и "терять 100% от 1% запросов" выбор однозначно в пользу последнего.

В случае такси как раз важнее availability. Если водитель завершает поездку, а она у него не завершается, я как клиент теряю деньги. В случае же РА системы, данные об окончании поездки запишутся в БД, даже в случае недоступности одного из ДЦ яндекса.
И консистентность там скорее всего достаточно поддерживать в рамках одной поездки, причем допустимо делать это пост фактум. Можно записать время/место начала поездки, точки маршрута и время/место окончания поездки отдельно для клиента и отдельно для водителя. Стоимость заранее расчитывается, биллинг отдельно работает и время задержки между окончанием позедки и списанием средств не критично.

S>Я привёл абстрактный иллюстративный пример. Ок, давайте рассмотрим Химки — сколько процентов заказов, сделанных из Химок хотят подачу машину в Химках, а сколько — в других районах?

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

S>Ну, то есть они опровергли CAP теорему, я вас правильно понял? Ведь ни разу такого не было, чтобы одному клиенту назначили две машины и наоборот — то есть consistency у них соблюдена.

выше ответил

S>Давайте с цитатами, что ли.

в соседней ветке ответил

CK>В случае такси как раз важнее availability.
Ваши же рассуждения ниже, показывают то, что важно и availability и consistency.

CK> Если водитель завершает поездку, а она у него не завершается, я как клиент теряю деньги. В случае же РА системы, данные об окончании поездки запишутся в БД, даже в случае недоступности одного из ДЦ яндекса.
CK>И консистентность там скорее всего достаточно поддерживать в рамках одной поездки, причем допустимо делать это пост фактум. Можно записать время/место начала поездки, точки маршрута и время/место окончания поездки отдельно для клиента и отдельно для водителя. Стоимость заранее расчитывается, биллинг отдельно работает и время задержки между окончанием позедки и списанием средств не критично.
Совершенно верно, и что же мы получаем? С точки зрения CAP — система не консистентна (AP), а с точки зрения бизнеса система и консистентна, и доступна. И водитель смог отчитаться о выполнении, и два такси никому не приехало и деньги аккуратно списались.
Ну и толку нам здесь от CAP?