Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Webアプリに低レイテンシ・高可用性を求めるのは間違っているのだろうか

6,277 views

Published on

Tech Deep Dive #0
https://connpass.com/event/72517/
2017年12月20日
高い可用性を持ちながらも低レスポンスタイム高スループットの性能を持つシステムを構築するために、何をどのように作ればよいのかを、アーキテクチャから実装レベルまで紹介いたします。

Published in: Software
  • Be the first to comment

Webアプリに低レイテンシ・高可用性を求めるのは間違っているのだろうか

  1. 1. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Webアプリに低レイテンシ・高可用性を 求めるのは間違っているのだろうか 伊藤智博(Chihiro Ito) @chiroito 日本オラクル株式会社 コンサルティングサービス事業統括 Tech Deep Dive #0 https://connpass.com/event/72517/
  2. 2. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle. 2
  3. 3. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 3 • Technologist • お客様のビジネス課題を技術で 解決する仕事をしています。 • 以前はミッションクリティカルなシステム のアーキテクチャを検討~実装の支援 やトラブルシューティングをしてました。 • 専門技術は Java SE、データグリッド、 分散・並列・Stream処理。 • 趣味でOpenJDK Author 自己紹介
  4. 4. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 本公演に関する SNS などの情報 • Togetter – https://togetter.com/li/1182047 • Source Code – https://github.com/chiroito/High-Performance-WebApplication • Connpass – https://connpass.com/event/72517/ • Hashtag – #oratdd 4
  5. 5. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 性能 可用性 5 今回注目するポイント
  6. 6. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 同じ仕事の性能が低いとコスト増加 可用性を上げるとコスト増加は顕著 6 なぜ性能と可用性が重要か 性能の低い システム 性能の高い システム コスト システム性能 要求するシステム性能 性能の低い システム 性能の高い システム コスト システム性能 要求するシステム性能
  7. 7. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | みなさんのアプリのレスポンスは速いですか? 7
  8. 8. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 8 目標値と実際
  9. 9. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | スループット レイテンシ 9 スケールアウト 効率性 性能でよく挙がる要素
  10. 10. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Single Point Of Failure Disaster Recovery 10 即時復旧 整合性 可用性でよく挙がる要素
  11. 11. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | よくあるWebアプリを見てみましょう 11
  12. 12. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Webアプリケーションのよくあるアーキテクチャ(概要) AP Server Data Store Web アプリケーションを実行層と データストア層に注目するため、 UIやLBといった層を今回は省略します 12
  13. 13. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | • Java EE Server • Microserviceの各種ランタイム • Function as a Service • Java コマンドで動くアプリケーション • RDBMS • NoSQL • Cache • Block Storage • Object Storage 13 具体的なイメージ AP Server Data Store
  14. 14. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 性能と可用性を意識したアーキテクチャの例 AP Server Data Store Data Store (Standby) ゾーン1 ゾーン2 AP Server リージョン 14
  15. 15. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | AP Server Data Store Data Store (Standby) ゾーン1 ゾーン2 AP Server リージョン 考えられる問題 障害で切替に 時間が掛かる APサーバが処理を 継続できない 何も起きてないが 突然滞留して 処理が遅延 何か遅いな… 止まってる? リージョン障害によって システムが停止 処理能力向上が困難 15
  16. 16. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | ログを収集 事象の確認 16 原因の調査 問題を修正 問題起きると大変ですよね?
  17. 17. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | とにかく速い 拡張できる 17 障害に強い 実装が簡単 こんなアーキテクチャ欲しくないですか?
  18. 18. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | ゾーン1 ゾーン2 リージョンB ゾーン1 リージョンA こんなアーキテクチャ欲しくないですか? AP Server Data StoreAP Server AP Server Data Store 接続先を意識しない。 障害時もアプリに通知 なく自立的に切替 足りなければ スケールアウト 別リージョンへ 冗長化 高性能なアーキテクチャを 簡単に実装できる 足りなければ スケールアウト Data Store 切替が速い 18
  19. 19. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 目次 1. 性能と可用性を意識したアーキテクチャ 2. 性能と可用性を意識したアーキテクチャ例でよくある問題 3. 更新の性能限界を実際に見てみましょう(デモ) 4. なにを気にしないといけないのか? 5. それってCacheを使えばできるんじゃない?(デモ) 6. In-place処理 & In-Memory Data Grid 7. 低レイテンシで高可用性なアーキテクチャ(デモ) 8. まとめ 19
  20. 20. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | demo について 20
  21. 21. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | デモの処理内容 • ECサイトの購入処理 • 画面ではユーザID、商品ID、注文数量を入力 • 処理内容: 1. ユーザIDを使用してユーザ情報を取得 2. 商品IDを使用して商品情報を取得 3. 注文処理を実行し注文情報を作成 4. 注文情報をデータストアへ反映 5. 商品の在庫情報をデータストアへ反映 21
  22. 22. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | テストケースA: • 限界となる性能を特定する • ユーザ数は0人から時間と共に増加 • 10,000件の商品 • スケールアウト/アップが効果ある – こちらは簡単 テストケースB: • 限界となる性能を特定する • ユーザ数は0人から時間と共に増加 • 1件の商品 • スケールアウト/アップが効かない – システムアーキテクチャが重要 22 デモの負荷について
  23. 23. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | デモのシーケンス JAX-RS ドメイン Product Dao UserDao Order Dao Data Store AP Server DataStore 商品情報 商品情報を取得(商品ID) ユーザ情報 ユーザ情報を取得(ユーザID) 注文情報 注文処理(商品情報, 注文数量) void 注文処理を保存(注文情報) void 商品情報を保存(商品情報) 23
  24. 24. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | デモのソースコード 24 https://github.com/chiroito/High-Performance-WebApplication/blob/master/web/src/main/java/system/rest/OrderSql.java#L48 https://github.com/chiroito/High-Performance-WebApplication/blob/master/web/src/main/java/system/rest/OrderCache.java#L38 https://github.com/chiroito/High-Performance-WebApplication/blob/master/gar/src/main/java/system/cache/delegate/OrderEntryProcessor.java#L47
  25. 25. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | デモアプリケーション • weblogic-jee-quickstart を使用して開発 – 以下の Maven プラグインを統合して Ear/Ejb/War を作るテンプレート • WebLogic Maven Plug-In • WebLogic Development Maven Plug-In – https://github.com/chiroito/weblogic-jee-quickstart • web-application Maven プロジェクトの内訳 – web-application-domain – web-application-web – web-application-gar – web-application-ear 25
  26. 26. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 26 デモの構成 AP Server負荷ツール Ear War domain Data Store 複数の Data Store を試しますが、 公平のため何もチューニングしません。
  27. 27. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 27 デモの構成(プロセスレベル) WebLogic Server (4vcpu, 4GB) WebLogic Server (4vcpu, 4GB) WebLogic Server (4vcpu, 4GB) WebLogic Server (4vcpu, 4GB) OSS DB (1vcpu, 4GB) Gatling (4vcpu, 16GB) Gatling (4vcpu, 16GB) Gatling (4vcpu, 16GB)
  28. 28. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 28 Oracle製品はdocker上でもサポートされます
  29. 29. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | (16vcpu, 24GB) 29 今回の環境(H/Wとコンテナの配置) (16vcpu, 24GB) Oracle WebLogic Server (4vcpu, 4GB) OSS DB (1vcpu, 4GB) Gatling (4vcpu, 16GB) Oracle WebLogic Server (4vcpu, 4GB) Oracle WebLogic Server (4vcpu, 4GB) Oracle WebLogic Server (4vcpu, 4GB) Gatling (4vcpu, 16GB) Gatling (4vcpu, 16GB) オンプレH/W
  30. 30. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 性能と可用性を意識したアーキテクチャ 30
  31. 31. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 性能と可用性を意識したアーキテクチャの例 AP Server Data Store Data Store (Standby) ゾーン1 ゾーン2 AP Server リージョン 31
  32. 32. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Read Replicaによるオフロード キャッシュによる高速化 32 シャーディング スケールアウト 性能を意識したアーキテクチャ例 AP Server Cache AP Server AP Server AP Server 処理によって 接続先を変える 処理によって 接続先を変える 同じデータストアを 複数並べる 取るデータ毎に DBを変える Data Store (A-N) Read Replica Read Replica Read Replica Data Store Data Store Data Store (O-Z)
  33. 33. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 別ゾーンへ複製して冗長化 横に並べて冗長化 33 可用性を意識したアーキテクチャ例 ゾーン1 ゾーン2 AP Server ゾーン1 ゾーン2 AP Server Standby Data Store Read Replica Read Replica
  34. 34. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | ゾーン1 ゾーン2 リージョンA AP Server Read Replica(O-Z) Data Store AP Server AP Server Read Replica Read Replica(A-N) Standby Read Replica AP Server AP Server Cache 性能と可用性を意識したアーキテクチャの具体例 足りなければ スケールアウト アプリAに性能影響がないように アプリB用のレプリカを作成 読み込みを オフロード 障害に備え 書込に専念 34
  35. 35. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 性能と可用性を意識したアーキテクチャ例で よくある問題 35
  36. 36. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | ゾーン1 ゾーン2 リージョンA AP Server Read Replica(O-Z) Data Store AP Server AP Server Read Replica Read Replica(A-N) Standby Read Replica AP Server AP Server Cache 性能と可用性を意識したアーキテクチャ例でよくある問題 APサーバ増加によるコ ネクション数の増加 更新の性能限界 更新の反映遅延 長い切替時間 SPOF 死んだコネクションを 取得する事による例外 リソースを使い切る リソースを使えない 区分の変更 データ不整合 リージョン障害でアクセス不能 36
  37. 37. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | ゾーン1 ゾーン2 リージョンA AP Server Read Replica(O-Z) Data Store AP Server AP Server Read Replica Read Replica(A-N) Standby Read Replica AP Server AP Server Cache 誤ったオペレーションによる問題が拡大されていくことがある APサーバ増加による コネクション数の増加 更新の性能限界 長い切替時間 死んだコネクションを 取得する事による例外 リソースを使えない ① ② ④ 切替 ⑦ 何か遅いな… エラーだ! ⓪ ⑧ SPOF ⑤ ⑥ スケールアウト ③ 37
  38. 38. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 性能 • 更新の性能限界 • リソースを使い切る • リソースを使えない • 区分の変更 可用性 • 長い切替時間 • データ不整合 • 更新の反映遅延 • ダメなコネクションを取得 38 問題を分類してみる
  39. 39. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | • リソースが足りてないケース –スレッドプールの枯渇 –オブジェクトプールの枯渇 • Stateless EJBなど –コネクションプールの枯渇 • Databaseコネクションなど • 一人しか処理出来ないケース –オブジェクトロック • synchronized –行ロック • SELECT for UPDATE 39 リソースが使えないとは? 更新の性能限界に繋がる
  40. 40. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 更新の性能限界を実際に見てみましょう 40
  41. 41. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 41 Database を使用した構成 AP Server DB
  42. 42. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 42 SQL版 シーケンスの概要 JAX-RS DAO DB WebLogic Database ドメイン
  43. 43. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 43 SQL版 デモのシーケンス JAX-RS Product DAO DB WebLogic Database ドメイン User DAO Order DAO ロック期間
  44. 44. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 44 SQL版 ソースコード:JAX-RS https://github.com/chiroito/High-Performance-WebApplication/blob/master/web/src/main/java/system/rest/OrderSql.java
  45. 45. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 45 SQL版 ソースコード:ProductDAO https://github.com/chiroito/High-Performance-WebApplication/blob/master/web/src/main/java/system/sql/ProductDaoSql.java
  46. 46. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | SQL版テストケースA • 10,000点の「商品」に対して複数のユーザが同時に商品を買う • ユーザ数は 25 秒かけて 0 ~ 1,800 人に増加 46
  47. 47. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | SQL版テストケースA WebLogic Server コンテナのCPU使用率 47 あまりCPUを 使えてない
  48. 48. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | SQL版テストケースA DatabaseコンテナのCPU使用率 48 CPUが頭打ち
  49. 49. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 49 SQL版テストケースA スループットとレスポンス時間 今後のケースAの性能値はこの性能値を基準にします スループット レスポンス時間
  50. 50. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | SQL版テストケースB • 単一の「商品」に対して複数のユーザが同時に商品を買う • ユーザ数は 25 秒かけて 0 ~ 600 人に増加 50
  51. 51. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | SQL版テストケースB WebLogic Server コンテナのCPU使用率 51 CPUを使えてない
  52. 52. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | SQL版テストケースB DatabaseコンテナのCPU使用率 52 CPUを使えてない
  53. 53. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 53 SQL版テストケースB スループットとレスポンス時間 今後のケースBの性能値はこの性能値を基準にします スループット レスポンス時間
  54. 54. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | なにを気にしないといけないのか? 54
  55. 55. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 負荷 インフラ 55 アプリ なにを気にしないといけないのか?
  56. 56. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 負荷で気にすること • 負荷全体に言えること – 今の負荷は将来の負荷では無いことに注意 • システム全体の負荷 – 実際起こりえる混合の負荷 • 特別な状況での負荷 – キャンペーン時に単一商品への大量アクセス – など 56
  57. 57. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | スケールアップ – スケールアウト/イン • 特に更新系 – スケールアップ/ダウン – スレッド、コネクション • スケールアウトは注意 57 可用性 – データストアの可用性 – 障害時の復旧時間 インフラで気にすること Data Store AP Server Active AP Server Standby スケールアウト Data Store AP Server AP Server 性能
  58. 58. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | インフラの性能で気にすること • スケールとリソース – スケールアップしてリソースを増やす • リソース数を増やすのは限界があるので注意 (CPU数やメモリには上限ある) – スケールアウトしてリソースを増やす • 他のインスタンスのリソースを使い切ってしまう可能性があるので注意(コネクションなど) 58 Data Store AP Server 機能的にスケールアウトできない Data Store AP Server AP Server これ以上スケールアップできない 相手のリソースが 枯渇する
  59. 59. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | インフラの可用性で気にすること • アプリにインフラを極力意識させない – インフラの構成とアプリの設計を分離(疎結合) • 全ての層でSPOFを取り除く – 全ての役割のインスタンスを複数用意 – リージョンを跨いだ環境の構築 • 高可用性構成の切替時間を短くする – 自動で検知 – 自動で切り替え (必要に応じて) – 切替が短時間で完了 59 Active AP Server Standby AP Server アプリはどちらへ 接続するか意識しない 瞬時に切り替え Read Replica Read Replica
  60. 60. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 性能 • ロック – オブジェクトロック(AP側) – 行ロック・表ロック(データストア側) • スケールアウト – DataStoreがスケールアウトした際に アプリが持つ接続が再分散する 可用性 • スケールイン – データストアに障害が落ちた場合に、落ち たデータストアへのコネクションを全て破棄 し、業務ロジックへの影響を及ぼさない 60 アプリケーションで気にすること
  61. 61. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | ロック時間が長い • 処理を減らす • CPU を速くする • 無駄な時間を極力短くする • スケールでは対応できないので注意 スケールアウト • DataStoreがスケールアウトした際に アプリが持つ接続が再分散する 61 アプリケーションの性能で気にすること AP Server 瞬時に検知して分散する 新規に追加 Read Replica Read Replica
  62. 62. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | コラム:非同期はどうなの? 同期/非同期 • 非同期にすることで受付と処理を別で行なえるため、レイテンシは高速になる • ビジネス的に同期必須のものもある。 – ビジネス要件とのバランス 62 A B C A B C 同期 非同期
  63. 63. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | アプリケーションの可用性で気にすること • スケールイン – フレームワークで対応が必要 – データストアに障害が落ちた瞬間に落ちたことを検知する – 落ちたデータストアへのコネクションを全て破棄する – 業務ロジックへ極力影響を及ぼさないようにする – アプリがコネクションを使っている場合には 気付かれないように正常なコネクションへ交換する 63 AP Server 瞬時に検知して 切断・破棄する Read Replica Read Replica
  64. 64. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | ロックについて • ロックしないとどうなるか – 在庫数よりも多くの商品が売れてしまう – ホテルで部屋数以上の予約が入る • ロック開放待ち中のスレッドは何も処理しない • 秒間の最大処理可能件数=1秒/ロック時間 – ロック時間が短いほどたくさん処理出来る – つまり DataStore が低レイテンシだとシステム性能が上がる 64
  65. 65. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | それってCacheを使えばできるんじゃない? 65
  66. 66. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 66 Cacheを使用した構成 AP Server Cache CacheとしてOracle Coherenceを 使用します。詳細は後ろで紹介します。
  67. 67. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 67 Cache版 シーケンスの概要 JAX-RS DAO キャッシュ ドメイン Cache AP Server
  68. 68. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 68 Cache版 デモのシーケンス JAX-RS Product DAO Cache ドメイン User DAO Order DAO Cache AP Server ロック期間
  69. 69. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 69 Cache版 ソースコード:JAX-RS https://github.com/chiroito/High-Performance-WebApplication/blob/master/web/src/main/java/system/rest/OrderCache.java
  70. 70. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 70 Cache版 ソースコード:ProductDAO https://github.com/chiroito/High-Performance-WebApplication/blob/master/gar/src/main/java/system/cache/putget/ProductDaoCache.java
  71. 71. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Cache版テストケースA • 10,000点の「商品」に対して複数のユーザが同時に商品を買う • ユーザ数は 25 秒かけて 0 ~ 11,400 人に増加 71
  72. 72. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Cache版テストケースA WebLogic Server コンテナのCPU使用率 72 CPUが使えるようになった。 =処理が捌けるようになった
  73. 73. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Cache版テストケースA CoherenceコンテナのCPU使用率 73 SQLと変わらず CPUが頭打ち
  74. 74. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 74 Cache版テストケースA スループットとレスポンス時間 x 7.88スループット レスポンス時間
  75. 75. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Cache版テストケースB • 単一の「商品」に対して複数のユーザが同時に商品を買う • ユーザ数は 25 秒かけて 0 ~ 600 人に増加 75
  76. 76. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Cache版テストケースB WebLogic Server コンテナのCPU使用率 76 CPUを使えてない
  77. 77. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Cache版テストケースB CoherenceコンテナのCPU使用率 77 CPUを使えてない
  78. 78. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 78 Cache版テストケースB スループットとレスポンス時間 スループット レスポンス時間 x 1.05
  79. 79. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | テストケースBの性能が変わらない理由 • ロックしている対象は変わっている – SQL版はDBの行 – Cache版はCacheされているオブジェクト • ロジックが変わっていないため、処理時間は変わらない – 同じ場所で同じだけロックしているロジックは変わっていない。 79
  80. 80. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | ケースBを速くするにはどうしたら良いのか… 80
  81. 81. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | データを取るのが遅いから、 データのある場所で処理をしよう!! 81
  82. 82. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | これまでの処理 1. データを取得 2. 処理 3. 処理結果を更新 In-place処理 1. ロジックを委譲 2. 処理 82 これまでの処理とIn-place処理 ロジック AP Server CacheAP Server Cache ロジック AP Server Cache ロジック AP Server ロジック get put ロジック AP Server Cache
  83. 83. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 83 In-place版 シーケンスの概要 AP Server Dao Cache Entry Processor ドメインJAX-RS
  84. 84. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | In-place版 デモのシーケンス JAX-RS Product Dao User Dao Order Dao Entry Processor Cacheドメイン 84 AP Server ロック期間
  85. 85. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 85 ソースコード:In-place 処理 https://github.com/chiroito/High-Performance-WebApplication/blob/master/gar/src/main/java/system/cache/delegate/OrderEntryProcessor.java
  86. 86. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 86 In-place版 ソースコード:JAX-RS https://github.com/chiroito/High-Performance-WebApplication/blob/master/web/src/main/java/system/rest/OrderDelegate.java
  87. 87. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 87 In-place版 ソースコード:ProductDAO https://github.com/chiroito/High-Performance-WebApplication/blob/master/gar/src/main/java/system/cache/delegate/ProductDaoEp.java
  88. 88. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | インフラではどうしよう? 88
  89. 89. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | インフラとして望む要件 • 高速 • リソースをキチンと使い切る • スケールアウトできる • SPOFがなく自律的 • データストア内で整合性を取ってくれる • リージョンレベルで冗長化できる • アプリは上記を意識しないで良い 89
  90. 90. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | インフラとして望む要件(詳細) • ロック時間が短くて済む(性能) • 足した分だけスループットが増える(スケールアウト) • ブロック処理がない(リソースを使い切る) • ノードが落ちても気にしないで勝手に復旧する(SPOF) • データストア間での整合性を担保してくれる (整合性) • 念のためリージョンレベルで冗長化する (DR) • アプリはインターフェースを実装するだけで良い 90
  91. 91. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | とにかく速い 拡張できる 91 障害に強い 実装が簡単 こんなアーキテクチャ欲しくないですか?
  92. 92. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | ゾーン1 ゾーン2 リージョンB ゾーン1 リージョンA こんなアーキテクチャ欲しくないですか? AP Server Data StoreAP Server AP Server Data Store 接続先を意識しない。 障害時もアプリに通知 なく自立的に切替 足りなければ スケールアウト 別リージョンへ 冗長化 高性能なアーキテクチャを 簡単に実装できる 足りなければ スケールアウト Data Store 切替が速い 92
  93. 93. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 別リージョンのデータストア 93 こんなアーキテクチャは欲しくないですか? AP Server Data Store Cache Cache Cache 接続先を意識しない。 障害時もアプリに通知 なく自立的に切替 Cache 足りなければ 足せばいい 永続化先と整合できる Cache Data Store 別リージョンへ 冗長化してくれる Data Store 障害時は自立的に 可用性を保つ 高速に処理する アプリの実装が楽 ブロックが少ない AP Server APが増えても DataStoreに 影響が少ない
  94. 94. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | In-Memory Data Grid を使いましょう 94
  95. 95. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | In-Memory Data Grid 製品である Oracle Coherence の例 95
  96. 96. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Coherenceとは • Oracle 社の In-Memory Data Grid 製品 • 数々のミッションクリティカルなシステムで導入されている • 歴史: – 2001年 Tangosol 社が開発 – 2007年 Oracleが買収 – 現在 様々な Oracle 製品に統合 96
  97. 97. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 標準に準拠 処理が速い 97 高可用性 Coherenceの良いところ
  98. 98. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | JCache Lambda式 98 他言語 標準に準拠
  99. 99. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | In-Place 処理 CacheStore 99 分散 処理が速い put JVM A CacheStore A insert update ① 処理のInvoke ② キャッシュサーバの JVMでデータ処 理 ③ 結果をリターン JVM Logic JVM Logic JVM Logic 非同期 バッチ
  100. 100. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 冗長化 Eviction 100 Persistence 高可用性 Coherence Active Coherence X Coherence Active JVM キャッシュ アウト A アクセス頻度 高 アクセス頻度 低 C Federation Machine 1 JVM 1 P B 4 1 JVM 2 P B 5 Machine 2 JVM 3 P B 1 2 JVM 4 P B 3 4 Machine 3 JVM 5 P B 5 3 JVM 6 P B 2
  101. 101. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 101 デモの構成 WebLogic Server (4vcpu, 4GB) WebLogic Server (4vcpu, 4GB) WebLogic Server (4vcpu, 4GB) WebLogic Server (4vcpu, 4GB) Coherence (1vcpu, 4GB) Gatling (4vcpu, 16GB) Gatling (4vcpu, 16GB) Gatling (4vcpu, 16GB) OSS DB (1vcpu, 4GB)
  102. 102. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | (16vcpu, 24GB) 102 今回の環境 (16vcpu, 24GB) Oracle WebLogic Server (4vcpu, 4GB) OSS DB (1vcpu, 4GB) Gatling (4vcpu, 16GB) Oracle WebLogic Server (4vcpu, 4GB) Oracle WebLogic Server (4vcpu, 4GB) Oracle WebLogic Server (4vcpu, 4GB) Gatling (4vcpu, 16GB) Gatling (4vcpu, 16GB) Coherence (1vcpu, 4GB)
  103. 103. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | In-place版テストケースA • 10,000点の「商品」に対して複数のユーザが同時に商品を買う • ユーザ数は 25 秒かけて 0 ~ 16,500 人に増加 103
  104. 104. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | In-place版テストケースA WebLogic Server コンテナのCPU使用率 104 JAX-RSでの処理は減ったが Cacheと同じように使えてる
  105. 105. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | In-place版テストケースA CoherenceコンテナのCPU使用率 105 SQLから変わらず CPUが頭打ち
  106. 106. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 106 In-place版テストケースA スループットとレスポンス時間 x 13.64スループット レスポンス時間
  107. 107. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | In-place版テストケースB • 単一の「商品」に対して複数のユーザが同時に商品を買う • ユーザ数は 25 秒かけて 0 ~ 16,500 人に増加 107
  108. 108. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | In-place版テストケースB WebLogic Server コンテナのCPU使用率 108 CPUを使えた
  109. 109. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | In-place版テストケースB CoherenceコンテナのCPU使用率 109 CPUを使えた
  110. 110. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 110 In-place版テストケースB スループットとレスポンス時間 x 31.27スループット レスポンス時間
  111. 111. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | まとめ 111
  112. 112. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 112 最大スループット(テストケースA) OSS DB 1 x 7.88 Cache x 13.64 In-place
  113. 113. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 90%tile 10ms 99%tile 100ms 113 レイテンシ毎のスループット(テストケースA) x 1.50 Cache x 6.90 In-place DB 1 x 4.15 Cache x 9.34 In-placeDB 1
  114. 114. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 114 最大スループット(テストケースB) OSS DB 1 x 1.05 Cache x 31.27 In-place
  115. 115. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 90%tile 10ms 99%tile 100ms 115 レイテンシ毎のスループット(テストケースB) x 0.97 Cache x 18.49 In-place DB 1 x 0.85 Cache x 24.06 In-placeDB 1
  116. 116. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | まとめ • テストケースA – データストアは常にCPUを使えていたが処理効率の違いからスループットに違いがある – APサーバはデータストアのレイテンシが短いとたくさん処理でき、CPUをたくさん使う • テストケースB – SQL版もCache版もロック時間が長いため処理ができない。 • ロック中はCPUが関する処理は少なく、時間の多くはネットワーク通信 – In-place 版はロック時間に通信を含まないためCPU時間だけのロックで済む。 116
  117. 117. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | まとめ • In-place 処理で低レイテンシが実現できる – インターフェースを実装するだけ – ドメイン処理をコピーして DAO の実装を変える • In-Memory Data Grid は性能・可用性でメリットがいっぱいある – 高可用性(ゾーンレベル、リージョンレベル) – 必要な CPU 数の削減(=コストの削減) 117

×