Распределённые системы *

TL;DR: Описание клиент-серверной архитектуры нашей внутренней системы управления конфигурацией сети, QControl. В основе лежит двухуровневый транспортный протокол, работающий с упакованными в gzip сообщениями без декомпрессии между эндпойнтами. Распределенные роутеры и эндпойнты получают конфигурационные апдейты, а сам протокол позволяет установку локализованных промежуточных релеев. Система построена по принципу дифференциального бэкапа (“recent-stable”, объясняется ниже) и задействует язык запросов JMESpath вместе с шаблонизатором Jinja для рендера конфигурационных файлов.

Qrator Labs управляет глобально распределенной сетью нейтрализации атак. Наша сеть работает по принципу anycast, а подсети анонсируются посредством BGP. Будучи BGP anycast-сетью, физически расположенной в нескольких регионах Земли мы можем обработать и отфильтровать нелегитимный трафик ближе к ядру интернета — Tier-1 операторам.

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

В начале было Слово. Оно быстро стало коммуникационным протоколом, нуждающимся в апдейте.

Ни для кого не секрет, что один из общераспространенных вспомогательных инструментов, без которого невозможна защита данных в открытых сетях, — это технология цифровых сертификатов. Впрочем, не является секретом и то, что главный недостаток это технологии — безусловное доверие к центрам, выпускающим цифровые сертификаты. Директор по технологиям и инновациям компании ENCRY Андрей Чмора предложил новый подход к организации инфраструктуры общедоступных ключей (Public Key Infrastructure, PKI), который поможет устранить существующие в настоящее время недостатки и который использует технологию распределенного реестра (блокчейна). Но обо всем по порядку.

Или как мы писали клиентскую C++ библиотеку для ZooKeeper, etcd и Consul KV

В мире распределённых систем существует ряд типовых задач: хранение информации о составе кластера, управление конфигурацией узлов, детекция сбойных узлов, выбор лидера и другие. Для решения этих задач созданы специальные распределённые системы — сервисы координации. Сейчас нас будут интересовать три из них: ZooKeeper, etcd и Consul. Из всей богатой функциональности Consul мы сосредоточимся на Consul KV.



По сути все эти системы представляют собой отказоустойчивые линеаризуемые key-value хранилища. Хотя их модели данных и имеют существенные отличия, о чём мы поговорим позднее, они позволяют решать одни и те же практические проблемы. Очевидно, каждое приложение, использующее сервис координации, завязывается на один из них, что может приводить к необходимости поддерживать в одном датацентре несколько систем, решающих одинаковые задачи, для разных приложений.

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

Традиционно ИТ-системы предприятий формировались под задачи автоматизации, поддержки целевых систем, таких, например, как ERP. Сегодня организациям приходится решать иные задачи – задачи цифровизации, цифровой трансформации. Делать это на основе прежней ИТ-архитектуры сложно. Цифровая трансформация — серьезный вызов.

На чем же должна основываться программа преобразования ИТ-систем с целью цифровой трансформации бизнеса?

Знаю-знаю. Криптопроектов тьма, есть куча консенсусов: на основе труда и владения, золота, нефти, выпеченных пирожков (есть и такой, да-да). Что нам ещё от одного? Это и предлагаю обсудить после прочтения перевода "облегченной" технической документации проекта *Созвездие (Constellation). Конечно, это не полное описание алгоритма, но мне интересно мнение комьюнити хабра, имеет ли место "быть" такому консенсусу или он даром не нужен?

Дальше букв не много, поэтому, если вам просто хочется написать "фу, сколько можно о крипте", то, пожалуйста, воздержитесь. Если вам интересны новые разработки в сфере распределенных систем и есть, чем поделиться в комментариях, то прошу под кат.

P.S. Я не автор технологии, за полную передачу сути ручаться не могу, поэтому буду рад комментариям с поправками, если такие будут.

Совсем недавно, с 8 по 12 июля, одновременно проходило два знаковых события — конференция Hydra и школа SPTDC. В этом посте хочется отметить несколько особенностей, которые мы заметили по ходу проведения конференции.

Самая большая гордость Гидры и Школы — это докладчики.

• Три лауреата премии Дейкстры: Leslie Lamport, Maurice Herlihy и Michael Scott. Причём Морис получил её целых два раза. Лесли Лэмпорт получил еще и премию Тьюринга — самую престижную премию ACM в информатике;
• Создатель JIT-компилятора Java — Cliff Click;
• Разработчики корутин — Роман Елизаров (elizarov) и Никита Коваль (ndkoval) для Kotlin, и Дмитрий Вьюков для Go;
• Контрибьюторы в Cassandra (Алекс Петров), CosmosDB (Денис Рысцов), Yandex Database (Семен Чечеринда и Владислав Кузнецов);
• И множество других известных людей: Martin Kleppmann (CRDT), Heidi Howard (Paxos), Ori Lahav (C++ memory model), Pedro Ramalhete (wait-free data structures), Алексей Зиновьев (ML), Дмитрий Бугайченко (анализ графов).

Несколько дней назад случилась конференция Hydra. Ребята из JUG.ru Group пригласили спикеров мечты (Лесли Лэмпорт! Клифф Клик! Мартин Клеппманн!) и посвятили два дня распределённым системам и вычислениям. Контур был одним из трёх партнёров конференции. Мы общались на стенде, рассказывали про наши распределённые хранилки, играли в бинго, решали задачки.

Это пост с разбором задач на стенде Контура от автора их текста. Кто был на Гидре — это ваш повод вспомнить приятные впечатления, кто не был — шанс размять мозги big O-нотацией.

Были даже участники, которые разобрали флипчарт на слайды, чтобы записать своё решение. Я не шучу — они сдали на проверку вот такую пачку бумаги:

Всего было три задачи:

• о выборе реплик по весам для балансировки нагрузки
• о сортировке результатов запроса к in-memory базе данных
• о передаче состояния в распределённой системе с кольцевой топологией

11-12 июля, то есть уже в этот четверг и пятницу, пройдёт конференция Hydra 2019. Это два дня и два трека докладов, посвященных распределённым вычислениям. Доклады ведут лучшие учёные и инженеры, приехавшие в Санкт-Петербург из разных стран мира. Конференция ориентирована на специалистов в области, никаких вводных докладов!

Вы сможете посмотреть совершенно бесплатную онлайн-трансляцию. На ней будет только первый день и первый зал + онлайн-интервью между докладами. Что это за доклады — обсудим чуть ниже.

Важно, что трансляция начнётся в 9:45 утра (по московскому времени), за 15 минут до открытия, и закончится ближе к 8 часам вечера. Всё это время вы сможете слушать доклады с небольшими перерывами. Ссылка будет работать весь день, поэтому можно открывать её только на наиболее важных для вас докладах.

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

Майкл Скотт — уже 34 года как профессор Computer Science в Рочестерском университетe, а в родном универститете Wisconsin–Madison был деканом в течение пяти лет. Он занимается исследованиям в области параллельного и распределённого программирования и дизайна языков и обучает этому студентов.

Мир знает Майкла по учебнику «Programming Language Pragmatics», а работа «Algorithms for scalable synchronization on shared-memory multiprocessors» получила премию Дейкстры как одна из наиболее известных в области распределённых вычислений. Также вы можете знать его как автора того самого алгоритма Майкла-Скотта.

Вместе с Дагом Ли разработал те неблокирующие алгоритмы и синхронные очереди, на которых работают библиотеки Java. Внедрение «dual data structures» в JavaSE 6 позволило в 10 раз улучшить производительность ThreadPoolExecutor.

Содержание:

• Начало карьеры, Рочестерский университет. Проект Charlotte, язык Lynx;
• IEEE Scalable Coherent Interface, блокировка MCS;
• Выживание в постоянно меняющемся мире;
• Становятся ли студенты глупее? Глобальные тренды, интернационализация;
• Эффективная работа со студентами;
• Как не отстать при подготовке новых курсов и книг;
• Связь между бизнесом и академией;
• Практическая реализация идей. MCS, MS, CLH, JSR 166, работа с Дагом Ли и многое другое;
• Транзакционная память;
• Новые архитектуры. Близкая победа транзакционной памяти;
• Энергонезависимая память, Optane DIMM, сверхбыстрые устройства;
• Следующий большой тренд. Dual data structures. Hydra.

Морис Херлихи — обладатель целых двух премий Дейкстры. Первая — за работу по «Wait-Free Synchronization» (Brown University) и вторая, более свежая, — «Transactional Memory: Architectural Support for Lock-Free Data Structures» (Virginia Tech University). Премию Дейкстры дают за работы, значимость и влияние которых были заметны на протяжении не менее десяти лет и, очевидно, Морис — один из самых известных специалистов в области. На данный момент он работает профессором в Брауновском университете и имеет множество достижений на целый абзац длиной. Сейчас он занимается исследованиями блокчейна в контексте классических распределенных вычислений.

Ранее Морис уже приезжал в Россию на SPTCC (видеозапись) и cделал отличную встречу сообщества Java-разработчиков JUG.ru в Питере (видеозапись).

Этот хабрапост  — большое интервью с Морисом Херлихи. В нем обсуждаются следующие темы:

• Взаимодействие академической сферы и индустрии;
• Фундамент для исследований блокчейна;
• Откуда берутся прорывные идеи. Влияние популярности;
• PhD под руководством Барбары Лисков;
• Мир в ожидании многоядерности;
• Новому миру – новые проблемы. NVM, NUMA и взлом архитектуры;
• Компиляторы против процессоров, RISC vs CISC, shared memory vs message passing;
• Искусство написания хрупкого многопоточного кода;
• Как обучить студентов написанию сложного многопоточного кода;
• Новое издание книги «The Art of Multiprocessor Programming»;
• Как изобреталась транзакционная память;   
• Почему стоит проводить исследования в области распределенных вычислений;
• Остановилось ли развитие алгоритмов, и как жить дальше;
• Работа в Брауновском Университете;
• Разница между исследованиями в университете и внутри корпорации;
• Hydra и SPTDC.

Redis Stream — новый абстрактный тип данных, представленный в Redis с выходом версии 5.0
Концептуально Redis Stream — это List, в который вы можете добавлять записи. Каждая запись имеет уникальный идентификатор. По умолчанию идентификатор генерируется автоматически и включает в себя временную метку. Поэтому вы можете запрашивать диапазоны записей по времени или получать новые данные по мере их поступления в поток, как Unix команда «tail -f» читает лог-файл и замирает в ожидании новых данных. Обратите внимание, что поток могут слушать одновременно несколько клиентов, как многие «tail -f» процессы могут одновременно читать файл, не конфликтуя друг с другом.

Чтобы понять все преимущества нового типа данных, давайте бегло вспомним давно существующие структуры Redis, которые частично повторяют функциональность Redis Stream.

Клифф Клик — CTO компании Cratus (IoT сенсоры для улучшения процессов), основатель и сооснователь нескольких стартапов (включая Rocket Realtime School, Neurensic и H2O.ai) с несколькими успешными экзитами. Клифф написал свой первый компилятор в 15 лет (Pascal для TRS Z-80)! Наиболее известен за работу над С2 в Java (the Sea of Nodes IR). Этот компилятор показал миру, что JIT может производить качественный код, что стало одним из факторов становления Java как одной из основных современных программных платформ. Потом Клифф помог компании Azul Systems построить 864-ядерный мейнфрейм с софтом на чистой Java, который поддерживал паузы GC на 500-гигабайтной куче в пределах 10 миллисекунд. Вообще, Клифф успел поработать над всеми аспектами JVM.
 
Этот хабрапост — большое интервью с Клиффом. Мы поговорим на следующие темы:

• Переход к низкоуровневым оптимизациям
• Как делать большой рефакторинг
• Модель стоимости
• Обучение низкоуровневым оптимизациям
• Практические примеры улучшения производительности
• Зачем создавать свой язык программирования
• Карьера перформанс-инженера
• Технические челленжи
• Немного про аллокацию регистров и многоядерность
• Самый большой челленж в жизни

Интервью ведут:

• Андрей Сатарин из Amazon Web Services. В своей карьере успел поработать в совершенно разных проектах: тестировал распределенную базу данных NewSQL в Яндексе, систему облачного детектирования в Лаборатории Касперского, многопользовательскую игру в Mail.ru и сервис расчёта валютных цен в Deutsche Bank. Интересуется тестированием крупномасштабных backend- и распределённых систем.
• Владимир Ситников из Netcracker. Десять лет работает над производительностью и масштабируемостью NetCracker OS — ПО, используемого операторами связи для автоматизации процессов управления сетью и сетевым оборудованием. Увлекается вопросами производительности Java и Oracle Database. Автор более десятка улучшений производительности в официальном PostgreSQL JDBC-драйвере.

Состоянием на июль 2019 года существует порядка 2000 криптовалют, однако единого механизма обмена между разными блокчейнами нет. В этой статье мы упрощенно рассмотрим как устроена одна из технологий обмена без посредников — атомарные обмены (atomic swaps).
Приятного чтения!

Используя nginx для балансировки HTTP трафика на уровне L7 есть возможность направить запрос клиента на следующий сервер приложений, если целевой не возвращает положительный ответ. Проба механизма пассивной проверки состояния работоспособности сервера приложений показало неоднозначность документации и специфичность работы алгоритмов исключения сервера из пула рабочих серверов.

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

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) — ведущий разработчик в команде Платформы компании Одноклассники. Научные и инженерные интересы Вадима касаются распределённых систем и хранилищ данных, а также верификации программных систем.

Термин Big Data подпорчен современным фантастическим преувеличением новых вещей. Как ИИ поработит людей, а блокчейн построит идеальную экономику — так и большие данные позволят знать абсолютно все про всех и видеть будущее.

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

Появляются новые методы. Вместе с ними — новые профессии. Декан факультета аналитики Big Data в GeekBrains Сергей Ширкин рассказал, что это за профессии, где они нужны, чем там надо заниматься и что надо уметь. Какие используются инструменты и сколько обычно платят специалистам.

Привет, Хабр!

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

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

В этой заметке мы запилим Rust-прототип недавнего предложения от соавтора Lightning Network Paper, Thaddeus Dryja — Utreexo: a dynamic hash-based accumulator optimized for the Bitcoin UTXO set, позволяющего уменьшить требования к дисковому пространству для узлов-валидаторов.

Service Mesh — известный архитектурный паттерн для интеграции микросервисов и перехода на облачную инфраструктуру. Сегодня в облачно-контейнерном мире обойтись без него довольно сложно. На рынке уже доступны несколько open-source реализаций service mesh, но их функциональности, надежности и безопасности далеко не всегда достаточно, особенно когда речь идет о требованиях больших финансовых компаний масштаба всей страны. Поэтому мы в Сбертехе решили кастомизировать Service Mesh и хотим рассказать о том, что в Service Mesh круто, что не очень и что мы с этим собираемся сделать.

Лесли Лэмпорт — автор основополагающих работ в распределённых вычислениях, а ещё вы его можете знать по буквам La в слове LaTeX — «Lamport TeX». Это он впервые, ещё в 1979 году, ввёл понятие последовательной согласованности, а его статья «How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs» получила премию Дейкстры (точней, в 2000 году премия называлась по-старому: «PODC Influential Paper Award»). Про него есть статья в Википедии, где можно добыть ещё несколько интересных ссылок. Если вы в восторге от решения задач на happens-before или проблемы византийских генералов (BFT), то должны понимать, что за всем этим стоит Лэмпорт.

Эта хабрастатья — перевод доклада Лесли на Heidelberg Laureate Forum в 2018 году. В докладе пойдёт речь о формальных методах, применяемых в разработке сложных и критичных систем вроде космического зонда Rosetta или движков Amazon Web Services. Просмотр этого доклада является обязательным для посещения сессии вопросов и ответов, которую проведет Лесли на конференции Hydra — эта хабрастатья может сэкономить вам час времени на просмотр видео. На этом вступление закончено, мы передаём слово автору.

---

Когда-то давно Тони Хоар написал: «В каждой большой программе живет маленькая программа, которая пытается выбраться наружу». Я бы это перефразировал так: «В каждой большой программе живет алгоритм, который пытается выбраться наружу». Не знаю, правда, согласится ли с такой интерпретацией Тони.

Привет, меня зовут Василий Богонатов. Я один из тех, кто приложил руку и голову и вложил свою душу в сервис распределённых персистентных очередей сообщений Yandex Message Queue. Сервис вышел в общий доступ в конце мая, но внутри Яндекса он уже давно и активно используется в разных продуктах.

Сегодня я хочу рассказать читателям Хабра об очередях сообщений вообще и о Yandex Message Queue в частности. Сначала я хочу объяснить, что такое «распределённая персистентная очередь сообщений» и зачем она нужна. Показать её практическую ценность, механику работы с сообщениями, поговорить про API и удобство использования. Во второй половине материала мы посмотрим на техническую сторону: как в наших очередях используется Yandex Database (это надежный фундамент нашего сервиса), как выглядят наивный и улучшенный подход к построению архитектуры, какие проблемы вызывает распределённость и как их можно решить.