Ops側のMySQL担当の視点から ・商用HA製品からMySQLMHAによる可用性担保に移行 ・fluentd + kibanaによるリアルタイムスローログ監視導入、運用 カカクコムのDevOpsを交えながらお話します

1. DevOps MySQL in カカクコム
OSSによる可用性担保と
リアルタイムパフォーマンス可視化
株式会社カカクコム
プラットフォーム技術本部
渡邉 洋平

2. 自己紹介
• 渡邉洋平（わたなべようへい）
• 所属
– 株式会社カカクコム プラットフォーム技術本部
• 業務
– OSS系サイトインフラ担当
• 経歴
– Web開発
– DB運用
– OSS系サイトインフラ担当

3. カカクコム運営サイト紹介

4. アジェンダ
0. カカクコムのDevとOpsの紹介
1. MHA for MySQLによる可用性担保
2. リアルタイムスローログ可視化
3. 今後のDevOps MySQL

5. カカクコムのDEVとOPSの紹介

6. システムプラットフォーム部

7. システムプラットフォーム部
Dev（事業部）
Ops

8. Dev 業務内容
• アプリケーション開発
• テスト
• リリース
• アプリケーション障害対応

9. Ops 業務内容
• HW、ストレージ等の選定、検証、導入
• ミドルウェア選定、検証
• 監視設計
• サーバー構築（OS、ミドルウェアインストール）
• HW、OS、ミドルウェア障害対応
• ・・・

10. Dev
• スキーマ設計
• クエリ作成 or ORM
• スロークエリチューニング
Ops
• MySQLチューニング
• MySQL冗長化
• MySQL障害対応
• DBスキーマ本番適用
• スロークエリチューニング
提案
DevOpsのDB業務分担

11. DevOpsのDB業務分担
• Devはアプリ開発に専念
• Opsは安定したDB環境を用意

12. MHA FOR MYSQLによる可用性担保

13. これまでのDBHA（高可用性）構成
• 共有ストレージ
• 商用クラスタソフト
• Active Standby

14. ReadWrite
これまでのDBＨＡ構成
SlaveB2
LoadBlancer
SlaveDB1共有ストレージ
MasterDB VIP WEB/AP
MasterDB ActiveMasterDB Standby
レプリケーションSAN

15. 課題
• 導入までのスピード
• スモールスタートサイトへの適用
• 仮想環境での利用
• 共有ストレージ保守切れに伴うリプレース

16. 目指したHA構成
• OSSによる可用性担保
• 共有ストレージを使用しない
• リプレースが容易
• 仮想環境でも利用可能
• 既存のHA構成から移行する際もパフォーマンスを維持

17. DBHA構成の検討
• ＭＨＡ for MySQL
• mysqlfailover
• Pacemaker/Corosync/DRBD

18. MHA for MySQL
• マスターDBの自動フェイルオーバーを実現
– マスターDB障害時、スレーブがマスターに昇格
• 松信嘉範氏が作成
– 2011リリース
• MySQL5.0以降で使用可能

19. mysqlfailover
• マスターDBの自動フェイルオーバーを実現
– マスターDB障害時、スレーブがマスターに昇格
• MySQL公式
• MySQL5.6.5以降で使用可能
– GTIDの導入が必須

20. DBHA構成の検討
• mysqlfailoverで利用するGTIDの導入には
マスター、スレーブDBを同時に再起動する必要
– サービス停止が必須
• MariaDBを利用するサイトの存在
MHA for MySQLを採用

21. MHA for MySQLでの考慮事項
• MasterDBが変更されたことを
どうアプリケーションに伝えるか
– DNS変更
– VIP切り替え

22. MHA for MySQLでの考慮事項
• 構成変更に伴うDev検証コストを増やさない
– アプリケーションとのインターフェースは変えない
既存HA構成と同じVIP切替え方式

23. VIP付与の方式の検討
• MHAのScript内から直接付与
– ネットワーク不安定時の挙動に不安
• Keepalived
• Pacemaker/Corosync
– 他ミドルウェアのHA構成への展開が可能

24. Pacemaker/Corosync
• OSSのHAクラスタソフト
• Heartbeatの後継
• リソース制御等のHAの制御

25. Pacemaker/Corosync
• Pacemaker/CorosyncによるVIP管理
– mysql_monitorリソースエージェント

26. Pacemaker/Corosync
リソースエージェント
• IPaddr2
– VIPの管理
• mysql_monitor
– MySQL状態監視
– MySQLのread_onlyステータスをチェック
– read_only offの場合VIP付与候補に

27. MHA for MySQLによるＨＡ構成
SlaveB2
LoadBlancer
SlaveDB1
WEB/AP
MHA Manager
MasterDB VIP

28. MHA for MySQLによるＨＡ構成
SlaveB2
LoadBlancer
SlaveDB1
WEB/AP
MHA Manager
MasterDB VIP
Pacemaker/Corosync

29. 障害時のフロー
SlaveB2
LoadBlancer
SlaveDB1
WEB/AP
MHA Manager
MasterDB VIP

30. 障害時のフロー
SlaveB2
LoadBlancer
SlaveDB1
WEB/AP
MHA Manager
MasterDB VIP
検知

31. 障害時のフロー
SlaveB2
LoadBlancer
SlaveDB1
WEB/AP
MHA Manager
MasterDB VIP
検知

32. 障害時のフロー
SlaveB2
LoadBlancer
SlaveDB1
WEB/AP
MHA Manager
MasterDB VIP
障害状態
MasterDB

33. 障害時のフロー
SlaveB2
LoadBlancer
SlaveDB1
WEB/AP
MHA Manager
MasterDB VIP
障害状態
MasterDB
Pacemaker/Corosync

34. 障害時のフロー
SlaveB2
LoadBlancer
SlaveDB1
WEB/AP
MHA Manager
障害状態
MasterDB
Pacemaker/Corosync
MasterDB VIP

35. 障害時のフロー
SlaveB2
LoadBlancerWEB/AP
MHA Manager
障害状態
MasterDB VIP
MasterDB

36. 目指したHA構成
• OSSによる可用性担保
– MHA for MySQL, Pacemaker/Corosyncを使用
• 共有ストレージを使用しない
– スレーブがマスターに昇格するため共有ストレージは不要
• リプレースが容易
– スレーブを追加しマスターに昇格
• 仮想環境でも利用可能
– 共有ストレージに依存しないため、物理、仮想問わず適用可能
• 既存のHA構成から移行する際もパフォーマンスを維持
– DiskIOパフォーマンスはPCieSSDを利用することで可能

37. 課題
• 導入までのスピード
• スモールスタートサイトへの適用
– OSSによる構成のためいつでも導入可能
• 仮想環境での利用
– 共有ストレージ不要で、
物理、仮想に依存しない構成
• 共有ストレージ保守切れに伴うリプレース
– 共有ストレージを使用していないため、
各サイト毎に移行時期を設定可能

38. MySQL設定の変更
• binlog_format=MIXED
– マスター、スレーブデータ整合性保証
• 通常はSTATEMENT
• Semi-Synchronous Replication有効化
– スレーブへのデータ伝達保証

39. MySQL設定の変更
• binlog_format=MIXED
– 遅くなる更新クエリが発生・・・
• STATEMENTは小さかった
• が、更新されたデータ量は大きかった
• Semi-Synchronous Replication有効化
– Commit単位が大きい場合Semi-Syncが切れる
に伴う課題・・・

40. MySQL設定の変更
• binlog_format=MIXED
– 整合性が取れると判断できる場合、クエリを
STATEMENTで実行
• Semi-Synchronous Replication有効化
– Commit単位をできるだけ小さく
– 長時間実行される＝レプリケーション遅延となる
クエリの排除
に伴う課題・・・の解決

41. MySQLの変更点に伴い
• 複雑な更新クエリがHA構成の命とり
• Devもパフォーマンス状況、発行したクエリを
常に意識する必要

42. リアルタイムスローログ可視化

43. DB業務内容
Dev
• スキーマ設計
• クエリ作成 or ORM
• スロークエリチューニング
Ops
• MySQLチューニング
• MySQL冗長化
• MySQL障害対応
• DBスキーマ本番適用
• スロークエリチューニング提案

44. 今までのスローログの確認
• Cacti（モニタリングツール）で件数を確認
• 1日1回ローテート、ログ集約サーバーに転送
• pt-query-digestでログの統計を取り見やすく
– Percona Toolkit
• 当日のログはサーバーに入りgrep,awkで確認

45. 課題
• 集約されていない当日のログは
サーバーに入って見る必要
• 見る人が限られてくる
– 本当に問題が顕在化するまで見ない
• ログの前後関係が把握しづらい
– スローログの本当の原因を見つけづらい

46. 目指したスローログ解析
• リアルタイム
– Fluentdでリアルタイムログ集約
• 誰でも見れる
– KibanaのGUIによるログ確認
• 簡単に深追いできる
– どのクエリが影響して遅くなっているのか
– Kibana, Elasticsearchによるログ分析

47. Elasticsearch/Kibana4
• ログ解析プラットホーム
• ElasticsearchのデータをKibana4で解析
• elasticが開発

48. Ｆluentd（td-agent）
• ログの転送、集約を行うツール
• リアルタイムに転送
• Treasure Dataが開発

49. Ｆluentd（td-agent）
Plugin
• fluent-plugin-mysqlslowquery
– スローログの転送
• fluent-plugin-elasticsearch
– Elasticsearchへのデータ挿入

50. Ｆluentd（td-agent）
Filter
• アドホックなクエリをfilterで変換
– Where句の値の違いを吸収
– Elasticsearchで解析しやすく

51. 構成
Reverse proxy
slowquery
apache認証
DBServer
filter

52. Dashboard
スローログ件数TOP5 スローログ総秒数TOP5
時間毎スローログ件数
スローログ詳細

53. 課題の解決
• 集約されてない場合はサーバーに入って
生ログを見る必要
– 全てのスローログをリアルタイムに集約
GUIで確認可能に
• ログの前後関係が把握しづらい
– 特定のクエリや時間に絞るなど解析することが可能
• 見る人が限られてくる
– GUIで簡単に確認できるように

54. 今後のDEVOPS MYSQL

55. いままでのDB 業務内容
• Devはアプリ開発に専念
• Opsは安定したDB環境を用意

56. これからのDB 業務内容
• Devは運用を意識したアプリ開発
– Opsはシステムの詳細な見える化を行い
Devが運用を意識して開発を
• OpsはDevと連携し安定したDB環境を用意
– Devと連携し、アプリケーションと連動した
システム導入

57. まとめ
 MHA for MySQLによる可用性担保
⇒ 既存HAの課題を解決
 リアルタイムスローログ可視化
⇒ 開発者が簡単にログを確認できるように
 今後のDevOps MySQL
⇒ 見える化による運用改善
⇒ アプリケーションと連動したシステム構成

58. ご清聴ありがとうございました

59. サンプル
• リアルタイムスローログ可視化サンプル
– https://github.com/yoheiW/vagrant_kibana

60. 参考
• https://code.google.com/p/mysql-master-
ha/
• http://clusterlabs.org/
• https://www.percona.com/blog/2013/11/20
/add-vips-percona-xtradb-cluster-mha-
pacemaker/
• https://www.elastic.co/
• http://www.fluentd.org/