Amazon EC2 のインスタンスは、結構簡単に止まる。負荷に耐えられなくなると、無反応になる場合がある。ssh ができず、AWS Console からのリブートも効かず、Terminate もできない。ping にはかろうじて反応していることもある。OS の /var/log には、止まっている間の記録は何もない。

こんなときどうするか。アタッチした外付けEBSのスナップショットを取ってボリュームを作り、他のインスタンスにつなげるくらいしか、できることがない。それすらもできないかもしれない。EBSのデタッチはできないと思ったほうがいい。強制デタッチもできない。ルートパーティションのデータは救い出せない。復旧するのを待つしかない。

Premium Support サービスを購入していなければ、AWS の公開フォーラムに書きこんで、中の人が対処してくれるのをじっと待つ。あるいはフォーラムに書きこまなくても、Amazon の監視で引っかかればリブートしてもらえるようだ。この前止まったときは、12時間以上たってからリブートされていた。12時間以上止まっているインスタンスをリブート対象にしているのかもしれない。

AWS Premium Support は、技術的支援を受けるためというよりは、大事なインスタンスが止まってしまったときに緊急対応してもらうためにあるのではないだろうか。品質の低いものをわざと提供してそこで稼いでいる、とまでは思わないが。

教訓 ・EC2インスタンスはいつ止まってもおかしくない。 ・救い出したいデータは、必ず外付けのEBSに格納する。 ・負荷が集中しそうで、止まって欲しくないサーバは、Microインスタンスなどではなく、処理能力に余裕のあるインスタンスのほうがいい。

Elastic Load Balancer は遅い。ELB を通すと、300-600ms ほどレスポンスが遅くなる。100ms を削ってユーザエクスペリエンスを高めたいときに、300ms はつらい。測ったことはないが LVS だとそんなに遅延しないんじゃなかろうか。ELB は Squid の改造版という話を聞いたことがあるが、ソース見当たらず。動いているレイヤが違うなら、遅いのは、一般的に考えて仕方がない。ab で軽く負荷テストしたところ、レスポンスは悪いものの、スループットは特に問題がない印象。

ELB は HTTPS を HTTP に変換して後ろのサーバに送る SSL Termination ができるものの、SSL Termination も遅い。4月に試したときは、20-25req/sec くらいまでしか処理できなかった。トラフィックが増えると自動的に高性能なノードに移るから、その閾値までいかなかったのかもしれないが、負荷分散のために差し挟む ELB がボトルネックになるようでは採用しにくい。HTTPS のプロトコルをスルーして、443/tcp としてそのままウェブサーバに転送すれば、このスループット悪化は起こらない。

Apache の AuthLDAPURLにLDAPサーバを複数指定するときは、ダブルクォーテーションで囲った上でスペース区切りでホスト名を並べなくてはならない。直観的じゃない文法だな。

AuthLDAPURL “ldap://ldap-master ldap-slave/ou=Users,dc=xxxx,dc=xxx?uid?sub?(objectClass=posixAccount)”

S3 にナイショの情報を格納して、スクリプトから取得できるようにしたかった。S3 は Basic認証などには対応していないので、everyone readable にしない限りは wget や curl で取ってこれない。

そこで、s3curl (http://aws.amazon.com/code/128) という curl のラッパが作られた。早速試すと、エラーが起こる。

SignatureDoesNotMatch The request signature we calculated does not match the signature you provided. Check your key and signing method.

なぜだろう。東京リージョンには対応していないのだろうか。と思って s3curl.pl を覗くと、tokyo region の定義が無かった。ので、追加してやる。

begin customizing here

my @endpoints= ( ‘s3.amazonaws.com’, ‘s3-us-west-1.amazonaws.com’, ‘s3-eu-west-1.amazonaws.com’, ‘s3-ap-southeast-1.amazonaws.com’, ‘s3-ap-northeast-1.amazonaws.com’ ); # ここ

これでめでたく動くようになった。

Amazon EC2 ではスポットインスタンスを徹底的に活用しようと思う。だって、安いのに品質は同じだもん。

そのときの「時価」で1時間ごとに価格が変動するスポットインスタンス。入札価格さえ十分に高くしておけば、強制的に停止させられることもない。現にいままで、一度も止められたことがない。皆が思う以上に安全なのだ。

という神話がこの週末に崩壊した。1時間1ドルで入札していたインスタンスで、瞬間的に時価が1ドルを超えてしまった。可用性を高めるために2台で運用していたのに、2台とも順次停止した。実運用しているインスタンスじゃなかったのがせめてもの救い。

反省点 ・アベイラビリティゾーンさえばらしておけば、今回の停止はなかった。ゾーンが異なれば時価も異なる。これはつい最近、導入されたAWSの新機能。 ・止まってほしくないインスタンスなら、入札価格はもっと高く、ありえないくらいに高くしておくべきだった。 ・いつ停止してもいいような備えをしておくべきだった。スポットインスタンスを使う以上、時価が瞬間的に高騰して停止する可能性をゼロにはできない。