急増するLINEインフラの課題と対応

こんにちは。今回はITサービスセンターより、インフラ運営の観点から急増するLINEインフラの課題と対応について記させていただきます。

はじめに

先日開催したLINE Developer Conference（インフラ編）には大勢の方にいらしていただきました。カンファレンスでは、LINEサービスが始まってから約2年の間に我々はどういった方法でインフラ運営を行い、またどんなことに悩んできたのかを、システム、データベース、ネットワークの観点からそれぞれ発表させていただきました。

カンファレンスはLINE株式会社が様々な技術をどのように使い、どのように運用を行っているのか。現在どのような技術的なことに取り組んでいるのか日本のエンジニアの皆さんに知っていただくために開催されました。結果としてインフラ編では150名の定員に対して430名のご応募をいただいたとのことでLINEサービスに対する関心の高さを感じ、当日発表させていただいた3名は身が締まる思いがしました。

各セッションの後、懇親会が行われ、大勢のエンジニアの方々からLINEインフラ運営について様々なご質問をいただきました。やはりLINEサービスにおける大規模なグローバルサービスをどのように運営しているかといったことに関心の高さを感じました。

さて、以下は先日発表させていただいたLINE Developer Conference（インフラ編）の内容を再構成して、インフラ運営の観点から急増するLINEインフラの課題と対応をご紹介させていただきます。ここでは急激に増え続けるLINEユーザーに対応するために、インフラ部門では日々様々な対策や障害対応を行っています。ここでは3つの事例をご紹介いたします。

データセンターの有効活用

増え続けるユーザー数に対応したペースでサーバー台数が増えていく状況に対応するためデータセンタースペースの確保とその有効活用が課題となっていました。

1. データセンタースペースの有効活用
   LINEでは都心のデータセンターを利用しています。都心のデータセンターは土地代・人件費の高さからラック1本あたりで換算した場合の費用が地方のセンターよりは高くなってしまいます。
   そこでラック1本あたりで使える電力の大きいセンターを選び、同じスペースでもより多くのサーバーを設置できる構造を目指しました。
   具体的には今使っているセンターの場合、実効で1ラックあたり8.5kVA程使用できます。これは既存のセンターと比べ1ラックあたり使える電力が2倍以上になっています。
   単純に計算しても既存のセンターの半分以下のスペースで同じサーバー台数を収容できるため、都心センター特有の高いスペース費用の節減につながっています。
   1ラックあたりに使える電力量が増えたのは良いことですが、それまで使用していた46Uのラックだとラックにサーバーを満杯に搭載しても8.5kVAを使い切れないことがわかりました。
   そこで新しいセンターではデータセンター事業者と相談し、そのセンターに設置することができる一番大きいラックである51Uラックを採用することにしました。
   1Uサーバー基準で最大44台のサーバーを搭載するポリシーを運用することで高密度なセンターの使用効率を100％とすることを目標としています。
   
   

   51Uラックの例

   
   
2. サーバーの効率利用
   いくらデータセンターを効率的に利用しても肝心のサーバーリソースを無駄遣いしていたのでは意味がありません。LINEではどのようにサーバーリソースの使用効率を高めているかという事例の一例を紹介したいと思います。
   LINEサービスにおいて一番台数が多いCluster Server GroupはHBaseでした。このサーバをScale-outすることでサーバ台数の増加速度を抑えました。
   HBaseサーバを分析してみるとDisk I/Oがボトルネックになっていることがわかったので、SAS-HDD、SSD、そしてPCIe-SSDを検討しました。
   
   

   HDD,SSD,PCIe-SSDのIOPSの比較

   
   図を見ると明らかなようにPCIe-SSDが圧倒的な性能を示しました。またコスト分析結果でもPCIe-SSDに大きなメリットがあったため、我々はHBaseサーバをSAS-HDDからPCIe-SSDに入れ替えることで、サーバ1台あたりの処理能力が増え、その分サーバ台数を減らしていきました。
   ただし、PCIe-SSDには1.2TBや3TBなどといったいくつかの容量が選べましたが我々は1.2TBを選定しました。その理由としては、PCIe-SSDを用いると今度はCPUがボトルネックとなり、とても3TBまで使い切れないことが判明したためでした。

増え続けるサーバ間通信対策

LINEサービスはサーバ間通信が多いシステム構造となっています。ネットワーク運営的にはインターネットトラフィックも急増しましたが、データセンター内部のトラフィックの急増による課題のほうが問題になっていました。

1. ネットワークの構造的な問題
   ネットワークスイッチに対する作業や障害等でSTPのTopology Changeが発生すると、MAC Address Tableがクリアされるため、サーバー間通信が多いVlanでは数百MbpsのUnkown Unicast Floodingが発生することがありました。それによりスイッチに接続されているサーバー向けのインターフェースのトラフィックが溢れてパケットドロップが発生するまでになっていました。この状況に対応するためネットワーク構造の改善を実施しました。
   改善のコンセプトはネットワークが不安定になる要因の排除とサーバー配置の自由度の向上でした。具体的には以下のような方法を採用しました。
   • L2ドメインの最小化
     いままでの構成はPOD単位でL2ドメインを構成していました。LINEの環境では同一POD内にサーバーが数千台収容されるため、前述のUnkown Unicast Floodingの影響が大きくなってしまいます。
     そこで一番大きな問題点であったUnknown Unicast Floodingの影響を最小限にするため、Edge Switch (ToR Switch)単位でL2ドメインを区切ることにしました。
     これにより、Unkown Unicast Floodingが発生してもその量は少なくて済む上影響が出る範囲も同じラック内にあるサーバーだけに留めることができます。
   • ネットワークのボトルネックを無くす
     サーバーの配置の自由度を高めるには、たとえサーバー間トラフィックが多いサーバーでもどのEdge Switch、どのPOD配下にでも置ける構成にする必要があります。
     そこで考えたのが、ボトルネックのないネットワークです。通常ネットワークのボトルネックになりやすい箇所はEdge SwitchのUplinkとPOD間の通信です。
     ネットワーク構成の改善にあたり、ボトルネックになりやすいこれらの箇所の帯域幅増強も実施しました。
     具体的にはEdge SwitchのUplinkは20Gbps、POD間通信は160Gbpsを最小構成とし、必要に応じて増速できる構成としています。
   • L3DSR方式のロードバランサー構成を採用
     LINEではロードバランサーをIn-Lineの構成ではなく、DSR(Direct Server Return、戻りのトラフィックはロードバランサーを経由しない)構成にしています。
     L2ドメインを大きく区切っていた時には、ロードバランサーとサーバーが同じL2ネットワークに配置されている場合にのみ使えるL2DSRという構成を採用していました。
     新しい構成ではEdge Switch単にでL2ドメインを区切るためにL2DSRが使いづらいネットワークとなりました。そこでロードバランサーとサーバーが同じL2ネットワークに配置されていなくても使うことができるL3DSRという構成の検討を始めました。L3DSRには2種類の方式があり、1つがTunnel方式でもう1つがDSCP方式です。Tunnel方式の場合、IPをIPでカプセル化しロードバランサーとサーバーがあたかも同一L2ネットワークにあるようにみせかける方式であるためEthernetの標準MTUである1500を超えないようにする仕組みが必要となります。DSCP方式の場合はそのようにする必要が無いためLINEではこの方式を採用することにしました。
     今ではLINEの大部分のシステムはDSCP方式のL3DSRで動作しています。
   

   構成変更前のネットワーク

   
   
   

   構成変更後のネットワーク

2. Short Burst Traffic対策
   短期間に大量のトラフィックが発生するとShort Burst Trafficと呼ばれる現象が発生することがあります。Short Burst Trafficとは、短期間に大量のトラフィックが発生することにより通信許容量を超えてしまう現象です。
   下の図は実際にShort Burst Trafficが発生したときの、とあるL2スイッチの特定ポートのステータスです。この図では1Gbpsのインタフェースに対して700Mbpsの通信量でdiscard(破棄)が発生しているのがわかります。ここでは1Gbpsのキャパシティに対して700Mbpsと、まだ300Mbpsの帯域に余裕があるように見えても実際はL2スイッチのバッファキャパシティを超えている状況です。
   
   

   Short Burst Trafficが発生したときのL2スイッチポートの状況

   
   一般的なL2スイッチは、受信したフレームを一旦バッファに入れてから少しづつ転送（スイッチング）する仕組みを取ります。上記の状況ではL2スイッチのバッファに収まりきらないほどの通信が瞬間的に大量に発生したため、バッファに収まらない分がdiscardとしてカウントされました。
   この問題に対して我々は2つの対策を取りました。
   1. バッファサイズが大きいL2スイッチへの入れ替え
   2. Short Burst Trafficの制御が難しいサーバをネットワーク的に分離することで他のサーバに影響を及ぼさないようにする

オンラインデータリバランシング

我々はデータベース拡張を日常的に行います。特にLINEGAMEにおいて、リリース直後に想定外の大ヒットを飛ばすゲームが度々現れます。LINEGAMEはユーザ数の規模が他のオンラインゲームと桁違いなのに加えてリリースされるタイトル数も多く、ユーザ数の増減に合わせてデータベースを柔軟にスケールアウトさせる手法の導入は我々にとって必須なものでした。

我々がデータベースのスケールアウトに求める要件は以下のようなものでした。

• DBに格納するデータが1台の規模を超えた場合に備えて、データを複数のDBに分けて保存しなければならないこと
• 新しいDB装置を追加すると、その分、新規の容量を確保することだけでなく、スループット増設もできること
• 別のサーバにデータを移行する場合は、サービス中断なく作業が実行できること
• サーバに障害が発生したりDBやソフトウェアのアップグレード時にサービス中断が発生しないこと

この問題に対して我々は一部システムにて無停止でShardを追加するnBaseという自社開発のシステムを導入しました。nBaseでは以下の機能が実装されています。

1. Hash演算を使ったマッピングとCGID(Container Group ID)単位でのグループ化
   
   

   マッピングデータ

   
   データベースのデータに対してCGIDと呼ぶ独自IDを付与することでnBaseのMgmtが各Group ID毎にShard先を管理できるようにしています。
   (いくら大規模なマッピングデータであれ、サイズを小さくして、各アプリケーションとDBサーバーのメモリ上に記録させるためです。)
2. サーバ増減時、CGIDのShard先を再構成し、データリバランシング
   
   

   Nbase データリバランシング

手順

1. 最初のMgmtは、 Shard #3機器にShard #1機器で30番CGを移行するように命令します。
2. 命令を受けたShard #3装置は、 Shard #1機器のDBに接続して30番CGのデータを読み取る準備をします。
3. Shard #1装置にDB接続を完了したら、 Shard #3の装置は、複数回に分けて30番CGのデータをselectした後、自分のDBにinsertします。
4. いくつかの段階に分けてデータを移行して、もうShard #1に残っているデータが非常に少ないと判断されればShard #1のサーバー30番CGのデータを変更する操作をBLOCKします。
5. そして最後に残っているデータをすばやく読んでShard #3装置に反映します。
6. mgmtは、このCGの前にある終了を検出し、このCGの位置はShard #3であることを他のサーバーに通知します。

おわりに

LINE社は14年の歴史を持ちますが、LINEサービスでは、これまでリリースさせていただいたどのサービスでも経験したことのない、グローバル、億単位のユーザ、そしてモバイルという特性により新しい課題に次々遭遇します。多くの課題はネットを検索しても解決策にたどり着かない類のもので、都度自分達の力で解決しています。

今後も規模が大きくなればなるほどこれまで経験したことのない状況に遭遇することになるでしょう。我々インフラ部門は世界中で愛されるLINEサービスを楽しく安定的に使っていただくために今後も精進してまいります。また、このLINEインフラを一緒に創り上げていきたいというインフラエンジニアの方を現在大募集中ですので、もしご興味がありましたら是非ご連絡ください。

どうもありがとうございました。