Elastic BeanstalkでカスタムAMIのタイムゾーンを変更してハマった件 Tweet

Elastic Beanstalkが日本に来てから約2ヶ月経ちますが、つい出来心で本格的に使う事になりましたので色々と触っております。 一般的にはどうなのかよくわかりませんが、自分のニーズでは標準のAMIそのままでは不足ですので、自ずとカスタムAMIを作成する事になります。

1. Beanstalk用のAMIの最新バージョンを探す
2. 普通にEC2インスタンスとして立ち上げて、ログイン。ごにょごにょする。 
3. AMIを保存して、AMI IDをメモっておく。 
4. BeanstalkのEnvironmentで、自分で作ったカスタムAMIのIDの指定をする。 

これでBeanstalkでアプリが起動してめでたしめでたし、のはずですが、しばらくすると勝手にEC2が落ちますw
BeanstalkのEventログを見てみると、あれ？BeanstalkがEC2インスタンスを落としてるじゃんw 自分で立ち上げておいて落とすなんてヒドい…



Beanstalkが立ち上げてくれたEC2にログインして、http://localhost:8080 を見てみるとちゃんと生きてる。と言う事は、Tomcatの死活監視をしてらっしゃるhostmanager様がたぶん勘違いしているはず…（Elastic Beanstalkの内部的な事は、こちらの資料に詳しく書かれています。: AWSマイスターシリーズReloaded(AWS Beanstalk)  ）

というわけで、ログ（/opt/elasticbeanstalk/var/log/hostmanager.log）を見てみました。すると、 というエラーが整然と並んで記録されておりますorz 

EC2のタイムゾーンを弄ったから？

ちょっとググってみたら、AWSのフォーラムに同じような質問がありました。

• AWS Developer Forums:multiple failures to retrieve status of instance - https://forums.aws.amazon.com/thread.jspa?threadID=63368 

質問の回答には「EC2のタイムゾーンをGMT以外で使わない事をオススメする」と言う事で…あぁ、確かに思い当たる節があるw 確かにカスタムAMIを作ったとき、タイムゾーンをJSTにしたわ。 と言う訳で、GMTに戻してみたら、hostmanagerのエラーは出なくなりました。ただ、そのままだとアプリ側の日付処理がずれるので、JVMのオプションに-Duser.timezone="Asia/Tokyo"を指定しました。かっこわるいけど仕方が無い…

これ、どうなんだろ？クラウド的（？）にはタイムゾーンはGMT！ってのも分かりますが、実際は変えちゃう事も多いのでは？

ちなみに問題のhostmanagerがtimestampをパースしている部分ですが、 となってます。Time.iso8601(timestamp)をお好みのものに変更すればうまく行きそうな気もしましたが、ハマるといけないので自重しました（笑）