Цифры latency, которые должен знать каждый программист.

Наткнулся в очередной раз на ссылку с цифрами времен задержек ответов от разных ресурсов.

Из интересного:
— 0.5нс — ответ от кэша первого уровня (L1)
— 7нс — ответ от кэша второго уровня (L2)
— 25нс — взять мьютекс
— 100нс — ответ от оперативной памяти
— 500,000нс (0.5мс) — round trip в том же датацентре
— 150,000,000нс (150мс) — отправить пакет CA->Netherlands->CA

Прочитать 1мб:
— 0.4мс — с оперативной памяти
— 1мс — с SSD
— 20мс — с HDD

https://gist.github.com/jboner/2841832

Архитектура распределенных систем или как пройти System Design интервью.

Недавно выступал с лекцией в МГУ "Архитектура распределенных систем на примере задачи о назначении в такси". Была цель объяснить базовые принципы и заодно дать какой-то понятный план того, что интервьюер ждет от кандидата на архитектурной секции. Получилась вполне самодостаточная подсказка.

4 августа в Москве будет Plus Camp - эвент для техлидов и тимлидов, который устраивают наши сервисы Яндекса Go и Плюс.

Я буду участвовать в подкасте, где расскажу про алгоритмы под капотом Яндек Go.
А еще в дебатле с Женей Смирновым @not_boring_ds, руководителем ML лаборатории в Альфа-Банке почеледжу миф о том, что программистов скоро заменит ИИ.

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

Хоть меня и попросили опубликовать этот пост наша devrel команда, это не отменяет крутости этого мероприятия, с кем-то встретимся на Белорусской, а для других опубликую запись подкаста про алгоритмы, не пропустите.

Инструменты для большой миграции на примере опыта Netflix с GraphQL
https://netflixtechblog.com/migrating-netflix-to-graphql-safely-8e1e4d4f1e72

На глаза попалась череда статей Netflix о переезде на GraphQL. Если хочется углубиться во все детали, то в конце поста все релевантные ссылки. Я же хочу вынести ключевые, как мне кажется, инструменты, которые могут пригодиться для большой миграции. Будь это какие-то технические или продуктовые изменения, рецепты того, как раскатывать большие фичи, примерно одинаковые, но будут на примере опыта из статей с GraphQL.

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

1. АБ-тестирование.
Нетфликс берет две равные аудитории клиентов: по 1 млн пользователей. Первая группа пользуется старым API, на вторую включается клиент с походом в GraphQL. Тестируется именно клиентская часть — клиент сам выбирает куда идти. На какие метрики смотреть: сравнение рейта ошибок на обоих группах, задержек итп. На клиентах замеряется и сравнивается метрика QoE (оценка качества восприятия пользователем).

2. Replay Testing — валидация на масштабе.
Если запросы клиентов идемпотентны, то можно перед двумя решениями поставить Gateway, который будет ходить в оба решения и сравнивать результаты. На примере Netflix, оба решения должны базово давать одинаковые результаты, поэтому достаточно просто было найти, в каких случаях новое решение на GraphQL дает ответ, отличающийся от легаси решения (просто сравнивая и логируя json’ы от обоих решений).

3. Sticky Canary
Хз как точно перевести. Решение очень похожее на AB тестирования, но только со стороны бекенда: для новой схемы на бекенде заводится отдельный кластер для нового решения и Gateway (который умеет роутить на старое или новое решения). Пользователи при этом “приклеиваются” к одному из кластеров и живут на нем. На что смотреть: в сравнении по кластерам задержки, рейты ошибок, логи, утилизацию ресурсов, QoE, другие метрики здоровья сервиса.


— о миграции Netflix на GraphQL
— о предпосылках к GraphQL
— о миграции более подробно часть 1
— о миграции более подробно часть 2

Как по закону Конвея можно зафакапить внедрение DDD.

Мы пишем микросервисы. Дальше еще больше микросеврисов, затем еще и еще до того момента как общая картинка перестает умещаться в голове даже самого опытного инженера. А как мы знаем, любую архитектурную проблему можно решить дополнительным слоем абстракции. Появляется идея внедрить DDD.
DDD — не новая методология, о который мы тут не так часто говорим, но которая призвана, добавив слой абстракции (домены), снизить связанность, возвести заборы (bounded context) и открыть новые возможность масштабирования.
С помощью DDD хочется порешать сразу несколько проблем:
— Cильная связанность микросервисов.
— Отсутсвие Observability.
— Проблемы нечетких зон ответственности.
Дальше идут классические подходы к выделению доменов — задача декомпозируется, делегируется командам и те идут дизайнить свое виденье бизнес-сущностей.

В чем ту проблема? Стоит обратиться к классическому закону Конвея:
Современная его трактовка  — «Если архитектура системы и архитектура организации противоречат друг другу, победу одерживает архитектура организации» (по версии Рут Малан).

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

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

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

https://www.uber.com/en-GB/blog/microservice-architecture/
https://cleverics.ru/digital/2020/12/conways-law-importance-teams-design/

Strangler Pattern

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

Основная идея паттерна состоит в том, что вы не беретесь “переписывать” весь монолит за раз, а просто блокируете написание новой функциональности в нем.

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

Дополнительные затраты на вынос старой логики из монолита размазываются во времени и не сильно влияют на time-to-market продукта.

Через какое-то время монолит переписывается, зоны ответственности разъезжаются по микросервисам, снижается связанность.

Есть минусы/консерны у подхода, заслуживающие внимания:
— Большая фича в новой концепции может стоить очень дорого из-за того, что придется переписать большой кусок монолита.
— Можно неправильно выделить зоны ответственности из монолита, потому что будет желание “переписать поменьше”.
— Дополнительно могут возникать затраты на вынос из монолита зон ответственности, от которых ваша функциональность зависит, например, хранилища каких-то данных.

https://microservices.io/patterns/refactoring/strangler-application.html
https://serverspace.ru/about/blog/pattern-mikroservisa-strangler/
https://www.geeksforgeeks.org/strangler-pattern-in-micro-services-system-design/

Яндекс всё.

Пару недель назад я сдал бейдж. 7 лет назад я стоял у истоков Яндекс Go, мы прошли большой и тернистый путь роста от стартапа в рамках всей компании до большого энтерпрайза с 44 млн MAU. А пару недель назад я, как CTO Go New Ventures, отвечал за запуски новых стартапов, уже внутри Яндекс Go - такая спираль, которая прокрутилась на 360.
И как говорится - пришло время выходить из зоны комфорта и двигаться дальше.
Для канала - это значит новый виток. Моя новая роль, ради которой я оставил Яндекс, подразумевает еще больше свежих взглядов и смелых решений - контента, которым я хотел бы продолжать тут делиться.

Stay tuned. Если интересно продолжение персональной истории - ставьте лайк. Если нет - новый пост уже на подходе. Делитесь ссылкой на канал с коллегами @startup_architecture - рост числа читателей сильно мотивирует писать.

Антологии технологий Яндекс Такси про изнанку сервиса.

Записали серию Антологии Такси о том, как работает Яндекс Go под капотом. Я даже попытался показать схематично на доске как все работает на уровне микросервисов.

Кстати, местный мем: когда я 7 лет назад пришел в такси, мы решили нарисовать все микросервисы Такси на стене кухни (БЦ Аврора на Павелецкой) со всеми связями между ними. Спустя пару часов мы израсходовали всю стену и бросили эту идею. Через пару дней схема уже была outdated. Но до сих пор по чатам гуляет фотография этой стены с 20-30 микросервисами. С тех пор их количества выросло до примерно 1000 штук. Надеюсь, ни у кого похожей идеи визуализации не возникает.

https://www.youtube.com/watch?v=GR7za5CWpxA

System Design Master Template.
https://medium.com/javarevisited/how-to-crack-system-design-interviews-in-2022-tips-questions-and-resources-fcad05e2dab

Нашел интересную картинку — шаблон дизайна плюс-минус любой системы. Поможет как с точки зрения ничего не забыть при проектировании "cтандартного" сервиса, так и к собеседованию по архитектуре подготовиться.

PS: если у вас есть другие полезные макеты по теме, поделитесь в комментариях.

Если хочется копнуть глубоко в тему архитектуры, то вот большой репозиторий с актуальными концептами системного дизайна:
https://github.com/ByteByteGoHq/system-design-101

Software Architecture and Design Trend 2023.

Наткнулся на исследование архитектурных трендов 2023 года. Почему это важно, если год почти закончился? Чтобы технологиях или практика стала инструментом большинства, она должна пройти через все стадии жизненного цикла продукта (по Роджерсу). То, чем пользуются сегодня только инноваторы, завтра может стать стандартом индустрии. Поэтому важно смотреть на то, какие технологии и практики в этом году вошли в стадии Innovators и Early Adopters.

Innovators:
— LLM или большие языковые модели окажут значительное влияние: от помощи в понимании архитектурных компромиссов до расширения возможностей нового поколения low-code и no-code разработчиков.
— Software Supply Chain Security или Безопасность цепочки поставки ПО.
— Design for Sustainability — нацеленность на снижение углеродный след (как часто лично вы задумываетесь? Что по утилизации ресурсов?)
— GraphQL Federation
— Policy as Code
— HTTP/3
— dApps — децентрализованные приложения.

Early Adopters или получающие распространение:
— Design for Portability получает все большее распространение (такие платформы как Dapr ориентированы на то, чтобы дать архитекторам возможность еще больше абстрагироваться от деталей реализации).
— Data-Driven Architecture — архитектура, управляемая данными.
— Architecture as a Team Sport — архитектурура больше не задача “Архитекторов”, а командная работа. Широкое признание ADR как способ работы команды над архитектурой приложения.
— WebAssembly (Server-side and Client-side)
— Design for Security
— Design for Resilience
— Design for Observability
— Micro Frontends
— AsyncAPI
— Workflow and Decision Automation Platforms
— Low Code / No Code

https://www.infoq.com/articles/architecture-trends-2023/
https://danielfoo.medium.com/software-architecture-and-design-trend-2023-f55ecfbcfcc0

What’s next?

В октябре прошлого года я оставил Яндекс позади. Наверное, пришло время сформулировать продолжение...
Я, в роли технического директора, присоединился к очень крутой команде AI-Center Тинькофф.

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

GPT как оркестратор микросервисной архитектуры?

Мы знаем, что GPT-модели могут писать SQL-запросы или код. Новая парадигма — А что если GPT будет формировать пользовательский флоу в архитектуре нашего сервиса?

Как выглядит шаблонный сервис? Какое-то количество микросервисов, которые ходят друг в друга, предоставляют интерфейсы, за ними какие-то базы данных итп. Пользовательский флоу в этой парадигме — это цепочка каскадных запросов в череду таких микросервисов.
Оркестраторы таких сценариев — это обычно написанная бизнес-логика с кучей if-ов.

Что если мы опишем базовые функции нашего сервиса и дадим GPT возможность самому конструировать пользовательские сценарии?

Я решил сделать сервис заказа еды. У меня есть несколько функций системы, про которые я рассказываю ассистенту:
- make_order([{item, count}])
- cancel_order…
Дальше я прошу ассистента обслужить пользователя — GPT может самостоятельно составить цепочку вызовов, которые нужно совершить для того, чтобы понять, что хочет пользователь, и сходить в нужные сервисы.
GPT выступает как замена части бизнес-логики приложения, отвечающей за формирование пользовательского пути по вашей архитектуре.
Просто посмотрите пример.

Такое становится доступным благодаря подходу RAG (Retrieval-Augmented Generation), когда обученной на большой базе знаний модели (GPT) на вход подсовывают динамический контекст (описание сервиса заказа еды). Если хочется начать углубляться — можно начать отсюда: https://habr.com/ru/articles/779526/

Как вы используете GPT-ассистентов? Спрашиваете советы или строите поверх системы и продукты?

Подход Change Data Capture как способ реактивного взаимодействия сервисов.
https://habr.com/ru/companies/yandex_cloud_and_infra/articles/754802/

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

Для решения подобных задач на помощь приходит подход Change Data Capture (CDC) или “Захват изменения данных”.

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

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

С применением этого подхода можно реализовать несколько популярных паттернов, таких как CQRS (чтобы развязать потоки чтения и модификации данных) или Strangler (чтобы распилить монолит на микросервисы).

Какую функциональность можно реализовать с помощью этого подхода:
— Репликация (Другая БД? DWH?)
— Обновление и инвалидация кэшей
— Экспорт данных в поисковые движки (Elastic?)
— Аудит изменений в БД
— Передача состояния другим сервисам

https://habr.com/ru/companies/yandex_cloud_and_infra/articles/754802/
https://en.wikipedia.org/wiki/Change_data_capture

ArchGPT — Архитектура с помощью GPT.

Давно думал, как подступиться к этому вопросу — как заставить GPT дизайнить архитектуру? Чтобы получше, чем качество уровня рандомного человека с улицы.
Пока не наткнулся на интересную статью https://www.accidental-architect.com/archgpt

Идея в следующем — если мы можем представлять нашу архитектуру как “код” (в статье приводится пример с моделью С4 — способ записи архитектуры системы в виде “контекст-контейнер-компонент-код”), то GPT может отлично понимать такой формат.

Тогда задача системного дизайна сводится к задаче “кодогенерации”, которую GPT умеет решать. В статье, например, приводится пример с тем, что GPT спросили, как перейти с json на protobuf. Модель подсказала, какие изменения в каких системах это повлечет, и как изменится сам документ архитектуры.

В дополнение получаем новый тип интерактивной документации.

Если подумать, как правильно прикрутить RAG, можно делать совсем интересные вещи.

Сборник постов с паттернами и подходами к построению системного дизайна.

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

Application architecture:
— Domain Driven Design (DDD)
— Как по закону Конвея можно зафакапить внедрение DDD
— Симптомы распределенного монолита

Обеспечение консистентности данных:
— Materialized View
— Целостность данных в микросервисах
— Кэширование
— Event Sourcing
— Event-based Microservices: обработка ошибок
— Saga

Querying:
— API Composition / API Gateway
— CQRS (Command and Query Responsibility Segregation)
— GraphQL

Reliability:
— Circuit breaker
— Rate limiting с Congestion Control

Deployment:
— Sidecar: Библиотка VS Сервис VS Сайдкар
— Plug-in Архитектура
— Consistent hashing
— Шардирование по географии - плохое решение

Refactoring:
— Strangler Pattern

Cell-based Architecture.
https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/why-to-use-a-cell-based-architecture.html

Согласно последнему отчету об архитектурных трендах от infoq, набирает популярность подход Cell-based Architecture или Клеточная Архитектура. О нем сегодня и поговорим.

Подход основан на особых принципах разделения микросервисов. Ячейки представляют собой группу инстансов микросервисов, которые обрабатывают изолированные end-to-end части сценариев работы сервиса. Например, ячейка может обслуживать конкретный регион, определенные сценарии или категории пользователей.

Рассмотрим пример классической микросервисной архитектуры:
— Есть микросервис A, обрабатывающий весь пользовательский трафик, состоящий из сотен инстансов, развернутых в разных локациях. Он ходит в микросервис B.
— Микросервис B, тоже сотни инстансов, использует базу данных, также шардированную по локациям.
Проблемы: возникает много долгих кросс-дц запросов, проблемы в одном микросервисе или базе приводят к невозможности обработать весь пользовательский трафик.

Клеточная архитектура предлагает одно из возможных решений:
Выделить инстансы микросервисов A, B и шарды данных в отдельные ячейки таким образом, чтобы они end-to-end обслуживали один пользовательский регион или один продуктовый сценарий.

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

Для продолжения углубления советую статью VK про их вариант адаптации подхода:

https://habr.com/ru/companies/vk/articles/807685/
https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/why-to-use-a-cell-based-architecture.html
https://github.com/wso2/reference-architecture/blob/master/reference-architecture-cell-based.md
https://habr.com/ru/companies/otus/articles/808205/

Bulkhead.
https://en.wikipedia.org/wiki/Bulkhead_(partition)

Поговорим сегодня о кораблях. Когда готовил прошлый пост про Cell-Based Architecture наткнулся на новый термин — “Переборка” или “Bulkhead”.

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

Интересно наблюдать как инженерные решения из оффлайнового мира перекочевывают в IT — Bulkhead Pattern или Cell-Based Architecture.

https://bool.dev/blog/detail/bulkhead-pattern
https://ru.wikipedia.org/wiki/Переборка
https://news.1rj.ru/str/startup_architecture/96
https://learn.microsoft.com/en-us/azure/architecture/patterns/bulkhead

InfoQ Software Architecture and Design Trends Report - April 2024
https://www.infoq.com/articles/architecture-trends-2024/

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

— Cell-Based архитектура как попытка увеличить надежность больших и сложных систем и снизить затраты с помощью разделения микросервисной архитектуры по пользовательским сценариям и зонам доступности. Подробнее в прошлом посте. В качестве инноваторов — Roblox, Slack, DoorDash.
— Privacy engineering. Компании меняют свой майндсет с реактивного подхода в следовании законам о пользовательских данных, например GDPR, на более проактивный подход и закладывают все требования в начальном проектировании. Кажется, что в России с законами о ПД происходит та же смена майндсета.
— Social-technical architecture. Более конкретный подход пришел на замену немного невнятному “Architecture as a Team Sport”. Смысл его в размывании роли архитектора. Больше компаний приходит к тому, что архитектурные решения должны принимать все, кто причастен к созданию и поддержке систем.
— LLM стремительно проходит адаптацию, и еще больше компаний ищут применение, которое может стать геймченджером в конкретной индустрии. Скорее всего, у вас тоже в продукте есть стрим про то, как можно использовать LLM. При этом дальше чатботов и RAG дело мало у кого доходит.
— Platform architecture я бы объединил с Low/No code и подчеркнул, что последние годы идет нескончаемый тренд на понижение планки входа в IT. Затраты на разработку всегда были большими, это большой и сочный кусок PnL, вокруг которого постоянно появляются и исчезают новые платформенные решения. Рано или поздно все будем писать на JS.

Отчет — https://www.infoq.com/articles/architecture-trends-2024/
Подкаст — https://www.infoq.com/podcasts/infoq-architecture-trends-2024/
Отчет за 2023 — https://news.1rj.ru/str/startup_architecture/88

Как Netflix обеспечивает высокую доступность stateful системам.

Вышла очень интересная статья Нетфликса о доступности в распределенных stateful системах. Всем рекомендую к прочтению.

Сервисы могут иметь одинаковое количество "девяток", но разные причины падений и методы повышения надежности. Например, один сервис редко падает, но долго восстанавливается, другой часто падает, но быстро восстанавливается — у них одинаковая метрика доступности, но разные подходы к улучшению надежности.

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

И дальше нужно сфокусировать ресурсы на конкретные пункты в зависимости от ваших потребностей (например, хороший компромисс, когда система часто выходит из строя, но не причиняет ущерба большому числу клиентов). В статье приводится множество методов, чтобы заставить эти метрики двигаться в нужном направлении.

https://www.infoq.com/articles/netflix-highly-reliable-stateful-systems/

@startup_architecture