Cloudfrontの仕組みを知りたい

Question

実現したいこと

Cloudfrontの仕組みを知りたいです

前提

こちらにAWSで利用されているIPアドレス一覧があります。
この一覧は公式情報です。
常に最新の情報が提供されています。
https://ip-ranges.amazonaws.com/ip-ranges.json

serviceにCLOUDFRONTが付いているIPアドレス範囲がCloudfrontで利用されているIPアドレス範囲です。
とても多くのIPアドレスがCloudfront用として利用されているようです。

質問

何故多くのIPアドレスが必要なのでしょうか？

調べたこと

IPアドレスを多く利用しない方法としてIP Anycastという方法があるようです。

BGP経路情報をもとに最適な経路で通信がされるので、経路的に最適なサーバーが自動で選択されてIPアドレスも多く必要ないのでいい事ばかりのような気がします。
（おそらく多くのIPアドレスを持つ事は維持コストもかかると思うので）

こちらのような方式を利用すればCloudfrontでも1つのIPアドレスだけで良いのではないでしょうか？
なぜCloudfrontは多くのIPアドレスが必要なのでしょうか？

また、IPアドレスはregionがGLOBALになっており、全世界でIPアドレスがバラバラに利用されているようです。
IPアドレス範囲AはAWS東京リージョンだけで利用されて、
IPアドレス範囲BはAWS大阪リージョンだけで利用されて、
・・・
という事ではないようです。

GLOBALで利用されてIPアドレスが世界中のサーバーに振り分けられている状況でどのように最適なサーバーが選択されているのでしょうか？
仮にIPリストからラウンドロビンのようにランダムなサーバーが選ばれている場合、Cloudfrontのメリットである「高速伝送」「低遅延」と言えるでしょうか？日本から閲覧する場合は日本サーバーが近いので日本サーバー（東京または大阪）が選択されるべきという気がします。海外サーバーが選択されてしまうと遅くなるはずです。

それを回避するために何らかの処理をCloudfront内部的に行っているとすると多くのIPアドレスが必要なCloudfrontの今の仕組みはIP Anycastと比べるととても複雑な仕組みになっているように思います。

また、多くのIPアドレスがあるということは多くのサーバーがあるということなのでCloudfrontのキャッシュヒット率も相当低くなるのではないでしょうか。
CloudfrontのIPアドレスは追加され続けているようです。今後もIPアドレスが追加され続けると更にキャッシュヒット率が低くなり続けると思います。
IP AnycastであればBGP情報をもとに常に最適なサーバーが自動で選択されるのでサーバーが増えたとしてもキャッシュ率は高いのではないでしょうか。
日本から閲覧する場合はAWS東京かAWS大阪が選択されるはずです。
現在のCloudfrontのようにアクセスするたびにランダムにIPアドレスが変化する事はないはずです。

※以下コマンドの結果は変化し続けます。
数秒単位では変化しませんが応答されるIPアドレスは変わり続けます。

$ dig a xxxxx.cloudfront.net

;; ANSWER SECTION:
xxxx.cloudfront.net. 60 IN    A       13.225.165.4
xxxx.cloudfront.net. 60 IN    A       13.225.165.29
xxxx.cloudfront.net. 60 IN    A       13.225.165.115
xxxx.cloudfront.net. 60 IN    A       13.225.165.52

仮に以下のような構成だとIPアドレスは少なくて良いですが（リージョンごとに1個で良いはず）
ロードバランサ自体がネットワーク帯域が多すぎて耐えられないのでダメという事でしょうか？
※インスタンス自体にはプライベートIPアドレスを付与して、グローバルIPアドレスは付与しない

参考

こちらの資料に目を通しましたがIPアドレスが多く必要な理由はわかりませんでした。
https://pages.awscloud.com/rs/112-TZM-766/images/AWS-29_AWS_Summit_Online_2020_NET02.pdf

Comments

[tmp]

参考にあがってる資料？ではなく広告だと思います。

Answer 1

何故多くのIPアドレスが必要なのでしょうか？

Cloudfrontの目的＝あらゆる場所からの静的・動的コンテンツへのアクセスを高速化する＋負荷分散＋可用性を高めること
⇒そのためにはエッジが地理的に広範囲かつ密度が高く網羅している必要
⇒広範囲かつ密度を高めるためにはたくさんのキャッシュサーバやリージョンが必要
⇒キャッシュサーバやリージョンがたくさんあれば、必然的にIPアドレスもたくさん必要

IPアドレスを多く利用しない方法としてIP Anycastという方法があるようです。

IP Anycastは古い技術。

GLOBALで利用されてIPアドレスが世界中のサーバーに振り分けられている状況でどのように最適なサーバーが選択されているのでしょうか？

仮にIPリストからラウンドロビンのようにラン？ダムなサーバーが選ばれている場合、Cloudfrontのメリットである「高速伝送」「低遅延」と言えるでしょうか？

IPリストからラウンドロビンのようにラン？ダムなサーバーが選ばれている

⇒ここが間違い。だから、「『高速伝送』『低遅延』と言えるでしょうか？」っていう主張？も筋違い。

ユーザーがオリジンのコンテンツに対してアクセスしようすると、CloudFront DNS という専用のDNSですぐに、ネットワークの利用状況・ユーザーへのコンテンツ提供可能速度・ユーザーとの物理的距離を勘案しつつ、かつキャッシュを持ってるエッジロケーションが提案され、そのエッジロケーションから転送が開始される。
つまり、キャッシュコンテンツ管理と経路案内を高速にやってるわけで、古典的なラウンドロビンとは異なる高度なことをやってる。

それを回避するために何らかの処理をCloudfront内部的に行っているとすると多くのIPアドレスが必要なCloudfrontの今の仕組みはIP Anycastと比べるととても複雑な仕組みになっているように思います。

⇒そもそも前提となる回避対象が違うので、この文自体が筋違いだが、「IP Anycastと比べるととても複雑な仕組みになっている」って点は正しい。だから速くて安定しててすごい。だからみんなAmazonに金を払う。

多くのIPアドレスがあるということは多くのサーバーがあるということなのでCloudfrontのキャッシュヒット率も相当低くなるのではないでしょうか。

ネットワークが太く（「AWS バックボーンネットワーク」）、キャッシュの配分が最適化されてるので、数が多いからといって、キャッシュデリバリーに影響がでるほどキャッシュサーバへの配分が遅くなるとか全く配分されないとかいうことはない。アクセスの多いコンテンツは優先的によりたくさんのエッジロケーションに高速にキャッシュされるし（アクセスもとに地理的な偏りもあれば、そのアクセス元に近いエッジにキャッシュされる）、人気のないコンテンツでもリージョン別エッジキャッシュとの連携によって、最低限の物理的距離は確保されてる。なにより数がたくさんあればあるほど、一番近くにキャッシュがなくても、次の近くにあるキャッシュを検索、そこにもなければ次の近くにあるキャッシュを検索、、、というように、短い間隔でどんどんヒット率を高めることができる、ってのはちょっと考えればわかると思う。

IP AnycastであればBGP情報をもとに常に最適なサーバーが自動で選択されるのでサーバーが増えたとしてもキャッシュ率は高いのではないでしょうか。

そりゃ、AWS並みに経路情報を選択・分岐できる技術が優秀でかつキャッシュサーバーもたくさんあってネットワークバックボーンも太ければ、AWS並みに高速になるかもしれないね。
そもそも「常に最適なサーバーが自動で選択される」ってのはCloudfront DNSが実現してること。

Answer 2

全て想像ですが、CloudFront って 2008年リリースの古いサービスなので、今となっては古臭い技術で作られたんじゃないですかね。

実際新しいサービスである AWS Global Accelerator では IP Anycast 使ってるわけですし。あと IP Anycast だと、なるべく AWS が管理する AWS Global Network 内で通信するというのがキモだと思うんですが、2008年に AWS Global Network というものがあったのか、あったとしてもどれほどよいものだったのかは疑問です。

昔は CDN と言えば Akamai や Limelight などの営業に見積もり依頼するところからスタートだったり、帯域指定した上での月額固定料金だったりなところが、「CloudFront ならコンソールからポチポチやるだけで CDN が使える！ しかも従量課金！！」というのは革命的であり、それが単一 IP かどうかなんてどうでもよかったので、AWS としては最速で立ち上げられる技術を使ったんじゃと思います。

Answer 3

解決してるのかどうなのかわからないので、ちょっと書いてみます。

まず、なんでそんなことが気になったんだろうなぁ、という根本的な疑問はあるんですが…。
※AWSが取得したIPをどう使おうがAWSの自由じゃない？
枯渇しそうなIPv4を濫用している！けしからん！とかなら気になった理由としてはわかるんですが。
IPAnycastはL3の技術なので、L7の技術であるCDNと同列で話すのはちょっと無理が。

IPがたくさんいるのはたくさんサーバーがあるからで、たくさんあればあるほどCDNとしては基本的には強いCDNです。
※より密度が高い。

技術論的な議論をするということになるとCloudFrontで読んでおかなければいけないのはおそらくWhitepaperですが、質問内容自体はそれ以前の話になります。
https://docs.aws.amazon.com/pdfs/whitepapers/latest/secure-content-delivery-amazon-cloudfront/secure-content-delivery-amazon-cloudfront.pdf

CDNというもののメカニズムはちょっと別にして、IPとIP Anycastにフォーカスします。

IP Anycast自体は特にDNSで非常によく使われていますが、CDNではまず使用されません。これはCloudFlareだろうがAkamaiだろうが同じです。

なぜIP AnycastがCDNで使用されないのか、というのをなるべく単純化して話してみますが、そもそもCloudFrontの話というよりもCDN自体の実装に関わる話になるかと。

CDNはなるべくクライアントに近い位置のサーバがオリジンからの応答を受け取ってキャッシュし、コンテンツを返す仕組みですので、なるべくたくさんのサーバがあちこちにあるほうが有利ですし、意味が出てきます。
キャッシュヒットの有効性についてはちょっと本題からずれすぎているのでここでは無視します。

主にBGPで広告されるIP Anycastですが、当然ながらL3レイヤの話であって、L7レイヤのことなんか気にもしません。
なのでL3レイヤのバランサなどではいいですが、L7レイヤで動作するCDNには（使えないわけではないが）使うには非常に大きな課題が発生します。

CDNでは、いったんいずれかのサーバとコネクション確立をしたら、同じサーバと通信します。IPの問い合わせがころころ変わるからと言って、通信中(Established)の通信コネクションまで切り替わるわけではありません。
一方、AnycastはL3の技術なので、L7のことなんかどうでもいいので、経路でより近い経路があれば、あるいは経路障害があれば別の宛先に切り替えてしまいます。それが、たとえコネクション確立中のものであろうが知ったことではありません。だってL7の通信の中身なんて見えないんですから。

結果何が起きるかというと、CDN（の特定の通信中のサーバー）との接続がいきなりぶった切られて、CDNの別の何も知らないサーバーに通信確立のための手順を全てすっ飛ばして、「通信途中のパケット」がいきなり送り付けられてきます。
当然、あたらしく通信先にされたサーバーはそんなもの受け取るわけもないので、通信は途中でコネクションロストします。
例えばデカいファイルをCDN経由でダウンロードしてる、動画をCDN経由で見てる、というのを想像してみれば、何が問題かイメージしやすいと思います。
httpは一度成立したコネクションを通じて、ひと段落するまでコネクションを維持してパケットのやり取りを続けていくものです。

ロードバランサーにIP Anycastをつけても同じことです。ロードバランサーのAnycastがhttpで有効に機能するのには、「結局最後に行きつく先は同じ」じゃないと成り立ちません。ロードバランサーもL3ならL7のことなんか原則何も気にしません。

これを解消するには、全世界中のCDNを構成しているサーバがすべてのコネクション情報を含めてタイムロスが極めて小さい状態で同期している、とかいう、インフラ屋に作ってくれって言ったら助走つけてぶん殴られるような要求仕様に仕上がり、ついでにお代のほうもおそらくとんでもないものに膨れ上がるんじゃないかと。AWSまるごと作るほうがまだ楽な気がします。

じゃあなんでDNSはいいんだよ、という話ですがそもそもDNSはコネクションにおいて「教えてくれ」「これだよ」という往復パケット１発しかありません。継続的に同じコネクションを使う、という動作そのものがないので、DNSにはAnycastがよく使われています。もともとUDPですし、パケットが迷子になったりしても応答なけりゃ次に聞く、という実装ですし。

というわけで、技術的に作れないわけではないですが、作る意味もなければ効果もありません。
そもそも選択肢にすら入ってきませんので、当然技術文書に「なぜIP AnycastをCDNに採用しないか」なんてことも書きません。

Answer 4

IPアドレスが少ないと不都合が多いのではと思います。

AWSのCloudFrontに限らずCDNは様々な顧客のサービスのトラフィックを一般ユーザーに転送します。
顧客は様々いて普通の企業からフィッシングサイト、違法サイトも含まれてしまいます。
(もちろんAWSをはじめとしたクラウドサービスプロパイダは対応しますが、すべてを防ぐことはできません)
これらの不正なサイトから身を守るために一般ユーザーや一般ユーザーが利用するプロパイダなどがIPアドレスをブロックしたとしましょう、その場合このIPアドレスを使用したサービスはこのユーザーから見てすべて使えなくなります。
現在一つのIPアドレスに一つのサービス、サーバーは少ないです。(CDNならなおのこと)
仮に少ないIPアドレスの場合全く関係の無いサービスのせいで一部のユーザーがアクセスできなくなることが起こりえます。
ユーザー自らブロックしたのであれば自己責任ですが、プロパイダや企業のGWルーターで止めた場合、一般ユーザーが知らぬ間に起こりうる事なので、ユーザーから見て障害が起きたと思われたり、顧客からAWSの障害だと思われてしまいます。

こういう事象対策にも大量のIPアドレスを保有し、割り当てているのでは無いかと思います。

Answer 5

IP Anycastがすごい機能かと思って読んで見ましたが・・・
IP Anycastの良い点は、ルーターは既存のままのファームで実現できることと、サーバーにIP切り替えなどの仕組みがなくても変更なしに切り替えれる。ルーターやサーバーを変更なしにできることがメリットですね。

CloudFront とは異なるものと考えた方がよいですね。
CloudFront 代わりにはならない点
まず、キャッシュ機能はありません。なぜならIPレベルの切り替えなので、キャッシュできないんです。あなたの示している資料では、しないと書いてありますができないんです。また、当然キャッシュしないので負荷軽減になりませんとも書いてあります。（後でもめる資料ですね。できないではなく、しないと書いてあるから、することも可能なのかと勘違いを誘ってる？。そこまではなくとも、ネガティブな表現をなるだけさけるとできないでなくしないと書いたのかもしれません）

また、経路変更による負荷分散も難しいです、なぜなら経路単位でしか切り替えができないので細かいコントロールができないからです。また、経路変更するとIPレベルでの切り替えなのでそれより上位のTCP接続などが切れてしまいますので頻繁に切り替えはできない。なので例で経路切り替え用途にあがってるのは、サーバーダウン時の切り替え程度です。あなたの資料もサーバーダウンが例に書いてありますね。（後でもめる資料ですね。サーバーダウン以外にも使える風に勘違いしてくれるが、実際にはサーバーダウン時にぐらいしか使えない）

グローバルIPの数については、CloudFront は、多数ですが、みんなで多数共有と専用１つだと思います。
IP Anycatのサービスでは、最低２つとあります。１つのサーバーで専用で２つだと思います。
となるとグローバルIPの数のメリットありますか？