久しぶりにすごい人混みに身をおいたわ・・。
どんな勉強会だったか
- 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の解決策
- Stable marriage problem(安定結婚問題)
- Gale-Shapleyアルゴリズム
- Algorithmic Nuggets in Content Delivery
- 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の後に立つサーバーがHTTP1.1でも大丈夫
- ServerPushも一部対応
- CSS, JSが対象
- 測定用のJSを埋め込んで返す、そこで計測した内容を元にPUSH
- PiezというChrome拡張で、効果測定できる
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でクライアントの状況を把握するのはどういう具合？
- draft-ietf-httpbis-cache-digest-04 - Cache Digests for HTTP/2 みたいなのもあるけど
- 機械学習でよしなにやってます
宣伝: 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
- 1999年から2015年まで、進化に時間がかかった
- なぜ今なのか
- プロトコルの制限（通信速度など）がボトルネックになってきた
- スマートフォンの圧倒的な普及
- スノーデン事件
- 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はハードウェアオフロードやカーネルとは疎にしてく？
- カーネルに関係なく動くようにしてる
- 基本的にはユーザーランドで