Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up
for free
what is ReactiveSystem
petitviolet
December 22, 2016
Technology
0
110
what is ReactiveSystem
2016/12/22の社内勉強会資料
petitviolet
December 22, 2016
Tweet
Share
More Decks by petitviolet
See All by petitviolet
petitviolet
14
7.1k
petitviolet
0
990
petitviolet
1
740
petitviolet
8
2k
petitviolet
1
400
petitviolet
3
1.8k
petitviolet
0
1.3k
petitviolet
17
4.2k
petitviolet
1
54
Other Decks in Technology
See All in Technology
kawaguti
0
110
clustervr
0
190
natsusan
0
130
iqbocchi
0
530
satoryu
0
2.1k
hecateball
1
12k
viva_tweet_x
5
2.6k
hamadakoji
0
1.1k
pinboro
1
1.5k
greymd
0
610
oracle4engineer
1
210
vkbaba
0
120
Featured
See All Featured
philhawksworth
192
8.8k
afnizarnur
176
14k
jrom
114
7.1k
stephaniewalter
260
11k
skipperchong
7
670
keavy
106
14k
3n
163
22k
erikaheidi
13
4.2k
holman
448
130k
geeforr
332
29k
danielanewman
200
19k
jonyablonski
14
1.1k
Transcript
次世代のシステムが あるべき姿 2016/12/22 @petitviolet
伝えたいこと
全ては Reactive System のために
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
what is `Reactive System`
http://www.reactivemanifesto.org/ja
http://www.reactivemanifesto.org/ja
Reactive Systemとは • 以下の4つを満たすシステム • 即応性(responsibility) • レジリエンス(resilient) • 弾力性(elastic)
• メッセージ駆動(message driven)
即応性(responsibility) • 迅速な応答時間、つまり高パフォーマンスな システムであること • 即応性はあらゆるシステムにおいて要求され るものであり、何かしら障害が起きたり高負 荷になったとしても、要求される水準のパ フォーマンスを保ち続けること
レジリエンス(resilient) • システムのどこかに障害が発生しても、レプ リケーション・封じ込め・隔離・委譲のいず れかの方法によって即応性を保つ • 単なるレジリエンスではなく、復旧・回復が 入る概念 • 何かしら予期しない障害が発生したとして
も、自律的に回復すること
弾力性(elastic) • リソースを増減させて要求される即応性・ス ループットを保ち続ける • スケーラビリティとの違いは、自動で伸縮す るかどうか • 弾力性のあるシステムは負荷に応じて自動 で伸縮する
メッセージ駆動(message driven) • 前述の即応性、レジリエンス、弾力性を実現するための手段 • 非同期なメッセージパッシングによってシステムを構築する • メッセージは、状態の変化などのイベントが発生した コンポーネントから発信されるデータ •
メッセージの受信者は、普段は休止しているがメッセー ジを受け取ったらそれに反応する • メッセージの送信者と受信者にコンポーネントを時間的・空 間的に分割することによってシステムが疎結合になる • 疎結合が、resilientとelasticのベースになる
メッセージ駆動?
https://speakerdeck.com/naoya/serverless-architecture
ちょっと違う • イベント駆動と似てやや非なるもので、メッセージが中 心にあるかどうか、が大きな違い • イベントは単なる観測可能なもの(`Observable`)でし かないが、メッセージには明確な目的がある • イベント駆動 •
通知のリスナーはイベントの発生源にあり、アドレス 可能なイベントソースが中心 • メッセージ駆動 • アドレス可能なメッセージ受信者が中心
http://www.reactivemanifesto.org/ja
why `Reactive System`
http://www.reactivemanifesto.org/ja
なぜリアクティブシステムなのか • 大規模化・複雑化・分散するシステム • 要求される水準がどんどん高くなってきている
なぜリアクティブシステムなのか • 大規模化・複雑化・分散するシステム • 要求される水準がどんどん高くなってきている • どうやって”いい感じに”まとめあげるか
なぜリアクティブシステムなのか システム全体の指針となる アーキテクチャが必要 • 大規模化・複雑化・分散するシステム • 要求される水準がどんどん高くなってきている • どうやって”いい感じに”まとめあげるか
システム全体の指針となる アーキテクチャが Reactive System
それだけ
Reactive Systemとして 具体的な設計や実装は 提示されていない
Immutable Infrastracture
Microservices
Serverless
昨今のバズワード(だった)ものたち • Immutable infrastracture • Microservices • Serverless
• Immutable infrastracture ⇒ 弾力性、レジリエンス • 負荷に応じてシステムを伸縮させるには不変なインフラがあって低コス トで起動/停止が可能でなければならない • 同じシステムを別のリソースで動かすこと(AZわけるみたいなレプリ
ケーション)が容易 • Microservices ⇒ レジリエンス、メッセージ駆動 • モノリシックだとサービス全体がダウンする可能性がある • マイクロサービスに切り分けていると、全体がダウンすることはなく、 一部のサービスが提供できない程度に被害を抑えられる • 全体としてのユーザー体験をなるべく損なわない • 明確なモジュール境界を設定することとなり、 モジュール間のやり取りは非同期なメッセージパッシングとなる • Serverless ⇒ 弾力性, メッセージ駆動 • shared nothingな"関数"だからこそスケールが容易 • 厳密にはイベント駆動だが、 別のイベントをkickすることも可能でメッセージ駆動ともいえる
`Reactive System` for application engineer
何が出来る? • 前述のバズワードたちはインフラ寄り • 各コンポーネント自体やそれを繋げるのは アプリケーションエンジニア • そこでリアクティブシステムを意識してい ないと台無し
何が出来る? • リアクティブシステムの基盤となる 「メッセージ駆動」という観点からプログラム を考える Scalaエンジニアなら でしょ
Akka(actor)がもたらすもの • メッセージパッシング(fire and forget) • ActorRefへのメッセージ送信がベース • 位置透過性(akka-remote/cluster) •
Let it crash • 障害からの回復(supervisor strategy) • バックプレッシャー(Reactive Stream) • コンポーネント間のメッセージ流量を制御
アクターモデル以外の OOP/FPの出番はない?
OOP/FPの出番はない? • アクターモデルというよりAkkaがリアクティブをサ ポートしているからやりやすいというだけ • 例えば以下のような考え方はアクターに限定されない • 外部サービスの呼び出し等はCircuitBreakerを使う • コンポーネント間で処理能力に差がある場合はス
ロットリングする • スケールアウトしやすいように切り分ける
Reactive Systemを意識して プログラムを書くのが大事
ちなみに、 Reactive Programmingと Reactive Systemは 別物です https://www.oreilly.com/ideas/reactive-programming-vs-reactive-systems
Summary
• 目指すべきはReactive System • 特に、即応性、弾力性、レジリエンスは全てに 共通 • 指針となるシステム全体のアーキテクチャ
• 目指すべきはReactive System • 特に、即応性、弾力性、レジリエンスは全てに 共通 • 指針となるシステム全体のアーキテクチャ • Actorつかわなきゃ!とか一切ない
• プログラミングモデルに左右されない • ScalaでもGolangでもPHPでも
• 目指すべきはReactive System • 特に、即応性、弾力性、レジリエンスは全てに 共通 • 指針となるシステム全体のアーキテクチャ • Actorつかわなきゃ!とか一切ない
• プログラミングモデルに左右されない • ScalaでもGolangでもPHPでも • 即応性を満たすフルマネージドサービス最強 • AWS-xxx, GAE, etc.
参考 • 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
次世代のシステムが あるべき姿 2016/12/22 @petitviolet