検証：SQL Server 2005＋HP Superdome ―　SQL Server 2005 SP1のスケーラブルな性能とミラーリング機能をエンタープライズ・サーバで徹底検証　― 第1回　SQL Server 2005の性能と可用性を実機評価する

　2005年末にマイクロソフト社製データベース・システムの新版、SQL Server 2005が発売され、2006年5月にはサービスパック１の提供が開始となった。このSQL Server 2005では、可用性や性能向上などを目的とする、多岐にわたる新機能追加・機能強化が実施されているとされる。

　しかしシステム導入を担当する者にとって最も気になるのは、単なるカタログ・スペックだけでなく、それらが実際のシステム構築でどれだけ価値があるかということだ。特にデータベース・システムなどのサーバ・ソフトウェアは、複数のアプリケーションやほかのミドルウェア、ネットワーク・システムやストレージ・システムなどが複雑に関係し合うエンタープライズ環境で使用される。ユーザーとしては、単一製品の機能や性能よりも、実際の運用環境でそれらがどう活かされるのか、可用性やパフォーマンスにどのような効果をもたらすのかを知りたいのだが、これを実際に検証するのは容易ではない。

　この疑問に応えるべく、数々のミッション・クリティカル・システムを構築してきた経験を持つ日本ヒューレット・パッカード株式会社（以下日本HP）は、マイクロソフトおよびマイクロソフトデベロプメントの協力のもと、自社のエンタープライズ・サーバであるHP Integrity Superdomeを使用し、実システムと同等の環境を構築して、HP Integrity ServerとSQL Server 2005を組み合わせた際の性能と可用性の実際を徹底検証した。これらのうち、SQL Server 2005（SP1）の新機能として注目されるデータベース・ミラーリング機能の検証結果は、上記3社から共同発表され、以下のように誰でも参照できるようになっている。

HP Integrity Superdome

　本稿では、今回の検証レポートを担当した日本HPの江田幹 氏（日本ヒューレット・パッカード株式会社 テクニカルセールスサポート本部 シェアードサービス本部 ミドルウェアソリューション シニアITスペシャリスト）にうかがった検証結果と、本レポートの中から、一部をご紹介する。

　ビジネス・アプリケーションにおけるデータベース・システムは、いわば心臓のような存在である。データベース・システムの性能が、システム全体の処理性能に及ぼす影響は非常に大きい。一般にデータベースは、一貫性保証とデータ同期の問題などがあるため、スケール・アウト型*1のスケーラビリティ確保よりも、プロセッサの追加などにより、サーバ・ハードウェア単体の性能向上を図るスケールアップのほうが容易だとされる。つまり、将来の処理要求増大にも対応できるスケーラビリティを確保するには、スケールアップが可能なサーバ・ハードウェアをデータベース用に採用することが望まれる。

　エンタープライズ環境向けのサーバでは、各社ともプロセッサ追加などによるスケールアップ・オプションを用意している。しかし問題は、プロセッサを何個搭載できるかではなく、搭載プロセッサ数に応じて、期待どおりリニアに性能が向上するかどうかである。プロセッサ以外にシステムのボトルネックが存在すると、一定の数で性能向上は頭打ちになり、それ以上いくらプロセッサを追加しても、性能向上に寄与しない可能性があるからだ。例えば、OSやアプリケーションがマルチプロセッサに未対応であったり、64bit未対応だったりした場合、十分にスケールせず、大容量メモリがフルに利用されることはない。

　今回日本HPは、ハードウェア、OS、アプリケーションのすべてがスケール可能なシステム構成からなるSQL Server 2005とSuperdomeサーバの組み合わせにおいて、プロセッサ・スケーラビリティがデータベース・システムの性能にリニアに影響を及ぼすかどうかをマイクロソフト、マイクロソフト・デベロップメントと共同検証した。このテストでは、実システム環境に実際に使用されるものと同様のデータベースを作成し、キューブ作成のための集計処理を実行する。このテストを、8プロセッサ、16プロセッサ、32プロセッサのシステムでそれぞれ実行し、処理時間の変化を計測した。計測に用いたシステム構成は以下のとおり（なお、HP Integrity SuperdomeがなぜDBサーバをはじめとするエンタープライズ・サーバに適しているかについては、第2回でご紹介する予定だ）。

　スケーラビリティ・テストの結果は以下のとおりである。

グラフ　スケーラビリティ・テストの実行結果

　このように、8プロセッサ→16プロセッサで性能は約1.9倍、16プロセッサ→32プロセッサで約1.7倍と、プロセッサ数に応じて、ほぼリニアに性能が向上することが実証された。以下の画面は、32プロセッサでのテストで、Windowsのタスク・マネージャを表示し、プロセッサの使用状況を確認したところである。画面から、特定のプロセッサに処理が集中するのではなく、すべてのプロセッサがまんべんなく使われていることが確認できる。今回のテストは32プロセッサまでだが、HP Integrity Superdomeの最大搭載プロセッサ数は64である。今回の結果を拡大して、64プロセッサまでリニアに性能が向上するとは一概にいえないが、下の画面を見れば、32個を超えるプロセッサを搭載した場合でも、ある程度リニアな性能向上が期待できるだろう。

テスト中のタスク・マネージャによるCPU使用率表示

　データベース・ミラーリング（以下DBミラーリング）は、SQL Server 2005 SP1から提供された新機能である。これは、従来のようなOSレベルのクラスタリング（MSCS：Microsoft Cluster Service）ではなく、SQL Server 2005のソフトウェア・レベルでのデータベースのミラーリングを実現し、可用性向上を可能にするものだ。具体的には、プリンシパル（本番系）とミラー（待機系）の2つのSQL Server 2005を用意し、プリンシパルからミラーに対し、データベースに加えられた変更などをトランザクション・ログとして送信し、両者間でデータベースを同期する。接続回線には、通常のTCP/IPネットワークを使用できる。

SQL Server 2005のデータベース・ミラーリング

　ミラー・システムを構成する際、Witness（ウィットネッス。「立会人」の意）と呼ばれる第3のサーバを用意することで、障害時の自動フェールオーバー機能を実現できる（手動復帰でよければ、Witnessは不要）。

　このSQL Server 2005のDBミラーリングの特長は、MSCSとは異なり、ソフトウェアだけでデータベースの多重化を実現できることだ。このためプリンシパルとミラー、Witnessは、必ずしも同一構成のハードウェアでなくてもかまわない。手軽な可用性向上が可能になるわけだ。なお必要なら、従来のMSCSとこのミラーリングを組み合わせることもできる。

　プリンシパルとミラーの動作モードには、「同期モード」と「非同期モード」の2種類がある。同期モードは、ミラーへのデータ同期が完了するまでトランザクションを完了しないモードである。同期モードは安全性が高い代わり、プリンシパル−ミラー間を高速ネットワークで接続しないと、トランザクション性能が低下してしまう。一方の非同期モードは、ミラーへの同期完了を待たずにプリンシパルのトランザクションを完了するモードだ。こちらは安全性が多少低下する代わりに、プリンシパルとミラーが低速なネットワークで接続されていても、同期モードほどトランザクション性能に影響を及ぼさない。例えば、遠隔地にデータを多重化するディザスターリカバリなどに応用できるモードである。

　今回検証を実施した3社は、前述のパフォーマンス・テストでも使用したHP Integrity Superdome（8プロセッサ、32Gbytesメモリ）を用い、SQL Server 2005のDBミラーリング単体によるミラーリング環境、およびMSCSとSQL Server 2005のDBミラーリングを組み合わせた高可用環境などさまざまな構成を実際に構築し、障害時のフェールオーバーがどのように起こるか、ミラーリングによる性能上のオーバーヘッドがどれほどか、などを検証した。

　紙面の都合ですべてをご紹介することはできないが、プリンシパル／ミラー／Witnessの3台構成による高可用性モードで（同期モード）、各サーバで障害を発生した場合の挙動をご紹介しよう（すべての結果は、前出のドキュメントから参照できる）。

　このように、Witnessが稼動していれば、プリンシパルが障害を起こしても、自動フェールオーバーが発生し、ミラー側を使ってデータベース処理は続行される。なお意外にも今回のテストで、プリンシパルが正常稼動していても、ミラーとWitnessの双方が停止すると、データベースは利用できなくなってしまうことが分かった。

■DBミラーリングの性能評価

　可用性向上についての注意点は理解できたが、DBミラーリングは、データベース性能にどれほど影響を及ぼすのか。日本HPは、100万レコードからなるテスト用のデータベースを用意し、DBミラーリングの有無、同期／非同期のDBミラーリング環境において、参照処理、更新・挿入処理（10万レコードの単純Insert）などの性能がそれぞれどのような影響を受けるのかを検証した。

　この結果、参照処理においては、プリンシパル側でコミットが発生しないため、ミラーリングでは何の処理も行われず、DBミラーリングの有無、同期／非同期のDBミラーリングとも、ほとんど性能に変化はなかった。

　一方の更新・挿入処理では、ミラー側での処理が発生するため、コミット数が一定以上に増えると性能低下が見られた。大量のコミットが発生するような用途では、十分な性能検証をした上でDBミラーリング導入を決定する必要があるだろう。

　また当然ながら、低速なネットワークでプリンシパルとミラーを同期モードで接続した場合には、ネットワークの遅延に応じてトランザクション性能が低下した。遠隔地接続など、低速なネットワーク、ないし性能が保証されないネットワークでプリンシパルとミラーを接続する場合には、非同期モードを選択するべきだ。

　一部で厳しい結果も得られたが、SQL Server 2005＋Superdomeという今回のテスト環境は、総じて期待を裏切らない性能を示した。SQL Server 2005のDBミラーリングは、手軽かつ柔軟な構成が可能な高可用オプションの1つとして有用だろう。可用性向上という意味では、ストレージ関連のエラー処理が十分とはいえない部分もあるが、MSCSと組み合わせることで弱点を相互補間し、高可用システム（HAシステム）構築が可能である。

　これまでSQL Serverというと、中小規模のデータベース・サーバとして使われることが中心だったが、今回のテスト結果より、HP Integrityサーバのようなエンタープライズ環境でSQL Server 2005を稼動させることで、中規模からミッション・クリティカル領域のシステムにおいても、十分通用することが実証されたといってよいだろう。