db tech showcase tokyo 2014の資料。 株式会社gloopsで、3年間80台の運用経験から得た20の教訓をご紹介します。

1. dbtech showcase Tokyo 2014
株式会社gloopsシステム統括部情報システムG
Microsoft MVP for Windows Azure
大和屋貴仁
SQL Server運用実践
3年間80台の運用経験から20の教訓

2. 株式会社gloops (グループス)
Windows Server / IIS / SQL Server
Redis/ memcached/Nginx/ icinga/ fluentd/ kibana/ ElasticSearch
ソーシャルゲームの開発・運用をする
エンターテイメント会社
Windows Server とLinuxのハイブリッドインフラ
データベースにSQL Serverを採用

3. gloops のデータベース・サーバー
5万人の同時接続ユーザーがリアルタイムバトルで
遊んで連打する
秒間5万クエリ
一日200GB の更新量
24時間で出力される
トランザクションログバックアップの総合計量

4. gloops のデータベース・サーバー
gloops で運用しているデータベース・サーバーの台数
クローズしたコンテンツや故障交換も含めると150台
80台のSQL Server
NAND型フラッシュメモリベースの高速なストレージを
2011年から採用し続けている
Fusion-ioDrive2

5. 大和屋貴仁
システムインテグレーターで5年間のデータベースSE
gloopsで3年間のデータベースアドミニストレーター
8年間のSQL Server 経験
2011年から4年間、マイクロソフトからMVPアワードを受賞
SQL Azureの分野で2年、WindwosAzureの分野で2年
Microsoft MVP

6. BIOS を適正にバージョンアップする
BIOSのバグによりメモリ破損が発生する
メモリ破損の影響を受け、論理データ不整合が発生する
論理データ不整合が発生していてもDBは動作し続ける
不整合が発生している箇所を読み取った時のみエラーが発生する
それ以外は意外とまっとうに動作する
インデックスの再構築がトリガーとなりデータベースが
起動しなく大規模障害発生
現在使用しているBIOSのバージョンが最新か確認する。
最新じゃない場合は、最新のバージョンで何が修正されているかを把握する
1

7. sqldumpが出力されていないか確認する
SQL Server は致命的なエラーが発生した場合、
SQLDump****という名前のダンプファイルを
SQL Server ログ配下に出力する
同フォルダーにexception.logも出力する
これらのファイルが生成されている場合、
最悪の場合論理不整合などが発生している可能性がある
データベースが起動しなくなる大規模障害の
可能性があるので出力されていないかを監視する
2

8. SQL Server を適正にバージョンアップする
SQL Server は、SPとCUをリリースしている
SPとCUで修正されているバグを確認し、
自社で使用する際に問題となるものが
含まれていないか確認する
gloopsでは、3 つのバグに立て続けに遭遇した
SP1は、SQL Server サービスが予期なく停止する
SP1 CU4は、コネクションプーリングがらみの問題
SP1 CU6は、NW接続が不安定になる（trans-port level error）
3

9. SQL Server の問い合わせ窓口を確保する
有償製品を使う最大のメリットは開発元のサポートを
受けられること
致命的なバグがあった場合に問い合わせ、解決することが可能
問い合わせをするためには、問い合わせ窓口の確保が必要
サポート形態はいくつかあるが、ProfessionalかPremiumを
確保する
Premiumはハードルが高いが、Professionalは利用ハードルが低い
ボリュームライセンス契約などでSA契約を締結していれば、
SA契約の特典でProfessionalサポートを受けられる
4

10. 必要なライセンス契約を確認する
サービスを展開する前に、マイクロソフトに
ライセンス契約を確認する
ライセンスについてはマイクロソフトのライセンス部門の判断が
全てに勝る
SPLA契約・SA契約の必要有無が意外と焦点となる
ソーシャルゲームは、SPLA契約もしくはSA契約が必要となる
AWSやAzureを使用する場合には、SPLA契約下で提供されているので
気にしなくても良いことが多い
プロセッサーライセンスかCALライセンスかを吟味する
一般公開するWebサービスは、ほぼ間違いなくプロセッサーライセンスを
使用したほうが有利
5

11. 冗長化ライセンス確保のためSA契約を締結する
1つまでは冗長化環境のライセンスは不要だった
冗長環境１個まではライセンスに含まれていたので
追加ライセンスが不要だった
SQL Server 2014のリリースに伴い製品使用権、
使用許諾で許諾されていた
「フェールオーバーに関する権利」がSA特典に
変更になった（2014/4/1以降）
ログ配布、AlwaysOnなどの環境構築時に
フェールオーバー環境用のライセンスか、SA契約が必要になった
6

12. NICはケチらず信頼性の高いメーカーを選ぶ
高トラフィック環境下では、相性や品質による
原因特定しにくいパケット再送が
多発することがある
あるメーカーのNICを使用していた時に、パケットの
再送が異常な値を示していた
NWが寸断してアプリケーションエラーが発生する原因となっていた
NICのメーカーを変更し、DBのNICを入れ替えたところ、
アプリケーションエラーの減少とパケット再送が正常な範囲に
収まるようになった
7

13. データベースの容量拡張は手動で実施する
更新量が多いデータベースを運用していると初期設定
したデータベース容量を超えてることがある
自動拡張した場合、予期しないタイミングでロックされることがある
拡張サイズはパーセンテージの指定からMB指定に変更する
自動拡張は転ばぬ先の杖とし、手動で更新する
データファイルを複数に分けている場合、自動拡張されるのは、
その内の１つのみ
空き状況に応じて振り分けられるので、自動拡張してしまうと
データ処理が特定データファイルに偏ってしまう
手動で全てのデータファイルの容量を均等に増やす
8

14. トランザクションログの容量を意識する
バッチ処理などで大量にデータを更新したり、
削除する場合には、トランザクションログバックアップの頻度を
意識する
大量処理を並列に動かしたりすると、トランザクションログの
初期容量を超えて自動拡張を大量に引き起こす可能性がある
バッチ処理（コミット粒度）が大きい場合、その処理が完了するまで、
以後にコミットされたログも開放されないので必要なトランザクションログ
容量が想像以上に多くなる
トランザクションログバックアップ頻度に沿ったバッチ処理計画を組む
トランザクションログバックアップ頻度が５分なら、５分間に収まるような
コミット粒度にできないか検討する
9

15. バックアップ容量と期間の計算を慎重にする
完全バックアップモードで運用している場合、
指定日時にリストアすることができるが、
ファイルが不足しているとリストアできない
完全バックアップからリストアしたい日時までの
トランザクションログバックアップファイルが揃っている必要がある
バッチ処理などでトランザクションログを定期削除する際に誤って消しすぎた
前日分を消す際に、単純に24時間分消したら、完全バックアップは
1日に1回だったので、一部トランザクションログファイルが不足した
具体的なシミュレート計算をして、いつでも（例えば、日をまたいだり、 バッチ処理をした直後etc）でも確実にリストアできるか確認する
10

16. バックアップにかかる時間と容量を考慮する
巨大なデータベースのフルバックアップは、高速 なストレージ（Fusion-ioDriveなど）を使用してい ても1~2時間かかる
フルバックアップとDB処理負荷のピークがカサラ内容 にする
フルバックアップの容量が数100GBになると外部ス トレージに逃すにも時間がかかるし、帯域を食い つぶしてしまう
1GBのNICの帯域を食いつぶしてしまい、他の処理が遅 延したりできなくなり別の障害原因となりうる
11

17. インデックス再構築をしない
有名なパフォーマンスチューニングテクニックの一つに 断片化が進んだインデックスの再構築がある
Standardエディションだと再構築中テーブルがブロックさ れてしまう
巨大なテーブルだとFusion-ioDriveを使用していても1時間 とかかかってしまう
1時間かけて再構築してもデータの新規追加が頻繁にある テーブルだと、1日で断片化率99％になってしまった
ディスクI/Oは、Fusion-ioDriveなどで担保し、再構築を 実施しないという選択もあり
12

18. データベースの複製は一箇所集約
SQL Server のライセンスはアクティブ-アクティブ構成 の場合、両方分のライセンスが必要
データ分析などのために本番以外のサーバーで処理をした い場合、複製をする必要がある
複製をするのにMySQLのようにMaster-Slave構成が取りに くい
集約用のデータベースサーバーを用意し、大容量ストレージを 接続し複数のコンテンツを集約しライセンス費用を圧縮する
データ転送には、相当の時間がかかる
帯域の問題と、物理I/O、データ容量が多い
13

19. デッドロック対策に情報収集策を用意する
デッドロックは突発的に発生することもある
デッドロック原因を特定するには情報を収集できる体 制を用意しておく
トレースフラグ、拡張イベント、sys.dm_xe_sessionsの system_healthなどからデッドロックに関する情報を収集 する
アプリケーションログだけでは原因特定がしにくいの で、SQL Serverのログも活用する
拡張イベントは事前に仕込む必要があるが、 sys.dm_xe_sessionsは後追いでも何とかなることもある
14

20. 性能問題に備えて性能情報を収集する
普段、何も問題なかったのに深夜5分間だけ、 性能問題が発生した
性能情報をそれなりに収集しておかないと、後か らでは原因特定が困難
パフォーマンスカウンターやDMVなどのそこそこ 詳細な情報を収集しておかないと原因特定しきれ ない
収集しなければならない情報を精査し、それを グラフツールなどに格納していく
15

21. パフォーマンスカウンターの種類に注意
性能情報を収集する際にはパフォーマンスカウン ターの仕様を把握しておく
Batch Requests/secなどの値は累積カウンターになって おり、グラフ描画などをする際には差分グラフにする 必要がある
Windows標準ビュワーでは、よろしくやってくれてい るが、そのせいで仕様をしらないことがある
グラフ描画の値がおかしくなってしまう
差分を格納するようにし、カウンターグラフが正 しい状態になった
16

22. 実行計画が狂うことがある
突発的にクエリの実行計画がおかしくなり、CPU使用率が跳 ね上がることがある
今まで問題なかったのに、急に発生する
特定クエリのCPU時間が異常な値を示している
はっきり原因特定したわけではないが、恐らく統計情報がらみの問題
インデックスをいじったり、統計情報を更新すると終息する
何もしていないのにCPU使用率が跳ね上がったら、短期的に は統計情報の陳腐化を疑う
データ構造やデータ容量の変化で実行計画がかわることがある。 クエリヒントの使用も検討する
17

23. インデックスの作成時にはテーブル件数に留意
インデックスを作成するのに必要な時間は、対象 テーブルの件数や列数などに依存する
巨大なテーブルにインデックスを作成するには時間が かかる
Fusion-ioDrive環境下でも、200万件で6秒、2億件で15 分かかる
Standardエディションでは、その間テーブルがロックされ てしまう
低速なストレージだと、数時間単位になりうる
18

24. AlwaysOnのセカンダリの状況に注意する
AlwaysOn可用性グループで同期コミットを形成し ている時に、セカンダリ側を再起動したらレスポ ンスが遅延した
セカンダリ側がダウンしたことを検知したら、同期 ジョブはキューイングされる
検知する前に同期処理が始まったものは、TrasactionDelayが発生し、そのタイムアウトは10秒なので、10秒 間クエリが処理されないことがある
メンテナンス前には、Alter文（HADR SUSPEND） で同期を停止しておくといい
19

25. ユーザーのアクセス権管理は悩みの種
データベースのアクセス権は慎重に設定する必要があるが、 適切な範囲の維持が大変
複数のエンジニアが在籍している環境で、ユーザー個別にアクセ ス権を制御するのは一手間
Web.configの接続文字列などにパスワードが平文でっかれていた り
データベースのアクセス権を適切に設定し事故を未然に防ぐ ために共有アカウントを廃止したいが、なかなかできない
gloopsの場合、WebゲームはMobage経由でりりーするので、 ユーザー情報はしかUIDしか保持しないので個人情報問題の懸念 はない
20