主要4カ国で1億6500万人のユーザーを抱えるLINEのインフラの課題とは
三枝氏は2005年に入社（当時の社名はNHN JAPAN）。以後、10年以上にわたりネットワークとデータセンターなどのインフラに携わってきた人物だ。
「LINEがリリースされてから7年以上が経過し、その間、インフラにおいては規模の拡大に伴い次のような課題が起こってきた」と三枝氏は語る。
- キャパシティの限度
- アーキテクチャの非効率性
- 運用コストの増大
なぜ、このような課題が起こってきたのか。その背景の第一がネットワークの問題である。ユーザー向けのトラフィックは1Tbpsを超えるが、それよりも「実際にはデータセンター間で発生するデータ間通信のトラフィックの規模が大きい」と三枝氏。そこでデータセンターとサーバ間通信をどう裁くかを主眼に置いてネットワーク設計をしてきた。
従来の設計では1つのネットワークPOD（Point of Delivery：コンピュータやシステム・システムモジュール等が提供されるかたまり）で1台あたり10Gbpsのネットワークインターフェースを持つサーバーを3200台収容できるようにしており、ネットワーク全体のPODでは1万6000Gbpsのキャパシティを実現。そしてそれを2Nの冗長構成でインフラを提供していた。
だがこのような構成だと、10Gbpsを使い切るサーバが増えると、ネットワークにボトルネットワークが発生し、通信が不安定になってしまう。「トラフィックを処理するサーバをネットワークの近いところに置くという運用でカバーしていたが、サーバ数が増えるに従い、このような運用が難しくなってきた」と三枝氏は説明する。
第二に2Nの冗長化方式の効率の悪化も問題だった。1万6000Gbpsのネットワークのキャパシティを提供するには、3万2000Gbpsのネットワークのインフラを組む必要がある。「Nの数が増えると、どんどん効率が悪化していく一方だった」と三枝氏。
第三はコネクション数の問題である。LINEが主に使われている日本、台湾、タイ、インドネシアの月間のアクティブユーザーの合計が1億6500万人。デイリーのアクティブユーザー比率は77％なので、LINEのインフラは常にユーザーの何千万というTCPコネクションを同時に取り扱う必要がある。そのTCPコネクションはロードバランサーを通じて、メッセージングゲートウェイというサーバに振り分けられる。一つのTCPコネクションは同じサーバに振り分けないと通信は実現しない。そのためロードバランサーは、TCPコネクションをセッションテーブルで管理するのだが、セッションテーブルのサイズは、ロードバランサーの各ノードのメモリのサイズに依存するため、キャパシティ不足とならないようにロードバランサーを複数並べることで対応してきた。
ロードバランシングの方式として採用したのはDSR（Direct Server Return）だ。DSRでは、クライアントからサーバに向かう通信だけがロードバランサー経由となり、サーバからクライアントに向かう通信はロードバランサーを経由しない。「クライアントからサーバに向かうトラフィックの方が、サーバからクライアントに向かうトラフィックに比べて、容量が小さい。小さなトラフィックに合わせてロードバランサーのキャパシティを設計できるというメリットがあったため」と三枝氏は語る。
しかしこの方式にはデメリットもある。それはセッションテーブルに関するきめ細やかなコントロールが難しいことだ。
「LINEのユーザーを多数抱える通信事業者側で大きな障害があった場合やLINEのインフラ自体に問題があった場合に、LINEのクライアントがサーバと通信しようとすると、TCPレベルでのリトライが多数発生する。このようなリトライの通信の一つ一つが、セッションテーブルに乗るため、その状況が続くとセッションテーブルがあふれてしまうことが起こってしまう。セッションテーブルのスケールの課題とロードバランサーの2N方式という冗長方式の悪化が大きな課題となっていた」（三枝氏）
第四に開発者と開発拠点の増加による運用コストの増大も問題だった。LINEでは開発者がアプリケーションをデプロイするためのインフラリソースを手配する場合、インフラレイヤー毎の専門チームに依頼を出す形で対応していた。「開発者の数や拠点数が少ないときは対応できていたが、すべての開発者がどのインフラチームにどのような依頼を出せば、自分が欲しいインフラリソースが手に入るのか理解するのは難しい。そのための学習コストが負担になっていた。またそれに対応するインフラチームの側も負担が増えていた。相互の負担を軽減するため、根本的な改善が不可欠だった」と三枝氏は話す。
