■諸元
日時: 2011/09/13 開場19:10 本編19:30-22:00
会場: リクルートエージェント本社(東京都千代田区丸の内1-9-2 グラントウキョウサウスタワー24F)
タグ: #rag_tech0913 #ragpress
要綱: http://www.r-agent.co.jp/info/rss/event/oracle_ace/ http://partake.in/events/2241a330-d9ce-437f-88dd-1381e094235b
当日のタイムライン抽出: http://togetter.com/li/187708
■松信氏講演
自己紹介
Mobageの規模
１日あたり20数億PV以上
1000台以上のDB(MuYSQL)サーバ、それ以上のWebサーバ
国内だけで数拠点のIDC
数百を超えるアプリ
SPOFをなくしたい
SPOF…その箇所がダウンするとサービスが止まる
いかなる時にも緊急対応が必要になる
早朝だろうと深夜だろうと対応が必要
アプリの数が多ければ確率も上がる
メンバーも疲弊する
MySQLの世界ではスレーブは冗長化によってSPOFをなくすことは簡単
マスターは単一なので難しい
MYSQLマスター障害対応の課題
MySQLのレプリケーションは非同期または準同期
スレーブ毎にレプリケーションのズレが生じる
正しく復旧するにはスレーブ間でのズレを解消して(最低限)マスターから取得したのを反映する必要がある
これを手作業で行うのは難しい
MHAはこれを全自動でやる
MHAのアーキテクチャ
マスターの稼働監視およびダウン時の自動フェイルオーバーを実現するツール
Perlで書かれている モジュールの依存関係は少ない
MySQL5.0以降で動作
管理サーバ(MHA Manager)・ここのバイナリログの差分修復等を行うツール(MHA Node)から構成される
http://code.google.com/p/mysql-master-ha/ にてOSSで公開されている
内部的な動作
i1 SQLスレッドの実行を終えるまで待つ
i2 最新スレーブのリレーログのヘッダを解析して各スレーブに適用すべき差分位置を特定
X マスターにアクセス可能ならマスタから差分を保存
i1 i2 Xをすべて組み立てて１個のバイナリログにして配布・反映する
主な特徴
マスタの稼働監視からフェイルオーバーまでを自動でできる
フェイルオーバーが秒単位 アクティブ／アクティブのため
非同期レプリケーションにもかかわらずスレーブ間での同期がとれている
任意のスレーブをマスタにできる
いくつかの箇所から外部スクリプトを呼ぶ機能がある(電源OFFやIPアドレスのフェイルオーバーなどに使う)
MySQL5.0以降であれば標準のMySQLで動作する
インストール・アンインストールにあたり、現在のmysqlプロセスやレプリケーションを止める必要がない
MHA自体は追加の負荷をかけないため、パフォーマンスが低下せず追加のサーバも不要
ストレージエンジンに依存しない
バイナリログのフォーマットに依存しない StatementベースでもRowベースでも大丈夫
拡張ポイント
seconary_check_script
マスタがダウンしたかどうかを複数のネット経路から判定するために呼ばれる
マスタに接続エラーになったときに呼ばれる
MHAに標準搭載されているスクリプト
shutdown_script
電源強制OFF
フェイルオーバーの直前に呼ばれる
master_ip_failover_script
マスタのIPアドレスの更新やアプリケーションから接続するためのユーザの作成など
ケーススタディ
DeNAのサービスにおいて150を超えるマスタ／スレーブのペアに対してMHAを導入
MySQLはめったにクラッシュしないがハードウェア障害などで落ちることがある
拡張ポイント
マスターのダウン検知
マスタの強制ダウン
マスタのIPアドレスのフェイルオーバー
OSダウンによるフェイルオーバにはダウン検知に10秒、フェイルオーバーに4秒程度
マスタの生死判定
フェイルオーバーの可否判定
フェイルオーバー処理
差分修復が本当に必要があるか？
回線障害のときなどに必要になった場面があった
デモ
3台構成 マスタ1 スレーブ2
・マスタのmysqldをkillして優先度を高めたスレーブをマスタに昇格させる
・スレーブの片方を止めた状態でマスタを更新し(スレーブ間で差分が発生している)、マスタでのmysqlをkillする
・スレーブの片方を止めた状態でマスタを更新し、マスタを強制シャットダウンする
既存のソリューションに対する優位性
マスタ障害が起きてもスレーブ間での整合性が崩れるに迅速にレプリケーションを再開できる
既存MySQLレプリケーション構成を変える必要がない
サーバの追加投資が不要
既存のレプリケーション構成とほぼ同等のパフォーマンスを得られる
どのストレージエンジンでも動作する
次バージョンでマルチマスタに対応する
他の方法との比較・優位性
Pacemaker+DRBD
既存環境にそのままいれることができる
スタンバイサーバが不要
フェイルオーバーが高速
MySQLCLuster Galenaに対する優位性
難しくない
既存環境にそのまま入れられる
その他の特徴
任意のスレーブを新マスタできる
フェイルバックをするのが面倒 障害マスタへの復旧には多くの場合作りなおしが必要
準同期レプリケーションを併用することでデータ消失をほぼ防げる
サービスの増強と縮退
ゲームタイトルの人気を正確に見積もることは困難
想定外の人気が出た場合
スレーブを追加する
水平分割してマスタを増やす
マスタを別マシンに移行したい時
よくある
メンテナンス時間を設ければ作業自体は簡単 マスタとスレーブを入れ替える
だがメンテを何度もやりたくない
ダウンタイムなしでマスタ切り替え
そのためには
マスタへの更新を一瞬止める
既存のスレーブがマスタからのレプリケーションをすべて終えていることを確認
新マスタへ透過的に接続できるようにする
スレーブが新マスタからレプリケーション開始
これらのステップを0.5秒から3秒でできれば許容範囲
書き込みのブロックをどうするか
FLUSH TABLES WITH READ LOCK
クライアントでタイムアウト設定していないとロック待ちになる
全テーブルをフラッシュのするので時間がかかる場合がある
実行中のトランザクションは実質エラーになる
SET GLOBAL read_only=1
更新を実行した時点でエラーになる
実行中のトランザクションは実質エラーになる
アプリから使っているユーザをDROPする
新規接続ができなくなる
接続済のセッションは切るまでエラーにならない
他のサーバにまたがった更新でも不成功にならない
安全性と高速性のバランスをとる
マスタでの長時間更新しているセッションがないことをチェック
ユーザをDROP
一定時間(最大3秒)アプリからの接続がなくなるまで待つ
接続がなくなるか時間切れになったらFLUSH TABLES WITH READ LOCKにより全体をロックして切り替えに入る
接続を張りっぱなしにしているデーモンプロセスについての考慮も必要
だいたい1秒もあればブロックが完了する
マスタ切替えのデモ
オープンソースを取り巻く世界
ベンダ 作る … サポートで収益
RedHat MySQL
SWサードベンダ インテグレートする … サポートで収益
HP IBM
サービス企業 ユーザ … 商用製品を使わずに節約できる
Facebook Twitter
ベンダ(MySQL)からサービス事業者(DeNA)への転職
MySQL時代 まとまった時間で特定のソリューションに取り組むことが難しかった
サービス事業者でないとできなかったこと 中長期的な施策(MHAの製作等) 1000台規模のサーバ運用の経験とそこから派生する潜在ニーズの発掘
遅いトランザクションを特定するツール 監視のしきい値となるKPIを決める など
サービス企業の中からDeNAに行った理由
スペシャリストというキャリアパスがある マネージャにならなくても高収入
データベーススペシャリストの働き場所は大規模サービス事業者でないと難しい
給与は日本円でもらいたいが海外での技術プレゼンスの意識があることが長期的に大事
付加価値の高い仕事をするためにある程度チームのメンバ層が厚いことが必要
オープンソースに貢献する意義
ノウハウを外に出す必要があるのか？と考えている企業ばかりだと技術は発展しない
オープンソースソフトウェアの価値
貢献するというだけなら誰でもできる
リリースしたからと言って貢献しているとは限らない
リリースしたからといって役立つとは限らない
現場で使っているソフトを出す
MHAはMobageの環境で実際に使っていて、実績がある
多くの人にとって使いやすいソフトを出す
公開したきりで発展がとまっているOSSは少なくない
MHAはMySQLサードベンダの商用サポートがある
インフラエンジニアのキャリア
0 件のコメント:
コメントを投稿