LINE Developer Conference (インフラ)

LINE Developer Conferenceに行ってきた。

テーマはインフラ。

以下備忘録。

#1.サーバ
[インフラエンジニアの教科書](http://www.amazon.co.jp/%E3%82%A4%E3%83%B3%E3%83%95%E3%83%A9%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E6%95%99%E7%A7%91%E6%9B%B8-%E4%BD%90%E9%87%8E-%E8%A3%95/dp/4863541333)の作者でもある佐野 裕さんが発表
事前アナウンスでは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の仕様が開示されない

![alt](https://qiita-image-store.s3.amazonaws.com/0/23539/96c49f78-599b-cbb2-f2b7-1e9c21d59aab.jpeg)

###個人的に気になったところ
・MySQL-MMM採用時にMySQL-Clusterは候補だったのか
・基本はInnoDBを採用していると思うが別エンジンの使用ケース
・MariaDBへの切り替え予定はあるのか

###懇親会で聞けたこと
・サーバは購入している、Facebookのような自作は今のところしていない