翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
インスタンスを同期的に起動する
Amazon EC2 Auto Scaling には、Auto Scaling グループでインスタンスを起動するための 2 つの方法があります。非同期スケーリング動作とLaunchInstances API を使用した同期プロビジョニングです。
同期プロビジョニングでは、LaunchInstances API を使用して、特定のアベイラビリティーゾーン内の特定の数のインスタンスをリクエストします。同期プロビジョニングには、次の利点があります。
-
特定のアベイラビリティーゾーンでのキャパシティーの可用性に関する即時フィードバック
-
で起動するアベイラビリティーゾーンインスタンスの正確な制御
-
オーケストレーションシステムですぐに使用するための決定的なインスタンス IDs
-
実際の容量制約に基づくリアルタイムのスケーリングの決定
-
非同期 Auto Scaling 起動の待機時間を排除することでスケーリングを高速化
非同期 Auto Scaling では、希望する容量を変更するか、スケーリングポリシーがトリガーされると、Amazon EC2 Auto Scaling はスケーリングリクエストを処理し、バックグラウンドでインスタンスを起動します。インスタンスが正常に起動されるタイミングを判断するには、スケーリングアクティビティをモニタリングするか、Auto Scaling グループを記述する必要があります。
注記
-
LaunchInstances API は、起動テンプレートを使用する Auto Scaling グループでのみ機能します。起動設定を使用する Auto Scaling グループはサポートされていません。Auto Scaling グループが起動設定を使用している場合は、同期プロビジョニングを使用する前に起動テンプレートに移行する必要があります。
-
LaunchInstances API は、完全なオンデマンドまたは完全なスポット購入オプションを持つ混合インスタンスポリシーのみをサポートします。オンデマンドインスタンスとスポットインスタンスの両方を組み合わせた混合ポリシーはサポートされていません。
-
複数のアベイラビリティーゾーンをカバーする Auto Scaling グループの場合は、ターゲットのアベイラビリティーゾーンまたはサブネットを指定する必要があります。シングル AZ グループの場合、このパラメータはオプションです。
同期プロビジョニングと非同期スケーリング
同期プロビジョニング
LaunchInstances API を使用する場合、Amazon EC2 Auto Scaling は次のようになります。
-
CreateFleet を使用してリクエストされたインスタンスをすぐに起動しようとする
-
CreateFleet が応答する前にインスタンス IDs を返すのを待ちます
-
成功に関するインスタンス IDs、インスタンスタイプ、およびアベイラビリティーゾーン情報を返します
-
失敗時の特定のエラーコードと詳細を返します
-
即時のフィードバックを提供し、リアルタイムのスケーリングの決定を可能にします
非同期スケーリング
希望する容量の変更やスケーリングポリシーの使用などの非同期 Auto Scaling メソッドを使用する場合、Amazon EC2 Auto Scaling は次のようになります。
-
API で必要な容量を更新しますが、インスタンスはすぐには返されません
-
アベイラビリティーゾーン間でのインスタンスの起動を自動的に計画します
-
バックグラウンドワークフローを使用してインスタンスを起動します
-
バランスを取るために複数のアベイラビリティーゾーンに容量を自動的に分散します
-
組み込みの再試行ロジックで起動の失敗を処理します
起動オペレーションのステータスを確認するには、スケーリングアクティビティをポーリングするか、Auto Scaling グループを記述する必要があります。
制約事項と考慮事項
同期プロビジョニングを使用する場合は、次の注意事項と制限事項に注意してください。
-
起動後のインスタンス状態 – API によって返されるインスタンスは保留中状態です。後続のワークフロープロセスまたはライフサイクルフック中に失敗する可能性があります。API レスポンスが成功すると、EC2 は起動リクエストを受け入れ、インスタンス IDs。インスタンスはワークロードに対して完全に準備ができていると見なされず、標準の EC2 および Auto Scaling ライフサイクルプロセスを完了する必要があります。
-
ウォームプールの制限 — ウォームプールを持つ Auto Scaling グループは、現在サポートされていません。ウォームプールが設定された Auto Scaling グループで LaunchInstances API を呼び出そうとすると、API はウォームプールインスタンスを使用する代わりにコールドスタートを実行し、UnsupportedOperation エラーを返します。コールドスタートの詳細については、「ウォームプールの制限」を参照してください。
-
API タイムアウトと再試行 — 基盤となる CreateFleet オペレーションに予想以上に時間がかかる場合、API がタイムアウトしてべき等性トークンを返すことがあります。同じ ClientToken を使用して元の起動オペレーションを追跡するか、クライアントトークンで describe-instances を使用して起動されたインスタンスを確認できます。
-
アベイラビリティーゾーンの制約 – Auto Scaling グループが複数のアベイラビリティーゾーンにまたがり、アベイラビリティーゾーンの再調整が有効になっている場合、インスタンスを同期的に起動すると、運用上の競合が発生する可能性があります。
-
呼び出しあたりの単一の AZ 制限 – Auto Scaling グループが複数のゾーンにまたがっている場合でも、各 LaunchInstances API 呼び出しは 1 つのアベイラビリティーゾーンのみをターゲットにできます。
-
AZ の再調整の競合 - Auto Scaling グループで AZ の再調整が有効になっている場合、異なる AZs 間でのシーケンシャル呼び出しによって追加の非同期起動がトリガーされ、意図したよりも多くのインスタンスが発生する可能性があります。正確な容量制御のために AZ の再調整を停止することを検討してください。詳細については、「Amazon EC2 Auto Scaling プロセスの中断と再開」を参照してください。
-
-
部分的な成功シナリオ – リクエストされたキャパシティの一部しか利用できない場合、
LaunchInstancesAPI は部分的な成功を返すことがあります。これは通常の EC2 動作です。API は、正常に起動されたインスタンスと、起動に失敗したエラーの詳細を返します。すべてのインスタンスを一緒に起動する必要があるユースケース (低レイテンシーで同じ AZ 内のすべてのインスタンスを必要とするアプリケーションなど) では、部分的に起動されたインスタンスを終了し、別の AZ で再試行する必要があります。キャパシティーの影響を受けやすいワークロードの再試行ロジックを設計する場合は、この動作を考慮してください。 -
インスタンスの重み – Auto Scaling グループがインスタンスの重みを使用する場合、RequestedCapacity パラメータはインスタンス数ではなく、加重キャパシティーユニットを表します。起動されるインスタンスの実際の数は、選択したインスタンスタイプと設定された重みによって異なります。EC2 Auto Scaling では、リクエストされた加重キャパシティーに関係なく、API コールごとに 100 インスタンスに制限されます。
-
混合インスタンスタイプ – LaunchInstances API はAuto Scaling グループの既存の混合インスタンスポリシーを使用して、起動するインスタンスタイプを決定します。API は、グループの配分戦略とインスタンスタイプの優先順位に従ってインスタンスを起動します。