console.lealog();

@leader22のWeb系に関する勉強めもブログですのだ

CDN Study (Akamai/Fastly) に行ってきたメモ #CDN_study

Web

CDN Study (Akamai/Fastly) - connpass

久しぶりにすごい人混みに身をおいたわ・・。

どんな勉強会だったか

  • CDNにもいろんな歴史がある
  • あの頃のCDNといまのCDNでは、世界観も役割も変わってきてる
  • 気がする
  • ので、中の人に聞いてみよう！

という主旨の会。

from Akamai

資料は見つけたら

CDNの過去と現在

  • 1995年の時点で、中央集権的なWebは破綻するといわれていた
    • 中央集権型ゆえに
    • インターネットの混雑が問題になるだろう
    • from Tim Berners-Lee
  • インターネットは網の目
    • ただ実際は地震でケーブルが切れて不安定になったり
    • 去年のGoogleの経路のアレとかも
  • 爆発的なトラフィックによる負荷

CDNってそもそも

  • インターネットの不安定さを避けるためにどうすれば
  • ユーザーに近いところにコンテンツを再配置すればいいのでは

Akamai

  • そして1998年にAkamaiが創業！
  • PoP数は1700
    • 他社より1桁多い（圧倒的に多い）
    • Point of Presence = いたるところにサーバーがある
  • どうやって最寄りのサーバーを見つけるのか
    • DNSの名前解決の時点でアクセス元を把握
    • Aレコードを動的に変える
    • 2019年まではAkamaiの特許
  • 最適なエッジサーバーとは
    • CPU・ディスク・メモリなどなど、それぞれを使う処理がある
  • Akamaiの解決策
  • Akamaiのエッジサーバーは高機能
    • やりたいことはだいたいできると思ってよい
    • 日本のエンジニアだけでも
    • XMLベースのDSLで書ける

CDNでやりたかったこと（これまで・これから）

  • インターネットの経路の不安定さを解消したかった
  • 静的ファイル配信を速くしたい
  • 画像や動画などの配信も最適化（ストリーミングとか）
  • DDoS対策、Bot対策など
  • もはやContentsDeliveryNetworkではない
    • Akamai内部ではもうそう呼んでない
    • CloudDeliveryNetwork
  • CDNのEdgeでやろうとすることが増えてきた

CDNベンダによる標準化

  • IETFなどに社員を派遣してる
    • HTTP/2, QUIC, TLS 1.3などの標準化
  • ブラウザが進化しないと、CDNとしても意味ない

Akamai x HTTP/2

Akamai x QUIC

  • 6月より利用できる
  • HLSの動画ファイル10個の取得にかかる時間が半分になった

Akamai x TLS 1.3

  • 1.3が使える`openssl`のバージョン次第で、既に接続可能
  • CipherProfileを1.3専用に

CDNの未来

  • Edgeの位置が変わるのでは
    • もっとユーザー寄りに
    • 電話会社とか、電柱とか
    • 不動産と同じでロケーションだけがカギ
  • IoTが普及したら
    • MQTTにも対応したい
    • よりレイテンシを下げる必要が出てきそう
  • Webガバナンス強化のためのCDN
    • 社外向けのドメインを束ねられる
    • SSLのバージョンを一括管理できたり
    • 突然デカいファイルを貼られてもいいように
  • サービスの設計時からキャッシュを考慮する
    • サービス開始ではなく、もっと前から使っていく
    • キャッシュフレンドリーに作る
    • ETag
  • キャッシュ戦略をモデリングできないか考えてる

質疑

  • WAFに組み込めるSDKみたいなのあればいいのでは？
    • その通りですね
  • 標準化のWGに名前が出てこないけど・・？
    • WGのことは知らなかったけど、他社との協力はやってます
  • Edgeでできることが増えると、CDNの引越しがつらそう、学習コストとかもあるので標準化できない？
    • 他社とすりあわせることはなさそう
    • それぞれのCDNの独自性や競争力にもなるので
  • Akamaiのキャッシュパージ遅くない？
    • 昔は遅かったが今は5秒
    • やり方は言えないけど、内部的にがんばってる
  • ServerPushでクライアントの状況を把握するのはどういう具合？

宣伝: 6/21にAkamai Tech Summitってのをやります！

from Fastly

資料は見つけたら

Fastly

  • 2011年創業
  • 社員は400人くらい

PoP設計

  • CDNを使うからには
    • Cacheのヒット率を上げたい
  • Fastlyは50
  • PoP設計は2パターン
    • コンビニモデル: よりユーザーの近くにたくさん
    • スーパーマーケットモデル: 狙ったところに巨大なものを
    • Akamaiが前者、Fastlyは後者
  • 1つでTbps級のネットワークを処理できる
  • ルータレス・ルーティング
  • ステートレス・ロードバランス
    • サーバーのクラスタ自体が全体で協調してロードバランスする
  • 独自のfsでSSDの書き込みを最適化したり、各種チューニングはもちろん

全世界的な分散KVS

  • VCL(VarnishControlLanguage)でロジックを書ける
    • リクエストのルーティング・書き換え・再送
    • レスポンスヘッダの書き換え
  • URLで参照・キャッシュ
    • リクエストを書き換えて、任意のキーでキャッシュするKVS
    • サロゲートキーでもってパージしたりも
  • Shieldingというリクエストをまとめる技術
    • より上位のPoPにキャッシュがあるかも
    • → キャッシュヒット率に貢献

Fastlyの機能

  • Firewallもデフォルト
  • DDoS対策
    • 小規模のものなら問題にならない
    • 悪意のあるパケットをフィルタしたり
  • 画像最適化
  • EdgeSideIncludesもできる
    • Akamaiと相互乗り換えできます
  • MicroServiceをFastly上で構築
    • 日経新聞の例
    • 高度な例だが事例は増えそう

プロトコルの進化とCDN

進化の方向

  • 全通信の暗号化
    • プライバシー保護、硬直化対策
  • より速く
    • 0-RTTで返せるように
    • Push, EarlyHints
  • よりつながるように
    • ネットワークをまたいでも
    • 劣悪な環境でも
  • CDNに関連するプロトコル拡張
    • DNS over HTTPS
    • EarlyHints / CacheDigests for HTTP/2
    • Server Timing
    • Secondary Certificates
    • Short Term Certs. / Delegated Creds.
    • Variants

QUIC

  • TCP/2と呼んではいけない
  • 0-1RTTで接続確立
  • ヘッドオブラインブロッキング解決
  • ネットワークをまたいでも途切れないように
  • 今後も進化できるプロトコルにするために
  • 進捗
    • トランスポート設計は固まりつつある
    • ヘッダの詳細などはこれから

質疑

  • Web Packagingあたりの話はどう思いますか？
    • AMPみたいなものですよね
    • 標準化な方向に進むのはよいと思います
  • CDNだとネットワーク回線にも工夫があるのでは？
    • 専用のハードウェアを作ったりはしないだろう
    • ソフトウェア設計上の工夫は、話した通り
  • Edgeで動かせるスクリプトを手軽にテストできる仕組みは？
    • 開発用のツールはあるが、検証用のテスト環境はない
  • 暗号化が進むとデバッグなどがつらいのでは？
    • どこまで標準化するかが議論
    • 暗号化はするけど一部は見れるようにするとか検討されてる
  • どこまでCDNに載せるか指針みたいのはある？
    • CDN屋としては全部載せてほしい・・
    • が、基本的には共用サーバーなので重い処理はダメとか
  • QUICはハードウェアオフロードやカーネルとは疎にしてく？
    • カーネルに関係なく動くようにしてる
    • 基本的にはユーザーランドで