LINE LIVEを支える負荷テストの知見。ベンチマーク環境により信頼性の高いシステムを実現する方法

サービス・機能やそれにまつわる開発の裏話や取り組みを聞く「Product Story」シリーズ 

2015年にスタートしたライブ配信サービスのLINE LIVE。いつでもどこでも、無料でライブ配信&視聴が可能という便利さから、サービス開始以来多くのユーザーにご利用いただいてきました。昨今ではコロナ禍の影響からオンライン上で楽しめるエンタメの重要性が高まっており、LINE LIVEのニーズはさらに増しています。

サービスの信頼性を高めるため、LINE LIVE開発チームは、サービスに対する負荷テストを実施するために構築されたベンチマーク環境を用いています。定期的な負荷テストを行うことでパフォーマンス上の課題を洗い出し、システムのさらなる改善につなげているのです。

今回はベンチマーク環境構築した経緯や負荷テストのノウハウ、LINE LIVE開発のやりがいなどについて、開発・運用に携わる開発3センター サービス開発1室 開発Hチームの堀内和也と開発Tチームの上田晃嗣に話を聞きました。

堀内和也
開発3センター サービス開発1室 開発Hチーム

前職にて携帯キャリアのWebサービス開発や業務システムの開発を経てLINEに入社。LINE LIVEサーバーパートのリード開発を担う。

上田晃嗣 (Ueda Koji)
開発3センター サービス開発1室 開発Tチーム
新卒入社したWeb系企業にて海外向けサービスや国内向け記事メディアの開発に従事した後、LINEに転職。所属する開発Tチームは様々なエンタメサービスを開発しており、その業務の一環としてLINE LIVEのサーバーサイド開発に携わる。


突発的なアクセススパイクが発生するサービス特性

――まずはLINE LIVEのサービス概要について教えてください。

堀内:LINE LIVEと、リアルタイムでライブ配信を実施・視聴できるサービスです。ライブ配信には大きく分けて2つのパターンが存在しています。

ひとつはLINE公式アカウントを持つ企業・団体が広告配信などを行うパターン。例えば、飲料メーカーが新商品を発表したり、通信キャリアが新しい料金プランを発表したりといったケースがこれにあたります。

もうひとつは一般ユーザーが個人的に配信を行うパターンです。ライブの視聴者はチャットでメッセージを送ったり、応援アイテムを送ったりすることで配信者とコミュニケーションをとることができます。

さらに、1年ほど前からLINE LIVEの新機能としてLINE LIVE-VIEWINGという、視聴権を購入してアーティストやアイドルなどのライブ配信を視聴できるサービスも提供しています。

LINE LIVE配信機能の簡易的なアーキテクチャ図。クライアントアプリはAPI経由でサービスにアクセスする。データストアは主にMySQLとRedisを使用しており、永続的に保存するデータはMySQLに、一時保存するデータ―

――システムの観点から見て、LINE LIVE特有のサービス特性はあるでしょうか? 
 堀内:一例を挙げると、突発的なアクセススパイクが発生することです。LINE LIVEでライブ配信が行われる際には、メッセージアプリのLINEでライブ情報が通知されることがあります。そのタイミングで数多くのユーザーがLINE LIVEにアクセスするため、瞬間的に大量トラフィックが起きる特性があるんです。

――ならば、システムのパフォーマンスを向上させることが、LINE LIVEの開発・運用においては重要になりそうですね。

堀内:ベンチマーク環境を構築した理由もそこにあります。LINE LIVEでは、特定の機能で性能劣化が発生していないか、大量のアクセスに耐えられるシステムになっているかを定期的に検証しなければ、大きな障害につながってしまう可能性があるんです。だからこそ、私たちは負荷テストの専用環境であるベンチマーク環境を構築し、継続的にパフォーマンス計測を行っています。

また、LINE LIVEは週単位で新しい機能開発を頻繁に行っています。ですから、ベンチマーク環境によって予期せぬ性能劣化を早めにキャッチアップできることが、安定的かつ攻めた開発にも繋げられているとも感じています。

負荷テストを支える各種ツールとは

――利用している負荷テストツールについて教えてください。 

上田:ベンチマーク環境が構築されたばかりの頃は、k6というOSSの負荷テストツールを用いていました。ですが最近は、k6のソースコードをベースにLINE社内で独自拡張を行った、Stampedeというツールを用いています。

Stampedeは他ツールとの連携が容易であったり、Grafanaなどで負荷テストの結果を可視化しやすかったりと、k6よりもさらに利便性が向上しました。LINEには開発組織がいくつかあり、Stampedeは開発支援室という部署によってメンテナンスが行われています。

Stampedeによって拡張されている機能の例>

  • curlやアプリケーションから負荷テストを実行するためのAPIがある
  • 実行中の負荷テスト一覧がわかるAPIがある
  • APIを簡単に利用できるCLIがある
  • CIに組み込むためのDocker Imageがある
  • 負荷テストの実行結果が時系列DBに保存されて、grafana dashboardで確認できる
  • 負荷テストの結果をSlack通知できる

――他の負荷テストツールと比較して、Stampedeのベースになっているk6の利点は何でしょうか?

上田:負荷テストのシナリオが読み書きしやすいことです。負荷テストを実施するには、秒間あたりのアクセス数といったリクエストのパターンを、エンジニアがテストシナリオに記述する必要があります。このシナリオは継続的にメンテナンスしていくものですから、読み書きが容易かどうかは運用の負担の大小に直結しますね。

さらに、k6はリクエストのパターンの柔軟性が高いのも利点です。特定種類のリクエストを送った後にしばらく待ってから別種類のリクエストを送ったり、全リクエストのうち何割かをAパターンで残りはBパターンで送ったりと、複雑なシナリオでも簡単に書けるのが良い点ですね。

 

――メンテナンス性の高さは大きな魅力ですね。日々の業務のなかで、負荷テストがどのような流れで実行されているのかを教えてください。

上田:最初期の頃は、Slack botに対して特定の文字列を含んだメンションを送ると、自動的に負荷テストが走る仕組みを用いていました。しかし、この運用ですとテスト実行する頻度がエンジニアの裁量に依存します。つまり、定期的に負荷テストを実行するという目的に沿わなくなってしまうんです。

そこで現在では、CIに負荷テストの仕組みを組み込み、1日に1回実行する形をとっています。また、もともと利用していたSlack botの機能もまだ生きているので、自分たちの好きなタイミングで実行することも可能です。

――負荷テストを実施したことで、改善できた点はあるでしょうか?

堀内:LINE LIVEには視聴者が配信者に応援アイテムを送る機能があります。その機能で用いられている、アイテムの一覧情報を返すAPIのパフォーマンスが悪いことを検出できました。応援アイテムの機能では、配信チャンネルによって利用可能なアイテムが異なるうえに、ユーザーごとに使用できるアイテムも変わってきます。そのためソースコードの条件分岐が複雑で、パフォーマンス劣化の原因になっていたんです。

――どのようにロジック改修することでパフォーマンス改善しましたか?

堀内:応援アイテムの機能では毎回MySQLからデータを取得しており、ほぼキャッシュを用いていませんでした。サービス開始当初はこの構造で問題なかったのですが、仕様変更や新機能追加をしていった中で、いつの間にか性能が劣化していったパターンになります。

またAPIへのアクセス量も、サービスが成長したりアプリの仕様変更があったりする中で多くなっていました。そこで、可能な限りキャッシュを活用する実装方針に変更。ロジックのコア部分に手を入れるとデグレードのリスクが高いため、なるべくコアを修正せずに性能改善させる方針をとりました。さらに、修正後のコードで確実に改善できているのかを検証できるのもベンチマーク環境の良いところですね。

 

――負荷テストのシナリオの書き方で工夫している点はありますか?

堀内:アプリエンジニアと協力して、どのAPIにどれくらいのアクセスがあるかの内訳を出し、その内容に沿ったシナリオを書いています。実際のアクセスパターンに近いシナリオで事前検証しておくことで、本番環境で起きる可能性のある障害を未然に検出しやすくなりますから。

上田:また、アクセススパイクにもいくつかの傾向があるため、シナリオのパターンを複数用意しています。例えば、配信開始のタイミングで一気に視聴者数が増えてしばらくすると少なくなるケースもあれば、人気のアーティストやスポーツチームの配信のように、多くのユーザーが継続的に視聴するケースもある。こういった実運用で生じうるアクセススパイクのパターンを考慮してシナリオを書いています。また、スマホアプリとWebアプリではリクエストの特性が異なるため、両パターンのシナリオも分けて作成していますね。

――スマホアプリとWebアプリの特性の違いは何でしょうか?

堀内:実は両アプリの機能には異なる部分がありまして、スマホアプリにのみ存在する画面項目・機能もあれば、その逆でWebアプリにしかないものもあります。アプリの仕様面の違いが、リクエストの特性の差に影響しているんです。

テストデータ作成を効率化し、さらなる改善につなげたい

――ベンチマーク環境を立ち上げたばかりの頃と、現在とで変化したことはありますか?

上田:最も大きな違いは、テスト結果をデータベースに保存し、Metabaseを用いて可視化・分析できるようにしたことでしょうか。最初期の頃は、負荷テストの結果がSlackに投稿されるようになってはいたものの、データベースに保存されてはいませんでした。過去の負荷テスト結果をさかのぼって確認することや現在の性能と比較することが、スムーズにできなかったです。そこで、現在では負荷テストの結果として以下のような項目をデータベースに格納し、定点観測できるようにしています。

また、Metabaseはデータをチャートやダッシュボードの形式で可視化できます。そのため、負荷テスト結果の推移を確認したり、パフォーマンスに課題のあるAPIの情報をわかりやすく表示したりといったことが実現しやすくなりました。

――テスト結果が継続的に蓄積されることや、情報の可視化が容易なことは、負荷テストの効果をより高めてくれそうです。今後さらに改善していきたい点はありますか?

上田:テストデータ作成の効率化ですね。定期的なテスト実行やシナリオのメンテナンス性の向上、テスト結果の可視化などは、今回お話しした施策によってだいぶ最適化できました。

一方、負荷テストに用いるためのデータ作成はまだまだ整備できていません。現在は負荷テストのデータをエンジニアの手作業で作成しているですよ。さらに、テーブルの定義変更を行った場合のベンチマーク環境へのDDL文の反映なども、エンジニア自身が行っています。

負荷試験を実施する際には、なるべく本番環境と同等のデータの量・内容を準備しておく必要があります。そうでなければ、データ依存の障害などを検出できないためです。しかし、現在LINE LIVEのユーザーレコード数は2000万弱ほどで、RDBに格納されるデータも1テーブルあたり数千万〜数億というレコード数になるケースもあります。膨大な量のデータをエンジニアが作成するのは苦労が多いですから、なんとかして効率化・自動化したいですね。

 

エンジニアの裁量の大きさはLINEの大きな魅力

――ベンチマーク環境を構築して負荷試験を行い、サービスの改善に結びつける意義とは何だと思われますか?

堀内:システムの性能改善を行うことは、エンジニアにとって大切な“守り”の業務だと感じています。安定してサービスを提供するうえで、盤石な基盤を構築するための重要な作業です。価値の高いものだと思っているので、今後も継続的に負荷試験を実施し、LINE LIVEをより良いサービスにしたいと考えています。

上田:エンジニアがシステムの品質を測定する場合、様々な基準を用います。わかりやすいところでは、静的コード解析の結果や単体テストのカバレッジ率などです。そして、負荷テストによって可視化できる性能も、私たちは機能と同じくらい重要な要素だと考えています。

性能を継続的に改善していくことで、サービスの利便性や信頼性は向上していきます。だからこそ、エンジニアがシステム品質を測定する指標として、負荷テストを行って性能を可視化することには意義がある。言うなれば、システムを良くしてくための物差しとして、負荷テストが機能してくれると思っています。

――今後もさらにサービスが改善していくのが楽しみです。最後に伺いたいのですが、エンジニアにとってLINE LIVEの開発に携わるやりがいは何でしょうか?

 

堀内:LINE LIVEはNo.1のライブ配信サービスになるために、常に新機能の開発や既存機能のブラッシュアップをしています。開発サイクルとしては、軽いものでは週単位での開発やリリースもしていて、非常にスピード感のある環境です。

また、サーバーサイドとしては他にも、裏方の運用業務が円滑に進むように社内用CMSの機能強化も積極的に行っています。どうすればプロジェクト全体がうまく回るかを考えながら仕事ができるのは良いことだと思います。

そのような攻めのスタイルが基本ですが、LINE LIVEが成長するにつれて、安定したサービスを提供する必要性も大きくなってきました。それに伴い、保守性の向上が課題の1つとなっています。そこで、今回の負荷テストのような話があります。エンジニアの裁量でそういった攻守のバランスを取ることができたり、案件を進められるのもやりがいだと思っています。 

上田:LINE LIVEをはじめとしたLINE関連サービスの開発では、社内の各種プラットフォーム・サービス担当者たちと連携をとることが多いです。その過程で、自分の所属する開発チームだけではなく、他チームの特徴や良い部分などを知ることで、プラスの影響を受けています。

また、各チームには様々な技術的バックグラウンドや国籍を持つメンバーがおり、LINEという企業の多様性を感じます。なかなか一般的な企業ではこの体制を実現できないでしょうし、LINE LIVEをはじめとしたLINE関連サービスの開発に携わる楽しさにつながっていますね。

堀内:今後もサービスの成長を開発がリードしていけるよう、色々なチャレンジを続けつつ、安定性や効率なども追求していきたいと思います。

LINE LIVEでは、一緒に働くメンバーを募集しています。

サーバーサイドエンジニア / LINEファミリーサービス

iOS/Androidエンジニア / LINEファミリーサービス