単一区画トランザクションおよびクロスデータ・グリッド・トランザクション

WebSphere® eXtreme Scale とリレーショナル・データベースやメモリー内データベースなどの従来のデータ・ストレージ・ソリューションとの間の主な相違は、キャッシュの直線的な増加を可能にする区画化を使用することにあります。考慮すべき重要なトランザクションのタイプに、単一区画トランザクションと各区画 (クロスデータ・グリッド) トランザクションがあります。

一般的に、以下のセクションで説明するようにキャッシュとの対話は、単一区画トランザクションまたはクロスデータ・グリッド・トランザクションとして分類できます。

単一区画トランザクション

単一区画トランザクションは、WebSphere eXtreme Scale によってホストされるキャッシュと対話する場合に適した方法です。単一区画に制限されている場合のトランザクションは、デフォルトで単一の Java 仮想マシン、すなわち単一のサーバー・コンピューターに制限されます。サーバーは、こうしたトランザクションを毎秒 M 個実行することができるので、N 台のコンピューターがある場合は、毎秒 M*N 個のトランザクションを実行できます。ビジネスが拡大し、毎秒こうしたトランザクションを 2 倍の数実行する必要性が出てきた場合、さらにコンピューターを購入して N を 2 倍にすることができます。これにより、アプリケーションを変更したり、ハードウェアをアップグレードしたり、さらにはアプリケーションをオフラインにしたりすることさえなく、容量ニーズを満たすことができます。

単一区画トランザクションは、キャッシュの拡大をかなり大幅に行えるようになっているほか、キャッシュの可用性を最大限に引き出します。各トランザクションは、1 台のコンピューターのみに依存します。他の (N-1) 台のコンピューターのいずれかに障害が起こっても、このトランザクションの成否および応答時間には影響しません。したがって、100 台のコンピューター (サーバー) を稼働していて、そのうち 1 台に障害が生じても、そのサーバーに障害が生じた時点で進行中であった 1 パーセントのトランザクションしかロールバックされません。サーバーの障害後、WebSphere eXtreme Scale は、障害を起こしたサーバーによってホストされる区画を他の 99 台のコンピューターに再配置します。これは短時間の処理であり、この操作の完了前であれば、この時間内に他の 99 台のコンピューターはトランザクションを完了できます。再配置される区画に関係するトランザクションしか、ブロックされません。フェイルオーバー・プロセスが完了すると、キャッシュは、元のスループット量の 99 パーセントで完全に操作可能状態で引き続き稼働できるようになります。障害のあるサーバーが交換されて、データ・グリッドに戻されると、キャッシュは 100 パーセントのスループット量に戻ります。

クロスデータ・グリッド・トランザクション

パフォーマンス、可用性、およびスケーラビリティーの面では、クロスデータ・グリッド・トランザクションは、単一区画トランザクションの対極にあります。クロスデータ・グリッド・トランザクションは、すべての区画、つまり構成内のすべてのコンピューターにアクセスします。データ・グリッド内の各コンピューターは、ある種のデータを検索して、その結果を戻すように求められます。トランザクションは、すべてのコンピューターが応答するまで完了できません。したがってデータ・グリッド全体のスループットは、最低速のコンピューターによって制限されます。コンピューターを追加しても、最低速のコンピューターの処理速度が増すわけではなく、キャッシュのスループットは改善しません。

クロスデータ・グリッド・トランザクションは、可用性についても同じ影響を及ぼします。先の例を拡大すると、100 台のサーバーが稼働していて、そのうち 1 台に障害が生じたとすると、そのサーバーに障害が生じた時点で進行中であったトランザクションの 100 パーセントがロールバックされます。サーバーの障害後、WebSphere eXtreme Scale は、このサーバーによってホストされる区画を他の 99 台のコンピューターに再配置する処理を開始します。この時間の間、フェイルオーバー・プロセスが完了するまでは、データ・グリッドは、該当するトランザクションをどれも処理できなくなります。フェイルオーバー・プロセスが完了すると、キャッシュは、続行できるようになりますが、容量は減少します。データ・グリッド内の各コンピューターが 10 個の区画をサービスしていた場合、残りの 99 台のコンピューターのうち 10 台は、フェイルオーバー・プロセスの一部として少なくとも 1 つの余分の区画を受け取ることになります。余分の区画を 1 つ追加すると、該当コンピューターのワークロードは 10 パーセント以上増えます。データ・グリッドのスループットは、クロスデータ・グリッド・トランザクション内の最低速のコンピューターのスループットに制限されるので、平均して、スループットは 10 パーセント減少します。

WebSphere eXtreme Scale のような高可用性の分散オブジェクト・キャッシュでのスケールアウトの場合は、単一区画トランザクションのほうがクロスデータ・グリッド・トランザクションよりも適しています。こうした種類のシステムのパフォーマンスを最大限にするには、従来のリレーショナルの方法論とは異なる手法を使用する必要がありますが、クロスデータ・グリッド・トランザクションをスケーラブルな単一区画トランザクションに変えることができます。

スケーラブル・データ・モデルのビルドのベスト・プラクティス

WebSphere eXtreme Scale のような製品でのスケーラブル・アプリケーションをビルドする際のベスト・プラクティスには、基本原則と実装ヒントという 2 つのカテゴリーがあります。基本原則は、データ自体の設計に取り込む必要がある中心的なアイデアです。こうした原則を守らないアプリケーションは、たとえそのメインライン・トランザクションに対しても、適切に拡大できる可能性が低くなります。実装ヒントは、スケーラブル・データ・モデルの本来は一般的な原則に従って適切に設計されたアプリケーション内の問題のあるトランザクションに適用されます。

基本原則

スケーラビリティーを最適化する重要な手段の一部として、基本的な概念または原則を考慮する必要があります。

正規化に代わる重複

WebSphere eXtreme Scale のような製品の場合、その製品が多数のコンピューター間でデータを展開できるように設計されているということを念頭に入れておくことが重要です。ほとんどまたはすべてのトランザクションを単一区画で完全なものとすることが目標である場合は、データ・モデル設計で、トランザクションが必要とする可能性のあるすべてのデータがその区画に存在するようにする必要があります。ほとんどの場合、データを複製することによってのみ、この目標を実現できます。

例えば、メッセージ・ボードのようなアプリケーションを考えてみます。メッセージ・ボードの 2 つの極めて重要なトランザクションとして、一定のユーザーからのすべてのポスト・メッセージを表示するものと、特定のトピックに関するすべてのポスト・メッセージを表示するものがあります。まずこうしたトランザクションがユーザー・レコード、トピック・レコード、さらに実際のテキストが含まれるポスト・レコードを含む正規化されたデータ・モデルをどのように扱うかを考えてみます。 ポスト・メッセージがユーザー・レコードによって区画に分割されている場合、トピックを表示することは、クロスグリッド・トランザクションとなります。またその逆もいえます。トピックおよびユーザーは、多対多のリレーションシップを持っているので一緒に区画に分割することはできません。

このメッセージ・ボードの拡大を行う最善の策は、ポスト・メッセージを複製して、トピック・レコードを持つコピーを 1 つ、ユーザー・レコードを持つコピーを 1 つ保存することです。この結果、ユーザーからのポスト・メッセージを表示することは単一区画トランザクションとなり、トピックに関するポスト・メッセージを表示することは単一区画トランザクションとなり、ポスト・メッセージを更新または削除することは、2 区画トランザクションとなります。データ・グリッド内のコンピューターの数が増えるにつれ、これら 3 つのトランザクションがすべて直線的に拡大します。

リソースに代わるスケーラビリティー

非正規化されたデータ・モデルを考慮する場合に克服すべき最大の障害は、こうしたモデルがリソースに与える影響です。ある種のデータのコピーを 2 つ、3 つ、またはそれ以上保持すると、利用される資源が多すぎるように見える場合があります。こうしたシナリオに直面したら、ハードウェア・リソースが年々低価格になっているという事実を思い出してください。第 2 に (さらに重要)、WebSphere eXtreme Scaleは、追加資源のデプロイに関連した隠れコストを削減します。

メガバイトやプロセッサーといったコンピューター関連ではなく、コスト関連でリソースを測定してください。正規化された関係データを扱うデータ・ストアは、一般的に同じコンピューターに存在する必要があります。こうしたコロケーションの必要性から、いくつか小型コンピューターを購入するのではなく、1 台の大型の企業向けコンピューターを購入したほうがよいという結果が導かれます。ただし企業向けハードウェアの場合、通常では、毎秒 100 万のトランザクションの実行が可能な 1 台のコンピューターを使用するほうが、それぞれ毎秒 10 万のトランザクションの実行が可能な 10 台のコンピューターを結合した場合よりコストがかなりかかることは珍しいことではありません。

リソースを追加する際のビジネス・コストも存在します。ビジネスが成長していくと、結果的に容量不足となります。容量不足となると、より大型の高速コンピューターに移行する際にシャットダウンが必要になるか、切り替え可能な第 2 の実稼働環境の作成が必要になります。いずれにせよ、ビジネス損失が発生するか、遷移期間にほぼ 2 倍の容量の維持が必要になるという形で追加コストが発生します。

WebSphere eXtreme Scale を使用すると、容量追加のためにアプリケーションをシャットダウンする必要がなくなります。ビジネスで翌年に 10 パーセントの追加容量が必要になることが見込まれた場合、データ・グリッド内のコンピューターの数を 10 パーセント増加します。このパーセンテージ分の増加の際に、アプリケーション・ダウン時間もなく、超過容量の購入の必要もありません。

データ形式変更の防止

WebSphere eXtreme Scale を使用している場合、データは、ビジネス・ロジックで直接消費可能な形式で保管されます。データをよりプリミティブな形式に分解することには、コストがかかります。データの書き込みおよび読み取り時に、変換を実行する必要があります。リレーショナル・データベースを使用する場合、データが最終的にディスクにパーシストされることがごく頻繁に行われるため、この変換は必要に応じて実行されますが、WebSphere eXtreme Scale を使用すると、こうした変換を実行する必要がなくなります。データは大部分メモリーに保管されるため、アプリケーションが必要とするそのままの形式で保管することができます。

この単純な規則に従うと、最初の原則に従ってデータを非正規化するのに役立ちます。ビジネス・データ用の最も一般的なタイプの変換は、正規化されたデータをアプリケーションのニーズに合う結果セットに変えるために必要な JOIN 演算です。データを正しい形式で保管すると、暗黙的にこうした JOIN 演算の実行が避けられ、非正規化されたデータ・モデルが作成されます。

未結合照会の除去

いくらデータを適切に構成しても、未結合照会は正しく拡張されません。例えば、値でソートされたすべての項目のリストを要求するようなトランザクションは使用しないでください。こうしたトランザクションは、はじめのうち合計項目数が 1000 であると、機能するかもしれませんが、合計項目数が 1000 万に達すると、トランザクションは 1000 万すべての項目を戻します。このトランザクションを実行した場合、最も考えられる 2 つの結果は、トランザクションのタイムアウトになるか、クライアントにメモリー不足エラーが発生するかのいずれかです。

最善のオプションは、上位 10 または 20 の項目だけが戻されるように、ビジネス・ロジックを変更することです。このロジック変更によって、キャッシュ内の項目数に関係なく、トランザクションのサイズが管理可能な程度に保たれます。

スキーマの定義

データの正規化の主な利点は、データベース・システムが状況の背後にあるデータの整合性を考慮できることです。データがスケーラビリティーのために非正規化されると、この自動データ整合性管理は存在しなくなります。データの整合性を保証するために、アプリケーション層で機能できるか、分散データ・グリッドに対するプラグインとして機能できるデータ・モデルを実装する必要があります。

メッセージ・ボードの例を考えてみます。トランザクションがトピックからポスト・メッセージを除去した場合、ユーザー・レコード上の重複するポスト・メッセージを除去する必要があります。データ・モデルがなくても、開発者は、トピックからポスト・メッセージを除去し、さらに確実にユーザー・レコードからそのポスト・メッセージを除去するアプリケーション・コードを作成することができます。ただし、仮に開発者がキャッシュと直接に対話する代わりにデータ・モデルを使用していたとしても、データ・モデル上の removePost メソッドによって、ポスト・メッセージからユーザー ID を抜き出して、ユーザー・レコードを検索し、この状況の背後にある重複ポスト・メッセージを除去することができます。

あるいは、実際の区画で実行し、トピックの変更を検出して、ユーザー・レコードを自動的に調整するリスナーを実装することができます。リスナーは、役に立ちます。区画がユーザー・レコードを持つようになった場合に、ユーザー・レコードの調整がローカルで可能になるか、ユーザー・レコードが異なる区画にあっても、トランザクションがクライアントとサーバーの間ではなく、サーバー間で実行されるためです。サーバー間のネットワーク接続のほうが、クライアントとサーバーの間のネットワーク接続よりも高速である可能性があります。

競合の防止

グローバル・カウンターを持つようなシナリオは避けてください。1 つのレコードが残りのレコードと比べて極端に多く使用されている場合は、データ・グリッドは拡張されません。データ・グリッドのパフォーマンスは、この特定のレコードを保持するコンピューターのパフォーマンスによって制限されています。

このような状態では、そのレコードを区画単位で管理できるように分割してみてください。例えば、分散キャッシュ内の合計エントリー数を戻すトランザクションを考えます。すべての挿入および除去操作で増大する単一のレコードにアクセスする代わりに、各区画のリスナーに挿入および除去操作を追跡させます。このリスナーによるトラッキングを使用すると、挿入および除去を単一区画操作とすることができます。

カウンターの読み取りはクロスデータ・グリッド操作となりますが、ほとんどの場合、それは元々クロスデータ・グリッド操作と同じく非効率的です。そのパフォーマンスがレコードをホストするコンピューターのパフォーマンスと関係しているためです。

実装ヒント

最善のスケーラビリティーを達成するには、以下のヒントも考慮してください。

逆引き索引の使用

顧客レコードが顧客 ID 番号に基づいて区画化されるような適切に非正規化されたデータ・モデルを考えます。この区画化方法は論理的な選択といえます。顧客レコードによって実行されるほぼすべてのビジネス・オペレーションは、顧客 ID 番号を使用するからです。ただし、顧客 ID 番号を使用しない重要なトランザクションに、ログイン・トランザクションがあります。ログインには顧客 ID 番号よりもユーザー名や電子メール・アドレスが使用されるほうが一般的です。

ログイン・シナリオの簡単な方法は、顧客レコードを見つけるためにクロスデータ・グリッド・トランザクションを使用することです。先に説明したように、この方法は拡張されません。

次のオプションとして、ユーザー名または電子メールに基づいて区画化することがあります。このオプションは、顧客 ID に基づくすべての操作がクロスデータ・グリッド・トランザクションとなるので、実用的でありません。またサイトのユーザーがユーザー名や電子メール・アドレスを変更したい場合もあります。WebSphere eXtreme Scale のような製品は、データをその不変性の維持のために区画化するのに使用される値を必要とします。

適切な解決方法として、逆引き索引を使用することができます。WebSphere eXtreme Scale を使用すると、すべてのユーザー・レコードを保持するキャッシュと同じ分散グリッドにキャッシュを作成できます。このキャッシュは、高可用性で、区画化され、しかもスケーラブルです。このキャッシュは、ユーザー名または電子メール・アドレスを顧客 ID にマップするために使用できます。このキャッシュでは、ログインは、クロスグリッド操作ではなく 2 区画操作となります。このシナリオは単一区画トランザクションほどよくはありませんが、コンピューターの数が増えるにつれ、スループットが直線的に増加します。

書き込み時の計算

平均や合計などの一般的な計算値は、作成にコストがかかることがあります。こうした操作には、通常膨大な数のエントリーを読み取る必要があるためです。ほとんどのアプリケーションでは、読み取りのほうが書き込みよりも一般的であるため、こうした値を書き込み時に計算し、結果をキャッシュに保管するほうが効率的です。これにより、読み取り操作は高速になり、よりスケーラブルになります。

オプション・フィールド

業務内容、自宅住所、および電話番号を保持するユーザー・レコードを考えます。これらすべてが定義されているユーザーもいれば、まったく定義されていないユーザーもいれば、一部が定義されているユーザーもいます。データが正規化されていると、ユーザー・テーブルおよび電話番号テーブルが存在することになります。一定ユーザーの電話番号は、この 2 つのテーブル間の JOIN 操作を使用して検出できます。

このレコードを非正規化する場合、データの重複は必要ありません。ほとんどのユーザーが電話番号を共有しないためです。代わりに、ユーザー・レコードで空スロットを使用できるようになっている必要があります。電話番号テーブルを使用する代わりに、各ユーザー・レコードに電話番号タイプごとに 1 つずつ 3 つの属性を追加します。この属性の追加により、JOIN 操作がなくなり、ユーザーの電話番号検索が単一区画操作となります。

多対多リレーションシップの配置

製品とその販売店を追跡するアプリケーションを考えてみます。1 つの製品が多くの店舗で販売され、1 つの店舗で多くの製品が販売されます。このアプリケーションが 50 の大規模小売業者を追跡するものとします。各製品が最大 50 の店舗で販売され、それぞれの店舗で何千もの製品が販売されます。

各店舗エンティティー内に製品リストを保持する (配置 B) 代わりに、製品エンティティーの内部に店舗リストを保持します (配置 A)。このアプリケーションが実行する必要があるトランザクションの一部を見ると、配置 A がよりスケーラブルである理由が明らかになります。

まず更新に注目します。配置 A では、店舗の在庫から製品を除去する場合、製品エンティティーがロックされます。データ・グリッドに 10000 の製品が保持されている場合、グリッドの 1/10000 しか更新の実行をロックする必要がありません。配置 B では、データ・グリッドには 50 の店舗しか含まれていないので、更新を完了するには、グリッドの 1/50 をロックする必要があります。これらは両方とも単一区画操作と考えることができますが、配置 A のほうがより効率よくスケールアウトされます。

現在、配置 A による読み取りを考えていますから、トランザクションで少量のデータのみが転送されるため、製品の販売店舗の検索は拡張され、高速な単一区画トランザクションとなります。配置 B では、製品が店舗で販売されているかどうかを確認するために、各店舗エンティティーにアクセスする必要があるため、このトランザクションはクロスデータ・グリッド・トランザクションになります。これは、配置 A の大きなパフォーマンス上の利点を明らかにします。

正規化されたデータによる拡張

クロスデータ・グリッド・トランザクションの正当な使用法の 1 つにデータ処理の拡張があります。データ・グリッドに 5 台のコンピューターがあり、各コンピューターについて約 100,000 のレコード全部をソートするクロスグリッド・トランザクションがディスパッチされると、そのトランザクションは全体で 500,000 個のレコードをソートします。データ・グリッド内の最低速のコンピューターが毎秒これらのトランザクションのうちの 10 個を実行できる場合、データ・グリッドは全体で毎秒 5,000,000 レコードをソートできます。グリッド内のデータが 2 倍になると、各コンピューターは全体で 200,000 個のレコードをソートする必要があり、各トランザクションは全体で 1,000,000 個のレコードをソートします。このデータの増加は、最低速のコンピューターのスループットを毎秒 5 トランザクションに減少させるので、データ・グリッドのスループットは毎秒 5 トランザクションに減少します。それでもデータ・グリッドは全体で毎秒 5,000,000 レコードをソートします。

このシナリオでは、コンピューターの数を 2 倍にすると、各コンピューターは元の 100,000 レコードのソートという負荷状態に戻るので、最低速のコンピューターは、これらのトランザクションを毎秒 10 個で処理できるようになります。データ・グリッドのスループットは、毎秒 10 要求という同じ状態ですが、現在では各トランザクションは 1,000,000 レコードを処理するので、処理するレコードに関してはグリッドの容量は毎秒 10,000,000 レコードと 2 倍になります。

ユーザー数の増加に合わせてインターネットとスループットの規模を拡大するため、データ処理に関して両方を拡張する必要のある検索エンジンなどのアプリケーションでは、グリッド間の要求のラウンドロビンを備えた複数のデータ・グリッドを作成する必要があります。スループットを拡大する必要がある場合、要求をサービスするために、コンピューターを追加し、別のデータ・グリッドを追加します。データ処理を拡大する必要がある場合、コンピューターを追加して、データ・グリッド数を一定に保ちます。