DB障害発生時も処理を継続
Coherenceは、システム全体の可用性を向上させるうえでも大きく貢献する。以下、杉氏が行ったデモを基にその点を紹介しよう。
先にも触れたとおり、Coherenceを使用すると、大規模な論理メモリ領域を確保できるためデータベースのデータを大量にキャッシュすることが可能になる。これによる効果は、単に性能向上が見込めるというだけではない。データベースが停止してもキャッシュした共有メモリ上のデータを使用してサービスを継続できるようになるのだ。データベースが復旧すれば、キャッシュデータに対して行われた変更は自動的に反映されるため、管理者の手を煩わせることもない。
![]() |
デモアプリケーションの通常時の内部状態。左上のグラフは生成されたオーダーの数(ダミープログラムにより生成している)、右上のグラフはデータベースで処理したオーダーの数、左下のグラフはCoherence内のキューに蓄積されたオブジェクトの数、右下のグラフはスループット |
![]() |
データベースを停止したときの内部状態。右上のグラフからデータベースの処理が停まったことがわかる。それに伴い、Coherence内のキューサイズが急増している(左下のグラフ。上の画面とはスケールが変わっている点に注意)が、スループットはゼロにはなっていない(右下のグラフ) |
Coherenceの追加/削除でもシステム停止不要
また、Coherenceは自身の障害にも強い。メモリリソースを仮想共有してデータをキャッシュするという処理を行っているにもかかわらず、一部のCoherenceに障害が生じて停止した場合にも、そこで扱っていたデータが消失するようなことはなく、システムは継続して稼働させることができる。
これは、マスタデータとバックアップデータを管理するノード(Coherence)が常に1台ずつ用意されており、障害発生時にはそれを基にデータを復元する仕組みになっているためだ。マスタデータ/バックアップデータを管理するCoherence自体に障害が発生した場合には、他のノードが自動的にその権限を引き継ぎ、同様の構成を再現する仕組みになっている。
加えて、ノードの追加に関してもシステムを止めずに行えるため、リソースの追加を自由に行える環境を構築することが可能だ。
![]() |
デモアプリケーションの初期状態。画面中段の「Coherenceデータグリッド概要」より、Coherenceのノード数が2、論理メモリが190MBであることがわかる。また、画面左下の「Coherenceデータグリッド分散」を見ると、各ノードのキャッシュ所有比率がそれぞれ50.23%、49.77%になっている |
![]() |
Coherenceのノードを1つ追加したときの状態。画面中段のCoherenceのノード数が3、論理メモリが317MBに変わり、各ノードのキャッシュ所有比率が33%ずつに減った。トランザクション処理時間(右下のグラフ)はノード追加時に一時的に234msまで上がったが処理は継続されていることがわかる |
![]() |
追加したノードを削除したときの状態。Coherenceのノード数が2、論理メモリが190MBになり、キャッシュ所有比率はほぼ以前の状態に戻っている。ノード削除時にトランザクション処理時間が一時的に243msまで上がったが処理は継続されていることがわかる |
なお、Coherenceは、Java EEおよび.Net Freameworkに対応する。Java EEに関しては、同社のOracle Application Serverだけでなく、WebLogic、WebSphere、JBoss、Tomcatなど、主要なアプリケーションサーバを全般的にサポート。また、データソースについては、Oracle Databaseをはじめとする主なRDBMSはもちろん、MQやホスト、Webサービスといったデータソースにも対応している。
価格は、Standard Editionが1プロセッサあたり50万円。Enterprise Editionが125万円で、Grid Editionが250万円になる。