ちなみに先月の JAWS DAYS 2014 では、Immutable Infrastructureのトラックが常に超満員でして、通路にまで人が溢れおりました。また、東京方面ではImmutable Infrastructure Conferenceが開催される位、ちょっとしたイミュータブル祭りになっているようです（笑）しかし、その中であまりAWS Elastic Beanstalkについて話題が出てこない気がしたので、今回あえて発表させてもらいました。
まだサーバーにSSHでログインしてるのかい？
AWS Elastic Beanstalkは、まさしくBlue Green Deploymentをするためのサービスですし、そもそもEC2起動時にkey pair指定をしなくても良い=サーバーにログインしなくてもいいんじゃね？という事実が、イミュータブルっぷりを発揮しております。※ちなみにスライドにもある通り、個人的にはkey pairを指定していますw でも個別のサーバーにSSHでログインする機会は滅多にありません。
Elastic Beanstalkがリリースされた2010年当時は、このkey pair指定をしなくても良い、という意味が全く分かりませんでした。当時はconfigで環境を自動構成する機能（公式ドキュメント）もなく、カスタムAMIをあらかじめ準備する必要がありました。しかし、カスタムAMIを作るという事は、そのAMI自体を管理して行かなければならない、という別のタスクが発生します。例えば、先日のHeartbleed Bugのような重大なセキュリティの問題が発生した場合、そのソフトウェアを最新版に更新した上で、再度AMIに保存し直す、といった作業が発生します。管理すべきものを増やしたくないのに、これでは本末転倒です。Chefなどのプロビジョニングツールも良いのですが、そこまで大げさじゃないんだよなぁ、という場合、このconfigがちょうど良い感じなんです。
ちなみにconfigではスクリプトも実行出来ちゃいます。ということは、要するに何でも出来るのですが（笑）configでは書ききれずにスクリプトを書いてしまう場合は、無理してElastic Beanstalkを使わずに、別のソリューションを使った方が良いと思います。（【参考】EC2 インスタンス上のソフトウェアのカスタマイズ）
インフラの構成管理をある意味強制される
基本的にconfigはアプリケーションのソースコードの中に入ります。具体的には$APP_ROOT/.ebextensions/*.configという場所に入りますので、基本はgitやsvnなどのソースコード管理システムの中に一緒に放り込まれるでしょう。そうすると、インフラの構成もバージョン管理されてしまうという・・ まさにDevOpsな世界が自動的に出来上がりますw AWSはこの点を意識しているのかどうか・・よく解りませんけども、個人的には良く出来ているなぁ、と思います。
