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の新機能。 ・止まってほしくないインスタンスなら、入札価格はもっと高く、ありえないくらいに高くしておくべきだった。 ・いつ停止してもいいような備えをしておくべきだった。スポットインスタンスを使う以上、時価が瞬間的に高騰して停止する可能性をゼロにはできない。

Amazon EC2上に2台のサーバを作り、その上で内部向けDNSサーバを動かしたときに、DNS は TCP でも問い合わせできるのだと改めて知った。

server1 と server2 があり、server1 で DNS サーバが稼働している。server1 から server1 に対して nslookup すると瞬時に答が返ってくるのに、server2 から server1 に対して nslookup するとワンテンポ遅れる。おそらく1秒未満の遅れだが、こんなに遅いはずがない。

実は、server1 と server2 の間で udp/53 の通信が許可されていないことが原因だった。Amazon EC2 では、同じセキュリティグループのインスタンス同士でも、明示的に許可してやらなければ通信できない。Passive mode の FTP を使いたかった関係上、TCP は全通しにしてあったが、UDP は閉じたままだった。

こういうときリゾルバは、UDP での通信を試みたあとに、TCP を試す。この UDP の失敗を待つ時間が、ワンテンポの遅れになっているのだろう。DNS における TCP はゾーントランスファーでのみ使われるものと思っていたが、通常の問い合わせでも使われることを学んだ。

RFC 1035 Domain Implementation and Specification を見ると、UDP でも TCP でも使えるけど、オーバーヘッドの少ない UDP の方が好ましいと書かれていた。

4.2. Transport

The DNS assumes that messages will be transmitted as datagrams or in a byte stream carried by a virtual circuit. While virtual circuits can be used for any DNS activity, datagrams are preferred for queries due to their lower overhead and better performance. Zone refresh activities must use virtual circuits because of the need for reliable transfer.

実装上は、UDP のデータグラムサイズを超える場合や、今回のように UDP での問い合わせに失敗した場合に TCP が使われるようになっているようだ。