これは旧eviry tech blogから移行した記事です。
fujiwaraです。
2018/10/25に行われたFastly Yamagoya MeetUp 2018 に初参加してきました。
Fastly?
弊社メンバーから噂に聞いていたFastlyですが、イメージとしては静的コンテンツだけでなくAPI等にも使える変わった(でも高速な)CDN?というものでした。
イベント参加前に軽く調べてみると、エッジコンピューティングというものだそうです。
なるほど、AWSのAPI Gatewayも同じジャンルという扱いなのか。
とりあえず聞いてみたいポイントなど
というように全く無知の状態で参加することになったわけですが、とりあえずは以下のような点について知れたらいいな、とぼんやりながらも事前にポイントを決めておきました。
- ミルビィのWeb APIの高速化
１点張り(汗)。果たしてこのような内容が聞けるでしょうか。
内容
写真を一切撮ってきてないため、会場の雰囲気などは割愛...
気になった講演についてピックアップします。
Brightcove
ライブ配信(HLS)の低遅延配信の実験についてのお話とデモが興味深い。
ライブ配信において、次のセグメントTSファイルがまだ存在しない場合にダミー(空)のTSを返すことで低遅延が実現できるとのこと。
セグメントの生成やコピーを各エンドポイントで待つ必要があることがHLSの遅延の原因とされているのですが、
それを待たずに返すことで色んなオーバーヘッドが軽減されて遅延が減るという感じなのかな？と解釈。
ダミー部分の再送はするのだろうか？映像を途切れさせて次のセグメントの再生に移ってしまうんだろうかと細かいことが気になります。
実現には相当苦労してそうですが、次世代フォーマットのCMAFを待たずにHLSで低遅延が実現できるとなると、動画配信技術としてはなかなかエポックメイキングかも知れません。
サイバーエージェント
AmebaニュースのリニューアルでFastlyを使用したお話。
採用した理由は「使ってみたかったから」とのことで非常に素晴らしい。
カスタムVCLでCacheKeyを生成するあたりがウチでやりたいことのヒントになるかも。
Fastly
FastlyはFastly上で動いていてデプロイもFastlyの仕組みで行われている話。
これ、すごいカッコいいですよね。リスクは高そうですが安全に最大限に考慮した上で実現できているのが凄い。
感想、成果など
- ウチのAPIのキャッシュとしての利用となると前述のCacheKeyの生成のところがポイントとなりそう。
ただFastlyのカスタムVCLでないと実現できないのか？というと既設のCDNのキャッシュ設定だけでもなんとかなるのかも知れない。 - インスタントパージ(キャッシュの即時削除)が便利そうだけど、実例・事例が聞けなかったので、具体的なイメージがまだ湧かない。
- いきなり導入してみるよりは既存のものの調整でどうしても解決できない点が出てきてからでも良い気もした。
インフラ寄りの特定のベンダーのセミナーというのは個人的には興味の薄いジャンルのため、なかなか参加する機会はなかったのですが、内容や会場の雰囲気も含めてなかなか楽しいイベントでした。
次回も参加してみたいところです。