關於不推薦用 1.1.1.1 的事情...

最近剛好跟朋友有聊到 1.1.1.1,然後就有提到我不推薦使用 1.1.1.1 的原因。

主要是因為 Cloudflare 以隱私的理由所以不打算支援 EDNS Client Subnet (ECS),而 ECS 這項技術可以把 client 的 subnet 資訊帶給 DNS server,讓 DNS server 可以配出更精準的伺服器,而關於 Cloudflare 不支援的這點,可以在「1.1.1.1 supports ECS?」這邊看到一些討論。

這個問題在 Akamai 這種超大 CDN,在同一個地區的各 ISP 都有伺服器的情況下特別明顯。

以我家第四台的 cable 線路來說 (我的備用線路),是走亞太 (APOL) 的線路出去,如果從自己的 ISP 查 www.akamai.com 的位置,可以查到 23.76.81.151,用 mtr 可以發現是走到 EBIX (也是亞太) 裡面的伺服器:

gslin@rpi3p [~] [13:35] host www.akamai.com         
www.akamai.com is an alias for www.akamai.comv2.edgekey.net.
www.akamai.comv2.edgekey.net is an alias for e1699.dscx.akamaiedge.net.
e1699.dscx.akamaiedge.net has address 23.76.81.151
e1699.dscx.akamaiedge.net has IPv6 address 2600:1417:76:594::6a3
e1699.dscx.akamaiedge.net has IPv6 address 2600:1417:76:58a::6a3
gslin@rpi3p [~] [13:35] mtr -w 23.76.81.151
Start: 2020-04-05T13:35:49+0000
HOST: rpi3p                                              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- unknown                                             0.0%    10    0.5   0.5   0.4   0.6   0.0
  2.|-- NK219-91-13-254.adsl.dynamic.apol.com.tw            0.0%    10    7.8   8.2   6.1  11.9   1.7
  3.|-- 10.251.11.6                                         0.0%    10   19.3  25.6  19.3  33.5   4.7
  4.|-- 10.251.231.5                                        0.0%    10   25.4  23.4  19.8  29.1   3.7
  5.|-- 10.251.231.1                                        0.0%    10    8.0  10.7   5.7  24.0   5.7
  6.|-- 10.251.230.34                                       0.0%    10   26.6  20.6   5.9 110.0  32.1
  7.|-- 10.251.230.29                                       0.0%    10   58.4  35.4   6.6  81.2  30.9
  8.|-- 202-178-245-162.cm.static.apol.com.tw               0.0%    10    9.5  18.4   7.4  78.5  21.3
  9.|-- 203-79-250-201.static.apol.com.tw                   0.0%    10    8.5   8.2   6.4   9.8   1.0
 10.|-- 211.76.96.191                                       0.0%    10    7.2  10.2   6.7  15.6   2.7
 11.|-- 203-79-254-10.ebix.net.tw                           0.0%    10  2226. 3802. 2226. 6017. 1314.6
 12.|-- a23-76-81-151.deploy.static.akamaitechnologies.com  0.0%    10    6.4   9.4   6.3  16.4   3.3

但如果從 1.1.1.1 查,會查到在中華電信內的 Akamai 伺服器,於是在尖峰時間反而變得很慢:

gslin@rpi3p [~] [13:36] host www.akamai.com 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases: 

www.akamai.com is an alias for www.akamai.comv2.edgekey.net.
www.akamai.comv2.edgekey.net is an alias for e1699.dscx.akamaiedge.net.
e1699.dscx.akamaiedge.net has address 23.48.142.132
e1699.dscx.akamaiedge.net has IPv6 address 2001:b034:1:1ea7::6a3
e1699.dscx.akamaiedge.net has IPv6 address 2001:b034:1:1e9f::6a3
gslin@rpi3p [~] [13:39] mtr -w 23.48.142.132
Start: 2020-04-05T13:39:42+0000
HOST: rpi3p                                               Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- unknown                                              0.0%    10    0.4   0.5   0.4   0.6   0.1
  2.|-- NK219-91-13-254.adsl.dynamic.apol.com.tw             0.0%    10    8.7  17.0   6.1  81.2  22.8
  3.|-- 10.251.11.6                                          0.0%    10   26.7  24.6  21.4  29.3   2.8
  4.|-- 10.251.231.5                                         0.0%    10   26.8  29.9  16.8  88.6  21.0
  5.|-- 10.251.231.1                                         0.0%    10    7.2   8.3   6.8  12.7   1.8
  6.|-- 10.251.230.34                                        0.0%    10   10.3   8.9   5.9  11.0   1.6
  7.|-- 10.251.230.29                                        0.0%    10    6.3  10.1   5.4  31.7   7.8
  8.|-- 202-178-245-162.cm.static.apol.com.tw                0.0%    10    8.8   9.1   7.3  13.2   1.8
  9.|-- 203-79-250-209.static.apol.com.tw                    0.0%    10   10.0   8.6   6.3  10.8   1.5
 10.|-- 211.76.96.67                                         0.0%    10    7.9   9.0   4.0  12.4   2.6
 11.|-- 109-84-21-113-static.chief.net.tw                    0.0%    10   18.3  11.7   7.0  25.1   5.7
 12.|-- 21-252-123-103-static.chief.net.tw                   0.0%    10    9.4  10.0   7.7  15.0   2.2
 13.|-- 203-75-228-5.HINET-IP.hinet.net                      0.0%    10   10.1  10.8   7.0  21.2   4.3
 14.|-- r4209-s2.hinet.net                                   0.0%    10    9.4  10.5   6.3  17.9   3.7
 15.|-- tpdt-3012.hinet.net                                  0.0%    10   92.0  61.6  11.1 141.6  53.8
 16.|-- tpdt-3301.hinet.net                                  0.0%    10   42.9  38.8   7.3 100.8  33.6
 17.|-- a23-48-142-132.deploy.static.akamaitechnologies.com  0.0%    10    8.2  15.5   8.2  46.6  12.4

跨 ISP 的線路品質通常都沒有同一個 ISP 內來的好,但因為沒有 EDNS Client Subnet (ECS) 的資訊,所以只能導去當地 (地理上) 預設的點,latency 應該還是夠低,但頻寬就未必足夠了。

8.8.8.8 會好一點,但目前最建議的還是用 ISP 自家的 DNS resolver,當 ISP 的 DNS Resolver 不支援 EDNS Client Subnet 時,CDN 也還是會正確讀到 ISP 的資訊,配到的伺服器的頻寬就不會太差...

Amazon ECS 的 Service Discovery

AWS 宣佈了 Amazon ECS 也支援 Route 53 提供的 Service Discovery 了:「Introducing Service Discovery for Amazon ECS」。

也就是說現在都整合好了... 比較一下先前需要自己包裝起來套用的方式會少不少功夫:

Previously, to ensure that services were able to discover and connect with each other, you had to configure and run your own service discovery system or connect every service to a load balancer. Now, you can enable service discovery for your containerized services with a simple selection in the ECS console, AWS CLI, or using the ECS API.

AWS 在 2016 年的時候有寫一篇「Service Discovery for Amazon ECS Using DNS」在講怎麼透過事件的觸發配合 AWS Lambda 把服務掛上去或是移除掉:

Recently, we proposed a reference architecture for ELB-based service discovery that uses Amazon CloudWatch Events and AWS Lambda to register the service in Amazon Route 53 and uses Elastic Load Balancing functionality to perform health checks and manage request routing. An ELB-based service discovery solution works well for most services, but some services do not need a load balancer.

現在看起來都可以改用 Auto Naming API 了...

Amazon ECS 與 AWS Fargate 都納入 Amazon Compute SLA 計算

AWS 宣佈的這兩個服務 (Amazon ECSAWS Fargate) 都納入 99.99% 的 SLA 合約範圍:「Amazon Compute Service Level Agreement Extended to Amazon ECS and AWS Fargate」。

Amazon Elastic Container Service (Amazon ECS) and AWS Fargate are now included in the Amazon Compute Service Level Agreement (SLA) for 99.99% uptime and availability.

ECS 已經跑一陣子了可以理解,但 Fargate 的概念算比較新,剛出來沒多久就決定放進去比較意外...

Amazon EKS 與 AWS Fargate

在今年的 AWS re:Invent 2017 上宣佈 Amazon ECS 也支援 Kubernetes,也就是 Amazon EKS:「Amazon Elastic Container Service for Kubernetes」,一個用的人夠多就支援的概念...

目前這個服務還在 Preview,所以要申請才能用:

Amazon EKS is available in Preview. We look forward to hearing your feedback.

另外一個在 AWS re:Invent 2017 上宣佈的是 AWS Fargate,讓你連 Amazon ECS 或是 Amazon EKS 都不用管的服務,直接按照 container 的大小收費:「Introducing AWS Fargate – Run Containers without Managing Infrastructure」、「AWS Fargate: A Product Overview」。

第一個有疑慮的點是,是否會跟其他人共用相同的 host,也就是 isolation 的程度。這點在 AWS 的人在 Hacker News 上的這邊有回覆,在不同的 cluster 上不會使用同樣的底層:

NathanKP 4 days ago [-]
Fargate isolation is at the cluster level. Apps running in the same cluster may share the underlying infrastructure, apps running in different clusters won't.

另外也提到每個 cluster 都是使用者自己產生的:

NathanKP 3 days ago [-]
A customer creates a cluster on their account. You as a customer can create one or more Fargate clusters on your account to launch your containers in.

不是很正面的回覆,而且不是在官方的 forum 回的,安全性就要大家自己判斷了...

另外也有有提到與 Amazon EC2 相比,價錢當然會比較貴,但可以預期會降低 engineer 的時間成本:

NathanKP 4 days ago [-]
AWS employee here. Just want to say that we actually had a typo in the per second pricing on launch. The actual pricing is:
$0.0506 per CPU per hour
$0.0127 per GB of memory per hour
Fargate is definitely more expensive than running and operating an EC2 instance yourself, but for many companies the amount that is saved by needing to spend less engineer time on devops will make it worth it right now, and as we iterate I expect this balance to continue to tip. AWS has dropped prices more than 60 times since we started out.

目前只能接 Amazon ECS,預定 2018 可以接 Amazon EKS:

I will tell you that we plan to support launching containers on Fargate using Amazon EKS in 2018.

而目前這個版本 (可以接 Amazon ECS 的版本) 在 us-east-1 已經開放了:

Fargate is available today in the US East (Northern Virginia) region.

AWS 推出 Cloud Native Networking,在每個 Container 內都有自己獨立的網路卡

AWSAmazon ECS 變得更好用了:「Introducing Cloud Native Networking for Amazon ECS Containers」。

Today, AWS announced task networking for Amazon ECS. This feature brings Amazon EC2 networking capabilities to tasks using elastic network interfaces.

awsvpc 模式下會給每個 container 一個獨立的網路卡 (Elastic Network Interface,ENI):

這樣有兩個好處。第一個是 port 就不需要拆開,所有 container 如果都是跑 nginx,都可以跑在同一個 port (80 或是 443),這對於前端應用程式會簡單一些。第二個整合了 AWS 的 security group,這對在 AWS 上本來就會使用 security group 的大多數人來說就可以輕鬆整合了。

AWS Batch 在東京區可以用了

AWS Batch 支援東京區了:「AWS Batch is Now Available in Tokyo」。

總算是在東京出現了... 在 FAQ 裡面有提到:

AWS Batch uses Amazon ECS to execute containerized jobs and therefore requires the ECS Agent to be installed on compute resources within your AWS Batch Compute Environments. The ECS Agent is pre-installed in Managed Compute Environments.

開起來測一些東西看看...

Amazon ECS 可以跑 cron job 了...

Amazon ECS 上面固定時間跑某些東西,以前得自己用 AWS Lambda 帶 (或是自己架,不過這樣就要自己考慮 High Availability 架構了),現在則是直接支援:「Amazon ECS Now Supports Time and Event-Based Task Scheduling」。

Previously, you could start and stop Amazon ECS tasks manually, but running tasks on a schedule required writing and integrating an external scheduler with the Amazon ECS API.

Now you can schedule tasks through the Amazon ECS console on fixed time intervals (e.g.: number of minutes, hours, or days). Additionally, you can now set Amazon ECS as a CloudWatch Events target, allowing you to launch tasks by using CloudWatch Events.