Amazon EBS 的 gp3 可以用在開機磁碟了

可以先參考「Amazon EBS 推出了 gp3」這篇,但剛出來的時候大家都有發現無論是透過 web console 還是透過 awscli,boot disk 都沒辦法改成 gp3,可是在官方的文件上又說可以用 gp3,所以就有人在 AWS 的 forum 上發問了:「EBS GP3 Boot Volume Issues」。

直到剛剛發現已經可以改成 gp3 了... 一個一個手動改當然也是 OK,但對於有一卡車 EBS 要換的人來說鐵定得弄指令來換,這邊搭配了 jq 一起改:

aws ec2 describe-volumes | jq '.Volumes[] | select(.VolumeType == "gp2") | .VolumeId' | xargs -n1 -P4 env aws ec2 modify-volume --volume-type gp3 --volume-id

這邊是把 gp2 都改成 gp3,沒有考慮到空間大小的問題 (因為超過 1TB 時 gp2 給的 IOPS 會比較多),另外 -P4 是平行四個 process 跑,改起來會快一些...

AWS 推出 Amazon Elastic Container Registry Public (公開版的 ECR)

算是延伸產品線,把 Amazon ECR 變成可以公開使用:「Amazon Elastic Container Registry Public: A New Public Container Registry」。

這篇稍微有趣的地方是,文章裡面的上面這張圖有把 path 模糊化,但下面那張沒有遮,後面的文字也直接有提到 path (這是要給使用者玩的...):

ECR Public 會自動同步到兩個 region,但設定的頁面上好像沒寫會怎麼挑... 另外前面會放 CloudFront 加速。

ECR Public automatically replicates container images across two AWS Regions to reduce download times and improve availability. Therefore, using public images directly from ECR Public may simplify your build process if you were previously creating and managing local copies. ECR Public caches image layers in Amazon CloudFront, to improve pull performance for a global audience, especially for popular images.

費用的部份,意外的有提供一些免費的空間與頻寬可以用,算是在推廣嗎?

Amazon S3 現在變成 Strong Read-After-Write Consistency 啦...

看到 Amazon S3 宣佈 Strong Read-After-Write Consistency 了:「Amazon S3 Update – Strong Read-After-Write Consistency」。

這個問題從很久前就被討論過:

所以到這次更新之前,只有新增的 object 會保證馬上出現。現在則是 update 也會:

Effective immediately, all S3 GET, PUT, and LIST operations, as well as operations that change object tags, ACLs, or metadata, are now strongly consistent. What you write is what you will read, and the results of a LIST will be an accurate reflection of what’s in the bucket. This applies to all existing and new S3 objects, works in all regions, and is available to you at no extra charge! There’s no impact on performance, you can update an object hundreds of times per second if you’d like, and there are no global dependencies.

要注意這邊沒有提到 DELETE,所以有可能 DELETE + GET 的操作還是沒有到 strong consistency,不過句子本身意思不是很清晰,也許這幾天會有人在 forum 上面問然後有答案...

另外從公告裡面提到 Amazon EMR 團隊,看起來是 Amazon EMR 團隊一直在內部戳 Amazon S3 的團隊改善:

We’ve been working with the Amazon EMR team and developers in the open-source community to ensure that customers can take advantage of this update with their big data workloads. As a result of that you no longer need to use EMRFS Consistent View or S3Guard, further reducing the cost to run big data workloads in AWS.

AWS Lambda 的消息:計費方式 1ms、上限變高、自訂 Image

這次 AWS re:InventAWS Lambda 也更新了不少東西:

首先是計價方式的改變,從本來 100ms 降到 1ms,對於這點 Cliff 有提出來了,cold start 會是成本中很重的一環 (在 https://www.facebook.com/clifflu666/posts/10214677842380050 這邊):

不過從本來的 100ms 變成現在的 1ms 只會變便宜,如果本來 100ms 的價錢就可以接受的話,現在看起來沒有理由變差 (humm,心情例外)。

會改變的是,以前可能不會想要對 cold start 最佳化 (因為做了還是收 100ms 的錢),現在就可以考慮進去讓成本再降了。

第二個是 lambda 的上限會變成 10GB RAM 與 6vCPU,剛好前幾天翻資料的時候,有翻到改版前的限制:「lambda_cpu_cores.md」,之前的上限是約 3GB 的記憶體與 2vCPU,現在拉起來讓你可以跑更大的東西...

第三個是讓你可以自訂 container image,而不需要用 AWS 提供的標準 image 跑,這點對於降低 cold start 成本也蠻有幫助的,另外一方面,總算是可以對環境客製化了...

裡面看起來最重要的應該還是第一個,計價方式讓整個成本評估大幅改變...

Amazon EC2 的新機種:R5b、D3 (D3en)、C6gn、M5zn、G4ad

Amazon EC2 除了昨天放出 Mac mini 消息打頭陣以外,其他機種的更新消息也陸陸續續公佈了:

比較有趣的 (對我而言),第一個是 ARM 架構的機器也推出 100Gbps 的 n 版本 c6gn,看起來很適合跑大流量的東西,馬上想到的就是自架的 memcached

另外是 m5zn,使用高頻率的 Intel Xeon,主打需要單核效率的程式,不過這是掛在 m 系列下,而不是 c 系列...

再來是使用 AMD GPU 的 g4ad,官方宣稱跟 NVIDIAg4dn 比起來,將會有 45% 的 C/P 值提昇,是個蘇媽跟老黃的對決:

However, when compared to G4dn the new G4ad instances enable up to 45% better price performance for graphics-intensive workloads, including the aforementioned game streaming, remote graphics workstations, and rendering scenarios. Compared to an equally-sized G4dn instance, G4ad instances offer up to 40% improvement in performance.

看起來 ARM 的消息沒有想像中的多...

Amazon EBS 的 io2 給了不少新消息...

Amazon EBS 的另外一個新推出的東西,是針對 io2 的改善:

前面兩則消息可以一起看,主要是推出了 EBS Block Express,有著效能上的提昇:

Built on our new EBS Block Express architecture that takes advantage of some advanced communication protocols implemented as part of the AWS Nitro System, the volumes will give you up to 256K IOPS & 4000 MBps of throughput and a maximum volume size of 64 TiB, all with sub-millisecond, low-variance I/O latency. Throughput scales proportionally at 0.256 MB/second per provisioned IOPS, up to a maximum of 4000 MBps per volume. You can provision 1000 IOPS per GiB of storage, twice as many as before. The increased volume size & higher throughput means that you will no longer need to stripe multiple EBS volumes together, reducing complexity and management overhead.

目前因為是 preview 階段,想要用的人需要申請測試。要注意目前支援的區域有限 (不像這次推出 gp3 的時候就是全區),而且需要搭配 r5b 的機器:

The preview is currently available in the US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Singapore), Asia Pacific (Tokyo), and Europe (Frankfurt) Regions. During the preview, we support the use of R5b instances, with support for other Nitro-powered instances in the works.

第三則消息則是在講 io2 的 IOPS 的折扣,針對購買 32K IOPS 以上的部份會有 30% 折扣:

Now, with the new tiered pricing structure, the first 32,000 IOPS provisioned on a volume are charged at the current base rate ($0.065 per provisioned IOPS-mo) and the second tier between 32,001 and 64,000 is charged at a 30% lower rate ($0.046 per provisioned IOPS-mo).

針對前面提到的 preview 版本 (EBS Block Express),因為可以超過 64K IOPS,這個部份的價錢會更低,再疊一次 30% 的折扣:

Furthermore, for customers who have even higher performance requirement than currently supported by a single io2 volume today, we are previewing io2 volumes that run on EBS Block Express, the next generation of our block storage architecture. io2 Block Express volumes can be provisioned to deliver peak IOPS of 256,000. For these volume, any IOPS provisioned over 64,000 IOPS will be charged at a further 30% lower rate than the second tier ($0.032 per provisioned IOP-mo for IOPS over 64,000). This lowers the effective rate to $0.038 per provisioned IOPS on a volume provisioned with 256,000 IOPS.

算是要衝效能的人用的,目前平常應該還是會用 gp2 或是 gp3 的 SSD...

Amazon EBS 推出了 gp3

今年的 AWS re:Invent 又開始了,不過因為疫情的關係,這次是線上為主... 這邊先來整理一下 Amazon EBS 相關的更新。

首先是推出了新的 gp3 類型,也是 SSD 類:「New – Amazon EBS gp3 Volume Lets You Provision Performance Apart From Capacity」。

每 GB 單位成本比 gp2 低 20%:

Today I would like to tell you about gp3, a new type of SSD EBS volume that lets you provision performance independent of storage capacity, and offers a 20% lower price than existing gp2 volume types.

然後直接給你 3000 IOPS 與 125MB/sec,有需要更高的話可以「加購」:

gp3 is designed to provide predictable 3,000 IOPS baseline performance and 125 MiB/s regardless of volume size. It is ideal for applications that require high performance at a low cost such as MySQL, Cassandra, virtual desktops and Hadoop analytics. Customers looking for higher performance can scale up to 16,000 IOPS and 1,000 MiB/s for an additional fee. The top performance of gp3 is 4 times faster than max throughput of gp2 volumes.

但照「Amazon EBS volume types」這邊的列表可以看到,要注意 gp2 可以 burst 的 throughput (250MB/sec) 比 gp3 的 baseline (125MB/sec) 高。

也因為這樣,可以把一些 random access 比較多的 /data 這類的 EBS 換過去,但如果是要大量 sequential access 的也許就不適合了。

IOPS 的部份,1TB 以下的 gp2 換過去應該是沒什麼太大問題,因為在 gp2 的時候是 1GB 給 3IOPS,所以 1TB 以下的 gp2 都低於 3000IOPS。

轉移的部份可以在 AWS 的 console 上直接 migrate 到 gp3

If you’re currently using gp2, you can easily migrate your EBS volumes to gp3 using Amazon EBS Elastic Volumes, an existing feature of Amazon EBS. Elastic Volumes allows you to modify the volume type, IOPS, and throughput of your existing EBS volumes without interrupting your Amazon EC2 instances.

像是這樣:

但照「Amazon EBS volume types」這邊的列表,gp3 可以是開機硬碟,但是改不過去啊 XDDD

Update:剛剛發現文件被修正了,看起來不能當開機硬碟...

不知道哪邊搞錯了,過幾天看看吧 XDDD

Salesforce 買下 Slack

前陣子就有 Salesforce 要買下 Slack 的消息,剛剛確認了:「Salesforce buys Slack in a $27.7B megadeal」。

2019 年的時候花了 $15.3B 買下 Tableau (Salesforce bets on big data with $15.3 billion Tableau buy),這次則是 $27.7B...

從維基百科上翻了一下 Salesforce 手上買過的公司,看起來只有 Heroku 以及上面提到的 Tableau 比較熟悉...

這次併購對於 Slack 的人來說應該是好事?畢竟股價先漲了一波... 另外 Stewart Butterfield 不知道會再待多久,也許之後又會看到拉著 Cal Henderson 再幹一波?

Amazon EC2 推出 Mac Instance

AWSMac miniAmazon EC2 上推出了 Mac Instance:

Powered by Mac mini hardware and the AWS Nitro System, you can use Amazon EC2 Mac instances to build, test, package, and sign Xcode applications for the Apple platform including macOS, iOS, iPadOS, tvOS, watchOS, and Safari.

這批 Mac mini 是 Intel i7 的機器:

The instances feature an 8th generation, 6-core Intel Core i7 (Coffee Lake) processor running at 3.2 GHz, with Turbo Boost up to 4.6 GHz. There’s 32 GiB of memory and access to other AWS services including Amazon Elastic Block Store (EBS), Amazon Elastic File System (EFS), Amazon FSx for Windows File Server, Amazon Simple Storage Service (S3), AWS Systems Manager, and so forth.

要注意的是最低租用時間是 24 小時:

Dedicated Hosts – The instances are launched as EC2 Dedicated Hosts with a minimum tenancy of 24 hours. This is largely transparent to you, but it does mean that the instances cannot be used as part of an Auto Scaling Group.

然後 Apple M1 也在規劃中:

Apple M1 Chip – EC2 Mac instances with the Apple M1 chip are already in the works, and planned for 2021.

區域上不多,不過亞洲區居然是新加坡首發:

You can start using Mac instances in the US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), and Asia Pacific (Singapore) Regions today, and check out this video for more information!

以前是自己用地端的 Mac mini 去接雲端的服務 (有點 worker 的感覺),現在這樣看起來又多了一些東西可以玩...?

關閉 GitLab 的 nginx,使用自己裝的 nginx

我自己架設的 GitLab 是透過「Install self-managed GitLab」這邊的方法裝進 Ubuntu 系統內的 (我在自己的 wiki 上也有整理:「GitLab」),他會自己下載所有對應的套件,包括了 nginx

但這樣就直接把 TCP port 80/443 都吃掉了,同一台機器要放其他的 virtual host 就比較麻煩,所以找了些方法讓 GitLab 不要佔用 TCP port 80/443。

首先是找到這篇,資料有點舊,但裡面關掉 nginx 的方法還算是有用:「How to setup gitlab without embedded nginx」。

現在只要把 /etc/gitlab/gitlab.rb 裡面的:

  • nginx['enable'] 改成 false
  • web_server['external_users'] 改成 ['www-data']

然後跑 gitlab-ctl reconfigure 讓他更新設定檔,接下來停掉整個 GitLab 再打開 (或是重開機) 讓 nginx 完全失效就可以了。

接下來弄好自己的 nginx 以及 HTTPS 設定,這個部份我自己偏好用 dehydrated,其他人會有不同的偏好設法。

在弄完 nginx 後再來是 proxy_pass 類的資訊要帶進去,這個部份可以參考本來 GitLab 的 nginx 設定檔 (在 /var/opt/gitlab/nginx/conf/ 這下面),其中最重要的就是 GitLab 本身,我們會在 /etc/nginx/conf.d/upstream.conf 裡面寫入對應的 upstream 資訊 (沒這個檔案就自己生一個):

upstream gitlab-workhorse {
    server unix:/var/opt/gitlab/gitlab-workhorse/sockets/socket;
}

接下來是在對應的 virtual host 下設定 proxy_pass

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass http://gitlab-workhorse;
    }

另外我有啟用 GitLab 提供的 Mattermost,所以也要翻設定導進去:

#
upstream gitlab_mattermost {
    server 127.0.0.1:8065;
}

與:

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass http://gitlab_mattermost;
    }

都弄好後叫 nginx 重讀設定,接下來應該就會動了... 然後 TCP port 80/443 也算自由了,要掛其他的網域上去應該都 OK。