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のDB業務分担

DevOpsのDB業務分担

• Devはアプリ開発に専念

• Opsは安定したDB環境を用意

MHA FOR MYSQLによる可用性担保

これまでのDBHA（高可用性）構成

• 共有ストレージ

• 商用クラスタソフト

• Active Standby

ReadWrite

これまでのDBＨＡ構成

SlaveB2

LoadBlancer

SlaveDB1共有ストレージ

MasterDB VIP WEB/AP

MasterDB ActiveMasterDB Standby

レプリケーションSAN

課題

• 導入までのスピード

• スモールスタートサイトへの適用

• 仮想環境での利用

• 共有ストレージ保守切れに伴うリプレース

目指したHA構成

• OSSによる可用性担保

• 共有ストレージを使用しない

• リプレースが容易

• 仮想環境でも利用可能

• 既存のHA構成から移行する際もパフォーマンスを維持

DBHA構成の検討

• ＭＨＡ 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の場合VIP付与候補に

MHA for MySQLによるＨＡ構成

SlaveB2

LoadBlancer

SlaveDB1

WEB/AP

MHA Manager

MasterDB VIP

MHA for MySQLによるＨＡ構成

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を使用

• 共有ストレージを使用しない

– スレーブがマスターに昇格するため共有ストレージは不要

• リプレースが容易

– スレーブを追加しマスターに昇格

• 仮想環境でも利用可能– 共有ストレージに依存しないため、物理、仮想問わず適用可能

• 既存のHA構成から移行する際もパフォーマンスを維持

– DiskIOパフォーマンスはPCieSSDを利用することで可能

課題

• 導入までのスピード

• スモールスタートサイトへの適用

– OSSによる構成のためいつでも導入可能

• 仮想環境での利用

– 共有ストレージ不要で、物理、仮想に依存しない構成

• 共有ストレージ保守切れに伴うリプレース

– 共有ストレージを使用していないため、各サイト毎に移行時期を設定可能

MySQL設定の変更

• binlog_format=MIXED

– マスター、スレーブデータ整合性保証

• 通常はSTATEMENT

• Semi-Synchronous Replication有効化

– スレーブへのデータ伝達保証

MySQL設定の変更

• binlog_format=MIXED

– 遅くなる更新クエリが発生・・・

• STATEMENTは小さかった

• が、更新されたデータ量は大きかった

• Semi-Synchronous Replication有効化

– Commit単位が大きい場合Semi-Syncが切れる

に伴う課題・・・

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

• 当日のログはサーバーに入りgrep,awkで確認

課題

• 集約されていない当日のログはサーバーに入って見る必要

• 見る人が限られてくる

– 本当に問題が顕在化するまで見ない

• ログの前後関係が把握しづらい

– スローログの本当の原因を見つけづらい

目指したスローログ解析

• リアルタイム

– Fluentdでリアルタイムログ集約

• 誰でも見れる

– KibanaのGUIによるログ確認

• 簡単に深追いできる

– どのクエリが影響して遅くなっているのか

– Kibana, Elasticsearchによるログ分析

Elasticsearch/Kibana4

• ログ解析プラットホーム

• ElasticsearchのデータをKibana4で解析

• elasticが開発

Ｆluentd（td-agent）

• ログの転送、集約を行うツール

• リアルタイムに転送

• Treasure Dataが開発

Ｆluentd（td-agent）Plugin

• fluent-plugin-mysqlslowquery

– スローログの転送

• fluent-plugin-elasticsearch

– Elasticsearchへのデータ挿入

Ｆluentd（td-agent）Filter

• アドホックなクエリをfilterで変換

– Where句の値の違いを吸収

– Elasticsearchで解析しやすく

構成

Reverse proxy

slowquery

apache認証

DBServer

filter

Dashboard

スローログ件数TOP5 スローログ総秒数TOP5

時間毎スローログ件数

スローログ詳細

課題の解決

• 集約されてない場合はサーバーに入って生ログを見る必要

– 全てのスローログをリアルタイムに集約GUIで確認可能に

• ログの前後関係が把握しづらい

– 特定のクエリや時間に絞るなど解析することが可能

• 見る人が限られてくる

– 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-vips-percona-xtradb-cluster-mha-pacemaker/

• https://www.elastic.co/

• http://www.fluentd.org/