| Oracle® Coherenceスタート・ガイド リリース3.7.1 B65028-01 |
|
 前 |
 次 |
Coherenceは、信頼性とスケーラビリティに優れたクラスタ・アプリケーションの構築に不可欠な要素です。クラスタ化という用語は、アプリケーションを実行する際(通常は信頼性とスケーラビリティの向上を目的として)、複数のサーバーを使用することを指します。Coherenceは、アプリケーションが最大の可用性、信頼性、スケーラビリティ、およびパフォーマンスを達成するために必要なすべての機能を提供します。 Coherenceは、ほとんどすべてのクラスタ・アプリケーションに利点をもたらします。
Coherenceの主な用途の1つは、アプリケーションのオブジェクトやデータをクラスタ化することです。これは、アプリケーションがCoherenceに委任したすべてのオブジェクトおよびデータについて、アプリケーション・クラスタに含まれるすべてのサーバーから自動的に使用およびアクセスできることを意味します。サーバーで障害が発生してもオブジェクトやデータが失われることはありません。
アプリケーションのオブジェクトおよびデータをクラスタ化することにより、Coherenceは、クラスタ・アプリケーションの可用性、信頼性、スケーラビリティ、パフォーマンス、サービス性および管理性を達成する際の多くの困難な課題を解決します。
可用性とは、アプリケーションが稼働している時間の割合を指します。高可用性とは100%に近い可用性を達成することです。Coherenceを使用すれば、次のように様々な方法で高可用性を実現できます。
Coherenceを使用すると、1つのアプリケーションを複数のサーバーで実行することが可能になり、これによってサーバーは冗長になります。たとえば、ロード・バランサを使用する場合、常に1つのサーバーが稼働していれば、冗長なサーバー上で稼働しているアプリケーションは使用可能になります。Coherenceでは、アプリケーションがすべての冗長サーバー間で重要な実行時情報を共有し、情報へのアクセスを調整し、それらの情報に関する変更イベントを更新および受信できるようにすることで冗長性を実現します。冗長性のある環境で稼働するよう設計されていないかぎり、ほとんどのアプリケーションは冗長サーバー環境では機能しません。Coherenceは、そのようなアーキテクチャに可能性を与えるキーとなります。
Coherenceは、使用可能なサーバーを常に正確に追跡します。追加のサーバーでアプリケーションが起動されると、Coherenceは、そのサーバーがオンラインになったことを瞬時に認識して自動的にクラスタに追加します。この機能により、サーバーを追加することで冗長性(およびそれに伴う可用性)を動的に向上させることが可能になります。
Coherenceは、ほとんどのタイプのサーバー障害を1秒未満で確実に検出し、データを失うことなく、障害の発生したサーバーのすべての役割を瞬時にフェイルオーバーします。したがって、サーバー障害が可用性に影響することはありません。
可用性管理の1つに平均リカバリ時間(MTTR)があります。これは、アプリケーションが使用不能になってから使用可能になるまでにかかる時間を指します。サーバー障害は1秒未満で検出および処理され、さらに冗長性によってサーバーが停止してもアプリケーションは使用可能となることから、アプリケーションの可用性という見地からのサーバー障害に起因するMTTRは0となり、受信リクエストを再ルーティングするロード・バランサの見地からは通常1秒未満になります。
Coherenceには、その他のインフラストラクチャ層で発生した障害から防護する機能があります。たとえば、Coherenceライトビハインド・キャッシュおよびCoherence分散パラレル問合せを使用することで、データベース障害からアプリケーションを分離できます。実際に、これらの機能を利用することで、実稼働中にデータベース障害が発生したものの、Coherenceベースの本番アプリケーションがその可用性と稼働状況を維持したという例が2件報告されています。
信頼性とは、アプリケーションが処理を正しく実行している時間の割合を指します。つまり、アプリケーションが使用可能でも、アプリケーション・プロセスを正しく処理できなければ信頼性があるとはいえません。高可用でも信頼性の低い例に携帯電話のネットワークがあります。携帯電話のネットワークの動作可能時間(可用性)は非常に高いのですが、通話が途切れることがよくあります(信頼性)。
Coherenceは、非常に高レベルの信頼性を実現するよう設計されています。たとえば、サーバーで障害が発生しても稼働中の業務に影響が及ぶことはありません。これは、それぞれの操作がサーバー障害から自動的に保護され、事前に計画された動的なリカバリ計画に基づいて内部的に2次ノードに再ルーティングされるためです。つまり、それぞれの操作にバックアップ計画が用意されているのです。
Coherenceは、障害は常にいつでも発生する可能性があるという前提のもとに設計されています。そのため、Coherenceに採用されているアルゴリズムは、ネットワーク、サーバー、オペレーティング・システム、JVMまたはその他のリソースの停止が原因で操作の各ステップに障害が発生する可能性があることを想定して入念に設計されています。これらの障害に対するCoherenceでの計画の例に、データの冗長コピーを保持した同期動作があります。つまり、アプリケーションのデータを当てにすることなく、サーバーの障害発生時もアプリケーションが継続して正しく動作するようにします。
スケーラビリティとは、アプリケーションでより高い負荷を処理できるようにあらかじめ備えておく機能のことを指します。1つのアプリケーションで維持できる負荷の最大量と、そのアプリケーションを実行するハードウェア・リソースの数が正比例する場合、アプリケーションは線形のスケーラビリティを示します。たとえば、2つのサーバーで実行されているアプリケーションが1秒間に2,000のリクエストを処理する場合、線形のスケーラビリティでは、10のサーバーで1秒間に10,000のリクエストを処理できることになります。
線形スケーラビリティはスケーラブルなアーキテクチャの目標ですが、実現は困難です。アプリケーションのスケールの度合いをスケール変更係数(SF)といいます。スケール変更係数1.0は線形スケーラビリティを示し、0.0はスケーラビリティがないことを示します。Coherenceには、アプリケーションが線形スケーラビリティを実現するのに役立つよう設計された機能がいくつか用意されています。
最大限のスケールを計画する場合、アプリケーションのスケーラビリティは、線形のスケーラビリティを示さない必須の共有リソースによって制限されるということを最初に理解しておく必要があります。この制限要素をボトルネックといいます。ほとんどのアプリケーションでは、データベースやEISなどのデータソースがボトルネックになります。
Coherenceは、明らかなボトルネックを可能なかぎり排除することで、スケーラビリティの問題を解決できるようにします。これには、次のような様々な機能を使用します。
Coherenceは、レプリケーション、分散、パーティション化および無効化の機能を組み合せて使用し、処理を実行するサーバーに関係なく、Coherenceから取得するデータが同じになるようクラスタ内のデータを確実に維持します。つまり、Coherenceは分散共有メモリーの実装を提供します。これは、単一システム・イメージ(SSI)またはCoherentクラスタ・キャッシングとも呼ばれます。
アプリケーションが必要なデータをアプリケーション層から取得できる場合、データソースはシングル・ポイント・ボトルネック(SPOB)ではなくなります。
Coherenceにおけるパーティション化とは、クラスタ内のすべてのサーバー間でデータ記憶域、アクセスおよび管理のロード・バランシングを行う機能のことを指します。たとえば、4つのサーバーで構成されるクラスタにおいてデータのパーティション化を使用すると、各サーバーがデータを25%ずつ管理するようになります。別のサーバーが1つ追加されると、5つのサーバーでデータを20%ずつ管理するよう負荷が動的に調整され、データや操作が失われることなく、アプリケーションの介入なしでデータのロード・バランシングが行われます。同様に、5つのサーバーの1つが停止した場合は、残りの4つのサーバーでデータを25%ずつ管理します。このデータのロード・バランシングでも、データ(障害の発生したサーバーで管理されていた20%のデータを含む)や操作が失われることはなく、アプリケーションが介入することはありません。
Coherenceでは、クラスタ内のデータについて構成可能な数のコピーを同期的に維持することで、データを失うことなくフェイルオーバーを実行します。データ管理の役割がクラスタに分散されるのと同様に、データ・バックアップの役割も分散されます。つまり前述の例では、残りの4つの各サーバーが、障害のあったサーバーのデータのバックアップを約25%ずつ受け持つことになります。このメッシュ・アーキテクチャにより、サーバーで障害が発生しても、残りのサーバーの特定の1つに膨大な量の追加の役割が集中しないようになります。
Coherenceを使用すると、クラスタ内の単一の物理サーバーで複数のアプリケーション・インスタンスが実行される場合にも、データの損失を回避することが可能になります。そのためには、データのバックアップ・コピーを複数の物理サーバーで管理します。これにより、1つの物理サーバーに障害が発生したり通信が切断されても、そのサーバーで管理していたすべてのデータには、別のサーバー上にいつでも使用できるバックアップが用意されていることになります。これは、クラスタで信頼性および高可用性が確保されている(通常は4つ以上の物理サーバーとすべての物理サーバー上にほぼ同じ数のJVMがある)ことを前提としています。Coherenceの高可用性構成の詳細は、『Oracle Coherence開発者ガイド』を参照してください。
また、パーティション化によってデータ容量およびスループットの両方に対する線形スケーラビリティがサポートされます。データ容量のスケーラビリティは、すべてのサーバー間にデータを均一に分散することで実現します。つまり、4つのサーバーを使用すれば、当然、2つのサーバーを使用する場合の2倍のデータを管理できます。スループットのスケーラビリティも、すべてのサーバー間でデータをロード・バランシングした直接的な結果になります。これは、サーバーが追加されるたびに、各サーバーで管理するデータセットの割合が全体に対して小さくなり、その管理に処理能力をフルに活用できるようになるためです。たとえば、10のサーバーで構成されるクラスタでは、各サーバーはデータ操作の10%を管理する必要があります。また、Coherenceはpeer-to-peerアーキテクチャを使用しているため、それらの操作の10%を各サーバーから受信します。その10倍のサーバー(つまり100のサーバー)の場合、各サーバーはデータ操作の1%を管理するだけであり、それらの操作の1%のみが各サーバーから受信されますが、10倍の数のサーバーが存在するため、そのクラスタでは全操作の10倍の処理が実行されます。10のサーバーで構成されるクラスタの例では、各サーバーから1秒間に100の操作が発行されると、各サーバーから他のサーバーに操作が10ずつ送信され、その結果、各サーバーは100の操作(10x10)を受信して処理を受け持つことになります。100のサーバーで構成されるクラスタの例では、各サーバーは同様に1秒間に100の操作を発行しますが、各サーバーが100の操作(100x1)を受信して処理を受け持つように、各サーバーから他のサーバーには操作は1つずつしか送信されません。この線形スケーラビリティは、最新のスイッチド・ネットワーク・アーキテクチャにより可能になります。このアーキテクチャは、各ポートに専用の全二重(アップストリームおよびダウンストリーム)帯域幅を備え、スイッチのポート数に比例してスケールするバックプレーンを提供します。(10および100のサーバーで構成されるどちらのクラスタの例でも)各サーバーで100の操作しか送受信されないため、クラスタ内のサーバー数にかかわらず、ポート当たりのネットワーク帯域幅の使用量はほぼ一定です。
Coherenceのクラスタ化の一般的な使用例の1つに、クラスタでのユーザー・セッション(対話状態)の管理があります。この機能は、Coherenceの組込み機能であるCoherence*Webモジュールによって提供されます。Coherence*Webは、何百もの本番サーバーで構成されるクラスタにおいて、HTTPセッション管理に対する線形スケーラビリティを提供します。この線形スケーラビリティを実現できるのは、そのコアで、Coherenceの動的なパーティション化に基づいて構築されているためです。
セッション管理では、共有データソースの典型的な特徴であるスケーラビリティの問題が重要になります。アプリケーションで複数のサーバー間でデータを共有できない場合、そのデータの管理は共有ストア(通常はアプリケーションのデータベース)へ完全に委任する必要があります。HTTPセッションがデータベースに保存されると、各HTTPリクエストは(スティッキーなロード・バランシングがない場合に)データベースからの読取りを必要とし、1秒当たりの望ましい読取り数がサーバー・クラスタのサイズに比例して増加します。さらに、各HTTPリクエストによって対応するHTTPセッションの更新が発生します。そのため、スティッキーなロード・バランシングの有無にかかわらず、データベースへの1秒当たりの望ましい書込み数もサーバー・クラスタのサイズに比例して増加します(サーバーの障害発生時にHTTPセッション・データが失われないようにするため)。いずれの場合も、実際にデータベースで実行される1秒当たりの読取り数および書込み数は、それらをリクエストするサーバー数に関連して変わるわけではありません。またデータベースがすぐにボトルネックとなり、可用性、信頼性(たとえば非同期の書込み)およびパフォーマンスは低下します。さらにパフォーマンスに関して、データベースからの各読取りに関連する待機時間が発生します。データベースの負荷が増加するに従って、この待機時間も著しく増加します。
しかし、Coherence*Webでは、2つのサーバーで構成されるクラスタでも、200のサーバーで構成されるクラスタでも、待機時間は同じになります。それは、(スティッキーなロード・バランシング処理の結果としての局所性などにより)ローカルで処理できないすべてのHTTPセッションの読取り操作がクラスタの残りのサーバー間で均等に分散され、同様に、(HTTPセッションを確実に保持するためにリモートで処理する必要がある)すべての更新処理もクラスタの残りのサーバー間で均等に分散されるためです。その結果、クラスタのサイズにかかわらず、待機時間が一定の線形スケーラビリティになります。
パフォーマンスは、(処理を完了するために必要な時間を表す)待機時間とは反対の意味を持ちます。パフォーマンスの向上を目的とするのであれば、待機時間のかかる処理を排除することが解決策になります。しかしアプリケーションの高可用性および信頼性の面では、重要な情報についての信頼できる最新のバックアップを(Coherenceなどの)基礎となるインフラストラクチャに依存して保持しているため、待機時間を完全に排除することは不可能です。つまり、一部の操作(データの変更やペシミスティックなトランザクションなど)について、その待機時間を回避することはできません。ただし、潜在的に待機時間が発生するその他の操作はすべて排除の対象とするべきであり、Coherenceには、それのみを実行するように設計された機能が数多く用意されています。
サーバー・クラスタ全体で動的かつ均等にデータのロード・バランシングを行うパーティション化と同様に、レプリケーションでも、クラスタ内の1つ1つのサーバーで目的のデータセットが常に最新の状態で保持されます。レプリケーション機能を使用すると、任意のサーバーで実行されている操作に必要なデータをローカルに取得できます。目的のデータはすでにサーバーにレプリケートされているため、基本的にはコストをかけずに処理を実行できます。つまり、レプリケーションは参照の局所性を保証するためのツールであり、その結果、レプリケートされているデータへのアクセス待機時間は0になります。
レプリケーションはすべてのサーバーに配置する必要のあるデータに対して最適に機能するため、アプリケーションですべてのサーバーへのコピーを回避しているデータがある場合は非効率です。たとえば、常に変更されるデータや膨大なデータセットはレプリケーションには適していませんが、(データ容量やスループットの線形スケーラビリティを示す)パーティション化には非常に適しています。
パーティション化の唯一のデメリットは、データ・アクセスの待機時間が発生することです。ほとんどのアプリケーションでは、データ・アクセスの割合がデータ変更の割合を大きく上回ります。パーティション化されたデータのアクセスに関連する待機時間を排除するために、ニア・キャッシュでは、目的のデータにアクセスする特定のサーバーに、パーティション化されたキャッシュからの使用頻度の高い、最後に使用されたデータを保持し、さらにイベントベースで無効化することによってデータの整合性を維持します。つまり、必要になる可能性が最も高いデータを近く(ニア・キャッシュ)に保持することで、最適なアクセスの局所性を実現しながら、パーティション化の線形スケーラビリティも維持します。
クラスタ内のトランザクション・スループットは線形なスケーラビリティを示すため、データ変更に関連するコストは固定の待機時間になり(一般的には数ミリ秒の範囲)、1秒当たりの総トランザクション数はクラスタ・サイズによってのみ制限されます。Coherenceでは、あるアプリケーションで、毎秒50万トランザクション近いトランザクション率を、2つのCPUを搭載した一般的なサーバーから構成されるクラスタで実現することができました。
多くの場合、Coherenceで管理するデータは、実際にはデータベースなどの正式な記録システム(SOR)に保存されているデータの一時的なコピーです。データベースがトランザクションのボトルネックにならないよう、またデータベース更新の待機時間を排除するため、Coherenceにはライトビハインド機能が用意されています。これにより、アプリケーションでクラスタ内のデータを変更でき、それらの変更をアプリケーションのデータベース(またはEIS)に非同期に再現できます。(前述の高可用性、信頼性およびスケーラビリティの特性をすべて備えた)クラスタ化されたキャッシュで変更を管理することにより、保留中の変更はサーバー障害の影響を受けず、変更の全体的な割合はクラスタ・サイズに比例します。
ライトビハインド機能は、各データ変更をキューで管理することによって実装されます。キューには記録システムに書き込む必要のある変更リストが含まれます。キュー内のアイテムの存続時間は構成可能で、ライトビハインド遅延と呼ばれています。データが変更されると、その変更がライトビハインド・キューに追加され(キューに存在しない場合)、構成したライトビハインド遅延の経過後、キューのエントリはripen(成熟した)に設定されます。キューのエントリが成熟すると、対応するデータの最新コピーが記録システムに書き込まれます。
記録システムでの処理の集中を回避するため、Coherenceでは、データの最新コピーのみをデータベースに再現します。そのため、同じデータに発生した多くの更新処理は、単一のデータベース操作にまとめられます。ライトビハインド遅延が長いほど、まとめる更新処理は多くなります。また、多くの異なるデータが変更された場合、それらの更新をすべて(たとえば、JDBC文のバッチなどを使用して)単一のデータベース操作にまとめることができます。この方法では、大量の変更の幅(変更するデータ数)および変更の深さ(それぞれの変更回数)を単一のデータベース操作にまとめることができます。その結果、データベースの負荷は大幅に低減されます。このバッチ処理も構成可能です。書込みバッチ係数と呼ばれるオプション(write-batch-factor)では、成熟していないキュー・エントリの一部も、まとめる更新処理に含めることができます。
サービス性とは、可用性に影響を与えることなく実行可能な変更の容易さおよび範囲を指します。Coherenceでは、サーバーをオフラインで使用することで、アプリケーションの可用性に影響することなくアプリケーションのサービス性を向上させることができます。これらのサーバーは、エンドユーザーや処理の介入なしにサービスを提供したり、オンラインに戻したりすることができます。Coherenceに関連する多くの構成変更も、同様にノードベースで行うことができます。慎重に計画すれば、(一度に1ノードずつですが)大規模なアプリケーションの変更もアプリケーションの中断なしに本番環境で実行できます。
管理性とは、稼働しているシステムが提供する情報のレベル、およびその情報に関連する設定を調整する機能を指します。たとえば、Coherenceでは標準のJMX APIを介してクラスタ全体の管理情報を表示できるため、単一のサーバーからクラスタ全体を管理できます。提供される情報には、ヒット率やミス率、キャッシュ・サイズ、読取り数/書込み数/ライトビハインド数の統計、およびネットワーク・パケット・レベルまでのすべての詳細情報が含まれます。
またCoherenceでは、同じクラスタ化されたJMX実装を介して、アプリケーション独自の管理情報を配置し、独自の構成可能な設定を公開できます。その結果、アプリケーション・インフラストラクチャでのクラスタ化されたアプリケーションの管理と監視が、単一サーバーを管理および監視する場合と同様に単純になり、それらはすべてJavaの標準管理APIを介して実行されます。
