世界制覇をもくろむLINE――ベールを脱いだプラットフォームの全体像とは：LINE Developer Conferenceまとめリポート（前編）（3/3 ページ）

LINEは4月15日と17日の両日、世界初となる「LINE Developer Conference」を開催。LINEプラットフォームの全体像を明らかにした。本稿では、その中でもLINEプラットフォームを統べるChannel Gatewayとは何か、LINEビジネスコネクトの仕組みとは、インフラをどのように高速化しているのかなどについてお届けする。

[益田昇，＠IT]

LINEにおけるネットワーク周りの高速化への取り組み

　LINEビジネスコネクトなどの利用が本格化していくと、サービスや通信の負荷は増大していく。LINEでは、サービスの高速化に向けてどのような取り組みを進めているのだろうか。

SPDYの最適化

　LINEのクライアントとサーバー間は、HTTPを拡張して高速化を図ったプロトコルである「SPDY」をベースに通信を行っている。なぜSPDYの仕様をそのまま使っていないかというと、LINEサーバーの場合は、通信の相手はLINEアプリしかなく、UserAgentは1種類に限定される。UserAgentが未知の状態でサーバーがリクエストを受け付ける場合、どのプロトコルで相手と通信するかを最初に決めなければならないが、LINEサーバーの場合は、そうした処理を省略することによって通信の高速化を図っている。

SPDYを最適化して通信の高速化を図る

「NOOP Frame」の活用

　また、国によっては通信回線が低速な場合もある。こうした通信環境でも、最初のパケットで通信を確立してしまえば、比較的高速に通信できるケースも少なくない。LINEの通信では、SPDYに加えて「NOOP Frame」（SPDYのドラフト2まで入っていた仕様）を使うことで、こうした処理を簡素化することにより通信を高速化する工夫を行っている（参考：Adopting SPDY in LINE - Part 2: The Details ≪ LINE Engineers' Blog）。

NOOP Frameで通信の高速化を図る

　「このSPDYの部分を担当しLINEクライアントからリクエストを受け付けているサーバーをわれわれは『LEGY（LINE Event GatewaY）』と呼んでおり、このLEGYは、並行処理指向の汎用プログラミング言語であるErlangで書かれています」（田中氏）

　Androidのプッシュ機能を効率化する「LEGY Server Push」、LINEクライアントにあらかじめ証明書や暗号キーを配置することでカギの交換手順を省略する「LEGY Encryption」などによっても、通信の高速化を図っている（参考：Adopting SPDY in Line - Part 1: An Overview ≪ LINE Engineers' Blog）。

Erlang言語によるプログラミングで処理を効率化

LINEにおけるストレージ拡張と処理の高速化の歴史

　登録ユーザーやメッセージの送受信数が日々増大する中、LINEでは、ストレージの拡張性の確保と処理の高速化が重要な課題であり続けている。

Redisの活用からクラスター化へ

　LINEがサービスを開始した当初は、ストレージは主にオープンソースのインメモリデータベース「Redis」を使っており、用途に応じてMySQLも利用していた。ところが、そのままではユーザー数の増大に対応しきれなかったため、とにかくRedisの数を増やそうと、Redisのクラスター化に取り組んだ。

HBASEに白羽の矢

　とはいえ、高価なメモリを主に利用するRedisの数をそのまま増やしていくのでは、コストが掛かり過ぎてしまう。また、LINEを利用するデバイスの多様化に対応するためには、永続化をきちんと確保した上で、高いパフォーマンスを引き出す必要がある。こうした点を考慮して検証を行った結果、白羽の矢が立ったのが列指向の分散データベース「HBASE」だった。

HBASEをHAに、StormやMongoDBも導入

　しかし、HBASEも導入しただけではうまく拡張することはできず、すぐにHA（高可用）構成に対応、並列化していくことになった。同時期に、リアルタイム分散処理フレームワークの「Apache Storm」も導入して使用を開始した。その際、柔軟なスキーマで情報の格納をしたかったためMongoDBを使用しているという。

Redisをさまざまな用途で活用

　Redisの最新の活用法は、HBASEの手前に置いてキャッシュ目的で使用するというものだ。そこでは、大量のリクエストが直接Redis上で処理されないように工夫されている。Redisは、用途を変化させながら、従来の使い方も含めて、引き続きさまざまなところで利用されている。

用途に応じてDBを試行錯誤しながら活用

　現在、Redisは、キャッシュ、コンタクト、メッセージ／同期キュー、タスクキューなどの用途で利用されており、総容量は30TB。メインストレージとして利用されているHBASEの総容量は1PBに上っている。また、ログ解析、統計に活用されているHadoopの総容量は7PBで、そのうち約42％が使用されている。

LINEのシステムアーキテクチャの現在

　LINEのサービスを支えるシステムアーキテクチャを見ると、ストレージレイヤーの上にLINEアプリレイヤーが位置付けられ、その上に、認証、LINEコネクションレイヤー（LEGY）、LINEクライアントがある。

　LINEアプリレイヤーで特徴的なのは、アプリケーションサーバー間の通信を非同期で安全に行うメッセージキューの技術を多用していることだ。LINEのサービスではメッセージのロストが最も懸念される障害であり、それを防止して信頼性を高めるために、メッセージをいったんキューに格納して再送するといった工夫がなされている。

LINEのシステムアーキテクチャ

　LINEのシステム構成全体を見渡すと、単一のハイエンドサーバーがあらゆる処理をこなすのではなく、さまざまなサービスを提供する多様なサーバーが通信し合い、協調して動作していることが分かる。そして、さまざまな技術とノウハウを駆使して、拡張性と信頼性を最大限に高め、拡大を続けるビジネスを支えている。

LINEのサーバー構成図

次回は、LINE GAMEプラットフォームの全貌

　次回は、LINE GAMEプラットフォームの全貌についての講演の模様をお届けするので、お楽しみに。