「明日、このサイトがテレビで取り上げられます」 そのとき、OpsWorksならどうする？

　前回の記事ではOpsWorksで運用することを考えたインストールのポイントを紹介していきました。

　今回は、実際に運用をしていくとよく起こり得るケースを想定して、「この場合はこうする」という鉄則をまとめて行きます。

　本稿の構成は皆さんが利用する際の「逆引き辞典」になればと考えていますが、AWSは進化の早いサービスであるため、今日の時点での最善が半年もすれば最善ではない可能性もあります。

前回からのアップデートを整理する

　既に前回の記事からのアップデートとして、AWSが提供するLoadBalancerのElasticLoadBalancing（ELB）、Amazon CloudWatchが利用できるようになっており（2013年5月14日から）、インスタンスのタイプにt1.microが使えるようになっています（2013年4月25日から）。

　前回の続きを進める前に、まずはこのアップデートについて追いかけておきましょう。

　今までは最低でもM1.smallというインスタンスを立ち上げる必要がありましたが、2013年4月には起動するインスタンスの種類でT1.microが使えるようになりました。これによって、テスト環境などのコストを半分以下に減らすことが可能になりました。

　また、2013年5月に、CloudWatchでLayerごとの監視が可能になりました。これによってAutoScalingと組み合わせて、より柔軟にスケールできるようになっています。

図1　Monitoring

ちなみに、ELBはHAProxyのようにLayerとして存在するのではなく、Layerに対して設置するようになっています。OpsWorksでELBを使用するために、まずManagementConsoleなどでELBを作成しておく必要があります。

　これは筆者の予想ですが、EC2が起動時にELBに自分自身を登録するという動きをするようです。ですから、SSHで接続できるようになっても、しばらくの間は、ELBのInstancesには出てきません。

図2　addELB

　「AddELB」をクリックするとLayerの変更の画面に遷移するので、Elastic Load Balancingの項目で先ほど作成したELBをコンボボックスで選択して設定します。

図3　作成したELBを選択する

運用の際に何が起こるのか

　さて、ここからが本題です。

　そもそも、運用をしていく上で、事前に何が起こるのかを全て把握するなんていうことは絶対にムリですし、それを試みることはムダです。もし、全てを把握できるのであれば、開発と運用の分離から生まれるビジネスリスクもそこまで大きくもなく、DevOpsなんていう言葉はきっと生まれてこなかったでしょう。

　とはいえ、何が起こるか分からないからといって

とりあえず、行き当たりばったりでやっちゃお♪

なんてことには、遊び以外では許されないわけで、想定できる限りのことは開発の段階で想定しておきましょう。そして、想定できることを事前にプログラミングしておくことこそがDevOpsの考え方なんだと筆者は思います。

　今回はOpsWorksを使うメリットを知るために、トラブルではなく、「通常の運用でこんなこと、あるよね。多分」というあたりの事柄をまとめたいと思います（次回では、「こんなトラブルのときはOpsWorksならこうするねっ」という情報をまとめていきますので、お楽しみに）。

　当然これ以外にも日常的に起こる運用の作業というのはあると思いますが、アプリケーションを運用していると、こんなような事が日常的に（？）に起こります。こんな運用をプログラムするのが楽になるのがOpsWorksです。今日はこれらの作業をOpsWorksでやってみます。

　現在は何もいじっていないEC-CUBEが入っていますが、これに対していくつかの作業をしていきます。