MHA for MySQLとDeNAのオープンソースの話

MHA for MySQLによるDeNAのMySQL高可用ソリューションとDeNAにおけるオープンソースへの取り組み株式会社ディー・エヌ・エー MySQL Geek, Oracle ACE Director 松信嘉範 (MATSUNOBU Yoshinori) Twitter: @matsunobu 1

自己紹介 MySQL/Linux周りのスペシャリスト 2006年9月から2010年8月までMySQL本家 (MySQL/Sun/Oracle)でAPAC/US圏のMySQLコンサルティングに従事主な著書に「現場で使えるMySQL」「Linux-DBシステム構築/ 運用入門」「Javaデータアクセス実践講座」日本で2人目のOracle ACE Director (WW MySQLでは4人目) 主に海外での講演 MySQL Conference and Expo 2011 OSCON (2011.7) Oracle Open World (2011.10) Percona Live London (2011.10) 2

アジェンダマスター自動フェイルオーバーの実現マスター無停止メンテの実現デモ DeNAにおけるオープンソースへの取り組み 3

Mobageの規模 1日あたり20数億PV以上 1000台以上のDB(MySQL)サーバ、それ以上の Webサーバ国内だけで数拠点のデータセンター数百を超えるアプリケーション 4

単一障害点を無くしたい Single Point of Failure: その箇所がダウンするとサービスが止まるいかなる時にも緊急対応が必要になる早朝だろうと深夜だろうと対応が必要アプリの数が多ければ確率も上がるメンバーも疲弊する MySQLの世界ではスレーブは冗長化によってSPoFでなくすことは簡単マスターは1個しか無いから難しい 5

MySQLマスター障害対応の課題・MySQLのレプリケーションは非同期または Writer IP 準同期 master ・マスター障害時に、一部のスレーブ (あるいは全部のスレーブ)が id=99 最新のバイナリログを受け取っていない id=100 id=101 可能性がある id=102 ・スレーブ間で、バイナリログの転送状況に 1. Save binlog events that ずれが生じている可能性がある exist on master only ・左図の例では、id=102はどのスレーブにも転送されていない・id=101はスレーブ2にしか転送されていない・スレーブ3ではid=100, id=101を受け取っていないslave1 slave2 slave3 id=99 id=99 id=99 正しく復旧するには、 id=100 id=100 id=100 ・id=102をマスターから転送する id=101 id=101 id=101 ・スレーブ間でのずれを解消する id=102 id=102 id=1022. Identify which events are not sent 必要がある 3. Apply lost events 6 これを全自動でやるのがMHA

MHAのアーキテクチャ Manager mastermha4mysql-manager- masterha_manager- masterha_master_switch slave1 slave2 slave3 master mha4mysql-node - save_binary_logs - apply_diff_relay_logs - purge_relay_logs slave1 slave2 slave3マスターの稼働監視およびダウン時の自動フェイルオーバーを実現するツール http://code.google.com/p/mysql-master-ha/ にてOSSで公開 Pure Perl MySQL 5.0以降で動作管理サーバ(MHA Manager)と、個々のMySQLサーバでバイナリログの差分修復等を行うツール(MHA Node)から構成されるモジュールの依存関係は少ない – NodeパッケージはDBD::mysqlのみ – ManagerパッケージはConfig::Tiny, Log::Dispatch, Parallel::ForkManager, DBD::mysql, MHA::Nodeに依存しているが、だいたい1-2箇所に入れれば十分 7

内部的な動作Dead Master Latest Slave Slave(i) Wait until SQL thread executes all events Final Relay_Log_File, Relay_Log_Pos (i1) Master_Log_File Read_Master_Log_Pos (i2) (X) SQLスレッドが実行を終えるまで待つ (i1) 最新スレーブのリレーログログのヘッダを解析して各スレーブに適用すべき差分位置を特定(i2) マスターにアクセス可能なら、マスターから差分を保存(X) i1->i2->Xをすべて組み立て1個のバイナリログにする (Format Description Eventは内部的にROLLBACKを生成しうるので先頭のみ) mysqlbinlogして実行 8 上記をスレーブ間で並列で行なう

主な特徴マスターの稼働監視からフェイルオーバーまでを自動でできるフェイルオーバーを手動で行なうことも可能フェイルオーバーが秒単位で可能アクティブ/アクティブ型のため非同期レプリケーションにもかかわらず、スレーブ間での同期が取れている任意のスレーブを新マスターにできるいくつかの箇所から外部スクリプトを呼ぶ機能(拡張ポイント)がある電源OFFやIPアドレスのフェイルオーバーなどに使う 9

主な特徴 MySQL5.0以降であれば標準のMySQLで動作するインストール/アンインストールにあたり現在のmysqldプロセスやレプリケーションを止める必要が無い MHA自体は追加の負荷をかけないため、パフォーマンスが低下せず、追加のサーバも不要ストレージエンジンに依存しないバイナリログのフォーマットに依存しない StatementベースでもRowベースでも大丈夫 10

拡張ポイント seconary_check_script マスターがダウンしたかどうかを複数のNW経路から判定するために呼ばれるマスターに接続エラーになった時に呼ばれる MHAに標準搭載しているスクリプトmasterha_seconary_check が便利 shutdown_script 電源強制OFFなどフェイルオーバーの直前に呼ばれる SSH到達可能な場合はmysqld, mysqld_safeを強制killし、到達不可能な場合は電源OFF すると良い master_ip_failover_script マスターIPアドレスの更新や、アプリケーションから接続するためのユーザの作成などフェイルオーバーの直前と、新マスター移行時(差分反映完了後)に呼ばれる用途に合わせてスクリプトを書くことで、アプリケーション側の修正無しで新マスターに接続できるマスターのIPアドレスにVirtual IPを使っている場合 – VIPを新マスターで割り当てるカタログデータベース等でマスターのIPアドレスを管理している場合 – そのカタログデータベースを更新する report_script: フェイルオーバーの可否と詳細情報をメール通知したりフェイルオーバーの終了後に呼ばれる 11

ケーススタディ DeNAのサービス(主にソーシャルゲーム)において、150を超えるマスター/スレーブのペアに対してMHAを導入 MySQLは滅多にクラッシュしないが、OSやH/W障害によって落ちることはある拡張ポイントマスターのダウン検知 – Manager→マスターに加えて、2箇所のリモートのデータセンターからマスターに到達できないことをチェックマスターの強制ダウン – SSHで接続可能なときはkillall -9 mysqld mysqld_safe、接続できないときはipmitool等で強制電源OFF マスターのIPアドレスのフェイルオーバー – 集中管理しているデータベースがあり、そこを更新 – マスター接続用のユーザ(INSERT/UPDATE/DELETE権限がある)を作成 OSダウンによるフェイルオーバーには、ダウン検知に10秒、フェイルオーバーに4秒程度マスターの生死判定 – 3秒×3-4 (9秒から12秒) フェイルオーバー可否判定 – デフォルトの動作は、ほかのスレーブがすべて生きている場合のみフェイルオーバー – スレーブの稼働状況をチェックして判定 (1秒未満) フェイルオーバー処理 – 現マスターの強制シャットダウン – SSHで接続可能なときは、差分バイナリログを保存 – 新マスターの決定 – 新マスターのIP有効化 – ほかのスレーブが新マスターからレプリケーション再開 12

デモ 3台構成 (マスター1個、スレーブ2個) Host centos6-1: Master Host centos6-2: Slave and Manager Host centos6-3: Slave マスターのmysqldをkill スレーブの片方を止めた状態でマスターを更新、そしてマスターのmysqldをkill (差分修復) スレーブの片方を止めた状態でマスターを更新、そしてマスターでカーネルパニック (差分修復) 13

既存のソリューションに対する優位性マスター障害が起きても、スレーブ間での整合性が崩れずに迅速にレプリケーションを再開できる障害検知に10秒程度→マスター修復に4秒程度既存のMySQLレプリケーション構成を変える必要が無い従来型のシングルマスター/マルチスレーブ構成であればOK MySQL5.0以降であれば動作する(5.0/5.1/5.5/5.6で動作確認済み) 5.5の準同期レプリケーションと組み合わせることで、データ消失をほぼ防げるサーバの追加投資が不要アクティブ/スタンバイ構成時のスタンバイ機のようなサーバが不要管理サーバはスレーブ上で動作させることもできる独立した管理サーバを設け、多数のマスターを監視することもできる既存のレプリケーション構成とほぼ同等のパフォーマンスを得られるマスターに対して過度の負荷をかけたりはしないどのストレージエンジンでも動作する MyISAM等、トランザクション非対応のストレージエンジンでも動作する 14

ほかの方法との比較 Pacemaker + DRBDに対する優位性既存環境にそのまま入れることができるスタンバイサーバが要らず、全サーバを有効活用できるフェイルオーバー時間が高速(検知に10秒程度、切り替えに4秒程度) – アクティブ/スタンバイ型のDRBDでは、クラッシュリカバリに1分単位は見ないといけない MySQL Cluster / Galeraに対する優位性既存環境にそのまま入れることができる難しくない (当社比) MySQL-MMMに対する優位性 MySQL-MMMはそもそもHAソリューションではない – 稼働監視のNW経路が1本しかない – マスター障害の状況によっては高確率で切り替えが止まる – 差分修復をしていない – 多数のVirtual IPが必須 – 切り替えが連続して起こる可能性があり、それを防ぐ手段が無い 15

その他の特徴任意のスレーブを新マスターにできる (最新でなくても)フェイルバックをするのが面倒。障害マスターへの復旧には多くの場合作り直しが必要 – Fully durable settings (innodb_flush_log_at_trx_commit=1, innodb_support_xa=1 sync_binlog=1)でなければほかのHAソリューションでも同じ欠点がある準同期レプリケーション(Semi-Synchronous Replication)を併用することで、データ消失をほぼ防げる MySQL 5.5からオプションでサポートされた機能マスター障害時に「どのスレーブにも最新のコミット情報が転送されていない」という状況をほぼ防ぐことができる全スレーブに同期されるわけではなく、「どれか1個のスレーブ」に対する同期を保証。このため、マスター障害時は各スレーブで状態がずれる可能性がある。MHAは最新のものをベースにほかのスレーブを復旧できる 16

サービスの増強と縮退ゲームタイトルの人気を正確に見積もることは困難想定外に人気が出ることもあるし、逆に人気が出ないこともあるある程度の期間が経過すれば、徐々に人気は下落傾向に入る想定外の人気が出た場合スレーブを追加する水平分割によってマスターを追加していく – サービスを止めずにマスターを追加することは可能マスターのハードウェアを増強する – メモリ、SSD、ネットワーク人気が下落傾向にある場合スレーブを減らすマスターを低スペックなサーバに移すいくつかのマスターを1個のサーバに集約する 17

マスターを別マシンに移行したいときマスターを別のマシンに移したいことはよくある増強：メモリの増設やHDD->SSDなどによって凌ぎたい縮退：人気の低いゲームタイトルを低スペックなサーバに移したい部分障害：ハードウェアの部分故障により性能が大幅に悪化したので移したい – ダウンしていないものの、さばけるスループットが大幅に悪化 H/W、Linux、MySQLのバージョンアップ：止めて上げなおすのは実質的に10分以上のダウンにつながるので厳しいメンテナンス時間を設ければ作業自体は簡単マスターのIPアドレスを新しいものに更新し、スレーブは全部新しいマスターからレプリケーションするだがメンテナンスは何度もやりたくはないユーザへの告知、カスタマーサポートへの連絡などの事務手続きダウンタイムは収益減になる多くの場合深夜作業になるのでメンバーが疲弊する 18

ダウンタイム無しでマスター切り替えダウンタイム無しでマスターを切り替えることが理想。そのためには… マスターへの更新を一瞬止める既存のスレーブが、マスターからのレプリケーションをすべて終えたことを確認する新しいマスターへの書き込み権限を与え、アプリケーションから透過的に(ロジックを書き換えずに) 接続できるようにする – 仮想IPを用いたり、マスターのIPをカタログデータベースで管理するのが定番スレーブが新しいマスターからレプリケーションを開始これらのステップを0.5-3秒くらいでできれば、多くの場合で許容範囲だろうそのタイミングでの更新はエラーになるが、ユーザから見ればもう1回クリックすれば成功するくらいの間隔なので 19

書き込みのブロックをどうするか MySQLでは更新をブロックする手段をいくつか提供しているが、すべてが安全なわけではない FLUSH TABLES WITH READ LOCK – クライアント側でタイムアウト設定をしていない限り、ずっとロック待ちになる：レスポンスタイムが悪くなる – 実行中のトランザクションは実質エラーとなるほかのサーバにまたがって更新している場合に不整合を生む – 全部のテーブルをフラッシュするので非常に時間がかかることがある事前にFLUSH NO_WRITE_TO_BINLOG TABLESしておくのが1つの定石 SET GLOBAL read_only = 1 – 更新を実行した時点で即時にエラーが返る – 実行中のトランザクションは実質エラーとなるアプリケーションから使っているユーザをDROPする – 新規接続が張れなくなる – 接続済みのセッションは、切断までエラーにならない – ほかのサーバにまたがった更新でも不整合にはならない – 接続済みのセッションが終了しない限り、更新が終わらない – 持続的接続では効果が無い 20

安全性と高速性のバランスを取るマスターで長時間更新を実行しているセッションが無いことをチェック – 100秒更新しているものは、スレーブでも100秒かかるユーザをDROP 一定時間(最大3秒等)、アプリからの接続が無くなるまで待つ – SHOW PROCESSLISTを見て、1秒以上Sleep状態なものは、単なる張りっぱなしや外部で待っているとかなので、切っても構わないだろう – 一番やってはいけないのは、コミット直前-途中のセッションを強制的に切ること接続が無くなるか時間切れになったら、FLUSH TABLES WITH READ LOCKにより全体をロックし、切り替えに入る接続を張りっぱなしにしているデーモンプロセス等についての考慮も必要だいたい1秒もあればブロックが完了する 21

MHAでの高速マスター切り替えFrom:host1 (current master) MHAではオプションでマス+--host2 (backup) ターをオンラインで切り替+--host3 (slave)+--host4 (slave) える機能がある+--host5 (remote) 手動で実行するマスターへの接続を0.5-2秒To: 程度ブロックhost2 (new master) その間に新マスターに切り+--host3 (slave) 替える+--host4 (slave)+--host5 (remote) 22

デモ 23

プロジェクトの詳細情報トップページ http://code.google.com/p/mysql-master-ha/ ドキュメント(英語) http://code.google.com/p/mysql-master-ha/wiki/TableOfContents?tm=6 有志による日本語ドキュメント http://myhome.munetika.mydns.jp/ossdbwiki/index.php/%E3%83%A1%E3%82%A4%E 3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8 ダウンロード(安定版) http://code.google.com/p/mysql-master-ha/downloads/list GitHubリポジトリ(開発ツリー: 名称変更したので注意) https://github.com/yoshinorim/mha4mysql-manager https://github.com/yoshinorim/mha4mysql-node 24

オープンソースを取り巻く世界ベンダー (RedHat, MySQL, etc) SI/サードベンダーサービス企業 (HP, IBM, Percona, etc) (Facebook, Twitter, DeNA, etc) ベンダー, SI, サードベンダー主にサポートやコンサルで収益を上げる開発者を雇用サービス企業オープンソース製品を利用することで、高い商用製品を買わずに済む 25

ベンダー(MySQL)からサービス事業者(DeNA)への転職 MySQL時代の業務内容本業だったコンサルは、2-5日単位での案件を多数こなすという仕事 1ヶ月-6ヶ月といった、まとまった期間を取って特定のソリューションに取り組むことは難しかったサービス事業者でないとできなかったこと中長期的な施策 (MHAは代表的な例) 1000台規模のサーバ運用の経験と、そこから派生する潜在ニーズの発掘 – 「遅いトランザクションを特定するツール」の重要性や「監視のしきい値となるKPIをより正確に決める(いつサーバ追加が必要か等を適切に判断するために)」など 26

サービス企業の中からDeNAに行った理由「スペシャリスト」というキャリアパスがあるマネージャにならなくても高い報酬を目指せるキャリアパス欧米企業では一般的だが、国内では珍しいデータベーススペシャリストの働き場所は大規模サービス事業者でないと難しい 5台のサーバを3台にするために DBスペシャリストを雇用したいと思う経営者はいない 1000台を600台にできるなら、それだけで価値がある為替レートの問題と、グローバル指向とのギャップを埋める今の時代、給与は日本円でもらいたい→日本企業だがある程度海外での技術プレゼンスの意識があることが長期的には大事米MySQL Conferenceに参加している国内Webサービス企業は mixi、Yahoo、楽天、DeNAくらいしか無い付加価値の高い仕事をするためには、ある程度チームのメンバ層が厚いことが必要チームマネジメント、トラブルシューティング、プロジェクト支援、勉強会の講師などすべてが特定の人に降ってくるようでは、時間を確保することは困難 27

オープンソースに貢献する意義「なぜノウハウを外に出す必要があるのか」ということをすべての会社が考えるようだと技術は発展しない一種のCSR 技術の発展に貢献するというCSR 28

オープンソース・ソフトウェアの価値 OSSに貢献すると言う ≠ OSS界に実際に貢献している言うだけなら誰でもできる「OSSとして出したいです」と言いながら何年も出ていないものはたくさんある OSSをリリースする ≠ 世の中に貢献するリリースしたからといって役に立つとは限らない現場で使っているソフトウェアを出す実験室で作っただけのソフトウェアと、現場で使われているソフトウェアは違う MHAはMobageの150系統を超える環境で実際に使っていて、多数のメンテや障害時に活躍した実績がある多くの人にとって使いやすいソフトウェアを出す公開したきり発展していない(ドキュメントも無い!)OSSは少なくない MHAはMySQLサードベンダーのSkySQL(およびそのパートナー)が商用サポートを提供している 29

インフラエンジニアのキャリア Problem Solving 今そこにある火を消す Core Skill enhancement 地道な勉強によるスキルの底上げ多くの検証環境での実験経験を通じて定量的な理解を深める Technology Marketing Tool development 国内外での積極的な情報発信問題解決のために便利なツールを整備する Solution Development Alliance 短中期的な問題を定義最新の技術動向を(公開/非公開を問わず) 効果の高い手段をリストアップ・検証仕入れるためのアンテナ/人脈の構築優先順位をつけて着実に実施 Research & Development 中長期的な課題の発見・解決策の立案/検証 DeNAはこうしたキャリアを積み上げる上で非常に向いていますもちろん、ソーシャルゲーム本体の開発者も絶賛募集中です 30

ありがとうございました 31

http://opendatabaselife.blogspot.com	3228
http://6pongi.wordpress.com	1821
http://opendatabaselife.blogspot.jp	1814
http://paper.li	36
http://webcache.googleusercontent.com	34
http://infra.rrdtool.net	10
http://a0.twimg.com	8
http://translate.googleusercontent.com	7
https://twimg0-a.akamaihd.net	7
http://twitter.com	6
http://opendatabaselife.blogspot.fr	6
http://wiki.onakasuita.org	4
http://www.blogger.com	4
http://www.slideshare.net	4
https://si0.twimg.com	3
http://opendatabaselife.blogspot.de	3
http://opendatabaselife.blogspot.co.uk	3
http://opendatabaselife.blogspot.com.au	3
http://opendatabaselife.blogspot.com.es	2
http://opendatabaselife.blogspot.com.br	2
http://opendatabaselife.blogspot.ca	2
http://s.deeeki.com	2
http://cache.yahoofs.jp	2
http://opendatabaselife.blogspot.in	2
http://www.opendatabaselife.blogspot.jp	1
http://www.opendatabaselife.blogspot.com	1
http://www.twylah.com	1
http://us-w1.rockmelt.com	1
http://opendatabaselife.blogspot.kr	1

MHA for MySQLとDeNAのオープンソースの話

by Yoshinori Matsunobu on Sep 16, 2011

Accessibility

Tags

Upload Details

Usage Rights

29 Embeds 7,018

Statistics

MHA for MySQLとDeNAのオープンソースの話 — Presentation Transcript