SQL Server 2005 のスケールアウト

[アーティクル]
09/29/2008

Microsoft Corporation

April 2006

対象:
SQL Server 2005

概要 : 本稿では、SQL Server 2005 データベースアプリケーションのスケールアウトに適用可能な、いくつかのテクノロジを取り上げます。特に、現在のアプリケーションに対して、どのソリューションを適用すればよいかの判断に影響を及ぼすさまざまな要因について重点的に説明します。

スケールアウトとは

スケーラビリティ とは、より有用な仕事を行うために、アプリケーションがリソースをより効率よく使用するための能力のことです。たとえば、シングルプロセッサのシステム上で 4 人のユーザーにサービスを提供できるアプリケーションがあるとき、 4 プロセッサのシステム上なら 15 人にサービスを提供することができるでしょう。この場合、このアプリケーションはスケーラブルです。もし、プロセッサを増やしてもサービスを受けるユーザーの数が増えなければ (ただし、アプリケーションがシングルスレッドで動作する場合) 、そのアプリケーションはスケーラブルとは言えません。

スケーラビリティには、スケールアップとスケールアウトという 2 つの種類があります。 スケールアップ とは、より規模が大きく、より強力なサーバーへと拡張する手法です (たとえば、 4 プロセッサのサーバーを 16 プロセッサや 32 プロセッサのサーバーへと移行するなど) 。この手法は、データベースを拡張する場合に最もよく利用されます。稼働中のデータベースが、現在のハードウェア上のリソースを使い果たしてしまった場合、おそらくはよりプロセッサの数が多く、より多くのメモリを搭載した、もっと大きなボックスを買いに出かけるでしょう。スケールアップには、データベースに対して大幅な改変を加えずに済むという利点があります。通常はデータベースをより大きなボックスにインストールし、これまでどおりに稼働を続けるだけで、データベースの処理能力が向上し、より重い負荷にも対処できるようになります。一方、 スケールアウト とは、 1 台の大規模なサーバーを使う代わりに、複数のサーバーにわたって拡張する手法です。スケールアウトには、ハードウェアの初期コスト面での利点があります。たとえば、 8 台の 4 プロセッササーバーは、たいていは 1 台の 32 プロセッササーバーよりも安価です。ただし、ライセンスや保守のコストまで含めると、多くの場合はこの利点が相殺されてしまいます。なお、可用性の観点から、スケールアウトソリューションによって提供される冗長性が役に立つ場合もあります。

SQL Server 2005 のスケールアウトテクノロジについては、これまでに多くの記事や書籍、白書などで紹介されてきたので、本稿では主に、稼働中のアプリケーションにどのソリューションを適用すればよいかの判断に影響を及ぼすさまざまな要因について重点的に説明することにします。なお、本稿の「参照資料」の節には、スケールアウトテクノロジに関するより詳細な情報への参照先を記してあります。

データの種類

成功するスケールアウト戦略を選択する上で非常に重要なポイントとなるのは、アプリケーションが複数の種類のデータを扱うということ、そしてスケールアウトのアーキテクチャ上では各種類のデータがそれぞれに異なる要求を突きつけてくるということです。もし単一のデータベースしか利用していなければ、すべてのデータを単純に同じように扱うのは、さほど難しくはありません。しかし、スケールアウトのためにデータの分割や複製を始めるとなると、適正なソリューションを選択するためには、データの使用状況を理解することが重要になってきます。多くのアプリケーションでは、スケールアウトのいくつかのアプローチが必要になりますが、それは複数の種類のデータが関与してくるからです。この節では、 3 種類のデータについて言及し、それらがスケールアウトの決定にどんな影響を及ぼすかを議論します。これらのデータの種類について、さらに詳細な情報が必要であれば、 Data on the Outside vs. Data on the Inside (英語) を参照してください。

参照データ

参照データ とは、その名のとおり、アプリケーションによって使用されるデータですが、必ずしもアプリケーションによって維持されている必要はありません。参照データは比較的不変で、特定の期間中は有効です。参照データのよい例としては、受注システムで使われるパーツカタログや、航空路線のスケジュール、および財務システムで使われる勘定科目一覧表などが挙げられます。参照データが比較的不変である理由は、他のアプリケーションから使用される可能性があるため、頻繁な変更があっては混乱を招きかねないからです。たとえば、価格表の掲載価格が1日の間に何度も変わったとしたら、顧客は混乱して苦情を言い出すでしょう (明らかな例外は、絶えず変化する株価や石油価格です) 。参照データは、たいていは固定した周期で変更されます。たとえば、物の価格は毎晩、あるいは毎週変わり、口座番号は月に一度だけ変わったりします。参照データはバージョンラベルを持っている場合もあり、そのようなラベルは、そのデータを参照するトランザクションの中に含めて使用されます。たとえば、ある購入注文は、価格がどこでどう決定されたか曖昧になってしまわないように、カタログのバージョンを参照します。商取引では、顧客が期限切れの参照データを使用してしまう問題を回避するために、複数のバージョンの参照データを許容するような場合もあり得ます。

参照データは一定期間中は不変なため、その参照データのどのバージョン (のコピー) が使われたかを判別するために、バージョン識別子が含められる場合もよくあります。これにより、整合性を損なってしまう危険性を最小限に抑えつつ、多数の異なるシステムに参照データをコピーすることができます。 Web ファームでは、カタログ閲覧のリクエストへの迅速な応答を提供するために、各 Web サーバーがそれぞれにカタログのコピーを持つことができます。多くの場合、共通の参照データはメモリ内にキャッシュされます。不変の参照データは、迅速なアクセスやオフライン閲覧の機能を提供するために、スマートクライアントに転送される場合もあります。こうなっていれば、データのコピーが紛失したり破壊されたりしても、新しいコピーを取得するのが容易です。最も新しいバージョンが利用可能かどうかを判別するために、参照データのバージョン識別子を使うこともできます。

参照データのすべてのコピーはマスターからのコピーであり、したがってマスターへの変更をしない限り、どのコピーも更新されることはありません。そのため、更新の衝突が問題となることはなく、参照データの更新状態を保つためにスナップショットとトランザクションの複製のいずれも使うことができます。マスターコピーの所有者は、データベース内に参照データを保管していないようなアプリケーションに対して参照データのコピーを返すために、サービスを公開することもできます。

以上の説明からわかるように、参照データのスケールアウトは実装するのが容易で、最小限の投資でパフォーマンスを改善することができます。参照データと同様に扱えるような、同じ特性を持った一般的な種類のデータは他にもいくつかあります。たとえば、歴史はほとんど変化しません (繰り返すことはありますが) 。そのため、四半期売上高や株価のような歴史的なデータは、参照データと同様に扱うことが可能です。

アクティビティデータ

アクティビティデータ とは、特定のアクティビティやビジネストランザクションに関連を持つデータです。たとえば、購入注文や株式売却では、そのトランザクションに関連した何らかのデータが生成されます。アクティビティデータは、特定のビジネスアクティビティの範囲の中に関連を持っており、特に歴史的な理由がない場合を除いて、いったんそのアクティビティが完了してしまえばさほどの重要性はなくなります。一般に、いったんアクティビティが完了するとアクティビティデータは参照データとなり、スケールアウトについては参照データと同様の検討事項が適用されることになります。

アクティビティデータは通常、あまり高レベルの同時性は要求しません。何百ものユーザーが所定の購入注文に同時にアクセスしようとすることなど、それほどあるものではないのです。これは、例外なくそうであると言い切れるほど一般的に起こるわけではありませんが、アクティビティデータのスケールアウトを考慮する際には、 1 つの原則として採用しても問題ない程度には一般的です。アクティビティデータはまた、それほど更新の頻度も高くありません。たとえば、購入注文は、一度作成されると状況の変化や配送予定日の変更などのイベントが生じたときしか変更されることはなく、しかもこれらのイベントの発生頻度は 1 秒間に何回もの更新などというものではなく、 1 日に数回といった程度に過ぎません。アクティビティデータは一般に、曖昧さなく容易に識別でき、アクティビティの範囲外からアクセスされることもあまりありません。そのため、アクセスデータがスケールアウトの目的でいくつかのデータベースにわたって分割されても、探し出すのは簡単です。特定の購入注文へのアクセスを必要とするビジネストランザクションは、一般に注文番号を識別します。したがって、その購入注文が番号範囲により分割されても、要求された購入注文にアクセスする適正なデータベースを簡単に探し出すことができます。

アクティビティデータは、多くの場合、他のデータオブジェクトにより参照されます。たとえば、特定の顧客から出されたすべての注文を、その顧客の顧客情報を格納しているのと同じデータベース内に保存することは、もしそれがごく一般的な注文の仕方なのであれば、よい方法だと言えるでしょう。また、特定の仕入先向けのすべての購入注文をその仕入先専用の仕入先データベースに格納することも、同様によい方法です。

以上の説明からわかるように、必要に応じてアクティビティデータを複製するのは比較的簡単であり、スケールアウトのために必要となったときに、アクティビティデータをいくつかのデータベースにわたって分割することは、多くの場合は実際的な手段であると言えます。アクティビティデータのスケールアウトを行うための最も適切なアプローチは、データ使用の要因に応じて変わってきます。この点については、以降の「スケールアウトに影響を及ぼす要因」の節で詳しく説明します。

リソースデータ

リソースデータ とは、在庫、会計データ、顧客マスターなど、ビジネスの前提をなす核となるデータです。もしリソースデータを失うようなことがあれば、基本的にはビジネスが成立しなくなります。そのため、この最も重要なデータを常に使用できるように、リソースデータベースではデータの整合性や高可用性を確保するための機能が数多く使われています。リソースデータは通常、高レベルの同時性を要求します。その理由は、同じデータに対して、多数のアプリケーションや多数の異なるユーザーがすべてアクセスできなければならないからです。また、たいていは更新の頻度も高いのが普通です。製品の在庫量や会計残高は、 1 日の間に何度も変わるものです。大量の同時更新という点に注目すれば、リソースデータのスケールアウトが非常に魅力的なパフォーマンス改善の選択肢となりますが、データの整合性や高可用性に注目すると、リソースデータのスケールアップのほうがより実際的な手段となる場合が多いようです。

リソースデータは一般に、同時的にアクティブなデータであるに過ぎません。利用されていない口座や生産中止になった部品などは、通常は比較的不変な履歴テーブル内に維持され、その意味で参照データとなります。リソースデータのスナップショットは、歴史的あるいはレポート作成などの理由によって作成されるものであり、やはり参照データであると言えます。リソースデータに対するデータの整合性と高可用性の要件は、それが参照データに変化すればあまり重要ではなくなります。こうしたリソースデータから参照データへの変換によって、リソースデータの妥当性は維持され、リソースデータのスケールアウトのサイズが縮減されるとともに、その必要性もが低減されます。

スケールアウトに影響を及ぼす要因

これまで、データベースシステム内に保管されるデータの種類について見てきました。次に、データのスケールアウトテクノロジの選択に影響を及ぼす、データ使用の特性について探ってみることにしましょう。 SQL Server 2005 はいくつかのスケールアウトテクノロジをサポートしていますが、そのうちのどれを選択するかは、関係のあるデータやアプリケーションの特性によって大きく変わってきます。

更新の頻度

データの中には、非常に頻繁に更新されるものがあります。例としては、 Web サーバーのログデータや、工場内の機械からの計測情報などが挙げられます (これらはどちらも、 UPDATE よりも INSERT が主体となることには注意が必要ですが、本稿の見地からすれば、両者とも同じものと考えることができます) 。一方、データの中には、ほとんど更新されることがなく、実質的に読み出し専用データと考えられるものもあります。例としては、四半期売上高のような歴史的なデータが挙げられます。データウェアハウスのデータは、通常は時間外のバッチ更新によって大規模に更新されますが、ウェアハウスの稼働中は読み出し専用となります。

頻繁に更新されるデータは、たいていは効率よく複製することが困難です。その理由は、更新の複製にかかるオーバーヘッドが、複製されたコピーのスケーラビリティを抑制してしまうからです。言い換えると、データベースが変更分を複製するのに多大な時間がかかるため、データを単一のデータベース内に置いておくのに比べ、全体的なパフォーマンスの低下を招きやすいということです。スケールアウトの実現に向けて複製を考慮する場合には、データ更新の頻度についてよく理解しておく必要があります。

更新の頻度がきわめて低いデータベースは複製を簡単に行うことができるので、複製の処理は優れたスケールアウト戦略となり得ます。データベースが、ほとんどの時間帯で読み出し専用としてマークされるほど更新の頻度が低いのであれば、スケーラブル共有データベースという選択肢が有望になってきます。これについて、詳しくは後述します。

アプリケーションの改変能力

厳密にはデータの特性というわけではありませんが、アプリケーションの再設計に当たってどれほど柔軟な考察をすることができるかは、どのスケールアウト戦略が最適であるかの選択に重大な影響を及ぼす可能性があります。あるスケールアウト戦略ではアプリケーションの改変が一切不要ですが、別の戦略ではクエリやストアドプロシージャへの細かな改変がかなり必要であり、さらに別の戦略ではアプリケーションの稼働方法そのものに対する見直しが必要な場合もあります。当然ながら、最大の柔軟性が得られるのは、完全に新しいアプリケーションから仕切り直しをした場合です。そのため、新しいアプリケーションの再設計をする場合は、たとえ当初の実装で必要にはならなくても、必ずスケールアウトについて考慮しておくべきです。なぜなら、実稼働状態にあるアプリケーションがリソースを使い果たしてしまったような場合、最初からスケールアウトの設計を行うよりも、改変を加えるほうがずっと困難だからです。パッケージ化されたアプリケーションや古いアプリケーションの中には改変することができないものがあります。したがって、どのようなスケールアウト戦略も、それらのアプリケーションコードに対しては透過的である (影響を及ぼさないようにする) 必要があります。

データの分割可能性

最も効率よくデータのスケールアウトを行う方法の 1 つは、データをいくつかのデータベース間で分割し、各データベースがそれぞれデータの一部の処理を受け持つというものです。これは、データをスケールアウトするための自明な方法と言えますが、すべてのデータを効率よく分割できるとは限らず、もし分割できたとしても、その分割の方法がパフォーマンスに大きな影響を及ぼします。

分割の影響を示す例として、注文データベースを分割するケースについて見てみましょう。まず 1 つには、何が注文されたかに基づいて注文を分割する方法があります。たとえば、あるデータベース内には書籍の注文、別のデータベース内には衣類の注文、といった分け方です。書籍と衣類の両方を含む注文の場合に起こるような明らかな問題は別にしても、もしクエリのほとんどが注文と顧客を結合 (join) するようなものだったとすると、この方法はうまく動作しないでしょう。なぜなら、このような結合では、注文の照合のために注文データベースをすべてチェックしなければならないからです。

また、注文データベースを分割するためには、注文番号の範囲によって分割する方法もあります。これは、注文が場所ではなく、ほとんど注文番号を使ってなされる場合にはよい方法だと言えます。しかし、顧客テーブルに多数の結合がある場合は、この方法ではやはり分散結合が必要となります。この結合の問題を解決するただ 1 つの方法は、データベースを顧客番号によって分割し、特定の顧客について、利用すべき注文データベースが必ずわかるようにすることです。これは、顧客データベースが分割されていて、かつ各顧客のための注文が同一のデータベース内に含まれている場合には特に効果的です。この場合、顧客データと結合されるべき他のデータが存在することになりますが、可能であれば、分散結合を回避するために、このデータは同じ方法に従って分割されるべきです。このデータの一部は参照データ (たとえば、商品説明) である場合もあり、それを他のすべての注文データベースに複製して、在庫データベースに対する分散結合を回避することもできます。

アプリケーションデータを複数のデータベースに分割でき、しかも複数のサーバーによってもたらされるさらなる処理能力が、結果を得るために必要な通信のコストよりも勝っている場合、そのデータは分割可能です。すべてのアプリケーションデータを効率よく分割できるとは限らないので、分割されたデータを用いた効率的なスケールアウトを実現するためには、適正な分割方法を選択することが非常に大切です。

データの相互依存と結合

スケールアウトのためにデータを分散するもう 1 つの方法は、データを用途に基づいて分けるというものです。データベースのいくつかの部分が異なるアプリケーションによって使用される場合、データベースをアプリケーションの境界に沿って分割し、各アプリケーションが自分の使用するデータ専用の処理を行うようにするとよいでしょう。もし、データの相互依存によって生じる過大なネットワークトラフィックという不利益を引き起こすことなく、専用のデータベース処理を提供するために、異なるアプリケーションにより使用されるデータを分割できるのであれば、それはよい方法だと言えます。極端な例として、すべての注文明細行が 1 つのデータベース内にあり、かつすべての注文見出し行が別のデータベース内にあるような形で注文データベースを分割すると、注文にアクセスするすべてのクエリは事実上、これら 2 つのデータベース間で分散結合を行わなければならなくなります。分散結合によって生じるネットワークトラフィックは、データの分散によって得られる利点をすべて相殺してしまうことになるでしょう。

データベースをどのように分割すればよいかを判断する最善の方法は、おそらくはデータモデルを注意深く分析することです。実体－リレーションシップダイアグラムの中に示されるリレーションシップは、結合パスと、参照整合性制約を表しています。分散データベース間をまたいで結合と制約の強制を行うと、コストが非常に高くつきます。データベースは、複数のデータベース間で参照制約を強制することはありません。したがって、関連テーブルがデータベース間で分割されると、制約は無視されるか、あるいはアプリケーションによるトリガーによって強制されなければならなくなります。このような問題を避けるためには、データモデルの中で、関連データの島 (孤立部分) を探し出すことです。これは、データモデルの他の部分に対する接続をほとんど持たないようなテーブルのグループを意味します。たとえば、一般に受注データベースでは、顧客テーブルと在庫テーブルとの間のリレーションシップはまず見つからないでしょう。

参照整合性制約の問題をあまり起こすことなく、異なるデータベース上に、どのテーブルのグループを隔離できるかを決定したら、次は更新パターンを調べる必要があります。データを複数のデータベース間に分割したことによって、データベース間にわたる大量の分散トランザクションが生じる場合は、 2 フェーズコミットの余計な更新オーバーヘッドによって、スケールアウトのいくつかの利点が相殺されてしまう場合もあります。

データ結合を考慮するための最後の要因は、共有テーブルがどのように扱われるかということです。複数のアプリケーションによってアクセスされるテーブルが、いくつか存在するとしましょう。この場合、データを分割するときには、共有テーブルをどこに配置するか決定しなければなりません。 1 つのテーブルが多数のアプリケーションから読み出されるものの、 1 つのアプリケーションからのみ更新されるようなケースでは、そのテーブルを更新用アプリケーションと一緒に配置するのは正しい選択と言えます。前述した参照整合性と分散の問題は、共有テーブルの配置にも影響を及ぼします。テーブルが比較的小さく、かついくつかのアプリケーションによって広範に使用されるのであれば、そのテーブルを複数のデータベースに複製することは道理に適っているでしょう。これは、テーブルが単一のアプリケーションによって更新される場合には最も簡単な方法であり、マスターコピーからのトランザクションの複製を使って、他のコピーを最新に保つようにすることができます。

リソースデータは、たいていは相互依存性が非常に高く、多くの整合性制約を持っています。これは、結合が密であることを意味します。そのため、場合によっては、アプリケーションによるリソースデータの分割は不可能であるか、あるいはいくつかのアプリケーションの改変が必要となります。参照データやアクティビティデータのスケールアウトは可能であり、リソースデータが密に結合している場合でもなおスケールアウトが可能であるようにリソースデータを分割することもできます。しかし、データの分割を必要とするスケールアウト戦略の中には、データアーキテクチャの見直しとともに、アプリケーションアーキテクチャの見直しまで迫るものもあります。アプリケーションの改変に関する項で説明したように、新しいアプリケーションを構築する場合、後で分割できるようにデータモデルを設計することはよい習慣であると言えます。

スケールアウトソリューション

SQL Server 2005 に向けたスケールアウトソリューションの選択に影響を及ぼす要因について理解できたところで、次はそれぞれのスケールアウトソリューションと、ソリューションの選択につながる要因について議論することにしましょう。ただし、本稿ではスケールアウトソリューションの細部にまで踏み込むことはしません。さらに詳細な情報が必要であれば、「参照資料」の節に掲げた記事を参照してください。

スケーラブル共有データベース

SQL Server 2005 に実装する最も簡単なスケールアウトソリューションは、スケーラブル共有データベースです。 SAN 上にデータベースを構築し、そのデータベースに接続された複数のサーバー上で 8 個までの SQL Server インスタンスを稼働させてから、クエリの処理を開始します。これは伝統的な「共有ディスク」型のスケールアウトソリューションであり、処理能力はスケールアウトされますが、データのディスクイメージが1つしか使用されません。ここで、 SQL Server をよく知る人なら、次のように言うでしょう。「ところで、ロックはどうなるのですか ? SQL Server インスタンスは、自身のメモリ内に自身のロックを維持していると思うのですが」。そのとおりです。それぞれのインスタンスは自身のデータベースロックを維持しており、どのインスタンスも、他のインスタンスのロックについては何も知りません。これがうまく動作するのは、ロックがないときだけです。つまり、スケーラブル共有データベースは、データベースが読み出し専用データベースとして接続されているときだけ動作するということです。したがって、スケーラブル共有データベースはデータウェアハウスやレポート用データベースには最適ですが、データを更新するようなアプリケーションには不向きです。ここで、前述したデータの特性を思い出してみると、スケーラブル共有データベースは更新の頻度がゼロである場合にのみ動作します。当然ながら、このようなデータは歴史的であり、つまりはすべてが参照データということです。図 1 は、スケールアウトソリューションとしてのスケーラブル共有データベースの利用方法を表しています。

Cc947718.aa479364_scaloutsql01(ja-jp,MSDN.10).gif

図 1　スケーラブル共有データベース

当然ながら、変化することのないデータベースの場合、限られた値しか持ちません。このようなデータベースを更新するためには、まずすべての SQL Server インスタンスがデータベースを分離し、次にインスタンスの 1 つが読み書き可能モードでデータベースに接続して、現在のデータでそのデータベースをリフレッシュすることになります。この場合、 SAN の容量が不足している状態で、変更すべきデータが大量にあるとかなりの時間がかかってしまうため、 2 つのデータベースを用意して、一方が供用中の間に他方を更新できるようにするとよいでしょう。この手法の詳細については、 SQL Server 2005 Books Online や、「参照資料」の節に掲げた記事を参照してください。

1 つのデータベースに 8 つまでのデータベースエンジンしか接続できないという制限は、技術的な制限ではなく、実地検査済みの制限です。将来のリリースでは、 8 つを超えるエンジンをサポートできるようになるものと思われます。このデータベースでは、書き込みがされることはなく、でき得る限り多くのデータがキャッシュされるため、たとえ大きな負荷のかかった 8 つのデータベースエンジンが接続されていたとしても、実際のディスク入出力の頻度はかなり低いものとなります。

多大な要求を出し続けるデータベースアプリケーションの多くは、読み出し専用モードではうまく動作します。データウェアハウスのワークロードは、比較的小数のクエリから成っており、個々のクエリはある程度静的で歴史的なデータに対する大規模で複雑な内容を持っています。ほとんどのデータウェアハウスでは、更新の頻度が毎日 1 回、ないしは毎週 1 回なので、供用中にデータウェアハウスを読み出し専用にすることは難しくありません。スケーラブル共有データベースはまた、データウェアハウスでよく見られる問題、つまり、すべてのデータベースリソースを何時間にもわたって拘束するようなクエリを書くユーザーの問題をも解決します。このようなクエリがデータベースエンジンの 1 つで実行されていても、残りのエンジンは依然として利用できるため、「地獄のクエリ」状態は最小限に留められることになります。

スケーラブル共有データベースが実用的であるのは、更新の頻度がきわめて低いときだけです。なぜなら、このデータベースは、共有されている間は一切更新できないからです。スケーラブル共有データベースでは、アプリケーションの改変はまったく不要です（ただし、そのアプリケーションがデータベースの更新を試みないという条件が付きます）。このデータベースは改変なしにスケールアウトできます。そのため、スケーラブル共有データベースの利用を検討する際、分割可能性や結合が判断の要因となることはありません。以上をまとめると、スケーラブル共有データベースは、データ更新の頻度を定期的なバッチ変更で済む程度まで減らすことの可能なアプリケーション (たとえば、データウェアハウス、データマート、レポート用データベースなど) で利用すると有用です。このような変更パターンをアプリケーションに適用できるのであれば、スケーラブル共有データベースはスケールアウトの好適な手法となります。なぜなら、このようなデータベースは実装が簡単であり、アプリケーションの改変も最小限で済むからです。

ピアツーピア複製

更新しなければならないデータがあるものの、その更新の頻度が比較的低い場合であれば、たいていは複製を利用して対処するのが最善です。データベースの 1 つのコピーを複数のデータベースエンジンでアクセスするのではなく、データベースの複数のコピーを用意して、各データベースエンジンがそれぞれ専用のコピーを維持するようにします。この手法では、データに対する更新が許容されながらも、スケールアウトの利点を得ることができます。複製は、データのすべてのコピーに対して変更を伝送するために利用されます。図 2 は、スケールアウトソリューションとしてのピアツーピア複製の利用方法を表しています。

Cc947718.aa479364_scaloutsql02(ja-jp,MSDN.10).gif

図 2　ピアツーピア複製

ピアツーピア複製は、 SQL Server 2005 で新しく採用された手法で、データに加えられたすべての変更を、他のすべてのコピーに伝送します。ピアツーピア複製では、衝突の解決は提供されないため、所与のデータ要素の 1 つのコピーだけが更新されるような構成で利用することを推奨します。たとえば、食品店チェーンの在庫管理のためにピアツーピア複製を利用している場合、在庫のエントリを所有している店舗だけが、そのエントリの更新を許されることになります。つまり、どの店舗も、他のすべての店舗の在庫を確認することはできても、自身の店舗の在庫しか変更することはできません。

データ項目の所有者だけがそのデータを更新できるような規則のことを、 データ管理責務 と呼びます。これは、データ更新の衝突を避けるためには非常に有用な方法です。データ管理責務が利用できない状況においては、衝突に対処するためにマージ複製を利用することができます。マージ複製は衝突を処理しなければならないため、ピアツーピア複製に比べてオーバーヘッドが大きくなります。そのため、衝突を回避できる場合であれば、ピアツーピア複製を利用するほうがよいでしょう。ピアツーピア複製では、データベースの各コピーから、それ以外のデータベースのコピーへと複製が行われるように設定しなければなりません。そのため、多数のデータベースが関与してくると、この処理が大きな負荷となる可能性もあります。他のコピーを最新に保つためにトランザクションの複製を利用するような単一のマスターコピーのソリューションは、データベースへの更新がデータベースの1つのコピーに制限される可能性がある場合には、最も簡単で最も効率のよい手法となります。

複製は、更新の頻度が中程度のデータに対しては好適なスケールアウトソリューションとなります。ピアツーピア複製を利用できるように、更新の衝突を排除するためには、データ管理責務を利用することができます。必要であれば、 1 つのデータベース内にあるすべてのデータについて複製を利用することができます。そのため、データが簡単には分割できない場合や、データベース間の結合が密である場合は、この方法が有用です。複製では、ほとんどの場合はアプリケーションの改変が不要なため、既存のアプリケーションを簡単にスケールアウトするために利用することができます。複製は、単一のテーブルの上、あるいはテーブルの一部の上でも動作できるため、アプリケーションデータの一部をスケールアウトするためには有用な方法です。たとえば、スケールアウトを改善するために、たとえリソースデータがスケールアウトされていない場合であっても、カタログや価格表のような参照データを複製することが可能です。また、複製は、他のスケールアウトソリューションとの組み合わせでも効果を発揮します。アクティビティデータを異なるデータベースへと分割することによってスケールアウトした場合、アクティビティデータによって使用される参照データをすべてのアクティビティデータベースに複製するとよいかもしれません。一般に複製は、 SQL Server 2005 で利用できるスケールアウトソリューションとしては、最も簡単かつ最も広範にわたって利用できる手法の1つだと言えます。

リンクサーバーと分散クエリ

SQL Server は、リモートデータベースオブジェクトに対して、それらがまるでローカルにあるかのようにクエリを送信できる能力を持っています。そのため、スケールアウトされたデータベースは、アプリケーションにとってはあたかも単一の大規模なデータベースのように見えることになります。 SQL クエリに対する主な変更点は、テーブル名に、そのデータが配置されているリンクサーバーの名前が含まれるようになる、ということです。したがって、アプリケーションの改変が困難な場合には、リンクサーバーは魅力的なスケールアウトソリューションとなります。 SQL Server 2005 では、シノニムを使うことにより、サーバー名を含む 4 つの部分から成る名前を単一の名前として表すことができます。これにより、ローカルテーブルを参照するクエリは、その内容を変更しなくてもリモートテーブルを参照できるようになります。図 3 は、スケールアウトソリューションとしてのリンクサーバーの利用方法を表しています。

Cc947718.aa479364_scaloutsql03(ja-jp,MSDN.10).gif

図 3　リンクサーバー

リンクサーバーは、きわめて結合が疎である複数のデータベースの中に、データを機能領域に応じて分割配置できるような環境では、その効果を最もよく発揮します。参照整合性制約はリモートテーブルについては機能しないので、ローカルデータとリモートデータ間のリレーションシップは最小限にする必要があります。リモートクエリは、ローカルクエリに比べてコストが非常に高く、ローカルテーブルとリモートテーブルの結合 (join) も非常にコストが高くつきます。しかも、リモートテーブルの更新には分散トランザクションが必要となります。そのため、リンクサーバーを利用したデータベースのスケールアウトを成功させるためには、リモートデータアクセスが最小限になるように、注意深くデータベースを設計する必要があります。もし、アプリケーションが、結合が疎であるデータの島 (孤立部分) ）を使用しており、かつその孤立部分にわたるクエリが比較的少ない場合は、スケールアウトソリューションの効果を向上させるために、それらの孤立部分をデータベース間に分散させることができます。異なる孤立部分を使用する複数のアプリケーションが、特定のテーブルを頻繁に使用するようなケース (このようなテーブルはホットスポットと呼ばれます) では、複製を利用することにより、それらのテーブルとローカルな関与を持つクエリのほとんどを作成することができます。

また、このソリューションによってスケールアウトされるデータベースは、すべてのアプリケーションにより使用される大半のデータが、単一のデータベースの中に収められるような形で設計されていなければなりません。たとえば、いくつかのアプリケーションが、そのクエリのほとんどで顧客データと注文データの両方を使用するようなケースでは、顧客データと注文データを異なるデータベースに分割するのは、たとえデータの結合が疎な場合であっても好ましくありません。その理由は、あるアプリケーションがどのデータベースを開いた場合でも、アプリケーションはそのデータの一部をリモートアクセスし続けると考えられるからです。これに対して、いくつかのアプリケーションが顧客データをほとんど絶え間なくアクセスする一方、他のアプリケーションは注文データにアクセスして顧客データにはほとんどアクセスしない、といったケースでは、この分割は効果的なものとなります。この場合も、 2 つのデータベースからのデータを使用するクエリが少ないのであれば、ネットワークトラフィックを減らすために複製を利用することができます。たとえば、注文に正しい顧客番号が必要であり、かつ各クエリにすべて顧客名が含まれる場合なら、顧客データベースの顧客番号および顧客名の列は、他のデータベースに複製することができます。

複製と同様、リンクサーバーは他のスケールアウトソリューションの一部として活用することもできます。どのような分散データベースの場合でも、データベースの境界を横断しなければならないようなクエリが一定数は存在します。リンクサーバーでは、このようなクエリを簡単にサポートすることが可能です。

リンクサーバーはまた、データを種類によって分割する場合にも有用です。たとえば、 60 日間を超える履歴のすべてが他のデータベースに転送される場合、リンクサーバーの実装を利用すれば、アプリケーションは少数のクエリを使って、その履歴参照データをまるでローカルにあるかのようにアクセスできるようになります。この戦略によって、参照データの処理は事実上、専用のハードウェアに移動されることになり、しかもそのデータを利用するアプリケーションに影響が及ぶことはありません。履歴に頻繁にアクセスするアプリケーションは、履歴用のマシン上で実行され、必要があるときだけ生のデータにアクセスします。

リンクサーバーのスケールアウトソリューションは、更新がデータベース全体にわたることがなければ、更新の頻度による影響を受けることはほとんどなく、したがって 2 フェーズコミットは不要です。そのため、リンクサーバーのソリューションは、 OLTP アプリケーションで効果的に利用することができます。また、リンクサーバーでは、アプリケーションの改変がほとんど、あるいはまったく不要なので、レガシーアプリケーションでの利用にも向いています。リンクサーバーの実装では通常、キー値によるデータの分割が行われることはないので、分割可能性が要因となることはありません。リンクサーバーのスケールアウトソリューションが適切であるかどうかを決定する主要な要因は、データの結合です。結合が密であると、分散クエリのオーバーヘッドが、スケールアウトによるパフォーマンスの向上分を相殺してしまうことになります。リンクサーバーが将来性のあるスケールアウトソリューションとなるかどうかを決定するためには、データのリレーションシップとアプリケーションのデータ使用状況をしっかりと理解する必要があります。

分散分割ビュー

分散分割ビュー (DPV) は、特に分割データの透過的なスケールアウトをサポートするために、 SQL Server 2000 で採用された機能です。テーブル内のデータは、分割キーに基づいて、いくつかの分散データベース内にあるテーブルの間で分割されます。たとえば、ある顧客テーブルは、顧客番号の範囲に基づいて分割されています (1 ～ 10000 番は第 1 のデータベース、 10001 ～ 20000 番は第 2 のデータベース、 20001 ～ 30000 番は第 3 のデータベース、といった具合です) 。どの顧客がどのデータベース内に配置されているかを SQL Server に知らせるために、 CHECK 制約が使用されます。特定の顧客番号にアクセスするクエリは、目的の顧客番号を含むデータベース上でのみ実行されます。特定の顧客番号を参照しないクエリは、すべての分割区画上で実行される必要があります。たとえば、ジョージ・ブッシュについての情報を見る必要があるのに、その顧客番号を知らないような場合、 SQL Server は顧客テーブルの分割区画を含むすべてのデータベースを探さなければならなくなります。同様に、顧客番号に基づく 2 つのデータベースの結合は、各データベース上で並行して実行でき、その結果はクエリが発行されたデータベースに返されます。

大半のスケールアウトソリューションと同様、 DPV をうまく利用すると、データベース間でのデータ移動を必要とするクエリの数を最小限に抑えられるようになります。 DPV データベース内のすべてのデータが同じ分割キーによって分割されている場合は、そのキーに基づく結合はすべて、ローカルに実行することができます。受注データベースを分割して、すべてのテーブルが顧客キーに基づいて分割されるようにし、かつすべてのデータベースクエリに顧客キーが含まれている場合は、どのクエリも、その顧客キーを含むデータベースにアクセスすれば回答を得ることができます。もちろん、そのキーを含まないデータベースからのクエリを実行した場合、そのクエリは分散クエリとなります。実際には、すべてのデータを同じキーに基づいて分割することは不可能なため、いくつかのテーブルは異なるキーに基づいて分割される可能性があり、大半の実装では多数のテーブルが分割されないままとなります。このため、クエリの多くは複数のデータベースにアクセスしなければならなくなるので、スケールアウト戦略が成功するかどうかは、分散クエリとローカルクエリの混合の比率によって変わってきます。分割されたテーブルと分割されていないテーブルとの結合は、コストが高くつく可能性があります。なぜなら、分割されていないデータは、その分割区画が存在するすべてのサーバーに対して送られる必要があるかもしれないからです。ローカルクエリの比率を高くするためには、分割計画を注意深く設計するだけでなく、分割のメリットを利用できるようにアプリケーションを改変する必要があります。つまり、たとえDPVが透過的なスケールアウトを提供するように設計されていたとしても、多くの場合はアプリケーションの改変が必要になるということです。多種多様なアプリケーションに適用できるような分割計画を考案するのは困難です。したがって、分割されたデータベースを、関連するアプリケーションのうちで限られたものだけが使用するような状況では、 DPV は概して有用です。 DPV の枠組みにアクセスするアプリケーションの数を制限する 1 つの方法は、データをアプリケーションごとに分割し、かつそれをキー値により分割することです。これが実行されると、アプリケーションのデータベースのうち、 DPV からの利点を享受できるほど大きなデータベースはごくわずかとなる可能性が高いため、分割されたテーブルと分割されていないテーブルの組み合わせという計画に帰着することになります。

DPV は、更新集中型のアプリケーションでは優れたパフォーマンスを示します。なぜなら、更新トランザクションの大半は少数の行にしか影響を及ぼさず、そのようなトランザクションは単一のデータベース上で実行されることが多いからです。このような特徴により、更新の頻度が高い場合は、 DPV が最も優れたスケールアウトソリューションとなります。理論上、 DPV の実装ではアプリケーションの改変はまったく不要なはずです。その理由は、このスケールアウトは SQL Server によって扱われ、アプリケーションに対しては透過的だからです。ただし実際には、スケールアウトの利点を最大限に生かすために、アプリケーションには多少の改変が必要になる場合もあります。 DPV の実装についての判断を下すための主要な要因となるのは、データの分割可能性です。データを均等に分割し、かつ分割区画をまたぐクエリを最小限にするような好適な分割キーがない場合、 DPV は有用とは言えません。適正な分割キーを探し出すためには、事前の分析や計画が多数必要となります。 DPV はデータの結合による影響をあまり受けませんが、データベース内に分割されていないテーブルが多数ある場合は、結合が密であるとデータを効率よく分配することが難しくなります。

OLTP アプリケーションはしばしば、 DPV を適用すべき最良の候補となります。なぜなら、 OLTP アプリケーションは大量のデータを保有し、かつ更新の頻度も高いからです。 DPV は、 1 つのテーブルに同じデータを保有する場合に比べて、一般により多くの管理作業を必要とします。たとえば、バックアップと復元の処理では、整合が取れた状態に復元するために、テーブルのすべての分割区画を同期することができなければなりません。スケールアウトソリューションとして、 DPV を採用するアプリケーションがそれほど多くない理由は、 DPV を効率よく実行するために比較的多くの労力が必要となるだけでなく、こうした余分な管理作業も必要になるからです。

データ依存型ルーティング

前述した DPV では、 SQL Server はデータがどのように分割されているかを理解して、どこにデータを探しに行けばよいかを判断します。一方、データ依存型ルーティング (DDR) では、データがデータベース間で分割されており、アプリケーションまたは何らかのミドルウェアサービスがクエリを正しいデータベースにルーティングします。 DDR は明らかに、アプリケーションに対してほとんど透過的とは言えません。しかし、アプリケーションがクエリをどこで実行するべきかを判断する必要が生じた場合には、アプリケーションがデータについて持っているより深い知識が、より好適な判断を導いてくれる可能性があります。 DDR はまた、現在は SQL Server が直接はサポートしていないオプションもサポートしています。たとえば、利用可能な同じデータのコピーが複数ある場合、 DDR では更新を 1 つのマスターコピーに向けて送りながら、すべてのコピーに SELECT を分配することができます。図 4 は、スケールアウトソリューションとしての DDR の利用方法を表しています。

Cc947718.aa479364_scaloutsql04(ja-jp,MSDN.10).gif

図 4　データ依存型ルーティング

大量のトランザクションを処理する大規模なデータベースの多くは、数百、あるいは数千ものデータベースサーバーをまたいで処理を分配するために、 DDR スケールアウトソリューションのバリエーションを利用しています。これらのサーバーでは、ほとんどすべてのクエリが単一のサーバーに向けて送られなければなりません。したがって、そのデータモデルは、クエリや更新で必要となるすべてのデータが、同じサーバー上に配置されるように設計されている必要があります。たとえば、ある大手のオンライン小売業者は、顧客 ID に基づいてデータベースを分割するでしょう。この場合、顧客に関するすべての情報、つまり顧客が出したすべての注文、顧客の請求状況、クレジットカード情報などは、その顧客用の顧客データとして同じデータベース内に配置されている状態にあります。これはしばしば、 顧客実体 と呼ばれます。データを分割して実体 (単一の識別子により参照される自己完結型のデータグループ) に組み入れる手法は、大半の大規模データベースの設計で採用されています。各データベースエンジンは、自身のデータベース内に含まれる顧客実体に向けたクエリを処理します。実体の数が増え過ぎた場合は、新しいサーバーが追加され、それらの実体は改めて分散配置されます。

これで、すべての顧客データを顧客 ID によって識別される実体の中に分割することができました。次の問題は、アプリケーションは、使うべき顧客 ID をどのようにして知るのか、ということです。ほとんどの場合、それは非常に簡単です。顧客が注文を出そうとするとき、おそらくはその前にログインの作業が行われているはずであり、その顧客の ID はログイン記録か何か (たとえば、 Web サーバーやクッキーの中) に含まれているでしょう。もしログインの過程がないのであれば、顧客の識別情報 (名前、ウィンドウ SID など) を顧客 ID にマッピングすればよく、これは実装するのも簡単です。このパズルの最後のピースは、顧客 ID を、顧客エントリが配置されるデータベースサーバーにマッピングするためのテーブルを用意することです。この作業が済むと、データアクセス層 (アプリケーション内、または中間層のアプリケーション内) は API を公開することができ、アプリケーションは所与の顧客エントリを格納しているデータにアクセスできるようになります。リクエストは、そのリクエストが指し示すデータに基づいてルーティングされます。これが、 DDR (データ依存型ルーティング) という名前の由来です。

ここで、 1 つの疑問が出てきます。それは「要約データを取得したり、すべての注文を探し出したりするために、何百ものデータベースにわたって検索をするにはどうすればよいのですか ? 」ということです。端的にその答えを言えば「その必要はありません」となります。 DDR アプリケーションの設計では、これらのクエリを処理するために必要となる機能を設計中に組み入れておかなければならないのです。その典型的な設計例の1つは、各注文に対する要約データを、顧客 ID とともに注文データベースの中に複製しておき、注文クエリのほとんどがその要約データにアクセスできるようにするというものです。もし、アプリケーションが注文の詳細を必要とするのであれば、要約データに含まれている顧客 ID を使えば注文の所在場所を知ることができます。ちなみに要約データは、レポート生成、データマイニング、データ分析などの目的のために、データウェアハウスやレポート用データベースにも配置されます。

DDR は、何千台ものデータベースサーバーへの大規模なスケールアウトを実現するために利用されることはほとんどありませんが、数十台のデータベースサーバーへのスケールアウトのためにこの同じ手法を適用することは、多くのアプリケーションに対する有望なソリューションとなります。このソリューションでは、データの再配置、複製の管理、要約データの抽出などの作業を管理するのが多少面倒になりますが、こうした作業の多くは反復性があり、自動化することが可能です。

DDR は、大量のトランザクションへの対処を考慮して設計されているため、更新の頻度が非常に高いアプリケーションに対しては間違いなく最適なソリューションとなります。 DDR では、自身が格納されているデータベースからデータ実体の場所を特定し、アクセスするための方法を理解しているデータ層が必要となります。そのため、 DDR は新しいアプリケーション用として最も適しています。データのルーティングを処理するために中間層のアプリケーションを利用すれば、アプリケーションコードそのものの改変は少なくて済みますが、レガシーアプリケーションを DDR に適応させるためには広範な改変が必要となります。 DDR では、データの分割可能性に対する要件は非常に高いレベルにあります。なぜなら、すべてのデータ実体の場所を特定するために分割キーを利用できるような形でデータが分割されていない限り、このソリューションはうまく動作しないからです。また、通常はデータベース全体を単一のキーで分割することは不可能なため、データの結合が疎であることも要求されます。たとえば、本稿で扱った受注システムの例では、顧客IDに基づいて在庫データを分割しても無意味です。そのため、在庫データは、専用のデータベースサーバー群 (できれば、カタログ番号に基づいて分割されたサーバー群) の中に隔離するべきです。一般に、 DDR はデータベースをスケールアウトするための手法としては最も効率が高いものですが、実装が最も難しいものでもあります。アプリケーションが再設計や修正の途上にある場合であれば、 DDR はたいていは最適なソリューションとなります。 DDR はまた、アプリケーションの一部のみをスケールアウトするためにも好適です。たとえば、注文データベース用としては DDR を利用し、残りのデータ用としてほかのスケールアウト戦略を利用することが考えられます。あるいは、注文データを削除することによって、残りのデータが十分に管理できるほど少量になっているのであれば、残っているデータをスケールアップする方法も利用できます。

サービス指向データアーキテクチャ

サービス指向アーキテクチャ (SOA) のトレンドが、 SQL Server 2005 の新しい機能と交わることによって生まれたのが、サービス指向データアーキテクチャ (SODA) です。なお、ここでは SODA のスケールアウトの側面について重点的に取り上げますが、この SODA の手法は単一のデータベースに対して適用することも可能です。

SODA ではアプリケーションを、自律的で再利用可能、かつ疎結合のサービスとともに実装することになります。これらのサービスは、定義済みのセマンティックおよびスキーマとともに、メッセージを介する形で公開されます。サービスはメッセージを介してのみ通信を行うので、サービスの拡張、サービスに対するサービスの提供、あるいはサービスの完全な置き換えさえも、サービス自体には何の影響も及ぼすことなく行うことができます。この疎結合のおかげで、再利用や配備、維持管理が容易になります。

SOA サービスの多くは非常にデータ相関性が強いため、 SOA サービスを実装する際に SQL Server 2005 で採用されたいくつかの新機能を利用することができます。 SOA 環境向けのサービスを実装するためにデータベース自体を利用する手法を、サービス指向データアーキテクチャ (SODA) と呼びます。 SODA については、「参照資料」の節に掲げたいくつかの記事で詳しく紹介されているので、本稿ではあまり深く追及することはしません。ごく簡単に言えば、 SODA はサービスブローカーを利用することにより、サービスメッセージの配送とキューイング、およびCLRストアドプロシージャとして実装されているサービスプロセスの管理を行う手法です。サービスを起動するためには、通常のデータベース接続経由で直接、または SQL Server 2005 Web Services インターフェイスを介して、サービスブローカーにメッセージを渡します。メッセージが XML ドキュメントである場合は、そのメッセージの処理やレスポンスの生成を行うために、 SQL Server 2005 の新機能である XML データタイプと XQuery を利用することができます。

スケールアウトを行うために SODA データを分割する際は、複数の方法を利用することができます。最も一般的な方法は、サービスをデータベース間で分割し、さらに各データベースのサービスで使われるデータを、各データベースがそれぞれに所有しているような形態でデータを分割するというものです。データの一部は、サービスの境界をまたいで共有されることになります。サービスが、自分自身の所有していないデータにアクセスしたい場合は、そのデータを取得するために、そのデータを所有しているサービスを呼び出すようにします。ただし、場合により、これでは効率が上がらない可能性もあります。そのため、サービスが自分自身では所有していないが頻繁に使用するデータにアクセスしたい場合には、複製やリンクサーバーの手法を利用することができます。他のサービスの中からデータに直接アクセスすることは可能な限り避けるべきです。ただし、その代表的な例外は参照データで、このデータは、それを必要とするすべてのサービスに複製することができます。

サービスの境界に基づいてデータを分割しても十分なスケールアウトの効果が得られない場合は、各サービスデータベースのコピーを複数作成して、各コピーがデータの分割区画を担当するように構成することができます。この方法は DDR と似たような動作をしますが、こちらの場合は、メッセージデータを監視し、要求されたデータを所有しているデータベースにそのメッセージをルーティングするフロントエンドサービスが提供されます。

SODA に適したデータの特性は、 DDR の場合とほぼ同じです。 SODA では、更新の頻度が非常に高いケースをうまく扱うことができます。その理由は、サービスのロジックがデータベース内で実行され、通常は 1 つのデータコピーだけが更新されるからです (ただし、複数のコピーを持つことも可能です。特に、クエリの頻度や可用性に対する要求が非常に高い場合にはむしろそうするべきです) 。 SODA では、アプリケーションを SOA アプリケーションとして書き直す必要があるので、アプリケーションに対する広範な改変ができるようにすることが要求されます。サービスを既存の SOA アプリケーションの中に移動して、データベースを SODA アプリケーションとして実行するようにした場合でさえ、いくらかの改変が必要になるでしょう。 SODA アプリケーションが複数のデータベース間で分割される場合は、データが疎結合であることが要求されます。 SODA では、データベースをまたいで所有されているサービスとデータを分割する必要はありませんが、最終的にはサービスを分割するような設計を考慮しておけば、後でスケールアウトするのが非常に容易になります。サービスのスケールアウトが、データの分割部分を処理する複数のサービスに分割することによって実現される場合は、データの分割可能性が必要となります。ただし、サービス境界に沿ってデータを分割すれば十分なスケーラビリティが得られる場合は、分割可能性は判断の要因とはなりません。

SODA モデルはまた、アプリケーションのスケールアウトに大きな柔軟性をもたらします。アプリケーションがサービスのグループとして実装され、各サービスが自身専用のデータベースに含まれている場合、それらのデータベースがすべて同じサーバーに接続されていても、また異なるサーバーに接続されていてもかまいません。実際、サービスデータ、サービスロジック、そしてサービスのためにキューイングされた作業はすべてデータベース内に格納されるため、サービスを現在のサーバー上にバックアップし、別のサーバー上でそれを復元してやれば、サービスを別のサーバーに移動することができます。サービスに関するすべてがデータベース内に含まれており、しかもすべてのサービスに関するトランザクションの整合性がデータベースによって維持されるので、処理中の作業の内容を失う恐れなしに、その作業とともにサービスを移動することができます。この柔軟性のおかげで、 SODA は SQL Server 2005 向けのスケールアウトソリューションの中でも最も魅力のあるものの1つとなっています。

まとめ

これまで SQL Server 2005 のスケールアウトについて議論してきましたが、その効果を損なう大きな阻害要因となるのが、どのようなアプリケーションにも多種多様なデータが存在する、ということです。そのため、実効性の高いスケールアウトソリューションには、異なるデータに対する異なるアプローチが含まれています。以下、データの種類ごとに例を挙げれば、次のようになるでしょう・・・・・・参照データはさまざまな場所に複製され、キャッシュされます。歴史的データは、低コストで大容量の記憶装置上に配置され、分散クエリを介して公開されます。アクティビティデータは、多数のサーバーをまたいで分割されます。そしてリソースデータは、アプリケーションにより分割されます。

スケールアウトソリューションの決定には、さまざまな要因が絡んできます。表 1 は、各ソリューションに対するこうした要因の重要性についてまとめたものです。

表 1　スケールアウトソリューションの選択に影響を及ぼす要因

	更新の頻度	アプリケーションの改変能力	データの分割可能性	データの結合
スケーラブル共有データベース	読み出し専用	改変はほとんど、あるいはまったく不要	要求なし	要求なし
ピアツーピア複製	ほとんど読み出し。衝突なし	改変はほとんど、あるいはまったく不要	要求なし	要求なし
リンクサーバー	データベースをまたぐ更新を最小化	わずかな改変	一般に不要	疎結合であることが非常に重要
分散分割ビュー (DPV)	頻繁な更新でも問題なし	多少の改変が必要な場合もある	非常に重要	ほとんど影響なし
データ依存型ルーティング (DDR)	頻繁な更新でも問題なし	大規模な改変が必要な場合もある	非常に重要	アプリケーションによっては疎結合が有用な場合もある
サービス指向データアーキテクチャ (SODA)	頻繁な更新でも問題なし	広範な改変が必要	DDR と組み合わせない限り、一般に不要	サービス間の疎結合が必要

なお、いくつかのスケールアウトソリューションは、複数のソリューションとの組み合わせが可能であることを覚えておいてください。 DDR と SOA は効果的に組み合わせることができ、複製とリンクサーバーはたいていは他のスケールアウトアーキテクチャの一部分を担当します。

データ、要件、およびアプリケーションに対する制約をよく理解すれば、スケールアウトのほぼすべてのレベルに対応できるような、実効性の高い SQL Server ソリューションを設計することができます。スケールアウトがアプリケーションの初期の要件ではない場合でも、スケールアウトについての考慮を設計中に含めておけば、アプリケーションやビジネスの成長に伴って、きっとそれが実を結ぶ日が来ることでしょう。