リアクティブ・アーキテクチャ ～大規模サービスにおける必要性と課題〜 #devsumi
•
79 likes•33,894 views
2016/02/18 Developers Summit 2016 【18-E-5】 by @okapies http://event.shoeisha.jp/devsumi/20160218/
Recommended
More Related Content
What's hot
What's hot (20)
Similar to リアクティブ・アーキテクチャ ～大規模サービスにおける必要性と課題〜 #devsumi
Similar to リアクティブ・アーキテクチャ ～大規模サービスにおける必要性と課題〜 #devsumi (20)
リアクティブ・アーキテクチャ ～大規模サービスにおける必要性と課題〜 #devsumi
- 1. Developers Summit 2016【18-E-5】#devsumiE リアクティブ・アーキテクチャ ∼大規模サービスにおける必要性と課題∼ 岡本 雄太 (@okapies) 2016/02/18 Greg Walters, “Crazy Architecutre (UK)" - CC BY 2.0
- 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 を選ぶ３つの理由
- 6. アジェンダ • なぜ分散システムか？ • マイクロサービス • リアクティブシステムと Reactive Streams • 分散システムのつらい話と対策 • プログラミングモデル • 結果整合性 • 運用の複雑さ
- 10. なぜ分散システムか？ • 開発組織のスケーラビリティ • 性能のスケーラビリティ • 耐障害性 リアクティブシステム マイクロサービス
- 14. MSA を採用している企業 • Amazon • Twitter • Netflix • PayPal • LinkedIn • Tumblr • SoundCloud • LINE • ドワンゴ • etc…
- 16. マイクロサービスの特性 1. サービスによるコンポーネント化 2. ビジネス遂行能力に基づく組織化 3. プロジェクトではなくプロダクト 4. 賢いエンドポイントと愚かなパイプ 5. 非中央集権的なガバナンス 6. 非中央集権的なデータ管理 7. インフラの自動化 8. 障害を考慮した設計 9. 進化的設計 http://martinfowler.com/microservices/
- 17. マイクロサービスの特性 2. ビジネス遂行能力に基づく組織化 3. プロジェクトではなくプロダクト 5. 非中央集権的なガバナンス 9. 進化的設計 1. サービスによるコンポーネント化 4. 賢いエンドポイントと愚かなパイプ 6. 非中央集権的なデータ管理 7. インフラの自動化 8. 障害を考慮した設計 組織の特性 (目的) 技術の特性 (手段) http://martinfowler.com/microservices/
- 18. マイクロサービスの目的 • 開発組織のスケーラビリティの確保 • ビジネス遂行能力を核とした非中央集権的な 機能横断型チームとして組織化する (c.f. Conway’s Law) http://martinfowler.com/articles/microservices.html
- 19. マイクロサービスの方法論 • サービス間にビジネス遂行能力やドメインの ライフサイクルに従ってモジュール境界を持つ • サービス間は REST や単純な MQ で繋ぐ。ト ランザクションはなるべく使わない • サービス同士の依存関係を減らして独立に配 備できるようにする
- 20. マイクロサービスの利点 • 強いモジュール境界：マイクロサービスはモジュー ル構造を強化する。このことは、チームの規模が大 きくなるにつれて特に重要になる • 独立した配備：単純なサービスは配備が容易であ り、また自律的なので、個々に不具合が起きてもシ ステム障害を引き起こしにくい • 技術的多様性：複数の言語、開発フレームワーク、 データストレージ技術を組み合わせることができる http://martinfowler.com/articles/microservice-trade-offs.html
- 21. なぜ分散システムか？ • 開発組織のスケーラビリティ • 性能のスケーラビリティ • 耐障害性 リアクティブシステム マイクロサービス
- 23. Reactive Manifesto • Reactive Systems への支持を呼びかける文書 • 社（Scala/Akka 開発元）が主導 • 他に Dave Farley (”継続的デリバリー”の著者) や Martin Thompson (元 LMAX CTO) など • アクターモデル、特に Erlang/OTP や Akka のプ ラクティスを念頭に置いている 賛同者数 13,000 人超え
- 24. 様々なリアクティブ Reactive Systems Reactive Programming Reactive Streams プログラミングモデル: ランタイム: システムアーキテクチャ:
- 25. 様々なリアクティブ Reactive Systems Reactive Programming Reactive Streams プログラミングモデル ランタイム システムアーキテクチャ:
- 26. アプリケーションの要求の変化 数年前 現在 Configuration 数十のサーバ 数千の マルチコアプロセッサ Response time 秒単位 ミリ秒単位 Availability 数時間の オフラインメンテナンス 稼働率 100% Data size ギガバイト単位 ペタバイト単位
- 30. 私が仕事で関わった、大きなシステムのアー キテクチャには類似点があった。 そうしたシステムでは、問題領域における明 確な Bounded Context を実装したサービスが疎 結合で結びついており、互いの通信は非同期 メッセージのみで行う。 これらは、RDB の上に構築された箱出しの標 準的な三層アーキテクチャのシステムのやり方 とは似ても似つかない。 “The Reactive Manifesto | Dave Farley's Weblog” より妙訳
- 33. 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 の マイクロサービス構造
- 34. MSA ⊂ リアクティブシステム • マイクロサービスは、リアクティブシステムの 実例の一つと考えることができる • マイクロサービスは、リアクティブシステムの ４つの性質を備えているとより良い、と言え る
- 36. 自己完結性 (self-containment) • 各コンポーネントの内部状態は互いに隔離さ れ、かつ独立したライフサイクルを持つ • 障害を外部へ波及させることなく封じ込める ? ? in out × ×外部の状態を暗黙 に参照/更新しない
- 37. • コンポーネント同士が非同期メッセージパッ シングでデータをやり取りする • 共有メモリは使わない（競合の原因） メッセージ駆動 (message-driven) コンポー ネント コンポー ネント … メッセージバッファ
- 38. • メッセージを明示的にやり取りする • 負荷管理、弾力性、フロー制御が容易に • プロトコルは非同期なら何でもよい（REST で もメッセージキュー経由でも） コンポー ネント コンポー ネント メッセージ駆動 (message-driven) …
- 39. • コンポーネント間は非同期（バイナリ）境界 で区切られ、互いに別のスレッド、プロセス、 ノード、データセンターに配置できる • 疎結合、時間的・空間的隔離、位置透過性 コンポー ネント コンポー ネント メッセージ駆動 (message-driven) …
- 40. 補足: 位置透過性 • 全ては分散コンピューティングである • メッセージパッシングにおいて、単体ノード（マル チコア）と複数ノードにコンセプトの違いはない • コンポーネントが任意の場所に配備できるなら、 ローカル通信は最適化に過ぎない • メッセージパッシングは RPC ではない • ネットワーク関連の障害を明示的に扱う
- 41. レジリエンス (resilience) • 部分的に障害が発生してもシステム全体に波 及せず（自律的に）回復する、という特性 • 耐障害性よりも広い概念 • 「物体が元の形へ戻ったり、困難から素早 く立ち直る能力」のこと • 〈抵抗力＋復元力〉みたいなニュアンス
- 42. レジリエンス (resilience) • エラーを非同期境界で封じ込め、他のコン ポーネントに波及させず隔離する • （予期可能なエラーと障害を区別する） 例外
- 43. レジリエンス (resilience) • レプリケーションによって高可用性や冗長性 を確保（c.f. 非同期境界、位置透過性） ワークロードを複製
- 44. レジリエンス (resilience) • 障害時には、処理中のタスクや回復処理を他 のコンポーネントに委譲する (Let it crash) • コーヒー自販機の喩え（豆が切れたら客に〈コーヒー 豆エラー〉を返すのではなくサービスマンを呼んでほしい） Super- visor タスク エラー通知
- 45. 補足: Let it crash • 故障したコンポーネントはその場でクラッシュさせ て、監督者 (Supervisor) に回復処理を任せる • 「予期しない障害は必ず起きるし、人為的には防 げない」という実世界のシステムに対する観察 • Erlang 発祥の概念で、極めて高い信頼性が求められ るシステム（電話交換機など）で可用性を確保する のが目的
- 47. 弾力性 (elasticity) • 弾力性 = Scale Out + Scale In • シャーディングやレプリケーションによって コンポーネント間で入力を分散し、スケーラ ビリティを確保（c.f. 位置透過性） • 同期の競合やボトルネックの原因になるので、 メモリの共有はしない（メッセージ駆動）
- 48. マイクロサービスとの比較 • マイクロサービス ⊂ リアクティブコンポーネント • 強固なモジュール境界: 同期呼出ではなく非同期呼出に • 独立した配備: レジリエントなシステムは〈障害を考慮し た設計〉と〈進化的設計〉を満たす • 技術的多様性: 非同期処理やメッセージ駆動ミドルウェア を重視（HTTP 等でも実現は可能） • メッセージ送信はバッチ化（RPC 粒度の課題を解決）
- 49. どうやって実現するか？ どのようにこの属性を実現するのかについて、マニュ フェストの中で規範的に言及するのは避けたいと思い ました。 — Martin Thompson • マニフェストは、リアクティブシステムの性 質や品質についてのみ記述しており、具体的 な実現方法には触れていない http://www.infoq.com/jp/news/2014/11/thompson-reactive-manifesto-2
- 50. 国内事例 • LINE のメッセージング基盤は、Akka Actor を 活用したリアクティブな設計になっている • 「Akka ActorとAMQPでLINEのメッセージ ングパイプラインをリプレースした話」 • TIS が Akka を使ったデモを GitHub で公開し ている https://github.com/tech-sketch/reactive-solar-farm-monitor/
- 51. Reactive Solar Farm Monitor デモ https://github.com/tech-sketch/reactive-solar-farm-monitor/blob/master/README.ja.md
- 52. Reactive Solar Farm Monitor デモ http://www.slideshare.net/yugolf/typesafe-reactive-platformreactive-system/35
- 53. リアクティブシステムの課題 • リアクティブシステムは大量データを扱う非 同期データストリーム • 同期型とは異なり、システムに流れ込むデー タ流量を制御する仕組み（フロー制御）が 必要 • フロー制御に失敗すると、データフローが 決壊してシステム全体のクラッシュに繋がる
- 54. データフローの決壊 • Publisher は Subscriber へメッセージを送る Publisher Subscriber … 3 msgs/sec 3 msgs/sec メッセージバッファ 処理能力 送信能力 =
- 55. • Subscriber が速いときは暇になる → 計算機資源を有効活用できない Publisher Subscriber データフローの決壊 … < 3 msgs/sec 来ない…あんま送ると 悪いかな… 1 msg/sec
- 56. • Publisher が速すぎるとバッファが れて死ぬ Publisher Subscriber データフローの決壊 … > 3 msgs/sec 100 msgs/sec やめて！俺に まかせろー！
- 58. Reactive Streams • Back-Pressure でフロー制御を行う • 非同期ストリーム処理ランタイムの 相互運用性を確保するための標準規格
- 59. Back-Pressure • Publisher はリクエストされた分だけメッセー ジを送る → 安全 … 100 msgs/sec [Request(3)] Publisher Subscriber 3 msgs/sec 次、3 個くださいあいよー
- 60. Back-Pressure • Back-pressure は伝播する • C が遅くなったら B, A もスローダウンする B C … 今はいいです A … 今はいいですあいよー
- 61. 経緯 • Reactive Manifesto の発表 (2013年9月) • Typesafe の主導で、非同期ストリーム技術を 開発するベンダー各社の間で、フロー制御の技 術課題の解決策を話し合うコミュニティが発足 • GitHub に reactive-streams グループを作成。 正式に共同で仕様策定を始める (2014年初頭)
- 62. 主な参加者 • (Akka) • (RxJava) • (Reactor) • (Vert.x) Scala 言語の開発元 米国最大手の 動画配信サービス Spring Framework の開発元
- 63. 主な参加者 • Doug Lea • JSR 166 (java.util.concurrent) の Specification Lead • 「Java 並行処理プログラミング」 の著者の一人 • JDK での標準化は氏の主導で進められている http://www.amazon.co.jp/dp/4797337206/
- 64. Reactive Streams in JDK 9
- 65. SPI のインタフェース public interface Publisher<T> { public void subscribe(Subscriber<? super T> s); } public interface Subscriber<T> { public void onSubscribe(Subscription s); public void onNext(T t); public void onError(Throwable t); public void onComplete(); } public interface Subscription { public void request(long n); public void cancel(); } すべて戻り値なし＝非同期 語彙は RxJava がベース
- 67. 準拠実装 • Akka Streams (Typesafe) • Ratpack • Reactor (Spring) • RxJava (Netflix) • Vert.x 3.0 (Red Hat)
- 68. DB アクセスライブラリの準拠実装 • Slick 3.0 a.k.a “Reactive Slick” (JDBC) • ReactiveMongo • Reactive Rabbit (AMQP) • Reactive Kafka • etc…
- 69. すべてがリアクティブになる • リアクティブシステムを、Reactive Streams 準拠のコンポーネントを使って入口から出口 まで組み上げることができる AMQP Rx Java Akka Vert.x RDB 例:
- 70. 余談
- 71. なぜ分散システムか？ • 開発組織のスケーラビリティ • 性能のスケーラビリティ • 耐障害性 リアクティブシステム マイクロサービス …本当に分散したいんだっけ？
- 72. 分散オブジェクト設計の法則 • 第一法則: ？？？？？？？？？？ by Martin Fowler http://martinfowler.com/bliki/FirstLaw.html
- 73. 分散オブジェクト設計の法則 • 第一法則: オブジェクトを分散させるな by Martin Fowler http://martinfowler.com/bliki/FirstLaw.html 分散化にはデメリット がたくさんある
- 74. 「分散コンピューティングの落とし穴」 1. ネットワークは信頼できる。 2. レイテンシはゼロである。 3. 帯域幅は無限である。 4. ネットワークはセキュアである。 5. ネットワーク構成は変化せず一定である。 6. 管理者は１人である。 7. トランスポートコストはゼロである。 8. ネットワークは均質である。
- 75. マイクロサービスのコスト • 分散：分散システムはプログラムが難しい。リ モート呼出は遅いし、失敗のリスクがある • 結果整合性：分散システムで強い一貫性を維持 するのは非常に困難なので、結果整合性を管理 しなければならない • 運用の複雑さ：定期的に再配備する大量の サービスを管理する成熟した運用チームが必要 http://martinfowler.com/articles/microservice-trade-offs.html
- 76. 分散プログラミングのつらみ • RPC の逐次処理や並列処理 • ネットワークの障害・遅延・分断 • リモートホストの障害 • スロットリング（連鎖障害の防止） • サービスディスカバリ • モニタリング、リクエストの分散トレース
- 77. マイクロサービス向けフレームワーク • 大規模なマイクロサービスを運用している企 業のうち、いくつかは自社の基盤ソフトウェ アを OSS 化している • Netflix OSS • Twitter Finagle, Zipkin, etc…
- 78. Finagle Twitter の Finagle は、(Tumblr が) Scala を採用した抗し難い要 因だ。Finagle は、分散トレース、サービスディスカバリやサー ビス登録といった分散の課題のほとんどに対処してくれる。 • Finagle は、Tumblr や SoundCloud などが自社のマイクロサー ビスへの Scala 導入に踏み切る大きな要因になっている • 解説記事書いてます: 「マイクロサービスが Scala を選ぶ３ つの理由」 Tumblr Architecture - 15 Billion Page Views a Month and Harder to Scale than Twitter
- 80. http://monkey.org/~marius/funsrv.pdf Your Server as a Function Future 型と Service, Filter という関数 の組み合わせでサーバを記述する
- 81. Finagle による分散処理 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 他のマイクロサービスへクエリ を投げ、全ての応答が ったら 非同期に集約してタプルにする
- 82. What と How の分離 Input Input Output(2) ランタイム (1) プログラミングモデル (DSL) (how を実行する = メッセージ配送) (what を記述する = データフロー) 関数型プログラミングなどの 宣言的なプログラミングモデルと親和性が高い
- 83. 横断的関心事の合成 recordHandletime andThen traceRequest andThen collectJvmStats andThen parseRequest andThen logRequest andThen recordClientStats andThen sanitize andThen respondToHealthCheck andThen applyTrafficControl andThen virtualHostServer Filter (実態はただの関数) を Service に合成するだけで、 サーバに様々な横断的関心事 を追加できる http://monkey.org/~marius/funsrv.pdf
- 85. 結果整合性 • マイクロサービスやリアクティブ宣言の警句 • “分散トランザクションを避けよ” • “shared-nothing にして競合を最小化せよ” • ユースケース次第で最適解は変わる • 誤っていたら謝って手動で修正する、とか • とはいえ、万事それで片付くかというと…
- 87. 協調動作なしの整合性保証 • 万能な手法はない • パフォーマンスと整合性のトレードオフ • 保証したい整合性に合わせて手法を選ぶ • ログ指向アーキテクチャ • CRDT
- 88. ログ指向アーキテクチャ • Kafka のようなログ指向の分散 MQ に、他コンポー ネントへの全メッセージを書き込んで永続化 • 全てのコンシューマがメッセージを同じ順序で認 識することを保証する（書き込み順序は不定） • 大規模なマイクロサービスでは一般的？ • Twitter の Cassandra 後継の分散 DB “Manhattan” も同様のアイデアを採用している
- 90. CRDT • Conflict-Free Replicated Data Types • 順序に関係なく収束するデータ型と演算の組に ついて、分散ノード間で協調動作なしで強い結 果整合性を保ったデータ共有を実現する仕組み • Set, Counter, Register, Flag, Map, Graph 等 • できないこともあるので注意（ユニーク ID の 発行など）
- 91. CRDT の利用例 • League of Legends のチャットサーバ • Riak 上に実装している • フレンドリスト管理の分散化など • https://engineering.riotgames.com/news/chat- service-architecture-persistence • Akka でも利用できる (Akka Distributed Data モ ジュール)
- 92. 参考: LASP • Erlang + Riak Core ベースの分散処理言語 • Basho の Christopher Meiklejohn 氏が開発中。Oz 言語で有名な Peter Van Roy 氏が指導教官？ • “Coordination-Free Computations” • “Coordination-Free Designs for Mobile Gaming”
- 93. 参考: Coordination free • 協調動作 (coordination) をしなくても一貫性が 保証できる不変条件を定式化しようという研究 • Peter Bailis, “Coordination Avoidance in Database Systems” (スライド) • GitHub にある OSS を解析したら 86.9% はテ ストをパスしたとか
- 94. 運用の複雑さ • ひたすらつらい • 配備自動化やサービスディスカバリは必須 • 宣言型の DSL を書くと Mesos 等からリソースを割 り当てて自動配備してくれる世界になってほしい • 「イミュータブルインフラ」がバズった割には 命令型の DSL が主流な現状 (Dockerfile とか) • ビッグデータ周りではある意味実現している
- 95. https://speakerdeck.com/googlecloudjapan/google-cloud-dataflowwoli-jie-suru DAG でデータ処理 パイプラインを記述 in Google Cloud Dataflow
- 96. https://speakerdeck.com/googlecloudjapan/google-cloud-dataflowwoli-jie-suru ランタイムとしての Google Cloud データフロー定義 データフロー・ランタイムとしての Google クラウドが データフローの最適化とタスクのスケジュールを行う
- 98. まとめ • 分散システムの必要性 • 性能と組織のスケーラビリティ、耐障害性 • 分散システムはつらい • すでにある体系的な知見やアカデミアの研 究にも目を向けよう