sql server運用実践 - 3年間80台の運用経験から20の教訓

db tech showcase Tokyo 2014

株式会社gloopsシステム統括部情報システムG

Microsoft MVP for Windows Azure

大和屋貴仁

SQL Server運用実践3年間80台の運用経験から20の教訓

株式会社gloops (グループス)

Windows Server / IIS / SQL Server

Redis / memcached /Nginx / icinga / fluentd / kibana / ElasticSearch

ソーシャルゲームの開発・運用をするエンターテイメント会社

Windows Server と Linuxのハイブリッドインフラ

データベースに SQL Serverを採用

gloops のデータベース・サーバー

5万人の同時接続ユーザーがリアルタイムバトルで

遊んで連打する

秒間 5万クエリ

一日 200GB の更新量24時間で出力される

トランザクションログバックアップの総合計量

gloops のデータベース・サーバー

gloops で運用しているデータベース・サーバーの台数

クローズしたコンテンツや故障交換も含めると150台

80台のSQL Server

NAND型フラッシュメモリベースの高速なストレージを

2011年から採用し続けている

Fusion-ioDrive2

大和屋貴仁

システムインテグレーターで5年間のデータベースSE

gloopsで3年間のデータベースアドミニストレーター

8年間の SQL Server 経験

2011年から4年間、マイクロソフトからMVPアワードを受賞

SQL Azureの分野で2年、Windwos Azureの分野で2年

Microsoft MVP

BIOS を適正にバージョンアップする

BIOSのバグによりメモリ破損が発生する

メモリ破損の影響を受け、論理データ不整合が発生する

論理データ不整合が発生していてもDBは動作し続ける

不整合が発生している箇所を読み取った時のみエラーが発生する

それ以外は意外とまっとうに動作する

インデックスの再構築がトリガーとなりデータベースが

起動しなく大規模障害発生

現在使用しているBIOSのバージョンが最新か確認する。

最新じゃない場合は、最新のバージョンで何が修正されているかを把握する

1

sqldumpが出力されていないか確認する

SQL Server は致命的なエラーが発生した場合、

SQLDump****という名前のダンプファイルを

SQL Server ログ配下に出力する

同フォルダーにexception.logも出力する

これらのファイルが生成されている場合、

最悪の場合論理不整合などが発生している可能性がある

データベースが起動しなくなる大規模障害の

可能性があるので出力されていないかを監視する

2

SQL Server を適正にバージョンアップする

SQL Server は、SPとCUをリリースしている

SPとCUで修正されているバグを確認し、

自社で使用する際に問題となるものが

含まれていないか確認する

gloopsでは、3 つのバグに立て続けに遭遇した

SP1は、SQL Server サービスが予期なく停止する

SP1 CU4は、コネクションプーリングがらみの問題

SP1 CU6は、NW接続が不安定になる（trans-port level error）

3

SQL Server の問い合わせ窓口を確保する

有償製品を使う最大のメリットは開発元のサポートを

受けられること

致命的なバグがあった場合に問い合わせ、解決することが可能

問い合わせをするためには、問い合わせ窓口の確保が必要

サポート形態はいくつかあるが、ProfessionalかPremiumを

確保する

Premiumはハードルが高いが、Professionalは利用ハードルが低い

ボリュームライセンス契約などでSA契約を締結していれば、

SA契約の特典でProfessionalサポートを受けられる

4

必要なライセンス契約を確認する

サービスを展開する前に、マイクロソフトに

ライセンス契約を確認する

ライセンスについてはマイクロソフトのライセンス部門の判断が

全てに勝る

SPLA契約・SA契約の必要有無が意外と焦点となる

ソーシャルゲームは、SPLA契約もしくはSA契約が必要となる

AWSやAzureを使用する場合には、SPLA契約下で提供されているので

気にしなくても良いことが多い

プロセッサーライセンスかCALライセンスかを吟味する

一般公開するWebサービスは、ほぼ間違いなくプロセッサーライセンスを

使用したほうが有利

5

冗長化ライセンス確保のためSA契約を締結する

1つまでは冗長化環境のライセンスは不要だった

冗長環境１個まではライセンスに含まれていたので

追加ライセンスが不要だった

SQL Server 2014のリリースに伴い製品使用権、

使用許諾で許諾されていた

「フェールオーバーに関する権利」がSA特典に

変更になった（2014/4/1以降）

ログ配布、AlwaysOnなどの環境構築時に

フェールオーバー環境用のライセンスか、SA契約が必要になった

6

NICはケチらず信頼性の高いメーカーを選ぶ

高トラフィック環境下では、相性や品質による

原因特定しにくいパケット再送が

多発することがある

あるメーカーのNICを使用していた時に、パケットの

再送が異常な値を示していた

NWが寸断してアプリケーションエラーが発生する原因となっていた

NICのメーカーを変更し、DBのNICを入れ替えたところ、

アプリケーションエラーの減少とパケット再送が正常な範囲に

収まるようになった

7

データベースの容量拡張は手動で実施する

更新量が多いデータベースを運用していると初期設定

したデータベース容量を超えてることがある

自動拡張した場合、予期しないタイミングでロックされることがある

拡張サイズはパーセンテージの指定からMB指定に変更する

自動拡張は転ばぬ先の杖とし、手動で更新する

データファイルを複数に分けている場合、自動拡張されるのは、

その内の１つのみ

空き状況に応じて振り分けられるので、自動拡張してしまうと

データ処理が特定データファイルに偏ってしまう

手動で全てのデータファイルの容量を均等に増やす

8

トランザクションログの容量を意識する

バッチ処理などで大量にデータを更新したり、

削除する場合には、トランザクションログバックアップの頻度を

意識する

大量処理を並列に動かしたりすると、トランザクションログの

初期容量を超えて自動拡張を大量に引き起こす可能性がある

バッチ処理（コミット粒度）が大きい場合、その処理が完了するまで、

以後にコミットされたログも開放されないので必要なトランザクションログ

容量が想像以上に多くなる

トランザクションログバックアップ頻度に沿ったバッチ処理計画を組む

トランザクションログバックアップ頻度が５分なら、５分間に収まるような

コミット粒度にできないか検討する

9

バックアップ容量と期間の計算を慎重にする

完全バックアップモードで運用している場合、

指定日時にリストアすることができるが、

ファイルが不足しているとリストアできない

完全バックアップからリストアしたい日時までの

トランザクションログバックアップファイルが揃っている必要がある

バッチ処理などでトランザクションログを定期削除する際に誤って消しすぎた

前日分を消す際に、単純に24時間分消したら、完全バックアップは

1日に1回だったので、一部トランザクションログファイルが不足した

具体的なシミュレート計算をして、いつでも（例えば、日をまたいだり、バッチ処理をした直後etc）でも確実にリストアできるか確認する

10

バックアップにかかる時間と容量を考慮する

巨大なデータベースのフルバックアップは、高速なストレージ（Fusion-ioDriveなど）を使用していても1~2時間かかる

フルバックアップとDB処理負荷のピークがカサラ内容にする

フルバックアップの容量が数100GBになると外部ストレージに逃すにも時間がかかるし、帯域を食いつぶしてしまう

1GBのNICの帯域を食いつぶしてしまい、他の処理が遅延したりできなくなり別の障害原因となりうる

11

インデックス再構築をしない

有名なパフォーマンスチューニングテクニックの一つに断片化が進んだインデックスの再構築がある

Standardエディションだと再構築中テーブルがブロックされてしまう

巨大なテーブルだとFusion-ioDriveを使用していても1時間とかかかってしまう

1時間かけて再構築してもデータの新規追加が頻繁にあるテーブルだと、1日で断片化率99％になってしまった

ディスクI/Oは、Fusion-ioDriveなどで担保し、再構築を実施しないという選択もあり

12

データベースの複製は一箇所集約

SQL Server のライセンスはアクティブ-アクティブ構成の場合、両方分のライセンスが必要

データ分析などのために本番以外のサーバーで処理をしたい場合、複製をする必要がある

複製をするのにMySQLのようにMaster-Slave構成が取りにくい

集約用のデータベースサーバーを用意し、大容量ストレージを接続し複数のコンテンツを集約しライセンス費用を圧縮する

データ転送には、相当の時間がかかる

帯域の問題と、物理I/O、データ容量が多い

13

デッドロック対策に情報収集策を用意する

デッドロックは突発的に発生することもある

デッドロック原因を特定するには情報を収集できる体制を用意しておく

トレースフラグ、拡張イベント、sys.dm_xe_sessionsのsystem_healthなどからデッドロックに関する情報を収集する

アプリケーションログだけでは原因特定がしにくいので、SQL Serverのログも活用する

拡張イベントは事前に仕込む必要があるが、sys.dm_xe_sessionsは後追いでも何とかなることもある

14

性能問題に備えて性能情報を収集する

普段、何も問題なかったのに深夜5分間だけ、性能問題が発生した

性能情報をそれなりに収集しておかないと、後からでは原因特定が困難

パフォーマンスカウンターやDMVなどのそこそこ詳細な情報を収集しておかないと原因特定しきれない

収集しなければならない情報を精査し、それをグラフツールなどに格納していく

15

パフォーマンスカウンターの種類に注意

性能情報を収集する際にはパフォーマンスカウンターの仕様を把握しておく

Batch Requests/secなどの値は累積カウンターになっており、グラフ描画などをする際には差分グラフにする必要がある

Windows標準ビュワーでは、よろしくやってくれているが、そのせいで仕様をしらないことがある

グラフ描画の値がおかしくなってしまう

差分を格納するようにし、カウンターグラフが正しい状態になった

16

実行計画が狂うことがある

突発的にクエリの実行計画がおかしくなり、CPU使用率が跳ね上がることがある

今まで問題なかったのに、急に発生する

特定クエリのCPU時間が異常な値を示している

はっきり原因特定したわけではないが、恐らく統計情報がらみの問題

インデックスをいじったり、統計情報を更新すると終息する

何もしていないのにCPU使用率が跳ね上がったら、短期的には統計情報の陳腐化を疑う

データ構造やデータ容量の変化で実行計画がかわることがある。クエリヒントの使用も検討する

17

インデックスの作成時にはテーブル件数に留意

インデックスを作成するのに必要な時間は、対象テーブルの件数や列数などに依存する

巨大なテーブルにインデックスを作成するには時間がかかる

Fusion-ioDrive環境下でも、200万件で6秒、2億件で15分かかる

Standardエディションでは、その間テーブルがロックされてしまう

低速なストレージだと、数時間単位になりうる

18

AlwaysOnのセカンダリの状況に注意する

AlwaysOn可用性グループで同期コミットを形成している時に、セカンダリ側を再起動したらレスポンスが遅延した

セカンダリ側がダウンしたことを検知したら、同期ジョブはキューイングされる

検知する前に同期処理が始まったものは、TrasactionDelayが発生し、そのタイムアウトは10秒なので、10秒間クエリが処理されないことがある

メンテナンス前には、Alter文（HADR SUSPEND）で同期を停止しておくといい

19

ユーザーのアクセス権管理は悩みの種

データベースのアクセス権は慎重に設定する必要があるが、適切な範囲の維持が大変

複数のエンジニアが在籍している環境で、ユーザー個別にアクセス権を制御するのは一手間

Web.configの接続文字列などにパスワードが平文でっかれていたり

データベースのアクセス権を適切に設定し事故を未然に防ぐために共有アカウントを廃止したいが、なかなかできない

gloopsの場合、WebゲームはMobage経由でりりーするので、ユーザー情報はしかUIDしか保持しないので個人情報問題の懸念はない

20