Антифрод. Архитектура сервиса (часть 3)

[kypexin]

Дмитрий, получившееся решение тестировалось под нагрузкой? Какие в итоге получились показатели производительности в продакшене? Очень интересует среднее время ответа антифрод-системы, запас по объёму транзакций (сколько транзакций в секунду/минуту могут быть обработаны без ухудшения общей производительности). Какие показатели при этом устанавливаются как целевые?

[codezombie]

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

[kypexin]

Ещё есть вопрос по таблице TransactionsStatistics: как и кем определяется, какие именно данные туда записываются? Понятно, что разных статистических данных и параметров транзакций можно записывать десятки, если не сотни, так вот интересует минимально необходимый набор, который сохраняется, и как он формируется. Спасибо.

[codezombie]

(Если упрощенно) Показатели, влияющие на точность работы алгоритма предсказания (предикторы), определяют эксперты в предметной области. Data scientist'ы статистическими методами проверяют верна ли гипотеза экспертов. Если да, то разработчик интегрирует новый показатель в систему и запускается переобучение модели.

[lair]

На самом деле, то, что вы нарисовали — это нормальный такой CQRS, где моделью на чтение выступает ML, а моделью на запись — лог транзакций. Осталось довести это до логического завершения, вставить ивенты максимально часто (включая прохождение внутри ML), после чего вы получите, с одной стороны, большую выборку данных для последующего анализа и построения статистики, а с другой — audit trail для ответов на вопросы «а почемуууу».

Мне вот другое интересно. Вы пишете, что Azure дает SLA .95. Ну допууууустим. Это гарантия SLA отдельного компонента?

[codezombie]

Разделение потоков на чтение и на запись — это довольно частый паттерн для высоконагруженных систем (но это только одна единственная концепция, и это точно ни CQRS, ни с Event Sourcing, ни CQRS + Event Sourcing.

Про SLA отдельных компонентов я не очень понял: что Вы подразумеваете под термином 'отдельных компонент'?

[lair]

Разделение потоков на чтение и на запись — это довольно частый паттерн для высоконагруженных систем (но это только одна единственная концепция, и это точно ни CQRS,

Я запутался в вашем предложении. Разделение потоков на чтение и запись — это CQRS (по собственному утверждению Янга).

что Вы подразумеваете под термином 'отдельных компонент'?

Я имею в виду: в вашем договоре с Azure SLA зафиксирован для всей системы целиком или для отдельного компонента — например, Azure Queue?

[codezombie]

Определение Янга не читал, но за концепцией разделения потоков еще стоит и реализация. В .NET CQRS принято реализовывать с использованием паттернов Repository/Command/введением DDD/Event Sourcing/etс. (тема долгая) В описываемой системе все обстоит немного (сильно) по-другому.

Внешним клиентам (когда они будут), конечно, открывается только SLA антифрод-сервиса (клиенты могут и не догадываться, что система работает в Azure).

[lair]

Определение Янга не читал, но за концепцией разделения потоков еще стоит и реализация. В .NET CQRS принято реализовывать с использованием паттернов Repository/Command/введением DDD/Event Sourcing/etс.

Тем не менее, по определению основателя для CQRS достаточно разделения потоков. И нет, я не думаю, что он согласится с вашим «принято» (если что, он сам из .net-мира).

Внешним клиентам (когда они будут), конечно, открывается только SLA антифрод-сервиса (клиенты могут и не догадываться, что система работает в Azure).

Я сейчас не про внешних клиентов, а про ваш договор с Azure, на основании которого вы делаете заявление: «Используемые антифрод-системой сервисы Azure [...] дают следующие преимущества из коробки: [...] SLA не ниже 99,95%;»

[codezombie]

Значит у меня полноценный CQRS .)

[lair]

Так что же, все-таки, с SLA?

[Don_Eric]

A 99.95% Window Azure Service Level Agreement is only achievable with two nodes for each install

www.erpsoftwareblog.com/2014/04/windows-azure-service-level-agreement-sla-what-microsoft-users-need-to-know/

[lair]

Это для компонента или для системы?

[Don_Eric]

у каждой компоненты SLA 99.95%, при условии что у нее есть узел-«двойник».

То есть если мы хотим, чтоб у самой системы был SLA 99.95%, и система состоит из нескольких компонент, то надо составить уравнение чтоб подсчитать сколько узлов надо для каждой компоненты, так чтоб произведение вероятности ошибок было меньше чем 0.05%
ru.wikipedia.org/wiki/Надёжность

[lair]

Да я как бы понимаю, как считается — в первом приближении — надежность системы, мне просто было интересно, дает Azure гарантию на компоненты или на системы целиком. Мне казалось, что первое — и вы это подтвердили. Следовательно, с общей надежностью системы все не так прозрачно.

[grossws]

А кто будет делать иначе (давать гарантию на чужую систему на основе сервисов azure/aws/whatever)? Доступность для клиента будет определяться надежностью балансировщика + веб-приложения + ML-сервиса (т. к. это критичный путь), в базовом варианте.

[lair]

(еще забыли геосервис и лог транзакций)

Мне вот тоже казалось, что иначе делать не будут. А это означает, что фраза «Azure дает SLA 99.95», хоть и интересна сама по себе, но практически ничего не говорит о SLA результирующего сервиса.

[PavelMSTU]

Есть ли проблемы юридического характера?
И если есть, как вы их решаете?

(Благодарю за пост!)

[codezombie]

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

[PavelMSTU]

И второй вопрос:
в чем питоновский scikit-learn хуже, а в чем лучше предлагаемого вами решения?

[codezombie]

Вопрос провокационнный.) Напишите статью — узнаем.