X

An Oracle blog about Oracle Coherence

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

Guest Author

データ処理を高速化する インメモリ・アーキテクチャ 大量データを高速に処理し、可用性/スケーラビリティを高める--コモディティ・サーバを活用したインメモリ・データ・グリッドの效用

インメモリ・データ・グリッドの基本的な仕組み

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

参照系に向いたレプリケーション・キャッシュ

これは、先にインメモリ・キャッシュのレプリケーション型として説明したものと同じ仕組みだ。アプリケーションと同一のプロセス内にキャッシュ領域を構成し、キャッシュを持つ各ノード(以降、キャッシュ・ノードと呼ぶ)間ですべてのデータを複製して持ち、変更の伝播を行う(図1)。

図1:レプリケーション・キャッシュ

1つのキャッシュ・ノードの視点で見たとき、各キャッシュはアプリケーションに対してローカルに構成されるため、読み込みの待ち時間は非常に短い。一方、書き込みに関しては、変更のレプリケーションを同期でやるか非同期でやるかによって性能が異なる。例えば、データの一貫性を考慮して同期でやる方法を選んだ場合、ノード間のレプリケーションが終わるまでアプリケーションからの書き込みは待機させられるので、その分だけ待ち時間は長くなる。

また、レプリケーションによる負荷にも注意すべきだろう。これには、変更を他のすべてのキャッシュ・ノードに送信するためのネットワーク負荷や、ネットワーク経由で受け取った変更データをデシリアライズするためのCPU負荷(レプリケート先のすべてのキャッシュ・ノードで発生)などがある。
1回当たりの書き込みで生じる負荷だが、これは無視できるほど小さいと考えられる。しかし、例えばシステム全体で1,000件/秒程度の書き込みが発生するような場合は、単純に考えても1秒間当たりに1,000件のデータ更新がすべてのキャッシュ・ノードで発生するわけで、これによる負荷は相当なものになる。よって、レプリケーション・キャッシュは、主に更新が発生しない(つまり、ノード間でのデータ同期が不要な)参照用データの格納に使われることが多い。
なお、レプリケーション・キャッシュでキャッシュできるデータ量は、1つのプロセスに割り当て可能なメモリ容量に依存するので、容量の上限に注意する必要がある。

大量データの処理を可能にするパーティション・キャッシュ

更新系には向かないというレプリケーション・キャッシュの欠点を解消したものが、次に紹介するパーティション・キャッシュだ。これはインメモリ・データ・グリッドの特徴を成すものでもあり、書き込みも含めた大量のデータ処理には欠かせない仕組みである。パーティション・キャッシュでは、事前に定義したパーティション・ロジックに従い、データを複数のキャッシュ・ノードに分割して配置する。また同時に、バックアップ・データをデータ本体(以降、これをプライマリ・データと呼ぶ)とは別のキャッシュ・ノードに配置して耐障害性を確保する。
アプリケーションは、データの実際の配置場所を意識する必要はなく、データの読み込み/書き込みのリクエストはキャッシュの管理サービス機能などによって自動的に該当データを持つキャッシュ・ノードにルーティングされる(図2)※1

図2:パーティション・キャッシュ

※1 パーティション・キャッシュでは、後述するようにキャッシュ・ノードとアプリケーション・プロセスを論理的に分けて配置するのが一般的なので、図2および以降の説明ではそのようなアーキテクチャを前提としている。

ノードの追加によるキャッシュ容量の拡張が可能

パーティション・キャッシュの最大の特徴は、キャッシュ容量を容易に拡張可能な点にある。新たなキャッシュ・ノードを追加するだけで、その分のメモリ領域がデータの格納先として追加されるので、1つのプロセスに割り当て可能な上限を大きく超えたメモリ領域を構成することが可能だ。ノードの動的な追加をサポートする製品なら、アプリケーション稼働中でも、状況に応じて容量の拡張が行える ※2
このように、ノード拡張の要件が異なるため、キャッシュ・ノードはアプリケーション・プロセスとは論理的に分けて構成することが多い。

※2 先にリスト2で示したように、アプリケーションは論理キャッシュ名(リスト中ではPerson)でデータにアクセスするので、キャッシュ構成の変更に伴ってアプリケーション・コードを書き換える必要はない。

キャッシュ・データの耐障害性とリカバリ

パーティション・キャッシュでは、プライマリ・データとは別のキャッシュ・ノードにバックアップ・データを配置することにより、インメモリでデータの耐障害性を確保する。データの書き込みは、プライマリとバックアップの両方を更新して初めて完了となるので、データの不整合は起こらない。障害時の動作は図3 のようになり、バックアップ・データから自動的にプライマリ・データがリカバリされる。
なお、バックアップ・データの数は変更することが可能であり、バックアップ数を増やせば耐障害性を高められるが、これはレプリケーション性能とのトレードオフになる。

図3:パーティション・キャッシュのリカバリ

レプリケーション負荷の軽減

パーティション・キャッシュでは、ネットワークを介したデータ・アクセスが前提となるので、読み込みの待ち時間にはキャッシュ・ノードへの1往復のネットワーク・アクセス時間が含まれる(ただし、一度読み取ったデータのコピーをアプリケーション側でローカルに保持する機能を使えば、頻繁に使われるデータの取得時間を最適化できる)。一方、書き込みの際にはプライマリ/バックアップ両方のデータを書き込むので、最低2往復のネットワーク・アクセスが生じる(これはバックアップ数が1の場合)。パーティション・キャッシュの特徴としてもう1つ重要な点は、レプリケーション時の負荷が比較的少ないので、書き込み処理の負荷分散が可能なことだ。

例えば、4ノードで構成されるキャッシュに対して1,000件/秒の書き込みが行われるとしよう。先のレプリケーション・キャッシュでは、書き込まれたデータを全キャッシュ・ノードにレプリケートする必要があるため、結局各ノードで1秒間当たり1,000件のデータ更新を処理することになる。
一方、パーティション・キャッシュの場合はどうだろうか。バックアップ数が1つの場合、1回の書き込みで1つのキャッシュ・ノードに対してレプリケートすれば済む。つまり、プライマリ/バックアップを合わせて全体で2,000件/秒、各ノード当たりでは平均で500件/秒の書き込みとなる。

以上がインメモリ・データ・グリッドの基本機能となるが、参考までに2つのキャッシュ形式の特徴を表2にまとめておこう。

表2:レプリケーション・キャッシュとパーティション・キャッシュの特徴

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.

Recent Content