Monte Carlo modeling in cloud - mc-modeling-sdk

Monte Carlo modeling in
Azure cloud
Alexey Bokov / abokov @ microsoft.com / twitter: @abokov
Senior Program Manager
Technical Evangelist and Development team
Microsoft Corp

Contents
Theory part:
1. CAP theorem statement and conslusions
2. Challenges and how to apply into real world apps
3. Last change – mobile and social apps
Design part:
1. In-Memory solutions – high performance and reliability
2. Monte Carlo modeling
3. C++ framework mc-modeling-sdk – practical usage
QA and some hands-on

CAP theorem and some Eric Brewer
The CAP Theorem states that, in a distributed system (a collection of
interconnected nodes that share data.), you can only have two out of the
following three guarantees across a write/read pair: Consistency, Availability, and
Partition Tolerance - one of them must be sacrificed.
• Consistency - A read is guaranteed to return the most recent write for a given
client.
• Availability - A non-failing node will return a reasonable response within a
reasonable amount of time (no error or timeout).
• Partition Tolerance - The system will continue to function when network
partitions occur.
Published 2000, proved 2002.
@eric_brewer

But Brewer wasn’t the first
4 june 1976 Sex Pistols had shown that barely-
constrained fury was more important to their
contemporaries than art-school structuralism,
giving anyone with three chords and something to
say permission to start a band.
We know three chords but you can only
pick two

Not only Brewer 
* In verse rhythm guitar actually added 3rd chord, but
it’s not so important because bass continue to stay on
two chords riff almost
Another 2 chords songs
• 1976 – ‘Judy is a Punk’ by The Ramones (Eb5, Bb5 )
• 1980 – Atmosphere by Joy Division (A, D ) *
• 1985 – ‘Just Like Honey’ by Jesus and the Mary Chain (G#, D# )
• 1995 – Common People by Pulp (C, G) *
• 2007 – ‘505’ by Arctic Monkeys (Dm, Em)
• 2010 – ‘Bloodbuzz Ohio’ by The National (A, F#m ) *
В России это целое музыкальное направление:

IT теория vs IT реальность
• Сетевые соединения не надежны и часто падают
• Латентность всегда оказывает существенное
влияние на работу приложения
• Пропускная способность сети очень даже
конечна
• Сетевое соединение не безопасно
• Топология сети меняется очень часто, и чем
дальше узлы друг от друга, тем чаще меняется
топология
• У вашей системы множество администраторов,
которые делают одни и те же вещи по-разному
• Стоимость передачи данных бывает очень
высока
• Сеть гетерогенна – пакеты могут разделяться, их
атрибуты могут быть затерты, часть из них может
быть отфильтрована
• Сетевые соединения надежны
• Латентность связи всегда
нулевая
• Пропускная способность сети
бесконечна
• Сетевое соединение безопасно
• Топология сети не меняется
• У вашей системы всегда 1
администратор
• Стоимость передачи данных
нулевая
• Сеть гомогенна
Вернёмся обратно в IT

Вернёмся обратно в IT: важные замечания
Consistency подразумевает что при чтении мы получаем данные от _последней_ записи
Availability включает в себя понятие разумного ответа за определенное время – то есть если система не отвечает по таймауту или
выдает ответ вида “сервер занят”, или любой другой нерелевантный цели запроса ответ, то это приравнивается к неответу системы
Partition tolerance – устойчивость к разделению. Мы считаем потерянными также те сообщения, доставка которых превысила
определенный лимит времени.
• Если узел вышел из строя – это не ситуация разделения, потому что все равно есть только одна партиция ( а не 1 и N-1 как
можно полагать ).
• При выходе узла из строя система как раз может быть одновременно и согласованной и доступной, т.к. этот узел в любом
случае не обрабатывает запросы, а когда он восстановится и у нас будет 1 и N-1 это узел может быть инициализирован
актуальной репликой _всех_ данных.
Вывод: во время разделения мы выбираем либо доступность (минус
консистентность) либо конситентность ( минус доступность ).

Виды сервисов согласено CAP теореме
1) Доступность сервиса важнее всего = AP ( Availability + Partition Tolerance - best effort
availability) системы – отвечаем на запросы, однако возвращенные данные не всегда могут
быть актуальными и консистентными – например это DNS
2) Важнее всего целостность данных при разделении данных ( минус доступность ) =
CP ( Consistency + Partition tolerance ) системы – отвечают на запросы всегда с корретными
данными, но при проблемах с сетью, узлы могут не отвечать – Hbase, Google bigtable,
большинство noSQL БД
3) Важнее всего консистеность и доступность,но без возможности разделения
данных = AC ( Availability + Consistency ) – возвращают всегда корретные данные, однако не
имеют возможности разделения данных по сети при этом – примеры большинство реляционных
баз данных

На самом деле все сложнее
1) До тех пор, пока не наступила ситуация разделения система может вести себя как CA и
только в случае возникновения партиций ей нужно выбирать между согласованностью
и доступностью.
2) Свойства ( С, A, P ) на практике не являются бинарными :
1) Доступность, очевидно, может измеряться по времени прошедшем между
посылкой запроса и получением ответа.
2) Какие-то системы могут позволить себе долго отвечать на запрос, другие должны
сделать за определенный промежуток времени.
3) Свойство устойчивости к разделению напрямую зависит от того, каким образом
классифицировать сложившуюся ситуацию как разделение.
4) У консистентности данных тоже могут быть разные степени

Степени консистентности
1) Сильная/строгая согласованность (strong consistency). Операции чтения, произошешие
после выполнения операции записи, всегда возвращают результат последней
операции записи. Данный тип согласованности используется в CA системах, в частности
в классических реляционных базах данных
2) Слабая согласованность (weak consistency). При данном типе согласованности система
не гарантирует того, что операция чтения вернет результат последней операции
записи.
1) Существует ряд условий, необходимых для того, чтобы чтение вернуло самое последнее доступное
значение.
2) Период, в течении которого операция чтения возвращает устаревшие данные называется периодом
несогласованности.

Степени cлабой консистентности
Согласованность в конечном счете (eventual consistency) - если операций изменения объекта нет, то в конечном
счете операции чтения начнут давать наиболее актуальное значение. Наиболее популярной системой,
использующей согласованность в конечном счете, является DNS: изменения имени распространяются по
заданному алгоритму
Причинная согласованность: Если процесс А сообщил процессу Б, что А обновил объект, последующие запросы
на чтение к Б вернут актуальное состояние объекта.
Read-your-writes согласованность: процесс А, после того, как он обновил объект, всегда возвращает
обновленное состояние объекта.
Сессионная согласованность: процесс читает из системы хранения данных в контексте сессий. До тех пор, пока
сессия существует, система гарантирует read-your-writes согласованность.
Согласованность монотонной записи: в этом случае, система гарантирует, что запись будет произведена.
Данный тип согласованности является практически повсеместным.

Немного про разные варианты
R – колиство read узлов, W – количество write узлов, N – количество узлов которые хранят реплику данных
1) R+W>N – строгая консистенстность, всегда найдутся такие узлы системы, которые будут участвовать как в
операции записи, так и в операции чтения.
2) R = N/2, W=N/2 - когда операции записи и чтения имеют равную значимость для систем.
3) R->1, W->N - операция чтения выполняется намного чаще, чем операция записи, и перед системой не стоит
требования «запись должна осуществляться всегда». Конфигурация (R=1, W=N) обеспечивает высокую
доступность и устойчивость к разделению для операции чтения, т.к. узлу, чтобы возвратить ответ, не нужно
соединение с другими узлами.
4) R->N, W->1 - переносит нагрузку с операции записи на операцию чтения. (R=N,W=1) характеризуется высокой
доступностью и устойчивостью к разделению при операции записи, минус – отсутствие оптимистичкой
блокировки
5) R+W<=N, то есть вероятность того, что узлов, участвующих в операции чтения и в операции записи, не будет,
из чего следует, что система с такими настройками не может гарантировать сильную согласованность.

Время ответа – от CAP к PACELC
CAP теорема не учитывает время ответа узла системы на запрос в качестве свойства,
задержка и ситуация разделения тесно связаны друг с другом
Эту момент учитывает PACELC (in case of Partition, choose between Availability and
Consistency, else – between Latency and Consistency ) – в случае разделения данных
выбираем между CA ( доступностью и консистентностью ) и LC (задержкой и
консистентностью) (Абади):
1. Разделение между доступностью и устойчивостью к разделению нечеткое.
2. Исходя из наблюдений Абади, те базы данных, которые предпочитают
жертвовать консистетностью данных, имеют тенденцию жертвовать ей не только во время
разделения, но также и при обычном функционировании.
Вывод: в случае нормального функционирования системы, следует
выбирать между уменьшением времени ответа и согласованностью.

Минимизация эффектов
1) обработка ситуаций разделения как в вопросе обнаружения разделения
2) Процесс восстановления после разделения и поддержанию вариантов системы, которые могли
быть нарушены
• Для выполненных операций храним версионные векторы, представляющие собой пары узлов, на
которых они выполнялись, и времени, когда они выполнялись. если в системе будет две версии
объекта, система сможет узнать, какая из них актуальней. Иногда возможна ситуация, когда
актуальность определить нельзя – в таком случае считается, что некоторые изменения объекта
выполнялись параллельно (Amazon Dynamo, Voldemort, Apache Cassandra, Riak, MongoDB )
• Сегментирование архитектуры:
• По данным
• По операциям
• По требованиям к функционалу
• По пользователям
• По иерархии

Восстановление после разделения
Задачи:
1. Состояние объектов на всех узлах должно стать полностью консистентным
2. Компенсация ошибок, допущенных в результате разделения
Основным подходом к определению текущего состояния объекта является
пошаговое исследование операций, происходившими с данными с
момента начала разделения, и произведение корректирующих действий
на каждом шаге.

Компенсация ошибок
1) "последняя запись - финальная запись”
2) Перекладываем задачу на пользователя
Пример из реальной жизни - Примером процесса компенсации ошибок после разделения
является ситуация, когда на самолет было продано больше билетов, чем есть в наличии.
Процедура посадки может рассматриваться в данном случае как своего рода компенсация
ошибки - в самолет пройдет не больше, чем есть сидений
Архитектурное решение - выполнение рискованных операций в ситуации разделения
следует откладывать настолько, насколько это возможно

Выводы
Нет 100% работающего универсального решения, каким путем решать задачу обработки
запросов при возникновении расщепления распределенной системы – выбирать
доступность или же выбирать
Этот выбор может быть сделан только разработчиком, на основе анализа бизнес-модели
приложения.
Более того, этот выбор может быть сделан не для всего приложения в целом, а отдельно
для каждой его части:
• Согласованность для процедуры покупки и оплаты в интернетмагазине;
• Доступность для процедуры просмотра каталога товаров, чтения отзывов и т.п.
Можем смириться с несогласованностью, в случае коротких периодов (1-2 минуты)
разделения системы

Есть исключения из теоремы

Что дальше
Масштабируемость – опять же возвращаемся к выборы между масштабируемостью и консистентностью
Устойчивость к атакам - например DDoS не укладывется в модель разделения данных. DDoS атаки и прерывание
работы веб сервисов требуют другого понимания выбора между консистентностью и доступностью.
Мобильные сети – параметры мобильных сетей (огромная вариативность всех параметров сети – скорость,
доступность, задережки ) не укладываются в модель сетевого взаимодействия CAP теоремы:
Модель CAP теоремы предполагает что у нас есть относительно стабильные партиции которые
изменяется раз в несколько минут. Для беспроводных сетей изменения гораздо более сильные, потери пакетов и
изменение задержек.
Приложения в мобильных сетях больше ориентированы на геотаргетинг и социальное
взаимодействие, в то время как CAP теорема больше ориентирована на веб 2000-х – большие веб порталы и e-
commerce.

In Memory solutions – performance and reliability
The data model is distributed across many servers in a single location or across multiple locations. This distribution is
known as a data fabric. This distributed model is known as a ‘shared nothing’ architecture.
• All servers can be active in each site.
• All data is stored in the RAM of the servers.
• Servers can be added or removed non-disruptively, to increase the amount of
RAM available.
• The data model is non-relational and is object-based.
• Distributed applications written on the .NET and Java application platforms
are supported.
• The data fabric is resilient, allowing non-disruptive automated detection and
recovery of a single server or multiple servers.

In-Memory-Data-Grid solutions
The features of IMDG can be summarized as follows:
• Data is distributed and stored in multiple servers.
• Each server operates in the active mode.
• A data model is usually object-oriented (serialized) and non-relational.
• According to the necessity, you often need to add or reduce servers.

IMDG features
• DistributedMap & DistributedMultiMap
• Distributed Collections
• DistributedTopic & DistributedEvent
• DistributedLock
• Transactions
• Using Large Capacity Memory and Garbage Collector

Monte Carlo modeling
Monte Carlo simulation, or probability simulation, is a technique used to understand the impact of
risk and uncertainty in financial, project management, cost, and other forecasting mode
Patterns:
• Define a domain of possible inputs.
• Generate inputs randomly from a probability distribution over the domain.
• Perform a deterministic computation on the inputs.
• Aggregate the results.

MC-Modeling-SDK
C++ open sourced framework implements different models of Monte-Carlo simulation
: github.com/abokov/mc-modeling-sdk
• Multi-thread safe ( I mean single thread itself, easily can be multitasked ))
• Linux now, win32 ( soon )
• Azure adopted (via Azure Storage C++ SDK )
• Input data – csv, xml
• JNI externals for connection to java code ( GridGain, Hadoop, … )
• Pre-sets of stocks data
Options to run:
• framework ( added to your C++ code )
• standalone binary
• Static lib called from java code

JNI integration
How to call :
run
JNIEXPORT void JNICALL Java_com_gridgainec2_DemoManagerJni_runMonteCarlo
which will go for
void runMonteCarlo(JNIEnv *jni_env, jobject java_this, jobjectArray position_array,
jint horizon, jint iters);
{
…
…
…
}

Models
1) BrownMotion
2) BaseExponent
3) BaseExponent (with historical data)
4) Simple Random generation
Main goal of models is demonstrate how to customize algorithm and use different
approximations.
To add your model please use ModelCommonTemplate from models/modelCommon.h

Monte Carlo modeling in cloud - mc-modeling-sdk

Recommended

More Related Content

Similar to Monte Carlo modeling in cloud - mc-modeling-sdk (20)

More from Alexey Bokov (20)

Monte Carlo modeling in cloud - mc-modeling-sdk

Editor's Notes