昨日(2014/04/15)にLINE Developer Conferenceに参加してきました。
寝かすと、永久に書かない気がしたので、消化し切れてないけど、メモ書きだけ残しておきます。
- LINE Developer Conference 開催のお知らせ
今まで、LINEのインフラ回りがどうなっているのかってあまり情報を見たことなかったので、興味深く聞けて面白かったです。
普段関わっているサービスとは全然規模が違い、世界展開するサービスならではの話などとても面白かったです。ネットワーク回りで、昔ちょろっと触っていたMPLSの単語が出てきて懐かしかった。
いろいろ話を聞いていて、LINE社は面白そうな技術を使っていてるので、こういう会社で働けるとすごい楽しそうですね。
こういう機会がまたあったら是非参加したいです。運営の方々ありがとうございました。お疲れ様でした。
line developer conferenceメモ
- 本日はスライド撮影禁止
- メモ内容はいくらでも公開して良いよ
- 今日はITサービスセンターの話
- 150/460
- 何の数字だっけこれ?
- 現在開発2トップ体制
CTO パクイビンさん
- 100億 message/ day
- global展開
- 各地にLINE遠征隊を配置
サービス開発担当 いけべさん
- サービス開発を支援 下記の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
- Internetではtimeoutを意識した設計が必要
- ひるがえって、IDC内部は?
- L2スイッチののトラフィック
- 700Mbps
- 704discard/sec !
- キャパシティに余裕があるのにdscardしてた
- short burst trafficが原因
- L2スイッチポートでバッファオーバーフロー
- 連続したTrafficは問題ない
- => burst trafficを発生させない設計が必要
- 解決策
- => 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)
- が、今度はIOが解消するとCPUがつまるのでScale UPはここまで
3.運営 イシュー
- 運営業務はずっと繰り返される
- その上での予想外のイシュー
- が、2014/1/1は無事では無かった
- 前年度の参考に通常の数倍のトラフィックを予測
- 予想通りの上昇
- 全て想定通りに見えた
- が、突然メッセージ送信が不安定に
- Redis Storageの一部のshardに負荷が集中
- Redisと通信するサーバretryを繰り返す
- 高負荷時に起こる非常に不運な状況状況
- 応急処置
- 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倍
- 仕事での悩み
- 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億人
- トラフィック増加
- サーバの増加
- 課題
- データセンター内部ネットワーク
- サーバ間通信
- ネットワークが不安定
- データセンタースペース
- サーバ台数増
- どう運用するかが課題
- 一般的なデータセンター
- L2ドメインをどこまでにするか
- エッジスイッチ単位で
- 集線スイッチ単位で(LINEでは個の単位をPODと呼ぶらしい)
- 問題発生時はPOD単位でL2ドメインを斬っていた
- 改善策
- ネットワーク不安定要素を減らしたい。サーバ配置の自由度を高めたい
データセンター
- 選定基準
- 高効率/高密度センター
- 1ラックあたりの収容台数が多い 費用面
- 実行8kVA以上/ラック
- 運用課題
- どうすれば高スペック名IDCを使いこなせるか
- 51Uラックを採用
- あまりうられていないので特注
- 定格24kVA、100口の電源を搭載
- 制約
- 空調効率を高めるための制約が多い
- エアフロー
- 前吸気 後排気
- 問題はスイッチ
- 前面にインターフェース
- ラックの背面にマウントしたら ダメ
- スイッチに熱気が伝わったから?
- スイッチに熱が伝わらないようにしないと
- スイッチダクトを独自に作った
2.ワールドワイド
- 海外でも利用されている
- 海外利用の品質確保のために拠点を構築
- 品質低下ポイント
- キャリアの相互接続ポイント
- 物理的な距離
- 解決の方向性
- local ISPと直接的なパスを持つ
- 利用者に近いところにサーバを配置
- 利用者が一番近いサイトに接続す仕組み(アプリ側)
グローバルインフラ
- 論理ネットワークで実現したい事
- インターネット通信で利用者に近いところで収容
- 拠点間通信
- 2つのネットワークを別々に構築
- これにより運用がシンプル
- サイトの選択
- クライアント側に機能を実装
- いろいろな情報を参考にstatic に割り当て
- キャリア情報
- 登録電話番号
- GeoIP
- マッピング情報をクライアントがダウンロードする
- 時間帯で変化したりしたり、障碍時に問題があったり
- GSLBも検討中
3. スマートフォン メッセージングアプリ
- リアルタイム制重視
- メッセージのやりとり
- 通知
- 解決策
- 機器を増やして負荷分散
- 運用の負荷が高い
- より高スペックのものに
- もともと高価なものなので現実的じゃ無かった
- LBでセッション管理しない構成に <== この方向性へ
- stateless SLB
- セッションテーブルでなくハッシュテーブルを利用
- セッションテーブルだとオーバフローしうる
- セッションテーブル 1対1
- 1000万のsrc ipなら1000万のテーブルが必要
- ハッシュテーブル サーバに対応出来るだけのハッシュテーブルがあれば良い
- ハッシュテーブルの再計算問題
- 障碍時
- ハッシュテーブル全体が再計算される 実装
- 負荷分散の均一性 +
- 関係ないユーザが影響受ける -
- 落ちたハッシュだけ再計算される実装 <== ユーザへの影響を最小限にしたいと考え採用
- 影響受けるユーザが最小限 +
- 負荷の偏りが発生しやすい -
- 一長一短
今のところ大きな問題は無い
- 各LBの特性を理解しつつ運用する必要がある
- 動作仕様の開示をメーカーがあまりしてくれない
- ハッシュテーブルはセッション数に対してスケールする
- 将来?
- そんなに難しい事してないのでOpenFlowとか?
