@okapies
将来的にはScalaで仕事したい
スライド
- finagle-kafka
- sircuit
- rx-process
など
- ブログ記事とか翻訳とかやっている
- 今回はプログラミング寄りの話はしない
近年のソフトウェア開発の課題
- 非同期プログラミング
- イベント駆動
- 並行並列処理
- スケーラビリティ
- 耐障害性
なんでもリアクティブで解決しようというソリューション
- フロントエンドからバックエンドまでリアクティブがキーワードになってる(というかバズワードになりつつある)
- Reactive Programming Stream Manifestなど似たような言葉がホイホイ出てくる
- マイクロサービス 例 ふたつのマイクロサービスへの非同期クエリを束ねて出力 けっこうたいへん
- ビッグデータ処理 Hadoop Sparkなど
- JDK9におけるReactive Streams
What is Reactive?
- Programming model
- Runtime engine
- Architecture
文脈によって意味がぜんぜんちがう
重要なのはこの2つ。
- Reactive component
- Reactive data flow
Programming Model
- 問題 イベント処理 並行並列処理を楽にしたい
- 非同期処理といえばコールバックなんだけど
- なんでそれを使わないのか
- コールバックヘル(モジュール化しにくい/データの依存/実行順序の制御が困難)
- 例のピラミッド
Reactive Component
- コンポーネントの内部状態を互いに隔離
- 独立したライフサイクルをもっているので非同期処理にむいている
- すべてのinが一つの方向に集約している
- 状態と時間の問題をReactive Componentで解決しうる
- コンポーネントのなかでエラーが発生しても他のコンポーネントに波及しないのもメリット
Reactive Programming
- 実行順序の問題
- 説明 https://en.wikipedia.org/wiki/Reactive_programming
- データの有向グラフ
- 命令型のプログラミングが主流のプログラマにとって、データの有向グラフはわかりづらい
- 命令型の実行モデルではCを計算したあとにAを変更してもなにもおきない
- リアクティブな実行モデルではCを計算したあとにAを変更したらCの値が再計算される
- リアクティブプログラミングというと、関数型の概念が取り込まれることが多い
突然の関数型
ここの論文が詳しい http://worrydream.com/refs/Hughes-WhyFunctionalProgrammingMatters.pdf
Why Functional Programming Matters
- 一番重要なのはモジュール性の向上がFPにとって重要
- モジュール化のための「糊」としての、遅延評価と高階関数
- 問題を分割する方法は解を貼り合わせること
無限数のFizzBuzzの例
- 遅延評価を利用することで、欲しいものが欲しいだけできる 生成器と選択器
- 高階関数で関数に関数を渡すことで、ビジネスロジックとデータ型の文脈を分離(データ構造を関数に押し込められる)
Adopting FP glues to RP
FRPがはやるりゆう
- 非同期イベントを生成器/選択器で少しずつ処理
- ビジネスロジックを非同期イベントの挙動と分離
- map/zipでビジネスロジックをパイプライン化できる
- 実行モデルとデータを分離できる
- WhatをDSLで記述しHowをランタイムで実行する
- リアクティブにはプログラミングモデルとランタイムには密接な関係がある
マルチプラットフォーム性 (Portability)
リアクティブなプログラムは様々なアーキ上でマッピングできる
- 書いたデータフローをランタイムが最適化できる
- いろいろなことをランタイムで最適化できる(机上の空論のように見える？やってるんですよ)
(Fusing) 複数の処理ステップをひとつにまとめる融合機能
- データフローDSLとランタイムの組み合わせは近年様々な分野で適用されている
- TensorFlowなどはリアクティブなアーキ
- Hadoop以降はだいたいこのような考え方で実装されている
まとめ 1
- リアクティブなコンポーネントとイベント駆動
- 並行並列処理も解決しうる
次
- 最近は分散処理の必要性が高くなってきてる
- 耐障害(落ちても動かす)
- スケール(拡大)
- マイクロサービス
Reactive Manifesto
- 4つのアーキのなかで非同期メッセージ駆動がじゅうよう
responsive elastic resilient message-driven
バイナリ境界で隔離されたコンポーネント同士がメッセージのみでやりとり
- メッセージ駆動で弾力性とレジリエンスを達成
- あるコンポーネントがクラッシュしても非同期バイナリ境界で句切られているので他のコンポーネントに波及しない(let it crash) など
疑問
- Reactive Systemはどう実現するのか
- Manifestにも実際にはかいていなくて実装方法は議論して っていうスタンス
MicroService Architecture
- 巨大な開発組織をスケールさせるための方法論
- リアクティブシステムの実例のひとつとみることが出来る
- でもマイクロサービスアーキテクチャとリアクティブシステムと同一とも言えない
- ビジネス同士の依存関係をデータフローで表現できる
- 最近のビッグデータ処理フレームワークはだいたいリアクティブアーキテクチャを採用してる
- データフローの形でプログラミングしてる
- DAGでデータ処理パイプラインを記述する " 例 AsakusaFWとか
- データフロー定義をランタイムが最適化とスケジューリングを行う
まとめ
- データフローを定義
- クラウドレベルランタイムで翻訳(最適化とスケジューリング)
- リアクティブシステムでデプロイ
クラウドレベルのランタイムがデータフローをリアクティブシステムとして配備して実行する
これはWebサービスに適用できる？
- できる。
- でも、Dockerfileなどを見ると、命令型っぽい書き方
- immutable infraのimmutableってFP的なimmutableとはちょっと違う
まとめ
- 現代のプログラミングが抱えている問題を、リアクティブは解決できる
- リアクティブはシステムのあらゆる階層で有効な概念
- プログラミングモデルよりもランタイムの能力が重要な時代になってくるのでは
