LINEサービスのネットワークインフラ取り組み事例紹介【LINE Developer Conference@インフラ回レポート】
LINE Developer Conference@インフラ回に参加してきたのでその時のレポートを3回に分けて報告致します。
第3回はDBのLINEサービスのネットワークインフラ取り組み事例についてのお話。
ネットワーク知識はちょっと難しくて理解があんまり出来てないところもあるかも…
Session3. LINEサービスのネットワークインフラ取り組み事例紹介
以下の様な取り組み事例を説明してくれました。
- ユーザ数増加への対応
- DCスペースへの対応
- WorldWide展開への対応
- スマートフォンでのメッセージングアプリとしての対応
ユーザ数増加への対応
DC内部ネットワークの課題
トラフィック、サーバ数の増加とともに、DC内部でのサーバ間通信が多くなってきているそうです。
Unknown Unicast Flooding
同一VLANにいるMac Address Tableが全てフラッシュされて膨大な内部トラフィックが発生して1Gbpsを超えパケットドロップしてしまう問題
ネットワーク構成
一般的なDCネットワーク構成はCore→集線スイッチ→Edge Switchの3層構造になっている。
その構造でL2のドメインをどこで切るかで対応する。
例えばEdge Switch単位でやったり、POD(データセンター コンポーネントのモジュール単位)単位でやったり、DC全体でやったりなどなど。
問題があった時のLINEのDCネットワーク構成というと、
L2ドメインはPOD単位でL2領域を切っていたため、POD内の数千台に影響が出てしまった
対策：ネットワーク不安定要素を減らしつつ、サーバ配置の自由度を高める
問題解決のため以下の対策を講じたようです。
- Edge Switch単位でL2ドメイン構成
- Internet向け通信とPOD間通信の分離
- POD専用通信Switchの設置
- ロードバランサをL3DSR(DSCP)で構成してサーバがどこのPODにもおけるように設置の自由度を確保
ちなみに1PODあたり160Gbps出るそうです。
たしかにわけないと大変ですね。
LBの構成
LBの構成としてはIn-LineとDSRの2通り説明しており、そのDSRの中でL3DSRのDSCP方式をLINEは選択しました。
一応受け売りですがさらっと解説。
In-Line
入ってくるトラフィックと出るトラフィックがLBを経由するよくある構成。
入ってくるものより出て行くトラフィックが大きくなってキャパオーバするので却下したそうです。
DSR
In-Lineに対してDSRは戻りのトラフィックはLBを経由しないのでLBのキャパシティを限界まで使える
L2DSR
LBとサーバは必ず同じL2ネットワークにいないといけない。
自由度がなくなるのでこれは却下。
L3DSR
必ずしもLBとサーバをL2ネットワークに置く必要がない。<-これだ！！
L3DSR Tunnel方式
LBとサーバでTunnelを貼ってあたかもサーバとLBを同じL2ネットワークに入れるように見せる。
ethnetのMTUを1500bytes超えないように調整しないといけないので却下したそうです。
L3DSR DSCP方式
LBからServerに例えばDSCP=10というパケットが届く。受け取ったらSource IPを変えてクライアントに返す。
LINEは最終的にこれを選択。
DCスペースへの対応
DC選択基準としては高効率・高密度センターかつ実行8kVA以上/ラックを基準にしたそうです。
DC運用課題
高密度なDCはコストが高いので費用が高くなってしまうためどうすれば高スペックなIDCを使いこなせるかを考えました。
その結果でた答えが・・・
サーバを積めれるだけ詰める
至極当たり前な答えだがLINEはどうしたかというと
- 特注で作った51Uラック(！)を採用
- 定格24kVA、100口の電源を搭載
- 1Uサーバを40台近く載せている
糞でかいラックに大量に搭載されたサーバの画像とともに( ･´ｰ･｀)どやるスタッフ
いや、さすがLINEさんです。
高密度センターの制約
高密度DCは空調効率を高めるために制約が多い。
エアフローのためかならず前から吸って後ろから吐く機器を選定しないといけないらしいです。
問題はスイッチで、通常スイッチは前面にネットワークインターフェースがあるのでラック前に配線してしまうと配線がしにくくなってしまう。
しかし、ラック後ろに設置すると熱がやばいらしい(ラック内温度50度以上！あじー！)
そこでスイッチは後ろに設置しつつ、サーバの排熱を防ぐためにLINEがとった対策は、、
スイッチ用のダクトを自作し、前から冷気を吸い取り、後ろの排熱を防ぐようにした。
ちなみに1Uスイッチが最大3台入る代物。
LINEはなんでも作っちゃいますね。
WorldWide展開への対応
LINEは海外でも利用されていますが海外環境は品質がよくない。
そのため海外利用者の品質確保のため拠点を構築しています。
ポイントと解決に向けて
品質低下ポイントとしてはキャリアの相互接続ポイントと物理的な距離が問題としてあります。
キャリアの接続ポイントを通れば通るほどその分スループットが落ちてしまいます。
また、距離も同じように長いと時間がかかってしまいます。
解決に向けて以下の方向性を考えました。
- Local ISPと直接的なパスを持つ
- 利用者に近いところにサーバーを配置
- 利用者が一番近いサイトに接続
- LINE IDCを専用線で結び、利用者に近いところのLOCAL ISPと接続するようにする
物理ネットワーク
LINEは世界の以下の主要な地域に拠点を置いてます。
- Europe Africa Region
- Main Site & Japan Region
- South East/ South Asia/Pacific Region
- North/South America Region
バックボーンはリングトポロジーで構築して、世界をぐるっと一周してます。
論理ネットワーク
トポロジーにとらわれないネットワークを構成しているそうです。
それを実現するためにバックボーンを動かすプロトコルとしてMPLSでPseudo Wireを構築し、好きなネットワーク(仮想的な専用線)をいくつでも作れるようにしています。
そうすることでバックボーンの上で作るネットワークは ルーティング感に関与しなくなります。
論理ネットワーク上で実現したいこと
やりたいこととしては以下があったみたいです。
- インターネット通信を利用者に近いところで収容してLINE専用線で通信させる
- 海外のIDCにサーバをおいてサーバ間で拠点間通信をするための専用線が必要。
そこでPseudoWireを用いることでサービスネットワークと内部ネットワーク、2つのネットワークを別々に構築しているそうです。
拠点の選択について
一番近い拠点を判別するには実はクライアント側にその機能が実装されてます。
登録に用いるキャリア情報、登録電話番号、GeoIP情報を元にユーザが接続するMapping情報をもとにStaticに割り当てているそうです。
これは結構いい感じに動作しているらしいですが、拠点が落ちた時やユーザが移動した時に対応できないのでGSLBも別途検討しているそうです。
スマートフォンでのメッセージングアプリとしての対応
LINEはスマートフォンに特化したメッセンジャーとしてッセージのやり取りや通知などのリアルタイム性を重視しています。
リアルタイム性のための常時TCPセッション
LINEではリアルタイム性を実現するため、なんとTCPセッションを張り続けています。(電池無くなりそうー)
(ちなみに、AndroidはLINE独自の通知システム利用しているらしいです。)
TCPセッション張りっぱなしなので深夜でもセッション数が落ちないです。
参考までに出されたグラフでは最大1800万セッションくらい張っていました。
膨大なセッション数処理の課題の解決法
LBのセッション数がボトルネックで、セッションテーブルが溢れて障害になることもあったそうです。
解決策としていくつか考えられました。
- 機器を増やして負荷分散
- VIPでセッションを管理するコストが高くなる
- より高スペックなLBに交換
- 機器自体の値段が高くなってしまう
- いずれ限界がくる
- LBでセッションを管理しない構成
- これだ！！！
桐島、LBでのセッション管理やめるってよ。
stateless SLB
ではどうやって管理するか？
その解決策がstateless SLBである。
これはセッションテーブルではなくハッシュテーブルを利用してロード・バランシングする方式で、
通常1千万のクライアントが来た場合、TCPは同じSrcIP/DestIPじゃないといけないのでテーブルエントリ数が1千万必要になるが、
ハッシュテーブルの場合はハッシュキーがAだったらServer1みたいなテーブルを持つため、クライアント数!=セッション数になる。
再計算の問題
stateless SLBの問題はハッシュテーブルを再計算するタイミングにある。
例えば、サーバ1が落ちた場合、再計算しないとサーバ1にバランシングされ続けてしまう。
これはメーカによって計算方法が違うらしい。
ハッシュテーブル全体再計算の特徴
サーバ1台が死んだあとに計算した場合、サーバ1台はなかったことになって計算されるため残りの台数に対するハッシュテーブルになる。
それにより均一性が保証される。
しかし、サーバ2に接続しに行ってしまったひとが再計算後はサーバ3にいってしまったりする。
ハッシュテーブル部分再計算の特徴
部分的な計算なので影響を受けるユーザが一部で済む。
しかし、問題点として負荷が均一じゃなくなる問題がある。
どういうことかというと、例えばサーバ1が落ちた場合に部分再計算後はサーバ1にいってた人はサーバ2に、サーバ2の人はサーバ2へとなったりする。
LINEの選択
結局LINEはどれを選んだかというと、部分再計算を選びました。
負荷がかたよる問題については運用で考慮しながらカバーしているそうです。
アプライアンス製品を使う場合は仕様をよく調査して、挙動を理解した上で運用に載せる必要がある。
…ただ、LBの仕様の非開示もあったりするので調査も大変そうです。
個人的感想
ネットワーク知識弱いなぁと思いつつまとめてみました。
特注ラックやら、TCPセッションはりっぱなしというのはすごいなと思いました。
特注ラックの画像がすごくてうちのスカスカ具合が悲しくなりました。。笑
懇親会だと、ネットワークのほうまでは残念ながら回る暇がありませんでしたので誰かがきっとまとめてくれてるでしょう。。
続きはLINEシステムの裏側を懇親会でいろいろ聞いてきた！【LINE Developer Conference@インフラ回レポート番外編】へ
