サービスをより“Stable”にする“ReactiveSystem”というアプローチ
•
0 likes•192 views
Rakuten Technology Conference 2019 @Sapporo
Recommended
More Related Content
Similar to サービスをより“Stable”にする“ReactiveSystem”というアプローチ
Similar to サービスをより“Stable”にする“ReactiveSystem”というアプローチ (20)
More from Rakuten Group, Inc.
More from Rakuten Group, Inc. (20)
Recently uploaded
Recently uploaded (8)
サービスをより“Stable”にする“ReactiveSystem”というアプローチ
- 1. サービスをより にする というアプローチ Nov 9, 2019 Kamata Yoshihiko EC Incubation Dept. Rakuten, Inc.
- 3. 3 持ち帰ってもらいたいこと • アーキテクチャ選定・設計をするための引き出しを増やす。 • “Reactive System”と、”Reactive Programming”の違いを 理解する。
- 4. 4 Agenda • “Reactive Programming”ではなく“Reactive System” です。 • リアクティブ宣言 • “Reactive System”の実装を紹介 • “Reactive System”とは？ • 私たちのサービスを例にして考えてみます。
- 5. 5 Do you know “Micro-services”?
- 6. 6 “Micro-services” Process space Process boundary Network boundary Host or Cluster boundary
- 7. 7 “Micro-services”のもたらすメリット • メンテナンス性の向上とテストのしやすさ • 疎結合 • 互いに独立したデプロイメント • Businessの責任範囲とのマッピング • サービスごとに独立した開発単位
- 8. 8 “Micro-services”によるデメリット • 複雑なアーキテクチャ → キャッチアップ、調査を困難にする。 • ネットワーク遅延との戦い • パラダイムシフト → 通信・デプロイ・管理など考えないといけない項目がMonolithic なApplicationより多い。
- 11. 11
- 15. 15 In computing, reactive programming is a declarative programming paradigm concerned with data streams and the propagation of change. With this paradigm it is possible to express static (e.g., arrays) or dynamic (e.g., event emitters) data streams with ease, and also communicate that an inferred dependency within the associated execution model exists, which facilitates the automatic propagation of the changed data flow. “Reactive programming”は、Streamデータを対象にしたパラダイムでデータの変化は自動的に 伝搬される。 宣言的な記述になり、静的/動的どちらのデータもStreamとして簡単に扱える。 Reactive programming, https://en.wikipedia.org/wiki/Reactive_programming, 2019.11.9
- 16. 16 例１ a = b + c; b = 1, c = 1; print a; b = 2; print a;
- 17. 17 “Reactive Extensions”は、元々はMicrosoftから”.NET”用にリリースされたもので、その後、 RxJava, RxJS, RxRubyなど各言語に広まっていったもの。 “Reactive Programming”の実装で、”Observer pattern”を取り入れている。 連続したデータやイベントを宣言的に記述することができ、マルチスレッド処理やNon-blocking処 理などが抽象化されている。 大本があって、それがメンテナンスされたものが各言語用にポーティングされているわけではないみ たいで、ものによってはしばらくメンテナンスされていなかったりするので、利用する際は、メンテ ナンスされているか確認したほうがよさそう。 例えば、RxJavaは継続的にメンテナンスされているが、RxRubyは2014年12月からCommitがない。
- 18. 18 ReactiveX intro, http://reactivex.io/intro.html, 2019.11.9
- 19. 19 ReactiveX intro, http://reactivex.io/intro.html, 2019.11.9
- 20. 20 “React(.js)”は、Facebookによってリリースされたライブラリで、Single Page Applicationに向いてい る。 ReactはEventを管理して、結果をVirtual DOMという仕組みを介してDOMに反映させる。 このデータの流れは単一方向に限定される。 似たコンセプトを持つものとしては”Vue.js”や”Angluar.js”が存在。
- 21. 21 Reactive Streams is an initiative to provide a standard for asynchronous stream processing with non-blocking back pressure. This encompasses efforts aimed at runtime environments (JVM and JavaScript) as well as network protocols. Reactive Streams, http://www.reactive-streams.org/, 2019.11.9 “Reactive Stream”は、”non-blocking back pressure”を伴う非同期ストリームの標準を提供する もので、実行環境とNetwork protocolを対象とした取り組みを含む。 これは、“Reactive System”を実現する上でも、取り入れることを検討したいものの一つです。
- 22. 22 ここから本題に入ります。
- 23. 23 Agenda • “Reactive Programming”ではなく“Reactive System” です。 • リアクティブ宣言 • “Reactive System”の実装を紹介 • “Reactive System”とは？ • 私たちのサービスを例にして考えてみます。
- 25. 25 リアクティブ宣言には何が書かれてる？ 求められているのは、システムアーキテクチャに対する明快なアプローチであると我々は考える。 そして、必要な側面の全ては既に独立に認識されている: 求めるものは、即応性と、耐障害性と、弾力性と、メッセージ駆動とを備えたシステムだ。 我々はこれをリアクティブシステム (Reactive Systems) と呼ぶ。 リアクティブシステムとして構築されたシステムはより柔軟で、疎結合で、スケーラビリティがある。 これによって開発が容易になるだけでなく、変更を受け入れやすくなる。 これらは障害に対してより著しい耐性を持ち、たとえ障害が起きても災害を起こすことなく優雅に対処する。 リアクティブシステムは高い即応性を持ち、ユーザに対して効果的な対話型フィードバックを与える。 リアクティブ宣言, https://www.reactivemanifesto.org/, 2019.11.9
- 27. 27 Elastic / 弾力性 システムはワークロードが変動しても即応性を保ち続ける。 リアクティブシステムは、入力の提供に割り当てるリソースを増加あるいは 減少させることで入力量の変化に反応する。 これは、システムの中に競合する場所や中心的なボトルネックが存在しないように設計し、 シャーディングしたりレプリケーションしたコンポーネント間に入力を分散させることを意味する。 リアクティブシステムは関連するライブな性能測定を提供することで、 予測的かつリアクティブなスケーリングアルゴリズムをサポートする。 これらは、コモディティなハードウェアとソフトウェアプラットフォーム上で 費用対効果の高い弾力性を実現する。 the Reactive Manifesto, https://www.reactivemanifesto.org/, 2019.11.9
- 28. 28 Resilient / 耐障害性 システムは障害に直面しても即応性を保ち続ける。 これが当てはまるのは高可用性のミッションクリティカルシステムだけではない — 耐障害性を持たないシステムは障害が起きると即応性を失う。 耐障害性は、レプリケーション、封じ込め、隔離、そして委譲によって実現される。 障害はそれぞれのコンポーネントに封じ込められ、コンポーネントは互いに隔離されるので、 システムが部分的に故障してもシステム全体を危険に晒すことなしに回復することが保証される。 各々のコンポーネントの回復処理は（外部の）他のコンポーネントに委譲され、 また必要な場合はレプリケーションによって高可用性を保証する。 コンポーネントのクライアントはコンポーネントの障害への対処に苦しめられることがなくなる the Reactive Manifesto, https://www.reactivemanifesto.org/, 2019.11.9
- 29. 29 Message Driven リアクティブシステムは非同期なメッセージパッシングに依ってコンポーネント間の境界を確立する。 これによって、疎結合性、隔離性、位置透過性を保証すると共に、 エラーをメッセージとして委譲する手段を確保する。 明示的なメッセージパッシングは負荷の管理と弾力性を可能とする。 また、システム内にメッセージキューを作成して監視し、 必要ならバックプレッシャーを適用することでフロー制御が可能になる。 通信の手段として位置透過なメッセージングを使うことで、 通信がクラスタを跨ぐ場合も単一のホスト内の場合も、同じ構成とセマンティクスで障害を管理できる。 ノンブロッキング通信により、受信側はアクティブ時のみリソースを消費できるので システムのオーバヘッドを抑制できる。 the Reactive Manifesto, https://www.reactivemanifesto.org/, 2019.11.9
- 30. 30 Responsive / 即応性 システムは可能な限りすみやかに応答する。 即応性とは使い勝手と実用性の基盤だが、しかしそれだけではなく、 問題が素早く検出され効果的に対処できることを意味する。 即応性のあるシステムは、迅速で、かつ一貫した応答時間を提供することに主眼を置く。 システムは応答時間に信頼性のある上限を確立し、一貫した品質のサービスを供給する。 この一貫した挙動によってエラー処理が単純化され、 エンドユーザの信頼を醸成し、さらなる相互作用を促す。 the Reactive Manifesto, https://www.reactivemanifesto.org/, 2019.11.9
- 31. 31 Agenda • “Reactive Programming”ではなく“Reactive System” です。 • リアクティブ宣言 • “Reactive System”の実装を紹介 • “Reactive System”とは？ • 私たちのサービスを例にして考えてみます。
- 32. 32 リアクティブ宣言によって、”Reactive System”の目指す姿は見えて きた。ただ、ここで述べられているのは概念的な説明のみだ。 実際に、自分たちのシステムに取り入れるにはどうしたらいいのか？ “Reactive System”を実装するものとして有名なものを 確認してみます。 ⇨ Netflixの“Hystrix”、“resilience4j” ⇨ Lightbendの“Akka”、“Play”、“Slick”
- 33. 33 HystrixはNetflixが開発した“耐遅延”、“耐障害”ライブラリで、High Traffic状態にあっても、 即応性を失わないようにする。 これは、一部機能（Micro-services呼び出し、外部APIなど）の障害によりサービスが全断してしまう ような事態を回避するために機能する。 “Circuit Breaker”によって応答不能を防ぐのと同時に、 監視機能を持ち、Alert機能や、 “Circuit Breaker”の自律的な管理も実現する。
- 34. 34 Fault Tolerance in a High Volume, Distributed System, https://medium.com/netflix-techblog/fault- tolerance-in-a-high-volume-distributed-system-91ab4faae74a, 2019.11.9
- 35. 35 Hystrixの開発は既に終了していて、後継となっているのは“resilience4j” “resilience4j”はHystrixにInspiredされたとされているが、Java8・関数型プログラミング向けに 設計されている。また、Hystrixに対して、依存関係を減らしており軽量なものになっている。 Reactive Programmingとしては、RxJava2やSpring Reactorを採用している。 実装する機能は、 ・Retry, Circuit Breaker, Rate Limiter, Time Limiter, Bulkhead, Cache, Fallback これらは、クラウド設計パターン（https://docs.microsoft.com/ja-jp/azure/architecture/patterns/） としても知られる。 新しいものらしく、Exporterも実装されている。
- 36. 36 Lightbend Reactive Platformは、個別のライブラリではなく、Reactive Systemを実現するための複数 のライブラリからなるカタログというか開発ガイドのようなもの。 Lightbend社のプロダクトだけでなく、Kafka, KubernetesまたはPublic Cloudなども含んでいて、 システムを構成する上で必要なライブラリなどが示されている。 Applicationを実装するためのライブラリとしては、Akka、Play、Slick、Lagomなどが提供される。 Akka、Play、Slickどれも非同期、Non-Blockingな特性を備えている。 アクターモデルのメッセージ駆動型ランタイムライブラリであるAkkaは、弾力性、耐障害性といったリ アクティブシステムに必要な特性を持ち、Play frameworkでも利用される。 また、Lagomは、Akka、Play frameworkで構築されたMicro service向けのフレームワークで、 疎結合、メッセージング、Circuit Beakerなどをサポートする他、永続化アーキテクチャのデフォルトが イベントベースになっている特徴がある。
- 37. 37 どちらも耐障害性を高めるためCircuit Breakerを備え、システムの応答性能を保つための仕組みを持つ。 また、Lightbend Reactive Platformは、イベントベースのデータ管理（イベントソーシング・CQRS） によって、シングルポイントになりやすいデータベースも登録(更新)と参照に分離することができて、 スケールしやすくしている。 -> akka 例えばCircuit Breakerのように、Kubernetesなどでもカバーできるものもあるが、常に応答可能なシ ステムを実現するための様々なアイデアがReactive Systemという視点から得られる。
- 38. 38 サービスメッシュで使われるIstioにもCircuit Breakerの機能がある。 ご存知の通り、Istioをインストールすると、Applicationの通信すべてにEnvoyが介在するよう になるが、そのEnvoyが実体としてこの機能を受け持つ。 Ref: https://www.envoyproxy.io/docs/envoy/latest/api-v2/clusters/clusters 検知できるトリガーとして、HTTP以外にもTCP、あるいはRedisなんかもNetwork filterとし て実装されている。この場合、非HTTPのものはHTTPにマップして扱われる。
- 40. 40 Agenda • “Reactive Programming”ではなく“Reactive System” です。 • リアクティブ宣言 • “Reactive System”の実装を紹介 • “Reactive System”とは？ • 私たちのサービスを例にして考えてみます。
- 41. 41
- 45. 45 ラッキーくじ スペック • ユーザーは期間内に１回だけ抽選される。 • 設定数以上の当たりを出してはいけない。 • 賞品は複数の等級が設定できる。 • 賞品には複数のタイプが存在する。 • テンプレートはカスタマイズ可能。 • 当選時にはユーザーへ当選メールを送信する。 • 参加者数/当選者数をリアルタイムに把握したい。
- 46. 46 ラッキーくじ 特性 • 複数の開催用途が存在する。 • 同時に複数のくじが開催される。 • SEO的に今のドメインは大事。 • 可能な限り100%の稼働率を求められる。
- 49. 49 ラッキーくじ Web Auth 問題点 Down or 不安定になった場合、 その場合は復帰を持つのみ。。。 Kubernetesに乗って、Down時の復旧 は早くなった。 リモートAPIが正常な応答を返せない場合、認証データが取得で きないが、打てる手がないので、影響件数が取れて、システム アラートの抑制ができればOK。 応答待ちによって受け口が詰まる事態の回避と、アラートの抑 制を実現するため、“Circuit Breaker”を導入。 回復に対する反応速度は検討が必要になるだろう。。。 Gem? or Envoy?
- 50. 50 Circuit Breaker 周辺 • Circuit Breaker • Rate Limit • Bulkhead • Retry • Time Limit • Cache • Health Check 相手側が弱い場合に 1/Nの障害で全滅しないように 自動でリトライしてくれると嬉しい 永遠に待たないために 結果をキャッシュ for Discovery
- 51. 51 Other Apps : 縮退 Client API 例えば、ページ表示処理において、PVカウンターみたいな パーツの取得処理であれば、表示できない影響は軽微。 むしろ、それの影響でページが全く表示できない方がCritical。 この場合の考え方としては、機能縮退として、Circuit Breakerを 使う手も考えられる。
- 52. 52 Other Apps : 制限 Client API API Cache Capacityの低いことが分かっているAPIに依存している場合に、 Rate Limitにより、閾値以上のアクセスがある場合はCacheを使う ようにする。あるいは、Circuit BreakerによりAPIへのアクセスが 遮断された場合、Cacheされた値を利用するように切り替える。 ということも考えられる。 内容は古いかもしれない
- 53. 53 ラッキーくじ スペック • ユーザーは期間内に１回だけ抽選される。 • 設定数以上の当たりを出してはいけない。 • 賞品は複数の等級が設定できる。 • 賞品には複数のタイプが存在する。 • テンプレートはカスタマイズ可能。 • 当選時にはユーザーへ当選メールを送信する。 • 参加者数/当選者数をリアルタイムに把握したい。
- 54. 54 ラッキーくじ Web MTA 問題点 単純に直接 “sendmail” を叩いてメー ル送信をしている為、指定されたア ドレスによってはTimeoutすることが ある。サービス終了とか。 sendmail Queue Cacheの考えで、直接MTAとやりとりすること を避けて、APPはQueueに入れて終わりにする。 これにより、APPはTimeoutする可能性が大幅に 少なくなる。 Queue -> MTAは、別プロセスで対応。 例えば、泥臭くPollingしたり、Serverlessアー キテクチャが使えるなら、Queuingをトリガー に、Jobを実行させるとか。
- 55. 55 当選メール : 代案 Web DB master DB slave-1 DB slave-2 DB slave-N Cache 当選確認が必要なだけなら、そもそもメールじゃないといけないのか？ 当選結果の照会画面で代替可能なら、切り替えてしまう手もあり？ 確定データの参照なのでスケールが容易。 出力データの形式によっては、Cacheを併用することも考慮。 Master -> Slaveの伝搬遅延についても検討する。
- 56. 56 ラッキーくじ スペック • ユーザーは期間内に１回だけ抽選される。 • 設定数以上の当たりを出してはいけない。 • 賞品は複数の等級が設定できる。 • 賞品には複数のタイプが存在する。 • テンプレートはカスタマイズ可能。 • 当選時にはユーザーへ当選メールを送信する。 • 参加者数/当選者数をリアルタイムに把握したい。
- 62. 62 ラッキーくじ スペック • ユーザーは期間内に１回だけ抽選される。 • 設定数以上の当たりを出してはいけない。 • 賞品は複数の等級が設定できる。 • 賞品には複数のタイプが存在する。 • テンプレートはカスタマイズ可能。 • 当選時にはユーザーへ当選メールを送信する。 • 参加者数/当選者数をリアルタイムに把握したい。
- 66. 66 ラッキーくじ スペック • ユーザーは期間内に１回だけ抽選される。 • 設定数以上の当たりを出してはいけない。 • 賞品は複数の等級が設定できる。 • 賞品には複数のタイプが存在する。 • テンプレートはカスタマイズ可能。 • 当選時にはユーザーへ当選メールを送信する。 • 参加者数/当選者数をリアルタイムに把握したい。
- 68. 68 ラッキーくじ スペック • ユーザーは期間内に１回だけ抽選される。 • 設定数以上の当たりを出してはいけない。 • 賞品は複数の等級が設定できる。 • 賞品には複数のタイプが存在する。 • テンプレートはカスタマイズ可能。 • 当選時にはユーザーへ当選メールを送信する。 • 参加者数/当選者数をリアルタイムに把握したい。
- 69. 69 ラッキーくじ スペック • ユーザーは期間内に１回だけ抽選される。 • 設定数以上の当たりを出してはいけない。 • 賞品は複数の等級が設定できる。 ご覧の通り、コアとなる部分です。社内の勉強会などで、システムを捉えるのに、単純 化・抽象化するように話をしていますが、このサービスで言えば、くじを作れて、抽選が できて、結果の管理ができることが大切だと思っていて、抽選はとても重要な部分です。 それだけに、Responsiveであることは必須になります。
- 70. 70 ラッキーくじ 話を進める前に、構成を確認します。 • 物理サーバーだった時代には３台構成だったこのサービスも、VMになりXX台構成にスケー ルされています。リソースも同様に拡張されています。 → 十分なスケールは既に実施済 • Public Cloudを頼れば簡単な実装も考えられますが、障害時のリカバリーを考えると難しい 部分があるのでオンプレ前提で考えてみます。 → コミュニケーションの問題、相手は大量の顧客を持っている。 → Public Cloudを使うのであれば、AZ、マルチクラウドなども検討しますよね。 • 現在はVMだが、Kubernetesへ移すことも可能。
- 73. 73 ラッキーくじ
- 74. 74 ラッキーくじ 対障害性を高めるため、外部リソースを扱う箇所 にCircuit Breakerを導入する。 また、エラー検出時だけでなく、パフォーマンス 低下を検知して、自動的に流入量を変えられるよ うに、Back pressureに対応した通信モジュールが 利用できるといいが、なければ自律的なRate Limit を実現できないか検討しておきたい。 また、ビジネスロジックごとに、所要時間が変 わってくるので、適当な単位でMicro service化さ せておくとリソースが有効活用できそうだ。
- 76. 76 ラッキーくじ 特性 • 複数の開催用途が存在する。 • 同時に複数のくじが開催される。 • SEO的に今のドメインは大事。 • 可能な限り100%の稼働率を求められる。
- 80. 80 まとめ • “Reactive Programming”と“Reactive System”は違う。 • リアクティブ宣言は何度も繰り返し読むべし。 • “Reactive System”の実装は非同期性が肝。 • “Reactive System”とは？ → 一貫した応答時間、品質を提供することを目的とした設計ア プローチです。
- 81. 81 持ち帰ってもらいたいこと • アーキテクチャ選定・設計をするための引き出しを増やす。 -> 新しい視点、Labelingが大切です。 • “Reactive System”と、”Reactive Programming”の違いを 理解する。 RP -> Observer patternを実装 RS -> Responsive system