Home » Computer » Network » Cloud » Archive by category "AWS" (Page 54)

Amazon Web Services 新的儲存方案:Amazon Glacier

Amazon Simple Storage Service (Amazon S3)AWS 第一代儲存服務。後來 S3 又提供了 Reduced Redundancy Storage,降低可靠度 (一年 99.99%) 換取價錢上的優勢,用在 cache file 之類的還蠻不錯。目前兩者在美東的價錢是 USD$0.125/GB 與 USD$0.093/GB。這兩種都是隨時可以存取的服務。

Amazon Glacier 則是提供超低的價錢與超高的可靠度:USD$0.01/GB 與一年 99.999999999%,而這是靠取回檔案的時間換來的。取回檔案需要排 3.5 到 4.5 小時的時間 (後面傳輸的時間另外計算):

Retrieving archives from Amazon Glacier requires the initiation of a job. Jobs typically complete in 3.5 to 4.5 hours.

是靠著機械手臂與軌道在處理嗎?

但這樣就多了很多用途啊... Data warehouse 是個很明顯的方向。目前可以透過 AWS Import/Export 匯入大量資料:

You can also use AWS Import/Export to accelerate moving large amounts of data into Amazon Glacier using portable storage devices for transport.

之後則是會提供從 S3 搬出去與搬進去的功能:

In the coming months, Amazon Simple Storage Service (Amazon S3) plans to introduce an option that will allow you to seamlessly move data between Amazon S3 and Amazon Glacier using data lifecycle policies.

等工具完整後再來研究 :p

Netflix 的 Chaos Monkey

Chaos MonkeyNetflix 丟出來的工具,這個工具的目的是希望建立超高可靠度的系統。方法則是沒事就亂關 AWS 上的 instance:「Chaos Monkey released into the wild」。

基本的想法是這樣:

  • 在 AWS 上的系統容錯率要超高。
  • 上班時間爛掉比凌晨三點被 call 起床好。
  • 所以平常就放火測試容錯率到底夠不夠高,方法就是隨機關 instance。

照 Netflix 的說法,他們不僅在開發環境測試,也在正式環境測試。利用 Chaos Monkey 看看 failure 的結果是否如預期。

Netflix 甚至建議可以排成每個上班日都隨機跑一跑:

The service has a configurable schedule that, by default, runs on non-holiday weekdays between 9am and 3pm.

只有在爆炸機率超高的系統上,設計師才會在意 failure 的問題...

AWS EBS 的改善...

AWS EBSAmazon Web Services 平台上的永久性儲存空間 (一般開起來的空間在 crash 後會消失),不過 EBS 的效能 (速度與 IOPS) 一直讓大家很頭痛,要硬撐 IOPS 的方式是透過四個 EBS volume,上面用 mdadm 跑 RAID0...

這幾個禮拜 AWS 丟出了兩個方案出來,提供不同的選擇...

首先是帶大容量 SSD 空間的 instance,參考「AWS 推出高速 I/O 的 EC2 instance」,這對於 cache 類的應用相當適合...

而昨天則是介紹了 Provisioned IOPS 與 EBS-Optimized instances:「Fast Forward - Provisioned IOPS for EBS Volumes」。

Provisioned IOPS 是保障 IOPS 的機制,每個 volume 最高可以到 1000 IOPS。除了每 GB 的價錢比較高以外,另外每個保障的 IOPS 要再收 USD$0.1/month。(本來 EBS 的 I/O 費用還是要計算)

標準的 EBS 約提供 100 IOPS,這個 Provisioned IOPS 架構讓使用者要在上面衝 IOPS 變得更容易...

EBS-Optimized instances 是把 EBS 使用的頻寬獨立出來,目前只支援 m1.large、m1.xlarge 以及 m2.4xlarge 這三種,其中 m1.large 跑到 500Mbps (理論值 62.5MB/sec),後面兩種可以上 1Gbps (125MB/sec),使得服務與 I/O 的頻寬不會互相干擾到...

在 Passion Bean 分享:System Operations for Startup

Passion Bean 的 Sting 與 ihower 邀請,到內湖用了兩個小時分享對於 Startup 公司在系統操作上的一些想法:

另外可以在 Facebook 上的活動頁 找到錄影。

一些關鍵字:

  • us-east-1:AWS 美東區的代號,位於維吉尼亞州。
  • 「萬事屋」指的是「新杰資訊科技股份有限公司」的老闆 Alex Wen。
  • Invalidation 與 Nameing Naming 是 CS 兩大難題:「TwoHardThings」。
  • 「未熟調教是一切邪惡的根源」出自劉燈「重新學C++」文章中 slzzp 的 comment

AWS 推出高速 I/O 的 EC2 instance

早上就看到 AWS EC2 推出 hi1.4xlarge 的消息:「New High I/O EC2 Instance Type - hi1.4xlarge - 2 TB of SSD-Backed Storage」(官方 blog)、「Expanding The Cloud – High Performance I/O Instances for Amazon EC2」(CTO Werner Vogels 的 blog)。

幾個比較重要的特性:

  • 60.5GB 記憶體
  • 10Gbps 網路
  • 1TB 的 SSD volume 兩個

前面兩個不會太意外,因為需要高速 I/O 的服務通常也都很需要用大量記憶體當作 cache 降低 I/O,也需要大量頻寬提供服務。用 SSD 也在預期的範圍內,不過提供的 SSD 空間居然這麼大...

當然,價位也不便宜,美東就要 USD$3.10/hour,冰島愛爾蘭則是 USD$3.41/hour (目前只有這兩區有提供)。如果以美東一個月 720hours 計算是 USD$2232,約台幣六萬六千多?

AWS SES 支援 DKIM

DKIM 全名 DomainKeys Identified Mail,是透過數位簽名技術確保 E-mail 的寄件人不是被偽造的,對於防止透過電子郵件網路釣魚是個還蠻有效的技術。

本來透過 AWS SES 寄信,要自己處理 DKIM 簽名的部份,不過今天 AWS 宣佈這項功能內建進 AWS SES:「Simple Email Service - Easy DomainKeys Identified Mail (DKIM) Support」。

於是,現在用 AWS SES 的人要 DKIM 只要把 SES 提供的 DNS record 設上去就可以了,比起之前自己得在 Sendmail 或是 Postfix 上弄一堆東西方便不少。

AWS CloudFront 增加的功能

引用 CTO Werner Vogels 寫的「Dynamic Content Support in Amazon CloudFront」這篇好了,雖然沒有講完整,但把重點都提到了,而且比官方網誌「Amazon CloudFront - Support for Dynamic Content」這篇清楚...

這次 AWS CloudFront 上的功能都可以在 AWS Management Console 上設定,不需要另外安裝 3rd party 軟體或是自己寫程式呼叫 API。

這次最主要的更新在支援 query string。在之前的版本,這兩個 url 會被 CloudFront 當作是同樣的 url 而被 cache 成同一份:

  • http://www.example.com/user.php?username=gslin
  • http://www.example.com/user.php?username=gslin2

而這次可以設定是否要將 query string 納入計算。

另外一個重要的設計是支援 Cache-ControlExpires,當 Cache-Control 給出 no-cache 的時候,新版的 CloudFront 可以依照 Cache-Control 的要求處理。

有了這兩個改善後,本來需要在 server workaround 的事情就可以交還給 CloudFront 處理。之後應該是試著支援像 AkamaiDynamic Site Accelerator 的功能?另外一方面也有可能讓消費者自己選擇 PoP?

功能愈來愈完整了...

Hosting Plan

2009 年在 Ptt 寫的文章有提到不少 hosting plan,2012 年現在有不少變化...

VPS 的部份,Linode 的 CPU 一向是 C/P 值超漂亮的方案。最小的方案從 384MB RAM 變成 512MB RAM (價錢沒變,仍然約 USD$20/month),在有 swap 的情況下,即使跑 ApacheMySQL 也應該還算堪用。

Linode 另外一個改變是多了東京機房。東京機房與台灣各 ISP 之間的 latency 都相當好。當以台灣使用者為主要族群而挑選 VPS 時,在東京的 Linode 主機通常是個好選擇。如果在 Linode 上面有 High Availability 需求,也有 NodeBalancer 可以用 (2011 年,Introducing NodeBalancer)。

Linode 已經算是不錯的方案,但如果你對 latency 非常重視 (日本與台灣之間大約有 30ms 的 latency) 而一定要使用台灣內部的 VPS (像是遊戲的伺服器),那麼中華的 HiCloud 會是一個可以考慮的方案。

PaaS 的部份,目前比較有名的是 Heroku,支援的語言多,而且有 free quota,對於一些小站台或是測試應用應該是沒什麼問題,不過目前只有美東 us-east-1 機房 (Heroku 用 AWS 為底層)。另外 AWS Elastic Beanstalk 的方案也可以看看,目前支援 JavaPHP 兩種語言,區域比較多。

如果是 IaaS 的部份,AWS 能提供的功能比較多,AWS 東京機房對台灣的速度也不差。另外 AWS S3 在雲端靜態儲存這個領域還是領先者,就算用 VPS 或是 Dedicated Hosting 也還是可以考慮把一些東西放到 S3 上。

Dedicated Hosting 的部份,目前還會選的是美西的 Energy Group Networks (EGIHosting) 以及 Limestone Networks。需要大頻寬的時候可以到 Dedicated Servers 這頁翻翻,或是寫信跟 EGIHosting 要 quote,當你 commit 1Gbps 含機器的價錢大約是 USD$1/Mbps (台幣 NTD$30/Mbps),連台灣的頻寬應該是透過 HE 或是 nLayer 連進來。

至於 CDN 服務,我的建議是,如果你不知道哪個比較好,就不要用吧... 等到你開始 profiling & analyze 後再回頭決定。

Archives