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

伝えたいこと
2

全ては
Reactive System
のために
3

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
4

what is `Reactive System`
5

http://www.reactivemanifesto.org/ja
6

http://www.reactivemanifesto.org/ja
7

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

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

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

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

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

メッセージ駆動？
13

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

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

http://www.reactivemanifesto.org/ja
16

why `Reactive System`
17

http://www.reactivemanifesto.org/ja
18

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

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

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

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

23

それだけ
24

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

Immutable Infrastracture
26

Microservices
27

Serverless
28

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

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

`Reactive System`
for
application engineer
31

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

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

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

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

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

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

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

Summary
39

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

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

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

参考
• 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
43

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