LINE Developer Conferenceに行ってきた。
テーマはインフラ。
以下備忘録。
1.サーバ
インフラエンジニアの教科書の作者でもある佐野 裕さんが発表
事前アナウンスではLINEにおけるIvy Bridge Serverの選定が予定されていたがリクエストが多かった運用やトラシューの実例を話すことに。
※個人的には電力関連のテストを一番聞きたかったのでガックリ
LINE2年間
・サービスとユーザー数は増加したがインフラ部門の人員は増えてない。
セットアップ
・プラグインストール(kickstartとかWDS)でやってる
運営時の問題点
ICDC内部でのコネクションタイムアウト
・1G のL2で700MBトラフィックでディスカード発生
・原因はshort burst traffic一瞬のトラフィックが大量に来たためL2のポートでオーバーフローが発生
・メッセージング系のアプリではよく起きる模様。
・例えばサッカーワールドカップとか。
・対策しとてバッファが大きいL2に交換、独立したNW空間を構築
IDC空間の不足
・気が付くとDC空間がなくなっている。
・対処として性能ボトルネックサーバのスケールアップと仮想化でスペース確保。
一番多いサーバはHBase
・スケールアウト有効
・それでも1000台の壁がありサーバが故障する件数が増え運営コスト上昇。
・対策としてスケールアップしていみるとI/Oがボトルネックになっていることが判明。
・解消のためにHDD/SSD/PCI storageで書き込み速度調査、RAID-0でもRAIDできないPCI storageが早かったので採用。
・ボトルネックはCPUとなる対策はここで打ち止め。
仮想化
・vSphereを採用 (会場ザワザワ…)
・理由は運用性の絶対的な基準として選択した、現在は数1000台が仮想している1台に付10台くらい動いている
運営イシュー
・バルスは乗り切った
※テレビで人気アニメーションが放映された時にtwitter以外でもLINEでセリフを送信する現象
正月
・無事じゃなかった。
・トラフィックの上昇は予想通りだったがRedisストレージの一部shareに負荷集中
・redisとNICの割り込みが同じ奇数番号のCPU coreを使っていることを発見。
watch -n1 "cat /proc/interrupts"
でわかる。
・応急処置としてCPU coreを偶数番号に手動割り当て(taskset)を行いcpuが100から 70-80で落ち着いた
・恒久処置としてredisのIRQをいじった?
※聞き取れなかった
2.DBシステム
崔 美京さん発表
LINEサービスの特徴
・DBMSはmysql 73%
・ディズニーアプリ
当初の10倍の同時接続数を超えてしまった。サービスイン1週間後に不安定になる、色々スケールアップしたが結局ノードを追加した。
自動ファイルオーバ
マルチマスターレプリケーション
・一般的なmaster/slave(レプリカ)はマスター障害時に切り替える際は一般的にはNWのIPとor APの変更で切り替える。
・リスクあり。
・そこで採用したのはMySQL-MMM
・マルチマスターにLINEでカスタマイズして使用している。
・witevip/readvipを割り当て障害時はIP移動を行う、IP移動するのはMMMの動作である。
shared追加
・無停止shared追加 N-Base
・LINEで独自開発したプロセスソフトウェア
一般的にはshadeを追加し、migrationする
N-Baseではhash計算してマッピングする、全てのユーザーIDにグループIDを割り当ててshared NOを割り当てる。select/insertでデータの移設を行う完了すると負荷が均一になっている。
Nbase追加情報
・マルチモニターに構成した
・failover構成にscriptを適用
・replicasionチェック機能削除
・ダミーテーブルにupdateしてエラーならフェイルオーバーする
3.LINEサービスのNWインフラの取り組み
三枝さん発表
ユーザー数4億突破
サーバ間通信が大量発生、そのためDC内NWが不安定なる。
DCスペースの確保について
困った
・unnow unicast follding
・1Gbps超のフラッティングされるとパケットドロップが起こってしまう
DCのNW
・L2ドメインをどこまでにするか
・pod単位でL2ドメイン
・サーバは数千台
・unnow unicast follding時にきつくなる
・NWの不安定を減らしつつサーバ配置の自由度を高める
・L2ドメインはエッジスイッチ単位とする
・internet抜け通信とpod間通信の分離、160GBで結んだ
L3DSR構成
・L3DSRとは戻りNWはLBを経由しない
・L3DSCP方式を採用
DC選定基準
・高効率/高密度を選ぶ
・1ラックあたりの電気使用量が大きい物
運用課題
・51Uラックを採用/特注
・設計上は44U使える
エアフロー
・空調効率を高めるため制約が多い
・問題はSW
・ラックの後ろにSWをマウントしたが一番温度が高いところで50度あった
・配線のしやすさを考慮し背面SWは堅持したい
・そこで自作スイッチダクトを作った最大で1U SWが3台入る
海外利用者向けに拠点確保
・ボトルネックはキャリア間の相互接続ポイント
・そもそも遠い(レイテンシ)
・local ISPと直正つパスを持つ
・利用者に近いところに拠点を持つ
・アメリカ2箇所/アジア3箇所/ヨーロッパ1箇所
・国際専用線は高いのでリングトポロジーを採用
実現したい
・インターネット通心を利用者の近くにで収容
・拠点間通信をどうするか
・2つのNWを別々に構築
・MPLSをせっかく使っているので運用をシンプルになるように
サイトの選択
・クライアント側に機能を実装
・色々情報を参考にstaticに割り当て
=>キャリア登録
=>登録電話番号
=>geoIP情報
=>GSLBも検討
スマートファンメッセージアプリ
・リアルタイム性重視
・TCPセッションを張り続ける
・深夜でもセッションが落ちない
LBのセッション数がボトルネック
・セッションテーブルのエージング時間調整
解決策
機器を増やす
=>運用に問題
より高スペックと構成
=>価格的にも選択できない
・そこでLBでセッションを持たせないstatless SLBで実現
・セッションテーブルではなくてハッシュテーブルを使って負荷分散
原理的にはクライアントが増えても対応できるはず
・検証へ・・・
あるメーカはサーバが1台落ちると全てのhash計算している
別メーカーはサーバ1台落ちるとそこだけ再計算する
・全計算は負荷分散の均一性が保てる
=>しかし関係ないユーザセッションまで影響でる
・部分的はユーザー影響最低限である
=>しかし負荷が偏りやすい
・LINEでは部分再計算方式のLBを購入した
・今のところ大きな問題は発生していない
・しかし運用時に特定サーバに不可が集中する
・アプライアンスの問題点としてLBの仕様が開示されない
個人的に気になったところ
・MySQL-MMM採用時にMySQL-Clusterは候補だったのか
・基本はInnoDBを採用していると思うが別エンジンの使用ケース
・MariaDBへの切り替え予定はあるのか
懇親会で聞けたこと
・サーバは購入している、Facebookのような自作は今のところしていない