Continuous Architecture in Practice — выпуск 3

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

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

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

Один из участников предлагает не спорить, где кончается масштабируемость и начинается производительность, а описывать сценарии атрибутов качества целиком — что за тип, чего мы ждём, как он будет эволюционировать — и проверять их фитнес-функциями; он ссылается на книгу Requirements Engineering for Software and Systems Филипа Лапланта, показавшуюся ему академичной, а ведущий честно отвечает, что ничего не понял, и просит потом дать ссылку. Список тактик — разделить клиентов по инстансам, завести мастер и реплики, разнести сервисы по доменам — участники называют банальным: про доступность ни слова, а за квадратиками и цилиндриками прячутся сложные решения. Александр приводит инженерную статью Ozon про кэши: мастер-системы, которые сами масштабируются плохо, выживают под пиками порядка 350 Гбит/с, но стратегия кэширования централизована, и теперь команда обязана знать про кэши соседей — вложенный параметр с локалью способен отдать русским пользователям китайские ответы. Инженерно задача решена, организационно вышла та же беда, что с централизованным DWH.

Дальше — базы и облака. В кейсе книги для аналитической реплики выбирают нативную репликацию вместо событий через брокер, потому что так дешевле и не нужна лишняя сериализация, и решают, что года два альтернативы можно не пересматривать; про синхронность репликации не сказано ни слова. Партиционирование авторы советуют откладывать до последнего, и участники соглашаются: оно превращает систему в распределённую. Зато не разобрано, до каких пор базу можно растить вертикально, — вопрос живой, пока тебе продают Oracle с почти бесконечным вертикальным ростом и оперативной памятью в терабайтах, после которого переезд на другую технологию превращается почти в полное переписывание. У облака в книге две правильные оговорки, которые стоило бы выделить красным: по деньгам легко улететь в трубу, а лимиты есть и у провайдера — их согласование через менеджера занимает до суток, ровно когда клиенты уже пришли. Serverless участники вспоминают как абсолютный vendor lock-in: в статье Amazon, по памяти рассказчика, видеоаналитику на лямбдах в итоге переписали обратно в распределённый монолит.

Вторую половину эфира занимает производительность, и ведущий успокаивает слушателей: достаточно мысленно заменить масштабируемость на перформанс, отличий там пара критериев. Метрики авторы делят на время со стороны пользователя и пропускную способность; участники добавляют, что бороться за хвост распределения очень дорого и части клиентов иногда дешевле отдать заглушку с просьбой зайти чуть позже. Про сеть в таких разговорах забывают зря: биржи пишут собственные драйверы сетевых карт, а на NASDAQ самый быстрый канал до сервера — радио, стойки стоят в том же помещении, и round-trip укладывается в полсотни микросекунд. Нагрузочное тестирование за определённым числом rps упирается в цену: прод-подобного стенда нет, приходится экстраполировать, а функция роста только кажется линейной. Отсюда просьба называть это не мониторингом, а observability, и совет гонять бенчмарки новой базы на своих сценариях, помня, что чинить её ночью тоже кому-то придётся. Следующий эфир — про надёжность и circuit breakers.