Home » Posts tagged "region" (Page 2)

Amazon DynamoDB 的 Point-In-Time Recovery

Amazon DynamoDB 在 3/26 發出來的功能,以秒為單位的備份與還原機制:「New – Amazon DynamoDB Continuous Backups and Point-In-Time Recovery (PITR)」。

先打開這個功能:

打開後就會開始記錄,最多可以還原 35 天內的任何一個時間點的資料:

DynamoDB can back up your data with per-second granularity and restore to any single second from the time PITR was enabled up to the prior 35 days.

這時候就算改變資料或是刪除資料,實際上在系統內都是 Copy-on-write 操作,所以需要另外的空間,這部份會另外計價:

Pricing for continuous backups is detailed on the DynamoDB Pricing Pages. Pricing varies by region and is based on the current size of the table and indexes. For example, in US East (N. Virginia) you pay $0.20 per GB based on the size of the data and all local secondary indexes.

有這樣的功能通常是一開始設計時就有考慮 (讓底層的資料結構可以很方便的達成這樣的效果),現在只是把功能實作出來... 像 MySQL 之類的軟體就沒辦法弄成這樣 XDDD

最後有提到支援的地區,是用條列的而不是說所有有 Amazon DynamoDB 的區域都支援:

PITR is available in the US East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), Asia Pacific (Tokyo), Asia Pacific (Seoul), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Canada (Central), EU (Frankfurt), EU (Ireland), EU (London), and South America (Sao Paulo) Regions starting today.

比對一下,應該是巴黎與美國政府用的區域沒進去... 一個是去年年底開幕的區域,另一個是本來上新功能就偏慢的區域。

AWS 大阪區

在寫前一篇「Inter-Region VPC Peering 的範圍大幅增加」時,跑去查了資料「AWS Regions and Endpoints」,發現 AWS 增加了 ap-northeast-3,但不同於其他區域的標法,大阪區的 Region Name 是「Asia Pacific (Osaka-Local)」,那個 Local 不知道代表什麼 XD

另外透過搜尋翻到的,在 Twitter 上的 AWS 日本帳號也提到了大阪區的消息:

Inter-Region VPC Peering 的範圍大幅增加

AWS 的 Inter-Region VPC Peering 又多了不少區域了:「Inter-Region VPC Peering is Now Available in Nine Additional AWS Regions」。

本來是支援 us-{east,west}-{1,2} 這四個,現在又多了 9 個,來到了 13 個:

Starting today, Inter-Region Virtual Private Cloud (VPC) Peering is available in AWS EU (London), EU (Ireland), EU (Paris), Asia Pacific (Mumbai), Asia Pacific (Sydney), Asia Pacific (Singapore), Asia Pacific (Tokyo), Canada (Central) and South America (São Paulo) Regions in addition to AWS US East (Northern Virgina), US East (Ohio), US West (Northern California), US West (Oregon) Regions.

與現在的 region 表格比較,剩下的是 ap-northeast-2 (南韓首爾) 與 eu-central-1 (德國法蘭克福),其他公開使用的區域都在這波的公告全上了。(也就是美國政府專屬區域與中國區不算在內)

AWS 公開了在台北的 Direct Connect 接口

也是個很久前就聽到傳言的消息... AWS 剛剛公佈了在台北的 Direct Connect 接口,用戶可以在台北內租用線路進機房就連上 Direct Connect:「New AWS Direct Connect sites land in Paris and Taipei」。

AWS Direct Connect also launched its first site in Taiwan at Chief Telecom LY, Taipei. In the Management Console, Taipei is located in the Asia Pacific (Tokyo) Region. With global access enabled for AWS Direct Connect, these sites can reach AWS resources in any global AWS region using global public VIFs and Direct Connect Gateway.

以往需要透過像 GCX 這樣的公司租用國際頻寬,再從 GCX 在台北的機房拉到自家機房 (通常是市內專線),現在只需要在台北對接的這段就可以了。

台北的接點在 AWS 上寫的是 Chief Telecom LY, Taipei, Taiwan,查了一下是是方電訊的「是方麗源大樓 (台北市內湖區陽光街250號)」,也就是之前有發生過火災而大斷線的那棟。對接的 AWS Home Region 是 Asia Pacific (Tokyo),所以使用 ap-northeast-1 的人可以規劃...

Jeff Barr 正在努力回顧去年 re:Invent 發表的東西:Inter-Region VPC Peering

居然是在補進度 XDDD 這是去年 AWS re:Invent 發表的功能:「New – Inter-Region VPC Peering」,在去年的時候也有提到了:「AWS 總算推出跨區 VPC Peering 了...」。

不過當時不確定跨區域時怎麼處理傳輸加密 (或者沒有處理?),這邊 Jeff Barr 補充提到了一些細節:

Data that passes between VPCs in distinct regions flows across the AWS global network in encrypted form. The data is encrypted in AEAD fashion using a modern algorithm and AWS-supplied keys that are managed and rotated automatically. The same key is used to encrypt traffic for all peering connections; this makes all traffic, regardless of customer, look the same. This anonymity provides additional protection in situations where your inter-VPC traffic is intermittent.

這樣架構會簡單不少,不需要自己再疊一層確保加密這件事情 (因為當時沒翻到資料說有加密...)。

AWS 的 Ningxia Region (寧夏) 開張

AWS 在寧夏的 Region 開張了:「Now Open – AWS China (Ningxia) Region」。一樣是走託管方式:

The AWS China (Ningxia) Region, operated by Ningxia Western Cloud Data Technology Co. Ltd. (NWCD), is generally available now and provides customers another option to run applications and store data on AWS in China.

代碼是 cn-northwest-1 (北京是 cn-north-1),都是使用 amazonaws.com.cn 網域。與北京區一樣都需要另外申請 AWS China 的帳號才能使用:

Customers already using the AWS China (Beijing) Region, operated by Sinnet, can select the AWS China (Ningxia) Region directly from the AWS Management Console, while new customers can request an account at www.amazonaws.cn to begin using both AWS China Regions.

不過在 AWS Regions and Endpoints 表上,寧夏區 (cn-northwest-1) 跟全球是放在一起的,但北京區 (cn-north-1) 是拆開的:

可能之後會再整理吧...

Amazon S3 的流量,以及 S3 與 Glacier 都推出 Select 功能

Twitter 上看到會場的照片,Amazon S3 單一 region 就有 37 Tb/sec 的量:

在這種量下面對 DDoS 沒什麼感覺 XDDD

另外是 Amazon S3 與 Amazon Glacier 都推出了 Select 功能:「S3 Select and Glacier Select – Retrieving Subsets of Objects」。

看示範的程式碼就可以看出用途了,原文中間那段有 sytax error,我這邊就幫忙修掉了:

handler = PrintingResponseHandler()
s3 = boto3.client('s3')
response = s3.select_object_content(
    Bucket="super-secret-reinvent-stuff",
    Key="stuff.csv",
    SelectRequest={
        'ExpressionType': 'SQL',
        'Expression': 'SELECT s._1 FROM S3Object AS s',
        'InputSerialization': {
            'CompressionType': 'NONE',
            'CSV': {
                'FileHeaderInfo': 'IGNORE',
                'RecordDelimiter': '\n',
                'FieldDelimiter': ',',
            }
        },
        'OutputSerialization': {
            'CSV': {
                'RecordDelimiter': '\n',
                'FieldDelimiter': ',',
            }
        }
    }
)

這樣可以大幅降低 I/O,節省成本:

Glacier Select 也是類似的想法,不需要整包拉出來再處理,可以在一開始就設定條件。

Amazon Aurora 的 Serverless 與 Multi-master

Amazon Aurora 推出了兩包玩意,第一包是 Serverless,讓需要人介入的情況更少:「In The Works – Amazon Aurora Serverless」。

在 Serverless 的第一個重點是支援以秒計費:

Today we are launching a preview (sign up now) of Amazon Aurora Serverless. Designed for workloads that are highly variable and subject to rapid change, this new configuration allows you to pay for the database resources you use, on a second-by-second basis.

然後是極為快速的 auto-scaling:

The endpoint is a simple proxy that routes your queries to a rapidly scaled fleet of database resources. This allows your connections to remain intact even as scaling operations take place behind the scenes. Scaling is rapid, with new resources coming online within 5 seconds

這兩個組合起來,讓使用端可以除了在 Amazon EC2 上可以快速 scale 外,後端的資料庫也能 scale 了...

第二個是 Multi-master 架構:「Sign Up for the Preview of Amazon Aurora Multi-Master」。

Amazon Aurora Multi-Master allows you to create multiple read/write master instances across multiple Availability Zones. This enables applications to read and write data to multiple database instances in a cluster, just as you can read across Read Replicas today.

(話說我一直都誤以為 Aurora 是 R/W master...)

Anyway,這個功能不知道怎麼疊上去的... 不笑得會不會有嚴重的 distributed lock issue,反而推薦大家平常都寫到同一台 (像是 PXC 就會這樣)。

Archives