LINE Developer Conference インフラの部の参加メモ
今更ですが「LINE Developer Conference」インフラの部に参加させて頂けたのでメモです。
http://line-hr.jp/archives/37147547.html
とても参考になる話が聞けてLINEさん大変ありがとうございました。
↓のようにもう既に奇麗に他の方が沢山書き留めていますので、もうひたすら個人的にメモっていたのを羅列するだけ。
http://masasuzu.hatenablog.jp/entry/2014/04/16/LINE_Developer_conference
http://dev.classmethod.jp/server-side/line-dev-conf-infra/
http://blog.mogmet.com/line-developer-conference-infra-introduce-network-case/
http://blog.mogmet.com/line-developer-conference-infra-db-high-availability/
思ったこと
L3DSR/statelessSLBあたりは今後のサービスインフラ考える上でとても参考になりました。
サービス運用におけるDBのDDL運用は…やっぱりまだ手間がかかるところかなという感じでした。
ただ、MySQLでもオンラインDDLができるようになっているので、今後Immutable Infrastructureに合わせてどう対応させて行くかが詰められて今後1,2年内には何かしら形になるんじゃないかという気もしています。
参考：http://dev.classmethod.jp/cloud/aws/jawsdays2014-08/
（ここを見ても、DBはまだどうやって対応させて行くかという感じかな？）
※付きは個人感
ITSCの紹介
範囲
データセンタ
ネットワーク
サーバ
DB
セキュリティ分野ではアプリケーションも含めた全体
サービスへの関わり方
企画・設計でキックオフ
開発・テストでインフラ設計、キャパ設計
リリース・運営は体制組んで対応
サービスインフラマネージャが表にたって対応
システム運営
開発 ー システム運営（ここ） ー パートナー企業（ISP/CDNなど）
２年振り返り
ユーザ、サービス、サーバ増え続けているがメンバーはあまり増えていない
自動インストール周りの整備がされているから（Plug and Installと呼んでいる）
問題
DC内のコネクションタイムアウト（アプリタイムアウト）
L２SWのパケドロ ※いつものキューオーバーフローのこと
アプリケーションで対象できればうれしいが…
メッセージサービスだとアプリケーション側で制御が難しい（一斉系）
結果、バッファの大きいSWに交換
NWを独立させてサーバを隔離
DC空調
サーバがつめなくなってきた
スケールアップ
VM集約
HBaseが一番台数が多い
経験則的に１０００台くらいで性能に壁がある感じ
ハード故障多くて運用コストがつらい
スケールアップで台数減らしをもくろむ
IOPS重視
Diskなら１５００くらいのIOPS
PCI-SSDで数万から１０万クラスに
Disk早くしたらCPUがネックになってきた
仮想化ハイパーバイザ
VMWareでやってる
運用性などでの都合
１サーバで１０VMくらいの集約度 ※48Gの24コアくらいか？
運営問題
地震などがあると２倍くらいのトラフィックがあるがなんとかさばけた
年末年始にRedisの一部に負荷集中
NIC割り込みとRedisの処理しているCPUコアが重複して遅延
tasksetでRedisプロセスが使うCPUを分散させて応急処置
irqbalanceの対象からNICを外して、NICは手動設定
LINE DBシステム
主にLINEゲーム系のお話
DBMS色々だけどMySQLが７３％くらいで最も多い、次がSQLServerで１７％くらい。ほかはほとんどない。
DBサーバ台数1000台くらい運用
容量算定について
同時接続が見込みから外れると大変だったという話
自動フェイルオーバ（Multi-Master Replication Manager）
MySQL+MMM 構成 MySQLはPerconaベースをカスタマイズ
Write用VIPとRead用VIPを振る
heatbeatでVIPの移動
フェイルオーバはMMMが指示
無停止シャード追加
MGMTという独自開発されたプロセスがシャードサーバ情報を提供 ※fabricの独自版のようなもの
シャーディング数が増える場合はどうするか
移行用マップが作られる
既存DBから担当シャードデータ移動のためにDB間でつないでデータとる
取り方はselect/insertのSQLベース
コピーが終わったらMGMTから新シャードDBを通知
MGMTはマネージャ・エージェントシステムでアプリサーバにエージェントが配置されており、アプリはエージェントに問い合わせてシャーディングマップを取得している
マネージャはPUSHでファイル配布＆エージェントメモリ展開
・シャード追加中のトランザクションはどうするか？
一番古いデータからselectして行く、そのための識別用タイムスタンプ列が存在する
複数回selectでのゲットをまわして事前同期を進めて、エイや！でシャード追加
・DDLの変更を伴う際にはどのように無停止対応をしているのか？
DDLを事前にもらってメンテ入れて適用パターンが多め
全部が全部必ずしも無停止ではない
MMMカスタマイズ点
・モニターサーバ１台で複数担当
・フェイルオーバ時に外部スクリプト呼び出し
・レプリケーション遅延でのフェイルオーバはしないようにした
・障害判断のSQLにダミーテーブルへの操作を追加
事前アンケートFAQ回答
LINEシステム規模
サーバは万、DBは千単位
ネットワークインフラの取り組み
課題
内部ネットワークトラフィック
データセンタスペース
ネットワーク
Unknown Unicast Flooding → MACアドレステーブルFLUSH → 通信不安定
これが1Gクラスで発生していた
前はPOD単位でL2
L2がSS単位
表と裏の分離、裏を160Gbps
LBをL3DSR化（Tunnel方式（トンネリングチャネルをサーバとバランサで張る）・DSCP方式（これを採用、DSCPヘッダを利用した制御方式）
データセンタ
高効率、高密度、実効8kVA以上
51Uラック 24kVA、100口の100V電源、特注
スイッチを背面設置、後は空調の問題
スイッチ専用の箱を特注して、サーバの熱がスイッチに影響しないようにした
海外利用向けには拠点を構築
海外はキャリアの相互接続ポイントが品質が落ちやすい
なるべくLocal ISPと直接パスを持つ
利用者に近いところにサーバを設置
利用者が一番近いところのサイトに接続
バックボーンはリングトポロジー（US 1、アジア3、EU1） コストと冗長性の妥協点
論理ネットワークはMPLSでPseudo wireを構築
論理ネットワークでやりたかったこと
インターネット通信を利用者に近いところで収容
クライアント側で機能を実装（得ている利用者情報からStaticに決まる）
GLSBも検討中
拠点間通信
MPLS上にサービス用、サーバ間通信用２つのネットワークを別々に構築
メッセージサービスとして
リアルタイム性重視
TCPセッションを張り続けるためセッション数があまり落ちない
LBセッションテーブルがあふれる
セッション管理どうする？
LB機器増やし、スペックアップ
LBでセッション管理しない構成
stateless SLB ハッシュテーブルを使ってバランスする形式
バランシング先サーバ増減時の挙動がメーカーによって違いがある
ハッシュテーブル全体再計算
負荷均等性は保証、サーバがかわってしまうので１回切断的な動き
部分再計算
負荷均等性はだめだが、既存セッションはOK、LINEはこっちを採用
stateless SBLまとめ
セッション数に対してはスケール
障害時の挙動の理解が必要
問題点
負荷の偏り
モニタリング
LB仕様をベンダーが開示してくれない
・配線で気をつけていること
電源ケーブルのあまりが出ないよう自作
NWケーブルは専用経路を通す感じなラックデザイン
以上
