開発者もインフラエンジニアも楽になる！ LINEの大規模インフラにおけるアーキテクチャ改善の取り組み【LINE DEVELOPER DAY 2018】

　2011年6月にサービスを開始したLINE。7年が経ち、現在、LINEでは物理サーバ3万台以上、インターネットトラフィックは1Tbpsを超える大規模なインフラを運用している。膨大なトラフィックを裁くためにどのようなネットワークデザインをしているのか、またインフラプラットフォームが大量のインフラリソースをマネジメントする方法、高可用性かつ高拡張性のあるインフラを提供するために乗り越えてきた課題とは――。LINEの技術カンファレンス「LINE DEVELOPER DAY」において、同社 インフラプラットフォーム室の三枝慶寛氏が解説した。

主要4カ国で1億6500万人のユーザーを抱えるLINEのインフラの課題とは

LINE株式会社 インフラプラットフォーム室　三枝慶寛氏

• 講演資料
• セッション動画

　三枝氏は2005年に入社（当時の社名はNHN JAPAN）。以後、10年以上にわたりネットワークとデータセンターなどのインフラに携わってきた人物だ。

　「LINEがリリースされてから7年以上が経過し、その間、インフラにおいては規模の拡大に伴い次のような課題が起こってきた」と三枝氏は語る。

1. キャパシティの限度
2. アーキテクチャの非効率性
3. 運用コストの増大

　なぜ、このような課題が起こってきたのか。その背景の第一がネットワークの問題である。ユーザー向けのトラフィックは1Tbpsを超えるが、それよりも「実際にはデータセンター間で発生するデータ間通信のトラフィックの規模が大きい」と三枝氏。そこでデータセンターとサーバ間通信をどう裁くかを主眼に置いてネットワーク設計をしてきた。

　従来の設計では1つのネットワークPOD（Point of Delivery：コンピュータやシステム・システムモジュール等が提供されるかたまり）で1台あたり10Gbpsのネットワークインターフェースを持つサーバーを3200台収容できるようにしており、ネットワーク全体のPODでは1万6000Gbpsのキャパシティを実現。そしてそれを2Nの冗長構成でインフラを提供していた。

LINEの従来のネットワーク設計

　だがこのような構成だと、10Gbpsを使い切るサーバが増えると、ネットワークにボトルネットワークが発生し、通信が不安定になってしまう。「トラフィックを処理するサーバをネットワークの近いところに置くという運用でカバーしていたが、サーバ数が増えるに従い、このような運用が難しくなってきた」と三枝氏は説明する。

　第二に2Nの冗長化方式の効率の悪化も問題だった。1万6000Gbpsのネットワークのキャパシティを提供するには、3万2000Gbpsのネットワークのインフラを組む必要がある。「Nの数が増えると、どんどん効率が悪化していく一方だった」と三枝氏。

　第三はコネクション数の問題である。LINEが主に使われている日本、台湾、タイ、インドネシアの月間のアクティブユーザーの合計が1億6500万人。デイリーのアクティブユーザー比率は77％なので、LINEのインフラは常にユーザーの何千万というTCPコネクションを同時に取り扱う必要がある。そのTCPコネクションはロードバランサーを通じて、メッセージングゲートウェイというサーバに振り分けられる。一つのTCPコネクションは同じサーバに振り分けないと通信は実現しない。そのためロードバランサーは、TCPコネクションをセッションテーブルで管理するのだが、セッションテーブルのサイズは、ロードバランサーの各ノードのメモリのサイズに依存するため、キャパシティ不足とならないようにロードバランサーを複数並べることで対応してきた。

　ロードバランシングの方式として採用したのはDSR（Direct Server Return）だ。DSRでは、クライアントからサーバに向かう通信だけがロードバランサー経由となり、サーバからクライアントに向かう通信はロードバランサーを経由しない。「クライアントからサーバに向かうトラフィックの方が、サーバからクライアントに向かうトラフィックに比べて、容量が小さい。小さなトラフィックに合わせてロードバランサーのキャパシティを設計できるというメリットがあったため」と三枝氏は語る。

ロードバランシングにはDSR方式を採用

　しかしこの方式にはデメリットもある。それはセッションテーブルに関するきめ細やかなコントロールが難しいことだ。

　「LINEのユーザーを多数抱える通信事業者側で大きな障害があった場合やLINEのインフラ自体に問題があった場合に、LINEのクライアントがサーバと通信しようとすると、TCPレベルでのリトライが多数発生する。このようなリトライの通信の一つ一つが、セッションテーブルに乗るため、その状況が続くとセッションテーブルがあふれてしまうことが起こってしまう。セッションテーブルのスケールの課題とロードバランサーの2N方式という冗長方式の悪化が大きな課題となっていた」（三枝氏）

　第四に開発者と開発拠点の増加による運用コストの増大も問題だった。LINEでは開発者がアプリケーションをデプロイするためのインフラリソースを手配する場合、インフラレイヤー毎の専門チームに依頼を出す形で対応していた。「開発者の数や拠点数が少ないときは対応できていたが、すべての開発者がどのインフラチームにどのような依頼を出せば、自分が欲しいインフラリソースが手に入るのか理解するのは難しい。そのための学習コストが負担になっていた。またそれに対応するインフラチームの側も負担が増えていた。相互の負担を軽減するため、根本的な改善が不可欠だった」と三枝氏は話す。