<Insert Picture Here>
クラウド世代のWebアプリケーション設計
インメモリ分散技術による変革とは?
-日本オラクル株式会社
Fusion Middleware 事業統括本部
Copyright Oracle Corporation Japan, 2010. All rights reserved.
分散キャッシュ
?
キーバリュー・ストア
? KVS?
Copyright Oracle Corporation Japan, 2010. All rights reserved.
4
クラウド的発想で行こう
!
•
データ量を気にしない
•
メモリ制限を気にしない
•
システム規模を気にしない
•
同時ユーザー数を気にしない
•
ハードウェア障害を気にしない
「
ITリソースを気にしない」
アプリ開発者・アプリ利用者の
利便性向上のためのクラウド
Shared Infrastructure
App3
Server
App2
Server
App1
Server
JVM
JVM
JVM
OS
OS
OS
現行のサーバー仮想化
Silo’d Virtual Infrastructure
Virtualization
App3
Server
App2
Server
App1
Server
JVM
JVM
JVM
OS
OS
OS
Virtualization
Virtualization
Virtualization
Copyright Oracle Corporation Japan, 2010. All rights reserved.
6
インメモリ分散技術
インメモリ・データグリッドでできること
「隣のサーバーのメモリと
CPUを活用する」
それによって
…
•
廉価なサーバーをつなげて高性能な処理を実現できる
•
遊休資産を活用できる（
IT資産を最適化できる）
•
テラバイト級の大規模メモリ空間を構築できる
Copyright Oracle Corporation Japan, 2010. All rights reserved.
8
Application
Server
アプリケーション・グリッドの中核技術
インメモリ・データグリッドがもたらすもの
アプリ
ケーション
JVM JVM JVM JVM
データグリッド層
大容量かつ拡張可能な
インメモリ・データ保持領域
• データアクセスを実施
• メモリデータを高い
信頼性で保持可能
▶
アプリ処理対象メモリデータ
を外部プロセスへ“逃がす
”
↓
アプリケーション本来の
処理用のリソースを確保
• より多くのリクエストを
処理可能
• GCの影響を極小化
→ より安定した応答
▶
アプリ
App
Process
処理の引継ぎ• Appサーバー障害の
影響を極小化
• Appサーバーの追加
を容易に実現
▶
Appサーバー層から
独立した層でデータを
インメモリ保持
共通データ処理をデータ
グリッド側で並列実行
• 処理のパラレル化
→ 高速化
• Appサーバー処理の
軽量化 → 高速化
▶
JVM
Application
Server
アプリケーション・グリッドの中核技術
インメモリ・データグリッドがもたらすもの
アプリ
ケーション
JVM JVM JVM JVM
データグリッド層
大容量かつ拡張可能な
インメモリ・データ保持領域
• データアクセスを実施
• メモリデータを高い
信頼性で保持可能
▶
アプリ処理対象メモリデータ
を外部プロセスへ“逃がす
”
↓
アプリケーション本来の
処理用のリソースを確保
• より多くのリクエストを
処理可能
• GCの影響を極小化
→ より安定した応答
▶
アプリ
App
Process
処理の引継ぎ• Appサーバー障害の
影響を極小化
• Appサーバーの追加
を容易に実現
▶
Appサーバー層から
独立した層でデータを
インメモリ保持
共通データ処理をデータ
グリッド側で並列実行
• 処理のパラレル化
→ 高速化
• Appサーバー処理の
軽量化 → 高速化
▶
耐障害性・可用性
オンデマンドな拡張性
高スループット
+安定性
アプリケーション容量の改善
高速性
パフォーマンス
JVM
Copyright Oracle Corporation Japan, 2010. All rights reserved.
10
サーバーの動的な再構成 + 耐障害性
①
Demonstration
データグリッド・サーバーの動的な増減
•
シナリオ
–
株取引アプリケーション
–
アプリケーション稼動中
① 取引量の増加に対応するため
メモリ処理可能な上限を
拡大したいが、どうするか
?
② 処理途中に
Coherence
サーバーがひとつダウン
した
場合、アプリケーションの処理
にどう影響が出るか
?
②
Copyright Oracle Corporation Japan, 2010. All rights reserved.
12
データグリッドによって
Webアプリに対するデータグリッド適用のレベル
Java EE/ISV
アプリ
Application
Server
JVM
JVM JVM JVM
データグリッド層
•
セッション
/ステート・データの
格納領域としての利用
従来手法では
…
–
httpsession.getAttribute(…);
httpsession.setAttribute(…);
–
または、カスタム・コードによって
ステート管理を実装
•
共通データアクセス処理としての適用
従来手法では
…
–
O/Rマッピング
Hibernate、TopLink JPA
–
その他のデータアクセス
フレームワークの利用
–
JDBCによる個別コーディング
…
特性
- 対象 : 単一データ
- データの信頼性が課題
- Appサーバーの
メモリ領域を圧迫しない
管理手法が必要
特性
- 対象 : 複数行データ
- DBに依存した処理
+ ネットワーク転送
+ O/R変換コスト
- 他セッションでも同様の
リクエストが発生する
可能性あり
Copyright Oracle Corporation Japan, 2010. All rights reserved.
14
変わる常識・考え方
•
セッション
/ステート管理に対する考え方
•
データアクセスの方法・考え方
•
GC に対する考え方
•
耐障害性に対する考え方
•
サイジング・システム増強時
セッション
/ステート管理に対する考え方
•
これまでの手法・常識
–
HTTPセッションであまり大きな
オブジェクトを保持すべきではない
–
セッション
/ステートの信頼性の
ためには、
DB に書き込む
（
DB負荷の増加、O/R変換コスト）
–
ステートレスなアプリでなければ
スケールしない
•
with インメモリ・データグリッド
データの大きさにかかわらず、
HTTPセッションでステート管理可能
信頼性はデータグリッドで確保
効果
–
セッション・データの取り扱いを統一
–
アプリはステートレスのようにスケール
–
DB負荷を増大させない
or
Copyright Oracle Corporation Japan, 2010. All rights reserved.
16
セッション
/ステート管理
従来型の限界に縛られない処理性能
スループット比較(テストケース2) 0 500 1000 1500 2000 2500 3000 同時仮想端末数 ス ルー プ ットWLS+COH 同一筐体 WLS+COH 別ノード配置 WLS Cluster theoretical max.
■
スループット
セッションサイズ 10K
総メモリ量 3G 制限での
検証テスト結果
従来型 クラスタ構成
1G
WebLogic
1G
1G
1G
512M1G
WebLogic
512M CoherenceCoherence*Web構成
同時
ユーザー数
繰り返し
実行数
処理時間
（秒）
コメント
通常のセッション管理
20
10
0.741
Coherence*Web (front)
20
10
0.702
Coherence*Web (near)
20
10
0.741
通常のセッション管理
100
20
測定不能（OutOfMemory）
Coherence*Web (front)
100
20
2.186
Coherence*Web (near)
100
20
1.961
海外顧客の
事前テスト結果
セッション
/ステート管理
統合セッション管理層としての
Coherenceの適用
WebLogic Server
WebSphere
JBoss
Tomcat …
Oracle WebLogic 9.x、10.x、11g
Oracle OC4J 10.1.2、10.1.3
IBM WebSphere 5.x、6.x、7
Sun GlassFish 2.x
Tomcat 5.5、6.0
JBoss
Resin 3.1
Jetty 5.1、6.1
ASP.NET
（
2.0 以上）
Java EE 標準API
VB or C#
CoherenceSessionProvider for .NET Web.config で設定Coherence*Web
インストーラによって
Javaアプリに組み込み
Coherence : 高信頼性メモリ領域
httpsession.setAttribute(
"count"
, integer );
Session(
“count”
)=Counter.Text
Coherence API
ver. 3.6
Copyright Oracle Corporation Japan, 2010. All rights reserved.
18
身近なところで効果がでるかも
アイディア
•
Struts とともに使ってみる
•
JSF とともに使ってみる
期待される効果
•
信頼性の向上
•
メモリ利用効率の向上
•
同時ユーザー数向上
•
このケースでの効果は
“速さ”ではない
アイディア
•
.NET アプリケーション
–
特に、
SQL Server で
セッション管理をやっている場合
はすぐにやってみるべし
!
期待される効果
•
SQL Server 不要
（速さ
+ コスト）
•
ディスクストレージの節約
変わる常識・考え方
•
セッション
/ステート管理に対する考え方
•
データアクセスの方法・考え方
•
GC に対する考え方
•
耐障害性に対する考え方
•
サイジング・システム増強時
Copyright Oracle Corporation Japan, 2010. All rights reserved.
20
データアクセスの方法・考え方
•
これまでの手法
•
with インメモリ・データグリッド
アプリケーション
B
アプリケーション
A
アプリケーション
B
アプリケーション
A
ア
プ
リ
ケ
ー
シ
ョ
ン
層
デ
ー
タ
ソ
ー
ス
層
画面系 処理 フロー 処理 画面系 処理 フロー 処理 画面系 処理 フロー 処理 画面系 処理 フロー 処理 画面系 処理 フロー 処理 デ ー タ グリ ッド層 アプリに特化した データ処理 アプリに特化した データ処理 共通データ処理 Ap p サ ー バ ー 層 画面系 処理 フロー 処理 画面系 処理 フロー 処理 画面系 処理 フロー 処理 画面系 処理 フロー 処理 画面系 処理 フロー 処理その他のデータソース
（ホスト、Webサービス …）
企業内
統合マスターDB
データ 処理 データ 処理 データ 処理 データ 処理 データ 処理 データ アクセス 処理 データ アクセス 処理データアクセス
データグリッド適用の場合に意識すべきポイント
•
with インメモリ・データグリッド
アプリケーション
B
アプリケーション
A
デ ー タ グリ ッド層 アプリに特化した データ処理 アプリに特化した データ処理 共通データ処理 Ap p サ ー バ ー 層 画面系 処理 フロー 処理 画面系 処理 フロー 処理 画面系 処理 フロー 処理 画面系 処理 フロー 処理 画面系 処理 フロー 処理その他のデータソース
（ホスト、Webサービス …）
企業内
統合マスターDB
データ アクセス 処理 データ アクセス 処理•
結果の再利用処理を検討すべき
–
データアクセスのチューニングより
効果的なこともある
•
オブジェクト化コストを意識すべき
–
アプリ側で処理するデータ量が多い
（オブジェクト数が多い）場合は
「問合せ
→オブジェクト化」よりも
「オブジェクト集合
→データ絞込み」
のほうが効率的
•
データソースへのアクセスは
Coherence に委譲することも可能
–
この場合、アクセスエラーでは
Coherence でリトライしてくれる
Copyright Oracle Corporation Japan, 2010. All rights reserved.
22
データアクセス
典型的な適用パターン
アプリケーション
アプリケーション
画面系 処理 フロー 処理 画面系 処理 フロー 処理 画面系 処理 フロー 処理 画面系 処理 フロー 処理 データ 処理 データ アクセス 処理アプリケーション
画面系 処理 フロー 処理 画面系 処理 フロー 処理 画面系 処理 フロー 処理 データ アクセス 処理TopLink JPA
Hibernate
■
データ処理層としてフル活用
- DAOの再設計
- データグリッド機能をもっとも
効果的に利用
■
既存データ処理の活用
- 処理された結果の共有に
よって、後続のデータ処理
リクエストを高速・効率化
■
データグリッド連携機能の利用
- Coherence の連携が可能な
フレームワーク機能の背後で
透過的に利用
Oracle Coherence
3.6
Coherence Query Language
アプリケーション
画面・ フロー 画面・ フロー 画面・ フローDB
アクセス処理
Access API
Class
Product {
private int id;
private
String name;
private int price;
private
String detail;
private
String pictureUrl;
...
public
String getName();
...
}
SQLのwhere句に類似の表現によって
条件を設定して処理を分散実行可能
（パラレル問合せ、集計、データ変換
etc）
コマンドラインツールからクエリを実行
例：
- select name from products
where price between 2000 and 10000
- select avg(price) from products
where name like ‘%リンゴ%’
CohQL>
Copyright Oracle Corporation Japan, 2010. All rights reserved.
複数サーバーのリソースを統合利用
J.Crew オンラインストア
AppServer ServerApp ServerApp ServerApp
ピーク時期の処理のためにノード数を伸縮
24
実際の顧客例
関連サイトのセッション共有化による利便性向上
セッション管理
+ データ処理
北米 流通小売企業
ヨーロッパ カジノサイト
AppServer ServerApp ServerApp
ファミリー向け
高級ブランド
廉価ブランド
変わる常識・考え方
•
セッション
/ステート管理に対する考え方
•
データアクセスの方法・考え方
•
GC に対する考え方
•
耐障害性に対する考え方
•
サイジング・システム増強時
Copyright Oracle Corporation Japan, 2010. All rights reserved.
26
GC/メモリに対する考え方
•
これまでの手法・常識
–
メモリに載り切れない
データをファイル書き出し
–
大きなヒープを確保
or
Javaアプリ Javaアプリ Javaアプリ•
with インメモリ・データグリッド
複数
JVM による仮想共有メモリ領域を構成
効果
–
一つ一つの
JVMヒープは大きくしなくても良い
→
GCの影響が小さいままで
大規模メモリ環境を実現
ディスクIO →性能を犠牲に 大きなヒープ領域 →大規模GCを誘発常識を覆す
3つのさらなる革新
Javaアプリ レ ス ポ ンス タ イム （ms ） 100 150 200 250 300 100 150 200 250 300不測のGC処理
→処理の滞留、タイムアウト…
無駄な障害の回避
機会損失の防止
“ヒープ外” のメモリ領域を活用する
（
Oracle Coherence）
Full GC を制御する
（
Oracle JRockit Real Time）
ヒープサイズを稼動中に変更する
（
Oracle JRockit）
1
2
3
3
1
2
•
Java NIO 機能を利用した “ヒープ外” の
メモリ領域でのデータ管理
→
GC の影響を受けずに大きなメモリ領域を
利用可能。特に
64bit 環境で有効。
•
JVMのリアルタイム状況を可視化
•
さまざまなJVMパラメータを動的に変更可能
ヒープサイズだって増減可能
Copyright Oracle Corporation Japan, 2010. All rights reserved.
28
耐障害性に対する考え方
•
これまでの手法・常識
–
冗長化構成を別途設計
→ 待機系部分からくるコスト増
HW/SWコスト
設計・構築コスト
テスト工数
–
待機系の正常系テスト
–
障害テスト
–
障害時の運用手順の準備が必要
•
with インメモリ・データグリッド
遊休リソースのないフル・アクティブ構成
耐障害性・フェールオーバー処理は
データグリッドに委譲
効果
–
アプリケーション開発者は
処理ロジックと性能向上に集中
–
障害時処理の多くが自動化
–
どのサーバーが
“落ちてもよい前提” の
アプリケーションになる
and/or
サイジング・システム増強時
•
with インメモリ・データグリッド
厳密な見積もりは不要
: ざっくりと見積もって、後からノード数で調整
スモールスタート時は
Appサーバーと同一筐体でデータグリッドを起動
→ 規模の拡大に応じて、物理的に独立したデータグリッド層を構築可能
効果
–
HWリソースの有効活用が可能（特にメモリ）
–
アプリケーション・コードは変更不要
: 構成変更はデータグリッドが吸収
–
オンライン状態でもシステム増強可能
Coherence
インスタンス
物理的に独立化
データグリッドを
Copyright Oracle Corporation Japan, 2010. All rights reserved.
30
国内のお客様の取り組み（抜粋）
国内オンラインショップ
ECサイトの中核として採用
ヨドバシカメラ様
画面を構成するオブジェクトを高速収集
国内ゲーム企業
ユーザープロファイル管理基盤
国内製造業
BOMデータの逆展開システム
国内公共
月次のデータ集計処理の高速化
国内大手オンラインストア
カートの高信頼性メモリ保持として
ヒロセ通商様 LION FX
スケーラブルなFX注文処理基盤
国内大手証券
自己売買取引システム
国内証券
証券トレーディング・システム
国内金融機関
（構築中）
アルゴリズム取引基盤
国内小売流通業
在庫状況に基づく配送の最適化計算
楽天証券様
フル板情報配信セッション管理基盤
• コンテンツ管理システム
のデータソースから
サイトに必要なデータを
高速収集する機能を実現
- 透過的にDBとも連携
• 性能と共に可用性を両立
（オープンソースの
キャッシュでは実現不可）
• アクセス数が増えても
DBの負荷に直結しない
• パフォーマンス
約10倍
の速度向上
• 省リソース:
従来の
半分
程度での実現
• 短期実装（
3ヶ月弱
）
ECサイトのユーザビリティ改善
ヨドバシカメラ様 （
www.yodobashi.com
）
ビジネス側のニーズ
• ユーザー・レスポンス改善
• リアルタイムに情報を提供したい
• 1ページでより多くの情報を提供したい
システム側のニーズ
• 高速化のためにキャッシュ機能は必須
→ 膨大なコンテンツを格納できる大容量を実現したい
• リクエスト数の増加に依存しない安定したレスポンス性能
• 障害時の復旧コストを下げたい
ECサイトのレスポンス劣化 → データグリッドによるレスポンス改善プロジェクト
プロジェクトの背景と目的
オラクル選定理由
オラクル導入範囲
• キャッシュ内に存在しないデータを
データベースから透過的に取得
• ノード追加により、バッファ量を拡張可
能⇒将来の商品増加に対応可能
• 最低限の通信回数で多種・大量の
データを取得し、画面を構築
• 障害時にもインメモリ上のデータは
自動復旧
- データロストしない
- アプリ側でエラー制御不要
コンテンツ管理システム
Copyright Oracle Corporation Japan, 2010. All rights reserved.
32
まとめ
: アプリケーション・グリッドによる効果
アプリケーション
B
アプリケーション
A
デ ー タ グリ ッド層 Ap p サ ー バ ー 層 画面系 処理 フロー 処理 画面系 処理 フロー 処理 画面系 処理 フロー 処理 画面系 処理 フロー 処理 画面系 処理 フロー 処理その他のデータソース
（ホスト、
Webサービス …）
企業内
統合マスターDB
■
アプリケーション・グリッド・アーキテクチャ
処理結果の共有
【効果】
レスポンス性能、処理効率（
CPU使用効率）
データソース依存度の軽減
セッション・データのオフロード
【効果】
同時ユーザー数向上、メモリ利用効率改善
突発的な高負荷への対応
データベース保守からの独立
【効果】
- 保守作業の改善、機会損失の防止
データソース性能からアプリケーションを解放
【効果】
- 安定したサービスレベルの維持
処理対象データのインメモリ保持
スペシャル・サイトのご案内
■
アプリケーション・グリッド
/ Coherence
http://www.oracle.co.jp/appgrid/
■
CIO for Tomorrow
http://www.oracle.co.jp/campaign/cio/
■
Oracle WebLogic Server マニアックス
http://www.oracle.co.jp/weblogic/
- 業種や課題別の解決策のご紹介
- 効果をわかりやすくアニメーションで紹介
- 事例動画（字幕付き）
- その他、関連ライブラリ
【連載コラム】
- CIOのミッション
- アナリストの提言
【ソリューション】 他
【3つの迷信】
【伝説のエキス
パートが語る】
【ライブラリ】 他
Copyright Oracle Corporation Japan, 2010. All rights reserved.
JRockit VE
OS
WebLogic VE: OS不要の効率的なソフトウェアスタック
標準ゲストOSとJVM
WebLogic Virtualization Option
JVM
WebLogic Server
WebLogic Server or
Other Java App Server
ファイル ネットワーク
