クラウド世代のWebアプリケーション設計　-...

<Insert Picture Here>

クラウド世代のWebアプリケーション設計- インメモリ分散技術による変革とは? -

日本オラクル株式会社

Fusion Middleware 事業統括本部

Copyright Oracle Corporation Japan, 2011. All rights reserved.

分散キャッシュ?

キーバリュー・ストア? KVS?

2


国内でも採用例、続々と

Copyright Oracle Corporation Japan, 2011. All rights reserved. 4

クラウド的発想で行こう !

•データ量を気にしない

• メモリ制限を気にしない

•システム規模を気にしない

•同時ユーザー数を気にしない

•ハードウェア障害を気にしない


「ITリソースを気にしない」

アプリ開発者・アプリ利用者の利便性向上のためのクラウド

Shared Infrastructure

App3

Server

App2

Server

App1

Server

JVM JVM JVM

OS OS OS

5

現行のサーバー仮想化

Silo’d Virtual Infrastructure

Virtualization

App3

Server

App2

Server

App1

Server

JVM JVM JVM

OS OS OS

Virtualization Virtualization Virtualization


インメモリ分散技術

インメモリ・データグリッド


インメモリ・データグリッドでできること

「隣のサーバーのメモリとCPUを活用する」

それによって…• 廉価なサーバーをつなげて高性能な処理を実現できる• 遊休資産を活用できる（IT資産を最適化できる）• テラバイト級の大規模メモリ空間を構築できる


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


サーバーの動的な再構成 + 耐障害性

D E M O N S T R A T I O N


①

Demonstration

データグリッド・サーバーの動的な増減

• シナリオ

– 株取引アプリケーション

– アプリケーション稼動中

①取引量の増加に対応するためメモリ処理可能な上限を拡大したいが、どうするか?

②処理途中に Coherence サーバーがひとつダウンした場合、アプリケーションの処理にどう影響が出るか?

②


データグリッドによって変わる開発スタイル


Webアプリに対するデータグリッド適用のレベル

Java EE/ISVアプリ

Application

Server

JVM JVM JVM JVM


• セッション/ステート・データの格納領域としての利用従来手法では…– httpsession.getAttribute(…);

httpsession.setAttribute(…);– または、カスタム・コードによってステート管理を実装

• 共通データアクセス処理としての適用従来手法では…– O/Rマッピング

Hibernate、TopLink JPA – その他のデータアクセスフレームワークの利用

– JDBCによる個別コーディング…

特性- 対象 : 単一データ- データの信頼性が課題- Appサーバーのメモリ領域を圧迫しない管理手法が必要

特性- 対象 : 複数行データ- DBに依存した処理

+ ネットワーク転送+ O/R変換コスト

- 他セッションでも同様のリクエストが発生する可能性あり


変わる常識・考え方

•セッション/ステート管理に対する考え方

•データアクセスの方法・考え方

• GC に対する考え方

•耐障害性に対する考え方

•サイジング・システム増強時


セッション/ステート管理に対する考え方

• これまでの手法・常識

– HTTPセッションであまり大きなオブジェクトを保持すべきではない

– セッション/ステートの信頼性のためには、DB に書き込む（DB負荷の増加、O/R変換コスト）

– ステートレスなアプリでなければスケールしない

• with インメモリ・データグリッド

データの大きさにかかわらず、HTTPセッションでステート管理可能

信頼性はデータグリッドで確保

効果

– セッション・データの取り扱いを統一

– アプリはステートレスのようにスケール

– DB負荷を増大させない

or


セッション/ステート管理

従来型の限界に縛られない処理性能スループット比較(テストケース2)

0 500 1000 1500 2000 2500 3000

同時仮想端末数

スル

ープ

ット

WLS+COH 同一筐体 WLS+COH 別ノード配置 WLS Cluster theoretical max.

■ スループットセッションサイズ 10K総メモリ量 3G 制限での

検証テスト結果

従来型クラスタ構成1G 1G

WebLogic1G

1G

512M

1GWebLogic

512M

Coherence

Coherence*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#

CoherenceSessionProviderfor .NET

Web.config で設定

Coherence*Web

インストーラによってJavaアプリに組み込み

Coherence : 高信頼性メモリ領域

httpsession.setAttribute( "count", integer ); Session( “count” )=Counter.Text

Coherence API

ver. 3.6強化ポイント


身近なところで効果がでるかも

アイディア

• Struts とともに使ってみる

• JSF とともに使ってみる

期待される効果

• 信頼性の向上

• メモリ利用効率の向上

• 同時ユーザー数向上

• このケースでの効果は“速さ”ではない

アイディア

• .NET アプリケーション

–特に、SQL Server でセッション管理をやっている場合はすぐにやってみるべし!

期待される効果

• SQL Server 不要（速さ + コスト）

• ディスクストレージの節約


データアクセスの方法・考え方

• これまでの手法 • with インメモリ・データグリッド

アプリケーション Bアプリケーション Aアプリケーション Bアプリケーション A

アプ

リケ

ーシ

ョン

層デ

ータ

ソー

ス層

画面系処理

フロー処理

画面系処理

フロー処理

画面系処理

フロー処理

画面系処理

フロー処理

画面系処理

フロー処理


アプリに特化したデータ処理


共通データ処理

Appサーバー層

画面系処理

フロー処理

画面系処理

フロー処理

画面系処理

フロー処理

画面系処理

フロー処理

画面系処理

フロー処理

その他のデータソース（ホスト、Webサービス …）

企業内統合マスターDB

データ処理

データ処理

データ処理

データ処理

データ処理

データアクセス

処理


処理



データグリッド適用の場合に意識すべきポイント


アプリケーション Bアプリケーション A




共通データ処理

Appサーバー層

画面系処理

フロー処理

画面系処理

フロー処理

画面系処理

フロー処理

画面系処理

フロー処理

画面系処理

フロー処理




処理


処理

• 結果の再利用処理を検討すべき

– データアクセスのチューニングより効果的なこともある

• オブジェクト化コストを意識すべき

– アプリ側で処理するデータ量が多い（オブジェクト数が多い）場合は「問合せ→オブジェクト化」よりも「オブジェクト集合→データ絞込み」のほうが効率的

• データソースへのアクセスはCoherence に委譲することも可能

– この場合、アクセスエラーではCoherence でリトライしてくれる



典型的な適用パターン

アプリケーションアプリケーション

画面系処理

フロー処理

画面系処理

フロー処理

画面系処理

フロー処理

画面系処理

フロー処理

データ処理


処理


画面系処理

フロー処理

画面系処理

フロー処理

画面系処理

フロー処理


処理

TopLink JPAHibernate

■ データ処理層としてフル活用- DAOの再設計- データグリッド機能をもっとも効果的に利用

■既存データ処理の活用- 処理された結果の共有によって、後続のデータ処理リクエストを高速・効率化

■ データグリッド連携機能の利用- Coherence の連携が可能なフレームワーク機能の背後で透過的に利用


Oracle Coherence 3.6Coherence Query Language

23


画面・フロー

画面・フロー

画面・フロー

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>

New!


複数サーバーのリソースを統合利用

J.Crew オンラインストア

AppServer

AppServer

AppServer

AppServer

ピーク時期の処理のためにノード数を伸縮

24

実際の顧客例

関連サイトのセッション共有化による利便性向上

セッション管理 + データ処理

北米流通小売企業

ヨーロッパカジノサイト

AppServer

AppServer

AppServer

ファミリー向け廉価ブランド高級ブランド

FedEx 貨物追跡


GC/メモリに対する考え方


–メモリに載り切れないデータをファイル書き出し

–大きなヒープを確保

or

Javaアプリ

Javaアプリ

Javaアプリ


複数JVM による仮想共有メモリ領域を構成

効果

– 一つ一つのJVMヒープは大きくしなくても良い→ GCの影響が小さいままで大規模メモリ環境を実現

ディスクIO→ 性能を犠牲に

大きなヒープ領域→ 大規模GCを誘発


常識を覆す3つのさらなる革新

Javaアプリ

レスポンスタイム（m

s）

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パラメータを動的に変更可能

ヒープサイズだって増減可能


耐障害性に対する考え方


– 冗長化構成を別途設計→ 待機系部分からくるコスト増

• HW/SWコスト

•設計・構築コスト

•テスト工数

–待機系の正常系テスト

–障害テスト

– 障害時の運用手順の準備が必要


遊休リソースのないフル・アクティブ構成

耐障害性・フェールオーバー処理はデータグリッドに委譲

効果

– アプリケーション開発者は処理ロジックと性能向上に集中

– 障害時処理の多くが自動化

– どのサーバーが “落ちてもよい前提” のアプリケーションになる

and/or


サイジング・システム増強時


厳密な見積もりは不要 : ざっくりと見積もって、後からノード数で調整

スモールスタート時はAppサーバーと同一筐体でデータグリッドを起動→規模の拡大に応じて、物理的に独立したデータグリッド層を構築可能

効果

– HWリソースの有効活用が可能（特にメモリ）

– アプリケーション・コードは変更不要 : 構成変更はデータグリッドが吸収

– オンライン状態でもシステム増強可能

Coherenceインスタンス

データグリッドを物理的に独立化


国内のお客様の取り組み（抜粋）

国内オンラインショップECサイトの中核として採用

ヨドバシカメラ様画面を構成するオブジェクトを高速収集

国内ゲーム企業ユーザープロファイル管理基盤

国内製造業BOMデータの逆展開システム

国内公共月次のデータ集計処理の高速化

国内大手オンラインストアカートの高信頼性メモリ保持として

ヒロセ通商様 LION FX

スケーラブルなFX注文処理基盤

国内大手証券自己売買取引システム

国内証券証券トレーディング・システム

国内金融機関（構築中）アルゴリズム取引基盤

国内小売流通業在庫状況に基づく配送の最適化計算

楽天証券様フル板情報配信セッション管理基盤


• コンテンツ管理システムのデータソースからサイトに必要なデータを高速収集する機能を実現- 透過的にDBとも連携

• 性能と共に可用性を両立（オープンソースのキャッシュでは実現不可）

• アクセス数が増えてもDBの負荷に直結しない

• パフォーマンス約10倍の速度向上

• 省リソース:従来の半分程度での実現

• 短期実装（3ヶ月弱）

ECサイトのユーザビリティ改善

ヨドバシカメラ様（www.yodobashi.com）

ビジネス側のニーズ•ユーザー・レスポンス改善•リアルタイムに情報を提供したい•1ページでより多くの情報を提供したい

システム側のニーズ

•高速化のためにキャッシュ機能は必須

→ 膨大なコンテンツを格納できる大容量を実現したい

•リクエスト数の増加に依存しない安定したレスポンス性能

•障害時の復旧コストを下げたい

ECサイトのレスポンス劣化 → データグリッドによるレスポンス改善プロジェクト

プロジェクトの背景と目的

オラクル選定理由オラクル導入範囲

• キャッシュ内に存在しないデータをデータベースから透過的に取得

• ノード追加により、バッファ量を拡張可能⇒将来の商品増加に対応可能

• 最低限の通信回数で多種・大量のデータを取得し、画面を構築

• 障害時にもインメモリ上のデータは自動復旧- データロストしない- アプリ側でエラー制御不要

コンテンツ管理システム

http://otndnld.oracle.co.jp/document/products/coherence/34/doc_cd/coh.340/B52976-01/integratespring.htm


まとめ : アプリケーション・グリッドによる効果

アプリケーション Bアプリケーション A


Appサーバー層

画面系処理

フロー処理

画面系処理

フロー処理

画面系処理

フロー処理

画面系処理

フロー処理

画面系処理

フロー処理



■ アプリケーション・グリッド・アーキテクチャ処理結果の共有

【効果】レスポンス性能、処理効率（CPU使用効率）データソース依存度の軽減

セッション・データのオフロード

【効果】同時ユーザー数向上、メモリ利用効率改善突発的な高負荷への対応

データベース保守からの独立

【効果】- 保守作業の改善、機会損失の防止

データソース性能からアプリケーションを解放

【効果】- 安定したサービスレベルの維持

処理対象データのインメモリ保持


スペシャル・サイトのご案内

■ アプリケーション・グリッド / Coherencehttp://www.oracle.co.jp/appgrid/

■ CIO for Tomorrowhttp://www.oracle.co.jp/campaign/cio/

■ Oracle WebLogic Server マニアックスhttp://www.oracle.co.jp/weblogic/

- 業種や課題別の解決策のご紹介

- 効果をわかりやすくアニメーションで紹介

- 事例動画（字幕付き）

- その他、関連ライブラリ

【連載コラム】- CIOのミッション- アナリストの提言

【ソリューション】他

【3つの迷信】

【伝説のエキスパートが語る】

【ライブラリ】他

http://www.oracle.co.jp/appgrid/

http://otndnld.oracle.co.jp/document/products/coherence/34/doc_cd/coh.340/B52976-01/integratespring.htm

http://news.searchina.ne.jp/disp.cgi?y=2009&d=0316&f=business_0316_015.shtml


JRockit VEOS

WebLogic VE: OS不要の効率的なソフトウェアスタック

標準ゲストOSとJVM WebLogic Virtualization Option

JVMWebLogic Server

WebLogic Server orOther Java App Server

ファイル

ネットワーク

仮想化ソフトウェア Oracle VM

仮想化環境での処理性能通常OS環境より

20-40%のオーバーヘッドチューンされた環境より

20％程度高速

JVM層までの必要容量 1GB以上 50MB

JVM層までの構成ファイル数膨大なOS設定 1つ

OS保守（パッチ、入れ替え）必要不要

OSセキュリティ・ホール/不正ログイン可能性ありなし

Coming Soon!

高速

シンプル

セキュア

V.S.

34


アプリケーション実行基盤ラインアップ

ITリソース利用の最大化

WebLogic Server

• Java EE フル機能

• アプリ毎に優先度設定/流量制御

• 実稼動に基づく動的スレッド配分

クラスタリング機能

• クラスタとしての配分制御

• MAN/WANレプリケーション

Oracle Coherence

• 隣のサーバーのCPU/メモリ活用

• ヒープ外領域メモリの利用

• インメモリセッション共有

保守作業の簡素/均一化

プロダクション再デプロイメント機能

• アプリを新版に無停止入れ替え

• 本番環境を間借りしたテスト実施

Oracle Database連携機能

• サービス名によるDB接続

• マルチデータソース機能

クラスタリング機能

• ローリング・アップグレード

• 一括デプロイ

JRockit Mission Control

• JVM内部動作までをドリルダウンして診断・分析

JRockit Real Time

• 不測のトラブル防止（GC制御）

Oracle Coherence

• データソースの計画停止時もシステムを継続稼動

運用監視コストの改善

• 定常作業のスクリプト化 • 複数JVMの詳細を一元監視 • 障害回復の自動処理

構成情報の自動収集

DB層を含む統合運用監視

WebLogic ServerStandard Edition

WebLogic ServerEnterprise Edition

アプリケーショングリッド/WebLogic Suite

複数サーバー構成による可用性・管理性・保守性

複数サーバーを共用化リソースの全体最適化

単一サーバー資産の最大活用アプリ集約環境の実現


36

http://www.oracle.co.jp/inq_pl/INQUIRY/quest?rid=28

Oracle Direct 検索

あなたにいちばん近いオラクル

Oracle Directまずはお問合せください

Web問い合わせフォームフリーダイヤル

専用お問い合わせフォームにてご相談内容を承ります。

※フォームの入力には、Oracle Direct Seminar申込時と同じログインが必要となります。

※こちらから詳細確認のお電話を差し上げる場合がありますので、ご登録されている連絡先が最新のものになっているか、ご確認下さい。

0120－155－096※月曜~金曜 9:00~12:00、13:00~18:00

（祝日および年末年始除く）

システムの検討・構築から運用まで、ITプロジェクト全般の相談窓口としてご支援いたします。

システム構成やライセンス/購入方法などお気軽にお問い合わせ下さい。

http://www.oracle.co.jp/inq_pl/INQUIRY/quest?rid=28

クラウド世代のWebアプリケーション設計　-...

Technology

Transcript of クラウド世代のWebアプリケーション設計　-...

クラウド世代のWebアプリケーション設計 -...

Technology

Transcript of クラウド世代のWebアプリケーション設計 -...

クラウド世代のWebアプリケーション設計　-...

Transcript of クラウド世代のWebアプリケーション設計　-...