CDN Study (Akamai/Fastly)
https://http2study.connpass.com/event/81469/
に行ってきたので、そのときのレポート
イントロ
資料
まず、jxckさんから
CDNの変遷(変化)
昔
edgeの数こそ正義
そのあと
edgeの数よりは同じurl使ってることが良いよねってなった
jqueryのダウンロードを他のサイトでやってたらキャッシュされるよねとか
さらに
cloud cdnが出てきて敷居が下がった。
今
ただのファイルだけじゃなくて、
imageを最適化してくれるとか
ddosに強いとか
さらにedgeの中でいろんなプログラムが動いてたらいいよねとか
cdnが前提になりつつある今
パフォーマンスやセキュリティの面から
edgeが正義という感じではなくなってきた。
縁の下の力持ちという感じではなく、
もっと前へ前へと出てきている感じがする。
Akamaiの方(岡本さん)の話
※悪魔で個人(登壇してくださった方)の見解です
資料
CDNの過去と現在
各CDNベンダの歴史を見てみる。
一応、CDNですと言って出てきたのは1995年にAkamaiが初
そのころ、今のインターネットはコンテンツ配信が中央集権的なものになってしまって
限界があるだろうと言われていた。
http://as2914.net/
というサイトで、インターネットの地図が見れる。
すごい
このサイトからも分かるように、インターネットはとても複雑な網目状になっているのに対して
配信箇所が一箇所だと、渋滞が起きてしまうだろう。
1998年にstar warsの映画の予告編が公開された
これが、「インターネット最大のダウンロードイベントだった」と、スティーブジョブズが言っていたらしい
このように、コンテンツが一気に様々なところからDLされるということがあり
このままではインターネットは壊れてしまうと予想された。
世界で動画を配信するような設計に、インターネットはなっていなかった。
このようなことからCDNの必要性が出てきた。
CDNの基本的な考え方
ユーザーの近くに必要なファイルのコピーがあればよいではないか。
akmaiの仕組み(ほんの一部)
Akamaiはpop数(edge数)が他のCDNベンダーと比べてダントツで多い(桁が1桁違う)
世界中に数多くあるのがAkamaiの特徴
ただ、数が多いと大変という話
ユーザーをどうやって最適なedgeに誘導するのか
→ DNSの名前解決の時点でアクセス元によって応答を動的に変える
→ 実は、これはAkamaiの特許(2019年で特許が切れる。)
Google Public DNSとAkamaiが相性が悪いという話
→ 全てが8.8.8.8からきてしまうと、区別がつかない
→ 今は別に相性が悪くなくなっている
最適なエッジサーバー群とは?
CPUバウンドやネットワークバウンドなどいろいろな要因があるなかで最適なedgeを探すのは難しい
→ 安定結婚問題、gale-shapleyアルゴリズムを当てはめている
Akamaiのedgeサーバーの構成
- 高機能な独自開発httpサーバー
- xmlベースのdlsでロジックを組む
- 膨大な機能があるため、したいことは現場のエンジニアレベルで大抵できる
→ なので、この問題はUSに問い合わせないと…ということがあまりない。
せっかく近くにいるのだから、もっと高度な処理をしたいよね
例えば、セキュリティ対策など
岡本さんがCDNでしたかったこと、していること
- ddos対策
- waf
- スクレイピング対策
- 画像動画htmlなどを自動的最適化
- webサイト全体
- apiをキャッシュから出して応答を速く
- 静的ファイル配信はまかせたい
- sslセッション数が多すぎるので対処
- インターネットの経路の不安定さを解決
CDNのもともとの名前の意味としても
現状は大分変わってきている
Akamaiの動き
bot managerやimage managerをリリース
最近だと、2018年にedgeで動作するjavascriptを開発中。
Akamaiの方(塲田(ばだ)さん)の話
資料
Akamai も標準化へ参加している
CDNがどんどん進化していくのも必要だし、ブラウザもどんどん進化する必要がある。
CDNベンダーもブラウザと共通言語で話せる必要がある。
新しいプロトコルを使いたいとなった場合もブラウザの対応が必要になる。
Akamaiによるhttp2
ユーザからhttp2でリクエストをしてもらい、Akamaiで受け、http1.1でwebサーバーに流すなど
real user monitor(RUM)
→ このページを見たユーザはこのページも見そうだから、
このcssとjsを送るようにしよう
というアルゴリズムを作ったりしている。
QUIC
https://blogs.akamai.com/jp/2017/05/udpquic—akamai-media-acceleration.html
TLS1.3
draft21もしくは23に対応したopensslを使えば、AkamaiとTLS1.3で通信ができる
CDNの未来
edgeはどこか?
→ 今後、もっとedgeがユーザの近くになるのではないか
携帯電話会社なのか、電柱なのか、スマホの中なのかとかとか
edge computing がくるぜ!っていう論文もある。
The Emergence of Edge Computing
http://elijah.cs.cmu.edu/DOCS/satya-edge2016.pdf
- コンテンツ予測配信
- 携帯電話専用回線網
- デバイス間コンテンツ共有
- などなど、、、
webガバナンス強化のためのCDN
様々なドメインでサービス配信してる時に、メインサービスは脆弱性対応しているが、全てのサービスに手が回ってないとか
自分の会社のサービスはどこが守れていてどこが守れていないのか
どこがcipher suite しているのかしていないのか
そういうことを管理できるようにしよう。
取り入れられそうなこと
開発後にチューニングとしてCDNを取り入れるのではなく
CDNを最初から考え、どの程度のTTLなら許容できるのか、キャッシュはどのようにしようかなど設計しましょう。
cacheabilityの観点からのアプリケーションのモデリングをしよう
- キャッシュの時間設定などが、ボトムアップだったり、良い設計ができていなかったりする
- キャッシュの生存時間を変更できるようなアプリケーション
Let’s Encrypt
Akamaiを使えば、Let’s Encryptとの連携も比較的簡単にできるよ!
→ Let’s Encryptをそのまま使うとなると、 cert bot などちょっと癖があるが、
そういうのを簡単にできたりするよ。
Q & A
Q1.
cacheabilityに関して、
それを取り入れるのが難しいと思うが、
webアプリケーションフレームワークの中にcacheの機構を持たせるようなことができたらハードルが下がりそうではないか?
A1.
たしかに、その視点はなかったが、それは良さそう。
Q2.(岡田さんから)
Multi CDN の話とかがあるが
A2.
あんまり凝ったことをしたいわけではないのなら、singleでやったほうがいいと思う。
Q3.
server pushってクライアント側の情報がわからないと難しいと思います。
cacheダイジェストなどもあるが、Akamaiさんの中でどのくらいserver push が使われていて、どのくらい早いのかとか教えてほしい。
A3.
アルゴリズムの際に、機械学習などを利用しているという風に、岡田さんは聞いている。
Fastlyの方(奥さん)の話
※悪魔で個人(登壇してくださった方)の見解です
資料
Fastlyのpop設計
キャッシュヒット率を高めたい。
- コンビニモデル
→ ユーザの近くにたくさんのpop
→ メリット:底レイテンシ
- スーパーマーケットモデル
→ ixの近くに巨大なpop
→ メリット:cacheのヒット率をあげることができる。
Fastlyは主にスーパーマーケットモデルを採用している。
popのキャパ
1Tbpsクラスのネットワーク
32台のクラスタ
Fastlyはルータレス、ルータを使っていませんよ。
32台のサーバーがルータも兼ねている
ロードバランサ
大量のリクエストをさばくにはコストが高い。
ECMPという技術
→ これも問題がある
→ 外すタイミング問題
→ ステートレスロードバランサというやり方をしている
→ クラスタの応用、ノードにあるサーバが知っている通信は別のサーバに流さないし、知っていない通信は別のサーバに流す。
他社と比べて
http2も早い
まとめ
FastlyはAkamaiとは違い、スーパーマーケットモデル
→ そのために、スケールアップ・スケールアウトの仕組みをソフトウェアを使って実装している
VCLについて
VCLができること
- リクエストのルーティン具
- リクエストの書き換え
- レスポンスヘッダの書き換え
- リクエストの再送(回数制限あり)
- etc…
パージ
- URLを指定してパージできる
- キーを指定してのパージ
→ 特定のキーがついたキャッシュをまとめてパージできる
→ 例えば、jsやcssのファイルを一気にパージしたいとき、特定のキーを持たせておいて、それをパージさせる
→ メリット:url単位での参照、パージができる
ヒット率の高いキャッシュ率を実現するには
- 大容量のキャッシュ
- インスタント・パージ
- shielding
他には
- waf(web application firewall)
- ddos対策
→ ddos対策をしながらも、他のお客さんにも迷惑がかからないような仕組み
- edge-side includes(Akamaiでもやっているし、Akamaiからの移行もしやすそう)
CDNの歴史とこれから
- プロトコル上の制限がボトルネックに
- スマホの普及
- スノーデン事件
→ 大規模な情報を管理する上で、プライバシー保護について厳しくなった
このようなことから、インターネットとプロトコルが進化してきた。
プロトコルの進化の方向性
- 全ての通信の暗号化
→ ルータとかでの通信の硬直化をしないようにしよう
- 迅速なセットアップ
→ リンクを端末にpushし、それがブラウザ上にあるか確認したりする
- ネットワークをまたいでも途切れない通信
- 劣悪な環境でも粘り強く通信をするように
- DNS over https
→ DNSからのクエリなのか、CDNからのクエリなのか分からなくなるので、セキュア
- cache diggest http
→ オリジンの処理中にCDNからアセットを配信
- server timing
→ 配信タイミングをjsで取得
- secondary certificates
→ 1本のTLS接続で複数の証明書を使う
- short term cert
→ ある国では、証明書は政府で管理しましょうとなっているところもある。
できるだけ秘密鍵が漏れたときの影響を少なくしよう。
- variants
→ varyのキャッシュ爆発の問題を対策
QUICの目標
- 1個目のパケットが処理できなかったとしても、2つ目3つ目のパケットを処理できるようにしたい。
- 進化を続ける通信プロトコル
→ tcp first open という機能は、8年間実装にかかったりした。
それは、アップデートを邪魔をするルータがいたりしたため。
→ アップデートに妨げられないプロトコルが必要
- 相互接続試験をやりながら、各社プロトコルを実装している。
→ googleはGquicというものを使っているが、だんだんIquicというものに近づけている。
そのような動きもある。
- Fastlyもプロトコル標準化に参加している
まとめ
CDNとしてのミッション
- より安く、より速くコンテンツを配信
- 全世界的な分散kvs
- edge cloud
- プロトコル進化の促進
Q & A
Q1.
web packagingについてどう思いますか
A1.
ampの問題などがあるが、web packagingのような技術が標準化されるのはいいと思う。
Q2.
ネットワーク回線も問題になりがち。配線や回線について工夫しているところはあるか?
A2.
私はsoftware engineerなので言えることは少ないが、
弊社はコンテンツ配信の一点特化なので、それに合わせた設計をしている。
例えば、ルータレスルーティングとか。
Q3.
Fastlyはvarnishが元になっていたりして、edgeのほうにバグが発生することも考えられるが
そのようなものに対してテストをやるための仕組みはあるか?
A3.
お客さんがテストするような仕組みは…ちょっと分からないです。開発の中でもテストはあると思うが。
ちょっと他の人に聞いてほしいです。すみません。
Q4.
標準化の中でデータを公開する話とかどうなってますか。
A4.
そこがやはり議論になっていて、何を見せて何を見せないかっていうのをちゃんと考えている。
例えば、うっかりルータから見えてはいけない情報が見えたりとか。
なので、何を見せるのか、見せない代わりに何か別のものを見せるとか、そういうのを明文化している。
Q5.
CDNでwafとかddosの話も出ている。
ただ、動的なコンテンツを配信しているwebサーバもあり、どこまでを通すのかというのが難しいと思う。
どこが適材適所なのかという意見とかあるか。
A5.
FastlyはCDN会社なのでCDNでやってほしいと思うが、どうしても共用サーバであることの制約とかもある。
どうしても処理の重いこととかは、別なサーバーでやったほうがいいなどトレードオフはあると思う。