CEDEC2021 ダウンロード時間を大幅減！～大量のアセットをさばく高速な実装と運用事例の共有～

CEDEC 2021 の講演資料です。
ノートに講演で話した内容をそのまま記載ありますので、
講演内容を完全に把握したい方はダウンロードしての閲覧をお勧めします。

株式会社セガ 開発技術部 山田英伸/竹原涼

Transcript

1. ダウンロード時間を⼤幅減︕ 〜⼤量のアセットをさばく⾼速な実装と運⽤事例の共有〜
2. © SEGA ゲームコンテンツ＆サービス事業本部 技術本部 開発技術部 ⽵原 涼 ⾃⼰紹介 【登壇歴】 CEDEC 2020 「技術同⼈作家になろう 〜働き⽅改⾰時代におけるエン ジニアのレベルアップの⼀例〜」 Unite Tokyo 2019 「⼤量のアセットも怖くない︕〜HTTP/2による⾼ 速な通信の実装例〜」 CEDEC 2018、CEDEC 2016、CEDEC 2015 プロダクション関連のラ ウンドテーブル GDC2016 報告会 「GDC16にみる⾃動化技術とテストのトレンド」 祝・HTTP/3 RFC発⾏(間近)︕
3. © SEGA ゲームコンテンツ＆サービス事業本部 技術本部 開発技術部 ⼭⽥ 英伸 ⾃⼰紹介 【登壇歴】 CEDEC 2020 「技術同⼈作家になろう 〜働き⽅改⾰時代におけるエンジニアのレベルアップの⼀例〜」 Unite Tokyo 2019 「⼤量のアセットも怖くない 〜HTTP/2による⾼速な通信の実装例〜」
4. © SEGA • 本講演内容の撮影、SNS投稿は OK • 後⽇、CEDIL で資料を公開 • 講演中の質疑が可能です。 コメントに書き込んでください • 資料に記載されている会社名、システム名、製品名、サービス名は各社の登録商標または商標です • Android ロボットは、Google が作成および提供している作品から複製または変更したものであり、 クリエイティブ・コモンズ表⽰ 3.0 ライセンスに記載された条件に従って使⽤しています
5. © SEGA • CDN に配置したアセットを端末にダウンロード • HTTP/1.1 と HTTP/2 の差に注⽬ 効果を先にお⾒せします
6. © SEGA • HTTP/2 なら接続数が少なくても、 HTTP/1.1 より圧倒的に早い (待ち時間短縮) HTTP/2による効果 プロトコル 速度 完了までの時間 備考 HTTP/2 約 280 Mbps 約 3.6 s 1 Connection HTTP/1.1 約 110 Mbps 約 9.2 s 6 Connection HTTP/1.1 約 59 Mbps 約 17.2 s 3 Connection 諸条件 Pixel3 (Android10) 使用 AWS CloudFront 使用(国内リージョン) 総数 2000 ファイル / 1ファイル64KB ※ 300-340Mbps が出る回線にて Wi-Fi 接続状態
7. © SEGA • ゲーム開発者向け HTTP/2 仕様の説明 • HTTP/2 を使うための実装について • HTTP/2 導⼊時の勘所 • HTTP/2 トラブル集 • HTTP/2 の採⽤によるインターネット全体への波及効果 • まとめ 本講演の流れ
8. © SEGA ゲーム開発者のための HTTP/2
9. © SEGA • HTTP/2 2015年 標準化完了＆公開 – HTTP/1.1 を基本的に継承 • 現在の普及率 約45.6% (w3techs.com 2021/06時点) ゲーム開発者のための HTTP/2
10. © SEGA • 多重化 • HPACK • バイナリフレーム (ゲームと関連性の深いものに限定) HTTP/2 の仕様
11. © SEGA HTTP/2 多重化
12. © SEGA • 1つのコネクションに複数の HTTP リクエスト 多重化 – HTTP/2 の仕様 GET GET GET APP SRV Connection ストリーム
13. © SEGA • HTTP の Head of Line Blocking:HoLB (HTTP/1.1) – 何らかの要因で先⾏リクエスト処理に時間が掛かると 後続のリクエスト処理が遅れてしまう HTTP/1.1の課題 - 多重化 – HTTP/2 の仕様 1.png 2.png 3.png この分の遅れが後続に響く 1.png
14. © SEGA • HTTP/2 は HTTP の HoLB を回避 – 複数ストリームの多重化により 後続のリクエストを並⾏に処理可能 多重化でHoLB回避 - 多重化 – HTTP/2 の仕様 1.png この分の遅れは 他のリクエストに影響しない 1.png 2.png 3.png
15. © SEGA • HTTP/1.1 と HTTP/2 通信状態の⽐較 帯域の利⽤ - 多重化 – HTTP/2 の仕様 HTTP/1.1 HTTP/2 時間 使⽤可能な 回線帯域 時間 HTTP/1.1 は Keep Alive 有効を想定. 但しファイルサイズが⼩さいと広帯域を活⽤できない.
16. © SEGA • HTTP/2 は使える帯域を有効活⽤ 帯域の利⽤ - 多重化 – HTTP/2 の仕様 HTTP/1.1 HTTP/2 時間 使⽤可能な 回線帯域 時間 帯域を活⽤できていない 多重化で帯域をしっかり活⽤
17. © SEGA l 細かいアセットダウンロードに有効 ü 効率的に回線帯域を使⽤ l クライアント・サーバ間通信 ü RTT による待ち時間削減 (モバイル回線 など) ゲームとの関連 – 多重化 – HTTP/2の仕様 RTT RTT APP SRV SRV APP 1RTT 分で複数リクエスト RTT HTTP/1.1 HTTP/2
18. © SEGA HTTP/2 HPACK
19. © SEGA • HTTP ヘッダを圧縮する仕組み (RFC 7541) • 技術要素 ü Huffman coding ü Indexing Table uStatic Table uDynamic Table HPACK – HTTP/2 の仕様
20. © SEGA • 出現頻度の⾼い⽂字に短いビット列を割当てて圧縮 Huffman coding - HPACK – HTTP/2 の仕様 HTTP/1.1 HTTP/2 10 BYTES から 8 BYTES へ
21. © SEGA • 出現頻度の⾼い⽂字に短いビット列を割当てて圧縮 Huffman coding - HPACK – HTTP/2 の仕様 ※ < > 内はパディング. オクテット境界に揃える
22. © SEGA • 出現頻度の⾼い⽂字に短いビット列を割当てて圧縮 Huffman coding - HPACK – HTTP/2 の仕様 HTTP/1.1 HTTP/2 59 BYTES 48 BYTES ※ 参考値です。実際に送信されるバイト数とは異なります 約 81.4% に削減 HTTP/2 63 BYTES
23. © SEGA • インデックス値を⽤いた圧縮機構 – Static Table – Dynamic Table Indexing Table - HPACK – HTTP/2 の仕様
24. © SEGA • 事前定義されているテーブルのインデックス値を使う Static Table - Indexing Table - HPACK – HTTP/2 の仕様 HTTP/2 ※ 参考値です。実際に送信されるバイト数とは異なります 31 BYTES 63 BYTES 約 49.2% に削減
25. © SEGA • 通信に使⽤したデータをテーブルに登録し、 テーブルのインデックス値を使う Dynamic Table - Indexing Table - HPACK – HTTP/2 の仕様 ※ 参考値です。実際に送信されるバイト数とは異なります 5 BYTES 約 8.4% に削減 テーブルに登録 同内容でリクエスト時
26. © SEGA • フレーム: ストリーム上を流れる最⼩単位 • バイナリデータ送受でテキストより効率が良い バイナリフレーム – HTTP/2の仕様 フレームヘッダは 9Bytes フレームの構造
27. © SEGA • HTTP/1.1 の場合 • テキストベースのプロトコル • 解釈の処理で負荷が⾼め ゲームとの関連 – HPACK/バイナリフレーム HTTP/1.1 200 OK Date: Wed, 30 Jun 2021 02:19:48 GMT Content-Type:image/jpeg Transfer-Encoding: chunked Keep-Alive: timeout=15, max=100 Connection: Keep-Alive 456 Chunk1のデータ .... 0 : の後に空⽩を許可 ヘッダ領域との区切り ヘッダ名は ⼤⽂字⼩⽂字区別なし Chunk終了の CRLF データサイズはまだ不明
28. © SEGA • HPACK, バイナリフレーム ü API 通信のデータ削減・処理負荷軽減 ゲームとの関連 – HPACK/バイナリフレーム HTTP/1.1 200 OK Date: Wed, 30 Jun 2021 02:19:48 GMT Content-Type:image/jpeg Transfer-Encoding: chunked Trailer: Expires Keep-Alive: timeout=15, max=100 Connection: Keep-Alive 456 Chunk1のデータ .... 0 データサイズは先頭 HPACKで圧縮 データサイズは先頭
29. © SEGA • TCP, RUDP を使えば︖ – HTTP/2をトランスポートレイヤーに持つ gRPC や WebSocket – サーバ設定や導⼊コストの圧縮が⾒込める – 対応したサーバレスコンテナの登場 • Cloud Run (Google) 閑話 : API 通信に HTTP を⽤いるメリット
30. © SEGA HTTP/2 を使う実装 Client Server クライアント サーバ
31. © SEGA • ⾃⼒で全て実装は現実的ではない • ゲームエンジンが内蔵しているもの ＆オープンソースの利⽤ HTTP/2 を使う実装 Client
32. © SEGA • C/C++による ⾃社製ゲームエンジンやミドルウェアを利⽤ ü C/C++製の OSS は選択肢が豊富 ü 中でも libcurl, nghttp2 がお勧め ケース１ - HTTP/2 を使う実装 Client
33. © SEGA • Unity を使⽤している場合 ü Unityが採⽤している C#ランタイム/クラスライブラ リでは HTTP/2 が利⽤できない ü 前述のC/C++製OSSを⽤いた ネイティブプラグインを実装 ケース２ - HTTP/2 を使う実装 Client
34. © SEGA • Unreal Engine4 を使⽤している場合 ü Windows で WinHttp 使⽤時のみ HTTP/2 対応 ü C/C++製OSSを⽤いて対処を考える ケース３ - HTTP/2 を使う実装 Client
35. © SEGA • C#による ⾃社ゲームエンジンやミドルウェアを利⽤ ü C# 標準 API (HttpClient) が HTTP/2 対応 • .NET Framework 4.6 • .NET Core は注意. .NET Core 3.0 で対応(*1) ü 但し、パフォーマンスに懸念 ケース４ - HTTP/2 を使う実装 Client *1 : https://docs.microsoft.com/ja-jp/dotnet/core/whats-new/dotnet-core-3-0#http2-support
36. © SEGA • CDN の選定 • サーバソフトウェアの選定 HTTP/2 を使う実装 Server
37. © SEGA • 主要なCDNは全て HTTP/2 対応済み︕ ü CloudFront (Amazon) ü Cloud CDN (Google) ü Azure CDN (Microsoft Azure) ü Fastly (Fastly) ü Akamai CDN (Akamai) ü CloudFlare (CloudFlare) CDNの選定 - HTTP/2 を使う実装 Server
38. © SEGA • サーバソフトウェアの選定 – 主要なサーバプログラムは全て HTTP/2 対応済み︕ • IIS, nginx, apache など – 前段にあるロードバランサに注意 (ADC含む) • HTTP/2を終端する可能性 ソフトウェア選定 - HTTP/2 を使う実装 Server
39. © SEGA HTTP/2 導⼊時の勘所
40. © SEGA • ダウンロードするデータサイズや順序によっては 期待した結果が出ない ü ファイルサイズが⼤きいものが⽀配的な場合 ü ファイルサイズでソートされている場合 パフォーマンスが出ない① Problem!
41. © SEGA • プロジェクトに有効かをまず判断︕ ü ファイルサイズのヒストグラム • ダウンロードリストの作り⽅に⼯夫が必要 パフォーマンスが出ない① Solution! 私たちが遭遇したので、 後で詳しく説明します
42. © SEGA • コネクション数に応じて、 逐次的にリクエスト発⾏をしている場合 – HTTP/1.1 を意識した実装の場合、 3〜6程度でリクエストを送信となることが多い パフォーマンスが出ない② Problem!
43. © SEGA • リクエストを束で受け取る設計 – 多くのリクエストを同時に発⾏する – ライブラリを作るときに意識する パフォーマンスが出ない② Solution!
44. © SEGA • リクエスト数が数万になることも︕ – ファイル保存時、ファイル I/O のコスト – メモリに展開時、メモリ使⽤量が爆発 ⼤量リクエストを捌くために Problem!
45. © SEGA ü ファイル保存時、分散書込みなど、負荷軽減策が必要 ü メモリに展開時、⼀旦ファイルに保存 ü 実装によっては、思わぬボトルネックを⽣むので注意 ⼤量リクエストを捌くために Solution! 私たちが遭遇したので、 後で詳しく説明します
46. © SEGA • HTTP/1.1 時 「コネクションエラー=通信エラー」だったが、 考え⽅を改める必要あり エラーへの考え⽅ Problem!
47. © SEGA • HTTP/2 ストリーム単位でのエラーは 復帰できる可能性がある ü 即、通信エラーにしてはいけない エラーへの考え⽅をアップデート Solution! APP SRV Connection 正常なストリームは通信中
48. © SEGA • 1 Connection内に複数ストリームで通信 – ⾼パケロス環境では 複数Connection HTTP/1.1 より速度が劣ることも パケットロス率に注意 Problem! APP SRV 他のストリームも 再送の影響を受ける パケットロスで 通信エラーが発⽣
49. © SEGA • HTTP/2 を悪環境で利⽤時 ü ⼀定のパケットロス環境では HTTP/1.1 にフォールバックする対策 ü フォールバックする場合の割合は、 各プロジェクトで計測して判断が必要 パケットロス率に注意 Solution!
50. © SEGA • 本番・テストのサーバは対応しているか︖ • サーバ側の HTTP/2 機能を有効にし忘れていないか︖ • このような事態が発⽣すると、 HTTP/2 使っても速くない、と誤解される恐れがある サーバの対応を確認 Problem!
51. © SEGA • HTTP/2 の誤った認識をさせないため ü HTTP/2 通信できているかの チェックツールを⽤意しておくのも良い サーバの対応を確認 Solution!
52. © SEGA • 優先度(プライオリティ)の仕様がある • 各ストリームに重みづけや依存関係を設定し、 先に欲しいリソースをサーバに通知する仕組み HTTP/2 の優先度設定
53. © SEGA • ダウンロードの順序制御に HTTP/2 の優先度制御を使うことはできない – CDN 実装の問題で事実上使えない – HTTP として優先度オプションの協議 – 現状 RFC 策定されていない 優先度制御の課題 Problem!
54. © SEGA • リクエスト順を制御したい場合には、 ⾃前で実装するのが無難 優先度制御 Solution!
55. © SEGA • TLS 1.2 以上が必要 (サーバ) – 仕様上 HTTP/2では TLS1.2 • AWS ロードバランサ – ALB の https 通信で HTTP/2 が使⽤可能 その他
56. © SEGA HTTP/2 トラブル集 C S クライアント事例 サーバ事例
57. © SEGA ダウンロード速度が出ない① C S クライアント事例 サーバ事例
58. © SEGA • 通信速度が⼀定を超えるとそれ以上のダウン ロード速度にならない問題が発⽣ ダウンロード速度が出ない① Problem! C
59. © SEGA • 受信バッファが満タンになった際に待ちが発⽣ ü 送受信処理をメインループに同期させていた為 ダウンロード速度が出ない① Cause C HTTP/2ライブラリ 受信処理 ゲームメインループ 同期 同期 受信バッファ満タン パケット 受け取れないので待つ
60. © SEGA • 受信を別スレッドに分離し、取りこぼしを抑制 ダウンロード速度が出ない① Solution! C HTTP/2ライブラリ 受信処理 ゲームメインループ 取得 パケット 受信バッファ 保存
61. © SEGA ダウンロード速度が出ない② C S クライアント事例 サーバ事例
62. © SEGA • 前項の「通信速度が⼀定を超えるとそれ以上の ダウンロード以上にならない問題」が特定の端 末でのみ再発 ダウンロード速度が出ない② Problem! C
63. © SEGA • 下位グレードの端末で以下の逆転現象が発⽣ ü 通信速度 > ファイルI/O速度 • 特にファイル I/O の回数がボトルネックに ダウンロード速度が出ない② C Cause
64. © SEGA • メモリマネージャの実装により解消 ü ⼀定のサイズまではメモリに書き溜めておく ü 上記サイズを上回った段階でファイルに書き込む • ⼀定のサイズの設定値には注意が必要 ü ⼤き過ぎるとこれまたボトルネックに ダウンロード速度が出ない② Solution! C
65. © SEGA ダウンロード速度が出ない③ C S クライアント事例 サーバ事例
66. © SEGA • 特定のタイトルでダウンロード速度が安定しな い問題が発⽣ ダウンロード速度が出ない③ Problem! C S
67. © SEGA • 帯域を使い切ることができないケースがある ü リスト上に⼩さいファイルが固まっている時 ダウンロード速度が出ない③ C Cause 使⽤可能な回線帯域 ここが使えていない︕
68. © SEGA • ダウンロードリストの作り⽅を⼯夫する ü ランダムに⼊れ替えるだけでも効果あり ダウンロード速度が出ない③ ここの部分を使えるようになった Solution! C
69. © SEGA • ソートしてもダメなケース ダウンロード速度が出ない③ C Cause 使⽤可能な回線帯域 (⾼速) 帯域次第で使い切れないケースが発⽣
70. © SEGA • ファイルの同時ダウンロード数はサーバ固有 ü HTTP/2的にはストリーム最⼤数と表現 ü RFC的にはMAX_CONCURRENT_STREAMS • クライアントとサーバで別 ü お互い⾃分の受付可能なストリーム最⼤数を送り合う ダウンロード速度が出ない③ C S Cause
71. © SEGA • コネクション数を増やすことにより解決 ü 使⽤していたCDNのストリーム最⼤数が変更不可 • 最⼤3コネクションまで張る仕様とした ü 300〜400ストリームで安定感のある速度になった ü 例 : 200Mbps ÷ 384 (stream) → 65kb (1filesize) ダウンロード速度が出ない③ Solution! C
72. © SEGA 主要なCDNのストリーム最⼤数 ダウンロード速度が出ない③ Appendix S Amazon CloudFront 128 Azure CDN 100 Google Cloud CDN 100 akamai 128 Fastly 100 Cloudflare 256 実測値 + 一部 https://netsec.ccert.edu.cn/files/papers/ndss-2020-cdn-judo.pdf を参考
73. © SEGA • .Net 6のHTTP/2の機能でも同様の議論有り ü ストリームが上限に達したらコネクションを追加する ü https://github.com/dotnet/runtime/issues/35088.Net ダウンロード速度が出ない③ Appendix C
74. © SEGA ダウンロード速度が出ない④ C S クライアント事例 サーバ事例
75. © SEGA • 特定のタイトルでのみダウンロード速度が極端 に低下する問題が発⽣ ダウンロード速度が出ない④ Problem! C
76. © SEGA • ファイル処理負荷が⾼い構成だった ü 1ディレクトリ下に⼤量のファイルを保存 ü ハッシュ化した⻑めのファイル名を使⽤ ダウンロード速度が出ない④ C Cause
77. © SEGA • ⼀時ファイルの処理を変更して回避 ü 専⽤のディレクトリを⽤意 ü 短いファイル名(内部的なリクエスト番号) ダウンロード速度が出ない④ Solution! C
78. © SEGA 速度出ない問題との闘いに終⽌符
79. © SEGA ダウンロード速度が出すぎた C S クライアント事例 サーバ事例
80. © SEGA • とあるタイトルの⼤型アップデート時に、CDN のデータ転送レート設定上限値を超える通信量 が発⽣することが判明した ダウンロード速度が出すぎた Problem! C S
81. © SEGA • CDNによってはデータ転送レートに制限が掛 かっていることがある • Amazon CloudFrontの旧制限は40Gbps (※) ü 200Mbps出る端末の同時ダウンロード可能数 Ø 40Gbps ÷ 200Mbps = 200 (端末) ダウンロード速度が出すぎた S Cause ※2020/5/20に150Gbpsに更新された
82. © SEGA • 混雑時間帯のみHTTP/1.1へダウングレード • お⾦で解決するのも⼿ ü 制限があるCDNも転送レート上限の引き上げが可能 な所がほとんど • CDN選定条件にデータ転送レートも考慮しよう ダウンロード速度が出すぎた Solution! C
83. © SEGA ファイルオープンエラー発⽣ C S クライアント事例 サーバ事例
84. © SEGA • タイトル側でファイル上限エラーが発⽣ • HTTP/2ライブラリは以下の80%を上限に使⽤ ü Windows (VCRUNTIME) : _getmaxstdio ü Android/iOS : /proc/self/limits ファイルオープンエラー発⽣ Problem! C
85. © SEGA • iOS11でファイルオープン上限数が256に • 結果、タイトル側でファイルリソースが枯渇 ü 256 * 0.2 = 51 ファイル ファイルオープンエラー発⽣ C Cause
86. © SEGA • 上限数の変更を⾏う実装に修正 ü setrlimit/getrlimitを使⽤ • タイトルのファイル使⽤上限を受け取るように ü setrlimit/getrlimitが効かない端末対策 • ファイルオープン数の削減 ü オープンタイミングの⾒直し ファイルオープンエラー発⽣ Solution! C
87. © SEGA ファイルのrenameに失敗 C S クライアント事例 サーバ事例
88. © SEGA • 特定の端末でのみダウンロード完了後のファイ ルのrenameに失敗する問題が発⽣ ファイルのrenameに失敗 Problem! C
89. © SEGA • Android11からExternalStorage境界をまたぐ rename(POSIX)呼び出しが禁⽌ ü Javaはコピー&削除にフォールバックされる • 以下の境界をまたぐとNG ü PublicDirectory(Download), Cache, Files, Files(Download), Media ファイルのrenameに失敗 C Cause
90. © SEGA • Android11でも必ず再現する訳ではない • sdcardfs採⽤のカーネルでは発⽣しない ü cat /proc/filesystems の結果にsdcardfsがあれば発 ⽣しない ファイルのrenameに失敗 C Cause
91. © SEGA • ファイルのrenameが失敗する端末ではコピー& 削除にフォールバック • renameに⽐べパフォーマンスペナルティあり ü ExternalStorageの境界を跨がない設計をお勧め ファイルのrenameに失敗 Solution! C S
92. © SEGA タイムアウトしない C S クライアント事例 サーバ事例
93. © SEGA • データを全くダウンロードできないにも関わら ず、タイムアウトが発⽣しない問題が発⽣ タイムアウトしない Problem! C S
94. © SEGA • HTTP/2特有のコネクションクローズ問題 ü コネクション切断時に送信されるGOAWAYフレーム がロストしたことが原因と推測 • 複数のストリームが⾮同期に絡むのでHTTP/2の コネクションクローズの実装は複雑となりがち タイムアウトしない C S Cause
95. © SEGA • 独⾃のタイムアウト処理を追加した ü タイムアウト判定時にはハンドシェイクからやり直し • graceful shutdownに対応したサーバやライブ ラリを使っていれば不要 ü サーバ側が担保できなかったので独⾃に実装 タイムアウトしない Solution! C S
96. © SEGA iPhoneで通信中に不正終了 C S クライアント事例 サーバ事例
97. © SEGA • ダウンロード中に極稀に不正終了が発⽣ ü 検証環境では7万回に⼀回程度発⽣ iPhoneで通信中に不正終了 Problem! C
98. © SEGA • 利⽤しているOSSの不具合だった ü HTTP/2のconnection reuse発⽣時に加えていくつか の条件を満たした時のみ発⽣ ü 数千〜数万ファイルを⼀気にダウンロードするのは ゲームくらいなのでレアなものを踏む iPhoneで通信中に不正終了 C Cause
99. © SEGA • その後OSSの更新で無事に修正された • HTTP/2のゲーム活⽤も枯れてきている ü 他社の⼤型タイトルでも採⽤が増えてきた iPhoneで通信中に不正終了 Solution! C
100. © SEGA HTTP/2独⾃の設定をしたい C S クライアント事例 サーバ事例
101. © SEGA • 5G時代に備え、もっと速度を……︕ ü HTTP/2独⾃の設定をカスタマイズすればいけそう︖ • 設定例 ü HPACK Dynamic Table設定 ü ストリームの初期ウィンドウサイズ HTTP/2独⾃の設定をしたい Problem! C S
102. © SEGA • 諦めた ü 利⽤しているOSSは設定を内部パラメータとして隠蔽 ü CDNも設定できない場合が多い • OSS選定のタイミングで考慮しておこう HTTP/2独⾃の設定をしたい Solution! C S
103. © SEGA インターネット全体への波及効果
104. © SEGA インターネット全体への波及効果 コネクション数削減による効果
105. © SEGA ゲームはコネクションを多数⽤いる アセットダウンロード ランキング ゲーム通信 チャット
106. © SEGA • コネクション数の増加はそのままインターネッ ト上に存在する中継器の負荷増⼤に繋がる コネクション数による負荷増⼤
107. © SEGA • ⽇本をはじめ全世界に余裕がない状態 インターネットは社会全体の資源 総務省 :我が国のインターネットにおけるトラヒックの集計・試算 2020年11⽉分の集計結果 より
108. © SEGA • HTTP/2であれば従来に⽐べてコネクション数を ⼤幅に削減可能 ü 多重化 ü コネクションの再利⽤ HTTP/2によるコネクション数削減
109. © SEGA • Webブラウザや動画ストリーミングサービス等 の⾮ゲーム分野ではコネクション数は減少傾向 ⾮ゲーム分野では既に導⼊が進んでいる Web Almanac 2020 HTTP/2 - HTTP/2のインパクト より
110. © SEGA HTTP/2のゲームへの導⼊のメリット 開発者 ユーザ体験の向上(離脱率低下) ユーザ ダウンロード待ち短縮 インターネット 負荷軽減
111. © SEGA コネクション数削減による効果 HTTP/2を使って 開発者、ユーザ、インターネット に優しいゲーム作りを⽬指そう︕︕
112. © SEGA インターネット全体への波及効果 ゲームのデータ配信とトラフィック
113. © SEGA • AAAタイトルの発売⽇や⼤型アップデートの⽇ にインターネットトラフィックが⾮常に混雑す るというのが最近問題になっている ü CEDEC 2020 [JANOG×CEDECコラボセッション] インターネットとゲームトラフィック でも話題に ゲームのデータ配信の影響
114. © SEGA • ゲーム業界はインターネットを使わせてもらっ ている⽴場 ü 少しでもインフラへの負荷を減らすべき • 必要になったタイミングで都度ダウンロード ü モバイルゲームでは採⽤しているタイトルも多い ü ⾮モバイルゲームは⼤型パッチが主流 データ配信⽅式の転換の提案
115. © SEGA • ゲームの適正とよく相談する必要はある ü ジャンル ü プラットフォーム • 採⽤メリットも ü 従来に⽐べ管理や差し替えが容易になる パッチ配信とトラフィック
116. © SEGA まとめ
117. © SEGA • HTTP/2はアセットダウンロードに効果⼤ • HTTP/2はクライアントサーバ間の通信の効率 化にも効果⼤ • HTTP/2はインターネットにも優しい HTTP/2を使おう︕︕
118. © SEGA ご清聴ありがとうございました