長いことお疲れ様でした

仕事場で個人用IMAPサーバとして働き続けてきたSun Blade 1000。

この夏から職場のメールがGoogle Appsに移行開始し、先週末で移行完了。個人用IMAPサーバも不要となったので先ほど停止した。実は個人用IMAPは90年代後半からずっと動かし続けており、このSun Bladeはたぶん5代目だと思われる。受け取ったメールはスパムやウィルス(笑)含めて全て保存してきた。

で、こういうデータは捨てるのももったいないのでAmazon S3に退避させることに。Duplicityを使おうとしたが、世の中には親切な人がいるものでより使いやすくするスクリプトが公開されていた。→Bash Script: Incremental Encrypted Backups with Duplicity (Amazon S3)

本来はこのスクリプトをcronで動かして差分バックアップを取るべきなのだろうがmaildir形式のディレクトリはファイル名とか激しく変わるのでどれくらい効率的なのかは不明。でも、IMAP止めてしまった今はどうでも良い話。

ということでサーバーから外したディスクをCeleron 2.2GHzの激遅LinuxにつないでS3へのバックアップを始めたが...tar、圧縮、PGP暗号化、分割、S3送信というのをちまちま繰り返すのでとても遅い。1時間で250〜300MBくらいか。過去メール全部がS3に収まるのは年明けになるかも（笑

米国愛国者法(Patriot Act)? で、何が怖いの？

日本出張でクラウドの話をするとかなりの確率で返ってきたのが「でもAmazon Cloudって、アメリカの愛国者法(Patriot Act)適用対象なんでしょ？」という懸念であった。調べたらこの春あたりから話題になっていたらしい。

• マイクロソフトのクラウド、欧州データセンターも米パトリオット法（愛国者法）の影響下だと認める
• 米国外のデータセンターでも、米国企業の運営なら米国法でデータを持ち出される可能性がある？

一方で、先月末にはこんなニュースが流れていた。

• Dassault Systèmes Goes Cloud with Amazon Web Services

Dassaultはフランスの会社で、PLMや3次元CADなどのサービスを提供している。顧客にはAirbusやらEntergy Nuclearなどの企業名がずらり。本当に米国愛国者法が怖いのであれば、とてもじゃないけどアメリカのクラウド事業者などにデータなど預けられないはずだ。想像だが、インスタンスやボリュームレベルで暗号化しているのであろう。

S3静的コンテンツサイトの利用料

S3で静的コンテンツWebサイト構築、で構築したhttp://www.masasushi.com/の5月分利用料請求が来た。

S3利用料金

• データ保存が$0.53
• PUT/COPY/POST/LISTが$0.01
• GETは8815回で$0.01

これにデータ転送量代が加わった。4.3GBの転送で$0.41。

合計で$0.96。静的コンテンツしか置かない閑散サイトだけど、これはとても安いよね。従来使っていた貸しサーバには毎月$20近く払っていたから。

動的サイトにおいても画像やCSS定義はS3に括り出してしまうといいかもしれない。

Hello Amazon MP3 Player, Good Bye iTunes

初代iPodに始まり、iPod Mini、iPod Nano、iPod Shuffle、iPod Touch、iPhone 2G、iPhone 3GS、iPhone4とAppleの策略にハマって投資を続けてきた我が家であるが、昨日をもってiTunesとおさらばすることができた。楽曲データはすべてAmazon Cloud Driveに移行。AppleのDRMがかかっていたAACデータも、iTunesからCDに焼いた上でMP3に落とせばプロテクトを外せる。面倒くさがり屋は仮想CD Driverを探してきて、そいつを通じてdmgイメージに焼き付ければいいだろう。

Amazon Cloud Driveのお値段は

• 5GBまで...無料
• 20GB...$20/年
• 50GB...$50/年
• 100GB...$100/年

おそらく背後にはAmazon S3が使われているのだろうけど、素のS3を1年間20GB使えば、$35くらい請求される。それより安いのは「20GB契約しても、全部使われることはない」「Amazon MP3 Storeで買い物してもらえる」という読みがあるのだろう。

Amazon Cloud Driveに入れたMP3楽曲は、パソコンからもAndroid携帯からも「ネットワークがつながっていれば」どこからでも聞ける。携帯網を使う場合はデータ通信定額でないと死亡するだろうが、まあ普通はWiFiで聞くだけだろうし。必要なら手元のSDカードにダウンロードしておくこともできる。

そして、母艦のPC/Macがいらないというのは本当にありがたい。さようならiTunes。

S3で静的コンテンツWebサイト構築

ずっと放置していたmasasushi.comのサイトをAmazon S3上に移転した。手順は

1. S3バケット作成。自分の場合はwww.masasushi.comというサイトを立ち上げるのでwww.masasushi.comというそのまんまのバケットを作った。
2. S3バケットの属性を変更し、Webサーバになるようにする。indexや404で表示するオブジェクトの指定もやっておく。
3. DNSの定義を修正。www.masasushi.comのCNAMEを、S3 Endpoint(自分の場合は http://www.masasushi.com.s3-website-us-east-1.amazonaws.com/ )に設定。

これだけ。Apacheの設定もPHPやらRailsやらの設定も一切なし。そりゃ、静的サイトだから当然といえば当然だけど、静的サイト構築のためにわざわざOSやらApacheやらの設定をするというのも馬鹿らしい。S3に任せられるというのは実にらくちん。

気になるお値段だが...

• S3領域利用料は1GBを一ヶ月保存しても$0.140
• S3へのPUT, COPY, POST, LISTリクエストは1000回/月で$0.01
• S3へのGETリクエストは10000回/月で$0.01

ということで、masasushi.comが月$0.20越えたら大事件だと思って良かろう。16円。（笑

昔懐かしいKompozerみたいなHTMLエディタが、FTPだけではなくREST APIに対応して、Amazon S3に直接書き出せるようになったら、S3 Webサイトの用途も広がってくるのではなかろうか。

一方で、バケット名とサイト名との対応を考えると、www.◯◯◯◯.comみたいなバケット名を今のうちに取得しておく動きが懸念される。ドメイン管理者は自分のところの名前のバケット名を念の為に押さえておくほうがいいのでは。

Amazon謹製Linux AMIでGAE開発しようとしたらPython2.5が入ってなかった、の巻

この後買う予定のEee Pad TransformerとAmazon EC2だけで開発をしてみようと思っているのだが、当面は一人での開発なのでMicro Instanceでやってみようと決意。で、これは非力なので自分が得意のGentooは苦しい。

そこでAmazon謹製Linux AMI(ami-8c1fece5)を使うことにしたのだが、なんとPythonは2.6しか載ってない。慣れないyumコマンドで調べてみたが、どうやらPythonは2.4と2.6しか用意されていない模様。

ちうわけで、ソースからコンパイルすることにした。って、結局Gentooより手間かかってるし（苦笑

1. コンパイラとかぶちこむ。

# yum groupinstall "Development Tools"

2. Python 2.5.5のソースを取ってきて展開。
3. /opt/python2.5の下に設置する

$ ./configure --prefix=/opt/python2.5
$ make
$ sudo make install

4. シンボリックリンク作成

# ln -s /opt/python2.5/bin/python /usr/bin/python25
# ln -s /opt/python2.5/bin/python /usr/bin/python2.5

5. /etc/ld.so.conf.d/opt-python2.5.confを作成。中身は以下の一行。

/opt/python2.5/lib

6. ldconfig実行

# ldconfig

7. virtualenvとvirtualenvwrapperのソース取ってきて、設置。それぞれ

$ sudo python setup.py install

8. GAE SDKのソース取ってきて展開。PATHを通しておく。
9. GAE用のVirtualenv設置

$ source virtualenvwrapper.sh
$ mkvirtualenv -p python25 GAE
$ workon GAE
(GAE) $

10. sqlite3周り

$ sudo yum install sqlite-devel
$ easy_install pysqlite

11. PIL周り

$ easy_install pil

EC2のMicro Instanceは安いし、起動・停止が速い。必要なときにコンソールから起動して、開発作業を終えたらコンソールから停止。Stop、ね。Terminateしたら全てが消える（笑

Security Groupで自端末からsshのみ繋がるようにして、ssh接続時にDynamicForward使えば他所からの変なアタックに悩むこともないでしょ。

Amazon Cloud障害に思う

ということで今朝出社した時点でAmazon Cloudの障害を知ったのであった。やられているのはUS-EastのECNとRDSで、自分が関わっているシステムの本番DB(RDS)も引っかかっている。あと、チームの作業を記録しているRedmineのDBもEBS上にあるので、やはりダメ。

以下、西海岸午前9時時点でのAmazon側発表。

ECN

1:41 AM PDT We are currently investigating latency and error rates with EBS volumes and connectivity issues reaching EC2 instances in the US-EAST-1 region. 

2:18 AM PDT We can confirm connectivity errors impacting EC2 instances and increased latencies impacting EBS volumes in multiple availability zones in the US-EAST-1 region. Increased error rates are affecting EBS CreateVolume API calls. We continue to work towards resolution. 

2:49 AM PDT We are continuing to see connectivity errors impacting EC2 instances, increased latencies impacting EBS volumes in multiple availability zones in the US-EAST-1 region, and increased error rates affecting EBS CreateVolume API calls. We are also experiencing delayed launches for EBS backed EC2 instances in affected availability zones in the US-EAST-1 region. We continue to work towards resolution. 

3:20 AM PDT Delayed EC2 instance launches and EBS API error rates are recovering. We're continuing to work towards full resolution. 

4:09 AM PDT EBS volume latency and API errors have recovered in one of the two impacted Availability Zones in US-EAST-1. We are continuing to work to resolve the issues in the second impacted Availability Zone. The errors, which started at 12:55AM PDT, began recovering at 2:55am PDT 

5:02 AM PDT Latency has recovered for a portion of the impacted EBS volumes. We are continuing to work to resolve the remaining issues with EBS volume latency and error rates in a single Availability Zone. 

6:09 AM PDT EBS API errors and volume latencies in the affected availability zone remain. We are continuing to work towards resolution. 

6:59 AM PDT There has been a moderate increase in error rates for CreateVolume. This may impact the launch of new EBS-backed EC2 instances in multiple availability zones in the US-EAST-1 region. Launches of instance store AMIs are currently unaffected. We are continuing to work on resolving this issue. 

7:40 AM PDT In addition to the EBS volume latencies, EBS-backed instances in the US-EAST-1 region are failing at a high rate. This is due to a high error rate for creating new volumes in this region.

RDS

 1:48 AM PDT We are currently investigating connectivity and latency issues with RDS database instances in the US-EAST-1 region. 

2:16 AM PDT We can confirm connectivity issues impacting RDS database instances across multiple availability zones in the US-EAST-1 region. 

3:05 AM PDT We are continuing to see connectivity issues impacting some RDS database instances in multiple availability zones in the US-EAST-1 region. Some Multi AZ failovers are taking longer than expected. We continue to work towards resolution. 

4:03 AM PDT We are making progress on failovers for Multi AZ instances and restore access to them. This event is also impacting RDS instance creation times in a single Availability Zone. We continue to work towards the resolution. 

5:06 AM PDT IO latency issues have recovered in one of the two impacted Availability Zones in US-EAST-1. We continue to make progress on restoring access and resolving IO latency issues for remaining affected RDS database instances. 

6:29 AM PDT We continue to work on restoring access to the affected Multi AZ instances and resolving the IO latency issues impacting RDS instances in the single availability zone. 

8:12 AM PDT Despite the continued effort from the team to resolve the issue we have not made any meaningful progress for the affected database instances since the last update. Create and Restore requests for RDS database instances are not succeeding in US-EAST-1 region.

Amazonの中の人達が頑張ってくれているけど、今のところ回復の予定は不明。Multi-AZも(最終的には切り替わったようだけど)切り替えに時間がかかっているということだったので、多重化して備えていた人たちもそれなりに影響があったのではないか。

こういう事件があると「ほ〜らパブリッククラウドは危険だよ」と言う人が出てくるだろうけど、自分はむしろ今回の事故で「より安く確実に待機系に切り替える方法」が色々提案されると予想している。要はEBSが死んだ時の対処方法だわな。

EBSのSnapshotをS3に定期的に投げて、EBSが死んでAZ切り替えもできないときはEC2のでかいのを立ち上げてそこでVolume復帰させる、ってのがいいのかな。うちらの使ってるのは10GB程度なので非常時はなんとかなるんじゃなかろうか。

09:54追記

8:54 AM PDT We'd like to provide additional color on what were working on right now (please note that we always know more and understand issues better after we fully recover and dive deep into the post mortem). A networking event early this morning triggered a large amount of re-mirroring of EBS volumes in US-EAST-1. This re-mirroring created a shortage of capacity in one of the US-EAST-1 Availability Zones, which impacted new EBS volume creation as well as the pace with which we could re-mirror and recover affected EBS volumes. Additionally, one of our internal control planes for EBS has become inundated such that it's difficult to create new EBS volumes and EBS backed instances. We are working as quickly as possible to add capacity to that one Availability Zone to speed up the re-mirroring, and working to restore the control plane issue. We're starting to see progress on these efforts, but are not there yet. We will continue to provide updates when we have them.

暫定情報だが、障害の原因が追加されていた。

• ネットワーク障害でEBSボリュームで大規模な複写(mirroring)が多発。
• US-EastのAZにおける領域が不足。結果、EBS上でのVolume生成速度が低下。
• EBSの制御系一部に処理が殺到。

今はAmazonの中の人達が頑張ってEBSの領域を追加しているらしい。待つしかないけど、頑張れ中の人達！

15:00追記

2:35 PM PDT We have restored access to the majority of RDS Multi AZ instances and continue to work on the remaining affected instances. A single Availability Zone in the US-EAST-1 region continues to experience problems for launching new RDS database instances. All other Availability Zones are operating normally. Customers with snapshots/backups of their instances in the affected Availability zone can restore them into another zone. We recommend that customers do not target a specific Availability Zone when creating or restoring new RDS database instances. We have updated our service to avoid placing any RDS instances in the impaired zone for untargeted requests.

うちらのRDSインスタンスはまだ死んでいるけど、スナップショットは見えるようになったのでそれを元に別のRDSインスタンスを立ち上げてサービス復旧。丸々14時間止めてしまったのは自分でも情けない。ということで、EBSと並行してS3にもスナップショットを置くようにする。

20:50追記

まだEBS/RDS障害は続いている。Hootsuiteとか大変なんだろうなぁ。

前述のようにRDSのスナップショットをEBSとS3に取るようにしたので、安心して眠れるようになった。