3-4:運用管理

やること

・業務外時間の全サーバ停止

業務外時間はサーバを停止しておけば、コスト的にもリスク的にも有効です。
リザーブドインスタンス契約は、AWSアカウント内の”インスタンスタイプ”・”OS種類”・”アベイラビリティゾーン”に対して適用されるものです。 
つまり、同じインスタンスタイプの2台のWindowsサーバを、毎日12時間稼働させる。
とすると、リザーブドインスタンス適用の1台を常時稼働しているのと同じ意味になります。←確認中
ただし、月次の延べサーバ利用時間でのディスカウントではなく、時間単位でリザーブドインスタンス適用か否かが決定されます。
つまり、リザーブドインスタンス契約1つに対して、対象となるインスタンスIDが決まってはいないので
午前のみ起動しているサーバ。午後のみ起動しているサーバ。としておけば、1つのリザーブドインスタンスで2台のサーバが値引きされます。
(そんな使い方をするのかどうかは別問題ですが。。)

・全サーバのバックアップ&世代管理

業務時間外に自動でAMI作成をしておけば、最悪前日業務終了時点まで戻すことができます。
AMIからの復旧手順を明確化しておけばダウンタイムは最少となります。
経験則からすると、AMIからのインスタンス再作成はほとんどありませんので、必要時は管理コンソールから実施すればよいです。
また、AMI作成しっぱなしだと、Snapshotが大量となりその分課金対象が増えます($0.095/月/GB)
ですので、世代管理とし、古いバックアップは消すようにします。

・障害時のアラート

AWSはサーバを起動するまでが責任範疇です。AWS管轄範囲内での障害を検知し、緊急連絡できる状況にします。
OS内での出来事は、ここでは触れません。
また自動実行するプログラムでの障害通知も把握できるようにします。

・AWSログ監視

サーバ起動等、各種アクションが実行された等のログを記録しておきます。


環境構築

1,実行命令を出すクライアント環境

AWS SDKで作成したアプリケーションは、アクセスキーによる認証さえできれば実行できます。
よって、これらのプログラムは必ずしもAWS内サーバから実行する必要はありません。
ここでは、VPC内作業用サーバ(192.168.101.5)に作成したアプリケーションを配置するものとし、
そのサーバは常時起動しているものとします。
作業用サーバでタスクスケジューラを下記の設定とします。
 8:00 対象サーバの一斉起動
20:00 対象サーバの一斉シャットダウン
21:00 対象サーバの一斉バックアップ(AMI作成)

2,プログラムの仕様

またタスクスケジューラで実行するので、アプリケーションは”コンソールアプリケーション”にします。
アクセスキーは、app.configに記述することにします。
インターネットに接続できず処理失敗した場合でも、トラブルシューティングできるように、エラーログはOSイベントログに書きます。

3,実行対象インスタンスの選定方法

上記サーバ起動・停止およびバックアップを作成する対象のEC2インスタンスを判別するためにタグを設定します。
サーバ起動・停止・バックアップを行う場合、実行対象はインスタンスIDで決まりますが、
AMIからサーバを再作成した場合にはインスタンスIDが変更されますし、実行対象サーバが増えた場合にも
EC2管理コンソールからタグ設定をするだけで、プログラムの実行対象とすることができるためです。

EC2管理コンソール→タグ→タグの管理ボタンを押す
対象とするインスタンスを選択して、タグを追加する。
ここでは・・・
キー:hogeTag    
値:3
※このタグ名が設定されていて、かつ設定されている値が数値で0以上のとき、サーバ起動・終了を行う
 また、バックアップ(AMI作成)は、設定されている数値(3)世代管理を行う。
と定義しました。


サブページ リスト


サブページ (1): 3-4-1:作成準備
Comments