こんにちは。アーキテクト部の廣瀬です。

私は2021年7月に、Data PlatformカテゴリにおいてMicrosoft MVPを受賞しました。昨年に続き2度目の受賞です。これからも受賞し続けられるように引き続きがんばります。

弊社ではサービスの一部にSQL Serverを使用しています。以前テックブログでSQL Serverの障害調査フローをご紹介しました。その中で動的管理ビュー（Dynamic Management View:以下、DMV）と拡張イベントの情報を保存（ロギング）しておき、障害調査に活用していることをご紹介しました。このロギングによって障害発生時の原因特定率が劇的に向上しています。具体的なトラブル解決事例を、以下のテックブログで紹介していますので、よろしければご覧ください。

ZOZOTOWNの冬セール負荷対策で実施したDBサーバーのCPUボトルネック調査手法
SQL Serverで断続的に発生するクエリタイムアウトの原因を調査した話
SQL Serverの障害調査フローと事例のご紹介～原因不明な障害の調査から解決まで～

本記事では、弊社で取り組んだSQL Serverロギングの仕組み作りについて詳しく紹介します。

SQL Serverロギングの有用性

パフォーマンスカウンターが提供するような数値ベースのメトリクスは、監視製品を導入すれば容易に可視化できます。そのため、クエリタイムアウト多発などの障害が発生した際に確認すれば、「CPU使用率が100％に張り付いていた」や「ワークスペースメモリの獲得待ちが多く発生していた」という事実が分かります。

しかし、これだけでは「どのクエリがそこまでの負荷増を招いたのか」「どのクエリがワークスペースメモリを逼迫させていたのか」といったクエリレベルでの原因特定には至りません。このようなパフォーマンスカウンターの値だけでは根本原因が特定できないケースに備え、他の情報も組み合わせて保存しておく必要があります。

例えば、「特定の日時において実行中だったクエリリスト」と「各クエリが消費したCPU時間と、獲得したワークスペースメモリサイズ」が後から確認できるとします。それが実現すればパフォーマンスカウンターの情報と組み合わせてクエリレベルでの根本原因を特定できます。原因が特定できれば、クエリチューニングなどの再発防止に繋がる具体的なアクションをとることが可能です。このように、障害発生時の原因特定率を向上させるためには、SQL Serverのロギングを如何に充実させるかが重要です。

続きはこちら