[db tech showcase Tokyo 2015] C15:DevOps MySQL in カカクコム～ OSSによる可用性担保とリアルタイムパフォーマンス可視化 ～ by 株式会社カカクコム 渡邉洋平

Transcript

• 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/