К основному содержимому
к выпуску
Конспект выпуска2023Fellow

Distributed Systems — выпуск 1

Клуб начинает год книгой Таненбаума и ван Стина Distributed Systems и сразу берёт четвёртое издание, вышедшее буквально на днях. Ведущие Александр Поломодов, Илья и коллеги зовут двух гостей — Антона, чьи команды делают сервисную платформу мобильного и интернет-банка, и второго Сашу из страховой — и разбирают первую главу.

Code of Architecture · книжный клуб7 минут

Конспект сокращён относительно полного выпуска; примеры и оценки передают опыт и позиции участников.

Основная линия материала
01

Четвёртое издание и спор об определениях

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

Самое важное в главе — определения. Авторы троллят привычную картинку с тремя графами и предлагают смотреть не на неё, а на две точки зрения: либо мы соединяем уже существующие части, и это история про интеграцию, либо подключаем к своей системе внешние ресурсы, когда своих мощностей не хватает. Первый путь, по новому наблюдению авторов, ведёт к децентрализованным системам, второй — к распределённым, а определения различаются одним словом: в децентрализованной процессы и ресурсы обязательно распределены по нескольким компьютерам, в распределённой достаточно, чтобы они были распределены. На начало главы ушло двадцать минут эфира: один участник читает «необходимо» как минимальные требования, а «достаточно» как рекомендованные, будто в играх; другой выводит, что любая децентрализованная система распределённая, но не наоборот; Александр замечает, что в математике эти слова работают наоборот, и это путает. Определение из третьего издания, принесённое зрителями в комментарии, — набор автономных элементов, который выглядит для пользователя единой системой, — участникам нравится больше.

02

Проблемы распределённости и цели дизайна

Новое издание жёстче спрашивает, нужно ли вам вообще распределять, — почти «не навреди», потому что вреда от ненужной распределённости нанесли много. Проблем авторы называют четыре: множество зависимостей, когда изменение одного компонента задевает остальные; сложность поиска ошибок, среди которых различают постоянные и «мигающие» — пример с плохим контактом, который в одну погоду пропускает сигнал, а в другую теряет пакеты; сложность поддержки множества компонентов и необходимость автоматического управления; административные границы, потому что, проникнув в один компонент, злоумышленник дотянется до остальных. Участники добавляют своё: при автоматическом восстановлении, когда один микросервис подхватывает функции другого, пропадает быстрая обратная связь — вместо пожара медленная деградация, которую без наблюдаемости можно не замечать полгода. Отсюда любимая шутка одного из ведущих: у централизованной системы одна точка отказа, а у распределённой их много, и взаимодействие отказов даёт undefined behavior. Антон возражает книге: терминология академическая, на практике вопрос, распределённая у него система или децентрализованная, не возникал ни разу.

Целей дизайна теперь шесть вместо четырёх, но перечислены они по одной, без анонса, и в тексте даже уцелел абзац из третьего издания со старым числом. Шаринг ресурсов — про лёгкий доступ к данным и экономику: общая система дешевле, чем отдельная на каждого пользователя; примеры — Miro с бесконечной доской, Zoom и StreamYard, выстрелившие в пандемию, peer-to-peer-сети и решения уровня Dropbox. Distribution transparency сначала путает: цель звучит как «скрыть от пользователя распределённость», а смысл — в едином фронте, когда не нужно заводить аккаунты в разных местах. Александр показывает обратную сторону: старые RPC, где локальный на вид вызов оборачивался сетевым запросом, ответа можно было ждать минутами, а потерянное сообщение давало лютые ошибки; если семантика удалённого вызова важна потребителю, прятать её не стоит. Открытость — про лёгкость интеграции и замены: двигатель, из которого можно собрать другой, и башенка из Lego, где к готовым кубикам дописываешь три новых.

03

Надёжность, масштабирование и заблуждения

Термин dependability один из участников впервые прочитал в этой книге, и помогло разложить его на знакомые части и сравнить с доверием к сервису. Availability считается по времени: 364 дня из 365 — это почти 0,3 процента простоя, а соблюдение SLA сервисами внутри компании считает отдельная система поверх мониторинга. Reliability измеряют не долей времени, а тем, сколько система пробежит без сбоев, — если течёт память и раз в два месяца её приходится перезагружать. Safety важна там, где на кону жизнь: у одного из участников жена диабетик, и сбой её инсулиновой помпы опасен, поэтому в медицине, как в космосе, цикл выпуска устройств очень долгий, а у военной ракеты запас прочности измеряется единицами процентов. Maintainability развязывает руки: совокупная стоимость владения — это в основном поддержка, и продукт, собранный на скорую руку, придётся долго переделывать. Security в первой главе новая: аутентификация нод, авторизация действий, доверие между нодами, TLS и ключи, а на главу о безопасности в конце книги Александр позвал главного безопасника компании.

Масштабирование идёт по трём направлениям — размер, география и администрирование; последнее далось ведущему хуже всего, потому что там уже не техника, а договорённости между организациями. С географией меняется многое: вместо локальной сети с малой задержкой появляется интернет, теряется, например, broadcast, и нужны механизмы регистрации сервисов и адресной рассылки, а размер закрывают scaling up и scaling out. Александр вспоминает закон Литтла: при утилизации, стремящейся к единице, время ответа уходит в бесконечность, так что предсказуемый отклик и максимальная утилизация несовместимы. Техники масштабирования — скрытие задержек, где вместо посимвольной проверки на сервере делают проверку на клиенте и валидацию всего батча на сервере, который всё равно не доверяет клиенту; партиционирование, как дерево DNS; репликация; кэширование как её частная форма, где политику задаёт клиент. За репликацией сразу приходит консистентность, которой посвящена отдельная глава. Заблуждения о сети авторы приводят стандартным списком, а Алекс Петров в своей книге добавляет к нему время обработки, рассинхронизацию часов, частичные отказы и каскадные сбои, любимый пункт одного из ведущих. Финальный совет: книга бесплатна, качайте свежую версию с сайта авторов и не останавливайтесь на первой главе.

Выводы

Что стоит унести с собой

  1. 01Децентрализованная и распределённая системы у авторов различаются одним словом: в первой процессы и ресурсы обязательно распределены по нескольким компьютерам, во второй достаточно, чтобы они были распределены.
  2. 02Четыре проблемы распределённости — зависимости, «мигающие» ошибки, поддержка множества компонентов и административные границы; участники добавляют пятую: медленную деградацию, которую скрывает автоматическое восстановление.
  3. 03Dependability раскладывается на availability, reliability, safety и maintainability, а в четвёртом издании к целям добавилась безопасность: аутентификация нод, авторизация действий и доверие между ними.
  4. 04При утилизации, стремящейся к единице, время ответа уходит в бесконечность, поэтому масштабирование — это скрытие задержек, партиционирование, репликация и кэширование, за которыми сразу встаёт вопрос консистентности.

Источники