LINE Developer Conference@インフラ回に参加してきたのでその時のレポートを3回に分けて報告致します。
第3回はDBのLINEサービスのネットワークインフラ取り組み事例についてのお話。
ネットワーク知識はちょっと難しくて理解があんまり出来てないところもあるかも…
以下の様な取り組み事例を説明してくれました。
DC内部ネットワークの課題
トラフィック、サーバ数の増加とともに、DC内部でのサーバ間通信が多くなってきているそうです。
同一VLANにいるMac Address Tableが全てフラッシュされて膨大な内部トラフィックが発生して1Gbpsを超えパケットドロップしてしまう問題
一般的なDCネットワーク構成はCore→集線スイッチ→Edge Switchの3層構造になっている。
その構造でL2のドメインをどこで切るかで対応する。
例えばEdge Switch単位でやったり、POD(データセンター コンポーネントのモジュール単位)単位でやったり、DC全体でやったりなどなど。
問題があった時のLINEのDCネットワーク構成というと、
L2ドメインはPOD単位でL2領域を切っていたため、POD内の数千台に影響が出てしまった
問題解決のため以下の対策を講じたようです。
ちなみに1PODあたり160Gbps出るそうです。
たしかにわけないと大変ですね。
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選択基準としては高効率・高密度センターかつ実行8kVA以上/ラックを基準にしたそうです。
高密度なDCはコストが高いので費用が高くなってしまうためどうすれば高スペックなIDCを使いこなせるかを考えました。
その結果でた答えが・・・
サーバを積めれるだけ詰める
至極当たり前な答えだがLINEはどうしたかというと
糞でかいラックに大量に搭載されたサーバの画像とともに( ･´ｰ･｀)どやるスタッフ
いや、さすがLINEさんです。
高密度DCは空調効率を高めるために制約が多い。
エアフローのためかならず前から吸って後ろから吐く機器を選定しないといけないらしいです。
問題はスイッチで、通常スイッチは前面にネットワークインターフェースがあるのでラック前に配線してしまうと配線がしにくくなってしまう。
しかし、ラック後ろに設置すると熱がやばいらしい(ラック内温度50度以上！あじー！)
そこでスイッチは後ろに設置しつつ、サーバの排熱を防ぐためにLINEがとった対策は、、
スイッチ用のダクトを自作し、前から冷気を吸い取り、後ろの排熱を防ぐようにした。
ちなみに1Uスイッチが最大3台入る代物。
LINEはなんでも作っちゃいますね。
LINEは海外でも利用されていますが海外環境は品質がよくない。
そのため海外利用者の品質確保のため拠点を構築しています。
品質低下ポイントとしてはキャリアの相互接続ポイントと物理的な距離が問題としてあります。
キャリアの接続ポイントを通れば通るほどその分スループットが落ちてしまいます。
また、距離も同じように長いと時間がかかってしまいます。
解決に向けて以下の方向性を考えました。
LINEは世界の以下の主要な地域に拠点を置いてます。
バックボーンはリングトポロジーで構築して、世界をぐるっと一周してます。
トポロジーにとらわれないネットワークを構成しているそうです。
それを実現するためにバックボーンを動かすプロトコルとしてMPLSでPseudo Wireを構築し、好きなネットワーク(仮想的な専用線)をいくつでも作れるようにしています。
そうすることでバックボーンの上で作るネットワークは ルーティング感に関与しなくなります。
やりたいこととしては以下があったみたいです。
そこでPseudoWireを用いることでサービスネットワークと内部ネットワーク、2つのネットワークを別々に構築しているそうです。
一番近い拠点を判別するには実はクライアント側にその機能が実装されてます。
登録に用いるキャリア情報、登録電話番号、GeoIP情報を元にユーザが接続するMapping情報をもとにStaticに割り当てているそうです。
これは結構いい感じに動作しているらしいですが、拠点が落ちた時やユーザが移動した時に対応できないのでGSLBも別途検討しているそうです。
LINEはスマートフォンに特化したメッセンジャーとしてッセージのやり取りや通知などのリアルタイム性を重視しています。
LINEではリアルタイム性を実現するため、なんとTCPセッションを張り続けています。(電池無くなりそうー)
(ちなみに、AndroidはLINE独自の通知システム利用しているらしいです。)
TCPセッション張りっぱなしなので深夜でもセッション数が落ちないです。
参考までに出されたグラフでは最大1800万セッションくらい張っていました。
LBのセッション数がボトルネックで、セッションテーブルが溢れて障害になることもあったそうです。
解決策としていくつか考えられました。
桐島、LBでのセッション管理やめるってよ。
ではどうやって管理するか？
その解決策がstateless SLBである。
これはセッションテーブルではなくハッシュテーブルを利用してロード・バランシングする方式で、
通常1千万のクライアントが来た場合、TCPは同じSrcIP/DestIPじゃないといけないのでテーブルエントリ数が1千万必要になるが、
ハッシュテーブルの場合はハッシュキーがAだったらServer1みたいなテーブルを持つため、クライアント数!=セッション数になる。
stateless SLBの問題はハッシュテーブルを再計算するタイミングにある。
例えば、サーバ1が落ちた場合、再計算しないとサーバ1にバランシングされ続けてしまう。
これはメーカによって計算方法が違うらしい。
サーバ1台が死んだあとに計算した場合、サーバ1台はなかったことになって計算されるため残りの台数に対するハッシュテーブルになる。
それにより均一性が保証される。
しかし、サーバ2に接続しに行ってしまったひとが再計算後はサーバ3にいってしまったりする。
部分的な計算なので影響を受けるユーザが一部で済む。
しかし、問題点として負荷が均一じゃなくなる問題がある。
どういうことかというと、例えばサーバ1が落ちた場合に部分再計算後はサーバ1にいってた人はサーバ2に、サーバ2の人はサーバ2へとなったりする。
結局LINEはどれを選んだかというと、部分再計算を選びました。
負荷がかたよる問題については運用で考慮しながらカバーしているそうです。
アプライアンス製品を使う場合は仕様をよく調査して、挙動を理解した上で運用に載せる必要がある。
…ただ、LBの仕様の非開示もあったりするので調査も大変そうです。
ネットワーク知識弱いなぁと思いつつまとめてみました。
特注ラックやら、TCPセッションはりっぱなしというのはすごいなと思いました。
特注ラックの画像がすごくてうちのスカスカ具合が悲しくなりました。。笑
懇親会だと、ネットワークのほうまでは残念ながら回る暇がありませんでしたので誰かがきっとまとめてくれてるでしょう。。
続きはLINEシステムの裏側を懇親会でいろいろ聞いてきた！【LINE Developer Conference@インフラ回レポート番外編】へ
こんにちは。virapture…
View Comments
Thank you very much for sharing, I learned a lot from your article. Very cool. Thanks. nimabi