2021年11月10日・11日の2日間にわたり、LINEのオンライン技術カンファレンス「LINE DEVELOPER DAY 2021」が開催されました。特別連載企画「DEVDAY2021 アフターインタビュー」では、発表内容をさらに深堀りし、発表では触れられなかった内容や裏話について登壇者たちにインタビューします。今回の対象セッションは「RedisのPub/Subを使って設定情報を大規模ユーザに高速配布した話」です。
ライブ配信サービス「LINE LIVE」は多くのユーザーに利用されており、なかには数十万ユーザーが同時接続するような配信もあります。「LINE LIVE」のチャットシステムでは、さまざまなシステムやユーザーの設定情報を一斉に同期する必要があり、これらの設定反映の速度はユーザビリティに大きく影響します。
旧来のアーキテクチャでも必要な情報を取得してキャッシュする仕組みはありましたが、キャッシュの有効期限が切れたときにしか情報が更新されませんでした。この課題を解決するために、RedisのPub/Subを使ってほぼリアルタイムにチャットサーバー120台へと設定情報を配信し、各サーバー内でキャッシュする仕組みを導入したのです。
このインタビューではセッションで語られた内容の裏話を、開発3センター サービス開発1室 開発Hチームの堀内和也と朱凌墨が解説します。
RedisのPub/Subを汎用的に利用可能にするため機能を拡張
――開発Hチームの役割やお2人の業務内容を教えてください。
堀内：開発Hチームは「LINE LIVE」の開発・運用を担当しています。私はこのチームのリードエンジニアで、 「LINE DEVELOPER DAY 2021」での発表も担当しました。朱さんもエンジニアで、このプロジェクトにおいて実際に手を動かしてコードを書き、機能を開発する役割を担っていました。私はこのプロジェクトで、設計・実装方針のレビューをしたり、相談を受けたりしました。
――「LINE DEVELOPER DAY 2021」のセッション内では、設定情報を各ユーザーに配布するための手法として、RedisのPub/Subを用いた旨が解説されていました。この方法を用いた経緯についてご説明ください。
堀内：イベントで発表したプロジェクトよりも以前から、私たちはユーザーがチャットルームで投稿したコメントを他のWebSocketサーバーに伝達する手段として、RedisのPub/Subを使っていました。
朱：RedisのPub/Subによる情報伝達は即時性が高いですし、この設計を他の機能にも応用できればライブラリの依存関係を不必要に増やさずに済みます。こうした利点を考慮し、設定情報の機能にもRedisのPub/Subを用いることを決めました。
――セッション内では「流用可能なように、Pub/Subの機能を汎用的に作った」旨が語られていました。設計・実装において、具体的にどのような工夫をすることで、汎用性を向上させましたか？
朱：「LINE LIVE」では、視聴者が増えるにつれてチャットルームを分割し、同一チャットルームに属するユーザー同士でのみ対話を行う仕組みを採用しています。その理由は、コメントの量が膨大になる人気の配信では、単一のチャットルームで処理するとサーバーやクライアントアプリが高負荷になるうえに、投稿されたコメントの数が多すぎてユーザーが読みきれないためUXも悪くなってしまうからです。
先ほど「もともと、チャットのコメント情報を各サーバーに反映させるためにRedisのPub/Subを用いていた」と説明しましたが、この機能では「特定のチャットルーム」に対してのみ情報を配布する設計になっていました。誰かがチャットルームで投稿したコメントは、同一ルームにいるユーザーが読めればそれでいいからです。
しかし、既存仕様のままではこの機能を複数のチャットルームへの設定情報の反映に使えませんでした。そこで、「すべてのチャットルーム」を対象として、RedisのPub/Subによる情報の配布を行えるように機能を拡張しました。リスナー側は受け取った情報の内容をもとに、どのような処理を行うかを判断する構造にしています。
余談ですが、今後追加を予定しているいくつかの機能のなかにも、RedisのPub/Subによる情報配布を行っていくことを視野に入れているのものがあります。これは、複数の機能に汎用的に使えるように機能拡張したからこその展開だと思いますね。
サービスの利便性・安定性を向上させるための設計の工夫
――今回発表された事例のように、「LINE LIVE」をより利便性や安定性の高いサービスにするために設計面で工夫されていることをピックアップしてください。
堀内：「LINE LIVE」では、配信のパフォーマンスを向上させるために、配信情報をRedisのキャッシュとして保持しています。しかし、数十万ユーザーが同時接続するような人気の高いライブ配信の場合には、Redisへの接続すらパフォーマンスのボトルネックになってしまうケースがあります。
そこで、ライブ配信機能を担うAPIサーバーのローカル上に配信情報をキャッシュすることで、Redisへのアクセス頻度を低減させています。可能な限りパフォーマンスを向上させて、ユーザーにとって利便性の高いサービスにするための工夫ですね。
朱：他には、2年ほど前に通知に関するシステム設計の改善を行いました。「LINE LIVE」では、プッシュ通知とアプリ内の通知の2種類が存在しています。
旧来の設計では両方の通知が別々の機能として実装されており、システム内で用いられる通知情報のデータ構造も異なっていました。通知設定の機能改修をする際には、ほぼ同じような修正をそれぞれのコードに加える必要があり、メンテナンス性が非常に悪かったのです。そこで、私たちは機能の再設計を行い、プッシュ通知とアプリ内通知のデータ構造を共通化し、同じ構造のデータを用いてどちらの通知も発行できるようにしました。
――プッシュ通知とアプリ内通知では、メッセージ構造も異なっていると思います。どのようにして、同一構造のデータで処理を行えるようにしたのでしょうか？
朱：この設計では、通知用のデータ構造のなかにメッセージの内容を直接入れ込むのではなく、メッセージプロセッサという概念を導入しています。通知用のデータが受け渡されると、メッセージプロセッサは定義された情報に基づいて、通知メッセージを作成する処理を行います。これにより、プッシュ通知とアプリ内通知で共通したデータ構造を持ちつつ、それぞれに最適化したメッセージを生成することが可能になりました。
サービス改善のアイデアを積極的に出し合うチーム文化
――LINE LIVEの開発・運用に携わることはエンジニアのキャリアにおいてどのような意義があるか、お2人の考えをお聞かせください。
堀内：「LINE LIVE」は大規模なトラフィックが発生するサービスです。その開発や運用に携わる過程で「どうすればサービスを安定稼働させられるか」「より利便性を向上させるには何をすべきか」などを考えていく必要があります。ユーザー数やトラフィック数が多いサービスを扱うからこそ、エンジニアとして身につけられるスキルがあります。
また、「LINE LIVE」に限らずライブ配信という市場は近年盛り上がりを見せており、今後も配信者やサービス利用者が増加していくと考えられます。これから成長していくサービスの開発に携わることで、自分の仕事が世の中にプラスの影響をもたらしていることを肌で感じられるでしょう。
また、私たちはインフラ環境の改善にも積極的に取り組んでいます。例えば、今後チャットサーバーなどのインフラ環境としてKubernetesを導入し、よりスケーラビリティの高いアーキテクチャに変えることを構想しています。
「LINE LIVE」は6年以上も前に開始したサービスですから、各種の技術的負債やレガシーな構造になっている部分がいくつもあります。開発Hチームのエンジニアたちは常に、それらをより良いシステムにするための試行錯誤を続けています。アーキテクチャ改善やシステムの最適化が好きなエンジニアにとっては、非常にマッチする環境だと思います。
朱：そうですよね。それなりに長く運用されているサービスですから、改善すべき点も数多くあります。だからこそ、エンジニアたちが自主的にアイデアを出し合い、よりメンテナンスしやすい設計に変えたり、パフォーマンスに優れたアーキテクチャを取り入れたりといったことを積極的に行っています。今回お話しした事例は、その好例です。
開発Hチームには、メンバーの誰しもがアイデアを出すことができ、その案が妥当であれば積極的に受け入れる文化があります。これは私たちのチームの非常に良い点ですし、アーキテクチャ改善に寄与している要素でもあると思います。
――今回のインタビューで、メンバーのシステム改善に対するモチベーションの高さや積極的に意見を出し合うチーム文化が伺えました。「LINE LIVE」のさらなる成長が楽しみです。どうもありがとうございました。
採用情報
LINE株式会社では一緒に働くエンジニアを募集しています！
今回のインタビューと関連する募集ポジションはこちらです。