AWSでWebサービスを構築10 AWSクラスタの運用例

これまでの知識で、Apacheなどが動作するアプリケーションサーバとデータベースを構成することはできる。
冗長化や負荷分散も基本的な構成は説明した。
ドメインやサブドメインの設定も、前回の説明で可能になった。
すでにサービスの開始は可能になった。

ここで、EC2インスタンスの修正とクラスタ更新に関して、実際に運用する際の一例を説明したい。
ただ、特にAWS側で推奨している方法というわけではないため、自分に合うかを判断しながら参考にしてほしい。

EC2インスタンスの運用方法

EC2インスタンスは編集→AMI作成という手順を繰り返しながら更新していくことは説明した。
ただ、この編集するインスタンスは１つでいいし、外に公開されている必要はない。（というより非公開の方が断然いい）

更新用のインスタンスを１つ作成しておいて、編集するとき以外は停止しておけば、無駄なく効率的かつ安全に運用できるだろう。
例えばアプリケーションサーバを作ることを考えると、下記のような構成がいいだろう。




まずは編集用のインスタンスを用意する(上図ではAPBase)。
APBaseには専用のセキュリティグループを用意する。このセキュリティグループの設定はほぼAPサーバと同様だが、インバウンドの各プロトコルの送信元設定を制限する。
具体的には、編集作業する場所（仕事場や自宅など）の固定IPなどを設定する。要は、外部に公開せず内部の人間だけで編集や確認を行う。
（固定IPを持たない人は、SSHの設定と同じく「マイIP」で都度設定する）

APサーバを編集する際にはAPBaseを起動し編集する。編集が済んだらAMIを作成し、またAPBaseを停止する。
必要なときにだけ起動することで、費用を軽減する。

AMIを作成したら、それからインスタンスを複製する（上図ではAP001-004）。
これらのインスタンスはAPセキュリティグループに複製する。
このとき、すでに起動している古いインスタンスは残しておいて、ロードバランサのサーバ指定だけを切り替えることで、サービスをほぼ止めることなく更新することが可能になる。
切り替えと確認が済んだら、古いインスタンスは破棄するといい。


自分はこれ以外にテスト環境やステージング環境を用意しているが、基本は同じような構成になっている。
また、これはアプリケーションサーバに限らず、EC2インスタンスで構成されるサービスには広く適用できる運用かと思う。

その他の運用方法

例えばphpMyAadminなどDBマネージメントシステムを使いたい場合は、自前で用意する必要がある。
こういう管理用サーバが必要な場合もEC2インスタンスを用意する。
セキュリティグループも独自に作った方がいいだろう。
（仮にManagerインスタンスとManagerセキュリティグループと呼ぶ）

Managerセキュリティグループのインバウンドの送信元は、自分のオフィスなどに制限して、非公開にする。

あまり説明することはないが、こういうサーバが一つあると結構便利なので、効率的な運用のためには必要になってくるだろう。


今回は短いしあくまで運用の一例だが、恒常的に運用できる方法なので参考にしてほしい。