Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
DevOps MySQL in カカクコム
OSSによる可用性担保と
リアルタイムパフォーマンス可視化
株式会社カカクコム
プラットフォーム技術本部
渡邉 洋平
自己紹介
• 渡邉洋平(わたなべようへい)
• 所属
– 株式会社カカクコム プラットフォーム技術本部
• 業務
– OSS系サイトインフラ担当
• 経歴
– Web開発
– DB運用
– OSS系サイトインフラ担当
カカクコム運営サイト紹介
アジェンダ
0. カカクコムのDevとOpsの紹介
1. MHA for MySQLによる可用性担保
2. リアルタイムスローログ可視化
3. 今後のDevOps MySQL
カカクコムのDEVとOPSの紹介
システムプラットフォーム部
システムプラットフォーム部
Dev(事業部)
Ops
Dev 業務内容
• アプリケーション開発
• テスト
• リリース
• アプリケーション障害対応
Ops 業務内容
• HW、ストレージ等の選定、検証、導入
• ミドルウェア選定、検証
• 監視設計
• サーバー構築(OS、ミドルウェアインストール)
• HW、OS、ミドルウェア障害対応
• ・・・
Dev
• スキーマ設計
• クエリ作成 or ORM
• スロークエリチューニング
Ops
• MySQLチューニング
• MySQL冗長化
• MySQL障害対応
• DBスキーマ本番適用
• スロークエリチューニング
提案
DevOpsの...
DevOpsのDB業務分担
• Devはアプリ開発に専念
• Opsは安定したDB環境を用意
MHA FOR MYSQLによる可用性担保
これまでのDBHA(高可用性)構成
• 共有ストレージ
• 商用クラスタソフト
• Active Standby
ReadWrite
これまでのDBHA構成
SlaveB2
LoadBlancer
SlaveDB1共有ストレージ
MasterDB VIP WEB/AP
MasterDB ActiveMasterDB Standby
レプリケーションSAN
課題
• 導入までのスピード
• スモールスタートサイトへの適用
• 仮想環境での利用
• 共有ストレージ保守切れに伴うリプレース
目指したHA構成
• OSSによる可用性担保
• 共有ストレージを使用しない
• リプレースが容易
• 仮想環境でも利用可能
• 既存のHA構成から移行する際もパフォーマンスを維持
DBHA構成の検討
• MHA for MySQL
• mysqlfailover
• Pacemaker/Corosync/DRBD
MHA for MySQL
• マスターDBの自動フェイルオーバーを実現
– マスターDB障害時、スレーブがマスターに昇格
• 松信嘉範氏が作成
– 2011リリース
• MySQL5.0以降で使用可能
mysqlfailover
• マスターDBの自動フェイルオーバーを実現
– マスターDB障害時、スレーブがマスターに昇格
• MySQL公式
• MySQL5.6.5以降で使用可能
– GTIDの導入が必須
DBHA構成の検討
• mysqlfailoverで利用するGTIDの導入には
マスター、スレーブDBを同時に再起動する必要
– サービス停止が必須
• MariaDBを利用するサイトの存在
MHA for MySQLを採用
MHA for MySQLでの考慮事項
• MasterDBが変更されたことを
どうアプリケーションに伝えるか
– DNS変更
– VIP切り替え
MHA for MySQLでの考慮事項
• 構成変更に伴うDev検証コストを増やさない
– アプリケーションとのインターフェースは変えない
既存HA構成と同じVIP切替え方式
VIP付与の方式の検討
• MHAのScript内から直接付与
– ネットワーク不安定時の挙動に不安
• Keepalived
• Pacemaker/Corosync
– 他ミドルウェアのHA構成への展開が可能
Pacemaker/Corosync
• OSSのHAクラスタソフト
• Heartbeatの後継
• リソース制御等のHAの制御
Pacemaker/Corosync
• Pacemaker/CorosyncによるVIP管理
– mysql_monitorリソースエージェント
Pacemaker/Corosync
リソースエージェント
• IPaddr2
– VIPの管理
• mysql_monitor
– MySQL状態監視
– MySQLのread_onlyステータスをチェック
– read_only offの場...
MHA for MySQLによるHA構成
SlaveB2
LoadBlancer
SlaveDB1
WEB/AP
MHA Manager
MasterDB VIP
MHA for MySQLによるHA構成
SlaveB2
LoadBlancer
SlaveDB1
WEB/AP
MHA Manager
MasterDB VIP
Pacemaker/Corosync
障害時のフロー
SlaveB2
LoadBlancer
SlaveDB1
WEB/AP
MHA Manager
MasterDB VIP
障害時のフロー
SlaveB2
LoadBlancer
SlaveDB1
WEB/AP
MHA Manager
MasterDB VIP
検知
障害時のフロー
SlaveB2
LoadBlancer
SlaveDB1
WEB/AP
MHA Manager
MasterDB VIP
検知
障害時のフロー
SlaveB2
LoadBlancer
SlaveDB1
WEB/AP
MHA Manager
MasterDB VIP
障害状態
MasterDB
障害時のフロー
SlaveB2
LoadBlancer
SlaveDB1
WEB/AP
MHA Manager
MasterDB VIP
障害状態
MasterDB
Pacemaker/Corosync
障害時のフロー
SlaveB2
LoadBlancer
SlaveDB1
WEB/AP
MHA Manager
障害状態
MasterDB
Pacemaker/Corosync
MasterDB VIP
障害時のフロー
SlaveB2
LoadBlancerWEB/AP
MHA Manager
障害状態
MasterDB VIP
MasterDB
目指したHA構成
• OSSによる可用性担保
– MHA for MySQL, Pacemaker/Corosyncを使用
• 共有ストレージを使用しない
– スレーブがマスターに昇格するため共有ストレージは不要
• リプレースが容易
– スレ...
課題
• 導入までのスピード
• スモールスタートサイトへの適用
– OSSによる構成のためいつでも導入可能
• 仮想環境での利用
– 共有ストレージ不要で、
物理、仮想に依存しない構成
• 共有ストレージ保守切れに伴うリプレース
– 共有スト...
MySQL設定の変更
• binlog_format=MIXED
– マスター、スレーブデータ整合性保証
• 通常はSTATEMENT
• Semi-Synchronous Replication有効化
– スレーブへのデータ伝達保証
MySQL設定の変更
• binlog_format=MIXED
– 遅くなる更新クエリが発生・・・
• STATEMENTは小さかった
• が、更新されたデータ量は大きかった
• Semi-Synchronous Replication有効化...
MySQL設定の変更
• binlog_format=MIXED
– 整合性が取れると判断できる場合、クエリを
STATEMENTで実行
• Semi-Synchronous Replication有効化
– Commit単位をできるだけ小さく...
MySQLの変更点に伴い
• 複雑な更新クエリがHA構成の命とり
• Devもパフォーマンス状況、発行したクエリを
常に意識する必要
リアルタイムスローログ可視化
DB業務内容
Dev
• スキーマ設計
• クエリ作成 or ORM
• スロークエリチューニング
Ops
• MySQLチューニング
• MySQL冗長化
• MySQL障害対応
• DBスキーマ本番適用
• スロークエリチューニング提案
今までのスローログの確認
• Cacti(モニタリングツール)で件数を確認
• 1日1回ローテート、ログ集約サーバーに転送
• pt-query-digestでログの統計を取り見やすく
– Percona Toolkit
• 当日のログはサーバ...
課題
• 集約されていない当日のログは
サーバーに入って見る必要
• 見る人が限られてくる
– 本当に問題が顕在化するまで見ない
• ログの前後関係が把握しづらい
– スローログの本当の原因を見つけづらい
目指したスローログ解析
• リアルタイム
– Fluentdでリアルタイムログ集約
• 誰でも見れる
– KibanaのGUIによるログ確認
• 簡単に深追いできる
– どのクエリが影響して遅くなっているのか
– Kibana, Elastic...
Elasticsearch/Kibana4
• ログ解析プラットホーム
• ElasticsearchのデータをKibana4で解析
• elasticが開発
Fluentd(td-agent)
• ログの転送、集約を行うツール
• リアルタイムに転送
• Treasure Dataが開発
Fluentd(td-agent)
Plugin
• fluent-plugin-mysqlslowquery
– スローログの転送
• fluent-plugin-elasticsearch
– Elasticsearchへのデータ挿入
Fluentd(td-agent)
Filter
• アドホックなクエリをfilterで変換
– Where句の値の違いを吸収
– Elasticsearchで解析しやすく
構成
Reverse proxy
slowquery
apache認証
DBServer
filter
Dashboard
スローログ件数TOP5 スローログ総秒数TOP5
時間毎スローログ件数
スローログ詳細
課題の解決
• 集約されてない場合はサーバーに入って
生ログを見る必要
– 全てのスローログをリアルタイムに集約
GUIで確認可能に
• ログの前後関係が把握しづらい
– 特定のクエリや時間に絞るなど解析することが可能
• 見る人が限られてくる...
今後のDEVOPS MYSQL
いままでのDB 業務内容
• Devはアプリ開発に専念
• Opsは安定したDB環境を用意
これからのDB 業務内容
• Devは運用を意識したアプリ開発
– Opsはシステムの詳細な見える化を行い
Devが運用を意識して開発を
• OpsはDevと連携し安定したDB環境を用意
– Devと連携し、アプリケーションと連動した
システム...
まとめ
 MHA for MySQLによる可用性担保
⇒ 既存HAの課題を解決
 リアルタイムスローログ可視化
⇒ 開発者が簡単にログを確認できるように
 今後のDevOps MySQL
⇒ 見える化による運用改善
⇒ アプリケーションと...
ご清聴ありがとうございました
サンプル
• リアルタイムスローログ可視化サンプル
– https://github.com/yoheiW/vagrant_kibana
参考
• https://code.google.com/p/mysql-master-
ha/
• http://clusterlabs.org/
• https://www.percona.com/blog/2013/11/20
/add-...
Upcoming SlideShare
Loading in …5
×

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

8,847 views

Published on

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

Published in: Technology
  • Be the first to comment

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

  1. 1. DevOps MySQL in カカクコム OSSによる可用性担保と リアルタイムパフォーマンス可視化 株式会社カカクコム プラットフォーム技術本部 渡邉 洋平
  2. 2. 自己紹介 • 渡邉洋平(わたなべようへい) • 所属 – 株式会社カカクコム プラットフォーム技術本部 • 業務 – OSS系サイトインフラ担当 • 経歴 – Web開発 – DB運用 – OSS系サイトインフラ担当
  3. 3. カカクコム運営サイト紹介
  4. 4. アジェンダ 0. カカクコムのDevとOpsの紹介 1. MHA for MySQLによる可用性担保 2. リアルタイムスローログ可視化 3. 今後のDevOps MySQL
  5. 5. カカクコムのDEVとOPSの紹介
  6. 6. システムプラットフォーム部
  7. 7. システムプラットフォーム部 Dev(事業部) Ops
  8. 8. Dev 業務内容 • アプリケーション開発 • テスト • リリース • アプリケーション障害対応
  9. 9. Ops 業務内容 • HW、ストレージ等の選定、検証、導入 • ミドルウェア選定、検証 • 監視設計 • サーバー構築(OS、ミドルウェアインストール) • HW、OS、ミドルウェア障害対応 • ・・・
  10. 10. Dev • スキーマ設計 • クエリ作成 or ORM • スロークエリチューニング Ops • MySQLチューニング • MySQL冗長化 • MySQL障害対応 • DBスキーマ本番適用 • スロークエリチューニング 提案 DevOpsのDB業務分担
  11. 11. DevOpsのDB業務分担 • Devはアプリ開発に専念 • Opsは安定したDB環境を用意
  12. 12. MHA FOR MYSQLによる可用性担保
  13. 13. これまでのDBHA(高可用性)構成 • 共有ストレージ • 商用クラスタソフト • Active Standby
  14. 14. ReadWrite これまでのDBHA構成 SlaveB2 LoadBlancer SlaveDB1共有ストレージ MasterDB VIP WEB/AP MasterDB ActiveMasterDB Standby レプリケーションSAN
  15. 15. 課題 • 導入までのスピード • スモールスタートサイトへの適用 • 仮想環境での利用 • 共有ストレージ保守切れに伴うリプレース
  16. 16. 目指したHA構成 • OSSによる可用性担保 • 共有ストレージを使用しない • リプレースが容易 • 仮想環境でも利用可能 • 既存のHA構成から移行する際もパフォーマンスを維持
  17. 17. DBHA構成の検討 • MHA for MySQL • mysqlfailover • Pacemaker/Corosync/DRBD
  18. 18. MHA for MySQL • マスターDBの自動フェイルオーバーを実現 – マスターDB障害時、スレーブがマスターに昇格 • 松信嘉範氏が作成 – 2011リリース • MySQL5.0以降で使用可能
  19. 19. mysqlfailover • マスターDBの自動フェイルオーバーを実現 – マスターDB障害時、スレーブがマスターに昇格 • MySQL公式 • MySQL5.6.5以降で使用可能 – GTIDの導入が必須
  20. 20. DBHA構成の検討 • mysqlfailoverで利用するGTIDの導入には マスター、スレーブDBを同時に再起動する必要 – サービス停止が必須 • MariaDBを利用するサイトの存在 MHA for MySQLを採用
  21. 21. MHA for MySQLでの考慮事項 • MasterDBが変更されたことを どうアプリケーションに伝えるか – DNS変更 – VIP切り替え
  22. 22. MHA for MySQLでの考慮事項 • 構成変更に伴うDev検証コストを増やさない – アプリケーションとのインターフェースは変えない 既存HA構成と同じVIP切替え方式
  23. 23. VIP付与の方式の検討 • MHAのScript内から直接付与 – ネットワーク不安定時の挙動に不安 • Keepalived • Pacemaker/Corosync – 他ミドルウェアのHA構成への展開が可能
  24. 24. Pacemaker/Corosync • OSSのHAクラスタソフト • Heartbeatの後継 • リソース制御等のHAの制御
  25. 25. Pacemaker/Corosync • Pacemaker/CorosyncによるVIP管理 – mysql_monitorリソースエージェント
  26. 26. Pacemaker/Corosync リソースエージェント • IPaddr2 – VIPの管理 • mysql_monitor – MySQL状態監視 – MySQLのread_onlyステータスをチェック – read_only offの場合VIP付与候補に
  27. 27. MHA for MySQLによるHA構成 SlaveB2 LoadBlancer SlaveDB1 WEB/AP MHA Manager MasterDB VIP
  28. 28. MHA for MySQLによるHA構成 SlaveB2 LoadBlancer SlaveDB1 WEB/AP MHA Manager MasterDB VIP Pacemaker/Corosync
  29. 29. 障害時のフロー SlaveB2 LoadBlancer SlaveDB1 WEB/AP MHA Manager MasterDB VIP
  30. 30. 障害時のフロー SlaveB2 LoadBlancer SlaveDB1 WEB/AP MHA Manager MasterDB VIP 検知
  31. 31. 障害時のフロー SlaveB2 LoadBlancer SlaveDB1 WEB/AP MHA Manager MasterDB VIP 検知
  32. 32. 障害時のフロー SlaveB2 LoadBlancer SlaveDB1 WEB/AP MHA Manager MasterDB VIP 障害状態 MasterDB
  33. 33. 障害時のフロー SlaveB2 LoadBlancer SlaveDB1 WEB/AP MHA Manager MasterDB VIP 障害状態 MasterDB Pacemaker/Corosync
  34. 34. 障害時のフロー SlaveB2 LoadBlancer SlaveDB1 WEB/AP MHA Manager 障害状態 MasterDB Pacemaker/Corosync MasterDB VIP
  35. 35. 障害時のフロー SlaveB2 LoadBlancerWEB/AP MHA Manager 障害状態 MasterDB VIP MasterDB
  36. 36. 目指したHA構成 • OSSによる可用性担保 – MHA for MySQL, Pacemaker/Corosyncを使用 • 共有ストレージを使用しない – スレーブがマスターに昇格するため共有ストレージは不要 • リプレースが容易 – スレーブを追加しマスターに昇格 • 仮想環境でも利用可能 – 共有ストレージに依存しないため、物理、仮想問わず適用可能 • 既存のHA構成から移行する際もパフォーマンスを維持 – DiskIOパフォーマンスはPCieSSDを利用することで可能
  37. 37. 課題 • 導入までのスピード • スモールスタートサイトへの適用 – OSSによる構成のためいつでも導入可能 • 仮想環境での利用 – 共有ストレージ不要で、 物理、仮想に依存しない構成 • 共有ストレージ保守切れに伴うリプレース – 共有ストレージを使用していないため、 各サイト毎に移行時期を設定可能
  38. 38. MySQL設定の変更 • binlog_format=MIXED – マスター、スレーブデータ整合性保証 • 通常はSTATEMENT • Semi-Synchronous Replication有効化 – スレーブへのデータ伝達保証
  39. 39. MySQL設定の変更 • binlog_format=MIXED – 遅くなる更新クエリが発生・・・ • STATEMENTは小さかった • が、更新されたデータ量は大きかった • Semi-Synchronous Replication有効化 – Commit単位が大きい場合Semi-Syncが切れる に伴う課題・・・
  40. 40. MySQL設定の変更 • binlog_format=MIXED – 整合性が取れると判断できる場合、クエリを STATEMENTで実行 • Semi-Synchronous Replication有効化 – Commit単位をできるだけ小さく – 長時間実行される=レプリケーション遅延となる クエリの排除 に伴う課題・・・の解決
  41. 41. MySQLの変更点に伴い • 複雑な更新クエリがHA構成の命とり • Devもパフォーマンス状況、発行したクエリを 常に意識する必要
  42. 42. リアルタイムスローログ可視化
  43. 43. DB業務内容 Dev • スキーマ設計 • クエリ作成 or ORM • スロークエリチューニング Ops • MySQLチューニング • MySQL冗長化 • MySQL障害対応 • DBスキーマ本番適用 • スロークエリチューニング提案
  44. 44. 今までのスローログの確認 • Cacti(モニタリングツール)で件数を確認 • 1日1回ローテート、ログ集約サーバーに転送 • pt-query-digestでログの統計を取り見やすく – Percona Toolkit • 当日のログはサーバーに入りgrep,awkで確認
  45. 45. 課題 • 集約されていない当日のログは サーバーに入って見る必要 • 見る人が限られてくる – 本当に問題が顕在化するまで見ない • ログの前後関係が把握しづらい – スローログの本当の原因を見つけづらい
  46. 46. 目指したスローログ解析 • リアルタイム – Fluentdでリアルタイムログ集約 • 誰でも見れる – KibanaのGUIによるログ確認 • 簡単に深追いできる – どのクエリが影響して遅くなっているのか – Kibana, Elasticsearchによるログ分析
  47. 47. Elasticsearch/Kibana4 • ログ解析プラットホーム • ElasticsearchのデータをKibana4で解析 • elasticが開発
  48. 48. Fluentd(td-agent) • ログの転送、集約を行うツール • リアルタイムに転送 • Treasure Dataが開発
  49. 49. Fluentd(td-agent) Plugin • fluent-plugin-mysqlslowquery – スローログの転送 • fluent-plugin-elasticsearch – Elasticsearchへのデータ挿入
  50. 50. Fluentd(td-agent) Filter • アドホックなクエリをfilterで変換 – Where句の値の違いを吸収 – Elasticsearchで解析しやすく
  51. 51. 構成 Reverse proxy slowquery apache認証 DBServer filter
  52. 52. Dashboard スローログ件数TOP5 スローログ総秒数TOP5 時間毎スローログ件数 スローログ詳細
  53. 53. 課題の解決 • 集約されてない場合はサーバーに入って 生ログを見る必要 – 全てのスローログをリアルタイムに集約 GUIで確認可能に • ログの前後関係が把握しづらい – 特定のクエリや時間に絞るなど解析することが可能 • 見る人が限られてくる – GUIで簡単に確認できるように
  54. 54. 今後のDEVOPS MYSQL
  55. 55. いままでのDB 業務内容 • Devはアプリ開発に専念 • Opsは安定したDB環境を用意
  56. 56. これからのDB 業務内容 • Devは運用を意識したアプリ開発 – Opsはシステムの詳細な見える化を行い Devが運用を意識して開発を • OpsはDevと連携し安定したDB環境を用意 – Devと連携し、アプリケーションと連動した システム導入
  57. 57. まとめ  MHA for MySQLによる可用性担保 ⇒ 既存HAの課題を解決  リアルタイムスローログ可視化 ⇒ 開発者が簡単にログを確認できるように  今後のDevOps MySQL ⇒ 見える化による運用改善 ⇒ アプリケーションと連動したシステム構成
  58. 58. ご清聴ありがとうございました
  59. 59. サンプル • リアルタイムスローログ可視化サンプル – https://github.com/yoheiW/vagrant_kibana
  60. 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/

×