質問編集履歴
16
修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -23,8 +23,8 @@
|
|
|
23
23
|
なぜCloudfrontは多くのIPアドレスが必要なのでしょうか？
|
|
24
24
|
|
|
25
25
|
また、IPアドレスは`region`が`GLOBAL`になっており、全世界でIPアドレスがバラバラに利用されているようです。
|
|
26
|
-
IPアドレスAはAWS`東京`リージョンだけで利用されて、
|
|
26
|
+
IPアドレス範囲AはAWS`東京`リージョンだけで利用されて、
|
|
27
|
-
IPアドレスBはAWS`大阪`リージョンだけで利用されて、
|
|
27
|
+
IPアドレス範囲BはAWS`大阪`リージョンだけで利用されて、
|
|
28
28
|
・・・
|
|
29
29
|
という事ではないようです。
|
|
30
30
|
|
15
修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -53,6 +53,7 @@
|
|
|
53
53
|
|
|
54
54
|
仮に以下のような構成だとIPアドレスは少なくて良いですが（リージョンごとに1個で良いはず）
|
|
55
55
|
ロードバランサ自体がネットワーク帯域が多すぎて耐えられないのでダメという事でしょうか？
|
|
56
|
+
※インスタンス自体にはプライベートIPアドレスを付与して、グローバルIPアドレスは付与しない
|
|
56
57
|
|
|
57
58
|
|
|
58
59
|
# 参考
|
14
修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -51,6 +51,10 @@
|
|
|
51
51
|
xxxx.cloudfront.net. 60 IN A 13.225.165.52
|
|
52
52
|
```
|
|
53
53
|
|
|
54
|
+
仮に以下のような構成だとIPアドレスは少なくて良いですが（リージョンごとに1個で良いはず）
|
|
55
|
+
ロードバランサ自体がネットワーク帯域が多すぎて耐えられないのでダメという事でしょうか？
|
|
56
|
+
|
|
57
|
+
|
|
54
58
|
# 参考
|
|
55
59
|
こちらの資料に目を通しましたがIPアドレスが多く必要な理由はわかりませんでした。
|
|
56
60
|
https://pages.awscloud.com/rs/112-TZM-766/images/AWS-29_AWS_Summit_Online_2020_NET02.pdf
|
13
修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -29,7 +29,7 @@
|
|
|
29
29
|
という事ではないようです。
|
|
30
30
|
|
|
31
31
|
GLOBALで利用されてIPアドレスが世界中のサーバーに振り分けられている状況でどのように最適なサーバーが選択されているのでしょうか？
|
|
32
|
-
仮にIPリストからラウンドロビンのようにランダムなサーバーが選ばれている場合、Cloudfrontのメリットである「高速伝送」「低遅延」と言えるでしょうか？日本から閲覧する場合は日本サーバーが近いので日本サーバーが選択されるべきという気がします。海外サーバーが選択されてしまうと遅くなるはずです。
|
|
32
|
+
仮にIPリストからラウンドロビンのようにランダムなサーバーが選ばれている場合、Cloudfrontのメリットである「高速伝送」「低遅延」と言えるでしょうか？日本から閲覧する場合は日本サーバーが近いので日本サーバー（東京または大阪）が選択されるべきという気がします。海外サーバーが選択されてしまうと遅くなるはずです。
|
|
33
33
|
|
|
34
34
|
それを回避するために何らかの処理をCloudfront内部的に行っているとすると多くのIPアドレスが必要なCloudfrontの今の仕組みはIP Anycastと比べるととても複雑な仕組みになっているように思います。
|
|
35
35
|
|
12
修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -29,7 +29,7 @@
|
|
|
29
29
|
という事ではないようです。
|
|
30
30
|
|
|
31
31
|
GLOBALで利用されてIPアドレスが世界中のサーバーに振り分けられている状況でどのように最適なサーバーが選択されているのでしょうか？
|
|
32
|
-
仮にIPリストからラウンドロビンのようにランダムなサーバーが選ばれている場合、Cloudfrontのメリットである「高速伝送」と言えるでしょうか？日本
|
|
32
|
+
仮にIPリストからラウンドロビンのようにランダムなサーバーが選ばれている場合、Cloudfrontのメリットである「高速伝送」「低遅延」と言えるでしょうか？日本から閲覧する場合は日本サーバーが近いので日本サーバーが選択されるべきという気がします。海外サーバーが選択されてしまうと遅くなるはずです。
|
|
33
33
|
|
|
34
34
|
それを回避するために何らかの処理をCloudfront内部的に行っているとすると多くのIPアドレスが必要なCloudfrontの今の仕組みはIP Anycastと比べるととても複雑な仕組みになっているように思います。
|
|
35
35
|
|
11
修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -23,9 +23,9 @@
|
|
|
23
23
|
なぜCloudfrontは多くのIPアドレスが必要なのでしょうか？
|
|
24
24
|
|
|
25
25
|
また、IPアドレスは`region`が`GLOBAL`になっており、全世界でIPアドレスがバラバラに利用されているようです。
|
|
26
|
-
|
|
26
|
+
IPアドレスAはAWS`東京`リージョンだけで利用されて、
|
|
27
|
-
|
|
27
|
+
IPアドレスBはAWS`大阪`リージョンだけで利用されて、
|
|
28
|
-
|
|
28
|
+
・・・
|
|
29
29
|
という事ではないようです。
|
|
30
30
|
|
|
31
31
|
GLOBALで利用されてIPアドレスが世界中のサーバーに振り分けられている状況でどのように最適なサーバーが選択されているのでしょうか？
|
10
修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -39,8 +39,8 @@
|
|
|
39
39
|
日本から閲覧する場合はAWS東京かAWS大阪が選択されるはずです。
|
|
40
40
|
現在のCloudfrontのようにアクセスするたびにランダムにIPアドレスが変化する事はないはずです。
|
|
41
41
|
|
|
42
|
-
※以下コマンドの結果は
|
|
42
|
+
※以下コマンドの結果は変化し続けます。
|
|
43
|
-
応答されるIPアドレスは変わり続けます。
|
|
43
|
+
数秒単位では変化しませんが応答されるIPアドレスは変わり続けます。
|
|
44
44
|
```
|
|
45
45
|
$ dig a xxxxx.cloudfront.net
|
|
46
46
|
|
9
修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -35,7 +35,7 @@
|
|
|
35
35
|
|
|
36
36
|
また、多くのIPアドレスがあるということは多くのサーバーがあるということなのでCloudfrontのキャッシュヒット率も相当低くなるのではないでしょうか。
|
|
37
37
|
CloudfrontのIPアドレスは追加され続けているようです。今後もIPアドレスが追加され続けると更にキャッシュヒット率が低くなり続けると思います。
|
|
38
|
-
IP AnycastであればBGP情報をもとに常に最適なサーバーが自動で選択されるのでキャッシュ率は高いのではないでしょうか。
|
|
38
|
+
IP AnycastであればBGP情報をもとに常に最適なサーバーが自動で選択されるのでサーバーが増えたとしてもキャッシュ率は高いのではないでしょうか。
|
|
39
39
|
日本から閲覧する場合はAWS東京かAWS大阪が選択されるはずです。
|
|
40
40
|
現在のCloudfrontのようにアクセスするたびにランダムにIPアドレスが変化する事はないはずです。
|
|
41
41
|
|
8
修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -51,3 +51,6 @@
|
|
|
51
51
|
xxxx.cloudfront.net. 60 IN A 13.225.165.52
|
|
52
52
|
```
|
|
53
53
|
|
|
54
|
+
# 参考
|
|
55
|
+
こちらの資料に目を通しましたがIPアドレスが多く必要な理由はわかりませんでした。
|
|
56
|
+
https://pages.awscloud.com/rs/112-TZM-766/images/AWS-29_AWS_Summit_Online_2020_NET02.pdf
|
7
修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -45,9 +45,9 @@
|
|
|
45
45
|
$ dig a xxxxx.cloudfront.net
|
|
46
46
|
|
|
47
47
|
;; ANSWER SECTION:
|
|
48
|
-
|
|
48
|
+
xxxx.cloudfront.net. 60 IN A 13.225.165.4
|
|
49
|
-
|
|
49
|
+
xxxx.cloudfront.net. 60 IN A 13.225.165.29
|
|
50
|
-
|
|
50
|
+
xxxx.cloudfront.net. 60 IN A 13.225.165.115
|
|
51
|
-
|
|
51
|
+
xxxx.cloudfront.net. 60 IN A 13.225.165.52
|
|
52
52
|
```
|
|
53
53
|
|
6
修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -35,4 +35,19 @@
|
|
|
35
35
|
|
|
36
36
|
また、多くのIPアドレスがあるということは多くのサーバーがあるということなのでCloudfrontのキャッシュヒット率も相当低くなるのではないでしょうか。
|
|
37
37
|
CloudfrontのIPアドレスは追加され続けているようです。今後もIPアドレスが追加され続けると更にキャッシュヒット率が低くなり続けると思います。
|
|
38
|
+
IP AnycastであればBGP情報をもとに常に最適なサーバーが自動で選択されるのでキャッシュ率は高いのではないでしょうか。
|
|
39
|
+
日本から閲覧する場合はAWS東京かAWS大阪が選択されるはずです。
|
|
40
|
+
現在のCloudfrontのようにアクセスするたびにランダムにIPアドレスが変化する事はないはずです。
|
|
38
41
|
|
|
42
|
+
※以下コマンドの結果は常に変化し続けます。
|
|
43
|
+
応答されるIPアドレスは変わり続けます。
|
|
44
|
+
```
|
|
45
|
+
$ dig a xxxxx.cloudfront.net
|
|
46
|
+
|
|
47
|
+
;; ANSWER SECTION:
|
|
48
|
+
d20h5w0pbp9yfp.cloudfront.net. 60 IN A 13.225.165.4
|
|
49
|
+
d20h5w0pbp9yfp.cloudfront.net. 60 IN A 13.225.165.29
|
|
50
|
+
d20h5w0pbp9yfp.cloudfront.net. 60 IN A 13.225.165.115
|
|
51
|
+
d20h5w0pbp9yfp.cloudfront.net. 60 IN A 13.225.165.52
|
|
52
|
+
```
|
|
53
|
+
|
5
修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -32,3 +32,7 @@
|
|
|
32
32
|
仮にIPリストからラウンドロビンのようにランダムなサーバーが選ばれている場合、Cloudfrontのメリットである「高速伝送」と言えるでしょうか？日本人が閲覧する場合は日本サーバーが近いので日本サーバーが選択されるべきという気がします。海外サーバーが選択されてしまうと遅くなるはずです。
|
|
33
33
|
|
|
34
34
|
それを回避するために何らかの処理をCloudfront内部的に行っているとすると多くのIPアドレスが必要なCloudfrontの今の仕組みはIP Anycastと比べるととても複雑な仕組みになっているように思います。
|
|
35
|
+
|
|
36
|
+
また、多くのIPアドレスがあるということは多くのサーバーがあるということなのでCloudfrontのキャッシュヒット率も相当低くなるのではないでしょうか。
|
|
37
|
+
CloudfrontのIPアドレスは追加され続けているようです。今後もIPアドレスが追加され続けると更にキャッシュヒット率が低くなり続けると思います。
|
|
38
|
+
|
4
修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -22,13 +22,13 @@
|
|
|
22
22
|
こちらのような方式を利用すればCloudfrontでも1つのIPアドレスだけで良いのではないでしょうか？
|
|
23
23
|
なぜCloudfrontは多くのIPアドレスが必要なのでしょうか？
|
|
24
24
|
|
|
25
|
-
また、IPアドレスは`region`が`GLOBAL`になっており、全世界でIPアドレスが利用されているようです。
|
|
25
|
+
また、IPアドレスは`region`が`GLOBAL`になっており、全世界でIPアドレスがバラバラに利用されているようです。
|
|
26
|
-
|
|
26
|
+
ある範囲のIPアドレスはAWS`東京`リージョンだけで利用されて、
|
|
27
|
-
|
|
27
|
+
ある範囲のIPアドレスはAWS`大阪`リージョンだけで利用されて、
|
|
28
28
|
…
|
|
29
29
|
という事ではないようです。
|
|
30
30
|
|
|
31
31
|
GLOBALで利用されてIPアドレスが世界中のサーバーに振り分けられている状況でどのように最適なサーバーが選択されているのでしょうか？
|
|
32
|
-
仮にIPリストからラウンドロビンのようにランダムなサーバーが選ばれている場合、Cloudfrontのメリットである「高速伝送」と言えるでしょうか？日本人が閲覧する場合は日本サーバーが近いので
|
|
32
|
+
仮にIPリストからラウンドロビンのようにランダムなサーバーが選ばれている場合、Cloudfrontのメリットである「高速伝送」と言えるでしょうか？日本人が閲覧する場合は日本サーバーが近いので日本サーバーが選択されるべきという気がします。海外サーバーが選択されてしまうと遅くなるはずです。
|
|
33
33
|
|
|
34
|
-
IP Anycastと比べるととても複雑な仕組みになっているように思います。
|
|
34
|
+
それを回避するために何らかの処理をCloudfront内部的に行っているとすると多くのIPアドレスが必要なCloudfrontの今の仕組みはIP Anycastと比べるととても複雑な仕組みになっているように思います。
|
3
修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -13,7 +13,7 @@
|
|
|
13
13
|
### 質問
|
|
14
14
|
何故多くのIPアドレスが必要なのでしょうか？
|
|
15
15
|
|
|
16
|
-
###
|
|
16
|
+
### 調べたこと
|
|
17
17
|
IPアドレスを多く利用しない方法として[IP Anycast](https://jprs.jp/glossary/index.php?ID=0108)という方法があるようです。
|
|
18
18
|
|
|
19
19
|
BGP経路情報をもとに最適な経路で通信がされるので、経路的に最適なサーバーが自動で選択されてIPアドレスも多く必要ないのでいい事ばかりのような気がします。
|
2
修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -14,11 +14,7 @@
|
|
|
14
14
|
何故多くのIPアドレスが必要なのでしょうか？
|
|
15
15
|
|
|
16
16
|
### 試したこと
|
|
17
|
-
IPアドレスを多く利用しない方法としてIP Anycastという方法があるようです。
|
|
18
|
-
|
|
19
|
-
[参考画像 ユニキャスト](https://jprs.jp/glossary/imgs/unicast.png)
|
|
20
|
-
[参考画像 IP Anycast](https://jprs.jp/glossary/imgs/anycast.png)
|
|
21
|
-
[
|
|
17
|
+
IPアドレスを多く利用しない方法として[IP Anycast](https://jprs.jp/glossary/index.php?ID=0108)という方法があるようです。
|
|
22
18
|
|
|
23
19
|
BGP経路情報をもとに最適な経路で通信がされるので、経路的に最適なサーバーが自動で選択されてIPアドレスも多く必要ないのでいい事ばかりのような気がします。
|
|
24
20
|
（おそらく多くのIPアドレスを持つ事は維持コストもかかると思うので）
|
1
画像修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -16,7 +16,8 @@
|
|
|
16
16
|
### 試したこと
|
|
17
17
|
IPアドレスを多く利用しない方法としてIP Anycastという方法があるようです。
|
|
18
18
|
|
|
19
|
-
[参考画像](https://jprs.jp/glossary/imgs/unicast.png)
|
|
19
|
+
[参考画像 ユニキャスト](https://jprs.jp/glossary/imgs/unicast.png)
|
|
20
|
+
[参考画像 IP Anycast](https://jprs.jp/glossary/imgs/anycast.png)
|
|
20
21
|
[引用元](https://jprs.jp/glossary/index.php?ID=0108)
|
|
21
22
|
|
|
22
23
|
BGP経路情報をもとに最適な経路で通信がされるので、経路的に最適なサーバーが自動で選択されてIPアドレスも多く必要ないのでいい事ばかりのような気がします。
|