LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog

Blog


JANOG39登壇レポート「LINEのインフラを運用して見えてきた課題」

こんにちは。LINEでネットワークやデータセンターを担当している三枝です。2017年1月にJANOG39で登壇する機会を頂きましたので、今回はその内容をレポートしたいと思います。

テーマはLINEのインフラについてです。LINEのサービス開始から現在までインフラの課題とその対応についてお話しました。

サービス開始当初 2011.06 ~ (サーバー数百台規模)

LINEのサービスが開始した2011年6月当初は、既存のサービスが動いているインフラに同居する形で始まりました。ネットワークは典型的な3Layerの構成を採用していました。

North-SouthのTrafficが主だった従来のサービスと比べて、LINEのシステムは分散型アーキテクチャーを各所に採用しているため、East-West Trafficが多いのが特徴です。

そのため、サービス開始後間も無くしてAccess 〜 Aggregation Layer間の帯域幅が足りなくなり、増速を余儀なくされました。その際に全てのリンクをActiveに使えるMC-LAGと呼ばれる構成を採用しました。

急拡大期 2012~(サーバー数千台規模)

2011年末頃からユーザーが急拡大をする時期を迎え、様々な課題に直面することになりました。

データセンターネットワークの安定化

サーバーの物理的な位置に関係なくどんなネットワークでも使えるようにするためにvlan tagを用いて、どのToR Switchでもどんなvlanでも使えるように設計をしていました。

ToR Switchの増設・交換を行うとSTPのTopology ChangeのEventが走り、switch上のmac address tableがflushされます。このときEast-West Trafficの場合、違うサブネット宛ての通信であっても、unknown unicast floodingがAggregation Layerを超えて発生してしまい、影響範囲が大きくなります。さらにTrafficが多い環境になると物理帯域を埋め尽くすほどのfloodingが発生します。これが問題となり、vlanの設計の見直しを迫られました。

左側のpodのようなswitchをまたぐようなvlan構成から、原則として右側のpodのようにサーバーラック毎にvlanを1つ割り当てる方式に変更をしました。ひとつひとつのvlanを小さくすることでunknown unicast floodingの通信量を最小化するのが狙いです。

virtual machine用のvlanはlive migrationをするためにサーバーラックにまたがるvlanを引き続き許容していますが、virtual machine上で動かしているシステムはNorth-South Trafficが多いので問題なくスケールしています。

データセンターの効率利用

サーバーの規模も一気に増えたためデータセンターの増床を行いました。増床したセンターはrackあたり8.5kVAを実効で利用できる高密度なセンターです。

データセンターのスペックが上がっているので、1rackあたりの費用も上昇しましたが、kVAあたりの単価では従来のセンターより安価であることはシミュレーション上わかっていました。

そこで、どうすれば8.5kVAのスペックを使いこなすことができるのかという検討が始まりました。

使いこなすために実現したいことと対策を整理すると下記の表のようになります。

実現したいこと 要件 対策
1 1Uサーバー基準で45台設置 最低45U+ToR Switch2U分の空間 51Uサイズのサーバーラック
2 ToR Switch二重化 90本のUTPケーブルを無理なく配線 ラック背面に垂直型ケーブルマネージャー設置
3 電源二重化 90本(サーバー)+4本(ToR)分のラックPDUの口数 25口 x 4 = 100口(2系統)の電源
4 機器の適切な冷却 センターのairflow設計への準拠 ToR Switch airflow(後述)

1ラックにサーバーをたくさん詰めれば詰めるほど電力を使い切る公算が大きくなります。そのため1~3についての対策はすんなり決まりました。

一番悩んだのが4番のairflowになります。ToR Switchをラック前面に配置すればcold aisleの冷たい空気を吸気できるのでairflow上の問題は発生しませんが、サーバーへのネットワークケーブルの取り回しがしづらくなります。(上の図)

1ラックあたり90本の配線があるので、取り回しやすさは重要になります。ケーブル取り回し問題の解決のため、ToR Switchをラックの背面に設置したときにはSwitchがラック内の温かい空気を吸気してしまうので冷却に問題が出ます。(下の図)

そこで、ケーブルの取り回しと機器の冷却の両方の課題を解決するためにスイッチボックスと呼んでいる装置を開発しました。スイッチボックスはラック背面に設置されたToR Switchにcold aisleの冷たい空気を送り届ける役割をするものです。

スイッチボックス全貌(左) cold aisle側から見たスイッチボックス(右)

このスイッチボックスにより、機器の冷却とケーブルの取り回しやすさの両方を実現しています。

海外利用者のための品質確保

日本での利用者の伸びた時期と同様の時期に海外での利用者も増加し、新たな課題が生まれました。

海外だとどうしても物理的な距離があるので、ネットワークのスループットがどうしても落ちてしまいます。加えて、海外だと通信環境が日本ほどよくない事業者も多く、それも品質悪化の原因になっていました。

そこで従来のデータセンターをCore DCという位置づけとして考え、利用者の近くで通信を終端し、スループットの向上を目的としたRegional DCを世界の主要3拠点(アメリカ、ドイツ、シンガポール)に配置しました。

また、Regional DCとCore DC間のトラフィック量の削減のため、Regional DCへのキャッシュサーバーの配置も行っています。

利用者がどのRegional DCに接続するかの制御はモバイルネットワークコードを用いたstaticな制御とGSLBによるdynamicな制御のハイブリッド構成にしています。それにより平常時はLINEのアプリ・インフラ運用側が意図したサイトに接続をしてもらい、問題がある場合(たとえばLINE側のDCに障害が発生したなど)には自動で他のDCに迂回されるような仕組みを実現しています。

現在〜今後 (サーバー数万台規模)

利用者の増加やサービスの多角化により物理サーバー数の規模で数万台のインフラになりました。

データセンターネットワークのL2/L3の部分については、最近のネットワーク機器の広帯域化・高密度化がすすんでいるおかげでなんとか大きなアーキテクチャー変更もなくスケールできています。

今現在、一番大きな課題はロードバランサーです。LINEではL3DSRと呼ばれる仕組みでロードバランサーを構成しています。負荷分散対象サーバーのネットワーク的な位置に縛られず、サーバーからクライアントへ戻るトラフィックはロードバランサー経由しないので、スケーラビリティ上の恩恵がある構成です。

しかしながら、通常ロードバランサーはステートフルで動作しますので、クライアントへの戻りの通信がロードバランサーを経由しないDSR構成においては問題となるケースも存在します。

例えばsyn floodingのような攻撃を受けたときの動作を考えるとわかりやすいと思います。 ロードバランサーがsynパケットを受信するとその通信が正常なものか悪意のあるものなのかの判断はその時点ではできませんので、その通信に対応するセッション情報を作ってしまいます。セッション情報を保持できる数には上限がありますので、膨大な量のsyn packetを一度に受けるとDoS攻撃が成立するという弱点をはらんでいます。

さらに冗長構成を確保するために1+1のcluster構成を採用しています。実際に必要なキャパシティNに対して2N分のシステムキャパシティを確保しなければなりませんので、規模が大きくなると冗長構成分の負担が大きくなってしまうのも課題です。

この課題を解決するために左側の絵のような2Nでステートフルな構成から右側の絵のようにN+1でステートレスな構成へのアーキテクチャーの改善をすすめています。

anycastによるロードバランサーノードに対する負荷分散とconsistent hashingによるハッシュテーブルを用いたサーバー負荷分散の技術を用いてN+1とステートレスの構成を実現しています。

この新しいアーキテクチャーを持つロードバランサーは、2017年中にプロダクション環境での投入を目指して開発を進めています。

最後に

これまではLINEのインフラに関してJANOGのような社外イベントでお話するようなことはあまり実施していませんでしたが、これを機に今後はもっと積極的に参加しようと思っています。

特に最後にご紹介した新しいロードバランサーについては力を入れている分野のうちのひとつですので、アップデートを何らかのかたちで情報を発信していこうと考えていますのでご期待ください。