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

В предыдущем посте мы рассматривали принципиальные подходы к оценке ёмкости кластера и совсем немного поговорили про оптимизацию. Для любителей заглянуть «под капот» Алексей Гончарук 29 мая проведет вебинар с живыми примерами:

• Откуда берется overhead при записи данных;
• Приемы оптимизации;
• Как планировать ёмкость кластера Apache Ignite;
• Улучшения, которые ждут вас в ближайших релизах.

Вебинар будет интересен тем, кто планирует использовать Apache Ignite в реальном проекте и хочет оценить аппаратную конфигурацию или объём памяти для хранения в Ignite заданного объёма исходных данных.

Ждем вас онлайн 29 мая в 19:00 (время московское).
Регистрация обязательна.

Публикуем расшифровку видеозаписи выступления Алексея Гончарука (Apache Ignite PMC Member и Главный архитектор GridGain) на митапе Apache Ignite сообщества в Петербурге 29 марта. Загрузить слайды можно по ссылке.



Участников сообщества Apache Ignite часто спрашивают: «Сколько нужно узлов и памяти для того, чтобы загрузить такой-то объем данных?» Об этом и я хочу сегодня поговорить. Забегая вперёд: такое прогнозирование пока что является достаточно сложной, нетривиальной задачей. Для этого нужно немного разбираться в устройстве Apache Ignite. Также я расскажу, как упросить себе задачу прогнозирования, и какие можно применять оптимизации.

Предисловие

Недавно прочитал очередную статью из серии: "мы лучше двухфазного коммита". Здесь я не буду анализировать содержания этой статьи (хотя, подумываю о том, чтобы дать развернутый анализ). Задача моего опуса — предложить самый эффективный вариант распределенного коммита с точки зрения временных задержек. Конечно, такой коммит дается высокой ценой. Однако цель — дать оценку и показать, что двухфазный коммит не является тормозным, как многие считают.

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

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

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

В этой статье я расскажу, как и почему мы в 2ГИС выбрали второй вариант для построения новой системы, как решали возникающие задачи и какие выгоды от этого получили. Под катом — про Amazon S3, Apache Kafka, Reactive Extensions (Rx), eventual consistency и GitHub, сжатые сроки и невозможность собрать команду необходимого размера из инженеров, использующих один стек технологий.

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

В скором времени у нас выходит изысканная новинка для разработчиков высшего класса — "Реактивные шаблоны проектирования".

Автор книги Роланд Кун — звезда первой величины в области распределенных систем, один из разработчиков Akka. Под катом предлагаем перевод его программной статьи о распределенных системах и акторной модели, размещенной на сайте GitHub

Описаны предпосылки создания proxy-cache на уровне ESB, а также и причины перехода с одной его версии на другую. После внедрения решения в одном из крупных банков, оно было оставлено, и в данный момент его судьба до конца не известна. Статья имеет целью поделиться образом мыслей и возможностями, которые предоставляет предложенное решение.

По роду своей деятельности мне достаточно часто приходится участвовать в проектах, в которых создаются высокодоступные, высокопроизводительные системы для различных рынков — реклама, финтех, сервисы классов SaaS, PaaS. В таких системах применяется вполне устоявшийся набор архитектур и компонентов, которые позволяют эффективно обеспечить соответствие продукта требованиям, например, lambda-архитектура для поточной обработки данных, масштабируемый микросервисный дизайн программного обеспечения, ориентированный на горизонтальное масштабирование, noSQL СУБД (Redis, Aerospike, Cassandra, MongoDB), брокеры сообщений (Kafka, RabbitMQ), распределенные серверы координации и обнаружения (Apache Zookeeper, Consul). Такие базовые инфраструктурные блоки чаще всего позволяют успешно решить большую часть задач и команда разработки не сталкивается с задачами разработки компонентов среднего уровня (middleware), которые, в свою очередь, будут использованы бизнес-ориентированной частью разрабатываемой системы.

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

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



«Каких ещё островах?», — спросите вы?

Уже в этот вторник, 23 мая, после долгого перерыва, в офисе DINO Systems состоится встреча CodeFreeze с Андреем Ершовым, специалистом по распределенным системам. Тема встречи — CRDT. Бесконфликтная синхронизация данных.

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

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

Немного вводной. Чтобы Bucardo заработал, мы должы:

1) Сказать ему какие базы-участники на каких серверах вообще существуют.

2) Сказать ему какие таблицы участвуют в репликации.

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

3) Сказать ему какие группы таблиц существуют и какие таблицы попадают в какие группы. Группы нужны на тот случай, если между разными серверами надо реплицировать разные таблицы. Удобнее работать с группой, чем каждую отдельно указывать (очень похоже на группы в Nagios).

4) Сказать ему какие группы баз данных существуют. Цель — та же, что и для таблиц.

Краткое содержание

1. Фатальная ошибка Мартина Клеппмана.
   
2. Физико-химическая кинетика уделывает математику.
   
3. Период полураспада кластера.
   
4. Решаем нелинейные дифференциальные уравнения, не решая их.
   
5. Ноды как катализатор.
   
6. Предсказательная сила графиков.
   
7. 100 миллионов лет.
   
8. Синергия.
   

В предыдущей заметке мы подробно разбирали статью Брюера и его одноименную теорему. На этот раз займемся препарированием поста Мартина Клеппмана «The probability of data loss in large clusters».

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

Ответ приведен на этой картинке:

Роман Гребенников объясняет сложность построения распределённых систем. Это — доклад Highload++ 2016.

Всем привет, меня зовут Гребенников Роман. Я работаю в компании Findify. Мы делаем поиск для онлайн-магазинов. Но разговор не об этом. В компании Findify я занимаюсь распределенными системами.

Что же такое распределённые системы?

Введение

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

Событие, когда какая-то статья вызывает бурю эмоций, — крайне редкое. Первый раз такое возникло, когда я прочитал про chained replication. Меня пытались убедить, что это мощный подход и что это лучшее, что могло произойти с консистентной репликацией. Я сейчас не буду приводить доводы, почему это плохо работает, а просто приведу говорящую цитату из статьи Chain Replication metadata management:

Split brain management is a thorny problem. The method presented here is one based on pragmatics. If it doesn’t work, there isn’t a serious worry, because Machi’s first serious use case all require only AP Mode. If we end up falling back to “use Riak Ensemble” or “use ZooKeeper”, then perhaps that’s fine enough.

В моем вольном пересказе это означает примерно следующее: "У нас тут есть некий алгоритм. Мы не знаем, будет ли он работать правильно или нет. Да нам это и не важно". Хотя бы честно, сэкономило кучу времени, спасибо авторам.

И тут, значит, попадается на глаза статья: Spanner, TrueTime & The CAP Theorem. Её мы разберем по полочкам ближе к концу, вооружившись понятиями и знаниями. А перед этим разберем самые распространенные мифы, связанные с CAP теоремой.

Тестирование распределенных систем существенно отличается от тестирования централизованных. Немногие тестировщики могут похвастаться серьезными знаниями и опытом в этой области.

Я пообщался со спикером конференции Heisenbug 2016 Moscow Андреем Сатариным (twitter.com/asatarin). Андрей участвовал в проектах по тестированию в Mail.ru, в Лаборатории Касперского, в Deutsche Bank, а сейчас тестирует распределенные системы в Яндексе. Статья будет полезна не только людям, которые занимаются тестированием, но и разработчикам. Если вы ни разу не касались вопроса тестирования распределенных систем, добро пожаловать под капот.

Андрей Сатарин:

… они убивают ноды прямо в рабочее время и разработчики наблюдают за...

Олег Царёв ( zabivator )

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

Иногда бывает необходимо, чтобы приложение могло получать все обновления из базы и желательно в режиме реального времени. Этим занимается оpen source библиотека, которая называется libslave.

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



Но обработка данных — это не проблема. Проблема в том, как и в каком виде сохранять результаты обработки, чтобы с ними можно было удобно работать. В процессе разработки нам приходилось несколько раз полностью менять подход к организации хранения данных. Мы начинали с таблиц MyISAM, использовали LSM-деревья и в конце концов пришли к column-oriented базе данных. В этой статье я хочу рассказать, что нас вынуждало это делать.

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

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

Но вернёмся в Россию 2015 года. Ниже я покажу, как «из подручных средств» (x86 машин и любых «хранилок») сэкономить денег, повысить надёжность и решить ещё ряд типовых для сисадминов среднего и крупного бизнеса задач.


На этой схеме видны обе архитектуры, о которых пойдет речь. SDS — два красных контроллера в центре с любым бекэндом, от внутренних дисков до FC полок и облаков. И виртуальный SAN, на схеме Hyper-converged storage.

Самое главное:

• Вам плевать, что за железо стоит: диски, SSD, зоопарк производителей, старые и новые модели… — всё это отдаётся оркестирующему софту, и он приводит это к той виртуальной архитектуре, которая вам нужна в итоге. Грубо говоря, объединяет в один том или позволяет нарезать как вам удобно.
• Вам плевать, какие интерфейсы у этих систем. SDS построится сверху.
• Вам плевать, какие функции ваши хранилки могли, а какие не могли (опять же, теперь они могут то, что надо: решает софт сверху).

Заодно рассмотрим пару типовых задач с конкретным железом и ценами.

В статье в ознакомительных целях рассматривается процесс создания простого хранилища простых текстовых документов на базе Riak версии 2.1.1 и организация поиска по ним с помощью Riak Search (Yokozuna). В качестве клиентской библиотеки используется официальный клиент для Erlang.

Для начала представим, что у нас есть огромное количество таких документов:

• title — заголовок;
• body — содержимое;
• tags — тэги;
• created_at — время создания;
• smiles — количество смайликов (плюсиков, лайков, как хотите)

и огромное количество пользователей, желающих их изменять. Кому интересно, начнём.

Здравствуйте все!

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

Мы предположили, что и в сфере изучения алгоритмов для распределенных систем краткость — сестра таланта, поэтому проработка книги Уона Фоккинка «Распределенные алгоритмы. Понятный подход» является перспективным и благодарным делом, пусть даже объем книги — всего 248 страниц.



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