LINEのメディアプラットフォームの舞台裏
チェ・ヘソン氏：みなさん、こんにちは。メディアプラットフォームチームのチェ・ヘソンと申します。
本日は、3つのテーマについてお話しいたします。
1つ目は、LINEのメディアプラットフォームに関する簡単な概要。2つ目は、我々の体験と課題です。これはこの7年間、我々がプラットフォームを開発し、運営してきた経験からお話しいたします。そして最後に、2019年の目標を発表します。
まずはLINEとメディアプラットフォームについて、簡単にご紹介させてください。ご存知かもしれませんが、LINEメッセンジャーは日本でローンチし、今ではグローバルメッセンジャーへと成長しました。世界中のおよそ200以上の国と地域で利用されています。
2011年以降、ユーザー数は急速に増加し、この増加に合わせてトラフィックとストレージの利用も急激に増えました。同時に、タイムラインやアルバムのような関連機能も開発されました。
このような増加に対応するため、我々はプラットフォームを開発することにしました。このプラットフォームは、ストレージとデリバリーを管理できるものです。これには3つの要素があります。
1つ目は、サービス設定を追加、また簡単に変更できるというもの。2つ目は、ユーザーコンテンツを効果的に、そして安心できるかたちで保存すること。3つ目は、ストレージとトラフィックの急激な増加に柔軟に対応できることです。
プラットフォームは、サービスへの依存性を最小化しなければなりません。これは複数のサービスに対応するために必要です。プラットフォームが独立するためには、ユーザーとコンテンツ情報はプラットフォームには無関係であり、プラットフォームは、それらの情報を取得できる構成であってはなりません。
その代わり、プラットフォームは、ストレージとメディアコンテンツのデリバリーにフォーカスします。そして、コンテンツへのアクセスは、認証APIの承認ベースでしか取得できないようにしなければなりません。
プラットフォームは現在、グローバルなPOPにインストールされていて、世界中で利用可能です。
このプラットフォームは、LINEを代表するメディアプラットフォームへと成長し、80以上のLINEのサービスに対応しています。
またユーザートラフィックを直接的に管理し、CDNを利用するサービスにとっても、CDNのオリジンとして利用できます。現在、メディアプラットフォームで扱われるトラッフィクの合計はおよそ500Gbpsとなっています。
また、およそ70ペタバイトのストレージを管理しています。そしてファイルのコピーは必ず3つ用意することで、ストレージを安全に保っています。
従って、実際のストレージはおよそ200ペタバイトです。
我々のほとんどのサービスは、永久的にユーザーコンテンツを保管します。従って、今このようにお話ししている間もストレージはどんどん増えています。
これらの機能を安定化させてから、我々はメディアコンテンツを直接扱うために、メディアの専門家をチームに招き入れました。そして対象をライブストリーミングの技術にまで広げました。
従って、段階的にプロフェッショナルなメディアプラットフォームチームとして成長を遂げてきました。最近はメディアコンテンツの分析も取り扱っており、コンピュータビジョンとAI技術を組み合わせたツールや、リッチインフォメーションを提供するサービスにも注力しております。
メディアプラットフォームチームがやってきたこと
冒頭にもお話ししたとおり、私の所属するチームはプラットフォーム開発に7年従事し、その中でたくさんの経験を積んでまいりました。ここからは、みなさまがご興味あるようなこの4つのテーマについてお話ししたいと思います。
1つ目は、早くて安定的なデリバリーです。LINEを利用できるのが日本のみだったころ、メインストレージとデリバリーサーバーは1つの場所に置かれていました。
そして、サービスは問題なく運用されていました。しかし、LINEがグローバルなメッセンジャーサービスへと成長した時に、2つの問題に直面しました。
まず1つ目は、サーバーから遠い位置にいるユーザーに対して、デリバリーを早く安定的に提供できなくなってきました。2013年にタイでテストを行った際は、だいたい3秒から4秒、場合によっては10秒以上かけて、やっと100KBの画像を送信できるような状況でした。
このような遅延を解消するために、最も根本的な問題を解決する必要がありました。それはレイテンシーの削減です。
2つ目の問題は、あまりに多くのトラフィックがメインストレージに集中していたため、メインストレージはそれらのトラフィックに対応しきれませんでした。
これにより、さまざまなサービスの問題が発生しました。幸いなことに、この問題の解決策は非常に簡単なものでした。それは、メインストレージへのアクセスを可能な限り少なくする、つまり保護するということです。
この2つの問題を、1つのソリューションで解決しました。それはキャッシュです。我々はフロントエンドサーバーを開発し、グローバルPOPにインストールし、キャッシュを追加しました。フロントエンドサーバーとキャッシュは、ユーザーがコンテンツにアクセスする時にかかる時間を大幅に短くしました。
さらにメインストレージへの負荷を軽減してくれるので、ストレージへのトラフィックもこれによって大きく改善しました。とくに台湾とタイでは、我々は独自のキャッシュサーバーをISPネットワーク内で運用しています。
これをLISAと呼んでおります。現在、この2つのエリアにおいてはLISAがLINEのメッセンジャーにおける動画トラフィックのほとんどすべてを扱っています。
LISAを開発した理由
では、なぜLISAを開発したのかと言いますと、ISPとLINEの両方がLISAからの恩恵を受けることができるからです。
LINEのメッセンジャーは、お話ししたとおりグローバルサービスですので、ISPは多くのトラフィックをネットワークを通じて配信していました。このアウトバウンドトラフィックは、非常に高額でした。そこでLISAを利用することによって、ISPは海外のネットワークへのアウトバウンドのトラフィックを大きく削減し、またコスト削減にもつながりました。
LINEの観点からお話ししますと、我々はCDNの利用料を大幅に少なくすることができました。なぜならこれまでCDNが扱ってたトラフィックのほとんどをLISAが扱うようになったからです。また、LISA経由のコンテンツをコントロールすることができるので、トラフィックのルートや量を必要に応じてコントロールすることもできるようになりました。
さらに、ユーザーの観点からも多くの利点がありました。LISAはユーザーのリクエストを、フロントエンドキャッシュよりも短い距離でレスポンスしているため、レスポンスの速さ、そして安定性が大きく改善しました。これによりユーザーは、早く、そして安定的に動画視聴ができるようになりました。
これらのキャッシュは、おそらく多くのサービスプロバイダーが既に利用していることと思います。なぜLINEのプラットフォームが特別かと言いますと、一般的なキャッシュポリシーだけでなく、特別なポリシーも利用しているからです。
メッセンジャーアプリが直面した課題
では、メッセンジャーアプリの特徴を見てみましょう。
ユーザーAが画像をユーザーBに、1対1のチャットルームで送信しているとします。ここで、ユーザーBがこの画像をダウンロードしている時、キャッシュは必要でしょうか。答えはノーです。
なぜかと言いますと、ユーザーB以外にこの画像をダウンロードする人はいないからです。従って、イメージがキャッシュされた後は、これ以上のリクエストが飛ぶことはありません。つまり1対1のチャットルームではメインストレージから既にコンテンツをダウンロードしているということでしょうか？ そうであるならば、コンテンツの配信は常にとても遅いでしょう。
この問題を解決するために、デリバリーサーバーはアップロードされたコンテンツをリアルタイムで分析します。
もし、コンテンツがLINEの仕様を満たすものであれば、メインストレージとキャッシュの両方に格納されます。これにより、ユーザーBはいつでもキャッシュからコンテンツをダウンロードできます。と言うのも、コンテンツはアップロードされてすぐにキャッシュされるからです。
ホットオブジェクトを自動検知して対応
続いて、このようにモニタリングシステムから、ストレージがいっぱいだというアラートが届きました。
その理由は、ニュースサービスがLINEのメッセンジャーを通じて速報を配信したからです。この速報は、プッシュ通知を使って台湾のユーザーに配信されました。この通知が届いたユーザーはすぐに、添付画像をいっぺんにダウンロードしました。これにより大幅なダウンロード配信が発生しました。
ニュースサービスはCDNを利用するべきサービスなのですが、キャッシュが有効化されていませんでした。これにより、ユーザーリクエストがすべてメインストレージに飛んでしまい、ストレージがいっぱいになってしまいました。
問題は、ニュースサービスがCDNを使っていなかったことではなく、このような状況がまたいつ何時でも起こり得るという点です。従って、こうした事態に柔軟に対応できるように、常に準備をしておく必要があります。
そのために、我々はプラットフォームをアップグレードして、ホットオブジェクトを自動的に検知し、処理できるようにしました。
ダウンロード数が特定の期間内で、一定以上に達した場合にホットオブジェクトとされます。ホットオブジェクトが検知されたら、最も効果的なキャッシュポリシーが自動的に選ばれて、オーバーロードに対応します。
具体的には、キャッシュが有効化されて、キャッシュポリシーもハッシングからラウンドロビンに変更されて、トラフィックを分散させます。このプロセスにより、我々はオーバーロードを効果的に分散し、メインストレージとキャッシュを守ることができます。
信頼性を担保するストレージの仕組み
2つ目のテーマは、効果的で安心できるストレージについてです。
信頼性というのは、ストレージサービスにおいて非常に重要な要素です。と言うのも、ユーザーデータが失われないように、あるいは壊れないように守る責任があるからです。
信頼性を確保できたら、次のステップは、この増え続けるデータをどのようにして効率的に保管できるかです。例えば、あるユーザーが車の画像を送ったとします。
この画像はストレージに格納されて、コピーが3つ作られます。スリーコピー・ポリシーと言いますが、これによってユーザーデータを保護しています。
しかし、ユーザーデータは急激に増えています。と言うのも、必ず3つのコピーを作るからです。従って、ストレージが増えるにつれてコストも増えますし、コストが増えるのは会社にとって問題です。
一方でストレージが減れば、コストも減ることになります。従って、信頼性を維持した状態でどのようにストレージを削減できるかを、我々は常に考えてきました。
また我々は、プラットフォームの統計について、何年間も統計データを集めてきました。
このような統計データにより、ユーザーの行動パターンが分かります。ユーザーは、最近のデータを集中して使用しますが、使われるデータはストレージ全体のほんの一部だということがわかります。一方で、ロングテールコンテンツがストレージのほとんどを占めています。
このような利用パターンに基づいて、ストレージの効率化に取り組みました。ストレージの使用量を減らすことはできないので、データを効率的に格納するようにしました。
ご覧のように、現在我々は3種類のストレージを利用しています。
通常はスタンダードストレージというものを使います。最近のコンテンツや頻繁にアクセスされるコンテンツは、ハイパフォーマンスストレージに格納します。また最もアクセス頻度の低いコンテンツは、ハイデンシティストレージに格納します。
ハイパフォーマンスストレージは、高額でキャパシティも低いですが、非常に高いパフォーマンスを発揮します。一方でハイデンシティストレージは、パフォーマンスが低いものの比較的安価で、キャパシティも大きいです。また、永続的に格納するデータは、1～2ヶ月後にハイデンシティストレージへと移行させます。
このようにしてサーバーの数を最小限に保ちながら、たくさんのデータを格納することができます。
ハイデンシティストレージは、ストレージの数が少ないだけでなく、IDCスペースも効果的に削減できます。
ANTMANの働きと効果
それではもう1つ、事例を紹介します。まず、コンテンツ消費においてもロングテールの形になっていて、そのファイルはやはりストレージの大きな容量を占めます。ですので、この古いデータを何とかしなければなりませんでした。
そこで、ANTMANを開発しました。
ANTMANの役割は非常にシンプルで、JPEGからHEIFへの変換を行ってくれます。
HEIFはHEVC……社内ではH265と呼ばれていますが、HEVCを活用しますので、画質を損なうことなく、容量はJPEGと比べて約半分で済みます。
ANTMANのメリットとしては、JPEGからHEIFへ変換する際に、最適な圧縮率を自動的に算定してくれるということです。
その圧縮率を見つけ出すために、元のデータのサイズと比較しながら、HEVCエンコーディングを繰り返し処理します。
元の画質ファクターは最適な圧縮率を見つけるための、HEVCエンコーディングが何回繰り返されるかにとても影響があります。よってANTMANは、この画質とイメージのアトリビューションデータとの関係性を常に学習しています。
ANTMANは、学習に基づいて、最も適切な画質を実現するためのHEVCエンコーディングの繰り返し数量を自動的に算定します。
しかしここで問題があります。すべてのデバイスがHEIFを表示できるわけではありません。
こうしたデバイスに対応するためにANTMANは、HEIFからリアルタイムに、再度JPEGに変換することができます。
しかし、そこでまた問題があります。JPEGは何度も圧縮しすぎてしまうと、画質が非常に低くなってしまいます。一方で、圧縮が十分でないと、不必要なトラフィックにコストをかけることになってしまいます。この問題を回避するために、ANTMANはHEIFに元のJPEGの画質ファクターをバックアップします。
HEIFがJPEGに再変換された時に、元の画質データを参照し適切な圧縮率を決めます。非常にシンプルですが、とても効果的なアプローチです。
ライブ配信における課題と解決策
本日お話しする3つ目のトピックは、ライブ配信です。
ライブ配信サービスは、当初プロジェクトの期限が非常にタイトでしたので、オープンソースや商用ソフトウェアを使って開発しました。しかし、何度か開発したのち、独自のモジュールを開発するに至りました。現在では、我々のライブ配信プラットフォームは、今までに培った経験をもとに、独自で開発しています。
開発したライブ配信プラットフォームについてご紹介します。3年前、LINE LIVEのサービスをスタートするにあたり、ライブ配信プラットフォームを開発し始めました。その際、内製で行うのか、商用ソフトを使うのか悩みました。
ただし、プロジェクトの期限がかなりタイトだったため、迅速にプラットフォームを立ち上げる必要があったので、オープンソースと商用ソフトウェアを使用しました。これによって、迅速にプラットフォームを立ち上げることができました。
しかし、外部のソリューションを使うことで、運用の段階になっていろいろな問題が発覚しました。例えば、「配信ができません」「動画と音声がシンクロしなくてラグが大きい」「読み込み時間が非常にかかる」「サービスのインフラコストが高すぎる」といったお問い合わせをたくさんいただきました。
外部のソフトを使っているので、こうした問題の原因を特定したり、迅速に対処したりするということが難しかったのですが、これを解決するために、RTMPを通じて配信と視聴ができるモジュールを開発しました。このモジュールをLIMEと呼びます。
LIMEを使うことで、こういった課題に対処することができ、そしてまた、技術的にも進化させることが可能になりました。
LIMEがもたらしたもの
LIMEを開発したときに、2つの改善を行うことができました。1つはRTMPフローの改善です。
ライブ配信にはRTMPを使用しています。このライブ配信を視聴するフローを見てみましょう。まず、TCPハンドシェイク。次にTLSハンドシェイク。次にRTMPハンドシェイク。少なくとも2回、RTMPコマンドのやり取りがあります。
そこから、再生コマンドがRTMPサーバーに送られます。ここで初めて、音声と動画のデータが転送されます。ご覧のとおり、少なくともネットワークのコミュニケーションが7回行われて、初めて動画が再生されます。これが長いディレイを起こしている原因です。
現在、LINE LIVEは、中東でもサービスを提供しています。しかしこの地域はシンガポールのPOP設備を使っています。シンガポールから中東のRTTを計測したところ、約250ミリ秒でした。
ということは、RTMPを通じて中東のユーザーが動画を視聴したとしても、ローディング時間が1.7秒かかるということです。もちろんネットワークが混んでいれば、もっと時間がかかります。
こういった理由から、我々はリアルタイム配信を早急に改善する必要があると考えました。改善策の1つとして、フローを変え、再生ボタンがクリックされるまで待たずにアプリが起動したらすぐに動画の再生のための処理をあらかじめ行うようにしました。そして、再生ボタンを押したときに、RTMPの再生コマンドが送られます。
これはキープアライブコネクションを用いたシングルコマンドでの動画再生と同じ効果があります。サーバーがこのような処理をサポートできたとしても、一般的なRTMPアプリでは、こう言ったフローを制御することができません。しかしRTMP SDKの開発チームと共に、これを実現しました。
動画の読み込み時間を大幅に削減
LIMEによって改善されたもう1つの点は、読み込み時間の大幅削減です。
理解を深めるために、まずは動画のデータ構造について説明します。
動画は、Iフレーム・Bフレーム・Pフレームという要素のデータセットの繰り返しでできています。Iフレームは完全な画像です。参照フレーム間の差分情報を持っているのが、BフレームとPフレームです。
わかりやすくするために、ここではBフレームについては考えないことにします。
矢印の部分の動画を見るには、直近のIフレームからどのぐらいの差分があるかを計算する必要があります。
ユーザーがライブ配信を視聴するためにこの矢印の地点にアクセスしたとします。そのデータはPフレームですので、動画が再生されません。なぜなら参照できるIフレームがないからです。よってユーザーは、次のIフレームが来るまで待つ必要があります。
これを改善するために、RTMPサーバーからのRTMPパケット内のフレームデータをチェックして、IフレームとIフレームの間のデータをキャッシュするという方法を取りました。そうすることで、矢印の部分からユーザーが視聴し始めたとしても、キャッシュされたデータセットで視聴できるため、次のIフレームを待たずに即座に動画を配信することが可能になります。
ここまでLIMEがサポートする2つの機能についてお話ししました。これらの機能によって、TCPとRTMPでのライブ配信のディレイは、RTMPフローの制御と、直前のデータセットをキャッシュすることで改善されました。
LINE LIVEは、日本やドイツ、オーストリア、タイ、台湾、そして中東でサービスが提供されています。
いま人気のあるクイズ番組も、日本、インドネシア、ベトナム、中東で配信されています。
こうしたすべてのサービスが、我々のライブ配信プラットフォームを活用しています。そして、このすべてのサービスにLIMEが適用されていて、サービスの品質改善に役立っています。
これまで、メディアのデリバリー、ストレージ、そして処理プロセスについては多くの改善をすることができました。みなさまなら次は何を考えますか？
コンテンツをAIを用いて分析する
我々は次に、メディアコンテンツをコンピュータビジョンとAI技術を使って分析することにしました。
本日お話しする4つ目のテーマです。このコンピュータビジョンとAI技術を組み合わせたツールは、PICCELLと呼びます。
PICCELLは、LINE Chinaの開発チームと共に開発したもので、メディアコンテンツの意味・内容を分析するツールです。
PICCELLには、問題のあるコンテンツをフィルターするという機能があります。この機能はとても重要です。なぜなら、サービスの品質というのは、問題のあるコンテンツによって大きな影響を受けるからです。
コンテンツフィルタリングを自動化することで、運用コストを大幅に削減することができました。このフィルタリング機能が検知するのは、アダルトコンテンツ、特定の文化シンボル、商業的な動画・画像、または商業的なQRコードなどです。
また、画像の中に入っているテキストもコンテンツに直接的に影響するため、多言語に対応したOCRモデルもPICCELLに追加しました。現在のOCRモデルは、日本語、英語、中国語、韓国語に対応しています。タイ語とインドネシア語は、近日ローンチ予定です。
また、実はOCR機能というのはLINEのデスクトップ版に既に実装されています。iPhone版とAndroid版についても近日公開予定です。
我々はOCRモデルを活用するだけではなく、Clovaモデルも積極的に活用しようとしています。そうすることで、ユーザー体験が大幅に向上すると考えています。PICCELLの設計には非常に柔軟性があるので、社内・社外で開発されたディープラーニングのモデルは、すべて簡単に追加することができます。
メディアプラットフォームチームのこれから
本日は、このような4つのテーマについてお話ししました。いかがでしたでしょうか。最後に、メディアプラットフォームチームの2019年の目標についてお話しします。
我々のチームは、さまざまなモジュールを開発してきました。
例えばデリバリー、ストレージ、画像処理、動画処理、そしてライブ配信などです。最も直近に開発したのがLIMEで、これをOSSで提供する予定です。LIMEはNetty上で開発されていますので、RTMPを使った配信視聴機能を改善することができます。また、RTMPのそれぞれのコマンドをコントロールできるUIも提供しています。RTMPに加えて、今後はライブ配信における最も進んだ技術であるWebRTCも使う予定です。
画像処理モジュールとANTMANは、既にGPUを使っています。画像処理のプロセスのモジュールを改善することで、そのタスクの処理の仕方によってCPUとGPUを自動的に算定するようになりました。これにより、サーバー数を80％削減することができました。来年はパフォーマンスの最適化を大きな課題に挙げています。また、画像処理モジュールにGPUを使うことで、サーバーコストの削減も目標に掲げています。
我々のチームは、LINEのさまざまなサービスをサポートしていますし、来年以降もさまざまなサービスが開発されるでしょう。こうしたサービスの運用面のサポートにも、たくさんの時間を割いています。
現在、サービスの運用時間を削減するような運用ツールも開発中です。このツールは来年の早いうちにローンチする予定なのですが、ユーザー・運用者双方にとって、メリットのあるツールになることと思います。ありがとうございました。
（会場拍手）
