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のような自作は今のところしていない