はじめに
第14回はストレージの動的な追加と性能の関係を解説しました。ストレージ装置を追加しただけではストレージ・サブシステムの性能が向上するわけではなく、データの配置とアクセス・パターンが適合している必要があります。
今回はこの概念の延長線上にある、複数の物理マシンでのクラスタ構成における動的なリソース増減を扱います。
なお、本連載で例として挙げるデータベースはオラクルが提供しているものが多いですが、オラクル製品を使っていない方にも参考にしていただけるように解説していきます。
対象読者
この連載では以下の読者を想定しています。
- データ資産を活用する、新しいアプリケーションの構想や設計を担われる方
- データ基盤の運用を担われている方や、今後検討される方
- 新たに開発するアプリケーションの、最適なデータベースをお探しの方
- 目的別データベースから、価値ある情報を素早く引き出す検討をされている方
クラスタ構成におけるリソースの動的増減
第13回では1台のマシン内におけるCPUとメモリーの動的増減を解説し、第14回ではストレージの動的増減について解説しました。今回はクラスタ構成におけるハードウェア・リソースの動的増減に着目して解説します。複数台の物理サーバーでデータベース・システムを構成するクラスタは第5回で一度扱っていますが、今回はそのリソース増減についてです。
データベースのハードウェアを動的に増減したい動機の例として「同時にアクセスするユーザーが増えるオンライン・トランザクション処理に対処する」といったものがあります。
クラスタ構成は1台の物理マシンを超えるハードウェア・リソースを使用することができます。大規模な同時ユーザー数によるアクセスがあるサイトでは、性能と可用性を向上させるためにデータベースもクラスタ構成がとられます。近年のクラスタ・データベース・エンジンはデータベースを稼働させたままクラスタ・ノードを動的に増減させることに対応していますが、クラスタ・アーキテクチャによってその考慮点が変わってきます。望ましいのは、データベース・スキーマの論理設計を変更することなく透過的にハードウェア・リソースの増減に対応できることです。
まず、1台のマシン内においては、データベースへのリクエストを処理するプロセスがどのCPUで実行されるかはOSのスケジューラーが決定します。プロセスがCPUに割り当てられる時間は数十ミリ秒という人間の感覚からすると一瞬を単位としており、どのCPUで実行されたとしても、実行時間は精密な測定をしなければほとんどわからないくらいの差しかありません。これは、複数存在しているCPUコアと、プログラムやデータが格納されているキャッシュ・メモリーとの時間的な距離が極めて近いため、プロセスがどのCPUコアで実行されたとしてもメモリーへのアクセス時間にあまり差がないためです。
一方、クラスタ構成においては、1台の物理マシン内におけるCPUコアからメモリーへのアクセス時間と比較して、別の物理マシンへネットワーク経由でアクセスするのに数千倍以上のオーダーの時間がかかります。そのため、ある処理を実行するとき、なるべく物理マシン間のネットワーク転送が少なくなるようなアクセス・パターンになっていないと性能の向上が見込めません。クラスタにハードウェア・リソースを追加したら性能が向上するとは限らないのです。
データの配置とアクセス・パターンが適合していないと性能向上しないというのは、第14回で解説したどのストレージ・デバイスにどのデータが格納されているかが影響するということと同じです。
データベースのクラスタ構成においても、クラスタ・アーキテクチャの物理構成がデータ配置の物理構成と強く結びついているため、データベース設計者のデータ物理配置設計が性能のスケーラビリティに強く影響します。
2種類のクラスタ・アーキテクチャ
連載第5回でも解説しましたが、性能をスケール・アウトさせるクラスタ・アーキテクチャには大別するとシェアード・ナッシングとシェアード・エブリシングがあります。シャーディングというのはシェアード・ナッシング・クラスタの各ノードにデータをパーティショニングする手法の一種です。
シェアード・ナッシング・クラスタはデータをパーティショニングし、各DBサーバー・ノードに保持させるデータが排他的な配置になっています。「クラスタにノードを追加する」という言葉は、DBサーバーとそのサーバーに排他的にアクセスされるストレージのセットを追加するという意味になります。また、既存データを追加したノードとストレージにも再配分します。
物理的にストレージ・ノードが各DBサーバー・ノードから排他的にアクセスされるストレージ構成の場合、各サーバー・ノードはデータのパーティションを排他的に保持しているため、データの再配分をするにはDBサーバー・ノード間のネットワークを通してデータを複製する必要があります。大量のデータを移動させるには相応の時間がかかり、また、移動中のデータへのアクセスが継続できるのか、という課題があります。
この課題に対応するため、近年のシェアード・ナッシング・クラスタでは、ストレージ・ネットワークとしてはDBサーバー・ノードからすべてのストレージ・ノードへのアクセス・パスが存在し、ストレージ・ノード側ではデータを移動させずに、DBサーバー・ノードからアクセスするデータのパーティションを短時間で切り替えるというものもあります。これはクラウド・プラットフォームのように「あらかじめ大量の物理ハードウェアが存在している」ということを暗黙の前提としており、支払いの課金に応じて使用可能なハードウェアが増えるという課金モデルです。いずれの移動方式にせよ、シェアード・ナッシング・クラスタにおいてノード間のデータの再配分を行う間、移動対象のデータ・パーティションへのアクセスができない時間が発生します。
シェアード・ナッシング・クラスタに対し、シェアード・エブリシング・クラスタはすべてのDBサーバーがすべてのストレージにアクセスすることができ、1つのDBサーバー・ノードがデータベースのすべてのデータにアクセスできます。「クラスタにノードを追加する」という言葉の意味はシェアード・ナッシング・クラスタとは異なり、DBサーバー（CPUとメモリーのリソース）だけを追加するということを指します。そして、スケール・アウト型のストレージ・ノードの追加はDBサーバー・ノードの追加とは独立しています。DBサーバー・ノードを追加または削除しただけではストレージの構成は変化しないため、データの再配分は発生しませんし、そもそも不要です。データの再配分が発生するのはストレージ・デバイスを物理的に増減させる時です。
シェアード・エブリシング・クラスタはDBサーバー・ノードをクラスタに動的追加／削除する間も既存ノードはすべてのデータへのアクセスが可能です。そして、ストレージ・デバイス間でデータを再配分する間もすべてのデータへのアクセスが可能です。
