Help us understand the problem. What is going on with this article?

Auto Scaling

More than 1 year has passed since last update.

1.AWS Auto Scaling

アプリケーションの負荷を処理するのに適切な数のAmazon EC2インスタンスが生成、維持されます。

2.スケールアウト・スケールイン

  • スケールアウト:インスタンスを追加されること
  • スケールイン:インスタンスが削除されること

3.必要な設定## 

  • 起動設定:何を立ち上げるのか、起動する要素を決めます。

    • AMI
    • インスタンスタイプ
    • セキュリティグループ
    • ロール
  • Auto Scaling グループ:どこで行うか、デプロイの範囲を決めます。

    • デプロイ設定
    • VPCとサブネット
    • ロードバランサー
    • 最小・最大インスタンス数
    • キャパシティ
  • Auto Scaling ポリシー:いつトリガーとして実行するのか決めます。

    • ポリシー設定
    • スケジュール
    • オンデマンド
    • スケールアウト・インポリシー

4.料金

Auto Scaling 設定そのものは無料です。

5.ヘルスチェック

EC2ヘルスチェックにするか、ELBヘルスチェックにするか?
前者にすると、EC2インスタンスが正常に稼働しているかを調べるため、アプリケーションが正常に稼働しているかまではわからない。
なので、後者であれば、アプリケーションレベルの応答を持って正常と判断できる。

  • EC2ステータス:インスタンスのステータスがrunning以外の状態を異常と判断
  • ELB:ELBのヘルスチェック機能を活用する。

・猶予時間が短い場合、どのような問題が生じるのでしょうか.
ヘルスチェックの猶予期間はインスタンスの起動~アプリケーションデプロイ~サービス組み込み、までに要する時間よりも長くとっておく必要があります。
猶予期間が短い場合、インスタンスの構成が終わっていない状態でヘルスチェックが開始してしまい、結果ヘルスチェックに失敗→Terminateという動きになってしまいます。
場合によってはインスタンスが追加されないことで再度アラームが起き続け、インスタンス起動~削除の無限ループに陥ってしまう可能性もあるので注意してください。

6.AMIかuser-dataか

AMIはアプリケーションがき見込まれているため、起動が早い。ただし、アプリケーションを変更するたびに毎回AMIを作り直す必要がある。

ユーザーデータはアプリケーションは組み込まないため、変更時に手間がない。しかし、配備するたびにアプリケーションをインストールすす必要があるため、起動に時間がかかる。

変更の少ない部分はAMIで、変更の多いソースコードなどの部分や外部パラメータなどは、ユーザーデータで実装することは推奨されています。

7.注意

  • データベースサーバーやファイルサーバーなどデータをローカルに保存する用途には向いていない。
  • ステートフルな実装を求める。AMIから復旧するので、消えてしまうデータはRDS,S3などにおく構成にする。
  • EC2,アプリケーションの起動に数分かかる。突発的なアクセスには向いていないので動的スケーリングではなく、スケジュールスケーリングを利用する。

8.demo

Auto Scalling demo
Auto Scaling を試してみた

9.プラン

プラン
手動スケーリング 設定外で予期せぬスケーリングが必要となった場合に手動でスケーリングを実施
スケジュールベース 予測された需要増時期にあわせたスケーリングスケジュールを設定
動的スケーリング 予測不能なケースにスケーリングポリシーにスケール方針を設定して、動的にスケールアウトを実施

スケジュールを設定し、スケジュール設定を超過したら動的スケーリングにするといったように組み合わせることも可能です。

10.設計のポイント

  • インスタンスの最大値/最小値の設定は慎重に設定する
  • ステートフルなアプリケーションへの設定には、AutoScaling Groupでの自動設定が必要
  • ライフサイクルフック(起動時または削除時にインスタンスを一時停止してカスタムアクションを実行)を使用、つまりターミネーション時に直ぐに削除していいものかを検討する。
  • Auto-Scalingスラッシング(急なスケールインによる影響)を避ける

11.スケールインポリシー

需要減に基づくスケールインの際にどのインスタンスから終了するかを設定

1.OldestInstance 古いインスタンスから終了する インスタンスタイプを変更する時
2.NewestInstance 新しいインスタンスから終了する 新しい起動設定をテストしたい時
3.OldestLaunchConfiguration 古い起動設定を使用しているインスタンスから終了する Auto Scaling groupをアップデートして、以前のlaunch configurationを利用するインスタンスを置き換えたい時 
4.ClosestToNextInstanceHour 次の請求時間に最も近いインスタンスを終了する インスタンスの利用量を最大化しつつコストを抑えたい時 
5.デフォルト設定 3.4の順 その後、複数インスタンスが残った場合はランダムに終了する Auto Scaling groupに1個以上のスケーリングポリシーを関連づけている時 

12.クールダウン

スケーリング動作が完了してから別の動作が開始できるまでの秒数。
短期間にスケールアウトとスケールインを繰り返してしまう場合に利用する。

leomaro7
AWS 認定 ソリューションアーキテクト – アソシエイト AWS 認定 SysOps アドミニストレーター – アソシエイト AWS 認定 デベロッパー – アソシエイト AWS 認定 クラウドプラクティショナー Linuc1
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away