Distributed Erlang

Лесли Лэмпорт (ученый, исследователь теории распределенных систем):

A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable.

Ну это, конечно, шутка. А если серьезно, то распределенную систему можно определить так: система, состоящая из 2-х и более компьютеров, взаимодействующих между собой.

Систем таких много, самых разных. И примеры долго искать не нужно:

Хранилища данных: Google BigTable, Amazon SimpleDB, Hadoop, Cassandra, множество их, в т.ч. и написаные на Erlang: Riak, CouchDB.

Сервисы: Google Search, поиск Яндекса, WhatsApp, множество их, в т.ч. и написаные частично на Erlang: Heroku, Github.

Социальные сети: Facebook, Twitter, Вконтакте и др.

Многопользовательские игры: Word of Warcraft, Call of Duty Black Ops и др.

Не то, чтобы все прям горели желанием, но приходится это делать тогда, когда задача не решается на одной машине:

• Хранить данных больше, чем может поместиться на одной машине;
• Обрабатывать данных больше, чем можно обработать на одной машине;
• Повысить надежность системы;
• Построить масштабируемую систему, способную адаптироваться к росту нагрузки;
• Сервисы, распределенные по своей сути (например, CDN – content delivery network);

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

Отказоустойчивость систем принято оценивать, как соотношение времени, когда система была доступна пользователям, ко времени, когда была недоступна. Промежуток времени берется – год, а соотношение оценивают в %.

С помощью Erlang была построена система с надежностью Nine Nines (девять девяток)

Вот тут один из создателей языка Джо Армстронг хвастается:

The AXD301 has achieved a NINE nines reliability (yes, you read that right, 99.9999999%). Let’s put this in context: 5 nines is reckoned to be good (5.2 minutes of downtime/year). 7 nines almost unachievable … but we did 9.

А компания 99s, давшая нам такие прекрасные тулы, как Cowboy, Ranch и Bullet, названа именно в честь такой отказоустойчивости Erlang.

Введем немного терминологии.

Эрланг приложение (Application) – система, сервис или библиотека с определенной функцией. Например: веб-сервер Cowboy, сервис логирования Lager, драйвер к базе данных и т.д.

Узел (Node) – экземпляр виртуальной машины Erlang. Обычно выполняет несколько Эрланг приложений. На одной машине может быть запущено несколько узлов.

Кластер – несколько узлов, взаимодействующих между собой. Узлов в кластере может быть от 2х до сотен и тысяч :)

Эффективную распределенную систему можно построить на самых разных технологиях и ЯП. А в чем особенность именно Erlang? Он предлагает единый подход и к локальному и к распределенному программированию.

Архитектура Erlang-приложения строится из независимых процессов, общающихся между собой отправкой сообщений.

Как элемент архитектуры, процесс:

• имеет публичный АПИ (реагирует на определенные сообщения);
• хранит внутри себя состояние (некие данные);
• общается с другими процессами, пользуясь их публичным АПИ;
• имеет закрытую бизнес-логику;

На что это похоже? На объект в ООП.

Идем уровнем выше. Из процессов строятся приложения.

Приложение:

• имеет публичный АПИ;
• хранит внутри себя данные;
• общается с другими приложениями, пользуясь их публичным АПИ;
• имеет закрытую бизнес-логику;

Идем уровнем выше. Для выполнения приложений запускается узел.

Узел:

• имеет публичный АПИ;
• хранит внутри себя данные;
• общается с клиентами и другими узлами;
• имеет закрытую бизнес-логику;

Идем уровне выше. Из узлов строится кластер.

Кластер:

• имеет публичный АПИ;
• хранит внутри себя данные;
• общается с клиентами;
• имеет закрытую бизнес-логику;

На всех уровнях у нас один и тот же архитектурный паттерн. Но это еще не особенность Erlang, так можно строить систему и на других языках.

Вся фишка Erlang в сетевой прозрачности. Процессы общаются отправкой сообщений друг другу, при этом не важно, находятся ли они на одном узле, или на разных. За реализацию отвечает виртуальная машина. Она сама открывает сокеты, устанавливает нужные TCP соединения между узлами, мониторит их состояние – программисту об этих низкоуровневых вещах думать не нужно.

Пробуем:

erl -name node1@127.0.0.1

erl -name node2@127.0.0.1

(node1@127.0.0.1)1> net_adm:ping('node2@127.0.0.1').
pong
(node1@127.0.0.1)2> register(my_shell, self()).
true

(node2@127.0.0.1)1> {my_shell, 'node1@127.0.0.1'} ! "hello there".
"hello there"

(node1@127.0.0.1)3> flush().
Shell got "hello there"
ok
(node1@127.0.0.1)4> node().
'node1@127.0.0.1'
(node1@127.0.0.1)5> nodes().
['node2@127.0.0.1']

Это база всех взаимодействий. Если я знаю Pid процесса, или знаю, под каким именем он зарегистрирован, то я могу с ним общаться. Pid уникален в пределах кластера. Имя уникально в пределах узла.

На самом деле вот такой код, с отправкой сообщений, пишут редко. На базе сообщений построены более высокие и удобные уровни: gen_server, rpc:call, распределенное OTP приложение и т.д. И разработчики обычно пользуются ими.

Но сетевая прозрачность касается не только отправки сообщений, но и мониторинга процессов. Мониторинг, это когда один процесс (supervisor) наблюдает за состоянием другого процесса (worker), и получает сообщение если с worker случается какая-то проблема. Supervisor может предпринять в этом случае какие-то действия. Например, перезапустить worker.

Эти механизмы тоже действуют в условиях сетевой прозрачности. Мониторить можно не только процессы в своем узле, но и процессы в другом узле. И можно мониторить доступность другого узла, и предпринять какие-то действия, если связь с другим узлом потеряна. Например, запустить резервную систему.

Весьма рекомендую книгу Фреда Хеберта Learn you some Erlang for greate good!

Она изначально была опубликована на сайте недавно вышла и в бумажном виде, и в электронном

2 главы там посвящены распределенным приложениям: Distribunomicon Distributed OTP Applications

Соответствующие главы по теме есть и в классических книгах: Programming Erlang: Software for a Concurrent World. Joe Armstrong Erlang Programming. Francesco Cesarini, Simon Thompson

И в менее известной, но тоже очень хорошей Erlang and OTP in Action. Martin Logan, Eric Merritt