Web Console 總算可以拿 Access Key 查詢是哪個 IAM 使用者了

AWS Web Console 上可以用 access key 查詢是哪個 IAM 使用者了:「Introducing IAM Console Search」。

這樣就可以再查出這個 IAM key 有哪些權限...

Amazon S3 推出新的種類:Standard - Infrequent Access Storage

Amazon S3 推出了新的種類:「AWS Storage Update – New Lower Cost S3 Storage Option & Glacier Price Reduction」。

原先只有「Standard」、「Reduced Redundancy Storage」以及「Glacier Storage」三種,現在多了一種「Standard - Infrequent Access Storage」。

首先是計價模式,儲存的單價變便宜很多,但存取是要另外收錢的:

$0.0125 / gigabyte / month (one and one-quarter US pennies), with a 30 day minimum storage duration for billing, and a $0.01 / gigabyte charge for retrieval (in addition to the usual data transfer and request charges).

拉資料的費用相當的貴啊一個月拉兩次就超過 Standard Storage 的價錢了,所以這個「Infrequent」的要求其實頗嚴苛的...

另外空間的部份以 128KB 為最小單位在計價的:

Further, for billing purposes, objects that are smaller than 128 kilobytes are charged for 128 kilobytes of storage.

所以綜合起來看,Infrequent Access Storage 的設計上是拿來堆資料備份,但希望拉資料時很快就可以拉出來。其實就是 Google Cloud StorageNearline 的想法,一樣有存取另外收費的項目。不過 Nearline 有說平均的 latency 是三秒:

但 IA 好像是跟 Standard 相同等級?至少文章裡沒有提到...

GitHub 保護自家的 OAuth Access Token 不會進入 GitHub 上公開的 Repository

GitHub 的公告:「Keeping GitHub OAuth Tokens Safe」。

當你不小心把 GitHub 的 OAuth Access Token 推到 GitHub 的 public repository 時,站方會自動 revoke 掉:

Starting today you can commit more confidently, knowing that we will email you if you push one of your OAuth Access Tokens to any public repository with a git push command. As an extra bonus, we'll also revoke your token so it can't be used to perform any unauthorized actions on your behalf.

保護使用者在使用 GitHub 自家的產品。

RAID 卡的電池維護

實際的世界都是由 workaround 疊 workaround 解決問題的...

MySQL 資料庫一般都用 RAID 10,利用 RAID 1 的特性保護資料,並且利用 RAID 0 的特性提昇 IOPS 能力。

而這些 RAID 卡通常都會提供 cache,預設應該都會開 read cache,可以大幅增加 random read 的速度。而另外也可以打開 write cache (也就是 write-back),寫入時先寫到 cache 裡,RAID 卡馬上就會跟作業系統回報完成,藉以加速 random write 的速度。

但這樣就會有風險,當資料還沒寫入硬碟就斷電時就會遺失資料。所以在設定 write-back 的 RAID 卡上安裝電池就變成解法之一。

而電池會有壽命問題,所以配電池的 RAID 卡會每隔一陣子就放電測試電池可以撐多久,但在放電測試時,如果斷電就有可能造成資料遺失,於是又冒出很多方法解決。

也就是在「Learning to Deal With Learning」這篇提到 RAID 卡電池維護的事情。

每一層都是 workaround 想辦法解決問題,然後再用 workaround 解決前面造成的問題...

Anyway,有幾種解法,其中仍然對上層作業系統與應用程式透明的解法是:

  • 雙電池架構,很明顯的可以一次只測一顆。
  • 改用 NVRAM,就不需要電池了,不過速度以及成本會是另外一個問題。

另外,對上層作業系統與應用程式有影響的方式:

  • 放電測試時將 write cache 關閉,切回 write-through。這點在原文裡也有提到,效能其實會受到蠻大的影響。
  • 不放電測試了,但這樣的缺點就是拿安全性交換,當斷電時不知道能不撐過去。
  • 或是自己控制放電測試的時間,這可以配合上面切回 write-through 的方式,挑負載比較輕的離峰時間做。

看了下來雙電池架構還不錯,增加的成本還算可以接受,而且因為效能不受到影響,也確保資料安全性,整體維護起來比較簡單。而之後在規模更大的時候,應該就會直接考慮跳到自己放電測試的方式來處理電池問題...

Elastic Load Balancing 總算實做 access log...

AWSElastic Load Balancing 總算想起來這個欠了許久的功能,access log:「Access Logs for Elastic Load Balancers」。

原文裡有提到用 Hive 分析的部份,挑出最前面的欄位名稱就可以看出提供什麼資訊:

CREATE EXTERNAL TABLE elb_raw_access_logs (
     Timestamp STRING,
     ELBName STRING,
     RequestIP STRING,
     RequestPort INT,
     BackendIP STRING,
     BackendPort INT,
     RequestProcessingTime DOUBLE,
     BackendProcessingTime DOUBLE,
     ClientResponseTime DOUBLE,
     ELBResponseCode STRING,
     BackendResponseCode STRING,
     ReceivedBytes BIGINT,
     SentBytes BIGINT,
     RequestVerb STRING,
     URL STRING,
     Protocol STRING
)

裡面還有些資訊沒包含在上面,像是 availability zone。因為這個資訊是包含在檔名內:

In addition to the bucket name and the prefix that you specified when you configured and enabled access logs, the log file name will also include the IP address of the load balancer, your AWS account number, the load balancer's name and region, the date (year, month, and day), the timestamp of the end of the logging interval, and a random number (to handle multiple log files for the same time interval).

接下來應該要把現有的 ELB 都開起來 XD

加州理工學院對於學術研究的公開公告

引用加州理工學院的「Caltech Announces Open Access Policy」開頭:

On January 1, 2014, a new open-access policy for faculty's scholarly writings will take effect at the California Institute of Technology (Caltech). According to this policy, approved by the faculty at their June 10 meeting, all faculty members will automatically grant nonexclusive rights to the Institute to disseminate their scholarly papers, making wider distribution of their work possible and eliminating confusion about copyright when posting research results on Caltech's websites.

正式決議並公告,讓研究員 (包含教授與學生) 可以很自由的在自己的頁面上放自己的研究 (論文或是文章)。

愈來愈多學術單位往這類公開政策邁進...

HTTP Header 裡與安全相關的 Header 的分析...

還是在 Zite 上看到的,對最大的一百萬個網站分析與安全有關的 HTTP Header:「Security Headers on the Top 1,000,000 Websites: November 2013 Report」。

數字大致上都有增加,不過對我來說的重點在於有列出所有與安全有關的 HTTP Header...

可以看到有這幾個:

  • Access-Control
  • Content-Security-Policy
  • Strict-Transport-Security
  • X-Content-Security-Policy
  • X-Frame-Options
  • X-Webkit-CSP

剛好可以拿來 review 設定...