LINEサービスのシステム運営【LINE Developer Conference@インフラ回レポート】
LINE Developer Conference@インフラ回に参加してきたのでその時のレポートを3回に分けて報告致します。
第1回はシステム運営についてのお話。
Session1. LINEサービスのシステム運営
LINE SYSTEM OPERATION
LINEはこの2年間でUser/Messagesは増加し、Server台数も増え、サービスも増えました。
しかし、メンバーは増えていません。
でもなんとか処理しきれています。
なぜまわるのか？
それはPlug and Installのコンセプトのもと以下のものがあるおかげ。
- ALIS (Auto Linux Install System) by kickstart
- WDS (Windows Distribution System)
どちらもLINEお手製のシステムで、LAN Cableをつないで電源を投入するだけでサーバの構築が行えるプロセスと技術がすでにあったようです。
しかし問題もあったようで今回は以下の問題と対策について語ってくれました。
- IDC(インターネットデータセンター)内部でのConnection Timeout
- IDC空間の不足
- 運営イシュー
IDC内部でのConnectionTimeout
一般的にInternet環境では回線品質保証が難しいのでConnection Timeoutを十分考慮したClient/Applicationの設計をしています。
問題概要
IDC内部ではL2スイッチは1Gbpsを使っていた。
トラフィック量は瞬間でMax700Mbps出ていることもあり、まだ余裕があるようにみえたが、704discard/secものフレームやパケットの破棄が起こっていた。
(通常のTrafficは連続してトラフィック量が流れ、discardは0の状態)
結論としてShort Burst Trafficが起こっていた。
L2Switch PortでBufferOverflowすることでDiscardが大量に発生。
あまりに短期間にパケットが入ってくるとパケットをすててしまう。
ちなみにこれはMessageServiceではよくある現象で、例えば人々は歓呼の声を上げる時、一緒にあげたりするときにおきる。(バルス！)
また、Official Accountなどは数十万人に同時にメッセージを送ったりするときにも発生します。
対策
対策としては以下を講じたそうです。
- Bufferが大きいL2Switchに交換
- Burst Traffic制御が難しいサーバについては独立したNetwork空間を作って分離した
IDC空間の不足
悩みの種としてサーバを設置する空間がなくて苦しくてとにかく大きな施設が欲しかったらしいです。
でもそういうわけにも行かないので以下の対策を講じたようです。
- 性能Bottle neckがあるサーバのScaleUP
- 仮想化進行
性能Bottle neckがあるサーバのScaleUP
LINEサーバ中いちばん台数が多いクラスタグループはHBASE。
Apacheグループが提供するHbaseには以下の特徴があります。
- Scalability architecture(= Scale outが有効)
- fail overがよくきく
- 複数 data copy(3copy以上だと安心)
しかしこんな問題も。
- HBASE Cluster 1000台の壁(経験則)
- 思ったより性能が出ない
- サーバ故障数増加
- 運営コスト上昇
そこで、Scale Upして台数を減らすことに。
ScaleUpするにあたっていろいろ調査をしたところCPU, Memory, disk使用量は問題なかったがDiskIO(IOPS)が問題になったようです。
PCIE-SSID最強
RAID0で6本並べてHDDやSSD、PCIE-SSDなどで比較調査してみたところ、IOPSはPCIE-SSD(FusionIOなどのあれ)だと飛び抜けて20万出ていました。
spec的には圧倒的なPCIE-SSD。
TCO分析結果ではSASサーバ2台をPCIE-SSDサーバ1台に移行するよりも割安だったらしいです。
また、Storage容量を増やすと今度はCPUがボトルネックになった模様
仮想化
IDC空間が足りない時に一番先に考えることは仮想化。
LINEではVMWare vShereをよく使っているらしいです。
仮想化では物理サーバ1台の運用がより重要となる。
運営サーバ数は同じか増え続けるので、運用性を絶対的な基準としてVMwareを選択したようです。
現在数千台のGuestOSが1/10の集約度でHypervisor上でサービスされています。
運営イシュー
2013年
バルス問題も無事にこなしました。
何回か地震もあり、トラフィックが通常時の2倍ありましたが、無事にこなしました。
しかし2014/1/1は無事ではなかったようです。
問題概要
通常は前年度の事例を参考に通常の数倍のトラフィックを予測しており、2014年度も予想通り上昇し、全て想定通りで完璧に見えた。
が、しかし突然メッセージ送信が不安定に。
症状として
Redis Storageの一部Shardに負荷が集中
↓
負荷が集中したRedisがレスポンスをなかなか返さない
↓
Redisと通信するサーバーはretryを繰り返す
↓
大きなConnectionBurstが発生
となっていたようです。
問題発見方法
Redisがかろうじてrequestを処理している時、RedisとNIC割り込みが同じ奇数番のCPU Coreを使っていることをメンバーが発見！
ちなみに以下のコマンドで見つけたようです。
|
1 |
watch -n 1 "cat /proc/interrupts" |
原因と対策
拡張メッセージシグナル割り込み(MIS-X)が動作中にirqbalanceが割り込みを制御している状況で非常に不安な状況になっていた。
応急処置としては、tasksetコマンドでRedisサーバのCPU Coreを偶数番号に手動割当てすることでCPU Usageが100%から70-80%におちて解決。
根本原因解消としては、RedisサーバはIRQBALANCE_BANNED_INTERRUPTSにNICのIRQを追加することでNICをInterrupt handling listから外すことで解消したようです。
個人的感想
どんなサーバ構成でOSはこれこれ使ったりなどのことが知りたいなぁと思ってましたが、LINEならではの問題や解決法などがメインになっていました。
でもこれはこれで大量のトラフィックを捌くのに必要なノウハウとしておもしろかったです。
ちなみに一応OSなどは後の懇親会で聞いたりしたので懇親会編にでもまとめます。
追記ログ
2014/04/16 0:47 仮想化の集約率修正
