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

シェアする

スポンサーリンク

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

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



Apple-Sept-9-2014-TV-Truck-Schedule



 ”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となっている。これは完全に非常識ではないが(我々はもっと悪いものを見ている)とても重い。それではこのページを分析してみましょう。


Apple-Live-Page-2014-September


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.



akamai


と、Appleのスペシャルイベントが世界中に与える影響を示唆している様です(DeepField のデータではAppleのライブ中継はワールドカップのピーク6.8Tbpsと同程度かそれを超え6~8Tbpsだったようです)。

 「9月のApple スペシャルイベントはAppleのウェブサイトよりApple TVの方が障害なく見えた」というのもこの辺が関係しているのかもしれません。

関連リンク:


Apple Special Event 基調講演のライブストリーミング開始直後に起こったカラーバー映像や中国語通訳に対する反応まとめ
b.hatena


コメント

  1. Apple7743 より:

    ぶっちゃけ公式サイトのTwitterキュレーションいらないよね…
    キュレーションシステムよりライブ感を大切にして欲しい

  2. Apple7743 より:

    配信が止まったのも残念だったけど中国語通訳が意味不明だった…