翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # ウォームプールを使用してブート時間が長いアプリケーションのレイテンシーを低減する ウォームプールを使用すると、インスタンスが大量のデータをディスクに書き込む必要があるなど、起動時間が非常に長いアプリケーションのレイテンシーを低減できます。ウォームプールの使用によって、アプリケーションのパフォーマンスを向上させるために、レイテンシーを管理するために Auto Scaling グループを過剰にプロビジョニングする必要がなくなりました。詳細については、ブログ記事 [Scaling your applications faster with EC2 Auto Scaling Warm Pools](https://aws.amazon.com/blogs/compute/scaling-your-applications-faster-with-ec2-auto-scaling-warm-pools/) (EC2 Auto Scaling ウォームプールを使用してアプリケーションをより高速にスケーリングする) をご覧ください。 **重要** 必要のないときにウォームプールを作成すると、不要なコストが発生する可能性があります。最初の起動時にアプリケーションに顕著なレイテンシーの問題が発生しない場合は、おそらくウォームプールを使用する必要はありません。 **Topics** + [主要概念](#warm-pool-core-concepts) + [前提条件](#warm-pool-prerequisites) + [ウォームプール内のインスタンスを更新する](#update-warm-pool) + [関連リソース](#warm-pools-related-resources) + [制限事項](#warm-pools-limitations) + [ライフサイクルフックを使用する](warm-pool-instance-lifecycle.md) + [Auto Scaling グループのためにウォームプールを作成する](create-warm-pool.md) + [ヘルスチェックステータスを表示する](warm-pools-health-checks-monitor-view-status.md) + [AWS CLI ウォームプールの使用例](examples-warm-pools-aws-cli.md) ## 主要概念 開始する前に、以下の主要概念を理解してください。 **ウォームプール** ウォームプールは、Auto Scaling グループに接続された初期化済みの EC2 インスタンスのプールです。アプリケーションがスケールアウトする必要があるときはいつでも、Auto Scaling グループはウォームプールに描画して、新しい希望する容量を満たすことができます。これにより、インスタンスがアプリケーショントラフィックを迅速化し、スケールアウトイベントへの応答を高速化できるようになります。インスタンスは、ウォームプールから離れたときに、グループの希望する容量にカウントされます。これは、*ウォームスタート*として知られています。 インスタンスがウォームプールにある間、スケーリングポリシーは、`InService` 状態のインスタンスのメトリクス値がスケーリングポリシーのアラーム上限しきい値 (ターゲット追跡スケーリングポリシーのターゲット使用率と同じ値) を超える場合のみスケールアウトします。 **ウォームプールのサイズ** デフォルトでは、ウォームプールのサイズは、Auto Scaling グループの最大容量と希望する容量の数値の差として計算されます。例えば、Auto Scaling グループの希望する容量が 6 で、最大容量が 10 の場合、ウォームプールを最初にセットアップし、プールが初期化されるときに、ウォームプールのサイズは 4 になります。 ウォームプールの最大容量を個別に指定するには、カスタム仕様 (`MaxGroupPreparedCapacity`) オプションを使用して、グループの現在の容量を超えるカスタム値を設定します。カスタム値を指定すると、ウォームプールのサイズは、グループのカスタム値と現在希望する容量の数値の差として計算されます。たとえば、Auto Scaling グループの希望容量が 6、最大容量が 20、カスタム値が 8 である場合、初めてウォームプールをセットアップしてプールが初期化されると、ウォームプールのサイズは 2 になります。 ウォームプールを使用するコストメリットを管理するために、大きな Auto Scaling グループで作業するときは、カスタム仕様 (`MaxGroupPreparedCapacity`) オプションのみを使用する場合があります。例えば、インスタンス 1,000 個、最大容量 1,500 個 (トラフィックの急増時に追加の容量を提供するため)、およびインスタンス 100 個のウォームプールがある Auto Scaling グループは、ウォームプール内に将来使用するインスタンスを 500 個予約しておくよりも、目標の達成に役立つ場合があります。 **ウォームプールサイズの最小サイズ** 最小サイズ設定を使用して、ウォームプール内で維持するインスタンスの最小数 (`MinSize`) を静的に設定することを検討してください。デフォルトでは最小サイズは設定されていません。`MinSize` の設定は、Auto Scaling グループの希望する容量が `MaxGroupPreparedCapacity` よりも高い場合でも、ウォームプールに最小数のインスタンスが維持されるように `MaxGroupPreparedCapacity` を指定する場合に便利です。 **ウォームプールインスタンスの状態** ウォームプール内のインスタンスは、次の 3 つの状態のいずれかで保持できます: `Stopped`、`Running`、`Hibernated`。インスタンスを`Stopped`状態で保持することは、コストを最小限に抑えるための効果的な方法です。停止したインスタンスでは、使用したボリュームとインスタンスにアタッチされた Elastic IP アドレスの分だけ料金が発生します。 または、インスタンスを `Hibernated` 状態に保持して、メモリコンテンツ (RAM) を削除せずにインスタンスを停止することができます。インスタンスが休止状態になると、RAM コンテンツを Amazon EBS ルートボリュームに保存するようオペレーティングシステムに通知されます。インスタンスを再起動すると、ルートボリュームは以前の状態に復元され、RAM コンテンツがリロードされます。インスタンスが休止状態になっている間は、RAM コンテンツのストレージ、インスタンスにアタッチされた Elastic IP アドレスなどの EBS ボリュームに対してのみ料金が発生します。 ウォームプール内のインスタンスを `Running` 状態にしておくことも可能ですが、不必要な料金の発生避けるためにも、そうしておかないことを強くお勧めします。インスタンスを停止または休止状態にしておくと、インスタンス自体のコストが削減されます。インスタンスの料金は、インスタンスが実行されている場合にのみ発生します。 **ライフサイクルフック** [ライフサイクルフック](warm-pool-instance-lifecycle.md)を使用して、インスタンスに対してカスタムアクションを実行できるように、インスタンスを待機状態にします。カスタムアクションは、インスタンスの起動時または終了前に実行されます。 ウォームプール設定では、ライフサイクルフックは、初期化が完了するまで、スケールアウトイベント中にインスタンスが停止または休止されたり、稼働したりするのを遅延させます。ライフサイクルフックなしで Auto Scaling グループにウォームプールを追加すると、初期化の完了までに長い時間がかかるインスタンスは停止または休止状態になり、準備が整う前にスケールアウトイベントが開始する可能性があります。 **インスタンスの再利用ポリシー** デフォルトでは、Amazon EC2 Auto Scaling は、Auto Scaling グループがスケールインするとインスタンスを終了します。次に、新しいインスタンスをウォームプールで起動し、終了したインスタンスを置換します。 置換する代わりに、インスタンスをウォームプールに戻す場合は、インスタンスの再利用ポリシーを指定します。これにより、アプリケーショントラフィックを処理するように設定されたインスタンスを再利用できます。ウォームプールが過剰プロビジョニングされないように、Amazon EC2 Auto Scaling はウォームプール内のインスタンスを終了し、その設定に基づいて、必要以上に大きくなったときにそのサイズを減らすことができます。ウォームプール内のインスタンスを終了する際に、Amazon EC2 Auto Scaling は[デフォルトの終了ポリシー](ec2-auto-scaling-termination-policies.md#default-termination-policy)を使用して、最初に終了するインスタンスを選択します。 スケールイン時にインスタンスを休止し、Auto Scaling グループに既存のインスタンスがある場合は、インスタンスの休止要件を満たしている必要があります。要件を満たしていない場合、インスタンスがウォームプールに戻ると、休止状態ではなく停止状態にフォールバックします。 現在、インスタンスの再利用ポリシーを指定できるのは、 AWS CLI または SDK のみです。この機能はコンソールからは利用できません。 ## 前提条件 Auto Scaling グループのためにウォームプールを作成する前に、ライフサイクルフックを使用して新しいインスタンスを適切な初期状態で初期化する方法を決定します。 インスタンスがライフサイクルフックを理由として待機状態にあるときに、インスタンスに対してカスタムアクションを実行するには、次の 2 つのオプションがあります。 + 起動時にインスタンスでコマンドを実行する単純なシナリオでは、Auto Scaling グループの起動テンプレートまたは起動設定の作成時にユーザーデータスクリプトを含めることができます。ユーザーデータスクリプトは、インスタンスの起動時に cloud-init により実行される通常のシェルスクリプトまたは cloud-init ディレクティブです。このスクリプトは、実行されるインスタンスの ID を使用して、インスタンスが次の状態に移行するタイミングを制御することもできます。まだそうしていない場合は、インスタンスメタデータからインスタンスのインスタンス ID を取得するためのスクリプトを更新します。詳細については、「*Amazon EC2 ユーザーガイド*」の「[インスタンスメタデータにアクセスする](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html)」を参照してください。 **ヒント** インスタンスの再起動時にユーザーデータスクリプトを実行するには、ユーザーデータを MIME マルチパート形式で指定し、ユーザーデータの `#cloud-config` セクションで以下を指定します。 ``` #cloud-config cloud_final_modules: - [scripts-user, always] ``` + インスタンスがウォームプールに出入りするときに AWS Lambda 何かを行うなどの高度なシナリオでは、Auto Scaling グループのライフサイクルフックを作成し、ライフサイクル通知に基づいてカスタムアクションを実行するようにターゲットサービスを設定できます。詳細については、「[サポートされている通知ターゲット](warm-pool-instance-lifecycle.md#warm-pools-supported-notification-targets)」を参照してください。 **インスタンス休止のための準備** `Hibernated` のプール状態を使用して Auto Scaling インスタンスを準備するには、「*Amazon EC2 ユーザーガイド*」の「[休止の前提条件](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/hibernating-prerequisites.html)」トピックの説明に従って、インスタンスの休止状態をサポートするように正しくセットアップされた新しい起動テンプレートまたは起動設定を作成します。次に、新しい起動テンプレートまたは起動設定を Auto Scaling グループに関連付けてインスタンスの更新を開始し、以前の起動テンプレートまたは起動設定に関連付けられているインスタンスを置換します。詳細については、「[インスタンスの更新を使用して Auto Scaling グループのインスタンスを更新する](asg-instance-refresh.md)」を参照してください。 ## ウォームプール内のインスタンスを更新する ウォームプール内のインスタンスを更新するには、新しい起動テンプレートまたは起動設定を作成し、それを Auto Scaling グループに関連付けます。新しいインスタンスは、起動テンプレートまたは起動設定で指定された新しい AMI およびその他の更新を使用して起動されますが、既存のインスタンスは影響を受けません。 新しい起動テンプレートまたは起動設定を使用する代替ウォームプールインスタンスを強制的に起動するには、インスタンスの更新を開始してグループのローリング更新を行うことができます。インスタンスの更新は、最初に`InService`インスタンスを置き換えます。その後、ウォームプール内のインスタンスが置き換えられます。詳細については、「[インスタンスの更新を使用して Auto Scaling グループのインスタンスを更新する](asg-instance-refresh.md)」を参照してください。 ## 関連リソース ウォームプールのライフサイクルフックの例については、[GitHub リポジトリ](https://github.com/aws-samples/amazon-ec2-auto-scaling-group-examples)にアクセスしてください。 ## 制限事項 + 混合インスタンスタイプの Auto Scaling グループにおけるウォームプールの制限: + ウォームプールは、重み付きの混合インスタンスグループがサポートされていません。Auto Scaling グループがインスタンスの重み付けを使用している場合、ウォームプールを追加できません。 + ウォームプールは、混合インスタンスグループ内のスポットインスタンスをサポートしていません。混合インスタンスポリシーは、ウォームプールを使用する場合にオンデマンドインスタンスのみで設定する必要があります。 + 休止状態の混合インスタンスグループでウォームプールを使用する場合は、起動テンプレートで `HibernationOptions` を設定する必要があります。 + Amazon EC2 Auto Scaling は、ルートデバイスとして Amazon EBS ボリュームを持つ場合にのみ、インスタンスを `Stopped` または `Hibernated` 状態にすることができます。ルートデバイスにインスタンスストアを使用するインスタンスは停止または休止できません。 + Amazon EC2 Auto Scaling は、「*Amazon EC2 ユーザーガイド*」の「[休止の前提条件](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/hibernating-prerequisites.html)」トピックに一覧表示されているすべての要件を満たしている場合にのみ、インスタンスを `Hibernated` 状態にすることができます。 + スケールアウトイベントがあるときにウォームプールが枯渇した場合、インスタンスは Auto Scaling グループ内に直接起動されます (*コールドスタート*)。また、アベイラビリティーゾーンが容量不足の場合にコールドスタートが発生する可能性があります。 + ウォームプール内のインスタンスが起動プロセス中に問題に遭遇し、`InService` 状態に到達できない場合、インスタンスは起動に失敗したと見なされ、終了します。これは、容量不足エラーやその他の要因など、根本的な原因に関係なく適用されます。 + Amazon Elastic Kubernetes Service (Amazon EKS) マネージドノードグループでウォームプールを使用しようとすると、まだ初期化中のインスタンスが Amazon EKS クラスターに登録される可能性があります。その結果、このクラスターは、インスタンスが停止または休止の準備を行っているときにインスタンスでジョブをスケジュールする場合があります。 + 同様に、Amazon ECS クラスターでウォームプールを使用しようとすると、初期化が完了する前にインスタンスがクラスターに登録される可能性があります。この問題を解決するには、ユーザーデータに特別なエージェント設定変数が含まれる起動テンプレートまたは起動設定を設定する必要があります。詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[EC2 起動タイプ用の Amazon ECS キャパシティープロバイダー](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/asg-capacity-providers.html#using-warm-pool)」を参照してください。