Skip to main content

ログ取得ツール (移転先予定地)

DAZN考察

DAZNに勝手なことを言うのが流行りなのかと思うので便乗していこう。

見てると主要なやりとりである動画データ部分はakamai(=当代最強のコンテンツデリバリ屋)を使っていて、たまに挟まってJSONでメタデータをやりとりしているcws.conviva.comはAWSのELBを使っている。これ、対処した後の状態かもしれないが、問題がある構成とは思えません。

あとweb font(?)を置いているcdn.dazn.comは自前のCDNのようなホスト名だが、これもAWSのCloudFrontでレイテンシは10-20msだから国内だろう。Server: AmazonS3だから、スタティックコンテンツとしてS3にwoffを置いてCloudFrontを噛ませているんじゃないかと。常識的。

だから、アクセス集中に対応しきれないとかいう問題ではないと思う。Jリーグ中継というレベルであれば、akamaiに十分なお金を払えば楽にさばけるデータ量。当然、akamaiからのレスポンスタイムはTTFB(Time To First Byte)で見ても10ms未満で明らかに国内から来ている。気になる部分としては、cws.conviva.comのレイテンシが常に100ms以上かかっているが、これはAWSのus-west-2リージョンを使っているため。小さいデータなので問題なさそうにも思えるが、もしレスポンスタイムが効いてくるなら日本向けにはap-northeast-1(tokyo)を使えば少しは良くなると思う。

たぶん中継機器からどこかを通ってakamaiにデータを送るんだと思うけど、そこがダメだった可能性はあるだろうか。1回(もしくは帯域別に数回?)akamaiまで通せばいいから、帯域は単純な設計に過ぎなくて、問題が起こりやすい部分とは言えない。ユーザの動向には依存しない。ユーザ集中の影響は単にakamaiに払う金額が変わるだけ、のはず。動画部分はそれで余裕を持って対応できたはず。

詰まった状態については詳しく見ていないけど、cws.conviva.comとのやりとりではないかと邪推している。DAZNの本体と言えるアプリサーバはcws.conviva.comなんだろう。Server: lighttpd/1.4.35で、常識的にはEC2に必要な台数ぶんデプロイされているんだろうと思う。アプリサーバか、その後ろのDBか、どこかで詰まるというシナリオは十分に考えられる。

結論としては、来週までにcws.conviva.comをap-northeast-1に引っ越し、かな? DAZNもワールドワイドにやってるから一律引っ越すことはしないだろうけど、その辺をうまくやる方法もあって、DAZNの人もどうにかできる技術は持っていると見た。

というわけで私はDAZN視聴の将来については楽観している。