SlideShare a Scribd company logo

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

S
S

CEDEC 2021 の講演資料です。 ノートに講演で話した内容をそのまま記載ありますので、 講演内容を完全に把握したい方はダウンロードしての閲覧をお勧めします。 株式会社セガ 開発技術部 山田英伸/竹原涼

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

1 of 118
ダウンロード時間を大幅減!
~大量のアセットをさばく高速な実装と運用事例の共有~
© SEGA
ゲームコンテンツ&サービス事業本部 技術本部 開発技術部
竹原 涼
自己紹介
【登壇歴】
CEDEC 2020 「技術同人作家になろう ~働き方改革時代におけるエン
ジニアのレベルアップの一例~」
Unite Tokyo 2019 「大量のアセットも怖くない!~HTTP/2による高
速な通信の実装例~」
CEDEC 2018、CEDEC 2016、CEDEC 2015 プロダクション関連のラ
ウンドテーブル
GDC2016 報告会 「GDC16にみる自動化技術とテストのトレンド」
祝・HTTP/3 RFC発行(間近)!
© SEGA
ゲームコンテンツ&サービス事業本部 技術本部 開発技術部
山田 英伸
自己紹介
【登壇歴】
CEDEC 2020
「技術同人作家になろう
~働き方改革時代におけるエンジニアのレベルアップの一例~」
Unite Tokyo 2019
「大量のアセットも怖くない
~HTTP/2による高速な通信の実装例~」
© SEGA
• 本講演内容の撮影、SNS投稿は OK
• 後日、CEDIL で資料を公開
• 講演中の質疑が可能です。
コメントに書き込んでください
• 資料に記載されている会社名、システム名、製品名、サービス名は各社の登録商標または
商標です
• Android ロボットは、Google が作成および提供している作品から複製または変更したもの
であり、
クリエイティブ・コモンズ表示 3.0 ライセンスに記載された条件に従って使用しています
© SEGA
• CDN に配置したアセットを端末にダウンロード
• HTTP/1.1 と HTTP/2 の差に注目
効果を先にお見せします
© 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 接続状態
Ad

Recommended

新入社員のための大規模ゲーム開発入門 サーバサイド編
新入社員のための大規模ゲーム開発入門 サーバサイド編新入社員のための大規模ゲーム開発入門 サーバサイド編
新入社員のための大規模ゲーム開発入門 サーバサイド編infinite_loop
 
PHPからgoへの移行で分かったこと
PHPからgoへの移行で分かったことPHPからgoへの移行で分かったこと
PHPからgoへの移行で分かったことgree_tech
 
オンラインゲームの仕組みと工夫
オンラインゲームの仕組みと工夫オンラインゲームの仕組みと工夫
オンラインゲームの仕組みと工夫Yuta Imai
 
CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する
CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭するCEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する
CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭するYoshifumi Kawai
 
DeNAの最新のマスタデータ管理システム Oyakata の全容
DeNAの最新のマスタデータ管理システム Oyakata の全容DeNAの最新のマスタデータ管理システム Oyakata の全容
DeNAの最新のマスタデータ管理システム Oyakata の全容sairoutine
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話Kumazaki Hiroki
 
【Unite Tokyo 2019】大量のアセットも怖くない!~HTTP/2による高速な通信の実装例~
【Unite Tokyo 2019】大量のアセットも怖くない!~HTTP/2による高速な通信の実装例~【Unite Tokyo 2019】大量のアセットも怖くない!~HTTP/2による高速な通信の実装例~
【Unite Tokyo 2019】大量のアセットも怖くない!~HTTP/2による高速な通信の実装例~UnityTechnologiesJapan002
 
CEDEC2019 大規模モバイルゲーム運用におけるマスタデータ管理事例
CEDEC2019 大規模モバイルゲーム運用におけるマスタデータ管理事例CEDEC2019 大規模モバイルゲーム運用におけるマスタデータ管理事例
CEDEC2019 大規模モバイルゲーム運用におけるマスタデータ管理事例sairoutine
 

More Related Content

What's hot

Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターンFluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターンKentaro Yoshida
 
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織Takafumi ONAKA
 
分散システムについて語らせてくれ
分散システムについて語らせてくれ分散システムについて語らせてくれ
分散システムについて語らせてくれKumazaki Hiroki
 
Building the Game Server both API and Realtime via c#
Building the Game Server both API and Realtime via c#Building the Game Server both API and Realtime via c#
Building the Game Server both API and Realtime via c#Yoshifumi Kawai
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Kohei Tokunaga
 
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計Yoshinori Matsunobu
 
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかシリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかAtsushi Nakada
 
FINAL FANTASY XVにおけるPhoton利用事例 - Photon運営事務局 GTMF 2018 OSAKA / TOKYO
FINAL FANTASY XVにおけるPhoton利用事例 - Photon運営事務局 GTMF 2018 OSAKA / TOKYOFINAL FANTASY XVにおけるPhoton利用事例 - Photon運営事務局 GTMF 2018 OSAKA / TOKYO
FINAL FANTASY XVにおけるPhoton利用事例 - Photon運営事務局 GTMF 2018 OSAKA / TOKYOGame Tools & Middleware Forum
 
イベント・ソーシングを知る
イベント・ソーシングを知るイベント・ソーシングを知る
イベント・ソーシングを知るShuhei Fujita
 
JIRA / Confluence の 必須プラグインはこれだ
JIRA / Confluence の必須プラグインはこれだJIRA / Confluence の必須プラグインはこれだ
JIRA / Confluence の 必須プラグインはこれだNarichika Kajihara
 
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャーKubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャーToru Makabe
 
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021Preferred Networks
 
がんばらなくても C# で Single Page Web アプリケーションが書けてしまう「Blazor」とは
がんばらなくても C# で Single Page Web アプリケーションが書けてしまう「Blazor」とはがんばらなくても C# で Single Page Web アプリケーションが書けてしまう「Blazor」とは
がんばらなくても C# で Single Page Web アプリケーションが書けてしまう「Blazor」とはJun-ichi Sakamoto
 
リアルタイムサーバー 〜Erlang/OTPで作るPubSubサーバー〜
リアルタイムサーバー 〜Erlang/OTPで作るPubSubサーバー〜 リアルタイムサーバー 〜Erlang/OTPで作るPubSubサーバー〜
リアルタイムサーバー 〜Erlang/OTPで作るPubSubサーバー〜 Yugo Shimizu
 
ネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分けネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分けモノビット エンジン
 
ゲームエンジニアのためのデータベース設計
ゲームエンジニアのためのデータベース設計ゲームエンジニアのためのデータベース設計
ゲームエンジニアのためのデータベース設計sairoutine
 
WebSocketのキホン
WebSocketのキホンWebSocketのキホン
WebSocketのキホンYou_Kinjoh
 
【Unite Tokyo 2019】Understanding C# Struct All Things
【Unite Tokyo 2019】Understanding C# Struct All Things【Unite Tokyo 2019】Understanding C# Struct All Things
【Unite Tokyo 2019】Understanding C# Struct All ThingsUnityTechnologiesJapan002
 
テスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるなテスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるなKentaro Matsui
 

What's hot (20)

Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターンFluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターン
 
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
 
分散システムについて語らせてくれ
分散システムについて語らせてくれ分散システムについて語らせてくれ
分散システムについて語らせてくれ
 
Building the Game Server both API and Realtime via c#
Building the Game Server both API and Realtime via c#Building the Game Server both API and Realtime via c#
Building the Game Server both API and Realtime via c#
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
 
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計
 
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかシリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
 
FINAL FANTASY XVにおけるPhoton利用事例 - Photon運営事務局 GTMF 2018 OSAKA / TOKYO
FINAL FANTASY XVにおけるPhoton利用事例 - Photon運営事務局 GTMF 2018 OSAKA / TOKYOFINAL FANTASY XVにおけるPhoton利用事例 - Photon運営事務局 GTMF 2018 OSAKA / TOKYO
FINAL FANTASY XVにおけるPhoton利用事例 - Photon運営事務局 GTMF 2018 OSAKA / TOKYO
 
イベント・ソーシングを知る
イベント・ソーシングを知るイベント・ソーシングを知る
イベント・ソーシングを知る
 
JIRA / Confluence の 必須プラグインはこれだ
JIRA / Confluence の必須プラグインはこれだJIRA / Confluence の必須プラグインはこれだ
JIRA / Confluence の 必須プラグインはこれだ
 
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャーKubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
 
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
 
がんばらなくても C# で Single Page Web アプリケーションが書けてしまう「Blazor」とは
がんばらなくても C# で Single Page Web アプリケーションが書けてしまう「Blazor」とはがんばらなくても C# で Single Page Web アプリケーションが書けてしまう「Blazor」とは
がんばらなくても C# で Single Page Web アプリケーションが書けてしまう「Blazor」とは
 
リアルタイムサーバー 〜Erlang/OTPで作るPubSubサーバー〜
リアルタイムサーバー 〜Erlang/OTPで作るPubSubサーバー〜 リアルタイムサーバー 〜Erlang/OTPで作るPubSubサーバー〜
リアルタイムサーバー 〜Erlang/OTPで作るPubSubサーバー〜
 
ネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分けネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分け
 
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajpAt least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
 
ゲームエンジニアのためのデータベース設計
ゲームエンジニアのためのデータベース設計ゲームエンジニアのためのデータベース設計
ゲームエンジニアのためのデータベース設計
 
WebSocketのキホン
WebSocketのキホンWebSocketのキホン
WebSocketのキホン
 
【Unite Tokyo 2019】Understanding C# Struct All Things
【Unite Tokyo 2019】Understanding C# Struct All Things【Unite Tokyo 2019】Understanding C# Struct All Things
【Unite Tokyo 2019】Understanding C# Struct All Things
 
テスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるなテスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるな
 

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

H2O - making HTTP better
H2O - making HTTP betterH2O - making HTTP better
H2O - making HTTP betterKazuho Oku
 
WebSocket Protocol と Plack::Middleware::WebSocket
WebSocket Protocol と Plack::Middleware::WebSocketWebSocket Protocol と Plack::Middleware::WebSocket
WebSocket Protocol と Plack::Middleware::WebSocketYu Nobuoka
 
性能問題を起こしにくい 強いDBシステムの作り方(Ver. 2018.9)
性能問題を起こしにくい 強いDBシステムの作り方(Ver. 2018.9)性能問題を起こしにくい 強いDBシステムの作り方(Ver. 2018.9)
性能問題を起こしにくい 強いDBシステムの作り方(Ver. 2018.9)Tomoyuki Oota
 
FPGAによる大規模データ処理の高速化
FPGAによる大規模データ処理の高速化FPGAによる大規模データ処理の高速化
FPGAによる大規模データ処理の高速化Kazunori Sato
 
【17-A-5】ウェブアーキテクチャの歴史と未来
【17-A-5】ウェブアーキテクチャの歴史と未来【17-A-5】ウェブアーキテクチャの歴史と未来
【17-A-5】ウェブアーキテクチャの歴史と未来Developers Summit
 
Atc15_reading_networking_session
Atc15_reading_networking_sessionAtc15_reading_networking_session
Atc15_reading_networking_session紘也 金子
 
[D20] 高速Software Switch/Router 開発から得られた高性能ソフトウェアルータ・スイッチ活用の知見 (July Tech Fest...
[D20] 高速Software Switch/Router 開発から得られた高性能ソフトウェアルータ・スイッチ活用の知見 (July Tech Fest...[D20] 高速Software Switch/Router 開発から得られた高性能ソフトウェアルータ・スイッチ活用の知見 (July Tech Fest...
[D20] 高速Software Switch/Router 開発から得られた高性能ソフトウェアルータ・スイッチ活用の知見 (July Tech Fest...Tomoya Hibi
 
The road of Apache CloudStack Contributor (Translation and Patch)
The road of Apache CloudStack Contributor (Translation and Patch)The road of Apache CloudStack Contributor (Translation and Patch)
The road of Apache CloudStack Contributor (Translation and Patch)Kimihiko Kitase
 
Performance and Scalability of Web Service
Performance and Scalability of Web ServicePerformance and Scalability of Web Service
Performance and Scalability of Web ServiceShinji Tanaka
 
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例terurou
 
ABEMA を次のフェーズへ進化させる技術への取り組み
ABEMA を次のフェーズへ進化させる技術への取り組みABEMA を次のフェーズへ進化させる技術への取り組み
ABEMA を次のフェーズへ進化させる技術への取り組みYusuke Goto
 
[db tech showcase Tokyo 2015] D16:マイケルストーンブレーカー発の超高速データベースで実現する分析基盤の簡単構築・運用ステ...
[db tech showcase Tokyo 2015] D16:マイケルストーンブレーカー発の超高速データベースで実現する分析基盤の簡単構築・運用ステ...[db tech showcase Tokyo 2015] D16:マイケルストーンブレーカー発の超高速データベースで実現する分析基盤の簡単構築・運用ステ...
[db tech showcase Tokyo 2015] D16:マイケルストーンブレーカー発の超高速データベースで実現する分析基盤の簡単構築・運用ステ...Insight Technology, Inc.
 
db tech showcase_2014_A14_Actian Vectorで得られる、BIにおける真のパフォーマンスとは
db tech showcase_2014_A14_Actian Vectorで得られる、BIにおける真のパフォーマンスとはdb tech showcase_2014_A14_Actian Vectorで得られる、BIにおける真のパフォーマンスとは
db tech showcase_2014_A14_Actian Vectorで得られる、BIにおける真のパフォーマンスとはKoji Shinkubo
 
Gmo media.inc 第9回西日本ossの普及を考える会
Gmo media.inc 第9回西日本ossの普及を考える会Gmo media.inc 第9回西日本ossの普及を考える会
Gmo media.inc 第9回西日本ossの普及を考える会Dai Utsui
 
HTTP/2時代のウェブサイト設計
HTTP/2時代のウェブサイト設計HTTP/2時代のウェブサイト設計
HTTP/2時代のウェブサイト設計Kazuho Oku
 
HTTPとサーバ技術の最新動向
HTTPとサーバ技術の最新動向HTTPとサーバ技術の最新動向
HTTPとサーバ技術の最新動向Kazuho Oku
 
ウェブアーキテクチャの歴史と未来
ウェブアーキテクチャの歴史と未来ウェブアーキテクチャの歴史と未来
ウェブアーキテクチャの歴史と未来Kazuho Oku
 

Similar to CEDEC2021 ダウンロード時間を大幅減!~大量のアセットをさばく高速な実装と運用事例の共有~ (20)

H2O - making HTTP better
H2O - making HTTP betterH2O - making HTTP better
H2O - making HTTP better
 
WebSocket Protocol と Plack::Middleware::WebSocket
WebSocket Protocol と Plack::Middleware::WebSocketWebSocket Protocol と Plack::Middleware::WebSocket
WebSocket Protocol と Plack::Middleware::WebSocket
 
性能問題を起こしにくい 強いDBシステムの作り方(Ver. 2018.9)
性能問題を起こしにくい 強いDBシステムの作り方(Ver. 2018.9)性能問題を起こしにくい 強いDBシステムの作り方(Ver. 2018.9)
性能問題を起こしにくい 強いDBシステムの作り方(Ver. 2018.9)
 
Spark SQL - The internal -
Spark SQL - The internal -Spark SQL - The internal -
Spark SQL - The internal -
 
FPGAによる大規模データ処理の高速化
FPGAによる大規模データ処理の高速化FPGAによる大規模データ処理の高速化
FPGAによる大規模データ処理の高速化
 
【17-A-5】ウェブアーキテクチャの歴史と未来
【17-A-5】ウェブアーキテクチャの歴史と未来【17-A-5】ウェブアーキテクチャの歴史と未来
【17-A-5】ウェブアーキテクチャの歴史と未来
 
SAIS/SIGMOD参加報告 in SAIS/DWS2018報告会@Yahoo! JAPAN
SAIS/SIGMOD参加報告 in SAIS/DWS2018報告会@Yahoo! JAPANSAIS/SIGMOD参加報告 in SAIS/DWS2018報告会@Yahoo! JAPAN
SAIS/SIGMOD参加報告 in SAIS/DWS2018報告会@Yahoo! JAPAN
 
Atc15_reading_networking_session
Atc15_reading_networking_sessionAtc15_reading_networking_session
Atc15_reading_networking_session
 
[D20] 高速Software Switch/Router 開発から得られた高性能ソフトウェアルータ・スイッチ活用の知見 (July Tech Fest...
[D20] 高速Software Switch/Router 開発から得られた高性能ソフトウェアルータ・スイッチ活用の知見 (July Tech Fest...[D20] 高速Software Switch/Router 開発から得られた高性能ソフトウェアルータ・スイッチ活用の知見 (July Tech Fest...
[D20] 高速Software Switch/Router 開発から得られた高性能ソフトウェアルータ・スイッチ活用の知見 (July Tech Fest...
 
The road of Apache CloudStack Contributor (Translation and Patch)
The road of Apache CloudStack Contributor (Translation and Patch)The road of Apache CloudStack Contributor (Translation and Patch)
The road of Apache CloudStack Contributor (Translation and Patch)
 
Performance and Scalability of Web Service
Performance and Scalability of Web ServicePerformance and Scalability of Web Service
Performance and Scalability of Web Service
 
Exadata with persistent memory an epic journey jp
Exadata with persistent memory  an epic journey jpExadata with persistent memory  an epic journey jp
Exadata with persistent memory an epic journey jp
 
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
 
ABEMA を次のフェーズへ進化させる技術への取り組み
ABEMA を次のフェーズへ進化させる技術への取り組みABEMA を次のフェーズへ進化させる技術への取り組み
ABEMA を次のフェーズへ進化させる技術への取り組み
 
[db tech showcase Tokyo 2015] D16:マイケルストーンブレーカー発の超高速データベースで実現する分析基盤の簡単構築・運用ステ...
[db tech showcase Tokyo 2015] D16:マイケルストーンブレーカー発の超高速データベースで実現する分析基盤の簡単構築・運用ステ...[db tech showcase Tokyo 2015] D16:マイケルストーンブレーカー発の超高速データベースで実現する分析基盤の簡単構築・運用ステ...
[db tech showcase Tokyo 2015] D16:マイケルストーンブレーカー発の超高速データベースで実現する分析基盤の簡単構築・運用ステ...
 
db tech showcase_2014_A14_Actian Vectorで得られる、BIにおける真のパフォーマンスとは
db tech showcase_2014_A14_Actian Vectorで得られる、BIにおける真のパフォーマンスとはdb tech showcase_2014_A14_Actian Vectorで得られる、BIにおける真のパフォーマンスとは
db tech showcase_2014_A14_Actian Vectorで得られる、BIにおける真のパフォーマンスとは
 
Gmo media.inc 第9回西日本ossの普及を考える会
Gmo media.inc 第9回西日本ossの普及を考える会Gmo media.inc 第9回西日本ossの普及を考える会
Gmo media.inc 第9回西日本ossの普及を考える会
 
HTTP/2時代のウェブサイト設計
HTTP/2時代のウェブサイト設計HTTP/2時代のウェブサイト設計
HTTP/2時代のウェブサイト設計
 
HTTPとサーバ技術の最新動向
HTTPとサーバ技術の最新動向HTTPとサーバ技術の最新動向
HTTPとサーバ技術の最新動向
 
ウェブアーキテクチャの歴史と未来
ウェブアーキテクチャの歴史と未来ウェブアーキテクチャの歴史と未来
ウェブアーキテクチャの歴史と未来
 

More from SEGADevTech

開発もQAも自動テスト!「LOST JUDGMENT:裁かれざる記憶」のQAテスター参加で進化した「テスト自動化チーム(仮)」の取り組みについて
開発もQAも自動テスト!「LOST JUDGMENT:裁かれざる記憶」のQAテスター参加で進化した「テスト自動化チーム(仮)」の取り組みについて開発もQAも自動テスト!「LOST JUDGMENT:裁かれざる記憶」のQAテスター参加で進化した「テスト自動化チーム(仮)」の取り組みについて
開発もQAも自動テスト!「LOST JUDGMENT:裁かれざる記憶」のQAテスター参加で進化した「テスト自動化チーム(仮)」の取り組みについてSEGADevTech
 
CEDEC2021 プランナーもハックしよう 業務効率化、ローコード開発とテクニカルプランナー
CEDEC2021 プランナーもハックしよう 業務効率化、ローコード開発とテクニカルプランナーCEDEC2021 プランナーもハックしよう 業務効率化、ローコード開発とテクニカルプランナー
CEDEC2021 プランナーもハックしよう 業務効率化、ローコード開発とテクニカルプランナーSEGADevTech
 
CEDEC2021 Android iOS 実機上での自動テストをより楽に有意義にする為に ~端末管理・イメージ転送・動画記録等の周辺情報のノウハウ共有~
CEDEC2021 Android iOS 実機上での自動テストをより楽に有意義にする為に ~端末管理・イメージ転送・動画記録等の周辺情報のノウハウ共有~CEDEC2021 Android iOS 実機上での自動テストをより楽に有意義にする為に ~端末管理・イメージ転送・動画記録等の周辺情報のノウハウ共有~
CEDEC2021 Android iOS 実機上での自動テストをより楽に有意義にする為に ~端末管理・イメージ転送・動画記録等の周辺情報のノウハウ共有~SEGADevTech
 
基礎線形代数講座
基礎線形代数講座基礎線形代数講座
基礎線形代数講座SEGADevTech
 
「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム
「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム
「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステムSEGADevTech
 
「龍が如く7 光と闇の行方」の自動テスト活用事例とテスト自動化チーム(仮)による若手育成の取り組みについて
「龍が如く7 光と闇の行方」の自動テスト活用事例とテスト自動化チーム(仮)による若手育成の取り組みについて「龍が如く7 光と闇の行方」の自動テスト活用事例とテスト自動化チーム(仮)による若手育成の取り組みについて
「龍が如く7 光と闇の行方」の自動テスト活用事例とテスト自動化チーム(仮)による若手育成の取り組みについてSEGADevTech
 
Jenkinsの構成・運用パターン
Jenkinsの構成・運用パターンJenkinsの構成・運用パターン
Jenkinsの構成・運用パターンSEGADevTech
 

More from SEGADevTech (7)

開発もQAも自動テスト!「LOST JUDGMENT:裁かれざる記憶」のQAテスター参加で進化した「テスト自動化チーム(仮)」の取り組みについて
開発もQAも自動テスト!「LOST JUDGMENT:裁かれざる記憶」のQAテスター参加で進化した「テスト自動化チーム(仮)」の取り組みについて開発もQAも自動テスト!「LOST JUDGMENT:裁かれざる記憶」のQAテスター参加で進化した「テスト自動化チーム(仮)」の取り組みについて
開発もQAも自動テスト!「LOST JUDGMENT:裁かれざる記憶」のQAテスター参加で進化した「テスト自動化チーム(仮)」の取り組みについて
 
CEDEC2021 プランナーもハックしよう 業務効率化、ローコード開発とテクニカルプランナー
CEDEC2021 プランナーもハックしよう 業務効率化、ローコード開発とテクニカルプランナーCEDEC2021 プランナーもハックしよう 業務効率化、ローコード開発とテクニカルプランナー
CEDEC2021 プランナーもハックしよう 業務効率化、ローコード開発とテクニカルプランナー
 
CEDEC2021 Android iOS 実機上での自動テストをより楽に有意義にする為に ~端末管理・イメージ転送・動画記録等の周辺情報のノウハウ共有~
CEDEC2021 Android iOS 実機上での自動テストをより楽に有意義にする為に ~端末管理・イメージ転送・動画記録等の周辺情報のノウハウ共有~CEDEC2021 Android iOS 実機上での自動テストをより楽に有意義にする為に ~端末管理・イメージ転送・動画記録等の周辺情報のノウハウ共有~
CEDEC2021 Android iOS 実機上での自動テストをより楽に有意義にする為に ~端末管理・イメージ転送・動画記録等の周辺情報のノウハウ共有~
 
基礎線形代数講座
基礎線形代数講座基礎線形代数講座
基礎線形代数講座
 
「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム
「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム
「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム
 
「龍が如く7 光と闇の行方」の自動テスト活用事例とテスト自動化チーム(仮)による若手育成の取り組みについて
「龍が如く7 光と闇の行方」の自動テスト活用事例とテスト自動化チーム(仮)による若手育成の取り組みについて「龍が如く7 光と闇の行方」の自動テスト活用事例とテスト自動化チーム(仮)による若手育成の取り組みについて
「龍が如く7 光と闇の行方」の自動テスト活用事例とテスト自動化チーム(仮)による若手育成の取り組みについて
 
Jenkinsの構成・運用パターン
Jenkinsの構成・運用パターンJenkinsの構成・運用パターン
Jenkinsの構成・運用パターン
 

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

Editor's Notes

  1. それでは ダウンロード時間を大幅減!~大量のアセットをさばく高速な実装と運用事例の共有~ というタイトルで、株式会社セガの私竹原と山田さんの2人で講演を始めてさせて頂きます
  2. まずは軽く自己紹介をさせて頂きます セガ開発技術部の竹原と申します 自動化やツール、ネットワークまわりが主戦場で、最近ではサウンドにも手を出し始めました、よろしくお願いします 自己紹介ついでに一言コメントということで、 祝 HTTP/3 RFC 発行! 昨日の Fastly の奥さん講演を聞いた方も多いと思いますが、ついにHTTP/2の次期規格であるHTTP/3の標準化が完了しようとしています 今回共有するHTTP/2のノウハウの多くはHTTP/3でも活用できるものだったりしますので、HTTP/3に備える意味でも是非当講演を聞いていって頂けると嬉しく思います さて、私は後半パートの担当ですので、ここからは山田さんにバトンタッチします。また後程お会いしましょう
  3. 私は開発技術部に所属している山田と申します。 普段は開発者向けツール作成やグラフィックスAPIサポート、ネットワーク関連など色々と幅広くやっております。 最近の趣味は技術同人誌で幅広く情報を集めることです。 技術同人誌は比較的ページ数が多く、割と積みあがってきました。PDFで配布される電子版も多いので、この写真に一緒に積みあがった様子を映すことはできませんでした。 私は前半を担当し、主にHTTP/2 ついてお話します。
  4. 早速ですが、HTTP/2を使ってファイルのダウンロードがどのくらい早くなるのか、というのを見てもらおうと思います。 計測の環境としては、CDNに配置したデータをHTTP 1.1 と HTTP2 でそれぞれダウンロードし、完了までの時間を計測しました。 それでは、ダウンロード時間計測の様子をみてみましょう。 アセットの数 2000 ファイル1つあたり 64KB 計測したのは Android の Pixel3 です。 このダウンロードが完了していく様子は特徴的ですね。 もう一度、動画を再生します。 HTTP/1.1 側は6コネクションを使っています。 HTTP/2はHTTP/1.1に比べて2.5倍速くダウンロードが完了しており、大きく待ち時間を減らせています。 アセットは日本リージョンに配置 Wi-Fi を使用
  5. 今の結果を整理したものが、こちらの表となります。 HTTP/2を使った場合、ダウンロード完了までは 3.6秒ほどでした。HTTP/1.1の場合では、9秒ほど掛かっていました。 これらのダウンロード処理中の平均速度はこのようになっており、 HTTP/2 では 280Mbps ほどの速度が出せていました。 HTTP/1.1で3コネクション使う場合も多くあると思いますので、こちらで計測したデータも載せています。 このように HTTP/2 を使うことで、細かなアセットデータを多くダウンロードするという状況で、待ち時間をかなり減らすことができます。 よく使われる HTTP/1.1 3コネクションと比べると圧倒的に時間短縮が出来ているところは良いですね! HTTP/2 の性能を確認して、興味を持ってもらったところで、詳しい話を始めていきましょう。 講演のタイトルにもある「ダウンロード時間を大幅減」のためには、 「HTTP/2 プロトコルをゲーム向けに使いこなす」というのが肝となってきます。
  6. 本講演では、このような流れで説明をしていきます。 始めにゲーム開発者に向けたHTTP/2の仕様とゲームとの相性を説明します。 それからHTTP/2を使うための実装と、導入についての勘所をお話します。 後半では竹原さんに交代して、HTTP/2に関連するトラブル集と、HTTP/2の採用でインターネット全体への波及効果についてお話します。
  7. HTTP/2 の話は膨大になるので、ここでは我々ゲーム開発者に向けて関連性の高いものを説明していきます。
  8. まず HTTP/2 プロトコルは 2015年標準化完了し、公開されました。基本的に HTTP/1.1 の仕様を継承しています。 現在の普及率は、全世界で約50% といったところです https://w3techs.com/technologies/details/ce-http2
  9. このHTTP/2 の仕様のうち、ゲーム開発の分野と親和性の高い、多重化、 HPACK、バイナリフレーム、という要素を説明していきます。 そろそろ HTTP/3 の話が聞こえてくるところですが、これらの仕様は基本的に継承されています。
  10. それでは HTTP/2 最大の特徴ともいえる多重化について説明していきます。
  11. これはサーバに対し1つのコネクションで、複数の HTTP リクエストを同時に送ることが可能となります。 HTTP/1.1の1つのコネクションに相当するものを、 HTTP2ではストリームという概念で表現します。 そして、 HTTP/2 の1つのコネクションの中には、複数のストリームが存在し、それぞれのストリームが同時にデータを通信します。 この図ではストリームを矢印で表現しており、1つのコネクションの中に3つのストリームで通信をしている、という図になっています。 複数のストリームを1つの接続の中で束ねて通信をしているということから多重化と呼んでいます。 ここでは3個のストリームで書いていますが、実際に使う場合にはストリームの数はもっと多くの数を使います。 なお、 HTTP/1.1 で並列ダウンロードを実装するためには複数のコネクションを使用します。
  12. 多重化のメリットを話す前にHTTP/1.1の話を先にさせてください。 HTTP/1.1にはHead of Line Blocking という課題があります。 1つのコネクションにおいては、先行するリクエスト・レスポンスが完了しないと、次のリクエストを投げることができません。これはプロトコルの仕様です。 この課題をあらわしたものがこの図です。3つのファイルを1つのコネクションを使ってダウンロードする場合、リクエストとレスポンスを順番に処理してダウンロードを行います。 ここで、なんらかの要因で、先行するリクエストの処理完了が遅れると、それが後続リクエストの開始に響いてきます。 このような問題が HTTPのHead of Line Blockingです。
  13. HTTP/2 では、この Head of line blocking の課題を解決してます。 多重化によって並行してストリームの通信ができるため、1つのリクエストの処理が遅れても、他のリクエストの開始に影響を与えません。 この図でも先ほどと同様に3つのファイルをダウンロードをしているときの状態ですが、1つ目のファイルのリクエストを出した後、後続のファイルに対してのリクエストも発行できることを表現しています。 仮に1つ目のファイルが何らかの要因で多少時間が掛かっても、他のファイルはスムーズに通信を完了することが出来ます。
  14. 多重化の効果はまだ続きます。多重化によって小さなファイルのダウンロードであっても効率的に帯域を使用することができます。 この図は HTTP/1.1 と HTTP/2 の通信でファイルのダウンロードの真っ最中、定常状態をモデル化したものです。 どちらの場合も1つの接続を用いて、リソースをパックしていない、ファイルサイズは小さめの、たくさんのアセットデータをダウンロードしている途中の状態を示しています。 それぞれ色分けされたブロックは1ファイル全体、もしくはファイルの一部データがおくられていると読んでください。 また、縦軸はその状況において使用可能な回線帯域を示し、各ファイルがどの程度使用中であるかを示しています。 HTTP/1.1では、回線帯域に余裕があり、十分な通信バッファがあるときでも、小さなファイルを多くダウンロードしている状況ではせっかくの広帯域を使用できていません。 通信のリクエストに対し、最大でもファイルサイズ分のデータのみが送られるためです。 HTTP2では、多重化が使えるため、小さなファイルを同時に通信します。その結果、使用可能な回線の帯域を十分に活用することが出来ます。
  15. 両者を比較してみると、HTTP/1.1ではこの塗りつぶした部分が、うまく帯域を使えていなかった部分になります。 一方で、 HTTP/2では使用可能な回線帯域をほぼほぼ活用する形で通信が行えています。 1つの接続の中で、ぎっしりとストリームが詰まって通信がおこなわれている状態になっています。 このように、使用できるリソース、今の場合は使用可能な回線帯域ですが、しっかり活用して無駄な時間を減らす、ということが HTTP/2 なら可能となっています。
  16. 今度はこの多重化をゲームとの相性という観点からみてみましょう。 効率的に回線帯域を使用可能であるということから、アセットのダウンロードに有効です。 細かなファイルのダウンロードでも十分に速度がだせるので、パッキングやアーカイブが不要となることも多いでしょう。 もう1つ、クライアント・サーバ間の通信について速度の向上というメリットがあります。 複数のリクエストを束ねて送ることが出来ることから、1RTT 分の待ち時間で、例えば 100 リクエストを処理することも可能でしょう。 HTTP/1.1 の場合ならば、これは確実に 100 RTT 分の待ち時間が必要なので、待ち時間を減らす効果があると考えられます。 さすがに、API 通信で 100リクエストは大げさかもしれませんが、モバイル回線ではレイテンシが大きいため、この RTT 削減というのは目に見える差となって現れてきます。 レイテイシが大きいという点では、海外のサーバに接続する、という状況でも当てはまることでしょう。
  17. HPACK は HTTP ヘッダを圧縮する仕組みです。
  18. HPACK の技術要素は、ハフマンコーディング、インデックステーブルとして スタティックテーブルとダイナミックテーブルです。これらを今から順番に説明します。 この HPACKは RFC 7541 で記載されています。内容をしっかり理解したい人はそちらを参照してください。 これから出てくる圧縮の数値データはあくまで説明のための概算です。リアルの値とは少々異なる点にはご注意ください。
  19. それではハフマンコーディングについて説明します。 ハフマンコーディング自体は可逆圧縮の方式として有名なため、どこかで聞いたことがあるという人も多いかもしれませんね。 ハフマンコーディングは、よく出現する文字・シンボルを少ないビット列で表現し、データを圧縮するという手法です。 このハフマンコーディングによって、どのような感じでHTTPのデータが表現されるのかを確認していきます。 左は HTTP/1.1 のヘッダ、右側にはHTTP/2での同等のヘッダを表現したものです。 ここで1行目をハフマンコーディングによってどのようなビット列になるかを示したものが下段の赤枠の部分です。 このビット列はバイト数にして8バイトとなっています。元の文字列に比べ縮んでいることがわかります。 各シンボルに対してどのようなビット列になるのかは、RFCにて定義されています。
  20. そして、この HTTP/2 のヘッダ分全体をハフマンコーディングしたものが、赤枠のなかのものです。 ハフマンコーディングによる符号化後のデータは奥手っと境界に整列していることが仕様で決まっているので、そのパディングを三角括弧で表示しています。 この結果、どのくらいのバイト数になるかを計算すると、(次のスライドへ続く)
  21. このようになります。ハフマンコーディングにより48バイトになります。 HTTP/1.1と比較すると、 およそ 81% のデータ量となり、2割程度のデータを削減できています。 このように頻出文字で構成されるデータであれば大幅に圧縮が可能ですが、一般的に出現頻度が低いとされるデータが入った場合には圧縮率の低下が発生します。 圧縮率低下だけならまだしも、単純にハフマンコーディングだけでは、最悪ケースとして元データよりも大きくなる可能性は存在します。
  22. 次にHPACKに含まれるインデックステーブルについて説明します。 これはインデックス値を用いた圧縮の仕組みですが、 StaticTableとDynamicTableというものの2種類があります。 それでは、 Static Table から説明を始めていきます。
  23. Static Tableではヘッダの各部分を、 RFC で定義されているテーブルのインデックス値に置き換えていきます。 この図の水色枠部分がRFCで定義されているテーブルの抜粋となります。 先ほどと同じヘッダデータを、このインデックスで置き換えていったところ、この右側緑枠の箇所の結果となります。 点線で囲った部分がインデックス値に置き換えられた箇所です。このとき、データは31バイトとなり、元のデータと比べ約半分のデータ量に圧縮されています。
  24. 今度は Dynamic Table を説明します。 Dynamic Tableは通信に使用したヘッダフィールドをテーブルに登録していき、次回の通信では StaticTableと同じようにインデックス値を用いて圧縮する機構です。 テーブルへの登録は Static Table の続きとして追加されていきます。先ほどと同じデータを再度通信する場合、これらのインデックス値を用いると、たった5バイトで済みます。 これは元のデータと比べると、 約8%程のデータ量となり、かなり圧縮できたことを示しています。
  25. 話は変わって、今度は HTTP/2 の通信においての最小単位 フレーム、と呼ばれるものの話になります。 フレームとは次のような構造となっており、バイナリデータとして構成されています。そのためバイナリフレームと呼んでいます。 この構造の先頭にはペイロード部の長さや、データタイプ、ストリームIDといったヘッダがあり、ペイロードが後ろにつく形をとっています。 例えばリクエストヘッダの場合、タイプに HEADERS を指定してペイロード部分には HPACK で処理された結果を格納します。 HTTP/1.1はテキストデータで処理でしたが、 HTTP/2ではバイナリデータで処理するように変わっています。このことは HTTP/2 での大きな変化の1つです。
  26. さて、これまでに登場した HPACK とバイナリフレームについて、ゲームとの相性を考えてみましょう。 HTTP/1.1 の通信を考えてみると、このスライド右側のようなデータをやり取りしている状態でした。 HTTP/1.1 はテキストベースのプロトコルであり、各ヘッダの改行コードやスペースの取り扱いで煩雑な箇所が存在し、通信を処理するライブラリ層に負荷がかかっている状態でした。 これがバイナリフレームの採用により、データのパース処理について処理負荷の軽減になっています。 この様子について次のスライドでもう少し見てみましょう。
  27. 同じデータをHTTP/2にした場合を図にしめしました。  バイナリフレームを用いてこれらのデータを送ることを考えると、フォーマットが決まっているバイナリフレームではデータ解析のオーバーヘッドを減らし、通信サイズもコンパクトにできます。 特にフレーム長が先頭にあることも重要です。 さらに HTTP のヘッダ部分は、 HPACK によって圧縮が施され、少ないデータで済むようになっています。そのため通信の効率も上がっています。 注意したいのが、バイナリフレームのやり取りになってテキストのパースよりは処理負荷が軽減した、ということであり、 HPACK の圧縮・展開という点は従来にはなく追加された処理のため、実行コストが追加されています。 それでも高速な通信ができているのであれば、トータルで効率化が成功していると考えられます。
  28. さて、ここまでは HTTP/2 の仕様の話が多くて、聞いている皆さんも少し疲れたかなと思います。ちょっと休憩しましょう。 API 通信では TCP, RUDP を使うという選択もありますが、HTTP/2を使うこともお勧めできます。 例えば API 通信でよく使用される gRPC や WebSocket ですが、これらのトランスポートレイヤーではHTTP/2が使われていたりします。 もしかすると既に皆さんの環境でも HTTP/2 を使っていた、ということがあるかもしれませんね。 そして、プロトコルが HTTP ということでサーバの設定の容易さや導入コストの圧縮が可能な場合もあるでしょう。 また、これらに対応したCloud Runのようなサーバレスコンテナの登場もあり、導入がし易い環境が整ってきています。
  29. HTTP/2 そのものについて理解してもらったところで、実装について説明していきます。 クライアントとサーバのそれぞれについて順番に説明します。 どちらの話をしているのかが分かりやすいように、右側に示しているタグをそれぞれのスライドで付けています。
  30. HTTP/2 を用いた通信をするためのクライアントの実装を自力で実装するのは現実的ではありません。 HTTP/1.1 や HTTP/2 の仕様が膨大で、複雑なためです。 そこで、クライアント側ではゲームエンジンが内蔵しているものやオープンソースを利用することにします。
  31. まずケース1、 C/C++を使っている場合で、自社製ゲームエンジンやミドルウェアを使っている場合です。 このときには、採用を検討できるオープンソースは豊富にあります。 そのなかでも、我々は libcurl, nghttp2 の採用をお勧めします。 Libcurlの HTTP/2実装として使われているのが nghttp2 で、HTTP/2にのみ対応するモジュールを作成するのであれば nghttp2 を使ってシンプルに実装できると考えています。 汎用的な HTTP による通信を扱うのであれば、機能が豊富な libcurl がお勧めです。
  32. 次にケース2として Unity を使用している場合です。 Unityが採用しているC#のランタイムやクラスライブラリでは、HTTP/2を利用できません。 そこで、先に紹介した C/C++のオープンソースを利用して、ネイティブプラグインとして実装することが現実的な対応策となります。 もし将来的に C# ランタイムおよびクラスライブラリが更新され、HTTP/2を利用可能になったとしても、数万リクエストを捌けるのか、パフォーマンスは問題ないかなど、注意すべき点があります。 ちなみに私たちは先に紹介した libcurl を用いたネイティブプラグインを実装して Unity で利用しています。
  33. 今度はケース3、UnrealEngine4を利用している場合です。このとき HTTP/2が使えるかどうかは、対象プラットフォームによって対応が分かれます。 Windows で WinHTTP を使用する状態のときにのみ HTTP/2が使用可能という状態で、多くの環境では非対応です。 よって、 C/C++ 製のオープンソースを用いて対処することが必要と考えます。 UnrealEngine4 の内部の話になるのですが、使用している libcurl が HTTP/2対応したものに更新され、さらに Apple 製品向けとして NSURLSession を用いた実装に更新されれば、 簡単に HTTP/2が使えると私は考えています。
  34. 最後にケース4としてC#を用いて、自社製ゲームエンジンやミドルウェアを使っている場合です。 Windows上でMicrosoftの.NET Frameworkや.Net CoreではHTTP/2を使うことが出来ます。 他の動作プラットフォームを考慮した場合、 .NET Core は HttpClient の実装がわかれていて非対応の場合がありましたが、 .NET Core3以降は多くの環境で使用可能です。 C#を使っている関係で、ゲームアセットのダウンロードなど大量のリクエストを処理させたときのパフォーマンスには懸念が残ります。
  35. ここからは、サーバ側の話になります。 HTTP/2 を用いた通信をするためにはサーバ側も対応していることが必要です。 HTTP/2 は既に Web ページアクセスで先行して導入されている関係で、比較的枯れているものが多く、クライアント実装に比べるとトラブルが少ないように思います。
  36. 主要な CDN は HTTP/2 に対応済みとなっています。 そのためこれらを使用しているのであれば、既にHTTP/2は利用可能であったり、設定により簡単に有効化が出来る状態にあります。 余談ですが、一部の CDN は既に HTTP/3 も対応済みとなっています。
  37. 代表的な HTTP サーバソフトウェアは、現在全て HTTP/2 に対応しています。 ただしネットワーク構成として、サーバよりも前段に配置されるロードバランサーには注意が必要です。 ロードバランサが HTTP/2 通信を終端してしまい、End To End での HTTP/2 通信ができていない場合があります。
  38. さて、ここまでで説明してきたのはどちらかといえば準備の話でした。 ここからは我々が遭遇した HTTP/2 の導入にあたってのコツを共有していきます。
  39. まずは、パフォーマンスがでない① です。 HTTP/2を導入して期待するのが高速なダウンロードでしょう。それが思ったほどではないとなると残念です。 重要なポイントは、ダウンロードするデータによってはHTTP/2に切り替えるだけでは、期待したパフォーマンスが得られないということがあるということです。 ここでは2つ例を上げています。 まず、1つがファイルサイズが大きいものが支配的である場合です。この場合には、既にHTTP/1.1でも十分に速度が出ていると考えられます。 もう1つが、ファイルサイズでダウンロードのリストがソートされている場合です。
  40. このような状況を避けるために次のことを提案します。 まず、導入するプロジェクトに有効なのかを判断しましょう。ダウンロードするファイルのサイズヒストグラムを取ってみましょう。 そして、ダウンロードのリストについて、作り方にひと工夫をいれることが必要です。 これは、私たちも見事に踏んだ課題でして、この状況や解説については後半パートで詳しくお話します。
  41. 次に、パフォーマンスが出ない②です。 HTTP/1.1の実装をベースとしている場合、同時に発行するリクエストが3~6程度となっていることが考えられます。 この程度のリクエストを逐次的にリクエスト発行する場合には、HTTP/2で性能を生かすことができません。
  42. これを解決するには、リクエストをまとめて発行することが重要です。 少し前に説明したように、HTTP/2では同時に多くのリクエストを処理することが可能であり、そのような時に帯域を有効活用できます。 HTTP/2を意識した設計として、リクエストを束で受け取る関数インタフェースで設計しておくことが大切です。
  43. そして、たくさんのリクエストを同時に発行しましょうと、話したところで、次の課題です。 リクエスト数が大量になるため、それに応じたコストに注意が必要です。 ファイル保存の際にはファイルI/Oのコストが、メモリに結果を保持する場合にはメモリの使用量が溢れるなどあります。
  44. この課題に対処するためには、ファイル保存時にはバッファリングを活用しての分散した書込み、メモリへの展開時には一旦ファイルに保存するなどが必要となります。 また大量のリクエストを処理する必要があるので、雑な実装ではボトルネックになることが考えられます。 高速に処理できる管理機構や、通信処理をブロックさせない仕組みなど、配慮した実装を行うことが求められます。 より詳細な説明を後半で用意していますので、ここでは解決の指標のみにとどめておきます。
  45. さて、リクエストを捌き終わって、正常系が問題なく動くようになったところで、今度はエラーについて目を向けてみましょう。 HTTP/2 になってからは、エラーの取り扱いについても注意して考える必要があります。 HTTP/1.1のときにはコネクションエラーは通信エラーとして扱えました。 しかしHTTP/2 では多重化で通信している関係で、この考えでは不味そうです。
  46. HTTP/2ではコネクションが確立したあとの、個々のストリームでの通信エラーはリトライによる復帰可能性があるということです。 そのため、ストリームを従来のコネクションと考えて、ストリームでのエラーを即通信エラーとしてはいけません。 ここで通信エラーとしてしまうと、他の正常な通信をしているストリームを止めてしまうことになります。
  47. 通信エラーの関連して、今度はパケットロスの話題をあげています。 HTTP/2になってパケットロス率に注意しましょうという話題があります。 これがなぜ重要かというと、 HTTP/2 では1コネクションの中に複数ストリームを束ねて通信を行っています。 そして、 HTTP/2ではTCPを使って動作をしているため、パケットロスの影響が全てのストリームに影響してしまいます。 これは TCP の Head of line blocking という症状です。 この結果として、複数コネクションを使用した HTTP/1.1に速度が劣ってしまうという可能性があります。
  48. 残念ながら、HTTP/2 で TCP の Head of Line blocking を回避することはできません。 HTTP/3 が普及して使えるようになるとこれは解決できます。 HTTP/2 までしか使えない状況で、さて、どう対策するかというと、品質のわるい環境では HTTP/1.1にフォールバックする実装を対策としていれるのがよいと考えています。 どの程度のロス率でフォールバックすべきかという点については、各プロジェクト毎に指標が異なるため各プロジェクトで計測して決める必要があります。
  49. 次はサーバの対応状態を確認しましょうという話です。 本番のクラウドサービス、開発中のサーバやテストのサーバで HTTP/2対応をした状態かを確認しましょう。 運用中のタイトルに HTTP/2を新規導入する場合には、サーバ側での有効・無効スイッチを変更し忘れるケースもあります。 このような事態が発生すると、 HTTP/2 に対応したのにダウンロードが速くならないと誤解される恐れがあります。
  50. そういったことを避ける意味でも、 HTTP/2 通信が出来ているのかどうかをチェックするツールを用意しておくのがよさそうと考えています。
  51. HTTP/2 の優先度に関係する課題があるのですが、その前に HTTP/2 の優先度とは何かを説明します。 HTTP/2 では優先度の仕組みが仕様として定義されており、各ストリームに重みづけや依存関係を設定をすることができました。 これにより、先に欲しいリソースをサーバに通知するということができ、例えばブラウザではhtmlやスタイルシート、JavaScriptに高い優先度を与え、画像データは後回しというようなことが可能となりました。
  52. そこで、この HTTP/2 の優先度制御を活用して、ダウンロードの順序制御に使おうという考えが浮上します。 しかし、実際にはいくつかの CDN で、正しいふるまいを実装しておらず、安心して使えない状態です。 また、 HTTP として優先度オプションの協議が始まっており、これは HTTP/2 とは切り離して話が進んでいます。 こちらは現時点においては、 RFC も策定されていません。
  53. ダウンロードの順序制御についての解決策は、自前で順序制御を実装する、という素直な方法が考えられます。 実際に、私たちが実装した通信ライブラリでは、自前でのこの機能を実装しました。
  54. もう少しだけ、私たちが遭遇した話を共有しておきます。 HTTP/2 の仕様上、 TLS 1.2 以上を必要とします。しかし、実際のところそれ以下のバージョンや、生http での通信で HTTP/2 が使用可能な場合もあります。 AWS の ALB では https での通信を行ったときのみ HTTP/2 が使用可能でした。
  55. ここからは竹原が担当させて頂きます、よろしくお願いします まずは実際に HTTP/2 に対応した通信ライブラリを運用した際に発生したトラブルとその解決方法について共有させて頂きます 先ほどの山田さんのパート同様にアイコンでクライアント、サーバ、もしくはその両方を示していますので参考にしてください それでは、いってみましょー
  56. まずはダウンロード速度が思った通りに出なかった、というトラブル事例となります 1とついていることからわかる通り、2,3 と続いていきます…… 山田さんパートで説明したように、導入時にもある程度パフォーマンスは意識していたのですが、それでも様々な要因で速度が出なかったので、その苦闘の歴史を是非共有させて頂ければと
  57. というわけで、まずは通信速度が一定以上になるとそれ以上ダウンロード速度が出ない、という問題です
  58. これは、データの送受信処理をメインループに同期させていた為、通信速度が一定値を超えるとソケットの受信バッファが満タンになり待ちが発生しているのが原因でした スマホのゲームは 30FPS のものが割と多いので、ゲーム側のメインループに同期させると結構簡単に受信バッファが満タンになってしまいます 通信プログラムでは割とありがちな問題ですね
  59. 対策としては、素直に受信処理の非同期化を採用しました しかし、非同期化したことにより abort 処理やリトライ処理、プログレスの計算がかなり複雑になってしまいバグも何度か出ました 多くのストリームを同時に扱うので、非同期化した際の実装難易度は HTTP/1.1 までより高くなります。注意してください 可能であれば、後付けでスレッド化しないで最初の設計時に盛り込んでおいた方が良いでしょう
  60. 次はダウンロード速度が出ない第二弾です
  61. ①の対策で安心したのもつかの間、特定の端末で前項の「通信速度が一定を超えるとそれ以上のダウンロード速度にならない問題」が再発してしまいました
  62. 調査の結果、下位グレードの端末で通信速度がファイル I/O 速度を上回ってしまった為に発生していることが判明しました 特にファイル I/O の回数がボトルネックになっていました 下位グレードの端末はファイル I/O が驚く程低速のものがあるので、しっかりテストしておくことをお勧めします
  63. こちらの解決策として、メモリマネージャを導入しました ライブラリの実装がダウンロードしたそばからファイルに書き込みをしているあまりよろしくない実装だったので、一定のサイズまではメモリに書き溜めておき、そのサイズを上回った段階でファイルに書き込むことでファイル I/O の負荷を軽減しました 一定のサイズの設定値が大き過ぎると、これまたボトルネックになったりするので注意が必要です アセットサイズ分布によりこの一定サイズの最適解は異なるので、アプリ毎に設定を変えられるのが理想です 私たちは現在デフォルト値を 64kb として、ライブラリ初期化時にこの値を変更可能な形で運用中です
  64. やれやれ、これでようやく HTTP/2 の爆速ダウンロードを味わえる……と思いきやまたまたダウンロード速度が出ない問題が発生しました
  65. ②までの対策でしばらく安定した速度が出ていたのですが、ある日ライブラリ側では何も修正していない、 大事なことなので二度言いますが、何も修正していないのに、突然特定のタイトルでダウンロード速度が安定しなかったり、低下する問題が発生しました
  66. これは、そのタイトルにおけるダウンロード対象のアセットリストの構成が変わっており、小さいファイルが集中しているゾーンが発生し、帯域を使い切れていないケースが発生してしまったのが原因でした スマホタイトルは割と小さいサイズのアセット中心で構成されていることが多く、案外この問題に遭遇することは多いです
  67. この問題は前半戦で山田さんが紹介したダウンロードリストの作り方を工夫することで回避できます まず、ダウンロードするファイル順序に気を配り、サイズでのソート済みという状況を避けましょう できれば常に帯域が埋まるようにリクエストを投入していくのが理想ですが、単純にランダムにリストの順序を入れ替えることでもある程度効果があります
  68. しかし、ソートしてあげてもダメなケースがあります 例えば最大で 128 ファイルを同時並行でダウンロード可能な実装とした場合、200Mbps の帯域では1 ファイル 195 kB 程度はないと帯域に余りがでてしまいます スマホタイトルではこのレベルのサイズのファイルは割と少なく、アセット構成次第ではいくら頑張っても同時ダウンロードするファイルサイズの合計が帯域より小さくなってしまうことがあります この 195kBを求めた計算はかなりざっくりとしたもので、実際にはウィンドウサイズや RTT により値は大きく変動することに注意してください
  69. 補足となりますが、 HTTP/2 において、同時にダウンロード可能な数、つまりリクエスト数はコネクションあたりのストリーム数に依存します これを HTTP/2 的にはストリーム最大数、 RFC では MAX_CONCURRENT_STREAMS と呼びます この値はクライアントとサーバで別々に管理しており、自分の受付可能なストリーム最大数をお互いに送信し合うことにより設定を行います
  70. このストリーム最大数を変更すれば同時ダウンロードするファイルサイズが帯域を上回るような設定が可能そうです しかし、使用していた CDN ではストリーム最大数を変更できませんでした そこで、ストリームが上限に達したら次のコネクションを追加し、最大でコネクションを 3 つまで張る方向で対応しました それでも 1.1 までの実装で多く見受けられる 6 コネクション構成に比べて半分の数になっています また、副次効果として前述した“パケットロス率が高い環境では HTTP/1.1 より遅くなる可能性がある”問題についても対応できました 私達が運用していた環境では、ストリーム最大数が 128 だったので、これにより最大 384 ファイルを同時並行でダウンロード可能になりました 384 平行ダウンロードできると、例えば 200Mbps 出る回線では 1 ファイル 65 kB 程度あれば十分に帯域を活用できるようになり、速度にも安定感が出ます この計算も先ほど同様ざっくり算出なので、あくまでも目安程度と考えてください ちなみに、前述のメモリマネージャのデフォルトサイズの 64kB はここからきていたりします
  71. 当問題に関する補足です Amazon Cloud Front をはじめ、多くの CDN ではストリーム最大数は 100 ~ 200 程度に設定されており、この値は CDN 設定で変更できないものがほとんどです CDN 業者の方がもしこの講演聞いていたら、ストリーム最大数 MAX_CONCURRENT_STREAMS を変更できるようにして頂けるとゲーム業界的には大変助かります
  72. 補足その②です 実は .Net 6 の HTTP/2 の通信実装でも、このストリーム最大数を超えた場合にどうするか、という議論が行われたようです そして、最終的には私たちの実装同様に、ストリームが上限に達したらコネクションを追加する、という結論に落ち着いたようです この問題からも分かる通り、ストリーム最大数は仕様が難解で、うまく活用されているかというと怪しい現状があります またこの現状は、ゲーム業界以外ではこの値を変更したいケースがあまりなさそう、という事情も絡んでそうです というわけで、これで速度問題は解決、次の問題はなんでしょうか?
  73. はい、もちろんダウウンロード速度が出ない問題です
  74. 今度は HTTP/2 ライブラリを別のタイトルにも導入しよう、となった際に、そのタイトルではなぜか速度が出ない問題が発生しました 更にこの問題は、そのタイトルで HTTP/2 ライブラリの導入を検証しているフェーズで発生したので、このままでは採用が危ぶまれると急ぎ調査をしました
  75. 結果、そのタイトルのディレクトリ構成だと HTTP/2 ライブラリ内部で C++ で実装されていた rename や delete の処理の負荷が高いことが原因とわかりました そのタイトルでは 1 ディレクトリに数千のアセットファイルが存在しており、更にハッシュ化された長めのファイル名が使われていました 私達が実装した HTTP/2 ライブラリでは、ダウンロード中の一時ファイルを “ファイル名.tmp” として同じディレクトリで管理していたので、このディレクトリ内での rename や delete の処理が重くなってしまっていました
  76. 検証を行っていたのが既に運用中のタイトルでしたので、ディレクトリ構成を変えて貰うのは影響が大きく、ライブラリ側の一時ファイルの処理を変更して問題を回避しました tmp ファイル専用のディレクトリを用意し、その中で内部的なリクエスト番号を使った一意な短いファイル名を使って管理しています 今回のケースは Android で問題が発生しましたが、 1 ディレクトリに大量のファイルを配置するのは、多くのファイルシステムにおいてパフォーマンス低下を招く可能性があるので避けるのが無難です (原因についてどこまで触れるかは未定 → 調査 Issue : https://ghe01.segard1dev.jp/SGC-DT/UniHttp2/issues/719)
  77. 当問題を解決したことによりついに速度でない問題は全て解消! これからは爆速アセットダウンロードの時代!!
  78. と喜び勇んでいたのですが、今度はダウンロード速度が出すぎることにより問題が発生しました……
  79. とあるタイトルの大型アップデート時に、CDN のデータ転送レート設定上限値を超える通信量が発生することが判明しました
  80. CDN によってはデータ転送レートに制限が掛かっていることがあります 例えばこの問題が発生した際は Amazon Cloud Front のデフォルトの上限値は 40Gbps でした 40Gbps というのは案外小さい数字で、 200Mbps でアセットダウンロードをする端末がある場合 200 ユーザーで詰まってしまいます HTTP/2 にすると 200Mbps 程度は余裕で出るようになるので注意が必要です ちなみに、Amazon Cloud Front のデフォルトの上限値は 2020/05/20 に 150Gbps に更新されています。ありがたいことです
  81. 幸いアップデート前にタイトルの方が気付いてくださり、混雑時間帯のみ HTTP/1.1 へダウングレードする方向で問題を回避し、大事にはならずに済みました 制限がある CDN も課金すれば転送レート上限の引き上げが可能な所がほとんどなので、お金で解決するのも手です HTTP/2 利用時には CDN 選定条件にデータ転送レートについて入れるのをお勧めします
  82. 次はファイルオープンに関する話です
  83. ある日、 HTTP/2 ライブラリを使っているタイトル側の処理内でファイル上限エラーが発生したとの報告が入りました ライブラリは Windows は VCRUNTIME の _getmaxstdio を Android/iOS では /proc/self/limits の値を基準として、この値の 80% までのファイルハンドルを使用しています _getmaxstdio の上限は 512 程度なので、 Windows では 409 まで同時オープン可能です これは前述する 384 ストリームに耐えうる数字です Android/iOS は /proc/self/limits の値より実測値が大きいことがありましたが、下回ることはなく、且つ検証したすべての端末で実測値が 1024 以上だったので問題なしと判断しました
  84. ところが iOS11 からファイルオープンのデフォルトの上限が 256 になったようで、ライブラリ側で 80% も使ってしまうとタイトル側で使えるファイル数が 51 ファイルと極端に少なくなってしまっていました
  85. 幸い iOS は BSD 系の OS なのでファイルオープンの上限数の変更を行う setrlimit/getrlimit が利用できます この関数を用い、コネクション数とストリーム上限数から利用するファイルハンドル数を算出して変更する実装に切り替えることにより問題を解消しました また、 setrlimit/getrlimit が効かない端末を考慮し、タイトルで使用するファイル上限数を受け取るようにして、最低でもその値はファイルリソースを残すような実装としています 更に iOS だけでなく Android 端末でもこの問題が発生しうるので同様の対策を入れました 最後に、通信開始時にファイルオープンしていた処理を、ファイル書き込みする段階になってはじめてオープンするように変更する等、可能な限りファイルリソースを節約するように処理を修正しました
  86. 次はファイルの rename に失敗する問題です
  87. これは割と最近の話なんですが、特定の端末でのみダウンロード完了後のファイルの rename に失敗する問題が発生しました rename は先ほど述べた .tmp を正しいファイル名にする処理が該当します 端末も古いものではなく、Pixel 5 とむしろとても新しいものでのみ問題が発生しました
  88. 調査はかなり難航したのですが、最終的には Android11 から ExternalStorage の境界をまたぐ POSIX の rename の呼び出しが禁止になったのが原因なことがわかりました 対象は PublicDirectory(Download), Cache, Files, Files(Download), Media で、お互いの境界をまたぐような rename が失敗します rename(POSIX) と書いてあるのは C/C++ から呼び出した場合のみ問題が発生するからで、 Java の rename については内部で COPY + 削除にフォールバックする処理が Android11 から入っているので問題が発生しません
  89. また、全ての Android11 端末で発生するわけではなく、sdcardfs が使用されているカーネル、具体的には cat /proc/filesystems の結果に sdcardfs が存在する場合は問題は発生しません この為、調査の際は Pixel3,4 を Android11 にしても再現せず、原因究明にかなり苦戦しました 条件を満たせば Android11 のエミュレータでも再現するので、当問題の確認を行う際は活用を検討ください
  90. 対策としては、 Java と同様に C/C++ の実装でもファイルの rename 失敗時にはコピー&削除にフォールバックするような処理を入れました ただし rename に比べてパフォーマンスのペナルティはあるので、大量のファイルを取り扱う HTTP/2 ではできる限り ExternalStorage の境界を跨がないようなディレクトリ構成で設計することをお勧めします
  91. 次はタイムアウトが発生しない問題です
  92. Amazon Cloud Front との通信で、データを全くダウンロードできないにも関わらず、タイムアウトしない問題が発生しました
  93. 発生頻度がかなり稀だった為に確証を掴むことはできなかったのですが、挙動からコネクション切断時に送信を行う GOAWAY フレームがロストした際の問題と推測を付けました 複数のストリーム処理が絡むので HTTP/2 のコネクションクローズの実装は複雑となりがちです
  94. この問題には、独自のタイムアウト処理を追加することにより対応しました タイムアウト判定時にはハンドシェイクからやり直すことになりますが、このパフォーマンスロスは受け入れる方針としました ちなみに、 HTTP/2 の graceful shutdown に対応したサーバ・ライブラリを使っていればこの問題は回避可能です 私達はライブラリの実装担当であり、サーバの選定はタイトル側の開発者が行う、という事情で対応が担保できなかった為に自前実装を選択しています
  95. 次は iPhone で通信中に不正終了する問題です
  96. 大量のアセットの一括ダウンロード中、極稀に不正終了する問題が発生しました 検証環境では7万回に一度程度発生しています 数字だけ見るとかなり発生条件がレアに見えますが、取り扱うアセットファイルの数が数千オーダーなので、割とひんぱつする問題と言えます
  97. こちらの調査もかなり難航したのですが、最終的には利用している OSS の不具合だと分かりました HTTP/2 の connection reuse 発生時に加え、いくつかの条件を満たした時のみ発生していました いくつかの条件についてはかなり複雑なので割愛しますが、数千~数万ファイルを一気にダウンロードするのはゲームくらいなので、レアなバグを踏むことがあります
  98. その後 OSS の更新で無事に問題は修正された レアなバグはあるものの、他社様の大型タイトルで HTTP/2 を採用しているものも見かけるようになって来た為、全体としては枯れていく流れが来ていると思います 時代は HTTP/2 です
  99. 最後に HTTP/2 独自の設定をしたい、という問題というよりは実装修正の話です
  100. 私達のライブラリは、現状設計としては 1.5Gbps までを限界の通信速度として設定しています しかし、 5G 時代に備え、もっと速度を出したい、という要望がいつ来るとも限りません そこで、速度改善の方法として、HTTP/2 独自設定のカスタマイズについても検討を行いました 例えば、 ストリームの初期ウィンドウサイズ を変更して通信開始時のパフォーマンスロスを減らしたい、という話や 速度にはあまり影響を与えませんが、 HPACK の Dynamic Table 設定を変更したい、という話も挙がりました
  101. しかし、利用している OSS はこれらの設定を内部パラメータとして隠蔽していました 改修して使う手もありましたが、現状まだ速度的には余裕があるのとメンテナンス性を考慮して今のところ対応は諦めています 今後 5G がより一般的に普及し、帯域に余裕が出てきたらまた考え直すかもしれません 皆さんが HTTP/2 を採用する場合は、こうした設定を行いたいか否かを OSS 選定のタイミングで考慮しておくのをお勧めします
  102. ここまでは開発者視点で HTTP/2 のメリットを語ってきました この項目では、少し観点を変えて HTTP/2 がインターネットそのものに与える影響について触れてみようと思います
  103. まずはコネクション削減による効果です
  104. 今までの講演でも触れてきましたが、ゲームはコネクションを多数張って各種通信を行う実装になっていることが多くあります アセットダウンロード、ゲームそのものの通信、ランキング等付加情報の通信、チャット等、送受信を行うデータも様々で、それぞれの通信に対して複数のコネクションを張ることも珍しくありません
  105. こうした形でコネクションを多数用いると、その分インターネット上に存在する中継器の負荷増大に繋がります
  106. 普段何気なく使っているインターネット通信ですが、そのリソースは社会全体のインフラ、すなわち資源です こちらはコネクションではなくトラフィックに関するグラフとなりますが、ゲームのオンライン化や動画サイトの一般化、家電をはじめとする様々なものの IoT 化、新型コロナウィルスによる在宅ワークの普及等により、全世界のインターネットには余裕がない状況が続いています
  107. これまで何度も触れてきた通り、 HTTP/2 であれば従来の通信に比べてコネクション数を削減可能です 最初に山田さんから説明のあった多重化に加え、特定の条件でコネクションの再利用をする機能もあり、HTTP/1.1 に比べて効率的にコネクションの運用ができます
  108. 既に非ゲーム分野では HTTP/2 化、果ては同様の効果を持つ HTTP/3 化も始まっており、コネクション数は減少傾向です こちらの資料は Web Almanac が公開している 2016 年から 2020 年の間に web ページ 1 ページあたりの TCP 接続数がどれくらい減少したかを表すグラフです 縦軸が web ページ 1 ページあたりの TCP 接続数、横軸は Percentile で、緑色が 2016 年の、紺色が 2020 年のデータです 中央値で 23 から 13 に、約 44% ものコネクション数が削減されているのがわかります 反面、ゲーム業界全体での HTTP/2 採用率は、前述した通り主要なゲームエンジンで HTTP/2 が標準採用されていないのもあり、まだまだの状況です
  109. HTTP/2 の導入は開発者にとってはユーザ体験を向上させ、離脱率の低下等に繋げることができます 更にユーザにとっては待ち時間が減り、インターネット全体の負荷も下げることができます まさしくいいことずくめです
  110. ゲーム業界の皆さんも HTTP/2 を使って開発者にもユーザーにもインターネットにも優しいゲーム作りを目指しましょう
  111. 次にゲームのデータ配信とインターネットのトラフィックに関係する話です
  112. 昨年の CEDEC 2020 [JANOG×CEDECコラボセッション] インターネットとゲームトラフィック でも話題に上りましたが、最近は AAA タイトルの発売日や大型アップデート日のインターネットトラフィックのスパイクが問題になっています
  113. ゲーム業界は社会全体のインフラであるインターネットを使わせてもらっている立場であり、無尽蔵にそのリソースを占有していい訳ではありません そこで、一括ダウンロードはなるべく避け、必要になったタイミングで都度データをダウンロードしてくる方式の採用を提案します 都度ロードが挟まることでユーザの体験が損なわれる恐れがありますが、そこは HTTP/2 で通信を効率化することによりカバー可能です 既にモバイルゲームではこうしたデータのダウンロード形式が一般的なので、非モバイルゲームにおいても当方式の採用を検討して貰えると嬉しく思います モバイルゲームで都度ダウンロード形式でない実装のタイトルの方もご検討お願いします
  114. 勿論、 FPS のようなリアルタイム性の高い対人ゲームのように都度ダウンロード形式が相性が悪いものは存在しています 反面、RPG や MMO、 MO といったそこまで導入のハードルが高くないジャンルも多くあります 随時ダウンロード形式は管理やデータの差し替えが容易というメリットもありますし、 業界全体でまずは導入が容易なタイトルから改善を行い、その後リアルタイム性が高いゲームへの適用方法も考えていきたいですね
  115. 最後にまとめです
  116. HTTP/2 はアセットダウンロードに効果大です HTTP/2 はクライアントサーバ間の通信の効率化にも効果大です HTTP/2 はインターネットにも優しいです 皆さん HTTP/2 を使いましょう!