データベースが思い通りに動くことはDB管理者にとって大きな安心感です。しかし、ほとんどのDB管理者は、この解放感を味わうことはありません。というのは、データベース専用のストレージを持っていない場合がほとんどだからです。ストレージがすべての原因という訳ではありませんが、データベースの運用の課題となることはよくあります。

このブログは、MS SQLと連携する業界唯一のストレージ、Tintri SQL Integrated Storage、DB管理者の頭痛の種を取り除くソリューションをご紹介するブログシリーズの３回目です。下記の記事もあわせてお読みください。
第1回「概要」
第2回「可視化」

第３回のテーマは「パフォーマンス」です。Tintri SQL Integrated Storageの提供する、使用パターンとQoS要件に基づいて、データベースが最適なリソースを確実に得ることができるようする独自のテクノロジーについて解説し、メンテナンスタスクの一部をオフロードすることにより、本番SQLデータベースと基礎となるシステムの全体的なパフォーマンスを向上させる方法などについても説明します。

データベースはデータベースサーバー上に存在しますが、より具体的には、多くの場合、他のデータベースも含む仮想マシン（VM）内に存在し、そのすべてがそのデータベースサーバー上で実行されます。そして、そのVMは、他のVMとともに、ストレージシステムのLUNに割り当てられます。この一般的な構成でのパフォーマンス動作は、同じLUN上のすべてのデータベースと他のすべてのVMが同じ物理ストレージシステムへのアクセスを共有しているため、「ヒットまたはミス」になる可能性があります。つまり、LUN上の特定のデータベースまたは仮想マシンのパフォーマンスについての動作が変わりリソース使用をスパイクさせると、たとえ別のサーバーで実行されていたとしても他のデータベースにもパフォーマンスに影響を与える可能性があります。

QoS

SQL Integrated Storageが他のストレージと全く異なるユニークな点は、各データベースに、予測可能なパフォーマンスつまり保証されたサービス品質（QoS）を提供できることです。QoSには、自動QoSと手動QoSの2種類がありますので、両方をご紹介します。ストレージパフォーマンスにデータベースごとのQoSを提供できる製品は他にありません。他のストレージでもLUNまたはボリュームレベルでQoSを提供できることもありますが、これらのソリューションではLUNごとに1つのデータベースのみを構成する必要があり、全く現実的ではないからです。

自動QoS

SQL Integrated Storageは、各データベースの動作を監視/分析し、使用パターンに基づいてシステムリザーブを設定し、各データベースで必要なレベルのパフォーマンスを一貫して維持するようにします。自動QoSは、自動的にセットアップされ管理されますので、DB管理者もストレージ管理者も構成を変更する必要はありません。オペレーションも不要です。全体的な負荷が増加した場合でも、各データベースが同じ専用リソースを確保できるため、パフォーマンスの予測が可能で一貫して同じレベルのパフォーマンスを提供することできます。他のワークロードの増加によって速度が低下することはもうありません。
自動QoSにより、同じサーバー上で実行されている、または同じストレージにアクセスしている他のデータベースのパフォーマンスを低下させることなく、データベースのインデックスメンテナンスを実行できるようになります。リザーブにより、1つのデータベースがすべてのストレージパフォーマンスを占有しないようにできるからです。

マニュアルQoS

また、マニュアルで、データベースを特定の最小または最大IOPS値に「固定」に設定しパフォーマンスを制御することもできます。SQL Serverインスタンス上の1つのデータベースが他のデータベースよりも重要な場合、QoSを設定して、必要に応じてそのデータベースに可能な限り高いIOを提供することができます。例えば、重要な本番データベースが重要度の低い開発やテストのワークロードよりも優先される場合などです。
一方、あまり重要ではないデータベースがある場合は、低いQoSレベルを設定して、リソースの使用量を制限し、その分のリソースを他のデータベースで使用できるようにすることができます。つまり、ビジネス上の要件に沿ってマニュアルにて設定することができます。この機能はSQL Serverのリソースガバナーに似ていますが、セットアップが面倒な接続関連のプロセスを回避できます。

メンテナンスの負荷をオフロード

DB管理者は、データベースの継続的なメンテナンスを実行しなければなりません。これらのメンテナンスには、インデックスの再作成と整合性チェックに加え、もちろんバックアップも含まれます。しかしメンテナンスタスクのほとんどはパフォーマンスに影響を与えるため、通常は計画されたメンテナンスウィンドウまたはピーク時以外に実行されます。ただし、多くのアプリケーションはさまざまなタイムゾーンで常に実行されているため、いつメンテナンスを実行しても、パフォーマンスへの影響を受け入れることはできません。そのため、これらのタスクの一部は、週に1回、またはそれよりも少ない頻度で実行されます。
SQL Integrated Storageによりこれらのタスクの一部を別のSQL Serverにオフロードできるため、パフォーマンスへの影響を心配する必要がなくなり、毎晩実行できるようになります。では、整合性チェックをオフロードするプロセスを見てみましょう

整合性チェック

CheckDBを実行することは、データベース内にデータの破損がないことを確認する唯一の方法です。通常、CheckDBは特定のデータベースに破損があるかどうかのみを通知するもので、データベースのバックアップコピーを利用してチェックしたとしても別のシステムで実行すると機能しません。したがって、2番目のコピーで問題が見つかった場合、これらの問題が本番環境に存在するかどうかはわかりません。これに加えて、CheckDBプロセスはパフォーマンスに大きな影響を与えます。CheckDBを実行する正確な頻度については議論の余地がありますが、最も一般的な推奨事項は、少なくとも毎週実行することです。
SQL Integrated StorageによりCheckDBを別のサーバーにオフロードできますので、本番環境で使用されているのとまったく同じストレージブロックに対してCheckDBを実行できるようになります。これは、スナップショットが作成された時点で、本番データベースに破損がなかったことを確認できることを意味します。このプロセスは、問題がなく、パフォーマンスに影響を与えることなく、自動的に毎日実行するように設定できます。

どのように機能するか見て行きましょう。本番データベースのスナップショットを作成し、1つのデータベース（または必要な数）を別のSQL Serverにクローンします。次に、データベースでCheckDBを実行します。CPUとメモリは別のSQL Serverにて消費されるため、パフォーマンスへの影響はありません。各データベース（クローンであっても）には、SQLサーバーとストレージの間に独自のI/Oパスがあります。したがって、CheckDBが同じデータブロックを使用していても、データベースへの本番アクセスが遅くなることはありません。CheckDBは何度でも実行でき、本番環境へのパフォーマンスへの影響を心配する必要はありません。

コピーのみのバックアップも同じ方法でオフロードできます。ただし、このバックアップによって新しいログチェーンが作成されるため、特定の時点のデータベースリカバリを実行したり、ログファイルを復元したりすることはできません。インデックスはオフロードできませんが、QoSを使用すると、同じサーバーで実行されている他のデータベースに影響を与えることなくインデックスを実行できます。

まとめ

データベースのストレージパフォーマンスを心配する必要がなくなることにより、DB管理者の負担は大幅に軽減されます。ITチームは、ETLまたはストアドプロシージャでスローダウンが発生した理由を解明するために、非常に多くの時間を費やすことが多々あります。また、問題はまったく異なるシステムがインフラストラクチャの一部に過負荷をかけ、ワークロードを遅くすることに起因するため、答えが見つからないこともよくあります。
Tintri SQL Integrated Storageでは過去の使用サイクルに基づいて同じ一貫したレベルのパフォーマンスを維持するために必要なリソースが常に提供されます。データベース整合性チェックのオフロードは、重要なワークロードパフォーマンスを維持するのにも役立ちます。

Tintri SQL Integrated Storageで、データベースストレージの運用方法を変えてみませんか？あなたに、ビジネスにメリットをもたらすか、ぜひ体験して見てください。

Tintri SQL Integrated Storageについて、詳しくはこちらのページをご参照ください。