SQL Server 2005 トランザクション・レプリケーションの最適化 (SubscriptionStreams)

マイクロソフトの植田です。

今回はレプリケーションに関する話題をご紹介したいと思います。

https://blogs.msdn.com/sqlcat/archive/2007/05/07/sql-server-2005-transactional-replication-benefit-of-using-subscriptionstreams-for-low-bandwidth-high-latency-environments.aspx 

注:下記内容に関する詳細の確認をご希望される場合は上記のブログを参照いただけますようお願いします。

本ドキュメントは以下の方を対象としております。

l 開発者、テストエンジニア、データベース・アドミニストレータ

l データベース、および、Microsoft SQL Serverについて基本的な知識をお持ちの方

l Microsoft SQL Serverレプリケーションに関して基礎的な知識をお持ちの方

Microsoft SQL Serverレプリケーションに関する概要はSQL Server 2005のBooks Onlineをご参照ください(SQL Serverのレプリケーション:https://technet.microsoft.com/ja-jp/library/ms151198.aspx)。

SQL Server 2005 トランザクション・レプリケーション:帯域幅が狭く、遅延が大きい環境でSubscriptionStreamsオプションを設定する利点

Introduction

Microsoft SQL Server 2005のトランザクション・レプリケーションを使用する際、ログリーダー・エージェントはログを読み込み、パブリッシュされるアーティクルのためのSQLステートメントを構成し、それをディストリビューション・データベースに渡します。そしてディストリビューション・エージェントはディストリビューション・データベースを読み、その「パッケージ」をサブスクライバに配布/適応します。多くの場合、それらのパブリッシャ、ディストリビュータおよびサブスクライバはトータルの送信遅延が小さい高速ネットワーク上に存在します。しかし、地理的に離れた環境のような遅いネットワーク上では回線速度は大抵、遅延の大きい狭帯域となり、そのような環境ではトータルの送信時間に悪影響を与えることは明白です。(Pingコマンドで簡単に確認できる)ネットワーク遅延はパフォーマンス低下に大きな影響を与えますが、新しいオプション“SubscriptionStreams”を使用することにより劇的にパフォーマンスが向上することがあります。“SubscriptionStreams”オプションはSQL Server 2005と共にインストールされる実行ファイル“DISTRIB.exe”(ディストリビューション・エージェントの設定を行うユーティリティ)のオプションの一つです。“DISTRIB.exe”に関する詳細についてはSQL Server 2005のBooks Onlineをご参照ください(レプリケーション ディストリビューション エージェント:https://technet.microsoft.com/ja-jp/library/ms147328.aspx

SubscriptionStreams NN

(過去のエディションのMicrosoft SQL serverでは)デフォルトでディストリビューション・エージェントはディストリビューション・データベースからサブスクライバ・データベースへトランザクションを送信するのに単一のストリームを使用します。Microsoft SQL Server 2005では、この設定はSubscriptionStreams NNパラメータを指定することにより上書きできます。NNには0(SQL Server以外のサブスクライバまたはピア・ツー・ピアトランザクション・サブスクリプションのための設定値)から64までの値を指定することができます。ただし、64という設定は、特に複数のディストリビューション・エージェントが同一サーバ上で同時実行している場合は、非現実的なスレッド数でしょう。そのパラメータは単一のディストリビューション・エージェントがサブスクライバに対してバッチ変更をパラレルで適応するために許可する接続数を表しています。たとえトランザクションがパラレル化されても、トランザクションの一貫性が維持される点が重要です。この点はプライマリ・キーにおいて効率的にハッシュ、および、分割を行い、サブスクライバでコミットする前に再度組み立てを行うことで実現できます。しかし、SQL Server Books Onlineに記載されている通り(レプリケーション ディストリビューション エージェント:https://technet.microsoft.com/ja-jp/library/ms147328.aspx)、もし一つの接続において実行、または、コミットが失敗したら、すべての接続は実行中のバッチ処理をアボートし、ディストリビューション・エージェントは失敗したバッチ処理をシングル・ストリームで再実行します。この再実行が完了するまでは、サブスクライバにおいて一時的にトランザクションの非整合が生じている可能性があります。失敗したバッチ処理が無事コミットされると、サブスクライバはトランザクションの一貫性が保たれた状態に戻ります。

The requirement (要件)

産業の先端を行く大規模なオンライン・ビジネスでは、世界中のインターネットを介して接続された地理的に分散しているオフィス間で、低遅延でも問題なく動作し、接続が切断さても24時間以内に復旧が可能であるように、データをレプリケートすることが求められます。基幹からブランチまでの「ラスト数マイル」の接続スピードは地域によって差がありますが、大抵品質の低い(遅延が大きい)、低速/狭帯域のものでした。平均的なオフィス(サブスクライバが存在する地点)は回線速度512kpbs、平均遅延200-600ミリ秒で接続されていました。パブリッシャ(例えばOLTP処理を行うサーバ)とディストリビュータは高速ネットワーク上に存在し、ディストリビュータ・サーバは4ソケットのデュアル・コアCPUを搭載しています。

テスト

OLTP処理を行うパブリッシャは最頻時に、5から10のコマンドを含むトランザクションを数百処理します。ログリーダー・エージェントはレプリケートされたトランザクションをディストリビューション・データベースに送ります。その後、ディストリビューション・エージェントが開始され、処理が終了するまでにかかった時間とスループットが測定されます。ディストリビュータとサブスクライバの間のネットワークは、帯域制御ソフトを使用して帯域を512kbpsから128kbps、遅延を300ミリ秒に制御しました。

テスト結果/発見

帯域512kbps、遅延300ミリ秒のネットワークにおいてデフォルトの1ディストリビューション・ストリームの設定を用いた場合、サブスクライバに配布される1秒あたりのコマンドのスループットは6.86でした。ストリーム数を8に増やした場合、スループットは488%向上し、40.34に到達しました。さらにストリーム数を16に増やした場合、スループットは718%向上し、56.11に到達しました、これはストリーム数8と比較して39%の性能向上です。

ネットワークの帯域を128kbpsに狭め、遅延は300ミリ秒のままにした場合、1ストリームでは1秒あたり5.9コマンドを配布し、8ストリームでは31.54コマンド/秒、16ストリームでは28.01コマンド/秒という結果になりました。Chart1はこれらの結果をグラフで表しています。

“SubscriptionStreams”オプションを使用することにより多大なスループット向上のメリットを受けることができる点も重要ですが、帯域を狭く、遅延を大きくした際の影響に着目することも重要です。今回のテスト結果ではネットワーク遅延の増加は、帯域幅の減少よりもパフォーマンスに与えるマイナスの影響が大きいことを示しています。なぜならば、すべてのトランザクションにおいてネットワークを通じてやり取りされるレスポンス/応答(ACK)に長い時間がかかるためです。また、今回のテストにおいて、狭帯域かつ大きな遅延があるネットワーク環境では、サブスクリプション・ストリームを16に設定してもスループットが向上しなかった(実際には多少悪くなっている)点も同様に重要です。このことは帯域幅の使用率が限界を超え、パラレル・スレッドを扱うコストがオーバーヘッドになっていることを示しています。

接続が切断さても24時間以内に復旧できる性能を含む要件に関して、Chart2はストリーム数の増加が復旧性能に与えるポジティブな効果を復旧時間で示しています。サブスクリプション・ストリームを設定せずに、遅いネットワーク上で復旧を行うと11時間かかるのに対して、ストリーム数を適切に設定することにより2時間程度での復旧が可能になります。このテストではネットワーク切断により24時間分のトランザクションまたは240,000コマンドが配布を待たされている状況を想定しています。

 

結論

SQL Server 2005のトランザクション・レプリケーションにおいて“SubscriptionStreams”を設定する機能は、特に遅いネットワークにおいて、パフォーマンスを大幅に向上させる効果を持ちます。しかし、多くのスレッドにおいて複数の接続が開かれているときにサブスクライバにおいてトランザクションのコミット、または、組み立て時にエラーが発生した場合、ストリームの数は一時的に1に削減され、その後設定された値に戻ります。ストリーム数の設定値を定期的に切り替えるのはコストのかかる処理です。システムを展開する前に、すべてのアプリケーション、環境について注意深くテストし、最適なストリーム数を見つけることを強く奨励します。

たとえ広帯域かつ低遅延な環境(例えば、1ギガビットの速度、0ミリ秒の遅延)であってもディストリビューション・エージェントが使用するサブスクリプション・ストリームを適切に設定することで顕著なパフォーマンス向上が見られることがあります、Chart3参照。この設定はテストして適応する価値のある特長です。

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。