「LINE DEVELOPER DAY 2019」レポート

DAY-1,時系列データベース‘Flash’とは?/LBaaS実現への道

この記事を読むのに必要な時間:およそ 5 分

「LINEの独自LBaaSを支えるソフトウェアエンジニアリング」by 早川侑太朗氏

LINE ネットワーク開発チーム インフラエンジニアの早川侑太朗氏より,⁠LINEの独自LBaaSを支えるソフトウェアエンジニアリング」というテーマでセッションが行われました。

早川侑太朗氏

早川侑太朗氏

「Verda」は,LINEのプライベートクラウドのコンポーネントの1つで,2016年頃より社内で運用されている,OpenStackベースのクラウドサービスです。LINE本体をはじめとして,多くのサービスがVerdaの上で運用されています。

同社内では,従来のインフラから「Verda」への移行が進んでいます。現在は,1,400のハイパーバイザ,3万5000のVMを収容するなど,大規模なプラットフォームとなっています。昨年は1年間で2万のVMが新たに作られるなど,その利用範囲も急激に拡大しています。

LINEのプライベートクラウドを支える完全自社開発のLBaaS

現在「Verda」で提供されているサービスは多岐にわたります。コンピューティングやネットワーキングなど基本的なインフラリソースを提供することに加えて,K8SやKafkaなどマネージのミドルウェア,最近ではFaaSなども乗せて運用されています。

同社が開発しているロードバランサは,これらの中でもコンピューティングやネットワーキング,ストレージと並ぶIaaS群の1つです。

「Verda」の概要

「Verda」の概要

「Verda」におけるLBaaSの役割は,LINEの各種サービスに対してスケーラブルで耐障害性の高いサービスを提供することです。デベロッパは,LBaaSが提供する抽象化により,あたかもロードバランサがそのサービス専用のものであるかのように運用できるようになっています。

実際には,全サーバ共通のロードバランサクラスタが用意されており,そこからリソースを切り出して使う形になっています。早川氏の所属するチームでは,この共通クラスタや,デベロッパに対するAPIサーバなどの開発や運用を行っています。

LBaaSの概要

LBaaSの概要

多様なサービスを提供しているLINEですが,そのためロードバランサも1つの汎用性の高いものを提供するだけでは広範なニーズに対応できません。そこで同社では,ロードバランササービスの中でも2種類のサービスを提供しています。

1つは,L7LB(Layer7 Load Balancer)と呼ばれているものです。こちらは,Webサービスなどでお馴染みのいわゆるリバースプロキシです。httpのパスやヘッダの内容をもとに,アプリのリクエスト単位で負荷分散をしていきます。

もう1つは,L4LB(Layer4 Load Balancer)です。こちらはアプリよりさらに下のレイヤの,IPアドレスやポート番号といった情報をもとに,TCPのコネクションレベルで負荷分散を行います。

この2つは,社内に持つユースケースで棲み分けが行われています。L7LBは,L4LBと比較してリッチな機能が備わっています。一般的なWebアプリでは,こちらを使うことでほとんどのユースケースに対応できます。

しかし,LINE本体のメッセージングサービスや動画配信,メディア配信といったパフォーマンスが求められるものでは,L7LBではオーバーヘッドが大きくなってしまいます。そのため,よりシンプルで高速なL4LBが好まれる傾向にあります。一般の人が目にするところで使用されている例としては,テキストメッセージやビデオ,アイコンに使われるイメージなどがあります。また,⁠LINE BLOG』『LINE Clova』といった,一部サービスでも利用されています。

「Verda」の利用範囲は広がってきており,それに伴いロードバランサのユーザ数も年々増えていくと予想されています。

このように,LINEの中でもかなり重要な位置を占めているロードバランサですが,既製品を購入してそのまま運用しているというわけではありません。ロードバランササービス自体を自社開発しています。デベロッパがロードバランササービスにアクセスするためのAPIサーバや,L7LB,L4LBのサービスも含めて,すべて自社で独自開発して運用されているのです。中でもL4LBでは,実際のユーザのトラフィックを処理するData Planeと呼ばれるところから,ほぼスクラッチで開発されています。

既製ロードバランス製品の問題─⁠─運用コスト,スケーラビリティ,アベイラビリティ

なぜ既製品を使わずに,自社開発を行っているのでしょうか? これについては,LINEが既製品のアプライアンスを運用していく中で直面してきたさまざまな問題から,最終的に自社開発を決断したという背景があります。その問題とは,運用面のコストとスケーラビリティの問題,アベイラビリティの問題です。

「Verda」のロードバランサができる2016年以前は,既製品でサービスが提供されていました。そのときは,1+1と呼ばれるロードバランサを2台使い,アクティブスタンバイで動かす方式がとられていました。多くのユーザはL4LBを使い,必要に応じてL7LBが提供されるといった運用が行われていました。

サービス規模が小さいうちは問題ありませんでしたが,サービス規模が拡大していくにつれてさまざまな問題が起きるようになってきました。1つは運用コストの問題です。当時のロードバランサは,CLIベースで人がマニュアルで操作することが前提になっており,オートメーションが非常に難しい状態でした。オペレータの手が空いていなかったときは,デベロッパがロードバランサの利用申請を出してから1〜2日経って,ようやくリクエストが処理されるという形になっていました。これらはオペレータとデベロッパの双方にとって,ストレスが高いものとなっていました。

社内でロードバランサの需要が高まっていくにつれて,こうしたオペレーションの問題は無視できなくなってきたのです。スケーラビリティとアベイラビリティにも問題を抱えており,その根幹にあったのはセッションテーブルの枯渇問題です。これらは,L4LBの実装方法に起因していました。

L4LBを実装する方法は数多くありますが,その中でも今現在どのサーバにどのクライアントが接続しているのかという対応関係を,TCPのコネクション1つごとにセッションテーブルと呼ばれるデータ構造に記憶していく方式があります。当時採用された方式はこちらでしたが,同時接続しているクライアントの数があまりにも増えてしまうと,セッションテーブルの容量が枯渇し,それ以上新しいコネクションを受け付けられなくなってしまうという弱点があります。同時に接続できるクライアントの数が,セッションテーブルによって制限されてしまうということです。

また,セッションテーブルのメモリ容量を意図的に枯渇させることができるTCP SYN FloodというDOS攻撃があります。この攻撃を受けると,セッションテーブルがサービスにとってまったく意味のない情報で埋め尽くされてしまいます。その影響は,ロードバランサに登録されているすべてのバックエンドサーバにおよぶため,非常に広範囲で障害が発生してしまいます。

スケーラビリティ,アベイラビリティの問題

スケーラビリティ,アベイラビリティの問題

著者プロフィール

高島修(たかしまおさむ)

コンピュータホビー雑誌『ログイン』の編集者やドワンゴでモバイルサイトの企画・運営等を経て,2014年よりフリーで活動中。XRやPCなどのIT系やゲームをメインに,年間120本以上の取材をこなしています。

バックナンバー

「LINE DEVELOPER DAY 2019」レポート