なぜリアクティブは重要か #ScalaMatsuri
•
29 likes•7,896 views
"Why Reactive Matters" 日本語版 2016/01/30 ScalaMatsuri 2016 by @okapies http://scalamatsuri.org/ Togetter まとめ: http://togetter.com/li/931864
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to なぜリアクティブは重要か #ScalaMatsuri
Similar to なぜリアクティブは重要か #ScalaMatsuri (20)
なぜリアクティブは重要か #ScalaMatsuri
- 1. ScalaMatsuri 2016 なぜリアクティブは重要か 岡本 雄太 (@okapies) 2016/01/30 https://www.flickr.com/photos/livenature/204420128
- 2. 自己紹介 • 岡本 雄太(@okapies) • 製造業で働くソフト屋さん • Scala と Scala OSSs 愛好家 • 最近の仕事はインフラエンジニアっぽい感じ • ScalaMatsuri 2016 準備委員会 運営委員
- 3. 公開してる OSS • finagle-kafka (https://github.com/okapies/ finagle-kafka) • sircuit (https://github.com/okapies/sircuit) • rx-process (https://github.com/okapies/rx- process)
- 4. 書き物 • 翻訳: • リアクティブ宣言 v2.0 • Effective Scala 日本語版 • 命令型のコールバック、関数型のプロミス • ブログ記事 (http://okapies.hateblo.jp/): • 非同期ストリーム処理の標準化を目指す "Reactive Streams" とは • 関数型プログラマのための Rx 入門 • マイクロサービスが Scala を選ぶ３つの理由
- 5. 関連するセッション • 12:00 - 12:40（国際交流会議場）: • リアクティブ・マイクロサービス (Christopher Hunt) • 15:00 - 15:40（メディアホール）: • レジリエンスが無ければ、他は無いも同じ (Jonas Bonér)
- 6. 今日のソフト開発が直面する課題 • 非同期＆イベント駆動プログラミング • 並行・並列処理 • システムと組織のスケーラビリティ • 耐障害性 （マイクロサービス）
- 8. どこでもリアクティブ！ • フロントエンドからバックエンドまで、様々な 文脈で〈リアクティブ〉がキーワードに • 互いに似ているけど異なる様々なコンセプト: • Reactive Programming • Reactive Streams • Reactive Manifesto
- 9. フロントエンド GUI マルチクリックストリーム https://gist.github.com/staltz/868e7e9bc2a7b8c1f754 250 ミリ秒毎に クリックを集積 リストを長さ にマッピング RxJS による非同期クリックストリーム
- 10. GUI とネットワークサービス https://github.com/reark/reark RxJava + Android 製のデモアプリ 非同期 GUI イベント と JSON API 呼び出 しを並行処理として 組み合わせる
- 11. マイクロサービス val userAndTweets = Future.join( userService.findByUserId(userId), tweetService.findByUserId(userId) ) find find userId userAndTweets User Service Tweet Service http://www.slideshare.net/knoldus/finagle-by-twitter-engineer/16 join 他のマイクロサービスへクエリ を投げ、全ての応答が ったら 非同期に集約してタプルにする Twitter Finagle
- 13. Reactive Streams が JDK 9 に
- 14. Reactive?
- 16. リアクティブの基盤 • リアクティブなコンポーネント ! • リアクティブなデータフロー in out 1 2 A B C
- 17. リアクティブなコンポーネント • 入力にのみ反応 (react) してデータを出力する • 自己完結性 in out 関数？ オブジェクト？ アクター？ サブシステム？
- 20. 課題（再掲） • 非同期＆イベント駆動プログラミング • 並行・並列処理 • システムと組織のスケーラビリティ • 耐障害性
- 21. コールバックじゃダメなの？ // asynchronous event def mouseClick(f: (Int, Int) => Unit): Unit ! // register a callback as an argument mouseClick { case (x, y) => println(s"x: $x, y: $y”) } コールバック
- 22. コールバック地獄 • コードのモジュール化が困難 • 状態（副作用）やデータの依存関係の管理が 困難 • 実行順序の制御が困難（外部イベント次第で 変化する）
- 23. 破滅のピラミッド var g = ... ! step1 { a => step2 { b => step3 { c => step4 { d => // do something with a, b, c, d and g } } } } 依存する非同期ステップが ピラミッドのように積み上がる 外側のスコープの状態を暗黙に 参照していてモジュール性が低い
- 25. 自己完結性 • 各コンポーネントの内部状態は互いに隔離さ れ、かつ独立したライフサイクルを持つ • 自己完結性があると非同期処理がやりやすい ? ? in out × ×外側の変数を 暗黙に使わない
- 26. 利点 • モジュール性（組み合わせ可能性）が向上 • 状態や障害の封じ込めが容易になる ? ? in out × ×
- 27. 実行順序と依存性 • 非同期プログラミングで実行順序をどうやっ て制御すればいいか？ • 解決策: リアクティブ・プログラミング
- 30. 一般的な (命令型の) プログラム A = 1; B = 2; C = (A+1) + (B-1)*2; 上から順に実行する
- 31. -1 ×2 + +1A B C 命令型コードをデータフローに A = 1; B = 2; C = (A+1) + (B-1)*2; 1 2 4 1 2 2
- 32. 実行モデル • データフローそのものは、変数と演算の間の 依存関係を記述しているだけ • グラフの具体的な計算方法は実行モデルが決 める A B C +1 —1 ×2 + A = 1; B = 2; C = (A+1) + (B-1)*2;
- 33. -1 ×2 + +1A B C 変数への再代入 A = 1; B = 2; C = (A+1) + (B-1)*2; A = 2; 1 $ 2 2 4 A の変更は C に伝搬しない 命令型の実行モデル × × ×× × ×
- 34. -1 ×2 + +1A B C 変数への再代入 A := 1; B := 2; C := (A+1) + (B-1)*2; A := 2; 1 $ 2 4 $ 52 1 $ 3 1 2 A の変更が C に伝搬する リアクティブの実行モデル
- 35. -1 ×2 + +1A B C 変数への再代入 2 5 $ 72 $ 3 1 $ 2 2 $ 4 3 C := (A+1) + (B-1)*2; A := 2; B := 3; リアクティブの実行モデル B の変更が C に伝搬する
- 36. -1 ×2 + +1A B C 変数への再代入 2 $ 0 7 $ 53 2 4 3 $ 1 A := 2; B := 3; A := 0; リアクティブの実行モデル A の変更が C に伝搬する
- 38. 例 (Akka Streams): implicit val system = ActorSystem() implicit val mat = ActorMaterializer() ! val a = Source(...) val b = Source(...) ! val a1 = a.map(_ + 1) val b1 = b.map(_ - 1).map(_ * 2) ! val c = (a1 zip b1).map{case (a, b) => a + b} ! c.runWith(Sink.foreach(println))(mat) A B C +1 —1 ×2 + 先ほどのデータフローを 関数型 DSL で記述する
- 39. 例 (Akka Streams): implicit val system = ActorSystem() implicit val mat = ActorMaterializer() ! val a = Source(...) val b = Source(...) ! val a1 = a.map(_ + 1) val b1 = b.map(_ - 1).map(_ * 2) ! val c = (a1 zip b1).map{case (a, b) => a + b} ! c.runWith(Sink.foreach(println))(mat) 入力に適用する関数を 高階関数 map で繋ぎ合わせる 関数 入力 A B C +1 —1 ×2 +
- 41. なぜ関数プログラミングは重要か • QuickCheck の開発や QuviQ の創業者として 知られるジョン・ヒューズ博士の著名な論文 • 初版は 1984 年（30 年前！） • 関数型プログラミングを活用して、コードの モジュール性を高める方法について論じてい る http://www.cse.chalmers.se/~rjmh/Papers/whyfp.html
- 42. 関数型の〈糊〉 • 関数型における二つの重要な〈糊〉 • 遅延評価 • 高階関数（コンビネータ） 「元の問題を分割する方法は、解と解を貼り合 わせる方法に直接に依存する。」
- 43. 遅延評価 class Cons[A](hd: A, tl: => List[A]) extends List[A] ! def nats(n: Int): List[Int] = new Cons(n, nats(n+1)) def fizzbuzz(n: Int) = n match { case _ if n % 15 == 0 => "FizzBuzz" case _ if n % 3 == 0 => "Fizz" case _ if n % 5 == 0 => "Buzz" case _ => n.toString } nats.map(fizzbuzz).take(100).foreach(println) 必要呼び （プル型） コードを生成器と選択器の 組み合わせでモジュール化できる 無限リスト
- 44. 高階関数 • プログラムを、汎用的な高階関数とユースケー スに特化した関数に分けてモジュール化 ! ! • ビジネスロジックと、それが乗っかるデータ 型の文脈を分離できる set. map(_ + 1) // Set[A] map. map(_ + 1) // Map[A, B] list.map(_ + 1) // List[A] 局所化された文脈 ビジネスロジックを使い回せる
- 45. FP の糊を RP に適用すると？ • 遅延評価: • 非同期イベントを少しずつ処理する生成器・選 択器のパイプラインとしてプログラムを構成す る（プッシュ型） • 高階関数: • ビジネスロジックと、それが乗っかる非同期イ ベント駆動の文脈を分離する
- 46. FRP の〈糊〉 implicit val system = ActorSystem() implicit val mat = ActorMaterializer() ! val a = Source(...) val b = Source(...) ! val a1 = a.map(_ + 1) val b1 = b.map(_ - 1).map(_ * 2) ! val c = (a1 zip b1).map{case (a, b) => a + b} ! c.runWith(Sink.foreach(println)) A B C +1 —1 ×2 + 生成器 非同期の文脈を局所化した高階関数 (map, zip 等)を使い、 ビジネスロジックをパイプライン化する 選択器 局所化された非同期の文脈
- 47. • 多くの FRP のデータフロー記述は宣言型 DSL: 構築したデータフローを実際にスケジュールし 実行するのはランタイムの役割 what と how の分離 implicit val system = ActorSystem() implicit val mat = ActorMaterializer() ! val c = (a1 zip b1).map{case (a, b) => a + b} ! c.runWith(Sink.foreach(println))(mat) ランタイム
- 48. what と how の分離 Input Input Output(2) ランタイム (1) プログラミングモデル (DSL) (how を実行する = 変更の伝搬) (what を記述する = データフロー)
- 50. 可搬性（マルチプラットフォーム） • リアクティブなプログラムは、ランタイムによっ て様々なアーキテクチャにマッピングできる • 単一マシン • GPU クラスタ • 分散環境
- 51. 最適化 • データフローの性能や安定性をランタイムが 最適化できる • 融合、データ局所化、キャッシュ • 並列分散化 • 検証
- 52. 例: 融合 (Fusing) • Akka Streams 2.0 の新機能 This new abstraction … is called fusing. This feature … will be now possible to execute multiple stream processing steps inside one actor, reducing the number of thread-hops where they are not necessary … will increase performance for various use cases, including HTTP. http://akka.io/news/2015/11/05/akka-streams-2.0-M1-released.html 複数の処理ステップを 一つにまとめて性能向上
- 53. 実装例 • データフロー DSL とランタイムの組み合わせは、近 年、様々な分野で適用されている • Akka Streams, ReactiveX, … • 科学技術計算: TensorFlow, Halide • ビッグデータ処理: Spark, Google Cloud Dataflow, Asakusa Framework, Gearpump
- 55. 課題（再掲） • 非同期＆イベント駆動プログラミング • 並行・並列処理 • システムと組織のスケーラビリティ • 耐障害性 DO NE!
- 57. 単一マシン ! ! 分散システム
- 58. なぜ分散システムか？ • 非同期＆イベント駆動プログラミング • 並行・並列処理 • システムと組織のスケーラビリティ • 耐障害性 → リアクティブ・システム （マイクロサービス）
- 60. アプリケーションの要求の変化 数年前 現在 Configuration 数十のサーバ 数千の マルチコアプロセッサ Response time 秒単位 ミリ秒単位 Availability 数時間の オフラインメンテナンス 稼働率 100% Data size ギガバイト単位 ペタバイト単位
- 64. RS におけるコンポーネント • メッセージのみを介して互いに通信する • 自己完結しており非同期（バイナリ）境界で 互いに隔離されている アクター サブシステム in out
- 65. メッセージ駆動が達成するもの • 弾力性: スケーラビリティ、シャーディング、 レプリケーション、位置透過性 • レジリエンス: レプリケーション、隔離、タス クやエラーの委譲 (“Let it crash”)
- 66. リアクティブシステムをどう構築するか？ マニフェストの中で、その実現方法について規範的なことは述 べたくなかった。 — Martin Thompson • マニフェストは、リアクティブなコンポーネントやシス テムの性質や品質についてのみ記述しており、具体的な 実現方法には触れていない • 実例としてマイクロサービス・アーキテクチャ (MSA) を 見てみよう http://www.infoq.com/news/2014/10/thompson-reactive-manifesto-2
- 67. マイクロサービス・アーキテクチャ • Amazon, Netflix, Twitter のような巨大な開発 組織をスケールさせるための方法論 • サービスを、ビジネス遂行能力に沿って小さく 独立したモジュールに分ける（c.f. コンウェイ の法則） • リアクティブシステムの実例の一つとみなせる
- 68. STORAGE & RETRIEVAL LOGICPRESENTATIONROUTING Redis Memcache Flock T-Bird MySQLTweet User Timeline Social Graph DMs API Web Monorail TFE HTTP Thrift “Stuff” http://monkey.org/~marius/scala2015.pdf 例: Twitter における マイクロサービス
- 69. システムレベルのデータフロー • MSA は（リアクティブな）コンポーネント と、そのビジネス上の依存関係で構成される • つまりシステムレベルのデータフロー • ならば、分散システム全体をコードとして記 述できないだろうか？ A B C
- 70. リアクティブ・ビッグデータ • 近年のビッグデータ処理フレームワークでは、リア クティブなアーキテクチャが採用されることが多い • Spark • Google Cloud Dataflow • Gearpump (Intel) • Asakusa Framework
- 71. https://speakerdeck.com/googlecloudjapan/google-cloud-dataflowwoli-jie-suru DAG でデータ処理 パイプラインを記述 in Google Cloud Dataflow
- 72. DAG on Spark https://cloud.githubusercontent.com/assets/2133137/7625997/e0878f8c-f9b4-11e4-8df3-7dd611b13c87.png 実行中の Spark ジョブを DAG として可視化した例
- 73. http://www.gearpump.io/overview.html Gearpump の Akka を 使ったリアクティブ・ アーキテクチャ
- 74. http://knowledge.sakura.ad.jp/tech/4016/ http://docs.asakusafw.com/preview/ja/html/asakusa-on-spark/user-guide.html Asakusa Framework 一つの DSL アプリを Hadoop でも Spark でも ポータブルに実行できる
- 75. Apache Dataflow (New!) http://googlecloudplatform.blogspot.co.uk/2016/01/Dataflow-and-open-source-proposal-to-join-the-Apache-Incubator.html Google 主導によるデータフロー記述の標準化の取り組み
- 76. https://speakerdeck.com/googlecloudjapan/google-cloud-dataflowwoli-jie-suru ランタイムとしての Google Cloud Optimize Schedule Flow of pipeline User code & SDK Monitoring UI データフロー定義 データフロー・ランタイムとしての Google クラウドが データフローの最適化とタスクのスケジュールを行う
- 78. 一般化すると… • クラウドレベルのランタイムは: • 指定されたデータフローを最適化すると共に、リアク ティブなコンポーネントをスケジューリングする • YARN や のような分散リソースマネージャ からリソースを獲得する • 確保したリソースにコンポーネントを配備し、リアク ティブ・システムとして実行する Dataflow Reactive System Cloud-level Runtime
- 79. ウェブサービスの配備自動化 • 現代の DevOps ツールは、主にノードごとにシ ステムを設定することに焦点を当てており、 Dockerfile のような命令的な記述を用いている • イミュータブル・インフラストラクチャは、本 来、リアクティブなコンポーネントと宣言的な データフローの組み合わせとして実現されるべ きだったのでは？
- 80. まとめ • リアクティブ・プログラミングとアーキテクチャによっ て、今日のソフト開発が直面する課題を解決できる: • 非同期＆イベント駆動プログラミング • 並行・並列処理 • システムと組織のスケーラビリティ • 耐障害性