Хабрахабр

«Не так важны инструменты, как умение мыслить о системах, которые они создают». Большое интервью с Мартином Клеппманом

Его книга «Designing Data-Intensive Applications», опубликованная в 2017 году, стала бестселлером в области хранения и обработки данных.  Мартин Клеппман (Martin Kleppman) – исследователь в Кембриджском университете, работающий над CRDT и формальной верификацией алгоритмов.

Это редкий ресурс, объединяющий теорию и практику, помогающий разработчикам глубже продумывать дизайн и реализацию инфраструктуры и систем обработки данных». Kevin Scott (CTO в Microsoft) однажды сказал: «Эта книга должна быть обязательной для инженеров-разработчиков. Что-то похожее говорил и Jay Kreps — создатель Apache Kafka и CEO Confluent.

А прежде чем заняться академическими исследованиями, Мартин работал в индустрии и стал сооснователем двух успешных стартапов: Rapportive (купленный LinkedIn в 2012 году) и Go Test It (куплен RedGate).

Примерные темы обсуждения: Этот хабрапост – развернутое интервью с Мартином.

  • Переход от бизнеса к академическим исследованиям;
  • Предпосылки написания Designing Data-Intensive Applications;
  • Здравый смысл против искусственного ажиотажа и рекламы инструментов;
  • Ненужность теоремы CAP и другие ошибки индустрии;
  • Полезность децентрализации;
  • Блокчейны, Dat, IPFS, Filecoin, WebRTC;
  • Новые CRDT. Формальная верификация на Isabelle;
  • Дискуссия про event sourcing. Низкоуровневый подход. XA-транзакции; 
  • Apache Kafka, PostgreSQL, Memcached, Redis, Elasticsearch;
  • Использование всего этого в реальной жизни;
  • Порог входа в доклады Мартина и конференция Hydra.

Интервью провёл Вадим Цесько (@incubos) — ведущий разработчик в команде Платформы компании Одноклассники. Научные и инженерные интересы Вадима касаются распределённых систем и хранилищ данных, а также верификации программных систем.

От бизнеса к академическим исследованиям

Вадим: Я хотел бы начать с вопроса, который очень важен для меня лично. Вы основали Go Test It и Rapportive, и в течение длительного времени занимались разработкой больших систем в LinkedIn, но потом решили уйти из коммерческой разработки и заняться исследованиями в университете. Не могли бы вы рассказать, что вас к этому толкнуло? В чем преимущества работы в университете, и чем вам пришлось пожертвовать?

Как я понимаю, мое решение интересует вас из-за того, что в академические исследования из коммерческой разработки уходит довольно мало людей, значительно чаще происходит движение в обратную сторону. Мартин: Это был очень интересный переход. Меня лично в позиции исследователя привлекает тот факт, что я могу сам решать, над какими темами мне работать, и я делаю этот выбор на основе того, что мне кажется интересным и важным, даже если работа над темой не обещает дать прибыль в течение следующих 6 месяцев. Это вполне объяснимо, поскольку заработки в университетах существенно ниже, чем в бизнесе. В данный момент я работаю над важными для будущего интернета и ПО темами, но наше понимание их еще недостаточно глубоко, чтобы можно было создать готовый продукт. Все, над чем вы работаете в компании, должно в той или иной форме быть продано. Поскольку эти исследования фундаментальные, я решил, что их лучше вести в университете, а не в компании: в университете больше свободы, там можно заниматься вещами, которые еще 10 лет не будут приносить никакой прибыли. Пока что мы даже в общих чертах не представляем, как эти технологии должны работать. Горизонт планирования значительно шире.

Книга «Designing Data-Intensive Applications»

Вадим: Мы обязательно вернемся к теме исследований, а пока давайте поговорим о вашей книге, Designing Data-Intensive Applications. На мой взгляд, это одно из лучших руководств по современным распределенным системам, почти энциклопедия: в ней перечислены все наиболее значимые достижения, существующие сегодня.

Мартин: Спасибо, я рад, что она вам пригодилась.

Вадим: Маловероятно, что наши читатели еще с ней не знакомы, но на всякий случай, давайте обсудим наиболее существенные достижения в области распределенных систем, о которых вы пишете.

Скорее я хотел сделать руководство по всему миру систем, используемых для хранения и обработки данных. Мартин: На самом деле, при написании этой книги я не ставил цели описать определенные технологии. И если нужна база данных для решения определенной проблемы, трудно выбрать какую-то одну из множества существующих. Сейчас существует огромное количество баз данных, потоковых процессоров, инструментов пакетной обработки, всякого рода инструментов репликации и тому подобного, поэтому составить для себя общую картину этой области очень тяжело. Например, в книге про Apache Cassandra может быть написано о том, какая Cassandra замечательная, но ничего не будет сказано о задачах, для которых она не подходит. Многие написанные о таких системах книги в этом случае просто бесполезны. Ответы на эти вопросы помогут определить, какие технологии хорошо подходят для решения текущей проблемы, а какие — не очень. Поэтому в своей книге я пытаюсь выявить основные вопросы, которые нужно себе задавать при написании больших систем. Я пытаюсь показать, в чем преимущества и недостатки разных технологий в разных контекстах. Главное, что не существует технологии, которая умела бы все.

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

Здравый смысл против искусственного ажиотажа и рекламы инструментов

Мартин: Больше того, зачастую приходится читать между строк, потому что в документации не написано, для каких задач база данных подходит не очень хорошо. На самом деле, любая база данных имеет свои ограничения, поэтому нужно всегда знать, какие именно. Зачастую приходится читать руководства по развертыванию и по ним реконструировать внутреннюю работу системы.

Вам не кажется, что в этой области не хватает общего словаря или единого набора критериев, используя которые можно было бы сравнивать различные решения для одной задачи? Вадим: Да, это отличный пример. Сейчас для одних и тех же вещей используются разные имена, а многие аспекты, которые должны быть четко и ясно прописаны, вовсе не упоминаются — например, гарантии транзакционности.

К сожалению, в нашей отрасли очень часто возникает излишний ажиотаж вокруг разных инструментов. Мартин: Да, это действительно так. Поэтому эти компании отправляют людей на конференции, и те, в сущности, рассказывают о том, какие эти продукты замечательные. Что вполне объяснимо, поскольку эти инструменты создаются компаниями, которые заинтересованы в продвижении своих продуктов. Нам как отрасли совершенно не помешало бы быть более честными относительно достоинств и недостатков производимых нами продуктов. Это маскируется под технические доклады, но, в сущности, это реклама. Но помимо этого необходимы способы анализа преимуществ и недостатков различных технологий. Одно из требований для этого — общая терминология, без нее сравнивать вещи невозможно.

Ненужность теоремы CAP и другие ошибки индустрии

Вадим: Мой следующий вопрос довольно щекотливый. Не могли бы вы рассказать о каких-нибудь общепринятых ошибках в нашей отрасли, с которыми вам пришлось столкнуться по ходу вашей карьеры? Например, о какой-нибудь переоцененной технологии или о широко используемом решении, от которого давным-давно следовало избавиться? Возможно, это не лучший пример, но мне приходит на ум использование JSON over HTTP/1.1 вместо gRPC over HTTP/2. Или быть может, вы не разделяете такую точку зрения?

В случае с выбором между JSON over HTTP/1. Мартин: Чаще всего при создании систем, чтобы добиться чего-то одного, нужно пожертвовать чем-то другим, и тут я предпочитаю не говорить об ошибках. Если принято решение использовать Protocol Buffers, необходимо определить схему, и она может быть очень полезной, поскольку она помогает точно определить поведение системы. 1 и, скажем, Protocol Buffers over HTTP/2 оба варианта вполне имеют право на существование. Опять-таки, здесь для достижения определенной цели приходится чем-то жертвовать, и в одних ситуациях это оправданно, а в других — нет. Но в некоторых ситуациях ничего кроме раздражения такая схема не вызывает, в особенности на ранних этапах разработки, когда форматы данных меняются довольно часто. Но раз уж об этом зашла речь, давайте поговорим о теореме CAP — на мой взгляд, от нее нет совершенно никакой пользы. Решений, которые действительно можно назвать неправильными, на самом деле, не так уж и много. В ней используется очень узко определённая модель согласованности — линеаризуемость, и очень узко определённая модель доступности — каждая реплика должна быть полностью доступна, даже если она не может установить связь с какой-либо другой репликой. Когда ее используют при проектировании систем, то либо имеет место непонимание смысла теоремы CAP, либо при помощи неё обосновывают самоочевидные утверждения. И если в приложении используется другое определение этих слов, теорема CAP для него бесполезна. С одной стороны, эти определения вполне верные, но, с другой, они слишком узкие: многим приложениям попросту не нужно именно такое определение согласованности или доступности. Кстати говоря, коль скоро мы заговорили об ошибках в нашей отрасли, давайте честно признаемся, что майнинг криптовалют — совершенно бесцельная трата электричества. Так что я не вижу большого смысла в её применении. Я не понимаю, как этим можно всерьёз заниматься.

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

Больше того, значительная часть технологий не подпадают под строгое определение согласованности и доступности теоремы СAP, то есть они не CP, не AP и не CA, а только P. Мартин: Совершенно верно. Это одна из причин, по которым я считаю, что от CAP при анализе софта больше вреда, чем пользы: значительная часть проектировочных решений в ней никак не представлены, причем это могут быть вполне рациональные решения, а CAP не позволяет их описать. Прямо это про свой софт никто не напишет, но на самом-то деле это может быть вполне рациональной стратегией при разработке.

Полезность децентрализации

Вадим: Какие проблемы в разработке Data-Intensive Applications стоят сейчас наиболее остро? Какие темы наиболее активно исследуются? Насколько мне известно, вы являетесь сторонником децентрализованных вычислений и децентрализованных хранилищ данных.

Один из тезисов, которые я доказываю в своём исследовании, заключается в том, что в данный момент мы слишком сильно полагаемся на серверы и централизацию. Мартин: Да. В случае ядерного взрыва в каком-либо городе в Америке уцелевшая часть сети продолжала бы работать, просто использовались бы альтернативные маршруты в обход вышедших из строя участков. В первое время существования интернета, когда он развивался из ARPANET, он проектировался как максимально устойчивая сеть, в которой пакеты можно отправлять по различным маршрутам, и они всё равно все достигают цели. Но потом мы решили разместить всё в облаке, так что сейчас практически всё так или иначе проходит через один из центров AWS где-то в Вирджинии, на востоке США. Это была схема, порождённая холодной войной. Я считаю важным вновь вернуться к децентрализованному подходу, при котором больше контроля над данными принадлежало бы не сервисам, а конечным пользователям. В определенный момент мы отказались от идеала децентрализованного использования различных частей сети и выделили сервисы, от которых теперь всё зависит.

Но это не та децентрализация, о которой говорю я, поскольку, на мой взгляд, криптовалюты тоже крайне централизованы: если необходимо выполнить сделку с Bitcoin, её обязательно нужно сделать через сеть Bitcoin, так что всё централизовано вокруг этой сети. Когда речь заходит о децентрализации очень часто под этим понимают вещи вроде криптовалют, поскольку в них функционируют сети взаимодействующих агентов, над которыми нет единой централизованной власти вроде банка. Я считаю, что это тоже форма централизации. Структура сети децентрализована в том смысле, что у нее нет единого организующего центра, но сеть в целом крайне централизована, поскольку каждая сделка должна совершаться через эту сеть и никак иначе. Но есть множество приложений, которые не требуют системы вроде блокчейна, они могут работать со значительно более гибкой моделью данных. В случае с криптовалютами это неизбежно, поскольку необходимо обеспечить отсутствие двойных расходов, а этого тяжело добиться без сети, которая обеспечивает консенсус относительно того, какие сделки были совершены, и тому подобного. Именно такие децентрализованные системы интересуют меня больше всего.

Сам я игрался с IPFS, но у вас гораздо больше опыта в этой сфере. Вадим: Коль скоро вы упомянули блокчейн, не могли бы вы рассказать о многообещающих или недостаточно известных технологиях в области децентрализованных систем?

Я немного читал о IPFS, но сам ее не использовал. Мартин: На самом деле, я не слежу активно за такими технологиями. Различие в том, что к IPFS привязана криптовалюта Filecoin, и она используется для оплаты хранения данных, а к Dat не привязан никакой блокчейн. Мы немного работали с Dat, который, как и IPFS, является технологией децентрализованного хранения данных. Мы писали ПО для совместной работы пользователей над документом, данными или базой данных, и каждое изменение в этих данных отправляется всем, у кого есть копия данных. Dat только позволяет реплицировать данные на несколько машин по принципу P2P, и для проекта, над которым мы работали, Dat отлично подходит. Поверх этого мы написали уровень из CRDT, при помощи которых несколько людей могли редактировать документ или набор данных и которые позволяли быстро и удобно обмениваться правками. В такой системе Dat можно использовать по принципу P2P, чтобы он обеспечивал работу на уровне сети, то есть NAT Traversal и прохождение через файрволы, что является довольно сложной задачей. Думаю, аналогичную систему можно было написать и поверх IPFS, при этом игнорируя Filecoin и пользуясь только P2P репликацией. 

Вадим: Но разве такая система не стала бы менее отзывчивой, ведь WebRTC напрямую соединяет узлы друг с другом, а IPFS — скорее распределенная хэш-таблица.

Он предназначен в основном для видеозвонков — с большой вероятностью он используется в том софте, через который мы с вами сейчас общаемся. Мартин: Дело в том, что WebRTC — это несколько другой уровень стека. Но создать поверх него систему репликации может быть трудно. Кроме того, WebRTC предоставляет канал, через который можно отправлять произвольные бинарные данные. А в Dat и IPFS для этого ничего делать не нужно. 

Предположим, мы хотим сделать следующий Google Docs децентрализованным. Вы упомянули отзывчивость, и это действительно важный фактор, который необходимо иметь в виду. С одной стороны, это обеспечивает быструю совместную работу, с другой, это значит, что при написании крупного документа необходимо переслать сотни тысяч односимвольных изменений, и многие существующие технологии плохо справляются со сжатием такого рода данных. В Google Docs единица изменений — отдельное нажатие клавиши, и каждый новый символ может быть отправлен в реальном времени другим людям, которые работают с тем же документом. Пока не изобретен некий хитрый способ сжатия такая синхронизация данных требует колоссальной дополнительной затраты ресурсов. Даже если предположить, что для каждого нажатия клавиши необходимо отправить всего сотню байт, то для документа из 100 000 символов будет необходимо переслать 10 МБ данных, при том что обычно такой документ занимает не больше нескольких десятков килобайт. Именно этой проблемой я сейчас и занимаюсь, пытаюсь создать алгоритм для более эффективной синхронизации документа для нескольких пользователей. Во многих P2P системах пока нет эффективного способа создания моментальных снимков состояния, который позволил бы использовать их для системы вроде Google Docs. Это должен быть алгоритм, который позволил бы не хранить каждое отдельное нажатие клавиши, поскольку для этого нужно слишком много ресурсов, и он должен обеспечить более эффективное использование сети.

Новые CRDT, формальная верификация на Isabelle

Вадим: Вы не могли бы рассказать об этом подробнее? Удалось ли вам добиться более чем 100-кратного сжатия данных? Речь идёт о новых приёмах сжатия или специальных CRDT?

Пока что у нас есть только прототип, он еще не полностью реализован. Мартин: Да. Но некоторые из наших методов многообещающие. Нужно поставить дополнительные эксперименты, чтобы узнать, насколько он эффективен на практике. 7 байт. В моем прототипе мне удалось сократить размер одного редактирования со 100 до 1. Так или иначе, в этой области есть большие возможности для оптимизации. Но, повторюсь, это пока только экспериментальная версия, этот показатель может немного поменяться.

Вадим: Значит, ваш доклад на конференции Hydra будет именно об этом?

У меня будет короткое введение о CRDT, софте для совместной работы и некоторых проблемах, которые возникают в этом контексте. Мартин: Да. С прикладной стороны у нас есть реализация этих алгоритмов на JavaScript, на основе неё мы создаём функционирующие программы, чтобы лучше понять поведение алгоритмов. Затем я расскажу об исследованиях, которые мы ведем в этой области — они касаются множества различных проблем. Многие разработанные ранее алгоритмы не обеспечивают согласованность в некоторых пограничных случаях. При этом мы также работаем над формальными методами доказательства правильности этих алгоритмов, потому что некоторые из них довольно неочевидные, а мы хотим добиться, чтобы они всегда достигали согласованного состояния. Чтобы этого избежать, мы обратились к формальным методам доказательства правильности.

Вадим: Используете ли вы для этого системы доказательства теорем вроде Coq или Isabelle? 

Мартин: Да, Isabelle.

Примечание редакции: Мартин прочитает доклад про Isabelle на конференции The Strange Loop.

Вадим: Вы планируете опубликовать эти доказательства?

Мы проверили три CRDT при помощи этого фреймворка, самый важный из них был RGA (Replicated Growable Array), CRDT для совместного редактирования текста. Мартин: Да, первый набор доказательств мы опубликовали полтора года назад вместе с фреймворком для проверки CRDT. Мы также занимались доказательством корректности нескольких существующих CRDT, а последнее, что мы делали в этой области — создание своих CRDT для новых моделей данных. Этот алгоритм не слишком сложный, но довольно неочевидный, на взгляд не сразу понятно, корректный ли он, поэтому необходимо было формальное доказательство.

С этим иногда возникают трудности. Вадим: Насколько объём формального доказательства больше чем размер кода самого алгоритма?

Я сейчас посмотрел на код: описание алгоритма занимает около 60 строк, он довольно компактный, а доказательство превышает 800 строк. Мартин: Трудностей действительно хватает, с доказательствами приходится много работать. К сожалению, это вполне типичная ситуация. Получается, что доказательство в 12 раз длиннее. Кроме того, работа над доказательством позволила нам самим лучше понять этот алгоритм. С другой стороны, наличие формального доказательства даёт нам уверенность в корректности алгоритма. В конечном итоге, это позволяет создавать более качественные реализации алгоритмов. Формализация вообще этому часто способствует.

Какие необходимы предварительные знания? Вадим: Скажите, на какую аудиторию вы рассчитываете ваш доклад?

Я даю много материала, но начинаю с довольно простых вещей. Мартин: Я стараюсь делать свои доклады как можно более доступными, и пытаюсь подтянуть всех до одного уровня. Но, по большому счёту, помимо базовых знаний ничего не нужно. Для слушателей будет полезно иметь некоторый опыт с распределенными системами: отправка данных по сети через TCP, представление об устройстве Git и тому подобное. Я объясняю всё на примерах и иллюстрирую их картинками. Имея их, понять нашу работу не так уж и трудно. Надеюсь, что доклад будет доступен всем.

Event sourcing, низкоуровневый подход, XA-транзакции

Вадим: Я хотел бы поговорить о вашей недавней статье, посвящённой обработке событий онлайн. Насколько я понимаю, вы сторонник event sourcing. Сейчас этот подход обретает всё большую популярность, и программисты пытаются применять его везде из-за преимуществ глобально упорядоченного журнала операций. А в каких ситуациях event sourcing не самый лучший подход? Хотелось бы избежать разочарования в этой технологии из-за того, что люди пытаются применить её везде и в некоторых случаях она плохо работает.

Event sourcing в той форме, в какой его создал Грег Янг и другие, является механизмом моделирования данных. Мартин: Эту проблему нужно обсудить на двух различных уровнях. События могут выразить напрямую, что происходит на уровне логики приложения, какое действие предпринимает пользователь, как его последствия обновляют различные таблицы и так далее. Если в вашей базе данных становится слишком много таблиц и транзакций с этими таблицами и она становится слишком неорганизованной, то event sourcing может помочь упорядочить модель данных. В сущности, event sourcing позволяет отделить действие (событие) от его последствий. 

Я занимался созданием масштабируемых систем при помощи технологий вроде Apache  Kafka. Я пришёл к event sourcing с более низкоуровневой стороны. Но для event sourcing использовать Apache Kafka не обязательно, это можно делать и с помощью обычной базы данных, или базы данных, специально созданной для event sourcing. Event sourcing похож на Apache Kafka, поскольку и там, и там используются события. Система вроде Apache Kafka полезна, если необходимо масштабирование, если поток данных настолько большой, что обработать их в базе данных, состоящей из одного узла, невозможно. В общем, эти подходы похожи, но они не завязаны друг на друга, просто у них есть некоторое пересечение. Apache Kafka особенно полезна, если необходимо интегрировать несколько различных систем хранения данных. При помощи журнала событий вроде Apache Kafka эту нагрузку можно распределить на несколько компьютеров. При помощи неё можно обновить одним событием не только реляционную базу данных, но и полнотекстовый поисковый индекс вроде Elasticsearch, или систему кэширования вроде Memcached или Redis. 

Как правило, я предпочитаю использовать наиболее простой подход. Что касается вашего изначального вопроса, то мне сложно точно сказать, когда именно не следует использовать event sourcing. Реляционные базы данных — вполне допустимый вариант, они прекрасно нам служат уже давно. Если необходимая модель данных прекрасно реализуется в реляционной базе данных со вставкой, обновлением и удалением строк, то используйте её. Аналогичного принципа следует придерживаться и на более низком уровне: если размер данных позволяет хранить их в PostgreSQL на одном компьютере, то так и следует поступить. Но если модель данных становится слишком сложной для реляционной базы данных, то следует перейти к event sourcing. То есть, повторюсь, для каждой ситуации следует выбирать наиболее простой для нее подход.  Если же один компьютер не может обработать все данные, то следует обратиться к распределенным системам вроде Kafka.

Кроме того, большинство прикладных систем постоянно развиваются и направление их развития не всегда известно заранее, так что никогда не знаешь наперёд, какие в них появятся запросы, паттерны и потоки данных.  Вадим: Это прекрасный совет.

Если необходимо поддержать новые запросы, можно просто создать недостающие индексы. Мартин: Да, и в этом отношении особенно полезны реляционные базы данных, потому что как правило сейчас у них есть поддержка JSON (например, PostgreSQL отлично его поддерживает) и с ней они особенно гибкие. Если размер данных не слишком большой и они не слишком сложные, все будет прекрасно работать. Можно поменять схему данных и смигрировать базу.

Вы упомянули интересный пример, в котором события из одной очереди отправляются нескольким получателям. Вадим: У меня есть ещё один вопрос относительно event sourcing. Эти системы работают одновременно и параллельно.  Предположим, у нас создаётся новый документ (скажем, объявление), и несколько систем получают о нём события: поисковая система на основе Elasticsearch, которая позволяет найти это объявление; система кэширования, которая помещает его в кэш key-value на основе Memcached; и база данных, которая сохраняет его в таблицы.

Мартин: То есть вы хотите узнать, что делать, если некоторые из этих получателей событий уже обновлены, а другие — ещё нет?

И в этой ситуации на сайт приходит пользователь, вводит поисковый запрос и видит, что, скажем, в этом районе доступна квартира, но после клика по объявлению получает код 404, поскольку база данных ещё не успела получить событие и нужный документ в ней пока отсутствует. Вадим: Да.

В идеале необходимо обеспечивать причинную согласованность (causal consitency) для этих систем. Мартин: Это действительно существенная трудность. К сожалению, добиться этого для нескольких различных систем хранения данных очень трудно: не важно, какой используется подход или система для отправки обновлений различным системам, в конечном итоге всегда могут возникнуть проблемы с параллелизмом. То есть если одна система содержит в себе некоторые необходимые данные, то они также будут находиться и в других системах. При чтении из обеих систем может быть выявлена несогласованность. Даже если выполнять запись в обе системы одновременно, может возникнуть небольшая задержка в сети, из-за которой обработка одного из действий записи произойдет немного раньше или позже. Проблема в том, что для правильного решения здесь необходимо иметь моментальный снимок и поискового индекса, и кэша, и базы данных. Существуют исследовательские проекты, которые пытаются добиться такого рода причинной согласованности, но её сложно обеспечить, просто используя Elasticsearch или Memcached. И все запросы будут возвращать данные на момент создания снимка. Если мы работаем только с реляционной базой данных, то у нас возникает snapshot isolation: это значит, что чтение из базы данных выполняется так, как будто бы у вас есть копия всей базы данных. В обсуждаемом случае с Memcached и Elasticsearch проблему можно решить при помощи согласованного моментального снимка этих двух систем. То есть даже если данные на момент чтения изменились, будут всё равно представлены старые данные, потому что они являются частью согласованного моментального снимка. Каждая система действует самостоятельно и, как правило, просто выдаёт последнее значение каждого ключа. Но, к сожалению, ни Memcached, ни Redis, ни Elasticsearch не предоставляют эффективного механизма создания таких снимков, которые можно было бы координировать для нескольких систем хранения данных. Так что я не могу порекомендовать оптимального решения для этой проблемы. Возможности получить более раннюю, но согласованную версию данных обычно нет. Нужен механизм создания моментальных снимков, который был бы достаточно быстрым, чтобы им можно было постоянно пользоваться — такие снимки могут быть необходимы несколько раз в секунду, а не один раз в день. Боюсь, что так или иначе придётся менять код систем хранения данных. В целом, это очень интересная исследовательская тема. Пока что существующие решения не позволяют создавать моментальные снимки для нескольких систем хранения данных. Надеюсь, что кто-то ею займётся, но пока что удовлетворительного решения этой проблемы я не видел. 

Вадим: Да, необходим некий единый распределенный Multiversion Concurrency Control.

Можно использовать распределенные XA-транзакции, но, к сожалению, в текущем состоянии эта система не очень хорошо подходит для этих целей. Мартин: Да, наподобие систем распределенных транзакций. Дело в том, что такой параллелизм имеет очень низкую производительность, поэтому на практике он сейчас не применяется. Она работает только с контролем параллелизма на основе блокировок, то есть при чтении любых данных эти данные блокируются, и никто другой не может их изменить. Быть может, из этого затруднения мог бы вывести новый протокол для распределенных транзакций, который позволял бы использовать изоляцию моментальных снимков для нескольких различных систем. Но без такой блокировки создать моментальные снимки в XA невозможно. Но пока я ничего подобного не видел.

Вадим: Будем надеяться, что кто-то над этим работает.

Сейчас считается правильным создавать для каждого микросервиса своё хранилище, свою базу данных, и микросервис не должен обращаться напрямую к базе данных другого сервиса, поскольку это было бы нарушением инкапсуляции. Мартин: Это было бы очень полезно, в том числе для микросервисов. Если необходимо что-либо узнать о пользователях, нужно обратиться к этому сервису. Каждый сервис управляет только своими данными, и существует отдельный сервис для управления пользователями с отдельной базой данных. Но это создаёт большие трудности с соблюдением согласованности различных сервисов между собой из-за проблемы, которую мы только что обсуждали: в двух сервисах могут быть данные, зависящие друг от друга, и в одном из этих сервисов они могут оказаться обновлены немного раньше, чем в другом. Всё это позволяет соблюсти инкапсуляцию, поскольку при этом подходе подробности схемы базы данных скрыты от других сервисов. Насколько я знаю, адекватного решения этой проблемы для микросервисов пока не существует.  Тогда при чтении из этих двух сервисов будут получены несогласованные результаты.

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

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

Я хотел бы ещё поговорить о преимуществах event sourcing. Вадим: По крайней мере, пока не мыслит. Таким образом, система всегда находится в согласованном состоянии. При использовании этого подхода можно остановить обработку событий, если обнаружен баг, и возобновить обработку, когда развёрнута новая версия с исправлением. Предположим, в банке работает система, которая продолжает получать финансовые транзакции, но при этом балансы или остатки являются устаревшими, поскольку приостановлено получение событий до тех пор, пока не развёрнута новая версия без бага. Это очень полезная и востребованная возможность, но в случае, например, банковского софта ей пользоваться невозможно. Как избежать такой ситуации?

Скорее в случае бага система продолжает работать, и параллельно с ней создаётся новая версия кода без бага, которая затем запускается параллельно со старой. Мартин: Я не думаю, что в реальности для развёртывания новой версии приостанавливается работа системы. После этого можно произвести замену и отключить старую версию. Исправленная версия должна будет обработать все входящие события, произошедшие с момента развёртывания кода с багом, и, возможно, записать результат в отдельную базу данных. Благодаря этому у разработчиков есть время исправить баг, и они могут устранить его последствия, поскольку можно повторно обработать входные события. Таким образом, система ни в какой момент не прекращает работу.

Вадим: Да, это отличный подход в случае, если есть контроль над хранилищем, но здесь не учитываются побочные эффекты для внешних систем.

Если данные отправлены сторонней системе, исправить их может быть невозможно. Мартин: Это верно. Когда создаётся квартальный отчёт, фиксируется состояние всех сделок на конец квартала, доход и прибыль рассчитываются, опираясь на эти показатели. Но это та же ситуация, с которой сталкиваются в бухгалтерском учёте. В этом случае бухгалтеры учитывают её в следующем квартале как поправку к предыдущему. Но иногда данные о некоторых транзакциях приходят с запозданием (скажем, кто-то забыл отдать квитанцию), хоть сама транзакция и относится к предыдущему кварталу. В бухгалтерском учёте этот подход применяется столетиями — столько, сколько существует сам бухгалтерский учёт. Обычно такие изменения составляют незначительную сумму и никаких ошибок из-за этого не возникает, при этом в конечном итоге учитывается правильная сумма. Думаю, мы можем перенять этот опыт и применить тот же подход для других типов систем хранения данных, то есть нам нужно признать, что цифры в основном верны, но не на 100%, точные цифры могут стать известны лишь позднее.

Это новый подход к написанию систем. Вадим: Интересно.

Примечание редакции: Год назад Владимир Красильщик про это делал доклад.

Мартин: Да, это не вполне обычный взгляд на вещи, и на первый взгляд он может приводить в замешательство. Но я боюсь, что другого пути нет — наше знание о всём состоянии мира неизбежно неточное, при работе с распределёнными системами от этого никуда не уйти. И эта неточность обязательно вскрывается при обработке данных.

Конференция Hydra 2019, профессиональный рост и развитие

Вадим: Как вам кажется, насколько важны конференции вроде Hydra? Ведь все распределённые системы очень разные, и мне сложно представить, что все участники после конференции сразу начнут применять на практике новые подходы, о которых они узнали. 

Скорее речь идёт о способах мышления о системах и о софте. Мартин: Тема действительно широкая, но, на мой взгляд, значительная часть интересных подходов в области распределенных систем относятся скорее к концептуальному уровню, то есть это не прямые указания «используй эту базу данных» или «используй эту технологию». Если честно, мне не так уж и важно, узнают ли участники о каком-то новом языке или инструменте; значительно важнее, на мой взгляд, чтобы они узнали о том, как мыслить о системах, которые они создают.  Такого рода идеи могут иметь довольно широкое применение.

Ведь во втором случае можно значительно более подробно осветить тему. Вадим: Если речь идёт о настолько сложных темах, как та, которую вы будете обсуждать в своём докладе, то в чём преимущество докладов на конференции перед публикацией в научном журнале? Или вы считаете, что необходимо делать и то, и другое?

В публикации можно очень подробно, точно и достоверно проанализировать проблему. Мартин: Я думаю, что публикации и доклады преследуют разные цели. Мне нравится посещать конференции отчасти именно из-за обсуждений после докладов. Доклад скорее служит для того, чтобы заинтересовать этой темой других людей и инициировать дискуссию. И размышляя над их проблемами, я сам узнаю для себя много нового. Ко мне постоянно подходят люди из аудитории и говорят, что они что-то подобное уже пробовали, но при этом наткнулись на такие-то проблемы. Но в основе своей выступление на конференции — скорее введение в проблему, а публикация — глубокий анализ довольно узкого вопроса. Для меня это важная причина выступать на конференциях: я учусь на опыте других людей и делюсь своим опытом, если он полезен другим людям. Так что, на мой взгляд, это очень разные жанры, и нам нужны они оба. 

Что вы делаете для своего профессионального роста как исследователя и разработчика? Вадим: И последний вопрос. Возможно, вы могли бы порекомендовать какие-либо конференции, блоги или сообщества для тех, кто хочет развиваться в области распределённых систем?

Интересных материалов есть множество. Мартин: Отличный вопрос. В книгах, в том числе в моей, можно найти как введение в тему, так и ссылки на другие исследования для дальнейшего чтения. Например, в онлайне выложено много записей выступлений на конференциях. Но помимо этого очень важно также самостоятельно писать системы и смотреть на практике, как они работают, а также делиться опытом с другими людьми. Если возникают какие-то вопросы — можно пройти по ссылкам. Но общаться можно и другими способами, например, в Slack есть канал для людей, которым интересны распределённые системы. Отчасти именно этим полезны конференции: живым общением. В общем, единственно правильного способа учиться не существует, нужно выбирать тот, который лучше подходит именно вам. Наконец, вам ничто не мешает перенимать опыт у коллег в компании, где вы работаете.

Вадим: Спасибо большое за ценные советы и интересную дискуссию. 

Мартин: Пожалуйста, очень рад был с вами побеседовать.

Вадим: Отлично, тогда до встречи на конференции!

Когда вы будете писать комментарии — помните, что Мартин их не прочитает. Напоминаю, что это предварительно записанное интервью. Если вам действительно хочется пообщаться с автором, то он будет с докладом «Syncing data across user devices for distributed collaboration» на конференции Hydra 2019, которая пройдёт 11-12 июля 2019 года в Санкт-Петербурге. Мы можем только передать что-то самое интересное. Билеты можно приобрести на официальном сайте.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть