JPA / HTTPセッションをスケーラブルにしよう

<Insert Picture Here>

JPA / HTTPセッションをスケーラブルにしよう

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

2012年 10月

Copyright Oracle Corporation Japan, 2012. All rights reserved.

本日の内容

テーマ

•パフォーマンスの維持

•キャパシティ拡張性

•サービス無停止

技術要素

• Java EE

• JPA/EclipseLink

• Hibernate

2

+ Oracle Coherence

Copyright Oracle Corporation Japan, 2012. All rights reserved. 3

• コンテンツ管理システムのデータソースからサイトに必要なデータを高速収集する機能を実現 - 透過的に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


シンプルなアプリケーション構成


顧客増、アクセス増 → さらなるキャパシティの要望規模拡張（スケール）の開始


2つの選択肢

データベースを強化する - HWコストが大きくなりがち - DB増強作業によってアプリ全体が影響 - 集中する負荷を適切にさばくために高価なストレージも必要

アプリケーション側にキャッシュを設ける（ローカルキャッシュ） - 追加の開発コスト - キャッシュ内データの整合性の調整（下手な仕組みは余計なトラブルを招く）


ローカルキャッシュ: サーバー間での一貫性維持は??? → “分散キャッシュ” という考え方


…

キャンペーン情報商品データ

顧客データ

• 利用数増加 • 市場および利用形態の変化

• 外部サイト/ SNS連携

• 期間限定キャンペーン • 限定商品 • 繁盛期対応

• 情報拡充 • 新商品発表

…

• 顧客別サービス（ポイント制、マイページ）

高信頼性メモリグリッドによって変わること

従来構造で起こる典型的な課題 Oracle Coherence 構成例

物理マシン境界を超える拡張可能な仮想メモリ領域

バックエンドDBとの非同期連携


データ操作時

障害時の動作

大容量かつ高信頼性のインメモリ・データ管理

• アプリケーションが利用するそのままの形式（オブジェクト）でデータをインメモリ保持

– 処理途中の情報（セッション、ステート）

– 高頻度の更新情報

– 参照データ

– 取引確定データ etc…

• アプリケーションは一つのメモリ領域とやり取りしている感覚

• 暗黙的なデータのミラーリング

–プライマリと異なるHWにバックアップを配置

– バックアップの数はデフォルト1

• ノード障害時にはバックアップからデータを自動的に復元

–各プロセスが平行してリカバリを実行

–アプリケーション側にエラーを返すことなくリカバリを実行

プロセス 1

P

B

プロセス 2

P

B

プロセス 3

P

B

プロセス 4

P

B

Ａ B C D

B C D Ａ

Application

Coherence API プライマリに対してget

put時はバックアップも

同期的に更新

プロセス 1

P

B

プロセス 4

P

B

Ａ D

C D

プロセス 2

P

B

B Ａ

プロセス 3

P

B

C

B Ａ D

プロセス2 ①バックアップAがプライマリに移動 ②Aのバックアップを他に作成

プロセス4 ①Dのバックアップを他に作成

P: プライマリ

B: バックアップ

Ａ B C D

Java .NET C++

補足： Oracle Coherence の機能


2つのキーとなる機能

• イベント通知 : リアルタイム型処理に必須の機能

– P2P型のイベント通知 → ノード数に依存しない性能

• パラレル処理 : 大量データ処理時に必須の機能

– 各ノードのCPUを活用したデータ処理

– ノード数の増加 = パラレル度向上

キャッシュ・ノード1 キャッシュ・ノード2 キャッシュ・ノード3 キャッシュ・ノード4

アプリケーション

条件を引数として

処理命令（Invocation）をコール

各ノードでパラレルに

処理を実行

データ追加更新・削除

他クライアントへの通知

後続処理の起動

リモートサイトとの同期化

事前定義問合せ結果セットの更新

ニア・キャッシュの破棄通知



バックエンドとの連携 – いくつかの構成が可能

11

読み取り処理 - Coherence経由でバックエンドからRead （Read-Through） - 指定された時間間隔でキャッシュを自動更新（Refresh-Ahead）

書き込み処理 - Coherence経由で同期型で更新（Write-Through） - 指定された時間間隔で非同期更新（Write-Behind）

同期または非同期で連携



独立した階層としての “キャッシュ層” へ

• メモリ領域で独立した規模拡張 • 異種アプリケーション/異種言語で共用のメモリ領域


将来の規模拡張の

ために


誰もが思うこと

•最初から余計な準備はしたくない（初期コスト最適化）

•将来の規模拡張時にできるだけ楽をしたい

– アプリケーション側の変更影響を最小化したい（作業簡素化）

– 実績のあるやり方で規模拡張したい（リスク低減）

14


Application Server

15

将来の規模拡張に対応するために

Java EE/ISV アプリ

• フロントのリクエスト処理部分 – セッション/ステート・データの格納領域のキャパシティ拡張（同時ユーザー数向上）

• バックエンドのデータ処理への対応 – 拡張可能な共有キャッシュ領域（大量データアクセス対応）

1 → ・Java EE標準を使う（HttpRequest/Response）

2

3

→ ・標準JPA/EclipseLink ・ Hibernate


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

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

WebLogic Server

WebSphere

JBoss

Tomcat …

• Oracle WebLogic 9.x、10.x、11g • Oracle OC4J 10.1.2、10.1.3 • Oracle GlassFish 2.x、3.1 • IBM WebSphere 5.x、6.x、7

• Tomcat 5.5、6.0 • JBoss • Resin 3.1 • Jetty 5.1、6.1

ASP.NET

（2.0 以上）

Java EE 標準API

CoherenceSessionProvider for .NET

Web.config で設定

Coherence*Web

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

Coherence : 高信頼性メモリ領域

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

Coherence API

1


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

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

0 500 1000 1500 2000 2500 3000

同時仮想端末数

スル

ープ

ット

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

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

検証テスト結果

従来型クラスタ構成

1G 1G WebLogic

1G

1G

512M

1G WebLogic

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

海外顧客の事前テスト結果

1


・高コストなスケールアップ対応方式から、よりコスト最適なスケールアウト型アプローチへ移行可能 - 今後の顧客増加に対しシステムの投資予測がしやすい - 増強による品質への影響が少ない（低リスク）

・異種ベンダのAppサーバーを横断するセッション管理層を容易に構築可能

メモリ・キャパシティ改善による顧客利便性と同時処理性能の向上

北米Eメール・マーケティング企業

ビジネス側のニーズ •サービスに対する顧客の信頼性を高めたい（顧客満足度向上） •もっと多くの顧客（企業）を獲得したい。

同時に、それを支えるシステムの投資を高コストな方式ではない、よりコスト最適なアプローチへ移行したい

システム側のニーズ •メインサービスである「Web経由でのEメール・レター作成機能」に

よって、顧客ごとのHTTPセッション・サイズが肥大化 → 圧迫されるAppサーバーのメモリ・キャパシティを改善したい

•計画外/計画停止の両面で顧客に迷惑をかけない運用にしたい

WebベースでEメールのキャンペーン構築・配信・トラッキングのサービスを提供

さらなる顧客獲得に向けた基盤の再整備

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

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

セッションデータのインメモリ保持

【同時ユーザー数向上】 •肥大化するユーザーセッションを Appサーバーの外部メモリに移行 → Appサーバー・キャパシティ改善 = 同時ユーザー数が向上

【メンテナンス性の向上】 • Appサーバーのパッチ適用や入替え作業をサービス無停止で実施

【コスト構造の変革】 •バックエンドDBに処理負荷を依存するスケールアップ型からアプリケーション層のスケールアウト型に移行

Coherence*Web

【顧客利便性の向上】 •障害やタイムアウトでもユーザーの作業中の状態をインメモリ保持

•レスポンス向上・安定化

18


バックエンドのデータ処理

標準JPA/EclipseLink → TopLink Grid 適用

EntityManager API

(find, query, persist, merge)

Coherence API

(get, put, filter)

に変換して実行

• アプリケーションからは Java EE標準のJPAによってアクセス • アノテーションまたは構成ファイルによってオブジェクトのキャッシュ形式を指定

2


画面系処理

フロー処理

画面系処理

フロー処理

画面系処理

フロー処理

JPA JPA JPA


画面系処理

フロー処理

画面系処理

フロー処理

画面系処理

フロー処理

TopLink Grid

JPA JPA JPA

// 標準の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 の適用パターン

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

画面系処理

フロー処理

画面系処理

フロー処理

画面系処理

フロー処理

画面系処理

フロー処理

JPA


画面系処理

フロー処理

画面系処理

フロー処理

画面系処理

フロー処理

JPA

■ Grid Read - クエリは Coherence に対してのみ実行 - 書き込みはDBに直接実施し Coherence にも反映

■ Grid Cache - L2キャッシュとして利用 - 読み書きともにDBへの依存性は残る

■ Grid Entity - 読み書きともに、完全に Coherence 経由で実施 - DB とアプリが分離された構造（DBとサービス可用性を分離）

2

JPA



TopLink Grid の構成パターン 2

■ Grid Cache 構成 @Entity

@CacheInterceptor(CoherenceInterceptor.class)

public class Employee implements Serializable {...

■ Grid Read 構成 @Entity

@Customizer(CoherenceReadCustomizer.class)


■ Grid Entity 構成 @Entity

@Customizer(CoherenceReadWriteCustomizer.class)


【参考】 http://download.oracle.com/docs/cd/E21043_01/doc.1111/b61395/toc.htm Oracle TopLinkのためのCoherence Grid統合ガイド - 「グリッド基盤のJPA」構成

■ または、eclipselink-orm.xml でエンティティとカスタマイザを紐付ける

（Javaソースを変更しない手法）

http://download.oracle.com/docs/cd/E21043_01/doc.1111/b61395/toc.htm


1 2 3 4 5 6 7 8 9 10

0

0.5

1

1.5

2

2.5

Hotel View Response Time

No Coher-ence View-Response

Coherence View-Re-sponse

Tiles

Resp

ons

e T

ime (

sec)


TopLink Grid の効果 2

ホテル空室問い合わせのデモ・アプリケーションでの検証例

空室状況一覧表示のレスポンスタイム

レスポンスタイム（秒

）

1 2 3 4 5 6 7 8 9 10

0

10

20

30

40

50

60

70

80

90

100

CPU Load on DB

No Coherence DB-CPU

Coherence DB-CPU

TilesC

PU

(%

)

DB 側のCPU負荷

■ Coherence を利用しない場合 ■ Coherence を利用する場合（TopLink Grid/Grid Entity構成）

サーバー台数サーバー台数

• 2.5倍の性能向上（クエリ処理、トランザクション処理） • 秒間数百万処理まで問題なくスケール • 安定したサービス品質（レスポンスタイム）でリニアに規模拡張可能 • データベースのCPU負荷を 40+% 軽減



Hibernate のキャッシュ機構への組み込み


画面系処理

フロー処理

Hiber nate

■ Hibernate L2キャッシュ - TopLink Grid の Grid Cache と類似の機能 - Hibernate の構成ファイルのプロパティとして指定することで組み込み - Hibernate のキャッシュ機構に基づいた3つのキャッシュ形式をサポート

3

• セッションキャッシュセッション個別のキャッシュとして機能 • L2キャッシュキーによる問い合わせに対応するキャッシュセッションを超えて結果を共有 • 問い合わせキャッシュ問い合わせ条件に対応した結果セットのキャッシュセッションを超えて結果を共有

【参考】 http://download.oracle.com/docs/cd/E16459_01/coh.350/b56042/usehibernateascoh.htm Oracle Coherence統合ガイド - HibernateのL2キャッシュとしてのCoherenceの使用

http://download.oracle.com/docs/cd/E16459_01/coh.350/b56042/usehibernateascoh.htm


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(); ... }

// キャッシュの取得 NamedCache productsStore = ….

// 問い合わせ処理の実行例 Set resultSet = productsStore.entrySet( QueryHelper.createFilter( “name like ‘%テレビ%’ and price < 250000” ) );

24

補足： Oracle Coherence をフルに使うなら

■ Coherence API を直接利用する場合 - SQL Where句に類似の表現によって条件を設定して処理を分散実行させる（パラレル問い合わせ、集計、データ変換など）


国内のお客様

25

Case Study

www.rakuten.co.jp

楽天市場様

日本生活協同組合連合会様

DBの稼働状況に左右されないサービス可用性を実現

複数事業体の共通基盤として安定したサービスレベルを提供


パフォーマンスだけではない、メモリグリッドによる効果

アプリ

ケーション

アプリ

ケーション

アプリ

ケーション

サーバー停止からシステムを保護

業務の傍らで定期保守可能

バックエンドDBの負荷を軽減

バックエンド性能からの解放

26

フロント・アプリのレスポンス向上

今後のサービス拡充に応える基盤余力

要件に応じて容易・即座に拡張可能

廉価マシンの適正規模でスタート可能

アプリ

ケーション

顧客満足度向上

サービス安定化

投資適正化

運用・保守の改善


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

J.Crew オンラインストア

App Server

App Server

App Server

App Server

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

27

実際の顧客例

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

DBの停止状態でもサービス稼働を継続

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

FedEx 貨物追跡北米自動車ディーラー向けSaaSベンダー

北米流通小売企業

App Server

App Server

App Server


まとめ

•サービス無停止と将来の規模拡張に対応可能な仕組みを使うことをご検討ください。

– キャパシティ改善が可能な仕組みは、容量計画に失敗してしまった場合にも役に立ちます。

– 次々と機能拡充が求められるサービス領域においてもキャパシティ拡張性は大きな助けになります。

– DBとアプリケーションの分離は、メンテナンスやサーバー入れ替えなどの運用作業にも有用です。

28


構成変更の容易性

Coherence の機能的特徴

• アプリケーションから物理位置を意識せず利用可能

• アプリの稼働状況下でも Coherenceサーバーの増強・縮退が可能

= 規模に応じて配置構成を変更可能

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

Coherence インスタンス

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

補足情報


もう一歩進んだ情報は…

•書籍: 『Oracle Coherence入門』

• トレーニング・コース Oracle Coherence: Share and Manage Data In Clusters

– 3日間の充実コース

– チーム・メンバー全体でのレベル向上にお勧め

30

•キャッシュの設計 • ドメイン・オブジェクトの実装 •データグリッドの照会 •並行インプレース処理 •データグリッド・イベント処理 •永続化層の実装 •プラットフォーム間接続とネットワーク境界 • .NETからのアクセス • C++からのアクセス •適切なツールの選択

http://www.amazon.co.jp/dp/4048689533

http://www.amazon.co.jp/dp/4048689533

http://education.oracle.com/pls/web_prod-plq-dad/db_pages.getCourseDesc?dc=D70466JP10&p_org_id=70&lang=JA




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

blogs.oracle.com/coherence_jp

• 国内事例/ユースケース

• アナリスト記事

• 技術コラム/トピック

• オンラインデモ

• ホワイトペーパー

• 自習用コンテンツ

• セミナー/イベントのご案内

http://blogs.oracle.com/coherence_jp

http://blogs.oracle.com/coherence_jp


Technology

JPA / HTTPセッションをスケーラブルにしよう