ギフトからコミュニケーションを！IRIAMのギフト体験を支えるGoサーバの負荷対策とシステム基盤の変遷

ギフトからコミュニケーションを！ IRIAMのギフト体験を支えるGoサーバの負荷対策とシステム基盤の変遷 2026年 03月 12日 (木) 今江 健悟 IRIAMプラットフォーム事業部 プロダクト開発部 エンジニアリング第九グループ 株式会社 IRIAM

アジェンダ IRIAMのギフト体験を支えるGoサーバの負荷対策とシステム基盤の変遷 ● 導入: IRIAMとは？ & ギフトの思想 ● 解説: ギフトを支えるシステム構成 ● 事例1: 連打との戦い ● 事例2: スパイクとの戦い ● 発展: インタラクション基盤の変遷 発表内容 累計500万DLを超えるVライブ配信アプリ「IRIAM」。そのコミュニケーションの中心にあるのが、ライバーとリス ナーの想いを繋ぐ「ギフト」です。 リスナーによる猛烈な連打（通称：コンボ）や、数万人規模のユーザーへのギフト情報の更新によるスパイク負荷な ど、ギフト基盤の開発にはライブ配信特有のシビアな要件が求められます。今回はその裏側を紹介します！ 2

アジェンダ 3

導入: IRIAMとは？ & ギフトの思想 4

IRIAMについて スマホひとつで、いつでも・どこでも 「キャラのライブ配信」を楽しめるアプリです。 5

500 pt IRIAMについて スマホひとつで、いつでも・どこでも 「キャラのライブ配信」を楽しめるアプリです。 今回の本題はこの「ギフト」になります！ “集中線“って ギフトがあるよ！ 6

ギフトの思想：単なる課金アイテムではない 配信におけるコミュニケーションツールとして定義している ● IRIAMでは、ギフトをきっかけに対話や企画が生まれている ● たわいもない会話 → IRIAMでより面白く・記憶に残る瞬間に！ IRIAMのビジョンが 「心でつながる魔法をかける」 だから 「心のつながりを生む」ギフト が良いギフトなのかな。。。 現実では得られないコミュニケーションが生まれる ネタ感や思いを伝える演出など多種多様！ 7

ギフトの思想：単なる課金アイテムではない 例：ネタ 例：LOVEカテ 例：ライブ感 例：あいさつ 8

ギフトの思想：どんなギフトがあるの？ みんな違って、みんな良い。（十人十色の良さがある） 人の心を動かす 文字では表現できない体験 関係性によるつながり ニッチで個性的 空間に入り込む 場を盛り上げる 遊び方が発明される 相互作用・盛り上がり 一体感を作る ペロペロしたい

おひとつ 5pt = 40pt ギフトの思想：どんなギフトがあるの？ みんな違って、みんな良い。（十人十色の良さがある） ゴマすっても ユーザーが気づいたら 新しい遊び方を考えだ していた 何も出ないか らね！笑 人の心を動かす ただの挨拶に 5pt…？ 現実世界なら 文字では表現できない体験 考えられない 関係性によるつながり クラムボンは かぷかぷ わらったよ。 ニッチで個性的 じゃん 気分は、 いきつけの 居酒屋！ 空間に入り込む 誰かの 感情に呼応して、 より良い体験に 場を盛り上げる 相互作用・盛り上がり みんなで サイリウムを 振ると 楽しいよね。 一体感を作る 遊び方が発明される よだれ 出てきた （五感を刺激） ペロペロしたい

その他、バラエティ豊かなギフトが盛りだくさん！ 会話を盛り上げるギフトがたくさん目に入るね！ 11

解説: ギフトを支えるシステム構成 12

現在のアーキテクチャ俯瞰：構成図 APIサーバ → Pub/Sub → メッセージング配送サーバ→ 配信サーバ ● 1対多（ライバー vs リスナー複数）リアルタイム通信の構造。 ● GCP：CloudSQL(MySQL)、MemoryStore(Redis)、CDN：Fastly、etc. APIサーバ 配送サーバ 配信サーバ Cloud Pub/Sub ライバー リスナー ※ 配送サーバ：Pub/Subからメッセージ取得＆変換処理を行い、配信サーバへ送り出すためのdaemon 🤐配送サーバ / 配信サーバの仕組みなど技術的なシステム構成は企業秘密であるため割愛。 13

※ Gopherの原作者はRenee Frenchさんです。 現在のアーキテクチャ俯瞰：シーケンス図 ライバー リスナー Cloud SQL Cloud Memorystore 配送サーバ APIサーバ 配信サーバ Cloud Pub/Sub ギフトAPI コメントAPI DB書き込み Pub/Subに流す キューイング データ送信 ※ APIサーバは DB → Redis, BQ, Pub/Sub の順で処理を制御している ギフトやコメントは上記の経路で各種サーバを経由してライバー・リスナーに送信される 14

※ Gopherの原作者はRenee Frenchさんです。 現在のアーキテクチャ俯瞰：シーケンス図 ライバー リスナー Cloud SQL Cloud Memorystore 配送サーバ APIサーバ 配信サーバ Cloud Pub/Sub ギフトAPI コメントAPI DB書き込み Pub/Subに流す キューイング データ送信 ギフトデータ コメントデータ ギフト再生 === コメント表示 ギフトデータ ギフト再生 === コメント表示 こんにちわ コメントデータ こんにちわ ギフトやコメントは上記の経路で各種サーバを経由してライバー・リスナーに送信される 15

事例１: 連打との戦い 16

ギフトカテゴリ種別 アニメギフト 現在のIRIAMでは様々なギフトがあるが、大きく分けると２種類に分類される ２種類のギフト アニメギフト ＝ 画面全体に演出が表示されるギフト プチギフト ＝ 動く小さなイラストが表示されるギフト プチギフト 17

ギフトカテゴリ種別 アニメギフト 現在のIRIAMでは様々なギフトがあるが、大きく分けると２種類に分類される ２種類のギフト アニメギフト ＝ 画面全体に演出が表示されるギフト プチギフト ＝ 動く小さなイラストが表示されるギフト 更に細かい紹介をすると・・・（抜粋） ・・・ プチギフト ← これは「定常無期限運営完結パカパカプチギフト」って言うんだね笑 18

プチギフトは連打ができる プチギフトは、コンボという連打機能が実装されている プチギフトのコンボ機能 これって上限いくつなんだろうか... 19

プチギフトは連打ができる プチギフトは、コンボという連打機能が実装されている ※ 当時は10ptが最安値 1ptギフトのリリースがきっかけ プチギフトのコンボ機能 これまでに起きた連打事件（抜粋） 連打間隔が人間離れしてる これって上限いくつなんだろうか... コンボの上限なし （2026/3月 現在） あの手この手で連打されてる... 20

事例1：連打ニキと連打対策 ※詳細ロジックは非公開 ユーザー体験を損なわずに、サーバー負荷を抑える必要がある クライアント側の対策： ① リクエストの集約：コンボモードになるとコンボ用APIでリクエストをまとめて送信 ② 送信制御の追加：ギフトごとにクールタイムの概念を追加してUI側のタップ制御を導入 〜ツール利用やAPI直叩き？に見えるログが一部観測されたため〜 サーバ側の対策： ③ キャッシュのTTLを利用した防壁を追加 連打基準: 1秒間に20連打(50ms)を超えると人間離れ判定 💡人間の遅延知覚：20-50msであれば「ほぼ遅延を感じない」、100msを超えると明確に「遅れている」と感じる 21

プチギフトに限らず連打体験が生まれてる話 わいわい投票：触れるインタラクションなギフトが登場 ● 制限時間内にAとBどちらかをリスナー投票によって決める遊び ● ギフト演出中にリスナーは金平糖を ⭕/❌ に 投票し続けられる 投票!! 登場演出 フェーズ 早期決着 投票中 フェーズ 時間経過 判定演出中 フェーズ 💡IRIAMの配信は少人数(~30人)のコミュニティサイズを想定されて設計されている ・負荷対策：同接数に応じて投票間隔を伸ばす（一定人数を超える→1人1票になる） ・大規模配信を想定：ユーザー体感が崩れてしまうが、連打の体感を犠牲にしている 22

事例２: スパイクとの戦い 23

事例2：データ更新時の「スパイク問題」 ギフトの更新機構とそれによってどういったことがおこってたか 前提： IRIAMのギフト情報はマスタデータとアセットデータの２種類で管理されている マスタデータ(DB) アセットデータ(AssetBundle) ・ギフト名、開催期間、消費ポイント数、etc. ・アイコン、演出データ、テクスチャ、etc. これらの情報が更新された場合に「配信内に最新のギフトデータを届ける必要」がある 💦 現在の通信モデルとシーケンス ● 特定時刻に全アクティブユーザーが同一エンドポイントへ一斉アクセスする構造になっていた ユーザー数が少ない時代は大きな問題にはならなかったが、現在のユーザー数ではAPIコール時のスパイク負荷が無視できないものに 24

事例2：データ更新時の「スパイク問題」 ギフトの更新時のサーバ負荷軽減のためにしたこと ● 数万人同時接続時の「一斉リクエスト」を回避する意図的な遅延（Jitter）の導入 ● マスターデータのインメモリキャッシュ化（Redisやインメモリキャッシュ活用） ● 効率的なクエリやロジックへのコード修正 瞬間的にAPIの スパイクが発生 してるね.... 💡 スパイク問題＝ゲームなどでもよくある問題（ホーム遷移や日跨ぎ処理など） 25

事例2：データ更新時の「スパイク問題」 26

事例2：データ更新時の「スパイク問題」 ● 意図的な遅延（Jitter）の導入による対象APIのレイテンシー比較 アプデ ギフト更新時に レイテンシーが 悪化する影響が 解決したね！

発展: インタラクション基盤の変遷 28

発展: インタラクション基盤の変遷 旧方式（ライバー駆動ギフト）から、より安定性を高めるために新方式（サーバ駆動ギフト）へ ライバー駆動ギフト（P2P方式が近いかも？） ライバー駆動ギフトが抱える課題 ・例：座標計算や同期をライバー端末が行うギフト ・ライバー：送られてきた座標位置を計算 ・リスナー：座標位置情報を送信 ・ライバーがいない瞬間がある（バクグラ・タスキル） ・いつどのタイミングで誰が参加するかわからない ・通信環境起因の問題（メッセージ遅延・通信不良） ライバーがギフト再生に必要なことを全てやる 離席 ライバーがいないとギフト再生が止まる 座標計算 状態遷移 座標計算 メッセージ同期 �� メッセージ同期 ギフト 演出 状態遷移 通信不良 ギフ ユーザ ト再生が ー で動か 環境起因 なくな る ギフト 演出 離席 ギフト流れない...？ �� 💡ユーザー環境起因で、ギフト演出が中断してしまう＆その責任を自分たちのシステムで担保できない 29

発展: インタラクション基盤の変遷 旧方式（ライバー駆動ギフト）から、より安定性を高めるために新方式（サーバ駆動ギフト）へ ライバー駆動ギフト … … … サーバ駆動ギフト：ライバーの状態に依存しないギフト設計 ・ライバーが担っていた責任を「ユーザー端末」から「サーバ」に寄せる。 ・これにより「ライバーの状態に依存しない状態管理やギフト再生」を実現する ✍ 結論 ＋ 演出の中断耐性を持った 仕組みを導入して一部改善 したが、、、 “開発難易度が高すぎる” という状態に至る。。。 配信サーバに同居する形でギフト送信をトリガーに起動する 「サイドカープロセス」を構築することにした インタラクションギフトのための、 技術基盤のメンバーと協働して 新インタラクション基盤開発が始動！ 「サイドカープロセスサーバ」 が爆誕 30

発展: インタラクション基盤の変遷 「サーバ駆動」による安定性を実現するための技術選定の背景 gRPCストリーミングを利用した構成との比較検討 ① ユーザー依存が無くならない（ストリーミングのコネクション維持担当が必要） ② 共有リソースの扱い問題（Redisで本当にやるの…？） ③ 仕組みが複雑になりそう（ストリーミングの複雑性の考慮が必要） 種類 方式 ライバー依存度 データ管理 状態遷移 通信複雑性 ライバー駆動 現在方式 高 主にクライアント管理 サバクラ協調 高（開発&QA工数↑↑） サーバ駆動 gRPCストリーミング 方式 中（ライバーのコネク ション必須） 主にRedis管理 （外部依存） サーバ制御 中（HTTP1.1ベース+ストリーミ ング通信） サーバ駆動 サイドカープロセス 方式 小 （サーバ担保） オンメモリ管理 （単体完結） サーバ制御 小（HTTP1.1ベース） 💡ストリーミング通信の複雑性やデータ管理のしやすさなどふまえて、運用しやすい構成検討ができた 31

新方式でのインタラクションギフトのリリース安定稼働 直近の2月のアップデートでサイドカープロセス方式ギフト第一弾がリリース&安定稼働しました！ 32

まとめ 33

まとめ この発表が面白いと思ったら、 API → Pub/Sub → 配送 → 配信サーバ → ユーザー に きっかけ ギフトを 企画が 対話や いる！ 生まれて ライバー駆動 →サーバ駆動ギフト への転換 連打対策 ・ 意図的な遅延 高評価といいねとチャンネル登録をよろしくね！ 34

35