SQL Server運用実践 - 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

SlideShare for iOS

Views

Actions

Embeds 71

Report content

Transcript

https://twitter.com	69
http://blog.gloops.com	2