LINE DBシステムの高可用性【LINE Developer Conference@インフラ回レポート】
LINE Developer Conference@インフラ回に参加してきたのでその時のレポートを3回に分けて報告致します。
第2回はDBの高可用性についてのお話。
Session2. LINE DBシステムの高可用性について
今回は以下のお話をお伺いしました。
- LINEサービスの特徴
- 自動FAILOVER
- 無停止Shard追加
LINEサービスの特徴
2014/4/2に世界中で4億ユーザを突破しました。
ユーザ数の大きなところの内訳は以下
- Japan 50million
- Taiwan 17million
- Thailand 24million
- Indonesia 20million
- Indo 18million
使っているDBMSとしては以下の様な内訳
- Cubrid :5%
- MySQL 73%
- Oracle 1%
- SQL Server 17%
使っている主な言語は
- Java
- PHP
- C
- C++
- C#
容量算定の難しさ
LINEツムツムは予想同時接続数は少なかったが実際は初期想定よりも10倍に。
ユーザ数は1000万突破。
サービスのオープン後、2週間でサービス提供が不可能になってしまったので、メモリやサーバの追加、SAS->SSDへの切り替えなどを行ったりして対応したようです。
ツムツムの例のように急速で増えるユーザ数に事前に備えといけない。
新規サービスや現在の運営されているサービスについても改修したりしないといけない。
自動Failover (Multi-Master Replication Manager)
今回はLINEでよく使われているMySQLについて説明頂ました。
一般的構成の問題
一般的MySQLシステム構造はMaster/Slave構成が多いが、Masterサーバがダウンした場合、Masterに接続できないためアプリからは継続的エラーが発生する。
対策としては
- ネットワークエンジニアがMasterIPをスレーブに付与する方法
- Applicationから参照するDBサーバのIPをスレーブに変更してサービスを普及させる方法
の上記2つがあるが、必ずメンテナンスが必要で人の手が必要になる。
LINEでの構成
LINEではMaster/Slave構成にプラスしてPercona社が開発したMulti-Master Replication Manager(MMM)というものをカスタマイズして使うことでマスターも冗長性をとっている。
参考
MySQLの死活監視と仮想IPアドレスの切り替えを行ってくれます。
MMMとは、MySQLのマルチマスタレプリケーションに関するモニタリングやフェイルオーバー、
そして、その管理などを行う柔軟なスクリプト群です。
LINEではMaster/SlaveにアクセスするようにWrite用のVIPとRead用のVIPを使っています。
MasterサーバとSlaveサーバはMMM ManagerがHeartbeatを送って管理しており、
サーバがダウンした時はMMM ManagerがVIPなどを操作します。
自動Failover
マスターがダウンしてフェイルオーバーする挙動を順序で説明してくれました。
- 1. MMMがmaster DB 障害確認
- 2. SlaveにMasterがダウンしたとの情報を転送する
- 3. SlaveはReplicationが完了されるまで待機
- 4. Replicationが完了したらReadOnlyを解除する
- 5. Writer IPをSlaveのサーバに割り当てることでマスターがフェイルオーバーする
MMMのカスタマイズ内容
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できるようにしている。
無停止Shard追加 “N-Base”
N-Baseとはなんぞや？とぐぐっても何かは出ません。(2014/04/16現在)
LINEが独自開発したプロセスソフトウェアで、N-baseシステムを使っているDBサーバ構造は以下の様な特徴があります。
- データを分散して格納できる(Mongo的なノリかな)
- 無停止でShard追加/削除できる
- Shard#1 Shard#2…を管理するMGMTがある
- MGMTがハッシュ演算したデータのマッピング情報を配信している
一般的Shardの問題
2台のShardが80%のリソースを使ってしまった場合の対策としては以下の方法が考えられる。
- 新しいShardを追加して、そのサーバにデータを追加していく
- Migrationしてデータを分散させる
しかしすべてのMigrationが終わるまでメンテナンスの必要がある
N-base(MGMT-CGMap)
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サーバを追加する順序について説明してくれました。
ここではShard#1とShard#2が既に存在しているグループにShard#3を追加するという想定で説明します。
- 1. サーバの準備が終わるとMGMTはCGmap情報(CGID30と60をShard#3に変更しますなどの情報)を準備する
- 2. 修正が終わったMapテーブル情報を用いて各Shardに移動を指示する
- 3. MGMTから命令をうけたShard#3はShard#1,Shard#2に接続しに行く
- 4. 接続成功したらShard#3に小分けにした複数回のSelect/Insertを用いてデータをインポートする
- 5. copyが終わったらMGMTにコピー完了を報告完了する
- 6. 報告をもらったらMGMTは新しいCG MapをAPサーバやShardサーバに再配布します(ここからCGID30,60のデータはShard#3を見るように。)
- 7. 全てMigrationが終わったら負荷が分散されるようになります
ハッシュ演算を用いたグループIDのおかげで運営中でも無停止でShardサーバの追加・データ移動が可能になっているようです。
コピー中の追加/更新データの扱い
Shard追加中にデータの変更があったらどうするんだろう？と思っていたらちゃんとここも説明してくれました。
使用者テーブルにSys_Tというカラムが追加されており、これはInsert/Updateされた時間を記録している。
この時間を元に一番古いデータからlimitで何回かに分けてSelect/Insertする。
Sys_Tカラムを参照することでShard#1の負荷分散、および次の分割したコピーの時に再度コピーされるようになっているようです
個人的感想
MySQLとか使ってないのかなと勝手に思ってましたが、以外に結構ガッツリ使っててちょっと驚きでした。
DB大好きっ子としてはレプリの挙動など色々と聞きたいことがあったのですが、質問時間はほぼカットされてしまいました。
懇親会で色々聞いてきましたので後ほど番外編で記述します。
LINEサービスのネットワークインフラ取り組み事例紹介【LINE Developer Conference@インフラ回レポート】へ続く
