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

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

[あけり，＠IT]

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

　もし、自分の管理しているWebサイトが取材を受けて、明日テレビで放映されていることが分かっていたとします。せっかくテレビで自社サイトやサービスが放映されたのに、放映された途端に、負荷に耐えられず、サービスが落ちてしまうなんていう機会損失は避けたいところです。

　そんなときには、Instanceを追加して対応すれば対処は簡単です。OpsWorksではManagementConsoleから少し操作をするだけで、Instanceの追加もできます。

　もし放映時に、「張り付き」で操作ができるのであれば放送少し前になったら立ち上げればいいのですが、そんなに人員がいないかもしれません。こんな場合、OpsWorks環境では、2つの対応方法が考えられます。

　1つはLoad-Based Instanceを追加し、負荷に応じてAutoScalingの機能によって立ち上がるようにしておく方法。もう1つはTime-Based Instanceを追加して時間を指定して起動させる方法です。

Scalingの設定

Time-Based Instanceの追加

スケジュールの設定

　Load-Basedであれば負荷に応じて勝手に増えてくれるので非常に便利ですが、OpsWorksはサーバを立ちあげた上で、1からミドルウェアを構築するので、負荷が高まってから、サーバが立ち上がってきちんと動くようになるまでには若干時間がかかります。少しでも早くするために、InstanceをEBSベースのInstaneにし、一度start、stopしておくことで、packageのインストールが済んでいる状態からの起動になっているので、かなり早くなります。

　しかし、それでも放映時間が3分なのに、負荷に耐えられるような構成が完成するのに5分もかかってしまっていては、意味がありません。そんな時は、Time-Basedであれば、指定した時間に起動できるので、放映の少し前から準備しておくことも可能です。

　ただし、設定を消し忘れると定期的にサーバが立ちあがってしまうので、放映が終わった後にきちんと設定を元に戻す作業を忘れないようにしましょう。

　本来、Time-Basedは定期的に指定した時間に実行するようなものに対して使うものかも知れませんが、こういった事前に予想ができるイレギュラーな負荷に備えるという使い方にも効果的です。

今回のまとめ

　今回はOpsWorksでサイト運用をしていて、起こり得るであろう事象とその対処法の一部を紹介しました。ほとんどの作業が簡単かつ少ない手順でできることが分かったと思います。ただし、今回のような「通常の運用」であれば、OpsWorksではなくても、そこまで手間の掛かるものではないかも知れません。

　今回紹介はしませんでしたが、AWSの全てのサービスはAPIから利用できます。ManagementConsoleで人が操作することもできますが、プログラムからこれらの機能を利用できることが、OpsWorksの強みだと思います。

　SDKなどからAPIを利用する、本当に「プログラマブルなOpsWorks」もいずれ紹介して行きたいと思っていますが、ひとまず、次回はトラブルがあったときに、OpsWorksではどのようにトラブルシュートしていくのかなどを紹介していきます。