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の方（塲田（ばだ）さん）の話

資料

CDN Study in http2study by bata from Toshiya Bata

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でやってほしいと思うが、どうしても共用サーバであることの制約とかもある。

どうしても処理の重いこととかは、別なサーバーでやったほうがいいなどトレードオフはあると思う。