障害にならないためのMySQL運用

1. 障害にならないためにどうするか障害になったらどうするか 2015. 04. 21 ビアバッシュLT @ DMM.com Labo

2. 島津純哉 • 北海道札幌市生まれ • 金沢大学 → DMM.comラボ • サーバーサイドエンジニア（フロントも少し兼任） • 好きなマンガ孤独のグルメ

3. 2013年9月サービスイン 1年半運用に携わってきました

4. ブラウザでも動きますアプリはほぼWebView フロントエンド  HTML + CSS + Javascript サーバーサイド  PHP + MySQL + Apache + CentOS

5. 運用でやってきたこと • 新機能、イベント追加作成 • カスタマーサポート対応 • システムリファクタリング • ユーザー動向の分析 • パフォーマンスチューニング • 障害対策・対応 • etc…

6. 運用でやってきたこと • 新機能、イベント追加作成 • カスタマーサポート対応 • システムリファクタリング • ユーザー動向の分析 • パフォーマンスチューニング • 障害対策・対応 ← 今日のお話 • etc…

7. ̶̶̶ 障害対応ってどんなことしてるの？

8. 実際に起こった障害 • DBまわりのトラブル • ミドルウェアレベルのトラブル • ハードウェアレベルのトラブル • DDOS攻撃 • 連携先APIでのトラブル

9. DDOS 1% ハードウェアレベルのトラブル 4% ミドルウェアレベルのトラブル 4% APIトラブル 14% DBトラブル 78%

10. DDOS 3% ハードウェアレベルのトラブル 3% ミドルウェアレベルのトラブル 3% APIトラブル 14% DBトラブル 78% ほとんどDBまわりのトラブル …ということで、本日はDBに着目したお話です

11. DBにおけるトラブルクエリの遅延ハードウェアの性能限界

12. DBにおけるトラブルクエリの遅延 → 多かったハードウェアの性能限界 → ほとんどなかった

13. いつ起こるの？ • 今じゃない • ユーザーのアクセスが増えてきたとき • 参照するデータ件数が増えてきたとき

14. クエリ遅延を防ぐためにしていた3つのこと 1. 安全なクエリをつくる 2. スロークエリの監視 3. スケーラブルな設計

15. クエリ遅延を防ぐためにしていた3つのこと 1. 安全なクエリをつくる 2. スロークエリの監視 3. スケーラブルな設計

16. 1. 安全なクエリをつくる • EXPLAIN しながらインデックスを最適化 • ひと手間かけてテスト環境でダミーデータを用意  するのが大事 • データの増え方、アクセス頻度まで考える

17. type  ALL, indexは危険 key  NULLは危険 rows  件数がやたら多いのは危険 Explainで見てすぐわかる危険なクエリ

18. 1. 安全なクエリをつくる 2. スロークエリの監視 3. スケーラブルな設計クエリ遅延を防ぐためにしていた3つのこと

19. 2.スロークエリの監視 • １秒以上かかったクエリを記録 • 基本的に発生しないようにする • 発生したらすぐ直す  （分析用のクエリで発生するものは例外としていた）

20. 監視ツール Munin

21. 遅延発生時平常時

22. 1. 安全なクエリをつくる 2. スロークエリの監視 3. スケーラブルな設計クエリ遅延を防ぐためにしていた3つのこと

23. 3. スケーラブルな設計負荷に合わせて増設できるようにしておく

24. 3. スケーラブルな設計 master slave 参照のみ書き込み & 参照レプリケーション

25. 3. スケーラブルな設計 master slave master slave UserDB (ユーザーデータ） CommonDB  (それ以外のデータ) 垂直分割

26. 3. スケーラブルな設計 master slave master slave UserDB-1  (user_id % 2 = 0のユーザーデータ） CommonDB master slave UserDB-2  (user_id % 2 = 1のユーザーデータ) 水平分割 (sharding)

27. 3. スケーラブルな設計 • ユーザーデータは水平分割したDBにもつ • 参照の増加に合わせてslaveを増やす • 更新の増加に合わせてさらにUserDBを水平分割

28. ̶̶ 障害が起こったらどうするの？

29. 障害になったら起こること • サービスの遅延 • サーバーアラート発生 • カスタマーサポート

30. DBの障害対応とは遅延のトリガーになっている  クエリを探すこと

31. クエリ遅延を見つけるためにしていた3つのこと 1. アラート・Muninの確認 2. スロークエリのログファイルを見る 3. プロセスリストを見る

33. 1. アラート, Munin確認発生した時間、対象のサーバーを知る

34. 遅延発生時平常時

36. 多すぎてよくわからない／(^o^)＼

37. 生のログはわかりにくいので  mysqldumpslow（コマンド）  を使って見やすく

38. ・  ・  ・  ※(簡単のため以下略)

39. 実行時間（平均）実行回数対象のクエリ

40. 実行時間（平均）実行回数対象のクエリわかりやすくなった＼(^o^)／  遅い順, 件数順などソートもできます

42. 3. プロセスリストを見る • mysql > show full processlist; • 実行中のクエリをすべて表示するコマンド

43. 滞留しているクエリに問題はないか？調べる DBの性能限界の場合もあるのでその場合はスケールを検討

44. 原因が特定できたら（根本的対策） case1. プログラム（クエリ）をその場で修正 case2. テーブルのインデックス最適化  （要メンテナンス、件数によっては時間がかかるので注意） case3. サーバーの増設・増強  (データセンターだと難しいが、クラウドなら）

45. 原因が特定できたら（暫定的対策） case1. 問題箇所の機能だけ停止してサービス再開 case2. 一部ユーザーをアクセス制限して負荷軽減 case3. そのまま様子見で収束を待つ  (ピーク終了が見込めるとき) …以上の対策をしたのちに根本的対策を行う。

46. ざっくりまとめ障害を防ぐのも、障害になったときもまずはスロークエリに着目するのが大事

47. ご静聴ありがとうございました

48. 細かくまとめ DB障害にならないために • EXPLAINしながらインデックスの最適化 • 監視のポイントはslow query • 設計はスケーラブルに DB障害になったら • slow query ログファイルの確認 • show processlist

障害にならないためのMySQL運用

You are reading a preview.

Check these out next

障害にならないためのMySQL運用

More Related Content

Slideshows for you (20)

Viewers also liked (20)

Similar to 障害にならないためのMySQL運用 (20)

Recently uploaded (20)