Movatterモバイル変換

MySQL Casual な生活 2012/04/19 hatak at MySQL Casual Talks Vol.3

自己紹介• hatak (@hisashi)• 株式会社コロプラ (2010/01-) • 開発からインフラ運用・障害対応まで • 最近はスマフォアプリを少々 • わりと何でもやります• インフラ / Perl な場所に時々います• 写真好きです

アジェンダ• コロプラな話• メンテナンスな話• チューニングな話• 障害な話

コロプラとは• 位置ゲーのプラットフォーム • 「コロニーな生活」などのモバイル向けゲームを自社運営 • パートナー様へのAPI提供• プラットフォームの規模感（2011年12月現在） • ユーザ数 : 250万人 • 位置登録回数 : 4,300万回/月 • 総PV数 : 37億/月（パートナー様コンテンツを除く）

全体的な構成• コロプラ（プラットフォーム） • ユーザ情報 • 課金情報 • 位置情報• コロプラ上に各アプリが存在 • それぞれのサービスとして開発アプリアプリアプリ • コロプラのAPIをJSONで呼び出し• パートナー様のサービスからも利用 COLOPL PF

基本的な構成• サーバ • 自社運用の物理とクラウドを併用 App • CentOS 5.x/6.x INSERT UPDATE SELECT• 開発言語 DERETE • Java/PHP MasterDB LVS• データベース rep lica tion • MySQL CommunityServer 5.1/5.5 • ほぼ InnoDB SlaveDB SlaveDB • master : slave = 1 : n の構成 • LVSでslaveを束ねて利用

MySQL 5.5 使ってます• 本番系DBサーバの7-8割がMySQL 5.5 • InnoDBのパフォーマンスと utf8mb4 が目的 • 5.5.12 (2011/04) 頃から、新規構築 or サーバ交換の際にアップデート • 今のところは大きなトラブルなく運用中• my.cnf の修正を忘れずに my.cnf • 廃止されたオプション -default-character-set = utf8 +character-set-server = utf8 • default-character-set -default_table_type = InnoDB DB +default_storage_engine = Inno • default_table_type • InnoDB Plugin がビルトインのため plugin-load 等の記述が不要前回(#2)の @oranie さんのLT資料にまとまってました (@oranie++)

そんなカジュアルなお話をさせていただきます

メンテナンスな話 Maintenance

データベースサーバには運用が必要• 長く運用していると様々なメンテナンスが必要となる • 論理な事情（件数の多いインデックス張り替え、スキーマ変更、etc...） • 物理な事情（ディスク故障、筐体交換、etc...）• Slaveの場合はわりと簡単 • 代替サーバを構築して入れ替え• Masterの場合は面倒 • うっかりやると刺さる（処理が詰まってしまう）• でもサービス停止してのメンテナンスは告知などが大変 • 停止させれば作業は楽になるところもあるけど • ゲームバランスや仕様の兼ね合いからも避けたい

オンラインマスタ切り替え方法• マニュアルオペレーションで対応する一つの例です • メリット：無停止で切り替えられる • デメリット：入れ替え分のサーバ台数が必要• 前提条件対象DB系統だけでユニークキーが決定できる• 大まかな流れ • 現在のSlaveを基に、新規のMaster&Slaveセットをまるごと準備 • 新SlaveをLVSに入れ、代わりに現Slaveを外す • 現Masterから新Masterに変える

切り替えの流れ• 右図のような構成の場合 App • 更新系：MasterDB INSERT UPDATE SELECT • 参照系：LVS経由でSlaveDBに分散 DELETE MasterDB.cur LVS replication SlaveDB.cur SlaveDB.cur

切り替えの流れ• SlaveDB.curを基にMasterDB.newを構築 App • MasterDB.newにも伝播するように設定 INSERT UPDATE SELECT • log_slave_updates DELETE MasterDB.cur LVS replication MasterDB.new SlaveDB.cur SlaveDB.cur

切り替えの流れ• MasterDB.newの下にSlaveDB.newを構築 App• 新系統は十分にpreloadしておく INSERT UPDATE SELECT DELETE MasterDB.cur LVS replication MasterDB.new SlaveDB.cur SlaveDB.cur replication SlaveDB.new SlaveDB.new

切り替えの流れ• SlaveDB.newをLVSに入れていく App INSERT UPDATE SELECT DELETE MasterDB.cur LVS replication MasterDB.new SlaveDB.cur SlaveDB.cur replication SlaveDB.new SlaveDB.new

切り替えの流れ• 代わりにSlaveDB.curをLVSから外す App INSERT UPDATE SELECT DELETE MasterDB.cur LVS replication MasterDB.new SlaveDB.cur SlaveDB.cur replication SlaveDB.new SlaveDB.new

切り替えの流れ• これでSlaveDBの切り替え完了 App• MasterDB.new の auto_increment INSERT 値を少し増やしておく UPDATE SELECT DELETE • 重複を避けるため MasterDB.cur LVS replication MasterDB.new replication SlaveDB.new SlaveDB.new

切り替えの流れ• AppからのMasterDB参照先を変える App • DNS 設定を書き換えるなど INSERT UPDATE SELECT• MasterDB.curからのレプリケーショ DELETE ンが完全に止まるまで待つ MasterDB.cur LVS replication MasterDB.new replication SlaveDB.new SlaveDB.new

切り替えの流れ• 切り替え完了！ App INSERT UPDATE SELECT DELETE LVS MasterDB.new replication SlaveDB.new SlaveDB.new

preloadとは• 事前に InnoDB Buﬀer pool にデータを読み込ませておく作業 • 本番投入直後でも Buﬀer pool hit rate をあげるため • ディスクI/O が極端に上がることを避ける • 特にMaster切り替えはいきなり本番投入 & しかも切り戻せない• いったん全テーブルのデータを読み込ませる • 全テーブルに対して SELECT * FROM ... でも読み込める • ダミーでINSERTするとbinlogに書かれるのでslaveにも伝播できる mysql> CREATE TABLE _preload LIKE <table_name>; mysql> ALTER TABLE _preload ENGINE = BLACKHOLE; mysql> INSERT INTO _preload SELECT * FROM <table_name>; mysql> DROP TABLE _preload;

より現実に即したpreload• やっぱり本番DBと同じ状況を再現してあげるのが良い • 現実のクエリを受ける方が最適化される• Weightを低めにしてLVSに入れてしまう• 他の本番DBからリレーする • tcpdump + pt-query-digest • 特にMasterからリレーする場合はSELECTだけにするように注意 $ sudo /usr/sbin/tcpdump -i eth0.100 port 3306 -s 65535 - x -n -q -tttt | pt-query-digest --type=tcpdump --no-report -- execute h=server.new -u'hoge' -pfuga --filter='$event- >{fingerprint} =~ m/^select/'

気をつけるところ• 応用すればだいたいのケースには対応できる • mk-slave-move でSlaveをつなぎ替えるとか • 障害の時でもまずはMasterを切り替えてしまって復旧するとか• ただしエラーになる可能性はある • Master切り替え時に Duplicate Key などのエラーになる可能性はある • Masterを手早く切り替えられるようにしておく必要 • 新旧のMasterに更新クエリが来ている状態は極力短く • トランザクションを意識した作りでないとデータ不整合も起こりうる得る

ちょっと力ずくな感じですみません。。

チューニングな話 Connections

ソーシャル性の強いゲームはちょっと特殊• 人気があればピークタイムのトラフィックもそれなりにある• イベントの終盤などで一気に負荷が高まる瞬間がある• アプリケーションサーバ / SlaveDB は並列化できる• でも、一番最初に訪れるボトルネックはMasterDB• （本来的には）スキーマや設計含めてアプリ開発者と一緒に考えるべき • でもミドルウェア/インフラ側である程度工面してあげられることもある• カジュアルな対策をいくつかご紹介 • チューニングと呼ぶほどではないかも知れませんが。。。

サーバサイドのチューニング• 個別の設定は各種書籍などでも紹介されているので割愛 • High Performance MySQL • エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド• my.cnf をひたすら調整 • オンデマンドで運用中に変更できるパラメータも多い • Weightを下げたSlaveで試しに調整するなど

よくある設定箇所• sync_binlog = 0 • ディスクに同期するとやはり遅いので。。• innodb_ﬂush_log_at_trx_commit = 0 [Default: 1] • クラッシュ時の信頼性を犠牲にパフォーマンスを得る設定 • 0 のとき、メンテナンス等で更新クエリが止まったときに一気にディスクI/Oが発生したりする挙動がありました• innodb_support_xa = 0 [Default: 1] • ディスクへのFlushを減らすため• そのほかもDBの系統ごとに試してみたりしている • サービスによってクエリの傾向が違うので個別に調整が必要

サーバ自体もチューニング• ディスクのマウントオプションを変えてみる • atime周りやI/Oスケジューラを変えてみるとか • ext4でのライトバリア無効化• メモリを詰めるだけ積む • 自社運用の物理サーバであればメモリを積みまくるのも一つ • 標準的なDBサーバには72GBのものを採用しています • ただし、落とし穴が... • 「空のデータセットにデータが溜まっていくとswapしてしまう事件」 • 続きはLTで...

クライアント（アプリ）サイドのチューニング• DBの負荷に引きずられないような設計にしておくのが第一 • DBへの問い合わせが最小限となるアプリ設計が理想• アプリケーションコードを修正できるならばいろんな方法がある • memcached などのキャッシュを有効に使う • 遅延が許される更新処理（ログなど）を非同期にする• 例えばライブラリの設定一つでも結構かわる

MySQL Connector/J• Java系サービスではJDBCドライバとして MySQL Connector/J を利用 • 設定できるプロパティは結構多い• 設定値のプロパティファイルがバンドルされている • ソースを見るとよく分かる ( https://launchpad.net/connectorj ) • maxPerformance, fullDebug などは設定の参考に $ cat maxPerformance.properties ... cachePrepStmts=true cacheCallableStatements=true cacheServerConfiguration=true useLocalSessionState=true elideSetAutoCommits=true alwaysSendSetIsolation=false enableQueryTimeouts=false

プロパティ調整してみた• cacheServerConﬁguration [Default: false] • 接続のたびにサーバ設定を確認する • 系統での設定がそろっているのであればキャッシュして良いはず• 設定してみた • これだけでも劇的に変わって負荷が下がったちゃんとプロパティ設定しましょう

（本番に影響しない範囲での）試行錯誤大事です

未然に防ぐことは大事• デプロイ時に担当者が異常がないかを見ることは当然 • でも、デプロイ以外のトリガーのケースも多々ある• 時々巡回したりしてチェック • メトリクス監視（Cacti など）の値の変化 • 負荷をバルクチェックしてみたり (SNMP使う自前スクリプトとか)• アラートが上がったら何かあるステータス監視（Nagios など）からの通知サービス内掲示板やTwitterに投稿されているユーザさんの声ユーザサポートからの確認

なにかおかしい？ときのチェック箇所• 何がおきてるか、を把握 • アプリケーションサーバ • エラーログ • MySQLサーバ • SHOW FULL PROCESSLIST コマンド • slowlog • tcpdump ¦ pt-query-digest でクエリ読む• 何があったか、を把握 • ソースツリー & git log を追っていく AdventCalendar の @riywo さんの記事にまとまってました (@riywo++)

MySQL設定/テーブル定義に起因する障害• RANGE PARTITION 作り忘れ • cron で作るようにしていても、サーバ切り替え時に移行漏れ。。• 切り替え時の接続ユーザ権限修正忘れ • MasterDB/SlaveDB などで権限を変えてるケース• auto_increment 桁あふれ • 設計時、そんなに長く使うとは思っていないことも多々あったりしますこのような障害は、多くの場合 Nagios 監視などで未然に防げる

サーバに起因する障害• SHOW PROCESSLIST で見たときに Commit が滞留するなど • ディスクI/Oがボトルネックになってるケースが多い• OSレベルでのエラー検知ができないケースもある • syslogなどにはエラーは見受けられないがパフォーマンスが上がらない • サーバベンダー提供のツールで見るとRAID構成ディスクの障害予兆が。。 • 自動での定期チェック時にパフォーマンス低下してたケース HWレベルでもしっかりとチェックしておく必要がある

アプリケーションに起因する障害• クエリが詰まる • 適切にインデックスが張られているかチェック • クエリ自体に無理がないか確認 • 元々想定していた以上のデータが蓄積されていることも。。• Sleep が溜まる • アプリケーション側で処理がブロックされている • 挙動がおかしいアプリケーションサーバがあることも複合的な要因のこともあるので、コード読んだりすることも必要

あくまで一例なので、ケースバイケースです

まとめ• 総移動距離134億キロの位置ゲーはMySQLのおかげで運用できてます• オンラインマスタ切り替えもそんなに難しいことではないです • 一つの手法として用意していれば、選択の幅は広がる• サービスごとに求められる環境/パフォーマンスは異なります • 「少し変える」ことで「かなり良くなる」こともある • 調べる - 試すの繰り返しでちょっとずつ改善• いろんな視点から考えることが大事だと思ってます • 開発で頑張りきれないところはインフラ・運用からもサポートしてあげる • 障害もいろんなタイプがあるのでアプローチもさまざま • サーバだけでなくてコードやサービスも見ないといけない

ご清聴ありがとうございました！

Movatterモバイル変換

Change Language

MySQL Casual な生活

Embed presentation

Recommended

More Related Content

What's hot

Viewers also liked

Similar to MySQL Casual な生活

MySQL Casual な生活