9月に行われたAppleスペシャルイベントのライブ中継障害はAppleが新たに導入したTwitter Feed付きのライブページが原因？

Apple

10月のApple Special Eventが近づいてきましたが、iPhone 6/PlusやApple Watchが発表された9月のスペシャルイベントではAppleが公式に配信していたライブ中継がダウンしたり中国語の翻訳が流れるなどの事態が起こりました。これについてストリーミングメディアやサービスなどの情報を提供している"Streaming Media"が面白い記事を書いています。詳細は以下から。

2014.10.13

記事内に広告が含まれています。

　10月のApple スペシャルイベントも9月の様になるのでしょうか？詳細は以下から。

　10月のApple Special Eventが近づいてきましたが、iPhone 6/PlusやApple Watchが発表された9月のスペシャルイベントではAppleが公式に配信していたライブ中継がダウンしたり中国語の翻訳が流れるなどの事態が起こりました。これについてストリーミングメディアやサービスなどの情報を提供している”Streaming Media”が面白い記事を書いています。

　”Inside Apple’s Live Event Stream Failure, And Why It Happened: It Wasn’t A Capacity Issue（Appleのライブイベントストリーミングはなぜ失敗したのか、それは容量問題ではなかった）”という記事では9月のApple
スペシャルイベントのライブ中継の失敗をサーバー、コード（JavaScript）、CDNの点から議論しており

iPhone 6とApple Watchの除幕式となったAppleのライブイストリーミングは多くのユーザーがイベントを見ようとしたことによる災害から始まった。私はまず始めにその障害はAkamai（CDN）の処理能力問題と仮定したが、より深くそのイベントで使用されたウェブページのサイトのコードや要素、また彼らがどの様にAmazon S3（サーバー）サービスにそのウェブページをセットアップしたかを見てみると、それらがスペシャルイベントに大きな問題を与えている。

Apple’s live stream of the unveiling of the iPhone 6 and Watch was a disaster today right from the start, with many users like myself having problems trying to watch the event. While at first I assumed it must be a capacity issue pertaining to Akamai,
a deeper look at the code on Apple’s page and some other elements from the event shows that decisions made by Apple pertaining to their website, and problems with how they setup storage on Amazon’s S3 service, contributed the biggest problems to the event.

として、スペシャルイベントライブ中継の障害はAppleが新たに作成したライブ中継ページに問題があるのではないかと推測しています。

　この記事はコメント欄の指摘により、詳しい解説を”Learning from Apple’s livestream perf fiasco“の記事に譲っていますが、こちらの記事でも

Web Page Performance Testでライブサイトを見てみるとビデオストリーミング無しでページの重さは5790KBとなっている。これは完全に非常識ではないが（我々はもっと悪いものを見ている）とても重い。それではこのページを分析してみましょう。

Running the livestream page through WPT shows that even without the video stream the landing page weighs in at 5,790KB – not completely outrageous (we’ve all seen worse), but pretty hefty. Let’s break it down.

として、Appleが新たに作成したライブ中継ページのfeed.jsonやmax-ageを解説しています。

かなり詳しく解説されているので興味のある方には読んでいただきたいのですが、まとめると

・Appleは今回新たにTwitter Feedが埋め込まれたライブサイトを作った

・feed.jsonは www.apple.com から読み込まれている

・feed.jsonファイルは531.7KBで圧縮されていない（gzip圧縮されていれば57KB）

・画像はLores（Low-Resolution）とMediumが読み込まれている

・ヘッダを見るとmax-ageが10秒未満に設定されている

　以上より「意訳：非常に短いmax-age TTL（Time To Live）と圧縮ミス（gzipしなかった）により、Appleは自分自身にDDoS攻撃をしてしまった。”Combine that with a really short maxage TTL and missing gzip compression, and you’ve just created a self-inflicted DDoS.”」と解説しています。

　また、”Streaming Media”では

AppleはこのイベントのCDNにAkamaiのみを使用した。 (略）以下のグラフはウェブパフォーマンスを測定するCedexisによるものですが、キャッシュが使用されていないので驚くべきではないがヨーロッパでのAkamaiのパフォーマンスがイベント中98.5%（最大
96.5%）まで落ちている。

As for Akamai’s involvement in the event, they were the only CDN Apple used.
（略）
The below chart from third-party web performance provider Cedexis shows Akamai’s availability dropping to 98.5% in Eastern Europe during the event, which isn’t surprising if no caching is being used.