[db tech showcase Tokyo 2015] C15:DevOps MySQL in カカクコム～ OSSによる可用性担保とリアルタイムパフォーマンス可視化 ～ by 株式会社カカクコム 渡邉洋平
•
11 gefällt mir•9,832 views
Ops側のMySQL担当の視点から ・商用HA製品からMySQLMHAによる可用性担保に移行 ・fluentd + kibanaによるリアルタイムスローログ監視導入、運用 カカクコムのDevOpsを交えながらお話します
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie [db tech showcase Tokyo 2015] C15:DevOps MySQL in カカクコム～ OSSによる可用性担保とリアルタイムパフォーマンス可視化 ～ by 株式会社カカクコム 渡邉洋平
Ähnlich wie [db tech showcase Tokyo 2015] C15:DevOps MySQL in カカクコム～ OSSによる可用性担保とリアルタイムパフォーマンス可視化 ～ by 株式会社カカクコム 渡邉洋平 (20)
Mehr von Insight Technology, Inc.
Mehr von Insight Technology, Inc. (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (10)
[db tech showcase Tokyo 2015] C15:DevOps MySQL in カカクコム～ OSSによる可用性担保とリアルタイムパフォーマンス可視化 ～ by 株式会社カカクコム 渡邉洋平
- 1. DevOps MySQL in カカクコム OSSによる可用性担保と リアルタイムパフォーマンス可視化 株式会社カカクコム プラットフォーム技術本部 渡邉 洋平
- 2. 自己紹介 • 渡邉洋平（わたなべようへい） • 所属 – 株式会社カカクコム プラットフォーム技術本部 • 業務 – OSS系サイトインフラ担当 • 経歴 – Web開発 – DB運用 – OSS系サイトインフラ担当
- 3. カカクコム運営サイト紹介
- 4. アジェンダ 0. カカクコムのDevとOpsの紹介 1. MHA for MySQLによる可用性担保 2. リアルタイムスローログ可視化 3. 今後のDevOps MySQL
- 8. Dev 業務内容 • アプリケーション開発 • テスト • リリース • アプリケーション障害対応
- 9. Ops 業務内容 • HW、ストレージ等の選定、検証、導入 • ミドルウェア選定、検証 • 監視設計 • サーバー構築（OS、ミドルウェアインストール） • HW、OS、ミドルウェア障害対応 • ・・・
- 10. Dev • スキーマ設計 • クエリ作成 or ORM • スロークエリチューニング Ops • MySQLチューニング • MySQL冗長化 • MySQL障害対応 • DBスキーマ本番適用 • スロークエリチューニング 提案 DevOpsのDB業務分担
- 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の制御
- 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
- 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単位をできるだけ小さく – 長時間実行される＝レプリケーション遅延となる クエリの排除 に伴う課題・・・の解決
- 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によるログ分析
- 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で解析しやすく
- 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. ご清聴ありがとうございました
- 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/