More Related Content Similar to Webアプリに低レイテンシ・高可用性を求めるのは間違っているのだろうか
Similar to Webアプリに低レイテンシ・高可用性を求めるのは間違っているのだろうか (20) More from Chihiro Ito (13) Webアプリに低レイテンシ・高可用性を求めるのは間違っているのだろうか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. 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. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 3
• Technologist
• お客様のビジネス課題を技術で
解決する仕事をしています。
• 以前はミッションクリティカルなシステム
のアーキテクチャを検討~実装の支援
やトラブルシューティングをしてました。
• 専門技術は Java SE、データグリッド、
分散・並列・Stream処理。
• 趣味でOpenJDK Author
自己紹介
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. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
性能 可用性
5
今回注目するポイント
6. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
同じ仕事の性能が低いとコスト増加 可用性を上げるとコスト増加は顕著
6
なぜ性能と可用性が重要か
性能の低い
システム
性能の高い
システム
コスト
システム性能
要求するシステム性能
性能の低い
システム
性能の高い
システム
コスト
システム性能
要求するシステム性能
7. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
みなさんのアプリのレスポンスは速いですか?
7
9. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
スループット レイテンシ
9
スケールアウト 効率性
性能でよく挙がる要素
10. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
Single Point
Of Failure
Disaster
Recovery
10
即時復旧 整合性
可用性でよく挙がる要素
11. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
よくあるWebアプリを見てみましょう
11
12. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
Webアプリケーションのよくあるアーキテクチャ(概要)
AP
Server
Data
Store
Web
アプリケーションを実行層と
データストア層に注目するため、
UIやLBといった層を今回は省略します
12
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. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
性能と可用性を意識したアーキテクチャの例
AP Server Data Store
Data Store
(Standby)
ゾーン1
ゾーン2
AP Server
リージョン
14
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. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
ログを収集 事象の確認
16
原因の調査 問題を修正
問題起きると大変ですよね?
17. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
とにかく速い 拡張できる
17
障害に強い 実装が簡単
こんなアーキテクチャ欲しくないですか?
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. 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. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
demo について
20
21. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
デモの処理内容
• ECサイトの購入処理
• 画面ではユーザID、商品ID、注文数量を入力
• 処理内容:
1. ユーザIDを使用してユーザ情報を取得
2. 商品IDを使用して商品情報を取得
3. 注文処理を実行し注文情報を作成
4. 注文情報をデータストアへ反映
5. 商品の在庫情報をデータストアへ反映
21
22. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
テストケースA:
• 限界となる性能を特定する
• ユーザ数は0人から時間と共に増加
• 10,000件の商品
• スケールアウト/アップが効果ある
– こちらは簡単
テストケースB:
• 限界となる性能を特定する
• ユーザ数は0人から時間と共に増加
• 1件の商品
• スケールアウト/アップが効かない
– システムアーキテクチャが重要
22
デモの負荷について
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. 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. 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. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 26
デモの構成
AP Server負荷ツール
Ear
War
domain
Data Store
複数の Data Store を試しますが、
公平のため何もチューニングしません。
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. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 28
Oracle製品はdocker上でもサポートされます
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. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
性能と可用性を意識したアーキテクチャ
30
31. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
性能と可用性を意識したアーキテクチャの例
AP Server Data Store
Data Store
(Standby)
ゾーン1
ゾーン2
AP Server
リージョン
31
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. 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. 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. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
性能と可用性を意識したアーキテクチャ例で
よくある問題
35
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. 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. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
性能
• 更新の性能限界
• リソースを使い切る
• リソースを使えない
• 区分の変更
可用性
• 長い切替時間
• データ不整合
• 更新の反映遅延
• ダメなコネクションを取得
38
問題を分類してみる
39. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
• リソースが足りてないケース
–スレッドプールの枯渇
–オブジェクトプールの枯渇
• Stateless EJBなど
–コネクションプールの枯渇
• Databaseコネクションなど
• 一人しか処理出来ないケース
–オブジェクトロック
• synchronized
–行ロック
• SELECT for UPDATE
39
リソースが使えないとは?
更新の性能限界に繋がる
40. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
更新の性能限界を実際に見てみましょう
40
41. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 41
Database を使用した構成
AP
Server DB
42. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 42
SQL版
シーケンスの概要
JAX-RS DAO DB
WebLogic Database
ドメイン
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. 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. 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. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
SQL版テストケースA
• 10,000点の「商品」に対して複数のユーザが同時に商品を買う
• ユーザ数は 25 秒かけて 0 ~ 1,800 人に増加
46
47. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
SQL版テストケースA
WebLogic Server コンテナのCPU使用率
47
あまりCPUを
使えてない
48. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
SQL版テストケースA
DatabaseコンテナのCPU使用率
48
CPUが頭打ち
49. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 49
SQL版テストケースA
スループットとレスポンス時間
今後のケースAの性能値はこの性能値を基準にします
スループット
レスポンス時間
50. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
SQL版テストケースB
• 単一の「商品」に対して複数のユーザが同時に商品を買う
• ユーザ数は 25 秒かけて 0 ~ 600 人に増加
50
51. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
SQL版テストケースB
WebLogic Server コンテナのCPU使用率
51
CPUを使えてない
52. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
SQL版テストケースB
DatabaseコンテナのCPU使用率
52
CPUを使えてない
53. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 53
SQL版テストケースB
スループットとレスポンス時間
今後のケースBの性能値はこの性能値を基準にします
スループット
レスポンス時間
54. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
なにを気にしないといけないのか?
54
55. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
負荷 インフラ
55
アプリ
なにを気にしないといけないのか?
56. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
負荷で気にすること
• 負荷全体に言えること
– 今の負荷は将来の負荷では無いことに注意
• システム全体の負荷
– 実際起こりえる混合の負荷
• 特別な状況での負荷
– キャンペーン時に単一商品への大量アクセス
– など
56
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. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
インフラの性能で気にすること
• スケールとリソース
– スケールアップしてリソースを増やす
• リソース数を増やすのは限界があるので注意 (CPU数やメモリには上限ある)
– スケールアウトしてリソースを増やす
• 他のインスタンスのリソースを使い切ってしまう可能性があるので注意(コネクションなど)
58
Data
Store
AP
Server
機能的にスケールアウトできない
Data
Store
AP
Server
AP
Server
これ以上スケールアップできない
相手のリソースが
枯渇する
59. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
インフラの可用性で気にすること
• アプリにインフラを極力意識させない
– インフラの構成とアプリの設計を分離(疎結合)
• 全ての層でSPOFを取り除く
– 全ての役割のインスタンスを複数用意
– リージョンを跨いだ環境の構築
• 高可用性構成の切替時間を短くする
– 自動で検知
– 自動で切り替え (必要に応じて)
– 切替が短時間で完了
59
Active
AP
Server
Standby
AP
Server
アプリはどちらへ
接続するか意識しない
瞬時に切り替え
Read
Replica
Read
Replica
60. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
性能
• ロック
– オブジェクトロック(AP側)
– 行ロック・表ロック(データストア側)
• スケールアウト
– DataStoreがスケールアウトした際に
アプリが持つ接続が再分散する
可用性
• スケールイン
– データストアに障害が落ちた場合に、落ち
たデータストアへのコネクションを全て破棄
し、業務ロジックへの影響を及ぼさない
60
アプリケーションで気にすること
61. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
ロック時間が長い
• 処理を減らす
• CPU を速くする
• 無駄な時間を極力短くする
• スケールでは対応できないので注意
スケールアウト
• DataStoreがスケールアウトした際に
アプリが持つ接続が再分散する
61
アプリケーションの性能で気にすること
AP
Server
瞬時に検知して分散する
新規に追加
Read
Replica
Read
Replica
62. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
コラム:非同期はどうなの?
同期/非同期
• 非同期にすることで受付と処理を別で行なえるため、レイテンシは高速になる
• ビジネス的に同期必須のものもある。
– ビジネス要件とのバランス
62
A B C A B C
同期 非同期
63. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
アプリケーションの可用性で気にすること
• スケールイン
– フレームワークで対応が必要
– データストアに障害が落ちた瞬間に落ちたことを検知する
– 落ちたデータストアへのコネクションを全て破棄する
– 業務ロジックへ極力影響を及ぼさないようにする
– アプリがコネクションを使っている場合には
気付かれないように正常なコネクションへ交換する
63
AP
Server
瞬時に検知して
切断・破棄する
Read
Replica
Read
Replica
64. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
ロックについて
• ロックしないとどうなるか
– 在庫数よりも多くの商品が売れてしまう
– ホテルで部屋数以上の予約が入る
• ロック開放待ち中のスレッドは何も処理しない
• 秒間の最大処理可能件数=1秒/ロック時間
– ロック時間が短いほどたくさん処理出来る
– つまり DataStore が低レイテンシだとシステム性能が上がる
64
65. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
それってCacheを使えばできるんじゃない?
65
66. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 66
Cacheを使用した構成
AP
Server
Cache
CacheとしてOracle Coherenceを
使用します。詳細は後ろで紹介します。
67. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 67
Cache版
シーケンスの概要
JAX-RS DAO
キャッシュ
ドメイン Cache
AP Server
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. 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. 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. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
Cache版テストケースA
• 10,000点の「商品」に対して複数のユーザが同時に商品を買う
• ユーザ数は 25 秒かけて 0 ~ 11,400 人に増加
71
72. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
Cache版テストケースA
WebLogic Server コンテナのCPU使用率
72
CPUが使えるようになった。
=処理が捌けるようになった
73. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
Cache版テストケースA
CoherenceコンテナのCPU使用率
73
SQLと変わらず
CPUが頭打ち
74. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 74
Cache版テストケースA
スループットとレスポンス時間
x 7.88スループット
レスポンス時間
75. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
Cache版テストケースB
• 単一の「商品」に対して複数のユーザが同時に商品を買う
• ユーザ数は 25 秒かけて 0 ~ 600 人に増加
75
76. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
Cache版テストケースB
WebLogic Server コンテナのCPU使用率
76
CPUを使えてない
77. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
Cache版テストケースB
CoherenceコンテナのCPU使用率
77
CPUを使えてない
78. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 78
Cache版テストケースB
スループットとレスポンス時間
スループット
レスポンス時間
x 1.05
79. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
テストケースBの性能が変わらない理由
• ロックしている対象は変わっている
– SQL版はDBの行
– Cache版はCacheされているオブジェクト
• ロジックが変わっていないため、処理時間は変わらない
– 同じ場所で同じだけロックしているロジックは変わっていない。
79
80. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
ケースBを速くするにはどうしたら良いのか…
80
81. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
データを取るのが遅いから、
データのある場所で処理をしよう!!
81
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. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 83
In-place版
シーケンスの概要
AP Server
Dao Cache
Entry
Processor
ドメインJAX-RS
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. 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. 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. 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. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
インフラではどうしよう?
88
89. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
インフラとして望む要件
• 高速
• リソースをキチンと使い切る
• スケールアウトできる
• SPOFがなく自律的
• データストア内で整合性を取ってくれる
• リージョンレベルで冗長化できる
• アプリは上記を意識しないで良い
89
90. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
インフラとして望む要件(詳細)
• ロック時間が短くて済む(性能)
• 足した分だけスループットが増える(スケールアウト)
• ブロック処理がない(リソースを使い切る)
• ノードが落ちても気にしないで勝手に復旧する(SPOF)
• データストア間での整合性を担保してくれる (整合性)
• 念のためリージョンレベルで冗長化する (DR)
• アプリはインターフェースを実装するだけで良い
90
91. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
とにかく速い 拡張できる
91
障害に強い 実装が簡単
こんなアーキテクチャ欲しくないですか?
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. 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. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
In-Memory Data Grid を使いましょう
94
95. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
In-Memory Data Grid 製品である
Oracle Coherence の例
95
96. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
Coherenceとは
• Oracle 社の In-Memory Data Grid 製品
• 数々のミッションクリティカルなシステムで導入されている
• 歴史:
– 2001年 Tangosol 社が開発
– 2007年 Oracleが買収
– 現在 様々な Oracle 製品に統合
96
97. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
標準に準拠 処理が速い
97
高可用性
Coherenceの良いところ
98. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
JCache Lambda式
98
他言語
標準に準拠
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. 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. 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. 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. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
In-place版テストケースA
• 10,000点の「商品」に対して複数のユーザが同時に商品を買う
• ユーザ数は 25 秒かけて 0 ~ 16,500 人に増加
103
104. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
In-place版テストケースA
WebLogic Server コンテナのCPU使用率
104
JAX-RSでの処理は減ったが
Cacheと同じように使えてる
105. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
In-place版テストケースA
CoherenceコンテナのCPU使用率
105
SQLから変わらず
CPUが頭打ち
106. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 106
In-place版テストケースA
スループットとレスポンス時間
x 13.64スループット
レスポンス時間
107. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
In-place版テストケースB
• 単一の「商品」に対して複数のユーザが同時に商品を買う
• ユーザ数は 25 秒かけて 0 ~ 16,500 人に増加
107
108. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
In-place版テストケースB
WebLogic Server コンテナのCPU使用率
108
CPUを使えた
109. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
In-place版テストケースB
CoherenceコンテナのCPU使用率
109
CPUを使えた
110. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 110
In-place版テストケースB
スループットとレスポンス時間
x 31.27スループット
レスポンス時間
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. 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. 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. 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. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
まとめ
• テストケースA
– データストアは常にCPUを使えていたが処理効率の違いからスループットに違いがある
– APサーバはデータストアのレイテンシが短いとたくさん処理でき、CPUをたくさん使う
• テストケースB
– SQL版もCache版もロック時間が長いため処理ができない。
• ロック中はCPUが関する処理は少なく、時間の多くはネットワーク通信
– In-place 版はロック時間に通信を含まないためCPU時間だけのロックで済む。
116
117. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
まとめ
• In-place 処理で低レイテンシが実現できる
– インターフェースを実装するだけ
– ドメイン処理をコピーして DAO の実装を変える
• In-Memory Data Grid は性能・可用性でメリットがいっぱいある
– 高可用性(ゾーンレベル、リージョンレベル)
– 必要な CPU 数の削減(=コストの削減)
117