X

An Oracle blog about Oracle Coherence

Recent Posts

05.インフォメーション

Coherence 12.2.1 リリース

Coherence の最新バージョン12.2.1 がリリースされました(リンク)。主な新機能/改善機能は以下の通りです。 リソース効率化 ヒープ外メモリを利用したキャッシュ領域の拡大: 従来からある Elastic Data 機能(透過的にヒープ外の領域[メモリおよびディスク]を利用して大容量データを管理する機能)に、ヒープ外メモリのみを使う(ディスク出力を起こさせない)モードがい追加されました。これはJavaヒープをそれほど大きく確保しなくても大容量のキャッシュ領域を確保できるため、GC影響を受けないアプリケーションメモリ環境を実現できます。 マルチテナント対応: WebLogic 12.2.1 と同様に、一つのJVM内でリソースを使い分けて、同じアプリケーションを複数のテナントに分割して利用できるモードが追加されました。 運用自動化・効率化 Persistence: メモリ内の情報およびステートをディスクに出力またはディスクから復旧するオプションが追加されました。これにより、より強固な信頼性を確保し、Coherence 内の領域をシステムの記録域として完全に利用できるようになります。また、キャッシュデータのバックアップ/リカバリとしても利用できるため、クラスタ再起動時の復旧時間の短縮にも活用できます。 Federated Cache: 複数のCoherenceクラスタをさまざまな設定でレプリケーションできるようになりました。既に稼働実績のある機能で、BCP/DR 目的で利用したり、各拠点でそれぞれに更新されるデータの競合解決をしながら同期化する仕組みとして利用いただけます。 開発生産性 Java8 コーディング規約対応: ラムダ式やストリームに対応したCoherence API が用意されました。 機能強化 セキュリティ強化: Coherenceへのアクセスするクライアントへ認可する操作の制限を行うことができます。たとえば、あるクライアントは読み取りのみ、というようなことが可能になります。 REST経由でのイベント通知: REST API経由でもサーバーサイドイベントを検知できるようになりました。Web経由でのPush型イベント通知ができるため、よりアクティブでデータ不整合のないアプリケーション実現が可能になります。 まだ英語のみですが、最新のドキュメントも参照いただけます(こちら)。

Coherence の最新バージョン12.2.1 がリリースされました(リンク)。主な新機能/改善機能は以下の通りです。 リソース効率化 ヒープ外メモリを利用したキャッシュ領域の拡大: 従来からある Elastic...

04.技術情報・Tips

Memcached Adaptor

Coherence 12.1.3 より利用可能な memcached アダプタ。これは、PHP などで広く利用されている memcached のインターフェースのままで Coherence にアクセスできるようになる仕組みです。こうしたニーズは昔からあり、その仕組みを実現しようとしていたパートナーもいました。いまや、それは正式な製品機能として提供されています。 どうやって使うの? 使い方は、公式ドキュメントを見ていただくのが良いですが、もう少しとっつきやすい情報として、江草ロジ子さんが翻訳情報を公開してくれました。これは最初のステップとして非常に良いものです。 [Coherence] Getting Started With The Coherence Memcached Adaptor  何が良いの? これが利用できると何が良くなるのでしょう? memcached はシンプルなキャッシュですが、利用する側は利用範囲や信頼性などにおいて、ある程度の割り切りが必要でした。Coherence を利用することで、そうした、エンタープライズ用途としてはちょっと足りない部分を補完することができます。 信頼性/耐障害性この部分が弱い memcached が Coherence になることで、実績ある信頼性/耐障害性を手に入れることができます。障害時の作業は大きく簡易化されるでしょう。 アプリケーション・コードの簡素化memcached 利用アプリケーションでは、典型的に次のような処理フローを記述します。 1) 該当データの有無についてキャッシュに確認、 2) キャッシュにない場合 DBに問い合わせ、 3) DBからデータを取得してキャッシュに格納。 これをアプリケーション開発者がぞれぞれに記述していると、品質にむらが出たり、DB変更時の作業が膨れ上がるなどのリスクが出てしまいます。エンタープライズシステムとしては考え物です。Coherence memcached アダプタを用いると、Coherence の裏側で CacheStore read-through を利用できるようになります。すると、「キャッシュになかったらDBに問い合わせ」 という処理は勝手にやってくれます。 既存 memcached アプリは、そのままでもかまいません。ただし、「DBへ問い合わせ」という処理はもはやコールされないでしょう。 新規アプリケーションは、「DBへ問い合わせ」の処理記述が不要になります。これは Coherence の背後で自動で実施されるので、「キャッシュにある」 こと前提でアプリケーションを記述できるようになります。 更新処理としての利用信頼性/耐障害性とCacheStore機能を組み合わせると、Coherence memcachedアダプタは、読み取りだけでなく、更新ルートとしても利用できることに気づきます。これにより、memcachedアプリケーションはさらに簡素化します。一方で、DBアクセス処理が集約され、専門のDB技術者に処理コードを保守してもらえば、品質も向上するでしょう。 他アプリケーションとの連携Coherence memcached アダプタを介して、より高度な Coherence アプリケーションと同一の共有メモリを通して会話できるようになります。それぞれのアプリケーションで起きた最新の変化(ステート)を即座に他アプリケーションが共有できるため、特に、複数ある顧客向けフロントシステム間の情報共有に有効です。この共有メモリ領域上に、memcached アプリケーションも加われるようになります。 何はともあれ、Coherence memcached アダプタは、既存のmemcachedアプリケーションを大きく変えることなくメモリグリッド環境に加えることができるのが最大の利点です。既存memcachedアプリケーションをお持ちのかたは、ぜひお試しください。

Coherence 12.1.3 より利用可能な memcached アダプタ。これは、PHP などで広く利用されている memcached のインターフェースのままで Coherence にアクセスできるようになる仕組みです。こうしたニーズは昔からあり、その仕組みを実現しようとしていたパートナーもいました。いまや、それは正式な製品機能として提供されています。 どうやって使うの? 使い方は、公式ドキュメ...

05.インフォメーション

[速報] JCache API対応の Coherence 12.1.3 リリース

JCache(JSR-107)対応の最新の Oracle Coherence(12.1.3)がリリースされました。Java EE 標準を先取りするうえで見逃せません。 Coherence : US OTN サイト(OTN Japan での対応はもうしばらくお待ちください)* 2014/06/27時点、US OTNでも、ドキュメントはまだ更新されていません。 Coherence 12.1.3 では、主に下記の機能が追加されています。 JCache API : 次世代 Java EE 8 で実装予定の JCache API を実装。Coherence の信頼性を Java EE の標準として利用できます。 memcached アダプタ : memcached クライアントがそのまま透過的に Coherence にアクセス可能なアダプタを提供。あなたの memcached 環境の信頼性を向上させ、読み取りだけでなく書き込み用途にも展開できます。 非同期 EntryProcessor / 非同期 Aggregator : Coherence の特徴の一つであるサーバーノードを使ったパラレル処理(グリッド型処理実行機能)を non-blocking な非同期モードで実行できます。クライアントは EntryProcessor/Aggregator を起動して、結果を後で取得することができるようになります。 なお、今回のリリースは Coherence だけでなく、Oracle Fusion Middleware の多くのコンポーネントが同時リリースされています。WebLogic、SOA Suite、BPM Suite の 12.1.3 にも注目です。

JCache(JSR-107)対応の最新の Oracle Coherence(12.1.3)がリリースされました。Java EE 標準を先取りするうえで見逃せません。 Coherence : US OTN サイト(OTN Japan での対応はもうしばらくお待ちください) * 2014/06/27時点、US OTNでも、ドキュメントはまだ更新されていません。 Coherence 12.1.3...

03.導入事例

導入事例|Internet of Things/M2M

Eコマース/B2Cサービス 金融機関/関連サービス 通信サービス IoT/M2M Internet of Things/M2M  広がりを見せる Internet of Things 型のサービス検討。どの企業も戦略的な取り組みで、その内部はなかなか見えてきませんが、確実に動いています。サービス差別化のためのタイムリーな処理と、今後の情報量増加に対応するための選択肢として、Oracle Coherence が選ばれています。 キヤノン株式会社 「複合機IoTソリューション」 キヤノンは2014年、全世界で100万台を超える複合機から収集した稼働情報をさまざまな顧客サービスへと転換するIoTソリューションのシステム基盤を刷新した。その新基盤を支える中核技術が「Oracle Exalogic」や「Oracle Coherence」、「Oracle Event Processing」といったオラクルの製品群だ。 記事を見る 詳細を見る 視聴する 日本電気株式会社 M2Mプラットフォーム 「CONNEXIVE」 すでに国内で稼働実績のあるM2Mプラットフォーム「CONNEXIVE」。よりリアルタイム性が求められる IoT 要件に対応すべく、「CONNEXIVE」を支える基盤テクノロジーとして「Oracle Coherence」を導入。処理性能および耐障害性の向上に貢献。 記事を見る 詳細を見る Nike 「Digital Platform」 Fuel Band などをお使いの世界中のユーザーとつながる Nike の Digital Platform。このパフォーマンスとスケーラビリティを支える基盤として「Oracle Coherence」、「Oracle Exadata」および位置情報管理「Oracle Spatial」を活用。 視聴する[英語] Sascar 「フリート管理」 「Oracle Coherence」「Oracle SOA Suite/Event Processing」「Exalogic」「Exadata」を活用して、数十万台の車両のリアルタイムの車両追跡を実現。秒間50,000メッセージの処理を連続処理しながら、高い圧縮率でデータを管理。 視聴する[英語] 記事を見る[英語]

Eコマース/B2Cサービス 金融機関/関連サービス 通信サービス IoT/M2M Internet of Things/M2M  広がりを見せる Internet of Things 型のサービス検討。どの企業も戦略的な取り組みで、その内部はなかなか見えてきませんが、確実に動いています。サービス差別化のためのタイムリーな処理と、今後の情報量増加に対応するための選択肢として、Oracle Coherenc...

04.技術情報・Tips

Hadoop MapReduce and Coherence

Hadoopのプログラミング・モデルをインメモリで実行させたい - そんなニーズを聞くことがあります。スケーラブルなモデルという意味では、Coherence を思い浮かべる方もいることでしょう。 ちょうど、そのような記事が上がっていますのでご紹介します。 [日本語翻訳] [Big Data, Coherence] Hadoop MapReduce and Coherence - A Perfect Matchby 江草ロジ子 [元記事] Hadoop MapReduce and Coherence - A Perfect Match 要約すると、Hadoop のモデルの入出力部分に Coherence を融合させるための追加のインターフェース・コンポーネントを少しだけ補完する、というものです。下記図において、青の部分が Hadoop、オレンジ部分が Coherence というイメージです。 両方ともにスケーラブルなテクノロジーですので、その利点を殺さない、よい組み合わせだといえますね。なお、 Hadoop のプログラミングモデルではないですが、Coherence 上での分散プロセッシングとしては、Coherence Incubator に Processing Pattern というものもあります。ご興味ある方はこちらもぜひ。

Hadoopのプログラミング・モデルをインメモリで実行させたい - そんなニーズを聞くことがあります。スケーラブルなモデルという意味では、Coherence を思い浮かべる方もいることでしょう。 ちょうど、そのような記事が上がっていますのでご紹介します。 [日本語翻訳] [Big Data, Coherence] Hadoop MapReduce and Coherence - A Perfect...

05.インフォメーション

Coherence 12.1.2/WebLogic 12.1.2 - WebCast & 最新イベント情報

Oracle Coherence 12.1.2/WebLogic 12.1.2 が US Oracle Corporation よりアナウンスされました。これを受けて、グローバルでも、国内でも、いよいよ動きが始まりました。 グローバル・プレスリリース グローバル WebCast 日本時間 8月1日 午前2時(太平洋夏時間 7月31日 午前10時 )深夜ですが、夜に強い方は是非ご覧ください。 国内でも、すでにイベントが行われることが決定しています。 Oracle Coherence 12c Forum(併設 WebLogic Server 12c Forum) 従来から評価の高いコア機能や使いやすさを踏襲しながら、新しい領域へとチャレンジします。イベント駆動のサービスへのニーズが高まる今、DB の変更を検知する仕組み(HotCache)やイベント処理をより柔軟かつ汎用的に構築する仕組み(Live Event)、管理/デプロイの効率化のための仕組み(Managed Server)を含め、さまざまな強化・改良がおこなわれています。ぜひ、ご参加ください。 日時:  8月1日 13:30-17:00 場所:  オラクル青山センター 参加無料 詳しくはこちらをご覧ください

Oracle Coherence 12.1.2/WebLogic 12.1.2 が US Oracle Corporation よりアナウンスされました。 これを受けて、グローバルでも、国内でも、いよいよ動きが始まりました。 グローバル・プレスリリース グローバル WebCast 日本時間 8月1日 午前2時 (太平洋夏時間 7月31日 午前10時 ) 深夜ですが、夜に強い方は是非ご覧ください。 国内でも、...

04.技術情報・Tips

Spring Batchを用いた高パフォーマンス・データ・ローディング

筆者: Vijay Nair、原文はこちら Spring Batchフレームワークと、データ・ロードのためのマルチスレッド化されたアプローチとの組合せによって、Coherenceベース・アプリケーションの管理性とパフォーマンスの向上を実現する方法 2011年12月公開 ますます多くの企業が大規模データ・セットに対応したインメモリ処理のメリットを追及するようになり、インメモリ処理を促進する製品への関心は急速に高まっています。 Oracle Coherenceは、シンプルなインタフェース、汎用プラットフォームに対する幅広いサポート(例: C++、Net、Hibernate、JPA)、およびわずかな構成の工夫でテラバイト級のデータに対応できるスケーラビリティによって、この領域にある多くの類似製品の中でもっとも優れた製品となっています。 さらに、企業環境内でのデータ・グリッド・キャッシュの重要性が増しているため、以下の条件を確保することが必須となっています。 任意のソース(例:フラット・ファイル/データベース)からのデータをキャッシュにロードするための時間を、最小限にする必要があります キャッシュへのデータ・ロードが、許容できる品質と信頼性で実行される必要があります 適切な部署への通知を行う機能など、的確なエラー処理メカニズムを導入する必要があります キャッシュのデータ・ロードに関するレポートを作成する機能が利用できる必要があります データ・ロード・プロセスに関するこれらの条件を確保することで、データ・グリッド・キャッシュにおけるデータの信頼性が保証されます。 SpringSourceのポートフォリオを元にしたオープンソース・プロジェクトであるSpring Batchは、大規模データの処理に必要な上記の特性を持ったインフラストラクチャを提供するJavaバッチ処理フレームワークの一つです。 この記事では、Spring Batchを使用して、Oracle CoherenceキャッシュにCSVファイルをロードする方法について説明します。 説明を簡潔にするために、ここでは、Oracle Coherence 3.7.1用の配布サンプル・ファイルに含まれているcontacts.csvファイルに変更を加えて再利用しています(レコードを99,990件まで追加)。 なお、この記事は、Oracle Coherence、Spring Framework、Spring Batchについて中級レベルの知識を持つ読者を対象としています。 プロジェクトの設定 ここでは、Oracle Enterprise Pack for Eclipseを使用します。このOracle Enterprise Pack for Eclipseは、Oracle Fusion Middlewareテクノロジー(この例ではOracle Coherence)を使用してアプリケーションを実行およびデバッグする場合に必要となるプラグインの包括的なセットを、オラクルのIDEとして提供します。 また、Oracle Enterprise Pack for Eclipseは、Springをサポートする包括的なツールも提供します。したがって、Oracle Enterprise Pack for Eclipseは、私のように両方のテクノロジーを連携させる開発者にとって不可欠なものとなっています。 最初に、以下のフォルダ構造とファイル(サンプルをこちらからダウンロード)を使用して、Oracle Enterprise Pack for Eclipseで新規のSpringプロジェクトを作成します。 また、Spring Frameworkのコアjarファイル(ファイルの依存関係を含む)、Spring Batchのjarファイル、およびOracle Coherence jarファイル(<<COHERENCE_HOME>>/libの下にあります)をすべて追加する必要もあります。 Oracle Coherenceで提供されているサンプル・モデルの使用に加えて、Oracle Coherenceで提供されているexamples.zipファイルにあるすべてのJavaファイルをコンパイルし、jarファイル(例: examples.jar)としてエクスポートする必要があります。 図1: 新規のSpringプロジェクト 変更を加えたcontacts.csvファイルには、連絡先情報が格納されています。 このファイルの各行は、キーとなるContactldオブジェクトおよび値となるContactオブジェクトとともに、マップとしてキャッシュにロードされます。 Contactオブジェクトには、以下のものが含まれています。 名の文字列表現 姓の文字列表現 2つの"アドレス"オブジェクト(HomeとWork) "PhoneNumber"オブジェクトで表される2つの電話番号を含むマップ ContactIdオブジェクトには、以下のものが含まれています。 名の文字列表現 姓の文字列表現 名と姓の組合せは、マップのキーとして、すべてのレコードに対して一意になるようにする必要があります。 サンプル・データの一部を、次に示します。 John,Loehe,1968-01-01,675 Beacon St.,,Dthaba,SC,91666,US,Yoyodyne Propulsion Systems,330 Lectroid Rd.,Grover's Mill,NM,41888,US,home,11,74,286,6864191,work,11,45,362,5379579, John,Vadrypkwiy,1978-12-29,62 Beacon St.,,Zxnmgcw,OR,18083,US,Yoyodyne Propulsion Systems,330 Lectroid Rd.,Grover's Mill,DC,81140,US,home,11,82,98,4330491,work,11,56,422,7695959, Spring Batchの使用 Spring Batchは、項目の読み込み(リーダー、ItemReader)と項目の書き込み(ライター、ItemWriter)の概念に基づいています。 また、Spring Batchは、ファイル内にある各行のデータをモデル・ファイルにマッピングするカスタム・マッパー・クラスを作成する機能も提供します。 少し興味深い例とするために、シングルスレッドでのデータ・ロードの実行とマルチスレッドでのデータ・ロードの実行の比較について説明しましょう。 最初に、batchCoherenceという名前のジョブを定義します。このジョブには、Spring Batchによって提供されるリーダーのFlatFileItemReader、カスタム・マッパー(CoherenceSampleMapper.java)、およびカスタム・ライター(CoherenceBatchWriter.java)を使用するステップが含まれます。 図2: batchCoherenceJob "チャンク"のコミット間隔は、1,000に設定します。つまり、リーダーを1,000回起動して、1,000個の項目をリストに移入するようにします。 このチャンクの間に、ライターは1回だけ起動されます。これによって、非常にスケーラブルなアーキテクチャを実現しています。 リーダーに対しては、次のものを構成します。 ロードされるリソース(この事例ではcontacts.csv) DelimitedLineTokenizer(デリミタとして","を使用) 各行を目的のモデルに変換するカスタム・マッパーのFieldSetMapper(CoherenceSampleMapper.javaとして構成) マッパーは、Spring Batchフレームワークによって提供されるFieldSetMapperを実装し、ファイルから読み取られたすべての行に対して起動されます。 その後、マッパーは、利用できるデータを、Spring Batchインフラストラクチャに戻されるContactモデルに変換します。 リーダーは、次のようになっています。 図3: CoherenceSampleMapper.java カスタム・ライターには、次の特徴があります。 Spring Batchフレームワークによって提供されるItemWriterインタフェースを実装、およびwrite()メソッドを実装するようにしています。 すでに説明したように、各チャンク処理の間にリーダーが1,000回起動され、モデルへのマッピングが実行されると、このモデルは項目のリストとしてライターで利用できるようになります。これによって、ライターは、リストに対してあらゆる種類の操作の実行を選択することが可能となります。この事例では、Coherenceキャッシュへの書込みを実行します。 Spring Batchフレームワークによって提供されるStepExecutionListenerインタフェースを実装、およびbeforeStep()メソッドとafterStep()メソッドを実装するようにしています。 その名前が示すように、これは、特定のイベントに基づいてメソッドをトリガーできるリスナー・クラスです。 そこで、この例では、beforeStep()メソッドで読取り/書込みを開始する前にCacheFactoryを開き、afterStep()メソッドでキャッシュへのプッシュが完了した後でCacheFactoryを正常に閉じるようにしています。 Spring Batchフレームワークによって提供されるChunkListenerインタフェースを実装、およびbeforeChunk()メソッドとafterChunk()メソッドを実装するようにしています。 これは、それぞれの"チャンク"の読取りまたは処理の前後に、特定のアクティビティを実行するのに役立ちます。 この事例では、キャッシュへのプッシュを実行するたびに、その後にマップ"mapBatch"を消去しています。 ライターは、次のようになっています。 図4: CoherenceBatchWriter.java ご覧のように、Spring Batchは役割分担が非常に明確化された数多くの役に立つメソッドを提供しているため、コードを保守する際に役に立ちます。 さらに、これらのリスナー・メソッドのいずれかで、入力ファイルのロード中に障害が発生した場合、またはデータをキャッシュにプッシュしている最中に障害が発生した場合は、便利な通知/トリガー・メカニズムを実行できます(ただしこれは、この記事の対象範囲外ですが)。 マルチスレッド用サンプルの用意 次に、シングスレッドとマルチスレッドのアプローチを比較する準備をするために、batchCoherenceJobmtと言う名前の新規ジョブを定義します。このジョブには、シングルスレッドのサンプルと同じFlatFileItemReaderおよび同じカスタム・マッパー(CoherenceSampleMapper.java)を使用するステップが含まれます。 また、新しいカスタムのマルチスレッド・ライター(CoherenceMTBatchWriter.java)も用意します。 図5: batchCoherenceJobmt 今度は、Springが提供するタスク・エグゼキュータの実装である非同期タスク・エグゼキュータで実行するために、タスクレットを割り当て、スロットル制限を5に設定します(スレッド・リソースの再利用に役立つものであれば、Springのどのようなタスク・エグゼキュータ実装であっても割り当てることが可能)。 前述の手順と同じように、"チャンク"のコミット間隔は、1,000に設定します。つまり、リーダーを1,000回起動して、1,000個の項目をリストに移入するようにします。 ライターは、このチャンクの間に1回だけ起動されます。 リーダーとマッパーは、次のように、シングルスレッドのサンプルと同じように構成します。 図6: CoherenceSampleMapper.java(マルチスレッド・バージョン) 図7: CoherenceBatchWriter.java(マルチスレッド・バージョン) ここでは、新しいMap<ContactId,Contact>を作成して、マルチスレッド実行の観点からwriteメソッド自体の中でこれを消去してスレッド・セーフにしました。 次は、テスト・フェーズへと進み、データ・ロードに関するシングルスレッドとマルチスレッドのアプローチを比較します。 すべてのテストは、インテルCore Duo CPU 2.4GHzと2GBのRAMを搭載したラップトップ上で実施しました。 実行: シングルスレッド 各ジョブの実行についての情報を格納するための、Spring Bacth のバッチ・リポジトリとしてOracle Databaseリポジトリを使用しています。つまり、通常のSpring Batchメタデータ表に関する場合と同じ必須要件が求められます(static.springsource.org/spring-batch/reference/html/metaDataSchema.htmlを参照)。 このサンプルでは、resourcesフォルダの下にあるjdbc.propertiesがテスト・データベースを指すように構成しました(実行の前に、クラスパスにojdbc.jarまたは適切なJDBCドライバを追加することが必要)。 最初に、<<COHERENCE_HOME>>/binの下にあるcach-server.cmdを使用して、通常のOracle Coherenceサーバーを起動します。 図8: サーバーの起動 また、<<COHERENCE_HOME>>/binの下にあるcoherence.cmdを使用して別のCoherenceノードを起動し、次のように入力します。 Map <?>: cache CacheBatchTestNonMT (シングルスレッドのシナリオで使用する名前付きキャッシュ) これによって、名前付きキャッシュのプロンプトが表示されます。 sizeコマンドを使用したクイック・テストでは、次の図のように、この名前付きキャッシュが空であることが示されます。 図9: サイズ・テストの実行 Eclipseに戻り、SpringのJUnitサポートを利用した簡単なテスト・ケース(OTNCoherenceBatchTest.java)を開きます。このテスト・ケースは、Springアプリケーション・コンテキストに必要なファイルをすべてロードするように記述されています。 図10: OTNCoherenceBatchTest.java クラスを右クリックし、「Run as JUnit test」を選択します。 Eclipseコンソールで、既存のクラスタに接続し、キャッシュ・コネクション・ファクトリが取得されていることが、はっきりと確認できます。 図11: JUnitテストの結果 メイン・サーバー(cache-server.cmdを使用して起動済み)では、転送されているデータを確認できます。 図12: 進行中のデータ転送 coherence.cmdを使用してCoherenceノードを起動し、sizeコマンドを入力すると、次のように、ファイルからロードされたデータがキャッシュに含まれていることが示されます。 ">Map <CacheBatchTestNonMT): size 99990 バッチ・ステップ実行表への問合せによって、実行時間が53.297秒であることを確認しました。 次は、この結果を、マルチスレッドのアプローチにおける結果と比較します。 実行: マルチスレッド 前述と同じ手順を実行しますが、CacheBatchTestMT-2と呼ばれる新しい名前付きキャッシュを使用する点が異なります。 このテストのために作成された別のJUnitテスト・ケース(OTNCoherenceBatchMTTest.java)を実行して、次のようにサイズを確認します。 Map <CacheBatchTestMT-2>: size 99990 バッチ・ステップ実行表への問合せによって、実行時間が28.218秒であることを確認しました。この結果は、シングルスレッドのアプローチよりも実行時間がおおよそ45%短縮されていることを示しています。 結論 Oracle Coherenceは、バッチ処理にとっての必須条件であるインメモリ・データ・グリッドへの高速アクセスを実現することによって、世界中の金融機関でバッチ・ワークロードにおけるパフォーマンス向上に役立っています。 しかし、Oracle Coherenceのデータ・グリッドのサイズが大きくなると、パフォーマンスを維持する上で、データのロードおよびアクセスに必要な時間の最小化が極めて重要となってきます。 上記の結果から分かるように、マルチスレッドのアプローチは、ロードとアクセスの両面で、シングルスレッドのアプローチと比較してパフォーマンスがはるかに優れています。 Spring Batchインフラストラクチャを使用することで、このアプローチの構成を宣言的な方法で極めて簡単に実行できます(例: Springタスク・エグゼキュータの使用)。 Vijay Nairは、オラクルのFinancial Services Global Business Unitで、テクニカル・アーキテクトとしてOracle FLEXCUBE Private Bankingを担当しています。 おもに、スケーラブル・コンピューティング関連、およびプライベート・バンキングの分野でこれらの原理を実践的なシナリオに適用するための作業に精力的に取り組んでいます。

筆者: Vijay Nair、原文はこちらSpring Batchフレームワークと、データ・ロードのためのマルチスレッド化されたアプローチとの組合せによって、Coherenceベース・アプリケーションの管理性とパフォーマンスの向上を実現する方法 2011年12月公開 ますます多くの企業が大規模データ・セットに対応したインメモリ処理のメリットを追及するようになり、インメモリ処理を促進する製品への関心は急速...

04.技術情報・Tips

イベントリスナーに関する技術記事

Coherence にはイベントリスナーという機能があります。これは、put や remove 操作のタイミングで、そのイベントを検知して何らかの処理をさせるものです。これに関して、江草ロジ子 blog で記事の紹介がありました。 紹介されている記事では、Coherence のイベントリスナーには、3つの実装があることがまとめられています。 クライアント側、非同期型実装 クライアント側、同期型実装 サーバー側実装(BackingMap Listener、MapTrigger) 記事の原文は英語ですが、上記3つの違いをシーケンス図を用いて説明してあります。このシーケンス図を知っておくだけでも価値があります。 1 は、Coherenceサーバー側の変更をクライアントで検知したい場合に使用します。たとえば、複数のサブアプリケーションの連携によって一つの処理を完結させるケースなどです。この場合、後続処理を担当するアプリケーションは、先の処理を担当するアプリケーションが処理結果を Coherence サーバーに put したことをリスナーで検知して後続処理を開始する、といった構造に仕立てることができます。 2 は、1 のケースで、さらに処理のアトミック性が要求される場合に使用します。ただし、同期型であるため、大本の put 処理の完了は、後続のイベント処理まで引きずられることを認識しておく必要があります。 3 は、サーバー側での自動イベント処理として利用するものです。なお、記事の原文では、この内部処理におけるブロッキングタイムに関する考察が書かれていますが、Listener ロジック内で java.util.Queue  とスレッドを用いた実装パターンで対処可能です(その発想で作られているのが、Coherence Incubator の Messeging Pattern です)。この実装パターンを利用すると、一般に SEDA(Staged Event Driven Architecture)と呼ばれるアプリケーション構造をスケーラブルに構築しやすくなります。

Coherence にはイベントリスナーという機能があります。これは、put や remove 操作のタイミングで、そのイベントを検知して何らかの処理をさせるものです。これに関して、江草ロジ子 blog で記事の紹介がありました。 紹介されている記事では、Coherence のイベントリスナーには、3つの実装があることがまとめられています。 クライアント側、非同期型実装 クライアント側、同期型実装 サーバー...

01.特集・コラム

技術者向け・自習コンテンツ : 2013/01版

製品概要から、2013年1月時点での最新版であるバージョン3.7.1までのアップデート情報、より踏み込んだ自習用コンテンツやオンラインデモを改めてご紹介します。さまざまなアプリケーション・サーバーとともに活用される Oracle Coherenceは、特にフロントシステムにおけるアーキテクチャがどうあるべきかを理解する上でのヒントにもなりますので、この仕組みや適用効果を理解しておくことはアーキテクトとして無駄にはなりません。ぜひ。 【セミナー資料】Oracle Coherence 概要(Slideshare) 【セミナー資料】Java EE標準のJPA / HTTPセッションをスケーラブルにしよう(Slideshare) 【技術資料】Oracle Coherence 3.7.1 Update(Slideshare) 【技術資料】インメモリデータグリッド Coherence 技術解説(Slideshare) 【技術情報】自習向けコンテンツ(コンテンツ・リンク集)- Oracle Coherence インメモリ・データグリッドの仕組みと活用- Oracle Coherence を使用したデータグリッド開発- オラクルコンサルが語る、超高速、Oracle Coherence の高可用性を支える多様な障害検知アーキテクチャ他、多数あります。 【デモ動画】メモリグリッドによるサービス可用性の改善(オンラインデモ) 【デモ動画】異拠点データセンター間レプリケーション(オンラインデモ) 【事例】Eコマース、通信、金融サービス(事例一覧ページ) 【書籍】Oracle Coherence 入門(書籍紹介ページ) 【教育コース】Oracle Coherence : データ・グリッド開発と操作(5日間コース) その他、関連Slideshare一覧

製品概要から、2013年1月時点での最新版であるバージョン3.7.1までのアップデート情報、より踏み込んだ自習用コンテンツやオンラインデモを改めてご紹介します。 さまざまなアプリケーション・サーバーとともに活用される OracleCoherenceは、特にフロントシステムにおけるアーキテクチャがどうあるべきかを理解する上でのヒントにもなりますので、この仕組みや適用効果を理解しておくことはアーキテ...

05.インフォメーション

ATG Web Commerce と Coherence の関係

先日、オラクルの eコマース製品の最新版の発表がありました。ここでは、ATG Web Commerce(以下、ATG)というEコマース・パッケージもアナウンスされていますが、このATGには、Coherence と連携する機能がすでに備わっています。さすが、今どきのEコマース・システムは柔軟にスケールするしくみがあるのです。 Eコマースで利用するデータを保持する広大なキャッシュ領域として(Repository Integration) 複数データセンターを横断可能なセッション保持領域として(Coherence*Web Integration) ATG を使ったホスティング・サービスを提供している AT&T では、Coherence を用いたデータセンター横断のセッション・レプリケーションを実際にやっているそうです。 Oracle OpenWorld 2012 SF 講演資料AT&T Active/Active ATG eCommerce Solution 性能や可用性、リソース効率化のために Coherence を内部的に利用するクラウド・サービスは、実は他にもいくつか存在します。サービスで差別化するクラウドのインフラとして重要な役割を今も担っているのです。 参考ホワイトペーパー: Architecting Oracle ATG Web Commerce for  Maximum Availability(英語)

先日、オラクルの eコマース製品の最新版の発表がありました。ここでは、ATG Web Commerce(以下、ATG)というEコマース・パッケージもアナウンスされていますが、このATGには、Coherence と連携する機能がすでに備わっています。さすが、今どきのEコマース・システムは柔軟にスケールするしくみがあるのです。 Eコマースで利用するデータを保持する広大なキャッシュ領域として(Reposit...

05.インフォメーション

Coherence on Exalogic、メルボルン大学での取り組み

世界中で開催されている Coherence SIG(Special Interest Group)。主に、北米(NY、SF)およびロンドン開催がメインですが、次はオーストラリアで開催されます。その一番の理由は、注目すべき事例セッションを開催できるから。なんと、Coherence on Exalogic の事例です。すごい。2012/10/18 開催です。 2012/10/18 Coherence SIG at Melbourne, Australia セッション: Case Study - Using Coherence and Exalogic to Provide a High-Performance, Reliable and Scalable Data-Tier(概要部分翻訳)Pankaj(講師)より、次のことをご紹介します。 - メルボルン大学(UoM)におけるCoherenceの利用ケース- Exalogic環境でのデプロイ- 超高速・高信頼性・スケーラブルなデータ層の実現 これによって UoMのアプリケーション・データアクセス要件に対する高いサービス品質の確保、アプリケーション性能ピーク時のみごとなハンドリングがもたらされています。

世界中で開催されている Coherence SIG(Special Interest Group)。主に、北米(NY、SF)およびロンドン開催がメインですが、次はオーストラリアで開催されます。その一番の理由は、注目すべき事例セッションを開催できるから。なんと、Coherence on Exalogic の事例です。すごい。2012/10/18 開催です。 2012/10/18 Coherence...

05.インフォメーション

Eコマース/B2Cサービスでの活用

変動が激しいアクセスに対して、サービスレベルをキープするには? ネットビジネスにとって、一定のレスポンスタイムをキープすることは、顧客サービス品質の観点で非常に重要な指標です。その一方で、アクセス増加率の予測 は非常に難しいのが現実。特に一般消費者向けのサイトは、その傾向や需要予測を図ることが容易ではありません。今後のアクセス/利用の伸びに対する正しい 予測は本当に可能なのでしょうか? 特に、一般消費者の中でも予測が難しいネットユーザー動向を正確に見抜き、今後数年のビジネスの伸びに最適なITインフラ(ハードウェア/CPU/メモ リ)を見積もることは現実的なのでしょうか? あたるかどうかわからないサービス、どれだけのHWリソースが適切なのか? 既存のインターネットサービスの今後の予測よりも、新規サービスに対する予測はさらに難しい問題です。ちょっとしたことで想定を超えるアクセスの集中が起 こったり、逆に、期待を裏切るほどにページビューが伸びないということも珍しくありません。何があたるのか、いつまであたるのか、どのくらいあたるのか。 十二分に慎重に予測した上で、その最大アクセス予測値を想定したITインフラの準備が必要となりますが、それによって、サービス開始の初期コストは必要以 上に膨れ上がっています。 不確かな予測による精度の低いインフラ・コストの見積もり 突発的なアクセス増加への対応 人気に陰りの見えるサービスの余剰ITインフラの保守コスト 成功したサービス同士の相乗効果を狙え! すでに安定した成功を収めているサービスをいくつか提供している企業は、そのサービス同士を連携させることで相乗効果を計るという施策を当然考えます。た とえば、いくつものブランドを持つ企業では、そのブランドを超えたショッピングカートの共用を検討し、異なる業種のサービスを抱える企業では、共通のポイント・サービスの提供といったことによって、相乗的な購入意欲を見出すことができるかもしれません。しかし、それぞれのサービスは、あたるかあたらないか、不明確な状況で個別にそれぞれの方針で構築されたため、連携を想定したつくりになっていません。サービスを横断する超高速の情報共有はどうやって実現するのでしょうか? ネットサービスITインフラの最適化のために オンデマンドなサーバーの拡張、サービスを横断する連携に対応すべく、大手企業のショッピングサイトが採用した答えとは? それはなぜ解となりうるのか? オラクルによる解決の道 増加するリクエストに対するシンプルな解答は? ポイントは “分散” と “共有” 分散と共有。一見、正反対に見えるこの言葉がうまく融合すると、非常に強力な武器となります。発想はいたってシンプル。コモディティ・サーバーと呼ばれる汎用の中級クラスのPC/ブレード・サーバーは、今や非常に強力な処理能力を持っています。そのコモディティ・サーバーを活用して大量のリクエストに対する処理を"分散"処理させます。一方で、システム全体としての一貫性や保全性を担保するために、各サーバーのデータを互いに"共有"可能にします。ただし、そのデータ共有を高速にするために、メモリ間通信を利用します。このサーバー間を横断するメモリ・データ共有の仕組みをOracle Coherence が提供します。サーバー間でメモリ・データが共有できることで、サーバーの追加が、単に処理能力の向上につながります。サーバー台数に比例した性能の拡張性(リニアなスケーラビリティ)が確保されることによって、ビジネス規模の拡張に応じてサーバーを順次追加するというコスト的に無駄の少ないシステム増強が可能になります。 解決策を動画で分かりやすく解説!- その1 解決策を動画で分かりやすく解説!- その2 応用編: 個別サイロ型のサービス基盤を透過的に論理統合 メモリ間通信によるデータ共有という利点を応用し、あるグローバル企業では、個別サイロ化されたサイトを論理統合することで相乗効果を見出しています。その企業は、複数の販売ブランドを持っていました(オンラインストア、チケットサイト、掲示板、旅行サイト)。そのそれぞれに構築されていた販売サイトの相乗効果のために Oracle Coherence を導入。各サイトはJavaアプリケーション・サーバーの種類も異なる状況でしたが、メモリ間通信を利用したユーザー情報の共有によって、利用者は、ショッピングカートをそれぞれの販売サイトを横断して利用し、まとめて決済することが可能になったのです。 サービスレベルを保障するために そもそも、インターネット・サービスでは以下の課題の克服が必須です ストレスのない応答時間の維持 ユーザー・データの信頼性 24時間365日の可用性 システム規模が大きくなればなるほど上記要件への要求レベルは高くなり、一方で、作業コストや運用コストとして大きく跳ね返ってきます。Oracle Coherence は、こうした要件にも一役買います。 1. 最適化されたメモリ間通信 独自プロトコルでチューニング可能なメモリ間通信によって、アプリケーション・サーバー固有のクラスタリング機能を凌駕するリニアなスケーラビリティを実現します。一方で、運用コストに大きな影響を与えません。 2. 共有メモリ領域における暗黙的バックアップ メモリ・データのバックアップは別サーバーに保持されます。コモディティ・サーバーで課題となるハードウェアの可用性の問題に対し、障害がおきても対処可能な状態を作り出します。 3. サーバー追加/減少の自動検知と透過的なフェールオーバー サーバーの追加や障害におけるノードダウンに対しても、システム全体としてのデータの一貫性を維持しながら、その影響を上位アプリケーションに与えません。したがって、障害時の自動フェールオーバーや、アクセス集中時の緊急のサーバー追加を可能にします。こうした機能は、初期のサービスイン時の容量計画が正確でなくても対処可能だということを意味します。最低限の小規模で開始し、必要に応じてオンデマンドでサーバー追加をすればよいからです。

変動が激しいアクセスに対して、サービスレベルをキープするには? ネットビジネスにとって、一定のレスポンスタイムをキープすることは、顧客サービス品質の観点で非常に重要な指標です。その一方で、アクセス増加率の予測 は非常に難しいのが現実。特に一般消費者向けのサイトは、その傾向や需要予測を図ることが容易ではありません。今後のアクセス/利用の伸びに対する正しい 予測は本当に可能なのでしょうか? 特に、一般消費...

05.インフォメーション

金融機関での利用

次の日の朝までには解析結果が必要 増加する取引量。肥大するデータ。アナリストやトレーダーからは、確実な情報を決まった時刻までに要求されます。これまでの取引量の成長率を考えれば、どうにか期限を守って、計算・分析の結果を情報として提供できていました。しかし... 市場に影響する情報 パラメータの多様化 グローバル競争の激化 証券取引所システムの強化 こうした要因によって、計算・分析の対象となるデータは加速度的に増えています。また、分析精度への高いリクエストは、より長いスパンの過去市場データを 包含した分析やシミュレーションを必要としています。日本国内の取引にとどまることなく、ニューヨークやロンドンといった取引のグローバル化がもっと進めば、「次の日の朝」という期限すらなくなるかもしれません。分析・計算結果が必要な期限までに利用できなければ、そのまま取引結果に影響します。大きな金額を左右する、その判断材料となる情報の精度をキープしたままグローバルで競争力のある取引をするには、どうしたらよいのでしょう? 取引処理自体にも限界が... そもそも、日々のオンライン取引処理に対するスピード化も深刻です。人が介在しないアルゴリズム取引が浸透すれば、そのスピードへの要求は比類ないものとなります。 そのスピード処理のレベルを、今後の取引量の増加に関係なく維持することができなければ、ユーザーの取引結果に多大な影響を与えかねません。システムを提供する側としてユーザーに対して保障すべきサービスレベルはスピードだけではありません。突然の市場変動や投資家の反応によって生じる突発的な大量の注文に対して、「市場の変化で予想外だった」という言い訳では済まないでしょう。オンデマンドに拡張して応えるという要件が求められます。 先行する欧米企業が出した答えは? 大量の取引を超高速、かつ、高い信頼性で処理するという高度な要求に答えるには、どうしたらよいのでしょうか? 欧米の金融機関が採用しているアーキテクチャは? そしてそこで使われているソフトウェアとは? オラクルによる解決の道 超高速システムの構築は、やはり高コストなのか? 「時間を制する = 超高速処理」 では、超高速処理をどうやって実現するのか。超高速処理のためには、インメモリでの処理は必然。しかし、インメモリ処理の問題は、データ量の上限があること。その上限をぎりぎりまで使うべく大型のハードウェアを導入し、信頼性/可用性(HA)のためにアクティブ-バックアップの構成をとるという従来の方式では、高コストな上に、障害時に少なからずダウンタイムを生じてしまいます。また、メモリで取り扱うデータの上限に到達すると物理ディスク上に退避させる などの対策が必要となり、処理スピードを低下させる要因となります。 解決策を動画で分かりやすく解説! 上限のないインメモリ処理と24時間365日の可用性を両立し、サービスレベルを維持し続けるアーキテクチャをコスト効果的に実現する。その答えは、メモリグリッドという仕組みにあります。数年前から有効性が期待されたグリッド・コンピューティング。その発展形として今や多くの先進企業で利用されているメモリグリッド製品としてオラクルが提供するのが Oracle Coherence です。 欧米の金融機関が採用する、その理由とは? 1. 大量データを複数の低コストPC/ブレードで分散配置 Oracle Coherence を利用することで異なるハードウェアのメモリ・データを仮想的に統合・共有化。一台のハードウェアに搭載されているメモリ上限を超えるデータのインメモリ保持が可能になります。 2. データのそばに処理を置く、という発想 データを分散化するだけでは処理の高速化にはなりません。分散配置した各ハードウェアのメモリだけでなく、CPUを活用してデータ操作処理自体も分散化。だから、データ量の増加が起こっても、処理時間を低下させることがありません。 3. 拡張の影響を上位アプリケーションに与えないアーキテクチャ 上位アプリケーションからは、ハードウェアの物理位置を意識せずにデータグリッドで保持されるデータにアクセスできます。したがって、データグリッドの ノードが増えても、万が一の障害がおきてノードダウンが起こっても、上位のアプリケーションに大きな影響を与えることがありません。

次の日の朝までには解析結果が必要 増加する取引量。肥大するデータ。 アナリストやトレーダーからは、確実な情報を決まった時刻までに要求されます。これまでの取引量の成長率を考えれば、どうにか期限を守って、計算・分析の結果を情報として提供できていました。しかし... 市場に影響する情報 パラメータの多様化 グローバル競争の激化 証券取引所システムの強化 こうした要因によって、計算・分析の対象となるデータは加速度的に増...

05.インフォメーション

統合データサービスとしての利用

さまざまな個別システムで管理される情報 企業の組織体制や業務の区切りに依存して個別化されたシステム。しかし、さまざまな理由から、それを横断した一つの統合情報としての活用が迫られています。さらに、こうした情報は、統合が必要なだけではありません。たとえば、次のような要件では、高速処理が必要です。 不確かな予測による精度の低いインフラ・コストの見積もり 資材調達記録・製造記録・ロット情報・出荷データを横断するトレースの必要性リコールなどのケースでは情報取得と精査に一刻を争う 多様化する販売チャネル/顧客サービス 突発的なアクセス増加への対応 散在化された顧客データを統合した顧客視点の情報/サービス提供の高速化顧客リクエストへの迅速な応答処理 = 顧客満足度向上 個別に構築されたシステムは、そのアーキテクチャもデータ構造も異なります。これらそれぞれのデータにアクセスする仕組みを用意し、その都度アクセスするという形では高速に検索したいという要件に応えることは難しく、開発コスト、検索性能、可用性などの問題に直面します。 理想的なのは、すべてのデータを集約するマスターデータを構築することです。そして、個々のシステムが、最終的にはその統合マスターデータを参照する形にすることです。しかし、状況によっては物理的なデータ統合が不可能なケースもあります。 たとえば・・・ グループ企業、買収/合併企業を横断する販売戦略 個別に管理されているデータ(商品、顧客など)を統合したビューをつくることで、効果的な販売戦略を練りたい。 パートナリング企業の商品情報を組み入れた統合検索/情報提供 散在化された顧客データを協業体制を確立した企業の商品を自社製品と区別なく扱い、顧客への販売機会を拡大したい スピードと柔軟性が要求される統合データサービス。それを実現している企業がとった策とは? オラクルによる解決の道 軽快なデータサービスの実現は、可能なのか? 散在するデータを集約して一つに見せる - それを効率的に行うためには、アプリケーション側から利用しやすい形でキャッシュしておくことが一番簡単な解決策になります。ただし、以下の要件を満たせることが必須条件となります。 メモリ領域を上限なく拡張可能 データ量が膨大になっても性能劣化を起こさない 定期的なデータ更新に対応可能 分散型データグリッド・テクノロジーなら、その要望に応えられます。 Why? Coherence が可能にするインメモリ型オブジェクトストレージ ノード追加によってメモリ領域を拡大可能 複数ノードで構成されるCoherenceクラスタ全体で一つの共有メモリを構成。ノード追加でメモリ領域を拡大できるため、取扱製品の追加などのデータ量増加に容易に対応できます。 ノード追加で得たCPUリソースを活用 データグリッドの各ノードは自ノード内のデータのみを自身のCPUパワーによって処理。処理のリクエスト側は各ノード処理の集約された結果を取得します。ノードの追加はメモリ領域の追加であると同時に処理能力の追加にもなります。 データソースから定期的にデータ読み込み可能 指定されたデータの有効期限に近づくと自動で再読み込みするよう設定できます。これによって、パートナー企業内にあるような外部データソースからも定期的に最新データを読み込んでおくことが可能になります。 このようなデータオブジェクトのストレージ層を挟むことにより、データソース側の性能に引きづらてしまうことがなくなります。極端なケースでは、データベースの障害にかかわらず、上位アプリケーションの稼動を継続できたという報告さえもあります(関連ホワイトペーパー参照)。 応用編:レガシーモダナイゼーションに向けて この発展形として、レガシーシステムの段階的なオープン化のステップに踏み出すこともできます。 1.データグリッドによってレガシーシステムのデータをキャッシュ レガシーシステムの老朽化したマシン環境にひきづられることなく蓄積��れたデータを活用可能。 2.キャッシュ・データ上にアプリケーションを新規構築 レガシーシステムと平行して新システムを運用しながら段階的に新システムに移行可能。 3.レガシーのデータストア(データベース)をリプレース データグリッドのデータソース連携機能により、蓄積されたデータを新データベースに格納可能。 「大幅なシステム改編をしても、メインフレームのしがらみから脱却したい」そんな思いをもつ企業にとって、このようなアプローチは一つの選択肢となります。

さまざまな個別システムで管理される情報 企業の組織体制や業務の区切りに依存して個別化されたシステム。しかし、さまざまな理由から、それを横断した一つの統合情報としての活用が迫られています。さらに、こうした情報は、統合が必要なだけではありません。たとえば、次のような要件では、高速処理が必要です。 不確かな予測による精度の低いインフラ・コストの見積もり 資材調達記録・製造記録・ロット情報・出荷データを横断する...

05.インフォメーション

計算処理での活用

データベースやデータウェアハウスに格納する前処理に対する課題 メインフレームやオフコンといった大型計算機による大量データのバッチ処理は確かに実績があります。でも、近年のIT技術者は、こうしたハードウェアの保守もその上で動くプログラムの記述もできなくなってきています。最近稼動された新オンライン処理システムのように Java や .NET で開発されていれば、保守も追加開発もできる人材の手配が可能なのに...レガシーの仕組みを使ってしまうと、そのメンテナンスが属人的になり、それゆえ高コストな運用になります。しかしいまだに、新しいプロジェクトでも、バッチ処理は実績あるCOBOLの提案があがってきます。本当に Java でバッチ処理の構築は難しいのでしょうか?オンラインもバッチもJavaで統一開発できれば、次のようなメリットが得られるはずです。 開発/テストが容易充実した無償の開発環境で作業コストも低減 オンライン処理とバッチ処理で共通の言語を使った実装が可能保守の複雑さを排除可能 ハードウェアをコモディティ・サーバーに統一可能企業全体としてのHWリソースの再活用/有効利用を促進 技術者のスキルを統一かつ集約可能教育コストを最適化 ベンダー依存性の極小化ちょっとした修正やカスタマイズも手軽に実施可能 一方で、まったく不安がないわけではありません。 Java によるバッチ処理が難しいとされる理由 バッチ処理では、大量データ処理を決められた期限までに実施することが必要です。定期的にジョブが開始され、万が一ジョブが失敗したら、それを適切に再実行するというジョブ管理も ジョブとしての実行スケジュール管理やその完了チェックは、市販の運用管理製品を利用するという手が使えます。しかし、決められた期限までに完了させるためには、大量データを保持可能なメモリ量の搭載、汎用機で用意されているような並列処理機能、ハードウェア自体の対障害性など、どうしてもハードウェアに依存せざるを得ない能力の壁があります。 スーパーコンピュータに匹敵するアーキテクチャの中核は? 一方で、バッチ処理よりもさらにハードウェア能力が要求される、従来スーパーコンピュータを利用していたような大量計算処理(HPC:ハイパフォーマンス・コンピューティング)の分野では、今、グリッド型アーキテクチャを取り入れる動きが目立ってきています。そして、そこでJavaが活用されている例も珍しくありません。 何がそれを可能にするのでしょう? オラクルによる解決の道 「Java + コモディティ・サーバー」によるグリッド型計算処理システム コモディティ・サーバーで大型計算機に匹敵する処理を可能にするために いまやコモディティ・サーバーは大型計算機に匹敵する性能を持っています。CPU性能は強力ですし、メモリも十分な量の搭載が可能になってきました。事実、世界のスーパーコンピュータの性能番付であるTOP500に掲載されている計算機のうちの8割強はx86系CPUを搭載したクラスタ型のアーキテクチャ構成なのです。 コモディティ・サーバーでバッチ・システムを組む際にもっとも問題となるのは信頼性です。大型計算機/汎用機に比べると高い故障率、低コストゆえの多重化措置の欠如といった点をどうやって克服するのでしょう?答えはデータグリッドによる逆転の発想です。 従来型: 高性能ハードウェアによる故障/障害率の最小化アプローチ 故障の可能性を高度なハードウェアで極限まで回避しようとする従来型のアプローチ。稼働率は高まる。しかし、故障/障害率がゼロになるわけではないので待機系システムの準備が必要。必然的にコストは高くなる。 データグリッド: 多数のコモディティ・サーバーによるグリッド型アプローチ 高性能なCPU能力を活用しつつ、データグリッドによってすべてのサーバーのメモリ・データを共有化。故障/障害の可能性を考慮し、その対策として、すべてのサーバーで代替処理を継続可能な設計。万が一、サーバー障害がおこっても他のサーバーが処理を継続できるため、途中までの処理が無駄にならない。 このデータグリッドの仕組みは、同時にJavaのウィークポイントをも克服します。 複数のJVMで一つの論理的なデータ領域を構成 全体として大量データをインメモリ処理可能かつ、JVM一つ一つのガベージ・コレクションの影響を最小化 メモリに載りきれないデータの中間ファイルへの書き出しが不要、処理完了までの時間を短縮化 並行処理プログラミングを簡素化 Oracle Coherence のパラレル実行フレームワークを活用することで、容易に並行処理を実現可能(開発/保守コストの低減) 開発/保守コストの低減 処理時間短縮化施策が容易 ノードの追加によって単純に一台あたりのデータ処理を減少化可能 処理スピード向上

データベースやデータウェアハウスに格納する前処理に対する課題 メインフレームやオフコンといった大型計算機による大量データのバッチ処理は確かに実績があります。でも、近年のIT技術者は、こうしたハードウェアの保守もその上で動くプログラムの記述もできなくなってきています。最近稼動された新オンライン処理システムのように Java や...

03.導入事例

導入事例|Eコマース/B2Cサービス

Eコマース/B2Cサービス 金融機関/関連サービス 通信サービス IoT/M2M Eコマース/B2Cサービス 株式会社NTTぷらら 「ひかりTV オンラインシステム」 Oracle Coherence を新たに活用したことでユーザー数の増加やサービス拡充に向けたスケールアウト性が強化され、バックエンドを Oracle Exadata に代えることでデータの永続性とバックオフィス処理の円滑化が実現し、今後新たに登場するサービスやビジネスに安定して対応できるようになりました。 詳細を見る 詳細を見る 株式会社NTTぷらら 「ひかりTV 課金処理」 処理時間の短縮は今後のお客さまへのサービス品質向上、そしてわれわれのビジネス戦略にも好影響をもたらしてくれることは確実です。また会員の増加に対してもスケールアウトの方法で対応できるのでコスト面でも助かります。 詳細を見る プレスリリース Gartner Japan レポートを見る 全日本空輸株式会社 「ANA SKY WEB」 従来のシステムと比較して空席照会機能の処理時間を約10分の1に短縮。顧客サービスのさらなる拡充も実現。 詳細を見る 取材記事を見る(日経BP) 取材記事を見る(IT Media) IDC Japan レポートを見る 日本生活協同組合連合会 「CO-OP WEB STANDARD」 Oracle CoherenceでWebお買い物サイトを刷新し、100万人を超える組合員が利用できる日本最大クラスのECサイトとなりました。Oracle Coherenceによって処理性能が全般的に向上したことは大きな成果となっています。100万人を超えるインターネット会員に対応できるようになり、サービスを止めずに増強できるので、安心して運用できるようになりました。 詳細を見る 関連サイトを見る プレスリリース 楽天株式会社 「楽天市場」 Oracle Coherenceを活用してビジネスの成長に不可欠な高い拡張性、可用性、柔軟性を備えたシステム構築を推進しました。トランザクションの増大に応じて安価なIAサーバーでスケールアウトを可能にし、データベースを意識しないアプリケーション開発、アジリティの高い開発スタイルを実現しました。 詳細を見る Gartner Japan レポートを見る 株式会社ヨドバシカメラ 「ヨドバシ・ドット・コム」 Oracle Coherenceを活用して3カ月でECサイトを刷新。レスポンス速度と耐障害性を大幅に高めつつ、ハードウェアおよび運用管理コストも削減しました。Oracle Consultingの支援のおかげでOracle Coherenceの短期導入に成功し、ECサイトのレスポンス速度が大幅に向上しました。システム運用に必要なリソースを低減できたことでサーバーの数が減り、運用管理の効率化も実現しています。 詳細を見る プレスリリース J.Crew 米国の小売業大手、J.CrewにおけるEコマースでの導入事例です。『Coherenceは、キャパシティの急成長に対応できるソリューションです。』(1分51秒) 視聴する

Eコマース/B2Cサービス 金融機関/関連サービス 通信サービス IoT/M2M Eコマース/B2Cサービス 株式会社NTTぷらら 「ひかりTV オンラインシステム」 Oracle Coherence を新たに活用したことでユーザー数の増加やサービス拡充に向けたスケールアウト性が強化され、バックエンドを Oracle...

03.導入事例

導入事例|金融および関連サービス

Eコマース/B2Cサービス 金融機関/関連サービス 通信サービス IoT/M2M 金融機関/関連サービス 株式会社三菱東京UFJ銀行 現在の為替取引において、超高速のアルゴリズム・トレーディングが多くの企業で実施されています。そのため新しい為替IBシステムでは、更新頻度の高い大量のデータを、高信頼性のもとに処理できる仕組みが必要でした。また最低でも10年間は利用できるアーキテクチャであることも必要でした。アプリケーション自体は、RDBをベースとして構築することも可能ですが、パフォーマンスで苦労することは避けたかったので、将来性を考えて高速な配信基盤の実現を検討しました。 プレスリリース 詳細を見る 株式会社インターネットイニシアティブ 「IIJ Raptorサービス」 柔軟性、パフォーマンス、利便性を追求したオンラインブローカー(FX/証券/銀行)向けFXプラットフォーム「IIJ Raptor(ラプター)サービス」においてOracle Coherenceを採用し、従来比約9倍となる業界最高水準の約定スピードを実現しました。また、システムの拡張性と耐障害性も高めることができました。 プレスリリース 情報を見る ヒロセ通商株式会社 「LION FX」 Oracle Coherenceを活用したオンラインFXシステムを稼動。インメモリ・データグリッド技術により大規模トランザクションの高速処理を実現しています。Oracle Coherenceを導入することで、オンライン取引システムのトランザクション処理性能が大幅に向上しました。これにより、顧客中心のサービスを迅速に展開して行くことが可能となりました。 詳細を見る 情報を見る ワイジェイFX株式会社 Oracle Coherence導入によって、ミリ秒レベルの高速処理を必要とする性能要件にも十分対応可能な基盤が実現されました。今後もOracle Coherenceのフレキシブルな拡張性を活かして、強いシステムを構築していく予定です。 情報を見る FXプライム株式会社 Oracle Coherenceを利用することで、外国為替相場の変動が激しい状況下でも高いレベルのリアルタイム処理が可能になりました。短期で実装できて、容易に拡張できるインメモリの仕組みなので、急激なトランザクションの増加にも柔軟に対応できそうです。 情報を見る エース交易株式会社 「エース365」 新取引システムは上限のないインメモリ処理と24時間365日の可用性を両立する仕組みである、オラクル社のインメモリ・データグリット製品「Oracle Coherence」を採用。耐障害性の向上と膨大な情報量の超高速処理を実現しました。 プレスリリース 情報を見る 岡安商事株式会社 「為替ライフ」 上限のないインメモリ処理と24時間365日の可用性を両立する仕組みであるオラクル社のデータグリッド製品である、Oracle Coherence の導入によって超高速レスポンスを実現し、ストレスフリーでスムーズなお取引を可能にしました。また、スキャルピング派にも満足の反応速度となっています。 情報を見る 楽天証券株式会社 「フル板情報配信システム」 Oracle Coherenceを活用したフル板情報配信システムを構築。東証arrowheadの高速配信に対応するパフォーマンスと可用性を実現しています。機関投資家と同じように、個人投資家が株式の全銘柄の情報をリアルタイムですべて参照でき、その場で発注可能な「フル板」サービスは楽天証券だけの機能です。Oracle Coherenceを採用することで、パフォーマンスと可用性の高いフル板情報配信システムを構築できました。 詳細を見る 視聴する プレスリリース 三井住友海上あいおい生命保険/MS&ADシステムズ 契約者情報管理システムにおける契約件数・契約者情報の一層の拡充に対応するために、「Oracle WebLogic Suite」を採用しました。これにより、オラクルの高性能アプリケーション・サーバー最新版「Oracle WebLogic Server 12c」と、同時並行処理能力を増強し、メモリ容量拡張を可能にするインメモリ・データグリッド製品「Oracle Coherence」をアプリケーション実行基盤として導入し、レスポンス・タイムの短縮化と合わせて、耐障害性も向上させています。 プレスリリース ワコビア銀行 米国の大手銀行、ワコビア銀行の法人・投資部門における導入事例です。『巨大なバッチ処理ともいえるリスク計算処理はグリッド型アーキテクチャで劇的に高速化されました。』(2分24秒) 視聴する

Eコマース/B2Cサービス 金融機関/関連サービス 通信サービス IoT/M2M 金融機関/関連サービス 株式会社三菱東京UFJ銀行 現在の為替取引において、超高速のアルゴリズム・トレーディングが多くの企業で実施されています。そのため新しい為替IBシステムでは、更新頻度の高い大量のデータを、高信頼性のもとに処理できる仕組みが必要でした。また最低でも10年間は利用できるアーキテクチャであることも必要でした。アプ...

03.導入事例

導入事例|通信サービス

Eコマース/B2Cサービス 金融機関/関連サービス 通信サービス IoT/M2M 通信サービス NTTコミュニケーションズ株式会社 「ネットワークのリアルタイム可視化・予兆監視」 「Oracle Event Processing」と「Oracle Coherence」を組み合わせて活用し、ネットワークを流れる毎秒140万件のパケットを受信してリアルタイムに統計を行うことで、異常状況の早期検知を実現 プレスリリース 記事を見る(ZDNet) Oracle Open World 2013 San Francisco セッション 株式会社NTTドコモ 「ビッグデータ・リアルタイム処理」 「Oracle Event Processing」と「Oracle Coherence」を組み合わせて活用することで1秒間に70万件のトラフィックのインメモリ処理を実現 プレスリリース 取材記事を見る(Enterprise Zine) ・「トラブルらしいトラブルはまったく起きていない。ここまで良い結果になるとは正直思わなかった。」 取材記事を見る(クラウドWatch) ・「データアクセスの高速化によるリアルタイム処理の実現と、可用性と一貫性を担保する信頼性があるデートストアの構築に威力を発揮している」 ソフトバンクモバイル株式会社 「Chronos Core」 そしてこれらを支えるリアルタイムコンピューティングプラットフォームがChronos Coreだ。Exadataとインメモリデータグリッド「Oracle Coherence」をベースに業務システム、実績分析などを搭載する。 取材記事を見る(ZDNet) 「インターネット/メール接続情報システム」 インターネットおよびメールの接続情報システムに、オラクルのインメモリ・データグリッド製品 「Oracle Coherence」の採用を決定 プレスリリース 株式会社UCOM 「光電話」 従来のシステム構成と比較して、導入コストを半減する一方、加入者の契約状況や位置情報を確認・登録する性能が約2倍に改善しました。 取材記事を見る(Business Network) ・「Javaのスキルに頼った設計と実装で必要な条件を実現できる」

Eコマース/B2Cサービス 金融機関/関連サービス 通信サービス IoT/M2M 通信サービス NTTコミュニケーションズ株式会社 「ネットワークのリアルタイム可視化・予兆監視」 「Oracle Event Processing」と「Oracle Coherence」を組み合わせて活用し、ネットワークを流れる毎秒140万件のパケットを受信してリアルタイムに統計を行うことで、異常状況の早期検知を実現 プレスリリ...

02.ダウンロード

デモ動画|ホワイトペーパー関連

デモ動画 ホワイトペーパー、製品カタログ デモ動画 デモ動画:「拠点間レプリケーション」 地理的に離れた拠点のメモリグリッドをWAN経由で双方向にレプリケーションさせることができます。* お互いの更新内容を伝播* 競合を解決して更新内容を受諾デモンストレーションを用いて解説します(3分: 日本語字幕) Coherence 拠点間レプリケーション 動画で解説:「ITシステムが直面する課題」 従来型のアーキテクチャと比べて、複数サーバーを有効活用したインメモリ・データグリッドがどう違うのか?その効果とは?分かりやすく解説します。 詳細を見る デモ動画:「データグリッドによるビジネスの継続性」 ECサイトにおいて、継続的に大量の注文を受けている際にバックエンドのデータベースに障害が発生した場合* 受注状況に起こる影響は?* DBが復旧時の状況は?画面イメージを用いて解説します(1分) 詳細を見る ホワイトペーパー、製品カタログ 予測可能なWebスケーラビリティの実現とその具体的メリット 分散インメモリ・アーキテクチャによって、Webベースの顧客向けサービスにどのような効果がもたらされるのか。実顧客の体験に基づいてまとめられたホワイトペーパーで、活用に関する様々なヒントになります。 詳細を見る 応答性の向上による顧客ロイヤリティの強化 応答性の向上による顧客ロイヤリティの強化 ECサイトにおいては、堅牢なテクノロジーの欠如により、顧客が大きな不利益を被り、結果としてビジネス上の巨大な損失が発生するリスクと隣り合わせです。テクノロジー上の課題と解決策を、4社の事例とともにご紹介します。オンライン・ビジネスに関わるシステム担当者の方、必見です。(全17ページ) * Eコマースが直面するデータ管理上の課題と解決策 * 4つのケース・スタディ * ミッションクリティカル: コストは度外視できるか? * Oracle Coherence:製品とテクノロジーの概要 他 ダウンロード 「Oracle Coherence」製品カタログ [製品カタログ] Oracle Coherence ダウンロード Javaアプリケーションの予測可能なスケーラビリティ、および継続的な可用性の実現 競合他社に勝つためのに、どのような領域で何をかんがえているのか。いくつか例を挙げて紹介します。 ダウンロード クラスタ・キャッシュおよびデータグリッド・ソリューションの投資対効果 過去のお客様の例に基づいて、メモリグリッドのROIについて紹介しています。 ダウンロード データ・グリッドとサービス指向アーキテクチャ サービス思考アーキテクチャ(SOA)とメモリグリッドの関係性とは? ダウンロード 不可能への挑戦: アプリケーションの無限の拡張性 クラウドやスマートフォンなどの広がりで、ますます重視されているスケーラビリティに着目した内容になっています。 ダウンロード

デモ動画 ホワイトペーパー、製品カタログ デモ動画 デモ動画:「拠点間レプリケーション」 地理的に離れた拠点のメモリグリッドをWAN経由で双方向にレプリケーションさせることができます。 * お互いの更新内容を伝播 * 競合を解決して更新内容を受諾 デモンストレーションを用いて解説します(3分: 日本語字幕) Coherence 拠点間レプリケーション 動画で解説:「ITシステムが直面する課題」 従来型のアーキテク...

01.特集・コラム

【技術コラム 第3回】 インメモリ・データグリッドの適用パターン:基本と応用 その2

インメモリ・データ・グリッドの応用アーキテクチャ 上に紹介した2つのパターンは、「拡張可能なメモリ領域」というインメモリ・データ・グリッドの基本的な特性を生かしたシンプルな適用形態である。インメモリ・データ・グリッドは、これらの形態にとどまらず、データ・ソースとの連携機能や並列分散処理機能を活用して、さらに適用範囲を広げることができる。そうした応用パターンとして、次の4つを見てみよう。 パターン(3)スケールアウト可能な高速データ・ストアとして利用する パターン(4)データベース停止時にもシステムを止めずに運用する パターン(5)一連のデータ処理をインメモリで高速に処理する パターン(6)複数のデータ・ソースを仮想化する パターン(3)スケールアウト可能な高速データ・ストアとして利用する 従来型のアーキテクチャでは、大量のトランザクションを処理する場合、データベースがボトルネックになりやすく、処理性能を高めるのが難しい。それに対して、インメモリ・データ・グリッドを用いたアーキテクチャでは、データをメモリ上に保持することで、高速かつスケールアウトが可能なデータ・アクセスを実現する。このアーキテクチャでは、データベースはデータの永続化先としてアーカイバの役割を果たし、インメモリ・データ・グリッドはデータ・ソース連携機能を使ってデータベースに同期もしくは非同期でデータを自動的に書き出す(次ページの図8)。アプリケーションからの書き出しを高速に処理したいときは非同期で、インメモリ・データと永続化されたデータの一貫性を常に保ちたい場合は同期で書き出すといった使い分けが可能だ。 パターン(4)データベース停止時にもシステムを止めずに運用する 従来型のアーキテクチャでは、データベースの停止はシステム全体の停止を意味していた。 一方、インメモリ・データ・グリッドでは、データ・ソース連携機能を非同期で使うことで、インメモリ・データ・グリッドをデータベースに対する更新データのバッファとして機能させ、データベース停止時にもシステムを止めずに運用できるようになる。システム全体を止める必要がなくなるので、計画停止時の停止時間の削減や運用手順の簡略化など、運用コストの面でも効果が期待できる。このアーキテクチャは、データベース側の信頼性が低いケース(例えば、オープンソースのデータベースを使う場合など)や、データベースの定期メンテナンスが頻繁に生じるようなケースでは特に有効だ。 パターン(5)一連のデータ処理をインメモリで高速に処理する これは高速なデータ・ストアとしての使い方と似ているが、この適用パターンがターゲットとするのは、複数のデータ処理が含まれる細かいトランザクションを大量に処理しなければならない場合である。例えば、証券取引のように、「注文の受け付け→マッチング→約定」といった具合に連続したデータ処理が含まれるトランザクション処理などだ。従来型のアーキテクチャでは、このようなトランザクションの処理性能は、データベースに対するアクセス性能に依存する。もしデータベース・アクセスがボトルネックになっていたとしたら、アプリケーション・サーバを拡張するだけでは、トランザクション処理性能を高めることはできない。一方、インメモリ・データ・グリッドを用いた場合は、これら一連のデータ処理を各ノード上で分散して並列に実行することが可能だ。すべての処理を一貫してメモリ上で行うため高速に処理ができ、また各ノードで分散して実行するので、ノードを増やして処理性能を上げることもできる(図9)。 パターン(6)複数のデータ・ソースを仮想化する 従来型のアーキテクチャでは、1つのアプリケーションで複数のデータ・ソースを扱う場合、アプリケーション開発者は対象となる各データ・ソースに合わせて実装を作成する必要がある。また、システム全体が複数のデータ・ソースと関連するため、1つのデータ・ソースで起きた障害の影響がシステム全体に波及しやすいという問題がある。一方、これはCoherenceの場合だが、メモリ上のデータを特定のデータ・ソースと関連づけて定義でき、データに応じて各データ・ソースと自動的に連携する機能が備わっている。この機能を使うことで、複数のデータ・ソースを束ねた"仮想統合データ・ソース"としてインメモリ・データ・グリッドを使うことが可能だ(図10)。このアーキテクチャにおいて、アプリケーションはデータ・グリッド層にアクセスすることだけを考えればよく、実装をシンプルにできる。加えて、データ・ソースで障害が起きたときはインメモリ・データ・グリッドがバッファの役割を果たすので、システムを止めずに連続稼働させることが可能となる。 以上、本パートでは、現在普及が進みつつあるインメモリ型のデータ管理方式と、その中でも特に最近注目を集めているインメモリ・データ・グリッドの概要、システム・アーキテクチャへの適用例を紹介した。データやトランザクションの増加は、今後も間違いなく続く。この課題に対して、サービス・レベルと耐障害性を担保していくうえで、インメモリ・データ・グリッドは1つの有効な策となる。コモディティ化したサーバの性能向上とメモリ価格の低下、ネットワーク環境の充実を背景に登場してきたこの方式は、コストに対する締め付けがより厳しくなった今だからこそ、検討すべきアーキテクチャだと言えるかもしれない。 前へ 1 2

インメモリ・データ・グリッドの応用アーキテクチャ 上に紹介した2つのパターンは、「拡張可能なメモリ領域」というインメモリ・データ・グリッドの基本的な特性を生かしたシンプルな適用形態である。インメモリ・データ・グリッドは、これらの形態にとどまらず、データ・ソースとの連携機能や並列分散処理機能を活用して、さらに適用範囲を広げることができる。そうした応用パターンとして、次の4つを見てみよう。 パターン(3)...

01.特集・コラム

【技術コラム 第3回】 インメモリ・データグリッドの適用パターン:基本と応用 その1

インメモリ・データ・グリッドの基本的な適用パターン ここまで、インメモリ・データ・グリッドの基本的な仕組みと付加機能を見てきたが、実際のシステムでは、これをどのように用いるのが効果的なのだろうか。以降では、いくつかの適用パターンを紹介していこう。インメモリ・データ・グリッドを使う場合、従来の3階層システムのアプリケーション・サーバとデータベース・サーバとの間に配置するのが典型的なアーキテクチャとなる。まずは従来型のシステム・アーキテクチャとインメモリ・データ・グリッドを用いた場合のアーキテクチャの比較を図5に示す。 インメモリ・データ・グリッドの基本的な考え方は、アプリケーション・サーバがメモリ上に持っていたデータをインメモリ・データ・グリッド層で保持するという、非常にシンプルなものだ。このアーキテクチャにより、アプリケーション・サーバ上で大量のデータを保持しなければならない場合に発生する課題を解決するのである。大量データを保持するパターンとしては、例えば次のようなものが考えられる。 パターン(1)大量のマスタ・データをキャッシュする パターン(2)大量のHTTPセッションを扱う まずはこの2つのパターンについて、従来型アーキテクチャとインメモリ・データ・グリッドを用いたアーキテクチャがどう違うのか、後者にどういったメリットがあるのかを説明する。 パターン(1)大量のマスタ・データをキャッシュする マスタ・データをキャッシュする主な目的は、データ・アクセスの高速化とデータベース処理の負荷低減である。これらの目的を果たすには、キャッシュできるデータの適用範囲を増やし、キャッシュ・ヒット率を高める必要がある。従来のアーキテクチャでは、単一のアプリケーション・サーバ・プロセス(JVMプロセス)のヒープ・メモリにマスタ情報をキャッシュするが、ガーベッジ・コレクション(GC)の影響を考えると、ヒープ・サイズを大きくするのは得策ではない。また、キャッシュ対象のマスタ・データが、将来どの程度増加するのかを設計段階で正確に予測しておく必要がある。従来型のアーキテクチャでは、想定したメモリ容量を超えるデータ増加に対処するのは難しく、あまりに増えすぎたときや予測がつかないときには、最OutOfMemoryErrorとなる。これに対して、インメモリ・データ・グリッドを用いた場合、従来型のアーキテクチャでは扱えなかった大量のマスタ・データ(ギガ・バイト規模のマスタ・データ)をインメモリで保持し、なおかつ将来のデータ増加に対してスケールアウトによって対応できるようになる(図6)また、従来型のアーキテクチャでは、各アプリケーション・サーバの起動時にデータの読み込み処理を実行する必要があるのに対し、インメモリ・データ・グリッドでは、データ・グリッド層に一度だけデータを読み込めばよい。その結果、アプリケーション・サーバの起動処理が軽くなり、サーバの障害復旧などが迅速に行えるようになる。 パターン(2)大量のHTTPセッションを扱う 大量のHTTPセッションが発生するケースとしては、例えば単純に同時セッション数が増えている状況ならば、セッションを長時間保持しておきたいときや、1つのセッションに大規模なオブジェクトを保持したいときなどが考えられる。従来型のアーキテクチャでは、セッション・データはアプリケーション・サーバが保持/管理するが、当然ヒープ・メモリを大きくとる必要が出てくる。また、存続期間が決まっているセッション・データは頻繁にGCの対象となるので、GCの発生頻度や発生時の停止時間は増大する。さらに、大半のアプリケーション・サーバのセッション・レプリケーションは、ノード数が増えるとレプリケーション処理の負荷が重くなって性能や拡張性に支障が出る(これを理由に、セッション・レプリケーションを避けている方もおられるだろう)。従来型のアーキテクチャで生じるこれらの課題は、インメモリ・データ・グリッド層でHTTPセッションを管理することによって解決できる(図7)。図7のアーキテクチャでは、アプリケーション・サーバのセッション管理のためにヒープ領域を適正化するとともに、GCの影響の軽減を図ることが可能だ。また、アプリケーション・サーバ側でのレプリケーション処理が不要になり、アプリケーション・サーバ層のスケールアウト性能が向上する。セッション・データの可用性と拡張性は、インメモリ・データ・グリッドで担保されるのである※3。 ※3 ただし、このパターンを適用するには、インメモリ・データ・グリッド製品にHTTPセッションの管理機能が備わっている必要がある。 第2回 1 2 次へ

インメモリ・データ・グリッドの基本的な適用パターン ここまで、インメモリ・データ・グリッドの基本的な仕組みと付加機能を見てきたが、実際のシステムでは、これをどのように用いるのが効果的なのだろうか。以降では、いくつかの適用パターンを紹介していこう。インメモリ・データ・グリッドを使う場合、従来の3階層システムのアプリケーション・サーバとデータベース・サーバとの間に配置するのが典型的なアーキテクチャとなる...

01.特集・コラム

【技術コラム 第2回】 インメモリ・データ・グリッドの基本的な仕組みと効果 その2

インメモリ・データ・グリッドが提供する付加機能 インメモリ・データ・グリッドは、核となるキャッシュ機能のほかにも、有用な付加機能を提供している。オラクルのOracle Coherenceを例にとり、そうした機能をいくつか見てみよう。 クエリ機能 通常、キャッシュとの間でのデータ入出力では、先にリスト2に示したようなput/getメソッドを使ってキー・アクセスを行う。だがこれでは、 RDBMSで言えばプライマリ・キーによる問い合わせしかできないのに等しい。そこで、インメモリ・データ・グリッド製品には、任意の属性値を条件にしてクエリを発行する機能が用意されている(リスト3。これは単純な例だが、条件を階層化して複雑な検索を行うことも可能)。なお、Coherenceの場合、リスト3のようなコードを実行すると、複数ノードでパラレルにクエリが発行される。また、クエリ性能を高めるためのインデックスの作成もサポートしている。 リスト3:データのクエリ // 「商品番号として100を持つ」という条件を設定Filter filter = new EqualsFilter("getProductId", 100);// 条件を付加して検索を実行Set orders = orderCache.entrySet(filter); イベント・リスナ機能 これは、キャッシュ・データが変更されたことをアプリケーションに対してイベントとして通知する機能だ。イベントの発生に応じてロジックを起動したり、変更を監査したりといったことに使える。これもJava開発者にはなじみ深いJavaのイベント・モデルのスタイルを採用しており、変更イベントを検知するリスナを作成し(リスト4)、それをキャッシュに登録するだけでよい(リスト5)。ちなみに、Coherenceの場合、リスナ・クラスの各メソッドに渡されるMapEventオブジェクトには、変更前後のデータが格納されており、メソッド内でそれらのデータを使うことができる。 リスト4:リスナ・クラスのコード // 注文データの変更イベントを受け取るリスナ・クラスpublic class ProcessOrderListener implements MapListener {   public void entryInserted(MapEvent event) { /* 処理を記述 */ }   public void entryUpdated(MapEvent event) {}   public void entryDeleted(MapEvent event) {}} リスト5:リスナの登録処理 orderCache.addMapListener(new ProcessOrderListener()); データ処理のパラレル実行機能 これは文字どおり、データの加工を並列(パラレル)に実行する機能だ。例えば、データベースに格納されたすべての注文データに対して「商品番号が100である注文の割引率を0.1にする」という処理を行うケースを考えてみよう。これをアプリケーション上で行う場合、条件に該当する注文データの読み込み、ループ処理による割引率の更新、データの再格納といった一連の処理を実行することになり、対象データが大量にある場合は処理時間も長くなる。データをデータベースで管理しているのなら、こうしたケースではストアド・プロシージャをデータベース上に定義して実行することで、データ転送処理を省き、アプリケーション側の処理負荷を下げるという手法をとるだろう。 Coherenceでは、それと同様の発想で、データ処理をアプリケーション側(クライアント側)ではなく、各キャッシュ・ノード上で実行する「Invocation」という機能を用意している(図4)。この機能を使うと、アプリケーション側ではデータの取得や更新したデータの再格納といった処理を行う必要がなくなり、またデータの更新処理も各キャッシュ・ノードでパラレルに実行される。そのため、大量のデータ処理を分散して効率的に実行することが可能だ。加えて、キャッシュ・ノードを増やせば自然に処理の並列度が上がるので、データ処理性能も拡張できる。 なお、データ更新や集計といった基本的な処理はCoherenceにあらかじめ用意されているが、それ以外に独自の処理を作ることも可能である。これを利用して、複数アプリケーションに共通のデータ操作処理を作ってキャッシュ側に配置しておけば、処理の効率化につながるとともに、インメモリ・データ・グリッド層を統合データ・サービスとしてプライベート・クラウドのように利用できる。 前へ 1 2 第3回

インメモリ・データ・グリッドが提供する付加機能 インメモリ・データ・グリッドは、核となるキャッシュ機能のほかにも、有用な付加機能を提供している。オラクルのOracle Coherenceを例にとり、そうした機能をいくつか見てみよう。 クエリ機能 通常、キャッシュとの間でのデータ入出力では、先にリスト2に示したようなput/getメソッドを使ってキー・アクセスを行う。だがこれでは、 RDBMSで言えばプライ...

01.特集・コラム

【技術コラム 第2回】 インメモリ・データ・グリッドの基本的な仕組みと効果 その1

インメモリ・データ・グリッドの基本的な仕組み まずは基本的な仕組みを説明しよう。インメモリ・データ・グリッドのコアとなる機能は、データをメモリ上で管理し、アプリケーションから利用可能な状態にすることだ。実際にどのようにしてデータをメモリ上に配置して管理するのかを、2つの代表的なキャッシュ形式「レプリケーション・キャッシュ」と「パーティション・キャッシュ」を例にとって解説する。 参照系に向いたレプリケーション・キャッシュ これは、先にインメモリ・キャッシュのレプリケーション型として説明したものと同じ仕組みだ。アプリケーションと同一のプロセス内にキャッシュ領域を構成し、キャッシュを持つ各ノード(以降、キャッシュ・ノードと呼ぶ)間ですべてのデータを複製して持ち、変更の伝播を行う(図1)。 1つのキャッシュ・ノードの視点で見たとき、各キャッシュはアプリケーションに対してローカルに構成されるため、読み込みの待ち時間は非常に短い。一方、書き込みに関しては、変更のレプリケーションを同期でやるか非同期でやるかによって性能が異なる。例えば、データの一貫性を考慮して同期でやる方法を選んだ場合、ノード間のレプリケーションが終わるまでアプリケーションからの書き込みは待機させられるので、その分だけ待ち時間は長くなる。 また、レプリケーションによる負荷にも注意すべきだろう。これには、変更を他のすべてのキャッシュ・ノードに送信するためのネットワーク負荷や、ネットワーク経由で受け取った変更データをデシリアライズするためのCPU負荷(レプリケート先のすべてのキャッシュ・ノードで発生)などがある。1回当たりの書き込みで生じる負荷だが、これは無視できるほど小さいと考えられる。しかし、例えばシステム全体で1,000件/秒程度の書き込みが発生するような場合は、単純に考えても1秒間当たりに1,000件のデータ更新がすべてのキャッシュ・ノードで発生するわけで、これによる負荷は相当なものになる。よって、レプリケーション・キャッシュは、主に更新が発生しない(つまり、ノード間でのデータ同期が不要な)参照用データの格納に使われることが多い。なお、レプリケーション・キャッシュでキャッシュできるデータ量は、1つのプロセスに割り当て可能なメモリ容量に依存するので、容量の上限に注意する必要がある。 大量データの処理を可能にするパーティション・キャッシュ 更新系には向かないというレプリケーション・キャッシュの欠点を解消したものが、次に紹介するパーティション・キャッシュだ。これはインメモリ・データ・グリッドの特徴を成すものでもあり、書き込みも含めた大量のデータ処理には欠かせない仕組みである。パーティション・キャッシュでは、事前に定義したパーティション・ロジックに従い、データを複数のキャッシュ・ノードに分割して配置する。また同時に、バックアップ・データをデータ本体(以降、これをプライマリ・データと呼ぶ)とは別のキャッシュ・ノードに配置して耐障害性を確保する。アプリケーションは、データの実際の配置場所を意識する必要はなく、データの読み込み/書き込みのリクエストはキャッシュの管理サービス機能などによって自動的に該当データを持つキャッシュ・ノードにルーティングされる(図2)※1。 ※1 パーティション・キャッシュでは、後述するようにキャッシュ・ノードとアプリケーション・プロセスを論理的に分けて配置するのが一般的なので、図2および以降の説明ではそのようなアーキテクチャを前提としている。 ノードの追加によるキャッシュ容量の拡張が可能 パーティション・キャッシュの最大の特徴は、キャッシュ容量を容易に拡張可能な点にある。新たなキャッシュ・ノードを追加するだけで、その分のメモリ領域がデータの格納先として追加されるので、1つのプロセスに割り当て可能な上限を大きく超えたメモリ領域を構成することが可能だ。ノードの動的な追加をサポートする製品なら、アプリケーション稼働中でも、状況に応じて容量の拡張が行える ※2。このように、ノード拡張の要件が異なるため、キャッシュ・ノードはアプリケーション・プロセスとは論理的に分けて構成することが多い。 ※2 先にリスト2で示したように、アプリケーションは論理キャッシュ名(リスト中ではPerson)でデータにアクセスするので、キャッシュ構成の変更に伴ってアプリケーション・コードを書き換える必要はない。 キャッシュ・データの耐障害性とリカバリ パーティション・キャッシュでは、プライマリ・データとは別のキャッシュ・ノードにバックアップ・データを配置することにより、インメモリでデータの耐障害性を確保する。データの書き込みは、プライマリとバックアップの両方を更新して初めて完了となるので、データの不整合は起こらない。障害時の動作は図3 のようになり、バックアップ・データから自動的にプライマリ・データがリカバリされる。なお、バックアップ・データの数は変更することが可能であり、バックアップ数を増やせば耐障害性を高められるが、これはレプリケーション性能とのトレードオフになる。 レプリケーション負荷の軽減 パーティション・キャッシュでは、ネットワークを介したデータ・アクセスが前提となるので、読み込みの待ち時間にはキャッシュ・ノードへの1往復のネットワーク・アクセス時間が含まれる(ただし、一度読み取ったデータのコピーをアプリケーション側でローカルに保持する機能を使えば、頻繁に使われるデータの取得時間を最適化できる)。一方、書き込みの際にはプライマリ/バックアップ両方のデータを書き込むので、最低2往復のネットワーク・アクセスが生じる(これはバックアップ数が1の場合)。パーティション・キャッシュの特徴としてもう1つ重要な点は、レプリケーション時の負荷が比較的少ないので、書き込み処理の負荷分散が可能なことだ。 例えば、4ノードで構成されるキャッシュに対して1,000件/秒の書き込みが行われるとしよう。先のレプリケーション・キャッシュでは、書き込まれたデータを全キャッシュ・ノードにレプリケートする必要があるため、結局各ノードで1秒間当たり1,000件のデータ更新を処理することになる。一方、パーティション・キャッシュの場合はどうだろうか。バックアップ数が1つの場合、1回の書き込みで1つのキャッシュ・ノードに対してレプリケートすれば済む。つまり、プライマリ/バックアップを合わせて全体で2,000件/秒、各ノード当たりでは平均で500件/秒の書き込みとなる。 以上がインメモリ・データ・グリッドの基本機能となるが、参考までに2つのキャッシュ形式の特徴を表2にまとめておこう。 第1回 1 2 次へ

インメモリ・データ・グリッドの基本的な仕組み まずは基本的な仕組みを説明しよう。インメモリ・データ・グリッドのコアとなる機能は、データをメモリ上で管理し、アプリケーションから利用可能な状態にすることだ。実際にどのようにしてデータをメモリ上に配置して管理するのかを、2つの代表的なキャッシュ形式「レプリケーション・キャッシュ」と「パーティション・キャッシュ」を例にとって解説する。 参照系に向いたレプリケー...

01.特集・コラム

【技術コラム 第1回】 増え続けるデータに対処せよ! その2

インメモリ型データ管理の3つの方式 現在、インメモリ型のデータ管理方式には、大別して3つの種類がある。以下に、それらについて簡単に説明する(それぞれの特徴を表1にまとめたので、併せて参照されたい)。 クリックすると拡大図がご覧になれます インメモリRDBMS 1つ目は「インメモリRDBMS」だ。これは、その名が示すように「メモリ上で動作するRDBMS」であり、構成やインタフェースはRDBMSと同じだ。ただし、データをディスクに書き込まずに常時メモリ上に置くため、SQL 文の処理が高速に実行できるというメリットがある。アプリケーションから見れば通常のRDBMSなので、既存システムへの組み込みが容易に行える。 インメモリ・キャッシュ 「インメモリ・キャッシュ」とは、「アプリケーション・サーバ上に、アプリケーションから利用しやすい形式でデータを保持(キャッシュ)する」という、従来からシステム構築の中で工夫として実践されてきた手法を拡張したものである。主にデータベースなどから取得したデータを一時的に保持しておき、2回目以降のデータの読み取り速度を速める目的で使われる。このインメモリ・キャッシュには、次の2つのタイプがある。 複数のサーバで構成されるアプリケーション・サーバ層において、それぞれのサーバにあるキャッシュ間のデータを同期するタイプ(レプリケーション型) データ全体を複数のサーバに分散してキャッシュするタイプ(分散キャッシュ型) 例えば、レプリケーション型のインメモリ・キャッシュであるレッドハットの「JBoss Cache」を使う場合、リスト1のようにJava Map APIと同様のput/getメソッドによってデータを操作する。Java 開発者にはなじみの深いコーディング・スタイルを提供する一方で、背後では各サーバ上のキャッシュのデータを同期してくれるのだ。 リスト1:JBoss Cache 3.0を使う場合のデータをキャッシュに格納するコード(Java Map APIを使った通常のJavaプログラミングと大差ないコードでキャッシュの操作が可能) // 別途定義されたクラスPersonにデータを格納し、キャッシュする// CacheFactory、DefaultCacheFactory、Cache、Fqn、NodeはJBoss CacheのクラスCacheFactory factory = new DefaultCacheFactory();// キャッシュの作成Cache cache = factory.createCache();Fqn personData = Fqn.fromString("/person");// キャッシュを行うノード(キャッシュ・ノード)としてPersonを追加Node personNode = cache.getRoot().addChild(personData);// 新規Personオブジェクトにデータを格納Person p1 = new Person(1234, "田中", "太郎", "東京都港区");// キャッシュ・ノードへのデータの追加personNode.put(1234, p1); インメモリ・データ・グリッド インメモリ・キャッシュの機能を包含しつつ、さらに高度な機能を提供するのが「インメモリ・データ・グリッド」と呼ばれる方式である。この方式はインメモリ・キャッシュからの派生形であり、リスト2に示すようにアプリケーションから操作する際のコードのスタイルも類似している。ただし、データをキャッシュするだけでなく、データの書き込みまでサポートしており、実質的にインメモリのストレージとして機能する。1つ目のインメモリRDBMSとの違いは、高度な分散キャッシュの機能を備え、リスト2のようにアプリケーションからは通常のJava APIを扱うかのように利用できる点だ。なお、バックエンドのデータベースとは非同期で連携するよう設計することが多い。インメモリ・データ・グリッドのアプローチは、グーグルやアマゾンなどがクラウド・コンピューティング・サービスの提供基盤となる自社インフラの構築に用ている手法と類似している。実際、インメモリ・データ・グリッドでは、グーグルの分散処理技術であるMapReduceと同様、分散配置されたキャッシュの各ノード上でデータ処理を並行して実行することができる(詳細は後述)。企業システムにおいて、例えばインメモリ・データ・グリッドを独立した層としてアプリケーションとデータベースの間に配置すれば、複数のアプリケーションから利用可能な統合データ・サービスを構築できるだろう。なお、この方式が最初に活用されるようになったのは、IT系のベンチャー企業がひしめくWeb 2.0などの新たなビジネス領域ではなく、欧米の大手証券会社や銀行の業務システムであることを付け加えておく。こうした、システムの高速性と信頼性が特に重視される分野で使われ、発展してきた技術が今日、他の分野でも利用されつつあるのだ。 リスト2:オラクルのインメモリ・データ・グリッド製品「Oracle Coherence」でデータをキャッシュに格納するコード(コーディング・スタイルはJBoss Cacheとほぼ同じ) // 別途定義されたクラスPersonにデータを格納し、キャッシュする// CacheFactoryはOracle Coherenceのクラス// Personキャッシュの作成Map personCache = CacheFactory.getCache("person");// 新規Personオブジェクトにデータを格納Person p1 = new Person(1234, "田中", "太郎", "東京都港区");// キャッシュ・ノードにデータを追加personCache.put(1234, p1); 以上のように、インメモリ型データ管理方式には3 種類があるが、このうち本稿では、最も新しく、なおかつ今後の企業システム・アーキテクチャに大きな影響を及ぼすと見られるインメモリ・データ・グリッド方式にフォーカスを当て、その概要や、同方式を活用したシステム・アーキテクチャの例を紹介していく。 前へ 1 2 第2回

インメモリ型データ管理の3つの方式 現在、インメモリ型のデータ管理方式には、大別して3つの種類がある。以下に、それらについて簡単に説明する(それぞれの特徴を表1にまとめたので、併せて参照されたい)。 クリックすると拡大図がご覧になれます インメモリRDBMS 1つ目は「インメモリRDBMS」だ。これは、その名が示すように「メモリ上で動作するRDBMS」であり、構成やインタフェースはRDBMSと同じだ。た...

01.特集・コラム

【技術コラム 第1回】 増え続けるデータに対処せよ! その1

最近、一部の企業において、データ・アクセスに関して従来とは異なる考え方/アーキテクチャを採用する動きが起きている。これは、見方によっては"プライベート・クラウド"ともとらえられる、インメモリ型のデータ管理層を取り入れたアーキテクチャだ。本パートでは、この動きの背景にある課題や技術動向などにも触れながら、インメモリ型のデータ管理という新たなアーキテクチャ手法の概要や企業システムにおける使いどころなどを紹介する。 増え続けるデータに対処せよ! 大量のトランザクションを処理するために、大型のサーバが使われるケースは少なくない。確かに大型のサーバは高性能であるし、通常は障害対応の仕組みも搭載しており、そうした面では申し分のない存在だ。しかし、その分"高価"である。いくら高性能なサーバを導入したとしても、トランザクションが増え続ければ、いつかは処理性能が限界に達する。そして結局、追加のサーバを投入せざるをえなくなり、さらにコストがかさんでいくことになる----このような具合に、増え続けるトランザクションやデータへの対応に苦慮している企業は多い。この問題がやっかいな点は、最初に「アプリケーションのスローダウン」という現象として表面化してくることだ。そのため、「パフォーマンスを改善しなくては」という意識で対応しがちだが、問題の核心はチューニングにではなく(チューニングしても、性能の限界点を先延ばしにするだけである)、「妥当なコストでシステムを拡張していけるかどうか」ということにある。 データ処理のボトルネックがシステムの性能向上を妨げる では、コストが問題だとしたら、近年、性能向上が著しいコモディティ・サーバを並べるスケールアウトのアーキテクチャを採用すればよいのだろか。確かに、それは有力な解の1つだが、それで問題の根本が解決するわけではない。これについて、ある企業のシステムを例にとって説明しよう。 この企業では、大量のトランザクション/リクエストをさばくために、複数のアプリケーション・サーバを並べて負荷分散するという一般的なアーキテクチャをとっていた。リクエストの増加に応じてアプリケーション・サーバを追加していたのだが、やがて追加台数に見合った性能が得られなくなってきた。システムの性能向上が頭打ちになった理由はいくつか考えられる。まず複数のアプリケーション・サーバからのデータベースへのアクセスの集中がボトルネックになっていたり、データベースのロックを引き起こしていたりする可能性がある。また、耐障害性確保のために、アプリケーション・サーバ側でセッションのインメモリ・レプリケーションを設定していたが、サーバ台数の増加に伴ってその処理が追いつかなくなっている可能性もある。あるいは、インメモリではなく、データベースやファイル・ベースのレプリケーションを行っており、そのディスクI/Oの増加に性能が引きずられているのかもしれない----これらの何が原因であるにせよ、結局、データの処理がボトルネックとなり、ハードウェアへの投資に見合った性能向上を妨げているのである。 データ処理はどうあるべきか 上の事例のようなケースは今日よく見られるものだが、それらに共通しているのは、データ処理のボトルネックがシステムの性能向上を妨げ、ひいては投資対効果(ROI:Return On Investment)を低下させているということだ。今日のシステムにおいて、データ処理はボトルネックの代表格なのである。 アプリケーションが持つ4種類のデータ もっとも、一口にデータ処理と言っても、これにはさまざまなものがある。ここで、昨今のアプリケーションが扱うデータにはどのような種類があり、その処理形態はどうあるのが望ましいのかを簡単に整理しておこう。アプリケーションの内部では、主に次の4種類のデータが使われる。 1)全体で共通に使われる参照情報(マスタ・データ、ユーザーの個人情報データなど) 2)システム上で発生する入力情報(トランザクション・データや注文/申請データなど) 3)ユーザーに固有のアプリケーション定義情報(アプリケーション固有のプロファイル情報や画面表示の設定情報など) 4)アプリケーション上での一連の作業状態に関する情報(セッション情報) このうち、(1)と(2)は業務履歴として保管する必要性があったり、後々の傾向分析などのために蓄積しておくべき情報だったりする。関係各所からの問い合わせに迅速に対応できるよう、これらはRDBMSで管理するのが望ましいだろう。一方、(3)と(4)のデータは、特定のアプリケーションだけで必要となる情報であり、分析の必要性も低いので、必ずしもRDBMSで管理する必要はない。だが現実には、データの信頼性確保やレプリケーション負荷の軽減のために、RDBMSに格納しているケースが多い。データ処理の性能やROIを高めるには、少なくとも(3)、(4)のデータを管理する方法を再検討するとともに、(1)、(2)のデータのうち、オンライン処理で使われる部分(オンタイムのスナップショット・データなど)を極力、高速なアクセスが可能な環境に置くことが望まれる。 "インメモリ"でデータ処理を高速化する その「高速なアクセスが可能な環境」として近年注目を集め、技術開発が活発化しているのが「インメモリ」の領域である。本稿で扱うインメモリ型のデータ管理方式とは、従来RDBMS(ストレージ)内に置かれていたデータをメモリ上に配置することで、データ・アクセスの高速化を図るというアプローチだ。これを上記(3)、(4)の用途で使うには、次のような条件を満たすことが求められる。 メモリ/データの信頼性や耐障害性を確保する メモリ上のデータのレプリケーションにかかる負荷を最適化する 大量のデータを格納可能なメモリ容量を確保する メモリ価格の低下などもあり、近年のインメモリ型データ管理方式はこれらの条件をクリアし、実用的なアプローチとして注目を集めつつあるのだ。 ※本コラムは、ITアーキテクトVol.22の掲載記事「データ処理を高速化するインメモリ・アーキテクチャ」を、ITアーキテクト編集部の了承を得て掲載しています。 1 2 次へ

最近、一部の企業において、データ・アクセスに関して従来とは異なる考え方/アーキテクチャを採用する動きが起きている。これは、見方によっては"プライベート・クラウド"ともとらえられる、インメモリ型のデータ管理層を取り入れたアーキテクチャだ。本パートでは、この動きの背景にある課題や技術動向などにも触れながら、インメモリ型のデータ管理という新たなアーキテクチャ手法の概要や企業システムにおける使いどころなど...

01.特集・コラム

Coherenceって、何だろう? [第2回]

前回は成長を続けるECサイトや金融システムなどデータ処理量が莫大なシステムでよく見られる代表的な症状を紹介した。それらの症状に対して、Oracle Coherenceはどんな効能があるのか、おさらいしておこう。 仮想メモリ領域を構成し、DBサーバ・アプリケーションサーバの処理負荷を軽減。 こうしたECサイトをはじめとするネットビジネスの課題に対して、Oracle Coherenceはシンプルかつ効果的な答えを提供している。アクセス集中時にも高速な応答を維持するためには、インメモリでの処理が望ましいが、取り扱うデータの量が増えれば増えるほど、大型のハードウェアが必要になってしまう。これに対して、Oracle Coherenceではインメモリグリッドというアーキテクチャにより、サーバ間を横断するメモリ・データ共有の仕組みを提供。1台のサーバにすべての処理を集約するのではなく、システム全体としての一貫性やデータの整合性を保ちつつ、複数のサーバに処理を分散させることを可能にする。 高速処理を維持しながら、リソースを拡張。複数のデータソースの統合も可能。 このように、Oracle Coherenceはサーバ間でのメモリ・データ共有を実現する仕組みなので、処理能力を向上するには単純にサーバの台数を増やせばいいということになる。つまり、将来的なアクセス増加を予測しながら、より大型のハードウェアへの入れ替えを図っていくという難しい作業を行う必要はなく、コスト的にも無駄の少ないシステム増強が可能になる。しかも、Oracle Coherenceの導入メリットは“高速化”だけにとどまるものではない。メモリ間通信によるデータ共有を活用することで、個別に構築されたサイトを仮想的に統合する役割を担うことも可能だ。 データ処理量の増加が引き起こす様々な症状に速効性があるOracle Coherence。では、具体的にはどのようにして症状の改善を行ってくれるのだろうか。実際にOracle Coherenceを導入し、様々な課題を解決した企業の事例を見てみよう。  家電系ショッピングサイトを運営するA社では、1年ほど前にサイトのリニューアルを実施。オンラインショッピングでは実店舗のように知識の豊富な販売員のアドバイスを受けられないため、サイトの訪問者を購買にまで導くにはコンテンツの充実が不可欠だと考え、商品情報の質と量を高め、キャンペーンなどに合わせて内容を動的に変更できるようにした。しかし、1ページあたりのデータ処理量が数倍に増えてしまったことで、従来よりもページ表示に時間がかかるようになってしまった。 この問題を解決すべく、同社が着目したのがインメモリ・データグリッド・ソリューションOracle Coherenceだ。単にキャッシュするだけでなく、キャッシュ側でロジックを実行できるという利点に加え、構築がきわめて容易で、スケールアウト型でボリュームが増えた際に拡張しやすいことも決め手の1つになったという。Oracle Coherence導入後のレスポンス速度は10分の1以下となり、導入前に比べて大幅に短縮。更に、以前は時間帯によってレスポンス速度にばらつきがあったが、現在は安定した値が得られ、運用上のトラブルもないという。  B社が運営するインターネット・ショッピングモールは、多くの店が軒を連ね、大規模なユニークユーザに利用されている。サーバの負荷も増え続け、既に処理能力の限界に近づいていたが、従来型のシステム・アーキテクチャではデータベースとアプリケーションが密結合しているため、何か変更しようとしても開発やテストの影響範囲が広く工数がかかり、サービス側が要求する柔軟性やスピードに追従できないというジレンマがあった。 そのため同社では、データベースに依存するのではなく、キャッシュなどのテクノロジーを用いてアプリケーション層で対応できないかと考え、安価なIAサーバを活用したスケールアウト型システムを実現するために様々な製品を検討。その結果、Oracle Coherenceを採用し、データベースとアプリケーションを切り離すプロジェクトを実施した。 アプリケーション開発者にフレンドリーなOracle Coherenceのインターフェースが功を奏して、アプリケーション担当中心の導入プロジェクトはスムーズに進行し、開発期間、動作検証期間とも2ヵ月程度で完了。「体感してわかる」ほどレスポンス速度が向上したほか、アプリケーションの開発スタイルそのものにも変化がもたらされた。つまり、データベースの負荷を考慮することなく試行錯誤できる、アジリティの高いアプリケーション開発が可能になっているという。  C社のオンライン・チケット予約サイトでは、Oracle Coherenceの採用により、拡大するビジネスに耐えうる安定かつ効率的な販売基盤を構築。これまでバックエンドのレガシーシステムへ問い合わせを行っていた予約状況照会をインメモリ・データグリッドへ実装することで、照会機能の処理時間を約10分の1に短縮することができた。また、バックエンドへのクエリーが削減された上に、問い合わせ処理の負荷が複数サーバに分散化されたことで、キャンペーンなどの売り出し時の集中するアクセス・ピーク時にも安定したレスポンスを維持できているという。  大手衣料ブランドD社では、ファミリー層向け、高級志向、カジュアルなど、複数のECサイトを別々に構築していたが、利用者からはこれらの複数ブランドの商品をまとめて購入できるようにしてほしいという要望が多く寄せられていた。そこで、同社では各々のブランドのECサイトを透過的に論理統合し、総合サイトとしての運用を実現するためにOracle Coherenceを導入。各サイトはJavaアプリケーション・サーバの種類も異なる状況だったが、メモリ間通信を利用してユーザ情報を共有することで、利用者はサイトを横断しながら買い物を行い、まとめて決済することが可能になった。顧客利便性が向上するとともに、相互の顧客呼び込みによるアクセス増効果も得られているという。

前回は成長を続けるECサイトや金融システムなどデータ処理量が莫大なシステムでよく見られる代表的な症状を紹介した。それらの症状に対して、Oracle Coherenceはどんな効能があるのか、おさらいしておこう。 仮想メモリ領域を構成し、DBサーバ・アプリケーションサーバの処理負荷を軽減。 こうしたECサイトをはじめとするネットビジネスの課題に対して、Oracle Coherenceはシンプルかつ効果的...

01.特集・コラム

Coherenceって、何だろう? [第1回]

 ネットビジネスを軌道に乗せるのは容易ではないが、いったん成功を収めたとしてもそれで安泰というわけではない。成長を遂げれば遂げるほど、様々な課題に直面するものだ。 例えば、際限なく増していくデータ処理量。ビジネスを成長させるためには様々なサービスの実装が不可欠になっており、その分、扱うデータ処理量も乗数的に増加していく。 しかも、システム増強のために長時間にわたってサービスを止めることなどはできないし、ましてや、増強後に規模が大きくなったゆえにメンテナンスでシステムダウンが頻繁に発生する事態などはあってはならない。こうした数々の課題に対して、有効な手立てはあるのだろうか。  ネットビジネスを成長させるためには、高い価格競争力を維持したり、SEO対策で集客力を強化することも有効な手段と言えるが、それだけでは単発的な購買やサービス利用にしか結びつかない。そのため、例えば、ECサイトなどでは商品情報の質や量を高めたり、キャンペーンや顧客の嗜好などに合わせて内容を動的に変更するといった工夫を行っている。しかし、そのことが恒常的なページ表示の遅延を招いてしまうというケースは少なくない。顧客の訪問を購買につなげようとコンテンツを充実させたのにもかかわらず、訪問者が待ち時間にいらだちを感じてしまっては、サイトからの離脱を招き、販売機会を失うことになってしまう。  例えば、金融システムなどではサービスを増やせば増やすほど、当然ながら利用者数は増えていき、トランザクションも、取扱商品/サービスの数も、更には利用履歴などの顧客データも増加していく。運営開始時にはまったく問題がないと思われたデータベース(サーバ)への負荷も、着実に増大し続け、いずれは処理能力の限界に達してしまうだろう。その際には何らかの対策を行う必要があるが、単に更に大規模なハードウェアへ変更すればよいというわけではない。多大なコストを要するばかりではなく、今後も限界に達するたびにハードウェアのスケールアップを繰り返していくのかという不安も生じてしまうものだ。  瞬間的なアクセスの集中によるレスポンス遅延や接続エラーもしばしば問題となりがちだ。その要因としては、曜日や時間帯、あるいは新商品のリリースやセール(特価販売)の実施といった、ある程度の事前予測が可能なものも存在するが、実際には様々な要素が絡み合うため、アクセスの傾向や需要予測を正確に図ることは決して容易ではない。特に最近では、一口にネットビジネスといっても多様なサービスを幅広く展開しているケースが多く、各々のサービスに対してピーク時のアクセスを想定し、それに対応可能なITインフラを確保しておくのは、あまり現実的ではない。必要以上にコストが膨れ上がってしまうからだ。  例えば、商品カテゴリの異なるECサイトを次々に立ち上げたり、他社のサービスサイトを買収して、複数のサイトを個別に運用しているという企業もあるだろう。そうした企業では、例えば、買い物客が自社内の全ECサイトを横断して利用できるようにできないかと考えているかもしれない。つまり、複数ブランドを横断して商品をショッピングカートに入れられるようにすることで、顧客利便性を向上させるとともに、決済や配送を一元化して効率化を図れないかということだ。しかし、新たな総合サイトとして一から再構築し直すのは非効率に思えるし、なるべく現在のシステム構成を変更したくないのだが…。 Coherenceなら、これほど劇的に改善!日本有数のECサイトでも続々と採用! 毎日のように増加していくデータ処理量やサイトアクセスといったネットビジネスにおける課題は、放置していても解決できません。しかし、具体的にどのような手立てを打てばいいのか? そして、どれほどの効果があるのか? この記事の続きでは、その答えをズバリお教えします!

 ネットビジネスを軌道に乗せるのは容易ではないが、いったん成功を収めたとしてもそれで安泰というわけではない。成長を遂げれば遂げるほど、様々な課題に直面するものだ。  例えば、際限なく増していくデータ処理量。ビジネスを成長させるためには様々なサービスの実装が不可欠になっており、その分、扱うデータ処理量も乗数的に増加していく。 しかも、システム増強のために長時間にわたってサービスを止めることなどはできな...

01.特集・コラム

導入事例:楽天 - Gartner Japanによるリポート

Gartner Japanによるリポート「ケーススタディ:楽天が目指したDCPによる性能改善と柔軟なアーキテクチャへの挑戦」 従来型のシステムは、アプリケーションとDBが完全に結合しています。しかし、サービス展開のスピードが求められる業務においては、これが足かせとなる可能性があります。 例えば、ひとつサービスを追加するにも、DBに及ぼす負荷を考慮して設計しなくてはなりません。DBのメンテナンスは即座にサービスの利用制限につながります。一方で、サービス展開はバックエンドの増強を待っていては時を逃します。多様化する携帯電話やスマートフォン、クライアント・デバイスに合わせた最適なユーザーインターフェースを効率的かつスピーディに用意する必要もあります。 楽天はこれらの課題を解決し、ビジネスの成長に合わせて拡張できるスケールアウト型でかつ、柔軟性、可用性を備えたシステムに取り組まれています。 ■楽天の取り組みのアプローチとは?■着目したポイントは何か?■どのように実装したのか?■そして、将来課題は何なのか? ぜひ、このリポートを御覧ください。 皆様のシステム課題に対するヒントがここにあります。Gartner Japanによるリポート 「ケーススタディ:楽天が目指したDCPによる性能改善と柔軟なアーキテクチャへの挑戦」には、楽天のこれら課題への取り組みが、Gartner Japanによる視点で記述されています(DCP:分散キャッシュ・プラットフォーム)。 高トランザクションを処理させることを検討されているシステムアーキテクト、情報システム部門の方々をはじめ、ITシステムに関わる全ての方に必見のリポートです。 顧客事例:楽天株式会社(楽天市場) 「体感してわかる」レスポンス速度が数倍に向上。ビジネスの成長に不可欠な高い拡張性、可用性、柔軟性を備えたシステム構築。Oracle Coherenceをうまく活用すると、データベースとアプリケーションを切り離すことが出来ます。楽天事例の入手はこちらから

Gartner Japanによるリポート 「ケーススタディ:楽天が目指したDCPによる性能改善と柔軟なアーキテクチャへの挑戦」 従来型のシステムは、アプリケーションとDBが完全に結合しています。しかし、サービス展開のスピードが求められる業務においては、これが足かせとなる可能性があります。 例えば、ひとつサービスを追加するにも、DBに及ぼす負荷を考慮して設計しなくてはなりません。DBのメンテナンスは即座...