LINE Developer Conference@インフラ回に参加してきたのでその時のレポートを3回に分けて報告致します。
第2回はDBの高可用性についてのお話。
今回は以下のお話をお伺いしました。
2014/4/2に世界中で4億ユーザを突破しました。
ユーザ数の大きなところの内訳は以下
使っているDBMSとしては以下の様な内訳
使っている主な言語は
LINEツムツムは予想同時接続数は少なかったが実際は初期想定よりも10倍に。
ユーザ数は1000万突破。
サービスのオープン後、2週間でサービス提供が不可能になってしまったので、メモリやサーバの追加、SAS->SSDへの切り替えなどを行ったりして対応したようです。
ツムツムの例のように急速で増えるユーザ数に事前に備えといけない。
新規サービスや現在の運営されているサービスについても改修したりしないといけない。
今回はLINEでよく使われているMySQLについて説明頂ました。
一般的MySQLシステム構造はMaster/Slave構成が多いが、Masterサーバがダウンした場合、Masterに接続できないためアプリからは継続的エラーが発生する。
対策としては
の上記2つがあるが、必ずメンテナンスが必要で人の手が必要になる。
LINEではMaster/Slave構成にプラスしてPercona社が開発したMulti-Master Replication Manager(MMM)というものをカスタマイズして使うことでマスターも冗長性をとっている。
参考
| EC2上では、仮想IPアドレスなどのIPレベルの機能が制限されているため、仮想IPアドレスを使用した冗長化は基本的には使用できません。が、DNSを使用することで、VIPほどの精度は高くないもののMySQL Multi-master構成を構築することができました。今回は、MySQL Multi-masterの切り替え用の支援ツールとして、Multi-Master Replication Manager for MySQLを使用します。このツールでは、MySQLの死活監視と仮想IPアドレスの切り替えを行ってくれます。もちろん、EC2上では仮想IPアドレスは使えないので、そのままではうまく動作しませ… EC2上でMySQL Multi-masterフェイルオーバー - stanaka's blog - stanaka's blog |
MySQLの死活監視と仮想IPアドレスの切り替えを行ってくれます。
| suz-lab.com は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、suz-lab.comが全てとなります。あなたがお探しの内容が見つかることを願っています！ suz-lab.com - suz lab リソースおよび情報 - blog.suz-lab.com |
MMMとは、MySQLのマルチマスタレプリケーションに関するモニタリングやフェイルオーバー、
そして、その管理などを行う柔軟なスクリプト群です。
LINEではMaster/SlaveにアクセスするようにWrite用のVIPとRead用のVIPを使っています。
MasterサーバとSlaveサーバはMMM ManagerがHeartbeatを送って管理しており、
サーバがダウンした時はMMM ManagerがVIPなどを操作します。
マスターがダウンしてフェイルオーバーする挙動を順序で説明してくれました。
LINEでMMMをカスタマイズしている内容についても教えてくれました。
Multi-Monitor構成
1台サーバで複数のMonitor構成をとっている
FailOver時外部Script適用
FailOver時に指定されたShellScriptを呼び出している
Replication Check機能削除
サービス安定性の安定性を考えた結果MMMのReplicationCheck機能を削除して、Replication遅延またはエラーでFailOver発生するようにしているそうです。
障害判断の変更
既存MMMは[SELECT Now()]を実行して実際にQuery実行エラーになっている。
これをDummyTableへUpdateQueryを実行するチェックに変更し、エラーになった場合にFailoverが発生するようにしている。
そうすることでDiskFull、SystemError時にもFailoverできるようにしている。
N-Baseとはなんぞや？とぐぐっても何かは出ません。(2014/04/16現在)
LINEが独自開発したプロセスソフトウェアで、N-baseシステムを使っているDBサーバ構造は以下の様な特徴があります。
2台のShardが80%のリソースを使ってしまった場合の対策としては以下の方法が考えられる。
しかしすべてのMigrationが終わるまでメンテナンスの必要がある
MGMTはMappingテーブル情報の管理をしています。
普通のShardのノリだと以下の様な感じにデータが格納されます。
| Username | ShardNo |
| Cony | 1 |
| Moon | 2 |
| Brown | 2 |
| Sarry | 1 |
| Jessica | 2 |
| James | 1 |
しかしN-Baseでは全てのユーザにハッシュ演算してグループIDを発行してマッピングされています。
| Username | CGID | ShardNo |
| Cony | 10 | 1 |
| Moon | 20 | 2 |
| Brown | 40 | 2 |
| Sarry | 30 | 1 |
| Jessica | 60 | 2 |
| James | 50 | 1 |
こうすることで例えばShard#1にはCGID10、30、50のデータが、Shard#2にはCGID20,40,60のデータが入り、Conyのデータが欲しかったらShard#1へみにいく、Moonのデータが欲しかったらShard#2へみにいく…
と、データを分散して格納することができるようになります。
また、データの分散はLINEのアルゴリズムによって均等にわけられています。
無停止でShardサーバを追加する順序について説明してくれました。
ここではShard#1とShard#2が既に存在しているグループにShard#3を追加するという想定で説明します。
ハッシュ演算を用いたグループIDのおかげで運営中でも無停止でShardサーバの追加・データ移動が可能になっているようです。
Shard追加中にデータの変更があったらどうするんだろう？と思っていたらちゃんとここも説明してくれました。
使用者テーブルにSys_Tというカラムが追加されており、これはInsert/Updateされた時間を記録している。
この時間を元に一番古いデータからlimitで何回かに分けてSelect/Insertする。
Sys_Tカラムを参照することでShard#1の負荷分散、および次の分割したコピーの時に再度コピーされるようになっているようです
MySQLとか使ってないのかなと勝手に思ってましたが、以外に結構ガッツリ使っててちょっと驚きでした。
DB大好きっ子としてはレプリの挙動など色々と聞きたいことがあったのですが、質問時間はほぼカットされてしまいました。
懇親会で色々聞いてきましたので後ほど番外編で記述します。
LINEサービスのネットワークインフラ取り組み事例紹介【LINE Developer Conference@インフラ回レポート】へ続く
こんにちは。virapture…
View Comments
Can you be more specific about the content of your article? After reading it, I still have some doubts. Hope you can help me.
Thank you very much for sharing, I learned a lot from your article. Very cool. Thanks. nimabi
Thank you very much for sharing, I learned a lot from your article. Very cool. Thanks. nimabi
The point of view of your article has taught me a lot, and I already know how to improve the paper on gate.oi, thank you.