「明日、このサイトがテレビで取り上げられます」 そのとき、OpsWorksならどうする？：AWS OpsWorksアプリケーション運用の勘所（2）（2/3 ページ）

明日は当初想定を超えたアクセスが予想される……。システム運用者なら冷や汗が出そうな事態を察知したとき、AWS OpsWorksでシステムを運用していたなら、どう対処する？

[あけり，＠IT]

アプリケーションの改修（バージョンアップ）

　アプリケーションをリリースしたら放ったらかし、なんてことは、滅多にないと思います。何かしらの機能拡張もすれば、バグの修正もあります。そんなとき、OpsWorksではどのようにしたらいいのでしょうか。答えは簡単です。

　まず修正したソースコードを、github（＝ソースコードリポジトリ）にpushしてManagementConsoleのDeploymentsのところから「Deploy an app」ボタンを押せば下のような画面になります。

Deploy

　この画面で「Command: deploy」を選択し、「Instances」でデプロイしたいインスタンスを選んで「Deploy」ボタンを押せば完了です。これで少し待てば新しいソースコードでアプリが動き始めます。簡単ですね。

デプロイからの戻し方

　アプリケーションを改修してデプロイしてみたはいいけれども、バグがあってやっぱり元に戻したい！ なんてこともあるかもしれません。そんなときは、GitHubのソースコードを元に戻して、もう一度、上の手順を行うことで簡単に元に戻せます。

　OpsWorks自体でバージョンを管理し、元に戻すことができないのが、Elastic Beanstalkと違うところです。OpsWorks（≒Chef）の「お仕事」は、あくまでも現在の状態を外部から構成することですから、変更の管理は外部のツールに頼らざるを得ません。。OpsWorksではアプリケーションの単位で、どのブランチもしくはリビジョンを使用するかを指定できます。リポジトリのブランチなどをうまく使って切り替えていきましょう。Tagが使えるともっといいのにな、と思ったりもします。

テスト環境の構築

　さて、もう改修してデプロイしてみたはいいけれども、バグがあって差し戻すなんてことはないようにしていきたいですよね。ということで、全く同じ構成のテスト環境を構築し、テストをしっかりやっていけるように環境を整備しておきましょう。テスト環境があったからといって、前述のようなことが絶対に起こらないわけではありません。それでも、その可能性を少しでも減らすことがビジネスリスクを減らすことにつながります。

　OpsWorksではStackをcloneすれば簡単に同じ構成を作ることができます。Stackのコピーは「Dashboard」から行います。

　データーベースのエンドポイントは、前回の解説で、OpsWorksが教えてくれるものを使うように書き換えてあるので、簡単に接続できます。

　ただ、これではテスト環境としては不十分です。テスト環境として動作させるためには、データを移さなくてはいけません。OpsWorksはそこまでは面倒をみてくれないので、おとなしくdumpをとってテスト環境に入れておきましょう。データベースをバックアップから復元するのはChefで可能だとは思います。テスト環境ができれば、好きなだけテストし放題です。心ゆくまでテストしましょう。