クラウド世代のwebアプリケーション設計 · asp.net 2.0 java ee 標準api vb or c#...

<Insert Picture Here>

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

日本オラクル株式会社 Fusion Middleware 事業統括本部

2010年 5月

2Copyright Oracle Corporation Japan, 2010. All rights reserved.

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

•データ量を気にしない

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

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

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

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


インメモリ分散技術

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


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

「隣のサーバーのメモリと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

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

従来型の限界はもはや限界ではない

スループット比較(テストケース2)

0 500 1000 1500 2000 2500 3000

同時仮想端末数

スル

ープ

ット

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

■ レスポンス

■ スループット

セッションサイズ 10K （総メモリ量 3G 制限）での検証テスト結果

従来型クラスタ構成

1G 1GWebLogic

1G

1G

512M

1GWebLogic

512M

Coherence

アプリケーショングリッド構成


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

統合セッション管理層としてのCoherenceの適用

WebLogic Server

WebSphere

JBoss

Tomcat …

Oracle WebLogic 8.x、9.x、10.xOracle OC4J 10.1.2、10.1.3IBM WebSphere 6.xSun GlassFish 2.x

Tomcat 5.5、6.0JBossResin 3.0、3.1Jetty 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


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

アイディア

• 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 TopLink JPA による透過的アクセス


EntityManager API

(find, query, persist, merge)

Coherence API

(get, put, filter)

TopLink JPA

JPAを介したデータ操作をCoherence APIに変換・実行

ご参考

データアクセスAPI

Coherence クラスタ

DB

データソース連携API

利点• SQLライクな問い合わせAPI（JPQL）を利用可能考慮点• データグリッドのフル機能の利用は直接APIをコールする必要あり

// 標準のJPAによるオブジェクト処理コードを記述// JPQLの指定String queryString = “select o from Order o where o.productId = 100”;

// JPQLの実行Query query = entityManager.createQuery(queryString);

List<Order> orders = query.getResultList();

TopLink Grid• Coherence のフロントAPI として利用可能• Java EE標準のJPAによるコーディングによってデータグリッド内データにアクセス


複数サーバーを統合利用

パートナー情報を集約してインメモリ処理

実際の顧客例

トランザクション・ステートをメモリ管理

J.Crew オンラインストア

AppServer

AppServer

AppServer

AppServer

Coherence

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

ヨーロッパ大手銀行トレーディング基盤

Hotwire : 旅行サイトヨーロッパカジノサイト


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://news.searchina.ne.jp/disp.cgi?y=2009&d=0316&f=business_0316_015.shtml


・高い更新性能(0.5ms/件)をリニアに拡張できるスケーラビリティを検証フェーズで実証→ ユーザー数の増加や

市況変化に対して対応計画を描きやすい

・DBやディスクに永続化せずに高可用性を実現

・国内外での稼動実績とコンサルティング実績

・約定性能0.035秒を実現

・Coherence、WebLogic、JRockit Mission ControlOracle RAC を活用

世界最高レベルのFXシステムにむけた超高速オンライン処理

ヒロセ通商様「LION FX」 - フラクタルシステムズ様「U-Forex1」-

ビジネス側のニーズ•顧客サービスの拡充並びに顧客ディーリング収益の追求•約定性能向上•リスク管理の徹底（ロスカット、値洗処理の短縮）•ポジションの高速集計と敏速なカバー取引の実行

システム側のニーズ•データベースに依存した設計によるボトルネック解消•大量トランザクションへの対応•高拡張性と高可用性、システムの安定化を実現•計算処理の高速化

増加する外国為替取引に追従するシステムの拡張性、IT監査に対応する運用システムモデル

LION FX （ヒロセ通商様のFXサービス）として U-Forex1 を採用

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

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

イベントリスナー

フロ

ント

処理

バッ

ク処

理

• Coherenceのデータパーティショニングにより注文リクエスト受付を負荷分散→ノード追加でスループット向上

• WebLogic Server を経由して注文を受付（1000TPS）

• マッチング、ポジション更新を高速化• ポジション集計を秒間100回で実行

• データをインメモリ保持して高速性を維持しながら高信頼性も担保- フロント：レート、注文データ- バック：ポジション、注文データ

レート配信2000レート/秒

注文管理

注文管理

RAC

RAC

発注

マッチングエンジン

• Coherenceのイベントリスナーで注文のマッチング処理を呼び出し


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

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


Appサーバー層

画面系処理

フロー処理

画面系処理

フロー処理

画面系処理

フロー処理

画面系処理

フロー処理

画面系処理

フロー処理



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

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

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

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

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

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

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

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

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

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.

32

「グリッド + 仮想化」 - 真の企業向け高品質クラウド

Web2.0型サービスサイト

Java EE/ISVアプリ

SOAインフラ

ビジネスインテリジェンス

コンテンツ管理

運用管理

JVM JVM JVM JVMJVM JVM JVM JVMJVM

OS OSOS OS OS OS

グリッド型ソフトウェア

Oracle VM

OS

JVMJRockit

Virtual

Edition

JRockit

Virtual

Edition

JRockit

Virtual

Edition

Application

Server

Application

Server

Application

ServerTPM/

.Net他社Appサーバー

オープンソース

Application

Server


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

■ アプリケーション・グリッド / 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


おまけ

WebLogic Server で定常コストにメスを入れよう!

•引き続き、強い「コスト削減」の圧力

出典 : オラクル調査 – 既存顧客アンケート定常コストの内訳

30%

20%

50%

容量管理、HA管理、災害サイト管理

トラブルシューティング、チューニング

デプロイ、構成作業、変更管理

検討事項典型的な対応策課題

サーバー集約環境構築コストの低減

仮想化?大型サーバーのコスト/保守

HW障害時の影響の大きさ

ライセンス節約オープンソース活用? TCO 削減になるのか?

Appサーバーの数が減るわけではない

「アプリケーション集約」という考え方


アプリケーション毎に処理配分を適切に制御

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

WebLogic Server 11 g

ITリソース利用の効率化と運用保守作業の簡素化

コア当たりの能力を最大限に利用

353.66

418.57

IBM Oracle

公式ベンチマーク SPECｊAppServer

22634.13 JOPS/64インスタンス

28463.03 JOPS/68インスタンス

他社Appサーバー

アプリケーションA

アプリケーションB

アプリケーションC

アプリケーションA

アプリケーションB

スレッドプール

実際のリクエスト状況によって配分を適正化

運用側の意図で処理の優先度を制御サーバー数の抑制に貢献

本番環境を間借りしたテスト実行 /ユーザー処理を邪魔せずにアプリを入れ替え

アプリケーションAバージョン 1.1

アプリケーションAバージョン 1.0

一般ユーザー

管理ユーザー

テスト環境構築コスト低減・デプロイ作業の簡略化

クラウド世代のwebアプリケーション設計 · asp.net 2.0 java ee 標準api vb or c#...

Documents