CDN Study (Akamai/Fastly) 参加メモ

勉強会メモ
CDN / Fastly / Akamai

4/13に開催されたCDN Studyに行ってきました。

抽選発表の時点で補欠70番台ぐらいでしたが、当日の19:00過ぎくらいに繰り上がって参加できるようになりました。
会場の入り口で張っていた甲斐がありました！

当日に取ったメモをアップします。

今回のテーマの主旨

導入スライド

昔と比べてCDNの世界観(※1)が変わっているので、AkamaiとFastlyの中の人にそのあたりの話を聞いてみよう、という会。

※1: 昔は単純なキャッシュとしての用途でエッジの数が多いことが正義な時代だったが、今はやれることが増えてきていてキャッシュに留まらなくなっていることを指す

Akamaiの中の人の話

発表スライド 岡本さんパート
発表スライド 塲田さんパート

  • 登壇者
    • 岡本さん
    • 塲田さん

CDNの過去と現在

  • インターネットは複雑で網の目のような構造になっている
  • 年々増加するトラフィック
  • 複雑でファイルの配信は大変なので、ユーザの近くにサーバを置けばよい、というのがCDNの基本コンセプト
  • 世界中に置かれたエッジ
    • Akamaiは1700以上のエッジを持っている！
  • ユーザをどのように最適なエッジに誘導するのか
    • DNSの名前解決の時点でアクセス元によって応答を動的に変えている(Akamaiの場合)
      • (この技術はAkamaiが特許を持っており、2019年で特許が切れる。)
      • この方式はGoogle DNSのようなPublic DNSと相性が悪い？
        • 昔の話。Googleとデータのやりとりをして誘導できるようになっている。
        • 最近Cloudflareが出した1.1.1.1から来られると厳しい
  • 各サーバの混雑具合をみながらどのようにリクエストを分散すべきか
  • Akamaiのエッジサーバについて
    • 高機能な独自開発のHTTPサーバ
    • XMLベースのDSLでロジックを組む
    • 膨大な機能があるため、したいことは現場のエンジニアレベルでかなりのことができる
  • CDNでしたかったこと、今できていること
    • インターネットの経路の不安定さに対応したい
    • SSLセッション数が多すぎてつらいのを対処したい
    • 静的ファイル配信は任せたい
    • Webサイト全体/APIをキャッシュから配信して応答を速くしたい
    • 画像・動画・HTMLなどpayloadを自動的に最適化してほしい
    • L7 DDoS対策/WAF/Bot&スクレイピング対策をしたい
  • 要するにエッジで高度な処理をしたいというニーズが高まってきた
    • もはやContents Delivery Networkというワーディングは適切なのだろうか

CDNベンダによる標準化への参加

  • AkamaiにおけるHTTP/2
    • HTTP/2はAkamai製品においてデフォルトで有効になる
    • akamai独自のアルゴリズムでできたServer Pushなども利用可能
    • オプション機能
      • Server Push
        • Real User Monitoringを利用
      • Pre-connect
      • Resource Optimizer
    • Chrome Addonの"Piez"を利用してAkamaiの機能を実感できる
  • AkamaiにおけるQUIC
    • Media Acceleration。ダウンロードやストリーミング配信で6/1より使用可能
    • HLS(細かいファイルを少しずつ取得していく配信方式)に要する時間はHTTP1.1の約半分となる
  • AkamaiにおけるTLS1.3
    • Draft21もしくは23に対応したopensslを利用すれば、既にAkamaiプラットフォームとTLS1.3で接続可能

CDNの未来

  • エッジはどこか
    • 昔はISPの中にあった
    • これからは前によっていく(クライアントデバイスに近くなっていく)のでは
    • いかにエンドユーザに近い場所にいけるか
    • 5G通信技術
  • IoTデバイス間通信(MQTT)
    • 中央サーバに寄らずにエッジ間でデータをやりとりする
  • Webガバナンス強化のためのCDN
    • サイト数多かったり、脆弱性試験回っていないサイトあったり、ドメインをわける必然性のないところはwww.hogehoge.comで見せたいだったり
    • ガバッとCDNかけてしまって一括管理してしまうやり方
  • Cacheabilityの観点からのアプリケーションのモデリングができないか？
    • ETag設計など、現時点で2015年時点とあまりうまく使われている印象がない
  • セキュリティ強化
    • AkamaiはLet’s Encryptの立ち上げメンバー
    • AkamaiでもネイティブでLet’s Encryptをサポートしている

質疑応答より

Q.Akamaiはエッジ数多いが、fastlyのようなインスタントパージは厳しい？
A.Akamaiは昔は7,8分キャッシュのクリアにかかっていたが、今は5秒でいけるようになってる。内部設計レベルから2回内部設計レベル2回変更されてそこまでの速度が出せるようになった。

Fastlyの中の人の話

  • タイトル: Fastlyのプログラマから見たCDN
  • 登壇者
    • Fastly 奥一穂さん
    • H2Oの開発者

FastlyのPOP設計

  • キャッシュヒット率を高めたい
  • Fastlyは50個のPOPを持っている
  • CDN業界ではPOP配置は2タイプ
    • コンビニモデル
      • Akamaiのように、ユーザの近くにたくさんのPOP
      • 低レイテンシ
    • スーパーマーケットモデル
      • IXの近くに巨大なPOP
      • Fastlyのモデル
      • キャッシュヒット率高
  • FastlyのPOPのキャパシティ
    • 最大1Tbpsクラスのネットワーク
    • 各POPは32台のサーバクラスタ
      • 768GBメモリ
      • 40TB SSD
    • これを高可用性・高効率で運用するのがFastlyのチャレンジ
    • スイッチとサーバだけでルーティングもロードバランサもやってる
      • ルータレス・ルーティング
        • 32台のサーバがそれぞれルータも兼ねている
      • ステートレス・ロードバランス
    • SSDキャッシュ
      • 独自のファイルシステム
      • 一般的なfsより緩い一貫性要件
      • SSDの特性に最適化

種々のトピック

  • VCLでできる色んなこと
    • リクエストのルーティング
    • リクエストの書き換え
    • レスポンスヘッダの書き換え
    • リクエストの再送
  • インスタントパージ
    • これにより、Fastlyは全世界的な分散KVSとも表現できる
    • パージ方式
      • URLを指定してのパージ
      • サロゲートキーを指定してのパージ
        • 特定のキーが含まれたキャッシュをまとめてパージ
  • Shielding

Edge Cloud

  • WAF
    • DDoS対策
      • CDNはネットワーク容量が大きい
        • 小さなDDoSは問題にならない
    • DDoSに対する専用のSink
  • 画像最適化
  • Edge-side Includes対応
  • マイクロサービス合成、認証

インターネットの進化とCDN

  • インターネットプロトコルの歴史
    • 1986 TCP
    • 1991 ウェブ誕生
    • 1996 HTTP/1.0
    • 1999 TLS/1.0
    • 2015 HTTP/2
    • 2018? HTS/1.3
    • 2019? QUIC
  • なぜ今になってアップデートが続いているのか
    • プロトコル上の制限がボトルネックに
    • スマートフォンの普及
    • スノーデン事件
      • プロトコル全体を暗号化したいという機運

プロトコル進化の方向性

  • すべての通信の暗号化

    • プライバシー保護と硬直化対策の両立
      • 硬直化対策:ルータでプロトコルを邪魔できないようにする

  • より迅速なセットアップ

    • 0-RTT,Push, Early Hints

  • ネットワークをまたいでも途切れない通信

    • 接続のハンドオーバーとマルチパス対応

  • 劣悪な環境下でも粘り強く

    • ヘッドオブラインブロッキングの解決、前方エラー訂正

  • CDNに特に関係のあるプロトコル拡張

    • DNS over HTTPS
    • Early Hints / Cache Digests for H2
    • Server Timing
    • Secondary Certificates
    • Short Term Certs. / Delegated Creds.
    • Variants

QUIC

  • QUICの目標

    • 0~1RTTでの接続確立
    • ネットワークをまたいでも途切れない
    • プロトコルの進化を続けるような基盤にしたい
      • カーネルやルータの影響を排除
      • アップデートできないデバイスは長期的に見て邪魔になる

  • 標準化進捗

    • トランスポート層の設計は固まりつつある
      • 残件
        • ハンドシェイク設計のリファクタ
        • (もう一件なんだったか…追いつけず)

濃ゆい濃ゆい会でした。話を聞いていて咀嚼しきれなかった部分も多々。
Twitterのタイムラインみていると、どうやらFastlyのBlogとかで内部の技術に関する記事もあがっているとのことなので、また時間のあるときにチェックしてみようかなと思っています。