別スレでも質問しましたが、回答がつかないようなので。

CDNについて、教えていただきたいのですが、
1つのキャッシュサーバ(=IPアドレス)に複数のサービス利用者のキャッシュが格納されている。
(=CDN-UがY社以外も利用する)
って言うのが調べてみてもはっきりしませんでした。
ここについて解説されている記事など有りましたらタイトルとか教えていただけないでしょうか?
ご意見だけでもOKです。

たとえばakamaiはエッジサーバの数が世界中で24万ほど有るとのことですが、パッと調べた限り、
APNIC内でも最低20万以上のIPv4を保有しています。
IPv6になると1垓以上保有しています。
となると、FQDNごとは無理でも、サービス利用者のドメインごとにIPを割り当てることは可能かと思います。

記事も何も問題文図5の（1）を読めば一つのCDNが複数のWebページを割り当ててると読み取れると思いますが。

すみません。自分も整理しきれていないため、矛盾あるかもしれませんが、

CDNーUとは 「とある会社が提供しているCDNサービス」でよいですよね?
そして、Y-CDN-U-FQDNのIPアドレスとはCDN-UのエッジサーバのIPアドレスになりますよね?

このエッジサーバはY社しか利用しないのか、X社やZも利用するのか図5からは読み取れないかと思います。

自分の見解なので間違っているかもしれませんが。。

>>このエッジサーバはY社しか利用しないのか、X社やZも利用するのか
⇒エッジサーバはCDN-Uと契約している全ての企業が利用することになると思います。今回でいうとY社、Z(攻撃者)。
 
  CDN-Uが、仮に日本中に10台のエッジサーバを保有しているとして。
  関東、関西、九州などの利用者はそれぞれ「Y-CDN-U-FQDN」の名前解決で
  自分のいる位置から最も近いエッジサーバのＩＰアドレスを得て接続します。
  初回のアクセスなら、エッジサーバがオリジンサーバにコンテンツを取得しに行きます。
  2回目以降のアクセスであればキャッシュを保有しているのでエッジサーバがそのまま返します。

攻撃者ZもCDN-Uと契約しているとなっているため、
「Z-CDN-U-FQDN」も「Y-CDN-U-FQDN」も名前解決をすると、利用者の位置の最寄りのエッジサーバのアドレスを得るので、結果同じエッジサーバに接続すると理解していました。

ほげほげさん､ありがとうございます｡

他の方の回答をみても､TACなどの解答速報を見ても､
ほげほげさんの見解と同様に､あるエッジサーバはCDN利用者すべてのエッジサーバとして機能する｡
との前提で書かれております｡

ただ､10個程度ですが実際にNSLOOKUPを試したところ､すべて違うIPアドレスで返ってきておりました｡
試したのがAKAMAIなので､エッジサーバが多くたまたま重複しなかっただけかもしれませんが､
エッジサーバは国内に数千以上あるわけですから､すべてのリクエストに対し｢近くて負荷が低い｣サーバに分散している事が実現できるのか想像つきません｡
それよりは､サービス利用者に割り当てるエッジサーバを限定するほうが制御としては簡単な様な気がしてます｡(CPU制御技術のイメージ)

この質問自体は自分がエッジサーバのキャッシュはY社のドメインのものしか無いと､思い込み､その前提で回答したため､それが正解かどうか知りたかったのが始まりですが､
技術的にどうCDNの制御を行っているか気になってしまいました｡
あと､CDNの制御技術について公開されていないなら､採点者がどう認識しているかによって正解･不正解が変わってしまう点も気になります｡

自分がCDNサービス提供しているわけではないので個人の見解含みますが。

>10個程度ですが実際にNSLOOKUPを試したところ､すべて違うIPアドレスで返ってきておりました｡
⇒「10個の名前解決をしたサイト」は、
  どの企業でもよいですが例えばakamai社が提供するCDNサービスと契約して構築された企業のwebサイト、を10個試した、で合ってますか？
  それでバラバラのIPが返ってきたとするならば、akamai社の設計によりますが負荷分散をかなり細かくやっているんでしょうね。

>すべてのリクエストに対し｢近くて負荷が低い｣サーバに分散している事が実現できるのか想像つきません｡
>技術的にどうCDNの制御を行っているか気になってしまいました｡
⇒方法はいくつかあるかもしれませんが、パッと思いつく方法として負荷分散装置（ロードバランサ、ＬＢ）を導入すれば可能です。
  分散方法も設計によりますが、ラウンドロビンで各アドレスを尽きるまで順番に返したり、負荷状況やセッション数を監視して、セッション数が1つでも少ないサーバを優先的に返したり。
  いずれにしてもエッジサーバもアドレスも有限ですので、何パターン試す必要があるかは設計次第ですが、そのうち過去と重複したアドレスが返ってくることになるかと思います。

>サービス利用者に割り当てるエッジサーバを限定するほうが制御としては簡単な様な気がしてます｡
⇒これもCDNサービス提供する会社の設計次第ですが、実現可能ではあると思います。
  ただ1社のサイトのアクセス数ともらえるお金に対して、サーバやアドレスのリソースが無駄になるとか、
  利益、構築や運用の手間など、トータルで考えた時に、採用とならなかったのかもしれませんね。
  スレ主さんの案を採用しているCDN企業もあるかもしれませんし。

>CDNの制御技術について公開されていないなら､採点者がどう認識しているかによって正解･不正解が変わってしまう点も気になります｡
⇒制御技術の詳細についてはCDNサービス提供企業それぞれの設計次第になり、各社で異なるはずなので公開はされていないと思いますが、
  実現方法が有限である以上、正解･不正･部分点は示してもらえるのではないかと思ってます。
  ただ、採点者も人間で、どれだけ複数の人間で厳重にチェックしても、過去に1例たりとも手違いがなかったかどうかは不明ですよね。
  自分の採点結果を部分点含めて見れるわけでもないですもんね。合格か、不合格かという結果だけという。

>自分の採点結果を部分点含めて見れるわけでもないですもんね。合格か、不合格かという結果だけという。
そうなんですよね｡今回の場合､問の成否でどの様な制御を行っているか判断できるのですが､それがないので掲示板でお聞きする形となりました｡
採点については多重チェックかつ､ゆらぎの範囲を設定した上で行っていると思いますが､不服申立てができる仕組みがあると良いですね｡自分だったらそんな面倒なことはやりたくありませんが｡

>akamai社が提供するCDNサービスと契約して構築された企業のwebサイト、を10個試した、で合ってますか？
はい｡有名ドコロの名前を使って適当にXXX.comでnslookupして､akamaiが入っているやつだけで見ました｡
>これもCDNサービス提供する会社の設計次第
質問している途中で､自分もなんとなくコレかなっと思いました｡調べても出てこない以上､効率的なCDNの制御方法は非公開だなと｡
もしかしたら､研究レポートや特許を見ればわかるかもしれませんが｡

LBは自分も考えましたが､キャッシュのヒット率まで考慮するとなると､複雑になりすぎるかと思います｡負荷が低いかつキャッシュを保有してそうなエッジをどう見つけるか･･･｡
また､エッジサーバは有限ですが､Webサイトの数は17億と言われていますので､
ipv6を用いた場合､事実上無限です｡そして､サーバ(=ポート)に対し､複数のIPアドレスが付与できることを含めて考えると､以下のような､サービス利用者ごとにエッジ(というかIP)を割り当てる事もできそうな気がします｡

1｡あるサービス利用者(Y社)へのリクエストを受け取る
2｡Y社へ割り当てているエッジのリストをチェックする
3｡リクエストのリージョン内に割当がなければ､未利用エッジ(物理)のリストから割り当てる
4｡エッジがすべて割り当てられている場合､負荷などをもとに判断した任意のエッジに未利用IPリストのIPを追加する｡
5｡Y社への秒間リクエストが一定以上になれば､新たにエッジを割り当てる｡
6｡割り当てられたエッジまたはIPは､キャッシュのTTLとは別の時間で次のリクエストがなければ開放される｡  

この方法であれば,エッジのリソースはY社以外も使うが､IPアドレスはY社専用になります｡
また､エッジサーバのキャッシュが不正に取得された場合(意味があるかは置いておいて)､割当ログから被害規模を推定できます｡(キャッシュのログでもできますが､TTLが30秒のキャッシュのログを保持するとなると大変かと)
キャッシュヒット率もかなり効率的かと思います｡
また､アクセス可能なキャッシュの制限もIP+ポートよりは容易かと｡
リストの照合を低遅延で行う方法があるかどうか知りませんが｡

ちなみに､nslookupの結果はこんなかんじです｡
nslookup www.honda.com
名前:    e8624.dscx.akamaiedge.net
Addresses:  2600:140b:10:1088::21b0
          2600:140b:10:109e::21b0
          104.102.145.208
Aliases:  www.honda.com
          www.honda.com.edgekey.net

nslookup www.microsoft.com
名前:    e13678.dscb.akamaiedge.net
Addresses:  2600:140b:10:88b::356e
          2600:140b:10:88e::356e
          184.25.233.172
Aliases:  www.microsoft.com
          www.microsoft.com-c-3.edgekey.net
          www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net

>不服申立てができる仕組みがあると良いですね｡
→面白い発想ですね。抜け道とか攻略法とかがネットで出てきそうですね。単純に面白い発想と感じました。
  それか、仕組みが出来ても、事実としては全部「強制却下」されるとか(+_+)

>有名ドコロの名前を使って適当にXXX.comでnslookupして､akamaiが入っているやつだけで見ました｡
→【akamaiが入っているやつ】はイコールでakamaiのCDNサービスを利用している、と解釈できるものですか？私が知らないので。
  akamaiはCDN以外にも、ただただDNSサービスもしているので、ある企業のwebサイトの名前解決をするために、akamaiのDNSサービスを提供しているプランもあるはずです。

なので、私の理解では名前解決をしてみて応答サーバにakamaiの文言が入っている場合はパターンがあると思ってます。
①ある企業が自社のwebサイトの名前解決だけのサービスをakamaiと契約して、akamaiのDNSサーバが応答している。
  webサーバはakamaiのCDNではなく、その企業内のサーバルームで構築しているパターン。

②akamaiのCDNサービスを契約していて、名前解決先も、webサイトもakamaiのCDN上に構築している。

①の場合はその企業のオフィス内にあるコンテンツサーバ本体がオリジンで、そこに接続になる、
②の場合はakamaiが作ったキャッシュサーバへの接続になるかと。

>キャッシュのヒット率まで考慮するとなると､複雑になりすぎるかと思います｡
→私がセッション数と記載したので、誤解を与えてしまったかもしれません。
  キャッシュのヒット率は考慮しなくて良いと思います。キャッシュを持っているかどうかは一切考慮せず。
  何を負荷のトリガーにするかは設計次第ですが、最寄りの負荷が少ないキャッシュサーバにアクセスをして、
  もし初回ならオリジンサーバに聞きにいく、もし2回目以降なら代理応答する、という動作が事実かと思います。

>Webサイトの数は17億と言われていますので､ipv6を用いた場合､事実上無限です｡
→確かに理論上はおっしゃるとおりかと。
  仮にakamaiがグローバルIPアドレスを1000個、IPv4とv6で保有していて、毎月どれだけのお金を支払わなければならないのかは私は知りません。
  個人的にakamaiの立場になると、1企業に、1アドレスと1サーバを割り当てる事はしないと思います。1000企業と契約したら冗長化を考慮するとその倍必要になりますし。
  出来ればまとめたいと思うところです。

>サービス利用者ごとにエッジ(というかIP)を割り当てる
→案として面白いと感じました。
  未利用IPを一つ買うにもお金かかりますし、買ったIPを未利用（予備）にしている事もレアですが、その上で面白いと感じました。
  発想が面白いし、今後スレ主さんが設計していく中で、自由な発送で暴れまわってほしいです。

誤解されている部分を指摘させていただきます｡
>買ったIPを未利用（予備）にしている事もレアですが、その上で面白いと感じました。
実際にNSLOOKUPしたIPをAPNICでWHOISした結果が下記になります｡
NetRange: 2600:1400:: - 2600:14FF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
CIDR: 2600:1400::/24
NetName: AKAMAI
このサブネットで利用可能な数は､
028穰2409𥝱6036垓5167京423兆9472億5128万6016
となります｡
JPNICの費用だったら｢758,222円｣になります｡

AKAMAI以外という意味では､うちの会社ではIPv4ですが/16(クラスB)を複数持ってたりします｡
実際のIPアドレスの利用率は20%以下だと思います｡
DCHPで割り振る端末ではなく､サーバ系のIPだと､XXX.XXX.XXX.10がファイルサーバ｡みたいなローカルルールを使いますので､その周辺のIPは予約済みIPとして通常､利用しません｡サブネットも同様に意味を持たせて使いますね｡

>キャッシュのヒット率は考慮しなくて良いと思います。キャッシュを持っているかどうかは一切考慮せず。
ヒット率を考慮せずに負荷のみを持って分散すると､CDNのエッジ数が増えるとヒット率が低下しますし､キャッシュが増えれば増えるほどヒットしやすくなる｡逆に言えばそこそこのリクエストではCDNは機能しないことになります｡
CDNの料金体制は｢定額｣｢リクエスト数｣｢オリジンサーバへの問い合わせ数｣とあるようですが､いずれも｢キャッシュにあることが稀｣なサービスは流行らないかと思います｡

エッジサーバの負荷分散が必要 ← CDNサービス提供者にとっての重要事項
キャッシュヒットしてオリジンサーバの負荷軽減が必要 ← サービス利用者にとっての重要事項
ってことなので､ヒット率が高くないと､サービスは成り立たないかと思います｡
(その場合は､高可用性を売りにすると思います)

>akamaiはCDN以外にも、ただただDNSサービスもしているので、ある企業のwebサイトの名前解決をするために、akamaiのDNSサービスを提供しているプランもあるはずです。
その視点､抜けていました｡
CDNの解説サイトなどでNSLOOKUPを使用して､CDNのエッジにアクセスしているか調べられるようなことが書いてあり､試していましたが､確かにAkamaiのCDNにあるDNSに問い合わせた結果ですね｡
ただ､akamaiedge.netが返したAliasesが複数あり､かつ､1つにedgekey.netがあるとそれがCDNのエッジっぽい?ようです｡

ちなみに､自分の想像はそんなに突飛でもないかと思います｡
AWSでリソースを使うとき､おそらくこんなフローじゃないですかね?
リソースの開放については主体が異なりますが｡

ご指摘ありがとうございます。

私が一切触ったことのない領域のため、アレコレ想像で記載していたので、間違いや認識違いが当然あり過ぎるだろうなぁと思っていました。

実務をされているのか、正確な数字や金額で記載いただけると理解が深まります。

いえいえ｡自分もIPの管理はしたりしますが､
まさかAkamaiがこんなに大量のIPを確保しているとは思いも付きませんでした｡
また､費用も調べたら出てきただけで､こんなに安いとは思いませんでした｡

ほげほげさん､議論に乗っていただきありがとうございます｡
こういう業務と関係ない話は仕事仲間とはできませんし､自分自身の中である程度理論立つと､
他の考えが思いつかなくなってしまうので､勉強になりました｡

CDNサービスを利用したことがある方がいましたら､
実際にどの程度負荷が減らせたか｡(ヒット率がどのくらいか)とか､
費用感とか投稿していただけると非常に助かります｡

あるいは､回答でY社やX社､Zを含めて書いて､
悩まれている方の考えでも結構です｡
将来SCを受験する人の役に立つかもしれませんし｡