【AWS】 EC2 Auto Scalingの解説
Auto Scaling
アプリケーションの需要に応じてEC2インスタンスの数を自動的に調整する。これにより、コスト効率を高めつつ、高可用性を維持できる。
Auto Scalingグループを作成してインスタンスのコレクションを管理し、最小・最大インスタンス数を設定してリソースの確保と上限を決定し、必要容量を指定して特定のインスタンス数を維持し、スケーリングポリシーを設定して需要に応じて自動的にインスタンスを起動・終了する、これらのステップを通じてアプリケーションの可用性とパフォーマンスを確保する。
Amazon EC2 Auto Scalingの主な機能と設定
インスタンスの健全性監視と負荷分散
Amazon EC2 Auto Scalingは、EC2の組み込みヘルスチェックを使用してインスタンスの状態と可用性を監視し、終了したインスタンスや障害のあるインスタンスを自動的に置き換えることで必要な容量を維持する。
カスタムヘルスチェックも設定可能で、アプリケーションが期待通りに動作しているかを確認できる。カスタムヘルスチェックに合格しないインスタンスは自動的に置き換えられる。
また、Elastic Load Balancing(ELB)の負荷分散とヘルスチェックを使用して、正常なインスタンスにアプリケーショントラフィックを均等に分散させる。インスタンスの起動や終了時には、自動的にロードバランサーに登録・解除される。
可用性ゾーン間の容量バランス
Auto Scalingグループに複数のアベイラビリティゾーンを指定することで、インスタンスをゾーン間で均等に分散させ、高い可用性と回復力を確保する。これにより、単一のゾーンでの障害からアプリケーションを保護できる。
複数のインスタンスタイプと購入オプション
単一のAuto Scalingグループ内で複数のインスタンスタイプや購入オプション(スポットインスタンスやオンデマンドインスタンス、Savings Plan)を利用することで、コストを最適化できる。ス
また、Auto Scalingグループにスポットインスタンスが含まれている場合、スポットインスタンスが中断されると自動的に置き換えをリクエストできる。容量の再調整により、中断のリスクが高いスポットインスタンスをプロアクティブに交換することもできる 。
インスタンスの更新
インスタンス更新機能は、AMIや起動テンプレートの更新時にインスタンスをローリング方式で更新するメカニズムを提供する。新しいAMIやテンプレートを少数のインスタンスでテストし、問題がなければグループ全体に展開するカナリアデプロイメントも可能。
インスタンスの更新が開始されると、Amazon EC2 Auto Scalingは、最小および最大の正常パーセンテージに基づき、インスタンスをバッチで置き換える。最小健全割合が100%の場合、新しいインスタンスを起動してから古いインスタンスを終了し、必要な容量を維持する。インスタンスの健全性を確認し、ウォームアップ時間を確保した後、正常でないインスタンスを終了して置き換える。更新が成功すると、新しい構成変更でAuto Scalingグループ設定を自動的に更新する。
ライフサイクルフックとステートフルワークロード
ライフサイクルフックは、新しいインスタンスの起動時や終了前にカスタムアクションを実行するための設定を提供する。これにより、ステートフルアプリケーションの継続性を確保し、シャットダウン時に状態を永続化することができる。スケールイン保護やカスタム終了ポリシーを使用して、重要なインスタンスが早期に終了するのを防ぐこともできる 。
ライフサイクルフックのカスタムアクション例
初期設定スクリプトの実行
Webサーバーのインストールと設定、アプリケーションコードのデプロイを行う。また、アプリケーションの設定ファイルをリモートサーバーからダウンロードして適用する。
コンフィグ管理ツールの呼び出し
Ansibleを使用して全インスタンスに対して一貫した設定を適用する。また、Chefを使用してインスタンスの初期設定を自動化する。
セキュリティ設定の適用
ファイアウォールルールを設定して特定のポートのみを開放する。さらに、セキュリティパッチの適用と不必要なサービスの無効化を行う。
ログファイルの保存
インスタンスが終了する前にアプリケーションログを安全な外部ストレージにアップロードする。これにより、重要なデバッグ情報を保存して後でトラブルシューティングに役立てることができる。
データベース接続のクリーンアップ
インスタンスの終了時にデータベースセッションをクリーンに終了する。未処理のトランザクションをコミットまたはロールバックしてデータ整合性を保つ。
通知の送信
インスタンスの終了をトリガーにSNSを使用して管理者に通知を送信する。これにより、監視システムにインスタンス終了を報告して適切なアクションを取ることができる。
スケーリングポリシー
ターゲット追跡スケーリングポリシー
特定のメトリクスを目標値に保つようインスタンス数を調整するポリシー。例えば、CPU使用率を常に50%に保つように設定すると、負荷が増加して使用率が50%を超えるとインスタンスが追加され、逆に使用率が50%を下回るとインスタンスが削減される。このポリシーは、アプリケーションの負荷に対して柔軟かつ迅速に対応する。
ステップスケーリングポリシー
メトリクスの値が特定の閾値を超えた場合に、インスタンス数を段階的に調整するポリシー。このポリシーでは、複数の閾値を設定でき、それぞれの閾値に応じて異なる数のインスタンスを追加・削減することが可能だ。例えば、CPU使用率が70%を超えた場合にインスタンスを1つ追加し、80%を超えた場合にはさらに2つ追加する、といった細かい設定ができる。リソースの使用状況に応じてインスタンスを細かく制御したい場合に有用。
スケジュールスケーリングポリシー
特定の日時にインスタンス数を調整するポリシー。定期的なイベントや予測可能な負荷の変動に対応するために利用される。例えば、毎日午前8時にインスタンス数を5に設定し、午後6時にインスタンス数を2に減らすといった設定が可能だ。これにより、時間帯によって変動する負荷に対してあらかじめリソースを調整することができる。このポリシーは、予測可能な負荷パターンに対して効率的にリソースを管理するために非常に効果的。
起動テンプレート (Launch Template)
Amazon EC2インスタンスの起動時に必要な設定情報を事前に定義するためのテンプレート。これにより、インスタンスの設定を一元管理し、簡単かつ迅速に新しいインスタンスを作成することができる。
バージョン管理
異なる設定を持つ複数のバージョンを作成して保存し、必要に応じて異なるバージョンを切り替えることができる。これにより、インスタンスの設定を柔軟かつ効率的に管理することが可能。
例えば、起動テンプレート「MyTemplate」を作成し、以下のようにバージョン管理する:
v1: 初期バージョン。基本的な設定(AMI、インスタンスタイプ、セキュリティグループ)。
v2: ユーザーデータを追加。起動時に実行するスクリプトを設定。
v3: 新しいAMIとインスタンスタイプに変更。
v4: IAMロールを追加して、インスタンスに特定の権限を付与。
各バージョンに対して一意の番号が付与されるため、特定のバージョンを指定してインスタンスを起動することができる。また、デフォルトバージョンを設定しておけば、通常の操作では最新の安定バージョンが自動的に使用される。