what is ReactiveSystem - Speaker Deck

Slide 1

Slide 1 text

次世代のシステムがあるべき姿 2016/12/22 @petitviolet

Slide 2

Slide 2 text

伝えたいこと

Slide 3

Slide 3 text

全ては Reactive System のために

Slide 4

Slide 4 text

Agenda • what is `Reactive System` • Reactive Manifesto • responsibility/resilient/elastic/message driven • why `Reactive System` • `Reactive System` for application engineer • Akka-Actor • OOP/FP • Summary

Slide 5

Slide 5 text

what is `Reactive System`

Slide 6

Slide 6 text

http://www.reactivemanifesto.org/ja

Slide 7

Slide 7 text

http://www.reactivemanifesto.org/ja

Slide 8

Slide 8 text

Reactive Systemとは • 以下の4つを満たすシステム • 即応性(responsibility) • レジリエンス(resilient) • 弾力性(elastic) • メッセージ駆動(message driven)

Slide 9

Slide 9 text

即応性(responsibility) • 迅速な応答時間、つまり高パフォーマンスなシステムであること • 即応性はあらゆるシステムにおいて要求されるものであり、何かしら障害が起きたり高負荷になったとしても、要求される水準のパフォーマンスを保ち続けること

Slide 10

Slide 10 text

レジリエンス(resilient) • システムのどこかに障害が発生しても、レプリケーション・封じ込め・隔離・委譲のいずれかの方法によって即応性を保つ • 単なるレジリエンスではなく、復旧・回復が入る概念 • 何かしら予期しない障害が発生したとしても、自律的に回復すること

Slide 11

Slide 11 text

弾力性(elastic) • リソースを増減させて要求される即応性・スループットを保ち続ける • スケーラビリティとの違いは、自動で伸縮するかどうか • 弾力性のあるシステムは負荷に応じて自動で伸縮する

Slide 12

Slide 12 text

メッセージ駆動(message driven) • 前述の即応性、レジリエンス、弾力性を実現するための手段 • 非同期なメッセージパッシングによってシステムを構築する • メッセージは、状態の変化などのイベントが発生したコンポーネントから発信されるデータ • メッセージの受信者は、普段は休止しているがメッセージを受け取ったらそれに反応する • メッセージの送信者と受信者にコンポーネントを時間的・空間的に分割することによってシステムが疎結合になる • 疎結合が、resilientとelasticのベースになる

Slide 13

Slide 13 text

メッセージ駆動？

Slide 14

Slide 14 text

https://speakerdeck.com/naoya/serverless-architecture

Slide 15

Slide 15 text

ちょっと違う • イベント駆動と似てやや非なるもので、メッセージが中心にあるかどうか、が大きな違い • イベントは単なる観測可能なもの(`Observable`)でしかないが、メッセージには明確な目的がある • イベント駆動 • 通知のリスナーはイベントの発生源にあり、アドレス可能なイベントソースが中心 • メッセージ駆動 • アドレス可能なメッセージ受信者が中心

Slide 16

Slide 16 text

http://www.reactivemanifesto.org/ja

Slide 17

Slide 17 text

why `Reactive System`

Slide 18

Slide 18 text

http://www.reactivemanifesto.org/ja

Slide 19

Slide 19 text

なぜリアクティブシステムなのか • 大規模化・複雑化・分散するシステム • 要求される水準がどんどん高くなってきている

Slide 20

Slide 20 text

なぜリアクティブシステムなのか • 大規模化・複雑化・分散するシステム • 要求される水準がどんどん高くなってきている • どうやって”いい感じに”まとめあげるか

Slide 21

Slide 21 text

なぜリアクティブシステムなのかシステム全体の指針となるアーキテクチャが必要 • 大規模化・複雑化・分散するシステム • 要求される水準がどんどん高くなってきている • どうやって”いい感じに”まとめあげるか

Slide 22

Slide 22 text

システム全体の指針となるアーキテクチャが Reactive System

Slide 23

Slide 23 text

Slide 24

Slide 24 text

それだけ

Slide 25

Slide 25 text

Reactive Systemとして具体的な設計や実装は提示されていない

Slide 26

Slide 26 text

Immutable Infrastracture

Slide 27

Slide 27 text

Microservices

Slide 28

Slide 28 text

Serverless

Slide 29

Slide 29 text

昨今のバズワード(だった)ものたち • Immutable infrastracture • Microservices • Serverless

Slide 30

Slide 30 text

• Immutable infrastracture ⇒ 弾力性、レジリエンス • 負荷に応じてシステムを伸縮させるには不変なインフラがあって低コストで起動/停止が可能でなければならない • 同じシステムを別のリソースで動かすこと(AZわけるみたいなレプリケーション)が容易 • Microservices ⇒ レジリエンス、メッセージ駆動 • モノリシックだとサービス全体がダウンする可能性がある • マイクロサービスに切り分けていると、全体がダウンすることはなく、一部のサービスが提供できない程度に被害を抑えられる • 全体としてのユーザー体験をなるべく損なわない • 明確なモジュール境界を設定することとなり、モジュール間のやり取りは非同期なメッセージパッシングとなる • Serverless ⇒ 弾力性, メッセージ駆動 • shared nothingな"関数"だからこそスケールが容易 • 厳密にはイベント駆動だが、別のイベントをkickすることも可能でメッセージ駆動ともいえる

Slide 31

Slide 31 text

`Reactive System` for application engineer

Slide 32

Slide 32 text

何が出来る？ • 前述のバズワードたちはインフラ寄り • 各コンポーネント自体やそれを繋げるのはアプリケーションエンジニア • そこでリアクティブシステムを意識していないと台無し

Slide 33

Slide 33 text

何が出来る？ • リアクティブシステムの基盤となる「メッセージ駆動」という観点からプログラムを考える Scalaエンジニアならでしょ

Slide 34

Slide 34 text

Akka(actor)がもたらすもの • メッセージパッシング(ﬁre and forget) • ActorRefへのメッセージ送信がベース • 位置透過性(akka-remote/cluster) • Let it crash • 障害からの回復(supervisor strategy) • バックプレッシャー(Reactive Stream) • コンポーネント間のメッセージ流量を制御

Slide 35

Slide 35 text

アクターモデル以外の OOP/FPの出番はない？

Slide 36

Slide 36 text

OOP/FPの出番はない？ • アクターモデルというよりAkkaがリアクティブをサポートしているからやりやすいというだけ • 例えば以下のような考え方はアクターに限定されない • 外部サービスの呼び出し等はCircuitBreakerを使う • コンポーネント間で処理能力に差がある場合はスロットリングする • スケールアウトしやすいように切り分ける

Slide 37

Slide 37 text

Reactive Systemを意識してプログラムを書くのが大事

Slide 38

Slide 38 text

ちなみに、 Reactive Programmingと Reactive Systemは別物です https://www.oreilly.com/ideas/reactive-programming-vs-reactive-systems

Slide 39

Slide 39 text

Summary

Slide 40

Slide 40 text

• 目指すべきはReactive System • 特に、即応性、弾力性、レジリエンスは全てに共通 • 指針となるシステム全体のアーキテクチャ

Slide 41

Slide 41 text

• 目指すべきはReactive System • 特に、即応性、弾力性、レジリエンスは全てに共通 • 指針となるシステム全体のアーキテクチャ • Actorつかわなきゃ！とか一切ない • プログラミングモデルに左右されない • ScalaでもGolangでもPHPでも

Slide 42

Slide 42 text

• 目指すべきはReactive System • 特に、即応性、弾力性、レジリエンスは全てに共通 • 指針となるシステム全体のアーキテクチャ • Actorつかわなきゃ！とか一切ない • プログラミングモデルに左右されない • ScalaでもGolangでもPHPでも • 即応性を満たすフルマネージドサービス最強 • AWS-xxx, GAE, etc.

Slide 43

Slide 43 text

参考 • Reactive programming vs. Reactive systems • https://www.oreilly.com/ideas/reactive-programming-vs- reactive-systems • Why Reactive? • https://www.oreilly.com/learning/why-reactive • Reactive Manifesto • http://www.reactivemanifesto.org/ja • Why Reactive Matters • http://www.slideshare.net/okapies/why-reactive-matters

Slide 44

Slide 44 text

次世代のシステムがあるべき姿 2016/12/22 @petitviolet