Давайте немножко побеседуем про новомодные low consistency poor availability системы, снискавшие популярность в последнее время.
Попытка заблокировать сервисы Google обернулась сбоем в работе систем Центробанка РФ (комментарий)
«интернет вояками планировался как отказоустойчивая сеть, но вебмакаки умудрились сделать из нее сильно связанный фарш, поздравляю, вы сломали чугунный шар»
Как мы все знаем, интернет разрабатывался, как отказоустойчивая система, которая функционирует до последнего узла. Как мы знаем, коммерсанту частенько есть что скрывать и не хочется зависеть от благого расположения Васи Пупкина, даже если Васю Пупкина зовут SAP, Oracle, IBM, или Microsoft. Так почему же люди покупают Office 365 и Dynamics 365 при том, что есть полностью оффлайн альтернативы? Если вы размещаетесь в России или Китае, покупаете продукт 365, а потом Роскомнадзоры или сам MS блокирует вам облако — вы остаетесь полностью в дерьме. Кто это покупает и что ими движет? Кто завязывает свой бизнес на Dynamics 365? Или на облачный Битрикс? Я не понимаю, предлагайте ваши вариант.
«Облака», в плане «привязан цепью к интернет-серверу», не новы, Самая отстойная копирастическая контора, Ubisoft, в свое время отличилась тем, что их uPlay при кратковременной потере интернет-соединения вываливал вас из ОФФЛАЙН игры. По сути, многие софтоделы ориентируются на облако просто для того, чтобы иметь больше возможностей струсить денег с потребителя. И даже несмотря на то, что теоретически возможность миграции предоставляет много кто — фактически эта миграция выйдет вам в копеечку и вы семь раз подумаете, прежде чем мигрировать.
Ладно, допустим, просто допустим, что таким образом некий Ерохин экономит время и деньги на установке и настройке оффлайнового софта, на организации своего сервера, к которому можно было бы получить доступ даже с мабилы (не спрашивайте меня, зачем с мобилы — я не понимаю). Давайте даже на минуту пофантазируем, что мы — технически грамотный разработчик, который желает приобщиться к потоку денег. Естественно, при этом мы желаем клиенту только добра. Железо дешевое, хостинг дешевый — давайте же сделаем бэк нашего продукта на большом-прибольшом числе серверов, да еще и в разных геолокациях, чтобы у нашего любимого клиента было меньше проблем со связью.
Но раскидать серваки по планете — это одно, а заставить их работать после этого вместе — это совершенно другого уровня задача. Как она обычно решается? Через базы данных, в число которых входят брокеры сообщений, вроде RabbitMQ. И здесь мы вступаем на тропу лютого треша, потому что проектировать и реализовывать распределенные системы и БД в частности на планете умеет человек двадцать, и скорее всего они работают не у вас, но спрос на них сильно больше, потому что другие «умники» уже давно витают в облаках и своих спецов не отдадут.
«Готовые решения всё порешают» — скажете вы? А знаете ли вы, что ZooKeeper — единственная распределенная СУБД, гарантирующая строгую согласованность данных при отказах? А знаете ли вы, что, даже несмотря на выдающиеся достижения, в ZooKeeper операция синхронизированного чтения нелинеаризуема, а потому часть вашего кластера может сидеть с тухлыми данными, не зная об этом? А знаете ли вы, что полностью исправный кластер Riak при интенсивных конфликтах обновлений теряет более половины этих обновлений на полностью исправном кластере? Даже при самых строгих настройках согласованности данных. Причем, таким ужасным Riak делать было не обязательно — на самом деле это спонсоры Riak и попросили сделать умолчательную конфигурацию такой ужасной.
Но как же так, мы же все давно знаем про Paxos, который еще триста лет назад позволял достигнуть консенсуса в распределенной системе с отказами узлов — почему же до сих пор в школе не преподают основы построения распределенных систем? Если мы возьмем тот же ZooKeeper, то мы увидим, что в случае отказа лидера кластеру требуется НЕСКОЛЬКО СЕКУНД на возобновление работы — это настоящая стоимость честного распределенного консенсуса, который у ZooKeeper при выборах лидера похож на Paxos. Для решения проблем дичайше медленного консенсуса и возникла идея выбора «эталонного сервера», лидера, мнение которого безоговорочно принимает весь кластер без затрат на спор между узлами.
Правда, этот подход все равно не сработает при достаточно частых сбоях с частыми потерями лидера. Более того, система на консенсусе полностью выйдет из строя при потере более половины узлов. Вы можете заметить, что согласно теореме говна-или-мочи достижима либо согласованность данных, либо доступность системы, либо в системе недопустимы отказы. Давайте пожертвует согласованностью ради доступности! Но беда мамкиных бигдатовцев заключается в том, что средняя система по больнице не обладает высокой доступностью и не обладает хорошими гарантиями согласованности. То есть, высокодоступная система готова работать 24/7 до первого отказа сервера или потери соединения с интернетом. Почему пришлось так делать? Потому что иначе будет высокая задержка ответа и/или большая нагрузка на каналы.
Возьмем среднюю бигдату в вакууме — GitLab:
https://about.gitlab.com/blog/2017/02/01/gitlab-dot-com-database-incident/
Пока бигдатовцы боролись со спамером, они умудрились ушатать данные пользователей за целый день, и потом еще день восстанавливали ее из бэкапа. Тест на доступность успешно провален. Это еще ладно — а я слышал истории о том, что у сервиса бэкапы-то есть, но восстанавливать их придется несколько недель. Так что отказ на день — это еще вполне себе High Availability по нынешним меркам.
Да, какой-нибудь яндекс регулярно устраивает тесты отказоустойчивости, вырубая датацентр. Однако, мне страшно подумать, что случится, если у яндекса внезапно вырубится более половины датацентров и отвалятся службы, опирающиеся на консенсус. Ихний кластер ClickHouse опирается в своей работе на (сюрприз) ZooKeeper. Отказ обезьянника (а он полностью отрубается при отказе половины узлов) приводит к переходу кластера в read-only. Сколько там еще служб отправится в read-only — мне было бы интересно узнать (давайте попросим роскомнадзор для проверки поблокировать датацентры яндекса).
Заметьте, что на серверах обычно SSD/HDD стоят в зеркале — чтобы, боже упаси, 24/7 сервис не умер из-за отказа одного из жестких дисков. И этому процессу впаривания говна нет конца, даже если завтра сделают устройства для передачи информации со сверхсветовой скоростью на спутанных квантовых состояниях и карманные петабайтные носители со средним периодом отказа в 2000 лет, то желающих хранить данные на локалхосте станет еще меньше и облачные сервисы будут выходить из строя по таймаутам при недопустимо больших задержках канала связи в 1 мс.
Потому, как ни странно, самое надежное «облако» — это то, которое стоит у вас в локальной сетке. Мало того, что облака могут в любой момент отвалиться — они еще и более несводобны, чем проприетарная софтина на локалхосте, как и предупреждал нас Штолман:
https://www.gnu.org/philosophy/who-does-that-server-really-serve.html
Я вот что не пойму: я один это вижу? Ваши данные, которые не ваши, ваши приложения, которая не ваши, ваши высоконадежные высокодоступные SaaS, которые остаются таковыми до первого отказа (и тоже, в общем-то, не ваши). Или вы тут все зарабатываете на SaaS (как Шома), потому особо не вскрываете эту тему? А со мной не поделились — у-у-у, подлецы.
PS: сам участвовал в разработке SaaS, но поставляли также и коробку для внутреннего сервера.
