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

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
Webアプリに低レイテンシ・高可用性を
求めるのは間違っているのだろうか
伊藤智博（Chihiro Ito)
@chiroito
日本オラクル株式会社
コンサルティングサービス事業統括
Tech Deep Dive #0
https://connpass.com/event/72517/

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

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 3
• Technologist
• お客様のビジネス課題を技術で
解決する仕事をしています。
• 以前はミッションクリティカルなシステム
のアーキテクチャを検討～実装の支援
やトラブルシューティングをしてました。
• 専門技術は Java SE、データグリッド、
分散・並列・Stream処理。
• 趣味でOpenJDK Author
自己紹介

本公演に関する 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
今回注目するポイント

同じ仕事の性能が低いとコスト増加可用性を上げるとコスト増加は顕著
6
なぜ性能と可用性が重要か
性能の低い
システム
性能の高い
システム
コスト
システム性能
要求するシステム性能
性能の低い
システム
性能の高い
システム
コスト
システム性能
要求するシステム性能

みなさんのアプリのレスポンスは速いですか？
7

目標値と実際

スループットレイテンシ
9
スケールアウト効率性
性能でよく挙がる要素

Single Point
Of Failure
Disaster
Recovery
10
即時復旧整合性
可用性でよく挙がる要素

よくあるWebアプリを見てみましょう
11

Webアプリケーションのよくあるアーキテクチャ（概要）
AP
Server
Data
Store
Web
アプリケーションを実行層と
データストア層に注目するため、
UIやLBといった層を今回は省略します
12

• Java EE Server
• Microserviceの各種ランタイム
• Function as a Service
• Java コマンドで動くアプリケーション
• RDBMS
• NoSQL
• Cache
• Block Storage
• Object Storage
13
具体的なイメージ
AP
Server
Data
Store

性能と可用性を意識したアーキテクチャの例
AP Server Data Store
Data Store
(Standby)
ゾーン1
ゾーン2
AP Server
リージョン
14

Data Store
(Standby)
ゾーン1
ゾーン2
AP Server
リージョン
考えられる問題
障害で切替に
時間が掛かる
APサーバが処理を
継続できない
何も起きてないが
突然滞留して
処理が遅延
何か遅いな…
止まってる？
リージョン障害によって
システムが停止
処理能力向上が困難
15

ログを収集事象の確認
16
原因の調査問題を修正
問題起きると大変ですよね？

とにかく速い拡張できる
17
障害に強い実装が簡単
こんなアーキテクチャ欲しくないですか？

ゾーン1
ゾーン2
リージョンB
ゾーン1
リージョンA
AP Server
Data StoreAP Server
接続先を意識しない。
障害時もアプリに通知
なく自立的に切替
足りなければ
スケールアウト
別リージョンへ
冗長化
高性能なアーキテクチャを
簡単に実装できる
足りなければ
Data Store
切替が速い
18

目次
1. 性能と可用性を意識したアーキテクチャ
2. 性能と可用性を意識したアーキテクチャ例でよくある問題
3. 更新の性能限界を実際に見てみましょう（デモ）
4. なにを気にしないといけないのか？
5. それってCacheを使えばできるんじゃない？（デモ）
6. In-place処理 & In-Memory Data Grid
7. 低レイテンシで高可用性なアーキテクチャ(デモ)
8. まとめ
19

demo について
20

デモの処理内容
• ECサイトの購入処理
• 画面ではユーザID、商品ID、注文数量を入力
• 処理内容：
1. ユーザIDを使用してユーザ情報を取得
2. 商品IDを使用して商品情報を取得
3. 注文処理を実行し注文情報を作成
4. 注文情報をデータストアへ反映
5. 商品の在庫情報をデータストアへ反映
21

テストケースA：
• 限界となる性能を特定する
• ユーザ数は0人から時間と共に増加
• 10,000件の商品
• スケールアウト/アップが効果ある
– こちらは簡単
テストケースB：
• 限界となる性能を特定する
• ユーザ数は0人から時間と共に増加
• 1件の商品
• スケールアウト/アップが効かない
– システムアーキテクチャが重要
22
デモの負荷について

デモのシーケンス
JAX-RS ドメイン
Product
Dao
UserDao
Order
Dao
Data
Store
AP Server DataStore
商品情報商品情報を取得(商品ID)
ユーザ情報ユーザ情報を取得(ユーザID)
注文情報注文処理(商品情報, 注文数量)
void 注文処理を保存(注文情報)
void 商品情報を保存(商品情報)
23

デモのソースコード
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

デモアプリケーション
• 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

デモの構成
AP Server負荷ツール
Ear
War
domain
Data Store
複数の Data Store を試しますが、
公平のため何もチューニングしません。

デモの構成（プロセスレベル）
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)

Oracle製品はdocker上でもサポートされます

(16vcpu, 24GB)
29
今回の環境（H/Wとコンテナの配置）
(16vcpu, 24GB)
Oracle WebLogic Server
(4vcpu, 4GB)
OSS DB
(1vcpu, 4GB)
Gatling
(4vcpu, 16GB)
(4vcpu, 4GB)
(4vcpu, 4GB)
(4vcpu, 4GB)
Gatling
(4vcpu, 16GB)
Gatling
(4vcpu, 16GB)
オンプレH/W

性能と可用性を意識したアーキテクチャ
30

性能と可用性を意識したアーキテクチャの例
Data Store
(Standby)
ゾーン1
ゾーン2
AP Server
リージョン
31

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
可用性を意識したアーキテクチャ例
ゾーン1
ゾーン2
AP
Server
ゾーン1
ゾーン2
AP
Server
Standby
Data
Store
Read
Replica
Read
Replica

ゾーン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

ゾーン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

ゾーン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
問題を分類してみる

• リソースが足りてないケース
–スレッドプールの枯渇
–オブジェクトプールの枯渇
• Stateless EJBなど
–コネクションプールの枯渇
• Databaseコネクションなど
• 一人しか処理出来ないケース
–オブジェクトロック
• synchronized
–行ロック
• SELECT for UPDATE
39
リソースが使えないとは？
更新の性能限界に繋がる

更新の性能限界を実際に見てみましょう
40

Database を使用した構成
AP
Server DB

SQL版
シーケンスの概要
JAX-RS DAO DB
WebLogic Database
ドメイン

SQL版
JAX-RS
Product
DAO DB
WebLogic Database
ドメイン
User
DAO
Order
DAO
ロック期間

SQL版
ソースコード：JAX-RS
https://github.com/chiroito/High-Performance-WebApplication/blob/master/web/src/main/java/system/rest/OrderSql.java

SQL版
ソースコード：ProductDAO
https://github.com/chiroito/High-Performance-WebApplication/blob/master/web/src/main/java/system/sql/ProductDaoSql.java

SQL版テストケースA
• 10,000点の「商品」に対して複数のユーザが同時に商品を買う
• ユーザ数は 25 秒かけて 0 ～ 1,800 人に増加
46

WebLogic Server コンテナのCPU使用率
47
あまりCPUを
使えてない

DatabaseコンテナのCPU使用率
48
CPUが頭打ち

スループットとレスポンス時間
今後のケースAの性能値はこの性能値を基準にします
スループット
レスポンス時間

SQL版テストケースB
• 単一の「商品」に対して複数のユーザが同時に商品を買う
• ユーザ数は 25 秒かけて 0 ～ 600 人に増加
50

51
CPUを使えてない

DatabaseコンテナのCPU使用率
52

今後のケースBの性能値はこの性能値を基準にします
スループット

なにを気にしないといけないのか？
54

負荷インフラ
55
アプリ
なにを気にしないといけないのか？

負荷で気にすること
• 負荷全体に言えること
– 今の負荷は将来の負荷では無いことに注意
• システム全体の負荷
– 実際起こりえる混合の負荷
• 特別な状況での負荷
– キャンペーン時に単一商品への大量アクセス
– など
56

スケールアップ
– スケールアウト/イン
• 特に更新系
– スケールアップ/ダウン
– スレッド、コネクション
• スケールアウトは注意
57
可用性
– データストアの可用性
– 障害時の復旧時間
インフラで気にすること
Data
Store
AP
Server
Active
AP
Server
Standby
Data
Store
AP
Server
AP
Server
性能

インフラの性能で気にすること
• スケールとリソース
– スケールアップしてリソースを増やす
• リソース数を増やすのは限界があるので注意 (CPU数やメモリには上限ある)
– スケールアウトしてリソースを増やす
• 他のインスタンスのリソースを使い切ってしまう可能性があるので注意（コネクションなど）
58
Data
Store
AP
Server
機能的にスケールアウトできない
Data
Store
AP
Server
AP
Server
これ以上スケールアップできない
相手のリソースが
枯渇する

インフラの可用性で気にすること
• アプリにインフラを極力意識させない
– インフラの構成とアプリの設計を分離（疎結合）
• 全ての層でSPOFを取り除く
– 全ての役割のインスタンスを複数用意
– リージョンを跨いだ環境の構築
• 高可用性構成の切替時間を短くする
– 自動で検知
– 自動で切り替え（必要に応じて）
– 切替が短時間で完了
59
Active
AP
Server
Standby
AP
Server
アプリはどちらへ
接続するか意識しない
瞬時に切り替え
Read
Replica
Read
Replica

性能
• ロック
– オブジェクトロック（AP側）
– 行ロック・表ロック（データストア側）
• スケールアウト
– DataStoreがスケールアウトした際に
アプリが持つ接続が再分散する
可用性
• スケールイン
– データストアに障害が落ちた場合に、落ち
たデータストアへのコネクションを全て破棄
し、業務ロジックへの影響を及ぼさない
60
アプリケーションで気にすること

ロック時間が長い
• 処理を減らす
• CPU を速くする
• 無駄な時間を極力短くする
• スケールでは対応できないので注意
• DataStoreがスケールアウトした際に
アプリが持つ接続が再分散する
61
アプリケーションの性能で気にすること
AP
Server
瞬時に検知して分散する
新規に追加
Read
Replica
Read
Replica

コラム：非同期はどうなの？
同期/非同期
• 非同期にすることで受付と処理を別で行なえるため、レイテンシは高速になる
• ビジネス的に同期必須のものもある。
– ビジネス要件とのバランス
62
A B C A B C
同期非同期

アプリケーションの可用性で気にすること
• スケールイン
– フレームワークで対応が必要
– データストアに障害が落ちた瞬間に落ちたことを検知する
– 落ちたデータストアへのコネクションを全て破棄する
– 業務ロジックへ極力影響を及ぼさないようにする
– アプリがコネクションを使っている場合には
気付かれないように正常なコネクションへ交換する
63
AP
Server
瞬時に検知して
切断・破棄する
Read
Replica
Read
Replica

ロックについて
• ロックしないとどうなるか
– 在庫数よりも多くの商品が売れてしまう
– ホテルで部屋数以上の予約が入る
• ロック開放待ち中のスレッドは何も処理しない
• 秒間の最大処理可能件数＝1秒/ロック時間
– ロック時間が短いほどたくさん処理出来る
– つまり DataStore が低レイテンシだとシステム性能が上がる
64

それってCacheを使えばできるんじゃない？
65

Cacheを使用した構成
AP
Server
Cache
CacheとしてOracle Coherenceを
使用します。詳細は後ろで紹介します。

Cache版
JAX-RS DAO
キャッシュ
ドメイン Cache
AP Server

Cache版
JAX-RS
Product
DAO
Cache
ドメイン
User
DAO
Order
DAO
Cache
AP Server
ロック期間

Cache版
https://github.com/chiroito/High-Performance-WebApplication/blob/master/web/src/main/java/system/rest/OrderCache.java

Cache版
https://github.com/chiroito/High-Performance-WebApplication/blob/master/gar/src/main/java/system/cache/putget/ProductDaoCache.java

Cache版テストケースA
71

72
CPUが使えるようになった。
＝処理が捌けるようになった

CoherenceコンテナのCPU使用率
73
SQLと変わらず
CPUが頭打ち

x 7.88スループット

Cache版テストケースB
• ユーザ数は 25 秒かけて 0 ～ 600 人に増加
75

76

77

スループット
x 1.05

テストケースBの性能が変わらない理由
• ロックしている対象は変わっている
– SQL版はDBの行
– Cache版はCacheされているオブジェクト
• ロジックが変わっていないため、処理時間は変わらない
– 同じ場所で同じだけロックしているロジックは変わっていない。
79

ケースBを速くするにはどうしたら良いのか…
80

データを取るのが遅いから、
データのある場所で処理をしよう！！
81

これまでの処理
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

In-place版
AP Server
Dao Cache
Entry
Processor
ドメインJAX-RS

In-place版
JAX-RS
Product
Dao
User
Dao
Order
Dao
Entry
Processor
Cacheドメイン
84
AP Server
ロック期間

ソースコード：In-place 処理
https://github.com/chiroito/High-Performance-WebApplication/blob/master/gar/src/main/java/system/cache/delegate/OrderEntryProcessor.java

In-place版
https://github.com/chiroito/High-Performance-WebApplication/blob/master/web/src/main/java/system/rest/OrderDelegate.java

In-place版
https://github.com/chiroito/High-Performance-WebApplication/blob/master/gar/src/main/java/system/cache/delegate/ProductDaoEp.java

インフラではどうしよう？
88

インフラとして望む要件
• 高速
• リソースをキチンと使い切る
• スケールアウトできる
• SPOFがなく自律的
• データストア内で整合性を取ってくれる
• リージョンレベルで冗長化できる
• アプリは上記を意識しないで良い
89

インフラとして望む要件（詳細）
• ロック時間が短くて済む（性能）
• 足した分だけスループットが増える（スケールアウト）
• ブロック処理がない（リソースを使い切る）
• ノードが落ちても気にしないで勝手に復旧する（SPOF）
• データストア間での整合性を担保してくれる (整合性)
• 念のためリージョンレベルで冗長化する (DR)
• アプリはインターフェースを実装するだけで良い
90

とにかく速い拡張できる
91
障害に強い実装が簡単

ゾーン1
ゾーン2
リージョンB
ゾーン1
リージョンA
AP Server
Data StoreAP Server
足りなければ
冗長化
高性能なアーキテクチャを
簡単に実装できる
足りなければ
Data Store
切替が速い
92

別リージョンのデータストア
93
こんなアーキテクチャは欲しくないですか？
AP
Server Data
Store
Cache
Cache
Cache
Cache
足りなければ
足せばいい
永続化先と整合できる
Cache Data
Store
冗長化してくれる
Data
Store
障害時は自立的に
可用性を保つ
高速に処理する
アプリの実装が楽
ブロックが少ない
AP
Server APが増えても
DataStoreに
影響が少ない

In-Memory Data Grid を使いましょう
94

In-Memory Data Grid 製品である
Oracle Coherence の例
95

Coherenceとは
• Oracle 社の In-Memory Data Grid 製品
• 数々のミッションクリティカルなシステムで導入されている
• 歴史：
– 2001年 Tangosol 社が開発
– 2007年 Oracleが買収
– 現在様々な Oracle 製品に統合
96

標準に準拠処理が速い
97
高可用性
Coherenceの良いところ

JCache Lambda式
98
他言語
標準に準拠

In-Place 処理 CacheStore
99
分散
処理が速い
put
JVM
Ａ
CacheStore
A
insert
update
① 処理のInvoke
② キャッシュサーバの
JVMでデータ処
理
③ 結果をリターン
JVM
Logic
JVM
Logic
JVM
Logic
非同期
バッチ

冗長化 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

デモの構成
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)

(16vcpu, 24GB)
102
今回の環境
(16vcpu, 24GB)
(4vcpu, 4GB)
OSS DB (1vcpu, 4GB)
Gatling
(4vcpu, 16GB)
(4vcpu, 4GB)
(4vcpu, 4GB)
(4vcpu, 4GB)
Gatling
(4vcpu, 16GB)
Gatling
(4vcpu, 16GB)
Coherence (1vcpu, 4GB)

In-place版テストケースA
103

104
JAX-RSでの処理は減ったが
Cacheと同じように使えてる

105
SQLから変わらず
CPUが頭打ち

In-place版テストケースB
107

108
CPUを使えた

109
CPUを使えた

まとめ
111

最大スループット（テストケースA）
OSS DB
1
x 7.88
Cache
x 13.64
In-place

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

最大スループット（テストケースB）
OSS DB
1 x 1.05
Cache
x 31.27
In-place

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

まとめ
• テストケースA
– データストアは常にCPUを使えていたが処理効率の違いからスループットに違いがある
– APサーバはデータストアのレイテンシが短いとたくさん処理でき、CPUをたくさん使う
• テストケースB
– SQL版もCache版もロック時間が長いため処理ができない。
• ロック中はCPUが関する処理は少なく、時間の多くはネットワーク通信
– In-place 版はロック時間に通信を含まないためCPU時間だけのロックで済む。
116

まとめ
• In-place 処理で低レイテンシが実現できる
– インターフェースを実装するだけ
– ドメイン処理をコピーして DAO の実装を変える
• In-Memory Data Grid は性能・可用性でメリットがいっぱいある
– 高可用性（ゾーンレベル、リージョンレベル）
– 必要な CPU 数の削減（＝コストの削減）
117

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

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

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

More from Chihiro Ito

More from Chihiro Ito (13)

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