MyCSS

2014/04/17

AWS Elastic BeanstalkはImmutable Infrastructureそのものじゃないか はてなブックマークに追加

ちょっと遅くなってしまいましたが、第13回 JAWS-UG札幌 勉強会で発表してきましたので、ご報告いたします。なお、今回でこのシリーズは完結いたします(笑)



ちなみに先月の 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はこの点を意識しているのかどうか・・よく解りませんけども、個人的には良く出来ているなぁ、と思います。

運用のベストプラクティス?

Amazonの長年の経験で培ってきたものがAWSにあるとすれば、まさしくサイト運用のベストプラクティスが詰まったものがElastic Beanstalkなんじゃないか?と思います。他のサービスに比べれば地味でパッとしないかもしれませんけども(笑)使いどころを間違えなければ、Elastic Beanstalkは初期学習コストも異様に低いですし、サイトの運用負荷を劇的に下げられる強力なサービスだと思います。