Tweet
Tweet

Slide 1

Slide 1 text

ダウンロード時間を⼤幅減︕ 〜⼤量のアセットをさばく⾼速な実装と運⽤事例の共有〜

Slide 2

Slide 2 text

© SEGA ゲームコンテンツ＆サービス事業本部 技術本部 開発技術部 ⽵原 涼 ⾃⼰紹介 【登壇歴】 CEDEC 2020 「技術同⼈作家になろう 〜働き⽅改⾰時代におけるエン ジニアのレベルアップの⼀例〜」 Unite Tokyo 2019 「⼤量のアセットも怖くない︕〜HTTP/2による⾼ 速な通信の実装例〜」 CEDEC 2018、CEDEC 2016、CEDEC 2015 プロダクション関連のラ ウンドテーブル GDC2016 報告会 「GDC16にみる⾃動化技術とテストのトレンド」 祝・HTTP/3 RFC発⾏(間近)︕

Slide 3

Slide 3 text

© SEGA ゲームコンテンツ＆サービス事業本部 技術本部 開発技術部 ⼭⽥ 英伸 ⾃⼰紹介 【登壇歴】 CEDEC 2020 「技術同⼈作家になろう 〜働き⽅改⾰時代におけるエンジニアのレベルアップの⼀例〜」 Unite Tokyo 2019 「⼤量のアセットも怖くない 〜HTTP/2による⾼速な通信の実装例〜」

Slide 4

Slide 4 text

© SEGA • 本講演内容の撮影、SNS投稿は OK • 後⽇、CEDIL で資料を公開 • 講演中の質疑が可能です。 コメントに書き込んでください • 資料に記載されている会社名、システム名、製品名、サービス名は各社の登録商標または商標です • Android ロボットは、Google が作成および提供している作品から複製または変更したものであり、 クリエイティブ・コモンズ表⽰ 3.0 ライセンスに記載された条件に従って使⽤しています

Slide 5

Slide 5 text

© SEGA • CDN に配置したアセットを端末にダウンロード • HTTP/1.1 と HTTP/2 の差に注⽬ 効果を先にお⾒せします

Slide 6

Slide 6 text

© 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 接続状態

Slide 7

Slide 7 text

© SEGA • ゲーム開発者向け HTTP/2 仕様の説明 • HTTP/2 を使うための実装について • HTTP/2 導⼊時の勘所 • HTTP/2 トラブル集 • HTTP/2 の採⽤によるインターネット全体への波及効果 • まとめ 本講演の流れ

Slide 8

Slide 8 text

© SEGA ゲーム開発者のための HTTP/2

Slide 9

Slide 9 text

© SEGA • HTTP/2 2015年 標準化完了＆公開 – HTTP/1.1 を基本的に継承 • 現在の普及率 約45.6% (w3techs.com 2021/06時点) ゲーム開発者のための HTTP/2

Slide 10

Slide 10 text

© SEGA • 多重化 • HPACK • バイナリフレーム (ゲームと関連性の深いものに限定) HTTP/2 の仕様

Slide 11

Slide 11 text

© SEGA HTTP/2 多重化

Slide 12

Slide 12 text

© SEGA • 1つのコネクションに複数の HTTP リクエスト 多重化 – HTTP/2 の仕様 GET GET GET APP SRV Connection ストリーム

Slide 13

Slide 13 text

© SEGA • HTTP の Head of Line Blocking:HoLB (HTTP/1.1) – 何らかの要因で先⾏リクエスト処理に時間が掛かると 後続のリクエスト処理が遅れてしまう HTTP/1.1の課題 - 多重化 – HTTP/2 の仕様 1.png 2.png 3.png この分の遅れが後続に響く 1.png

Slide 14

Slide 14 text

© SEGA • HTTP/2 は HTTP の HoLB を回避 – 複数ストリームの多重化により 後続のリクエストを並⾏に処理可能 多重化でHoLB回避 - 多重化 – HTTP/2 の仕様 1.png この分の遅れは 他のリクエストに影響しない 1.png 2.png 3.png

Slide 15

Slide 15 text

© SEGA • HTTP/1.1 と HTTP/2 通信状態の⽐較 帯域の利⽤ - 多重化 – HTTP/2 の仕様 HTTP/1.1 HTTP/2 時間 使⽤可能な 回線帯域 時間 HTTP/1.1 は Keep Alive 有効を想定. 但しファイルサイズが⼩さいと広帯域を活⽤できない.

Slide 16

Slide 16 text

© SEGA • HTTP/2 は使える帯域を有効活⽤ 帯域の利⽤ - 多重化 – HTTP/2 の仕様 HTTP/1.1 HTTP/2 時間 使⽤可能な 回線帯域 時間 帯域を活⽤できていない 多重化で帯域をしっかり活⽤

Slide 17

Slide 17 text

© SEGA l 細かいアセットダウンロードに有効 ü 効率的に回線帯域を使⽤ l クライアント・サーバ間通信 ü RTT による待ち時間削減 (モバイル回線 など) ゲームとの関連 – 多重化 – HTTP/2の仕様 RTT RTT APP SRV SRV APP 1RTT 分で複数リクエスト RTT HTTP/1.1 HTTP/2

Slide 18

Slide 18 text

© SEGA HTTP/2 HPACK

Slide 19

Slide 19 text

© SEGA • HTTP ヘッダを圧縮する仕組み (RFC 7541) • 技術要素 ü Huffman coding ü Indexing Table uStatic Table uDynamic Table HPACK – HTTP/2 の仕様

Slide 20

Slide 20 text

© SEGA • 出現頻度の⾼い⽂字に短いビット列を割当てて圧縮 Huffman coding - HPACK – HTTP/2 の仕様 HTTP/1.1 HTTP/2 10 BYTES から 8 BYTES へ

Slide 21

Slide 21 text

© SEGA • 出現頻度の⾼い⽂字に短いビット列を割当てて圧縮 Huffman coding - HPACK – HTTP/2 の仕様 ※ < > 内はパディング. オクテット境界に揃える

Slide 22

Slide 22 text

© SEGA • 出現頻度の⾼い⽂字に短いビット列を割当てて圧縮 Huffman coding - HPACK – HTTP/2 の仕様 HTTP/1.1 HTTP/2 59 BYTES 48 BYTES ※ 参考値です。実際に送信されるバイト数とは異なります 約 81.4% に削減 HTTP/2 63 BYTES

Slide 23

Slide 23 text

© SEGA • インデックス値を⽤いた圧縮機構 – Static Table – Dynamic Table Indexing Table - HPACK – HTTP/2 の仕様

Slide 24

Slide 24 text

© SEGA • 事前定義されているテーブルのインデックス値を使う Static Table - Indexing Table - HPACK – HTTP/2 の仕様 HTTP/2 ※ 参考値です。実際に送信されるバイト数とは異なります 31 BYTES 63 BYTES 約 49.2% に削減

Slide 25

Slide 25 text

© SEGA • 通信に使⽤したデータをテーブルに登録し、 テーブルのインデックス値を使う Dynamic Table - Indexing Table - HPACK – HTTP/2 の仕様 ※ 参考値です。実際に送信されるバイト数とは異なります 5 BYTES 約 8.4% に削減 テーブルに登録 同内容でリクエスト時

Slide 26

Slide 26 text

© SEGA • フレーム: ストリーム上を流れる最⼩単位 • バイナリデータ送受でテキストより効率が良い バイナリフレーム – HTTP/2の仕様 フレームヘッダは 9Bytes フレームの構造

Slide 27

Slide 27 text

© 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 データサイズはまだ不明

Slide 28

Slide 28 text

© 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で圧縮 データサイズは先頭

Slide 29

Slide 29 text

© SEGA • TCP, RUDP を使えば︖ – HTTP/2をトランスポートレイヤーに持つ gRPC や WebSocket – サーバ設定や導⼊コストの圧縮が⾒込める – 対応したサーバレスコンテナの登場 • Cloud Run (Google) 閑話 : API 通信に HTTP を⽤いるメリット

Slide 30

Slide 30 text

© SEGA HTTP/2 を使う実装 Client Server クライアント サーバ

Slide 31

Slide 31 text

© SEGA • ⾃⼒で全て実装は現実的ではない • ゲームエンジンが内蔵しているもの ＆オープンソースの利⽤ HTTP/2 を使う実装 Client

Slide 32

Slide 32 text

© SEGA • C/C++による ⾃社製ゲームエンジンやミドルウェアを利⽤ ü C/C++製の OSS は選択肢が豊富 ü 中でも libcurl, nghttp2 がお勧め ケース１ - HTTP/2 を使う実装 Client

Slide 33

Slide 33 text

© SEGA • Unity を使⽤している場合 ü Unityが採⽤している C#ランタイム/クラスライブラ リでは HTTP/2 が利⽤できない ü 前述のC/C++製OSSを⽤いた ネイティブプラグインを実装 ケース２ - HTTP/2 を使う実装 Client

Slide 34

Slide 34 text

© SEGA • Unreal Engine4 を使⽤している場合 ü Windows で WinHttp 使⽤時のみ HTTP/2 対応 ü C/C++製OSSを⽤いて対処を考える ケース３ - HTTP/2 を使う実装 Client

Slide 35

Slide 35 text

© 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

Slide 36

Slide 36 text

© SEGA • CDN の選定 • サーバソフトウェアの選定 HTTP/2 を使う実装 Server

Slide 37

Slide 37 text

© SEGA • 主要なCDNは全て HTTP/2 対応済み︕ ü CloudFront (Amazon) ü Cloud CDN (Google) ü Azure CDN (Microsoft Azure) ü Fastly (Fastly) ü Akamai CDN (Akamai) ü CloudFlare (CloudFlare) CDNの選定 - HTTP/2 を使う実装 Server

Slide 38

Slide 38 text

© SEGA • サーバソフトウェアの選定 – 主要なサーバプログラムは全て HTTP/2 対応済み︕ • IIS, nginx, apache など – 前段にあるロードバランサに注意 (ADC含む) • HTTP/2を終端する可能性 ソフトウェア選定 - HTTP/2 を使う実装 Server

Slide 39

Slide 39 text

© SEGA HTTP/2 導⼊時の勘所

Slide 40

Slide 40 text

© SEGA • ダウンロードするデータサイズや順序によっては 期待した結果が出ない ü ファイルサイズが⼤きいものが⽀配的な場合 ü ファイルサイズでソートされている場合 パフォーマンスが出ない① Problem!

Slide 41

Slide 41 text

© SEGA • プロジェクトに有効かをまず判断︕ ü ファイルサイズのヒストグラム • ダウンロードリストの作り⽅に⼯夫が必要 パフォーマンスが出ない① Solution! 私たちが遭遇したので、 後で詳しく説明します

Slide 42

Slide 42 text

© SEGA • コネクション数に応じて、 逐次的にリクエスト発⾏をしている場合 – HTTP/1.1 を意識した実装の場合、 3〜6程度でリクエストを送信となることが多い パフォーマンスが出ない② Problem!

Slide 43

Slide 43 text

© SEGA • リクエストを束で受け取る設計 – 多くのリクエストを同時に発⾏する – ライブラリを作るときに意識する パフォーマンスが出ない② Solution!

Slide 44

Slide 44 text

© SEGA • リクエスト数が数万になることも︕ – ファイル保存時、ファイル I/O のコスト – メモリに展開時、メモリ使⽤量が爆発 ⼤量リクエストを捌くために Problem!

Slide 45

Slide 45 text

© SEGA ü ファイル保存時、分散書込みなど、負荷軽減策が必要 ü メモリに展開時、⼀旦ファイルに保存 ü 実装によっては、思わぬボトルネックを⽣むので注意 ⼤量リクエストを捌くために Solution! 私たちが遭遇したので、 後で詳しく説明します

Slide 46

Slide 46 text

© SEGA • HTTP/1.1 時 「コネクションエラー=通信エラー」だったが、 考え⽅を改める必要あり エラーへの考え⽅ Problem!

Slide 47

Slide 47 text

© SEGA • HTTP/2 ストリーム単位でのエラーは 復帰できる可能性がある ü 即、通信エラーにしてはいけない エラーへの考え⽅をアップデート Solution! APP SRV Connection 正常なストリームは通信中

Slide 48

Slide 48 text

© SEGA • 1 Connection内に複数ストリームで通信 – ⾼パケロス環境では 複数Connection HTTP/1.1 より速度が劣ることも パケットロス率に注意 Problem! APP SRV 他のストリームも 再送の影響を受ける パケットロスで 通信エラーが発⽣

Slide 49

Slide 49 text

© SEGA • HTTP/2 を悪環境で利⽤時 ü ⼀定のパケットロス環境では HTTP/1.1 にフォールバックする対策 ü フォールバックする場合の割合は、 各プロジェクトで計測して判断が必要 パケットロス率に注意 Solution!

Slide 50

Slide 50 text

© SEGA • 本番・テストのサーバは対応しているか︖ • サーバ側の HTTP/2 機能を有効にし忘れていないか︖ • このような事態が発⽣すると、 HTTP/2 使っても速くない、と誤解される恐れがある サーバの対応を確認 Problem!

Slide 51

Slide 51 text

© SEGA • HTTP/2 の誤った認識をさせないため ü HTTP/2 通信できているかの チェックツールを⽤意しておくのも良い サーバの対応を確認 Solution!

Slide 52

Slide 52 text

© SEGA • 優先度(プライオリティ)の仕様がある • 各ストリームに重みづけや依存関係を設定し、 先に欲しいリソースをサーバに通知する仕組み HTTP/2 の優先度設定

Slide 53

Slide 53 text

© SEGA • ダウンロードの順序制御に HTTP/2 の優先度制御を使うことはできない – CDN 実装の問題で事実上使えない – HTTP として優先度オプションの協議 – 現状 RFC 策定されていない 優先度制御の課題 Problem!

Slide 54

Slide 54 text

© SEGA • リクエスト順を制御したい場合には、 ⾃前で実装するのが無難 優先度制御 Solution!

Slide 55

Slide 55 text

© SEGA • TLS 1.2 以上が必要 (サーバ) – 仕様上 HTTP/2では TLS1.2 • AWS ロードバランサ – ALB の https 通信で HTTP/2 が使⽤可能 その他

Slide 56

Slide 56 text

© SEGA HTTP/2 トラブル集 C S クライアント事例 サーバ事例

Slide 57

Slide 57 text

© SEGA ダウンロード速度が出ない① C S クライアント事例 サーバ事例

Slide 58

Slide 58 text

© SEGA • 通信速度が⼀定を超えるとそれ以上のダウン ロード速度にならない問題が発⽣ ダウンロード速度が出ない① Problem! C

Slide 59

Slide 59 text

© SEGA • 受信バッファが満タンになった際に待ちが発⽣ ü 送受信処理をメインループに同期させていた為 ダウンロード速度が出ない① Cause C HTTP/2ライブラリ 受信処理 ゲームメインループ 同期 同期 受信バッファ満タン パケット 受け取れないので待つ

Slide 60

Slide 60 text

© SEGA • 受信を別スレッドに分離し、取りこぼしを抑制 ダウンロード速度が出ない① Solution! C HTTP/2ライブラリ 受信処理 ゲームメインループ 取得 パケット 受信バッファ 保存

Slide 61

Slide 61 text

© SEGA ダウンロード速度が出ない② C S クライアント事例 サーバ事例

Slide 62

Slide 62 text

© SEGA • 前項の「通信速度が⼀定を超えるとそれ以上の ダウンロード以上にならない問題」が特定の端 末でのみ再発 ダウンロード速度が出ない② Problem! C

Slide 63

Slide 63 text

© SEGA • 下位グレードの端末で以下の逆転現象が発⽣ ü 通信速度 > ファイルI/O速度 • 特にファイル I/O の回数がボトルネックに ダウンロード速度が出ない② C Cause

Slide 64

Slide 64 text

© SEGA • メモリマネージャの実装により解消 ü ⼀定のサイズまではメモリに書き溜めておく ü 上記サイズを上回った段階でファイルに書き込む • ⼀定のサイズの設定値には注意が必要 ü ⼤き過ぎるとこれまたボトルネックに ダウンロード速度が出ない② Solution! C

Slide 65

Slide 65 text

© SEGA ダウンロード速度が出ない③ C S クライアント事例 サーバ事例

Slide 66

Slide 66 text

© SEGA • 特定のタイトルでダウンロード速度が安定しな い問題が発⽣ ダウンロード速度が出ない③ Problem! C S

Slide 67

Slide 67 text

© SEGA • 帯域を使い切ることができないケースがある ü リスト上に⼩さいファイルが固まっている時 ダウンロード速度が出ない③ C Cause 使⽤可能な回線帯域 ここが使えていない︕

Slide 68

Slide 68 text

© SEGA • ダウンロードリストの作り⽅を⼯夫する ü ランダムに⼊れ替えるだけでも効果あり ダウンロード速度が出ない③ ここの部分を使えるようになった Solution! C

Slide 69

Slide 69 text

© SEGA • ソートしてもダメなケース ダウンロード速度が出ない③ C Cause 使⽤可能な回線帯域 (⾼速) 帯域次第で使い切れないケースが発⽣

Slide 70

Slide 70 text

© SEGA • ファイルの同時ダウンロード数はサーバ固有 ü HTTP/2的にはストリーム最⼤数と表現 ü RFC的にはMAX_CONCURRENT_STREAMS • クライアントとサーバで別 ü お互い⾃分の受付可能なストリーム最⼤数を送り合う ダウンロード速度が出ない③ C S Cause

Slide 71

Slide 71 text

© SEGA • コネクション数を増やすことにより解決 ü 使⽤していたCDNのストリーム最⼤数が変更不可 • 最⼤3コネクションまで張る仕様とした ü 300〜400ストリームで安定感のある速度になった ü 例 : 200Mbps ÷ 384 (stream) → 65kb (1filesize) ダウンロード速度が出ない③ Solution! C

Slide 72

Slide 72 text

© 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 を参考

Slide 73

Slide 73 text

© SEGA • .Net 6のHTTP/2の機能でも同様の議論有り ü ストリームが上限に達したらコネクションを追加する ü https://github.com/dotnet/runtime/issues/35088.Net ダウンロード速度が出ない③ Appendix C

Slide 74

Slide 74 text

© SEGA ダウンロード速度が出ない④ C S クライアント事例 サーバ事例

Slide 75

Slide 75 text

© SEGA • 特定のタイトルでのみダウンロード速度が極端 に低下する問題が発⽣ ダウンロード速度が出ない④ Problem! C

Slide 76

Slide 76 text

© SEGA • ファイル処理負荷が⾼い構成だった ü 1ディレクトリ下に⼤量のファイルを保存 ü ハッシュ化した⻑めのファイル名を使⽤ ダウンロード速度が出ない④ C Cause

Slide 77

Slide 77 text

© SEGA • ⼀時ファイルの処理を変更して回避 ü 専⽤のディレクトリを⽤意 ü 短いファイル名(内部的なリクエスト番号) ダウンロード速度が出ない④ Solution! C

Slide 78

Slide 78 text

© SEGA 速度出ない問題との闘いに終⽌符

Slide 79

Slide 79 text

© SEGA ダウンロード速度が出すぎた C S クライアント事例 サーバ事例

Slide 80

Slide 80 text

© SEGA • とあるタイトルの⼤型アップデート時に、CDN のデータ転送レート設定上限値を超える通信量 が発⽣することが判明した ダウンロード速度が出すぎた Problem! C S

Slide 81

Slide 81 text

© SEGA • CDNによってはデータ転送レートに制限が掛 かっていることがある • Amazon CloudFrontの旧制限は40Gbps (※) ü 200Mbps出る端末の同時ダウンロード可能数 Ø 40Gbps ÷ 200Mbps = 200 (端末) ダウンロード速度が出すぎた S Cause ※2020/5/20に150Gbpsに更新された

Slide 82

Slide 82 text

© SEGA • 混雑時間帯のみHTTP/1.1へダウングレード • お⾦で解決するのも⼿ ü 制限があるCDNも転送レート上限の引き上げが可能 な所がほとんど • CDN選定条件にデータ転送レートも考慮しよう ダウンロード速度が出すぎた Solution! C

Slide 83

Slide 83 text

© SEGA ファイルオープンエラー発⽣ C S クライアント事例 サーバ事例

Slide 84

Slide 84 text

© SEGA • タイトル側でファイル上限エラーが発⽣ • HTTP/2ライブラリは以下の80%を上限に使⽤ ü Windows (VCRUNTIME) : _getmaxstdio ü Android/iOS : /proc/self/limits ファイルオープンエラー発⽣ Problem! C

Slide 85

Slide 85 text

© SEGA • iOS11でファイルオープン上限数が256に • 結果、タイトル側でファイルリソースが枯渇 ü 256 * 0.2 = 51 ファイル ファイルオープンエラー発⽣ C Cause

Slide 86

Slide 86 text

© SEGA • 上限数の変更を⾏う実装に修正 ü setrlimit/getrlimitを使⽤ • タイトルのファイル使⽤上限を受け取るように ü setrlimit/getrlimitが効かない端末対策 • ファイルオープン数の削減 ü オープンタイミングの⾒直し ファイルオープンエラー発⽣ Solution! C

Slide 87

Slide 87 text

© SEGA ファイルのrenameに失敗 C S クライアント事例 サーバ事例

Slide 88

Slide 88 text

© SEGA • 特定の端末でのみダウンロード完了後のファイ ルのrenameに失敗する問題が発⽣ ファイルのrenameに失敗 Problem! C

Slide 89

Slide 89 text

© SEGA • Android11からExternalStorage境界をまたぐ rename(POSIX)呼び出しが禁⽌ ü Javaはコピー&削除にフォールバックされる • 以下の境界をまたぐとNG ü PublicDirectory(Download), Cache, Files, Files(Download), Media ファイルのrenameに失敗 C Cause

Slide 90

Slide 90 text

© SEGA • Android11でも必ず再現する訳ではない • sdcardfs採⽤のカーネルでは発⽣しない ü cat /proc/filesystems の結果にsdcardfsがあれば発 ⽣しない ファイルのrenameに失敗 C Cause

Slide 91

Slide 91 text

© SEGA • ファイルのrenameが失敗する端末ではコピー& 削除にフォールバック • renameに⽐べパフォーマンスペナルティあり ü ExternalStorageの境界を跨がない設計をお勧め ファイルのrenameに失敗 Solution! C S

Slide 92

Slide 92 text

© SEGA タイムアウトしない C S クライアント事例 サーバ事例

Slide 93

Slide 93 text

© SEGA • データを全くダウンロードできないにも関わら ず、タイムアウトが発⽣しない問題が発⽣ タイムアウトしない Problem! C S

Slide 94

Slide 94 text

© SEGA • HTTP/2特有のコネクションクローズ問題 ü コネクション切断時に送信されるGOAWAYフレーム がロストしたことが原因と推測 • 複数のストリームが⾮同期に絡むのでHTTP/2の コネクションクローズの実装は複雑となりがち タイムアウトしない C S Cause

Slide 95

Slide 95 text

© SEGA • 独⾃のタイムアウト処理を追加した ü タイムアウト判定時にはハンドシェイクからやり直し • graceful shutdownに対応したサーバやライブ ラリを使っていれば不要 ü サーバ側が担保できなかったので独⾃に実装 タイムアウトしない Solution! C S

Slide 96

Slide 96 text

© SEGA iPhoneで通信中に不正終了 C S クライアント事例 サーバ事例

Slide 97

Slide 97 text

© SEGA • ダウンロード中に極稀に不正終了が発⽣ ü 検証環境では7万回に⼀回程度発⽣ iPhoneで通信中に不正終了 Problem! C

Slide 98

Slide 98 text

© SEGA • 利⽤しているOSSの不具合だった ü HTTP/2のconnection reuse発⽣時に加えていくつか の条件を満たした時のみ発⽣ ü 数千〜数万ファイルを⼀気にダウンロードするのは ゲームくらいなのでレアなものを踏む iPhoneで通信中に不正終了 C Cause

Slide 99

Slide 99 text

© SEGA • その後OSSの更新で無事に修正された • HTTP/2のゲーム活⽤も枯れてきている ü 他社の⼤型タイトルでも採⽤が増えてきた iPhoneで通信中に不正終了 Solution! C

Slide 100

Slide 100 text

© SEGA HTTP/2独⾃の設定をしたい C S クライアント事例 サーバ事例

Slide 101

Slide 101 text

© SEGA • 5G時代に備え、もっと速度を……︕ ü HTTP/2独⾃の設定をカスタマイズすればいけそう︖ • 設定例 ü HPACK Dynamic Table設定 ü ストリームの初期ウィンドウサイズ HTTP/2独⾃の設定をしたい Problem! C S

Slide 102

Slide 102 text

© SEGA • 諦めた ü 利⽤しているOSSは設定を内部パラメータとして隠蔽 ü CDNも設定できない場合が多い • OSS選定のタイミングで考慮しておこう HTTP/2独⾃の設定をしたい Solution! C S

Slide 103

Slide 103 text

© SEGA インターネット全体への波及効果

Slide 104

Slide 104 text

© SEGA インターネット全体への波及効果 コネクション数削減による効果

Slide 105

Slide 105 text

© SEGA ゲームはコネクションを多数⽤いる アセットダウンロード ランキング ゲーム通信 チャット

Slide 106

Slide 106 text

© SEGA • コネクション数の増加はそのままインターネッ ト上に存在する中継器の負荷増⼤に繋がる コネクション数による負荷増⼤

Slide 107

Slide 107 text

© SEGA • ⽇本をはじめ全世界に余裕がない状態 インターネットは社会全体の資源 総務省 :我が国のインターネットにおけるトラヒックの集計・試算 2020年11⽉分の集計結果 より

Slide 108

Slide 108 text

© SEGA • HTTP/2であれば従来に⽐べてコネクション数を ⼤幅に削減可能 ü 多重化 ü コネクションの再利⽤ HTTP/2によるコネクション数削減

Slide 109

Slide 109 text

© SEGA • Webブラウザや動画ストリーミングサービス等 の⾮ゲーム分野ではコネクション数は減少傾向 ⾮ゲーム分野では既に導⼊が進んでいる Web Almanac 2020 HTTP/2 - HTTP/2のインパクト より

Slide 110

Slide 110 text

© SEGA HTTP/2のゲームへの導⼊のメリット 開発者 ユーザ体験の向上(離脱率低下) ユーザ ダウンロード待ち短縮 インターネット 負荷軽減

Slide 111

Slide 111 text

© SEGA コネクション数削減による効果 HTTP/2を使って 開発者、ユーザ、インターネット に優しいゲーム作りを⽬指そう︕︕

Slide 112

Slide 112 text

© SEGA インターネット全体への波及効果 ゲームのデータ配信とトラフィック

Slide 113

Slide 113 text

© SEGA • AAAタイトルの発売⽇や⼤型アップデートの⽇ にインターネットトラフィックが⾮常に混雑す るというのが最近問題になっている ü CEDEC 2020 [JANOG×CEDECコラボセッション] インターネットとゲームトラフィック でも話題に ゲームのデータ配信の影響

Slide 114

Slide 114 text

© SEGA • ゲーム業界はインターネットを使わせてもらっ ている⽴場 ü 少しでもインフラへの負荷を減らすべき • 必要になったタイミングで都度ダウンロード ü モバイルゲームでは採⽤しているタイトルも多い ü ⾮モバイルゲームは⼤型パッチが主流 データ配信⽅式の転換の提案

Slide 115

Slide 115 text

© SEGA • ゲームの適正とよく相談する必要はある ü ジャンル ü プラットフォーム • 採⽤メリットも ü 従来に⽐べ管理や差し替えが容易になる パッチ配信とトラフィック

Slide 116

Slide 116 text

© SEGA まとめ

Slide 117

Slide 117 text

© SEGA • HTTP/2はアセットダウンロードに効果⼤ • HTTP/2はクライアントサーバ間の通信の効率 化にも効果⼤ • HTTP/2はインターネットにも優しい HTTP/2を使おう︕︕

Slide 118

Slide 118 text

© SEGA ご清聴ありがとうございました