前提
サーバの稼働に関して、そんなにシビアでは無いが知らない間にサーバが落ちていたりしない、ある程度自動で稼働する状態に回復する。小規模な構成なのでサーバは基本は出来るだけ一台で稼働している。
そんなゆるふわなサイトで最低限の運用を手間なしで実現するためELBとAutoScalingを使った構成です。
ちなみにテレビ紹介などの急激なトラフィック増に対しても事前にAutoScalingの設定を変え、ELBの申請をしておけば大丈夫とおもいます。
ELB、AutoScalingを使った構成への移行する
0.スタート時の構成 Route53、EC2一台、RDS一台
1.ELBをRoute53とEC2の間にはさむ
- ロードバランサを作成する
- セキュリティグループを作成する。IN HTTP OUT ALL
- ヘルスチェックを追加。今回はHTTPにて_common_img/logo.pngとしました。
- インスタンスを追加。これはあとで入れ替えますが一応。
- 他はデフォルトでとりあえず作成
2.ELB作成後の設定項目
- 作成されたELBを選択後、説明
- アクセスログを有効にしS3にアクセスログを残すようにします。バケットを作っていない場合はロケーションを作成にチェック。
- 説明>ポート構成>維持設定の編集をクリック。「ロードバランサーによって生成された Cookie による維持を有効化」を選択し保存する。これは複数インスタンスが立ち上がった時のセッションをインスタンスに固定するための設定です。
3.Route53の設定
- 現在AレコードにてEC2に紐づけられているものを、Aレコードのエイリアスレコードを利用してELBのDNSに変更します。これでsugoroku.osakaがELBにつばがるようになります。
- またEC2のセキュリティグループをIN HTTPは今ALLになっているので、ELB限定に変更します。
4.AutoScalingを作成
- 現在稼働しているEC2のイメージを作成する
- AutoScaling起動設定を作成
- ここの設定で先ほどのAMIを指定する
- セキュリティグループは既存のEC2のSGを利用
- AutoScalingグループを設定
- VPCとSubnetは現在のEC2と同じになる用に注意
- 高度な詳細でELBからのトラフィックを受け取るにチェック
- ヘルスチェックのタイプをELBに変更
- 通知を設定する（トピックを作っていない場合作成する必要があります）
- タグの設定は任意でOK、ひとまず完了
5.AutoScalingの詳細設定をおこないます。
- まずAutoScalingグループの詳細>編集ボタンからインスタンス数の設定を「希望」1「最小」1「最大」2に設定
- スケーリングポリシーを追加します。今回はインスタンスのCPUUtilizationのしきい値を70％を超えた場合インスタンスを1台追加する設定にしています。
補足
これにより基本的にはEC2は一台で稼働するように調整され、CPUの使用率が70％を超えた場合追加でもう一台インスタンスがELB配下に追加されます。CPUが70％を下回るとまた一台に戻るようAutoScalingが働きます。
またELBのヘルスチェックが失敗した場合も新しいインスタンスが立ち上げられ、ヘルスチェックに失敗したインスタンスはターミネートされます。インスタンスはターミネートされますがEBSは残っているのでデータの同期、ログの検証などはこのEBSを利用して可能です。
また各タイミングで設定したトピックによりメールアドレスへ通知メールが送信されます。
注意点
AutoScalingで作成されるインスタンスは最初のグループ作成時に指定したマシンイメージから作成されるため、ストレージ内のデータの同期、更新に対する処理が必要です。基本的には別途S3などに保管されているデータから取得する等をEC2の起動設定に入れておく必要があります。
6.EC2インスタンスの設定
- ここまででAutoScalingグループ内のインスタンスがELB配下に追加される形になっていると思うので、以前のインスタンスを削除します。
- あたらしく作成されたインスタンスはEIPが設定されていないので、設定します。AutoScalingで変動があった場合はまた設定しないといけませんが仕方ありません。
最後に
EC2インスタンス単体でもデフォルトで備えられているステータスチェックに関して、アラートが発生した場合に自動でインスタンスの復元を行う設定が出来るようになりました。
設定の方法はマネジメントコンソールのモニタリングからCloudWatchアラーム「アラームの作成」で設定が出来ます。
あくまでステータスチェックのみですが基本的にインスタンスには設定しておいたほうが安心です。