S3のエラーハンドリングPerl編

S3は作ったばかりのバケットを扱おうとすると、307 redirectを返すことがある。他にも http://docs.amazonwebservices.com/AmazonS3/latest/API/ErrorResponses.htmlにあるように多数のエラーレスポンスは定義されている。が、3xx系は扱えないライブラリであるLWPがメインのperlの場合

CPANに登録されているAmazon::S3とNet-Amazon-S3ではこんな対応がされている。(というかここのコメント100%同じ。ライセンス的にはokだからいいんだろう)

cpansearch.perl.org/src/TIMA/Amazon-S3-0.45/lib/Amazon/S3.pm

http://cpansearch.perl.org/src/PFIG/Net-Amazon-S3-0.56/lib/Net/Amazon/S3.pm

# Send a HEAD request first, to find out if we'll be hit with a 307 redirect.
# Since currently LWP does not have true support for 100 Continue, it simply
# slams the PUT body into the socket without waiting for any possible redirect.
# Thus when we're reading from a filehandle, when LWP goes to reissue the request
# having followed the redirect, the filehandle's already been closed from the
# first time we used it. Thus, we need to probe first to find out what's going on,
# before we start sending any actual data.

ということらしい。LWPがサポートしてないが故にHEADをわざわざ発行しているという。

Perlモジュール/LWP - Walrus, Digit.

POSTメソッドの場合でもこれを行うには、正攻法であればrequest処理時に返されるHTTP::Responseオブジェクトの内容を調べます。 リダイレクトが指定されていると、HTTP::Responseオブジェクトのis_responseメソッドの返り値は1になります。 この時に、HTTP::Responseオブジェクトのheaderメソッドで'Location'に対応する値（リダイレクト先のURLです）を取得し、このURLをGET（リダイレクトはGETで行うのが標準です）すれば良いのです。

VPCでのELB活用

VPCはAWSにおいて相談だれる様々な事を解決するツールというか環境なので、みなさまには大いに活用していただきたいと思っています。
正直、今からシステムを作るならばVPCを使わない理由を探すのがむずかしいほど。

VPCでならばNACLした後にELBに渡ります。RT @sato_shi: ELBでiptables的な何かをしたいっす。現在、ELB通すとL7でX-Forwarded-For/HostとかApache等でフィルタするしかない？ #AWS77 #jawsug

— ARAKI Yasuhiroさん (@ar1) 6月 22, 2012

こんなことを書いた。

これを絵にするとこんな具合。

通常のEC2でのELBは、いわば共用のネットワークセグメントで動作しており、自分でELBへどんなIPからアクセスすることができる。



VPCではELBは自分専用のVPC空間の内部に作成されるため、自分が設定したNACL下で動作させることができる。

TOP500の更新

スパコン「TOP500」、米「Sequoia」が首位に--「京」は2位 - CNET Japan

最新版「TOP500」リストによると、ローレンスリバモア米国立研究所にあるIBMの「Blue Gene/Q」スーパーコンピュータである「Sequoia」が、16.32ペタフロップスを達成したという。前回首位だった「京」が10.5ペタフロップスでそれに続いた。同リストは、ハンブルグで開催されているInternational Supercomputing Conferenceにおいて現地時間6月18日に発表された。

まあそんな記事はさておき。

AmazonはTOP500の42から72位に落ちました。前回あったもうひとつの記録は今回は圏外になりました。

ネットワークに目をやると、上位はtofuにinfinibandにのオンパレード。
イーサネットだけのデータだと最速は61位のHPのクラスタで、2位がAWSでした。
その61位のクラスタがEfficiencyがたったの28。Nvidia GPGPUパワーでたたきだしたもの。

そしてGPGPU搭載モデルがことごとく上位から消えていました。

AmazonLinuxにVarnish3をいれるはなし

@ar1 あれバグってますよね

— Issei Narutaさん (@mirakui) 6月 13, 2012

バグとなれば見るしかないですよねー。http://repo.varnish-cache.org/source/varnish-3.0.2.tar.gz からソースとってくる

yum install pcre-devel
configure
make
make install

これで問題ない。まあyumつかえばさくっとvarnishはいるんだけど。

結局、ヘルスチェック機能はまだ使わんでおいとこうという結論。

Amazon ELBをうまくつかうには、KeepAliveを有効にしよう。Timeoutは60秒より だいぶ長くしよう。その背景。

鯖管のメモ帳: AWSのELBでHealthyHostCountが0になるという記事の中で

■AWSのELBとApacheを使う際の注意点

・Timeoutは120以上が推奨

・ApacheのKeepAliveは有効にすべし。ELBとの接続効率があがる。

という形ですでにやるべきことは書いてあるのが、なぜそうなるか。。(いそがしい人は後は読まなくてok！)

根本的な理由としては、ELBはTCPを単にリレーしているのではなくて、アプリケーションレイヤのプロキシであることによるものが大きい。ELBはバックエンドのEC2との間で無通信の場合でも60秒はセッションを維持する。

ELBはTCP Persistent Connectionを提供し、webサーバとの間のTCPセッションをつかいまわすことによってTCPのハンドシェイク時間を削減して高速化している。



webサーバのTimeoutを60秒より短かくするとどうなるか。どうかするとあわれなELBはwebサーバから切られたことを知らず、TCPセッションを使おうとして失敗することもある。折角ハンドシェイクをとばして高速化できるチャンスを逃してしまうことになる。

じゃあなんでELBでないフツーのサイトやフツーのロードバランサで構成するwebサイトにおいて「KeepAliveを無効にして、Timeoutは短かく(たとえば5秒)しよう」という言説が流れているのか。

これは、クライアントがずっとコネクションをはりっぱなしにする傾向があるから。

HTTP keep-alive connection timeouts « FastMail.FM Weblog というすばらしい記事によると、

• Opera 11.11 – 120 seconds
• Chrome 13 – at least 300 seconds (server closed after 300 second timeout)
• IE 9 – 60 seconds (changeable in the registry, appears to apply to IE 8/9 as well though the page only mentions IE 5/6/7)
• Firefox 4 – 115 seconds (changeable in about:config with network.http.keep-alive.timeout preference)

といった具合。ほとんどのwebサイトにおいては、いくら通信が高速化されるとはいえ100秒も通信維持されても困ることばかりだろう。

「数千数万のクライアントからのコネクションを維持したままだとサーバのメモリを食って死んでしまう」→「ならば、そんなクライアントとは手を切るぜ」→「そのためには..」という常識がうまれた。

ELBはトラフィックが増えれば自在にリソースを変更するすぐれもの。そもそもELBがTCPのセッションを維持するのにどんだけメモリを食っていようが、そんなことはユーザの知ったことではない。そこが普通のロードバランサとは違う。

ELBをサーバとクライアントの間において、コネクションを維持したらどうなる? クライアントががんばって用意しているHTTP keepaliveはELBとの間で維持して、サーバはELBとのコネクションだけを考えればいいから、高速化する。

というわけで、ELBを使わない手はないし、その機能を生かすためにwebサーバはTCP keepaliveを有効にしてTimeoutを120秒にするのがいいのでした。

RDSは1秒未満のスロークエリを記録できない。そこでmin_examined_row_limit

1以上のintegerですね。RT @hiroohi: あれ？RDS(mysql)のParameterGroupって、long_query_timeは1秒以上しか設定できない？ #jawsug

— ARAKI Yasuhiroさん (@ar1) 6月 13, 2012

いろんな人に言われることではあるが、RDSは1秒未満のスロークエリを記録できない。

そこで使えるひとつの方法は、 minexaminedrow_limitを使うこと。折角なので超プロのblogから引用。

漢(オトコ)のコンピュータ道: MySQL 5.1のスロークエリログ

min_examined_row_limitという変数が追加されたのも見逃せない。この変数を指定すると、「○○○行以上の行をテーブルから読み込んだクエリをスロークエリログに記録する」という指定ができるようになる。多くの行を読み込むクエリは、潜在的にサーバ全体の性能を劣化させる危険性があるので、long_query_timeを少し大きめにしておいて、このオプションを併用しておくといいだろう。例えばmin_examined_row_limit=10000など。いずれの変数もアプリケーションの特性に合わせて調節して欲しい。

これをRDSで一発でやるなら

$ rds-modify-db-parameter-group sweet-parameter-group --parameters "name=slow_query_log, value=ON, method=immediate" --parameters "name=long_query_time, value=1, method=immediate" --parameters "name=min_examined_row_limit, value=10000, method=immediate"

といった具合になる。

マイクロDBインスタンスのRDSのアレな活用

【AWS発表】Amazon RDS MySQL を月26ドルで! マイクロDBインスタンスが利用可能に! 

ということで、安くRDSを使うことができる。ただし、マイクロインスタンスなのでどうしようもなく遅い。耐えられないくらい正直遅い。

が、それを逆手にとった活用法がある。

それはスロークエリの検出。