Download as PDF, PPTX
 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)必要呼び（プル型）コードを生成器と選択器の組み合わせでモジュール化できる無限リスト](/image.pl?url=https%3a%2f%2fimage.slidesharecdn.com%2fwhyreactivematters20160130jp-160211100952%2f85%2fScalaMatsuri-43-320.jpg&f=jpg&w=240)
![高階関数• プログラムを、汎用的な高階関数とユースケースに特化した関数に分けてモジュール化!!• ビジネスロジックと、それが乗っかるデータ型の文脈を分離できるset. map(_ + 1) // Set[A]map. map(_ + 1) // Map[A, B]list.map(_ + 1) // List[A]局所化された文脈 ビジネスロジックを使い回せる](/image.pl?url=https%3a%2f%2fimage.slidesharecdn.com%2fwhyreactivematters20160130jp-160211100952%2f85%2fScalaMatsuri-44-320.jpg&f=jpg&w=240)
Uploaded byYuta Okamoto
PDF, PPTX7,920 views
なぜリアクティブは重要か #ScalaMatsuri
"Why Reactive Matters" 日本語版2016/01/30 ScalaMatsuri 2016 by @okapieshttp://scalamatsuri.org/Togetter まとめ: http://togetter.com/li/931864
![Scalaで萌える関数型プログラミング[完全版]](/image.pl?url=https%3a%2f%2fcdn.slidesharecdn.com%2fss_thumbnails%2folbjpscala-110717003227-phpapp01-thumbnail.jpg%3fwidth%3d640%26amp%3bheight%3d640%26amp%3bfit%3dbounds&f=jpg&w=240)
なぜリアクティブは重要か #ScalaMatsuri
- 1.ScalaMatsuri 2016なぜリアクティブは重要か岡本 雄太(@okapies)2016/01/30https://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（国際交流会議場）:• リアクティブ・マイクロサービス (ChristopherHunt)• 15:00 - 15:40（メディアホール）:• レジリエンスが無ければ、他は無いも同じ (JonasBonér)
- 6.今日のソフト開発が直面する課題• 非同期＆イベント駆動プログラミング• 並行・並列処理•システムと組織のスケーラビリティ• 耐障害性（マイクロサービス）
- 8.どこでもリアクティブ！• フロントエンドからバックエンドまで、様々な文脈で〈リアクティブ〉がキーワードに• 互いに似ているけど異なる様々なコンセプト:•Reactive Programming• Reactive Streams• Reactive Manifesto
- 9.
- 10.GUI とネットワークサービスhttps://github.com/reark/rearkRxJava +Android 製のデモアプリ非同期 GUI イベント と JSON API 呼び出 しを並行処理として 組み合わせる
- 11.マイクロサービスval userAndTweets =Future.join(userService.findByUserId(userId),tweetService.findByUserId(userId))findfinduserId userAndTweetsUser ServiceTweet Servicehttp://www.slideshare.net/knoldus/finagle-by-twitter-engineer/16join他のマイクロサービスへクエリを投げ、全ての応答が ったら非同期に集約してタプルにするTwitter Finagle
- 12.
- 13.Reactive Streams がJDK 9 に
- 14.
- 15.
- 16.
- 17.リアクティブなコンポーネント• 入力にのみ反応 (react)してデータを出力する• 自己完結性in out関数？オブジェクト？アクター？サブシステム？
- 18.
- 19.
- 20.課題（再掲）• 非同期＆イベント駆動プログラミング• 並行・並列処理•システムと組織のスケーラビリティ• 耐障害性
- 21.コールバックじゃダメなの？// asynchronous eventdefmouseClick(f: (Int, Int) => Unit): Unit!// register a callback as an argumentmouseClick { 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}}}}依存する非同期ステップが ピラミッドのように積み上がる外側のスコープの状態を暗黙に 参照していてモジュール性が低い
- 24.
- 25.自己完結性• 各コンポーネントの内部状態は互いに隔離され、かつ独立したライフサイクルを持つ• 自己完結性があると非同期処理がやりやすい??in out× ×外側の変数を 暗黙に使わない
- 26.
- 27.実行順序と依存性• 非同期プログラミングで実行順序をどうやって制御すればいいか？• 解決策:リアクティブ・プログラミング
- 28.
- 29.
- 30.一般的な (命令型の) プログラムA= 1;B = 2;C = (A+1) + (B-1)*2;上から順に実行する
- 31.-1×2++1AB C命令型コードをデータフローにA =1;B = 2;C = (A+1) + (B-1)*2;12 41 22
- 32.実行モデル• データフローそのものは、変数と演算の間の依存関係を記述しているだけ• グラフの具体的な計算方法は実行モデルが決めるABC+1—1×2+A = 1;B = 2;C = (A+1) + (B-1)*2;
- 33.-1×2++1AB C変数への再代入A =1; B = 2;C = (A+1) + (B-1)*2; A = 2;1 $ 22 4A の変更は C に伝搬しない命令型の実行モデル××××× ×
- 34.-1×2++1AB C変数への再代入A :=1; B := 2; C := (A+1) + (B-1)*2; A := 2;1 $ 24 $ 521 $ 31 2A の変更が C に伝搬するリアクティブの実行モデル
- 35.-1×2++1AB C変数への再代入25 $72 $ 31 $ 2 2 $ 43C := (A+1) + (B-1)*2; A := 2;B := 3;リアクティブの実行モデルB の変更が C に伝搬する
- 36.-1×2++1AB C変数への再代入2 $07 $ 532 43 $ 1A := 2; B := 3; A := 0;リアクティブの実行モデルA の変更が C に伝搬する
- 37.
- 38.例 (Akka Streams):implicitval 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)AB C+1—1×2+先ほどのデータフローを 関数型 DSL で記述する
- 39.例 (Akka Streams):implicitval 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 で繋ぎ合わせる関数入力AB C+1—1×2+
- 40.
- 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 valsystem = 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))AB 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の分離InputInputOutput(2) ランタイム(1) プログラミングモデル (DSL)(how を実行する = 変更の伝搬)(what を記述する = データフロー)
- 49.
- 50.
- 51.
- 52.例: 融合 (Fusing)•Akka Streams 2.0 の新機能This new abstraction … is called fusing. This feature… will be now possible to execute multiple streamprocessing steps inside one actor, reducing thenumber of thread-hops where they are notnecessary … will increase performance for varioususe 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
- 54.
- 55.課題（再掲）• 非同期＆イベント駆動プログラミング• 並行・並列処理•システムと組織のスケーラビリティ• 耐障害性DONE!
- 56.
- 57.
- 58.なぜ分散システムか？• 非同期＆イベント駆動プログラミング• 並行・並列処理•システムと組織のスケーラビリティ• 耐障害性→ リアクティブ・システム（マイクロサービス）
- 59.
- 60.アプリケーションの要求の変化数年前 現在Configuration 数十のサーバ数千の マルチコアプロセッサResponse time秒単位ミリ秒単位Availability数時間の オフラインメンテナンス稼働率 100%Data size ギガバイト単位 ペタバイト単位
- 61.
- 62.
- 63.
- 64.RS におけるコンポーネント• メッセージのみを介して互いに通信する•自己完結しており非同期（バイナリ）境界で互いに隔離されているアクターサブシステムin out
- 65.メッセージ駆動が達成するもの• 弾力性: スケーラビリティ、シャーディング、レプリケーション、位置透過性•レジリエンス: レプリケーション、隔離、タスクやエラーの委譲 (“Let it crash”)
- 66.リアクティブシステムをどう構築するか？マニフェストの中で、その実現方法について規範的なことは述べたくなかった。 — MartinThompson• マニフェストは、リアクティブなコンポーネントやシステムの性質や品質についてのみ記述しており、具体的な実現方法には触れていない• 実例としてマイクロサービス・アーキテクチャ (MSA) を見てみようhttp://www.infoq.com/news/2014/10/thompson-reactive-manifesto-2
- 67.マイクロサービス・アーキテクチャ• Amazon, Netflix,Twitter のような巨大な開発組織をスケールさせるための方法論• サービスを、ビジネス遂行能力に沿って小さく独立したモジュールに分ける（c.f. コンウェイの法則）• リアクティブシステムの実例の一つとみなせる
- 68.STORAGE &RETRIEVALLOGICPRESENTATIONROUTINGRedisMemcacheFlockT-BirdMySQLTweetUserTimelineSocialGraphDMsAPIWebMonorailTFEHTTP Thrift“Stuff”http://monkey.org/~marius/scala2015.pdf例: Twitter におけるマイクロサービス
- 69.システムレベルのデータフロー• MSA は（リアクティブな）コンポーネントと、そのビジネス上の依存関係で構成される•つまりシステムレベルのデータフロー• ならば、分散システム全体をコードとして記述できないだろうか？AB C
- 70.リアクティブ・ビッグデータ• 近年のビッグデータ処理フレームワークでは、リアクティブなアーキテクチャが採用されることが多い• Spark•Google Cloud Dataflow• Gearpump (Intel)• Asakusa Framework
- 71.
- 72.
- 73.http://www.gearpump.io/overview.htmlGearpump の Akkaを 使ったリアクティブ・ アーキテクチャ
- 74.
- 75.
- 76.https://speakerdeck.com/googlecloudjapan/google-cloud-dataflowwoli-jie-suruランタイムとしてのGoogle CloudOptimizeScheduleFlow ofpipelineUser code & SDK Monitoring UIデータフロー定義データフロー・ランタイムとしての Google クラウドがデータフローの最適化とタスクのスケジュールを行う
- 77.
- 78.一般化すると…• クラウドレベルのランタイムは:• 指定されたデータフローを最適化すると共に、リアクティブなコンポーネントをスケジューリングする•YARN や のような分散リソースマネージャからリソースを獲得する• 確保したリソースにコンポーネントを配備し、リアクティブ・システムとして実行するDataflowReactive SystemCloud-level Runtime
- 79.ウェブサービスの配備自動化• 現代の DevOpsツールは、主にノードごとにシステムを設定することに焦点を当てており、Dockerfile のような命令的な記述を用いている• イミュータブル・インフラストラクチャは、本来、リアクティブなコンポーネントと宣言的なデータフローの組み合わせとして実現されるべきだったのでは？
- 80.まとめ• リアクティブ・プログラミングとアーキテクチャによって、今日のソフト開発が直面する課題を解決できる:• 非同期＆イベント駆動プログラミング•並行・並列処理• システムと組織のスケーラビリティ• 耐障害性
- 81.