LINE Developer Conference(テーマ：インフラ)にいってきたメモ

昨日(2014/04/15)にLINE Developer Conferenceに参加してきました。

寝かすと、永久に書かない気がしたので、消化し切れてないけど、メモ書きだけ残しておきます。

• LINE Developer Conference 開催のお知らせ
  • http://line-hr.jp/archives/37147547.html

今まで、LINEのインフラ回りがどうなっているのかってあまり情報を見たことなかったので、興味深く聞けて面白かったです。
普段関わっているサービスとは全然規模が違い、世界展開するサービスならではの話などとても面白かったです。ネットワーク回りで、昔ちょろっと触っていたMPLSの単語が出てきて懐かしかった。

いろいろ話を聞いていて、LINE社は面白そうな技術を使っていてるので、こういう会社で働けるとすごい楽しそうですね。

こういう機会がまたあったら是非参加したいです。運営の方々ありがとうございました。お疲れ様でした。

line developer conferenceメモ

• 本日はスライド撮影禁止
  • メモ内容はいくらでも公開して良いよ

• 今日はITサービスセンターの話

• 150/460
  • 何の数字だっけこれ?

• 現在開発2トップ体制

CTO パクイビンさん

• 100å„„ message/ day
• global展開
• 各地にLINE遠征隊を配置

サービス開発担当 いけべさん

• ITサービスセンター の職掌範囲
  • IT インフラ
  • IT セキュリティー

• サービス開発を支援 下記の4分野をサポート
  • system
  • database
  • network
  • sedurity

session 1 LINEサービスのシステム運営 佐野さん

• 2000/9入社
• システム運営チーム マネージャー

• 開発者 <=> SYSTEM <=> パートナー企業
  • この間をつなぐお仕事

• LINEの2å¹´é–“
  • サーバー、サービス増加
  • メンバーは増えてないが、なんとか回ってる

• plug and install (自動インストール)がLINE前からあったので省力化はできていた
  • ALIS
  • WDS

• LAN CABLEをつないで電源入れるだけでサーバ構築できる

• アジェンダ
  • 1.IDC内のConnection Timeout
  • 2.IDC空間の不足
  • 3.運営イシュー

1. IDC内のConnection Timeout

• Internetではtimeoutを意識した設計が必要
  • ひるがえって、IDC内部は?

• L2スイッチののトラフィック
  • 700Mbps
  • 704discard/sec !
  • キャパシティに余裕があるのにdscardしてた
  • short burst trafficが原因

• L2スイッチポートでバッファオーバーフロー
• 連続したTrafficは問題ない
  • => burst trafficを発生させない設計が必要

• これはmessagingサービスではよくある
  • 何かイベント(地震とか、ワールドカップのゴール時とか)
  • official account の同時メッセージ発信

• 解決策
  • => buffer の大きいスイッチを入れる
  • => burstがあるサービスはネットワーク隔離

• 解決まで1年費やした

2. IDC空間の不足

• サーバは私も知らない間にIDC空間を食いつぶしていった
• サーバを設置する空間が無くて苦しかった

• 2つの対策
  • 性能ボトルネックのあるサーバのスケールアップ
  • 仮想化

LINEサーバの中で一番多いクラスターサーバは HBase

• HBaseの特徴
  • scaleする
  • fail over
  • data copy(冗長化)

• 1000台の壁
  • スケールアウトしても思ったより性能が出ない
  • 台数増による
    • 故障率増
    • 運用コスト増

• そこで=>Scaleupして台数減らしてみる
  • CPU Discは問題ない
  • IOがボトルネック

• ふたつのIO指標
  • IOPS
  • Functional IOPS (RAID)

• PCIE SSDが圧倒的に早い
  • SASサーバ2台買うよりPCIE SSD1台買った方が割安

• が、今度はIOが解消するとCPUがつまるのでScale UPはここまで

仮想化

• 仮想化ミドルウェア
  • vmware vSphere <= LINEで使ってる
  • xen
  • kvm
  • hyper v

• 運用性(安定性)を絶対的な基準として選択した
• コストの問題もあるが今のところ使ってる

• 1物理 10VM

3.運営 イシュー

• 運営業務はずっと繰り返される
• その上での予想外のイシュー

• 2013年のバルス問題も無事に過ごした
• 2013年の地震のときも無事に過ごした
  • だいたいいつもの2倍のメッセージ数が流れる

• が、2014/1/1は無事では無かった
  • 前年度の参考に通常の数倍のトラフィックを予測
  • 予想通りの上昇
  • 全て想定通りに見えた

• が、突然メッセージ送信が不安定に
  • Redis Storageの一部のshardに負荷が集中
  • Redisと通信するサーバretryを繰り返す

• RedisとNICの割り込みが同じ奇数番のCPU Coreを使っている事を発見
• watch -n 1 "cat /proc/interruputs" で発見

• 高負荷時に起こる非常に不運な状況状況

• 応急処置
  • tasksetコマンドでRedisサーバのCPU Coreを偶数番号に
    • => 100% => 70 80へ

• 恒久処置
  • NICのInterruput handling listから外した

もうちょい詳しい説明あったはず。

session2 LINE DBシステムの高可用性について チェミギョンさん

• データベース運営チーム
• LINE Game

• アジェンダ
  • 1. lineサービス特徴
  • 2. 自動failover

1.lineサービスの特徴

• 400million user
• ユーザ増に備える必要
• 様々なLINEコンテンツ

• 使用DBの内MySQLが73%

• 容量算定の難しさ
  • ディズニーツムツムは当初予想の10倍

• 対策
  • SAS => SSDが圧倒的
  • メモリ追加
  • サーバ追加

• 仕事での悩み
  • 24時間障碍対応の必要

2. 自動FAILOVER

• Multi-Master Replication Manager というものを使っている
  • percona社開発
  • LINEではカスタマイズしている

• masterサーバにread/write用のvip
• slaveサーバにreadonlyのvipをつける
• MMM Managerがheartbeat監視

• 障碍時にmonitによってslaveのread_only(mysql variable)を解除しread/write vipを付与する

障碍時のシーケンスちょっと不明だったので、後で調べる

3. 無停止Shard 追加

• N-Base
• LINEが開発
• 無停止でShard追加削除する

• idにhashを通してgroup idを発行して、CG mapでshard idとgroup idをマッピングする
• 各shardに複数のグループが存在する

MMM Customize

• Muliti-Monitor
  • 普通は1台で1モニター 複数台モニターできるように

• 外部スクリプトをfailover時に実行できるように

• Replicationチェック機能削除
  • repli遅延やerrorでfailoverがよく発生してたのを解消

• 障碍判断
  • Select Now()の返値をみてた
  • Dummy Tableへupdate クエリを実行するように変更
    • Disc full, system error 時にもfail overできるように

N-baseに関してもう少し

• データコピー時の データ変更への対応はどうしている

• Sys_Ts順にデータをチャンクでコピーしてる
  • 更新しされればSys_Tsが更新されるので再度コピーされる

timestampみたいなカラム?

FAQ

LINE運営規模

• サーバ 5digits
• network 世界一周
• db 4digits

社風 慣習

• 諦めない
• チャレンジ
• 早い
• 変化は当たり前

外には出せないけど喋れるもの

• そんなものないけど。

• session担当は社員番号が若い
• ITSCのofficeはヒカリエじゃない
• 4億突破のおみやげがなかった
  • 3億ユーザ突破時はあった
  • 4億は通過点

目標

• 5億ユーザ

sesion3 LINEサービスネットワークインフラ取り組み事例

• 1.ユーザ数増加
• 2.ワールドワイド
• 3.スマートフォン/メッセージングアプリ

1.ユーザ数増加

• 4月に4億人

• トラフィック増加
• サーバの増加

• 課題
  • データセンター内部ネットワーク
    • サーバ間通信
    • ネットワークが不安定
  • データセンタースペース
    • サーバ台数増
    • どう運用するかが課題

• unknown unicast flooding問題
  • 同じVLAN内でmac address tableがflushされる
    • そのとき1Gbps長のトラフィックが流れる

• 一般的なデータセンター
  • L2ドメインをどこまでにするか
    • エッジスイッチ単位で
    • 集線スイッチ単位で(LINEでは個の単位をPODと呼ぶらしい)

• 問題発生時はPOD単位でL2ドメインを斬っていた

• 改善策
  • ネットワーク不安定要素を減らしたい。サーバ配置の自由度を高めたい

• L2ドメインはエッジスイッチ単位
  • Internet向け通信とPod間通信の分離
    • 1podあたり 160Gbps
  • ロードバランサーをL3DSRで構成
    • サーバをどこに置いてもOK

• よくあるLBの構成
  • In-Line
    • 戻りのトラフィックがLBを経由する
  • L2DSR
    • 同じネットワークの億必要がある
  • L3DSR Tunnel方式
    • IPカプセル化 => パケットサイズ(MTU)を考えないといけない
  • L3DSR DSVP形式 <== これを使ってる
    • DSCPフィールドを利用する

データセンター

• 選定基準
  • 高効率/高密度センター
    • 1ラックあたりの収容台数が多い 費用面
    • 実行8kVA以上/ラック

• 運用課題
  • どうすれば高スペック名IDCを使いこなせるか

• 51Uラックを採用
  • あまりうられていないので特注
• 定格24kVA、100口の電源を搭載

• 制約
  • 空調効率を高めるための制約が多い
    • エアフロー
    • 前吸気 後排気

• 問題はスイッチ
  • 前面にインターフェース
  • ラックの背面にマウントしたら ダメ
    • スイッチに熱気が伝わったから?

• スイッチに熱が伝わらないようにしないと
  • スイッチダクトを独自に作った

2.ワールドワイド

• 海外でも利用されている
• 海外利用の品質確保のために拠点を構築

• 品質低下ポイント
  • キャリアの相互接続ポイント
  • 物理的な距離

• 解決の方向性
  • local ISPと直接的なパスを持つ
  • 利用者に近いところにサーバを配置
  • 利用者が一番近いサイトに接続す仕組み(アプリ側)

グローバルインフラ

• 物理ネットワーク
  • 国際専用線は高いので(必要な線だけ引くといういみだと理解した)
  • 世界主要な地域に拠点を置く
  • バックボーンをリングトポロジーにする

• 論理ネットワーク
  • トポロジーにとらわれないネットワークを構成
  • MPLSでPseudo Wireを構築
    • バックボーン側ではルーティングを管理したくない

• 論理ネットワークで実現したい事
  • インターネット通信で利用者に近いところで収容
  • 拠点間通信

• 2つのネットワークを別々に構築
  • これにより運用がシンプル

• サイトの選択
  • クライアント側に機能を実装
  • いろいろな情報を参考にstatic に割り当て
    • キャリア情報
    • 登録電話番号
    • GeoIP

• マッピング情報をクライアントがダウンロードする
  • 時間帯で変化したりしたり、障碍時に問題があったり
    • GSLBも検討中

3. スマートフォン メッセージングアプリ

• リアルタイム制重視
  • メッセージのやりとり
  • 通知

• TCPセッションを張り続ける
  • AndroidはLINE独自の通知システムを利用
  • 深夜でもセッション数が落ちない
    • 膨大なセッション数
    • 某所で1800万セッション

• LBのセッションがボトルネックに
  • セッションテーブルのエージング時間調整

• 解決策
  • 機器を増やして負荷分散
    • 運用の負荷が高い
  • より高スペックのものに
    • もともと高価なものなので現実的じゃ無かった
  • LBでセッション管理しない構成に <== この方向性へ

• stateless SLB
  • セッションテーブルでなくハッシュテーブルを利用
  • セッションテーブルだとオーバフローしうる

• セッションテーブル 1対1
  • 1000万のsrc ipなら1000万のテーブルが必要
• ハッシュテーブル サーバに対応出来るだけのハッシュテーブルがあれば良い

• ハッシュテーブルの再計算問題
• 障碍時
  • ハッシュテーブル全体が再計算される 実装
    • 負荷分散の均一性 +
    • 関係ないユーザが影響受ける -
  • 落ちたハッシュだけ再計算される実装 <== ユーザへの影響を最小限にしたいと考え採用
    • 影響受けるユーザが最小限 +
    • 負荷の偏りが発生しやすい -

• 一長一短

今のところ大きな問題は無い

• 各LBの特性を理解しつつ運用する必要がある
  • 動作仕様の開示をメーカーがあまりしてくれない
• ハッシュテーブルはセッション数に対してスケールする

• 将来?
  • そんなに難しい事してないのでOpenFlowとか?