このトピックでは、Auto Scaling 利用時の問題のトラブルシューティングと解決に役立つ、よくある質問 (FAQ) に回答します。
|
カテゴリ |
FAQ |
|
課金 |
|
|
スケーリンググループ |
|
|
スケーリング設定 |
|
|
スケジュールタスク |
|
|
イベントトリガータスク |
|
|
スケーリングアクティビティ |
|
|
スケーリンググループ内のインスタンス管理 |
|
|
SLB インスタンスとの関連付け |
|
|
ApsaraDB RDS インスタンスとの関連付け |
Auto Scaling の料金
Auto Scaling 自体は無料です。サービスの有効化やスケーリンググループの作成では課金されません。ただし、Elastic Compute Service (ECS) インスタンス、Elastic Container Instance (ECI) インスタンス、Server Load Balancer (SLB) インスタンス、ApsaraDB Relational Database Service (RDS) インスタンスなどのリソースには課金されます。詳細については、「関連付けられたリソースの課金」をご参照ください。
アカウントに支払い遅延が発生した直後に、ECS または ECI インスタンスがリリースされるのはなぜですか?
Auto Scaling はヘルスチェック機能を提供します。ECS インスタンスまたは ECI インスタンスが 実行中 状態でない場合、Auto Scaling はそのインスタンスを異常と見なします。異常なインスタンスは、スケーリンググループから自動的に削除され、解放される場合があります。詳細については、「スケーリンググループにおけるインスタンスのライフサイクル」をご参照ください。
アカウントに支払い遅延が発生した場合、スケーリンググループ内のすべての後払いインスタンス (従量課金インスタンスやスポットインスタンスを含む) は停止されます。 Auto Scaling はこれらの停止済みのインスタンスを異常と識別し、削除してリリースします。
アカウントに十分な残高があることを確認してください。 支払い遅延によるインスタンスのステータスの変化については、「有効期限切れと支払い遅延」をご参照ください。
スケーリンググループを無効にした後も、ECS インスタンスまたは ECI インスタンスは課金されますか?
はい。スケーリンググループ自体は無料ですが、その中の ECS インスタンスまたは ECI インスタンスには課金されます。スケーリンググループを無効にした後もインスタンスが残っている場合、それらのインスタンスには引き続き課金されます。
Auto Scaling はデータディスクの自動スケーリングをサポートしていますか?
いいえ。
Auto Scaling は、スケーリンググループ内の ECS または ECI インスタンスの数を自動的に増減できます。しかし、個々のインスタンスの構成 (データディスクの数やサイズなど) を変更することはできません。
Auto Scaling を使用する際、SLB、CloudMonitor、ApsaraDB RDS と併用する必要がありますか?
いいえ。
Auto Scaling は柔軟なサービスであり、単独で使用できます。ただし、SLB、CloudMonitor、ApsaraDB RDS などの他のサービスと統合することで、機能を強化できます。例:
-
SLB と連携してトラフィックを分散します。詳細については、「クラシックロードバランサー (CLB) の概要」をご参照ください。
-
ApsaraDB RDS と連携してマネージドデータベースを利用します。詳細については、「ApsaraDB RDS の概要」をご参照ください。
-
CloudMonitor を使用してスケールアウトおよびスケールインアクティビティをトリガーします。詳細については、「イベントトリガータスクの概要」をご参照ください。
スケーリンググループに追加できるインスタンス数
インスタンス数およびその他の Auto Scaling リソースの制限については、「制限」をご参照ください。
既存インスタンスのスケーリンググループへの追加
はい。
追加する ECS または ECI インスタンスは、以下の条件を満たす必要があります。
-
インスタンスは、スケーリンググループと同じリージョンにある必要があります。詳細については、「リージョンとゾーン」をご参照ください。
-
インスタンスは [実行中] 状態である必要があります。詳細については、「インスタンスライフサイクル」 または 「ECI インスタンスライフサイクル」をご参照ください。
-
インスタンスは、他のスケーリンググループに属していてはなりません。
既存のサブスクリプション ECS インスタンスをスケーリンググループに追加できますか?
はい。
Auto Scaling は、従量課金インスタンスまたはスポットインスタンスを自動的に作成できます。また、既存のサブスクリプションインスタンスおよび従量課金インスタンスをスケーリンググループに追加することもできます。
ECS または ECI インスタンスを複数のスケーリンググループに追加できますか?
いいえ。
インスタンスは、一度に 1 つのスケーリンググループにのみ所属できます。インスタンスをあるスケーリンググループから別のスケーリンググループに移動するには、まず元のグループからインスタンスを削除してから、新しいグループに追加する必要があります。詳細については、「インスタンスを手動で削除する」と「スケーリンググループにインスタンスを手動で追加する」をご参照ください。
スケールイン時に削除するインスタンスのコントロール
スケーリンググループに削除ポリシーを設定できます。このポリシーは、2 段階のフィルタリングシステムを使用して、最も古いスケーリング設定から作成されたインスタンス、最も古いインスタンス、または最も新しいインスタンスなどを削除対象として選択します。詳細については、「スケーリンググループの作成」をご参照ください。
スケーリンググループを無効化すると、自動的に追加されたインスタンスはリリースされますか?
いいえ。
コンソールまたは API 呼び出しでスケーリンググループを無効化しても、その中の ECS または ECI インスタンスは自動的にリリースされません。スケーリンググループを無効化する方法については、「スケーリンググループの無効化」をご参照ください。
ECI インスタンスのスケーリンググループにおけるスケールアウトレイテンシーに影響する要因
ECI インスタンスのスケーリンググループのスケールアウトレイテンシーに影響を与える主な要因は、コンテナの初期化時間、アプリケーションの起動時間、ライフサイクルフックの設定時間、およびスケールアウトされたコンテナが外部リソースに登録されるまでにかかる時間です。
ECI インスタンスのスケーリンググループの場合、スケールアウト時間とは、スケールアウトされる ECI のライフサイクル全体の期間のことです。ECI ライフサイクルフックの詳細については、「ライフサイクルフック」をご参照ください。
スケーリンググループに複数の ECS インスタンスタイプを含めることはできますか?
はい、できます。
単一のスケーリング設定で複数の ECS インスタンスタイプを選択できます。これにより、スケールアウトの成功率が向上します。ただし、追加できるインスタンスタイプの数には制限があります。詳細については、「制限」をご参照ください。
スケーリンググループで 8 コアまたは 16 コアの ECS インスタンスを設定できますか?
はい。
利用可能なインスタンスタイプが要件を満たさない場合は、チケットを送信し、追加の ECS インスタンスタイプをリクエストしてください。
Auto Scaling によって自動作成される ECS インスタンスのデータディスク容量を指定する方法
スケーリング設定の作成時に、ストレージ設定でデータディスク容量を指定できます。詳細については、「ECS インスタンスのスケーリング設定の作成」をご参照ください。
Alibaba Cloud Marketplace イメージによる ECS インスタンスの起動
同じイメージの N 個のインスタンスを起動する必要がある場合、まず Alibaba Cloud Marketplace からそのイメージの N 個のライセンスを購入する必要があります。
Alibaba Cloud Marketplace でのイメージの一括購入
現在、一括購入はサポートされていません。
使用していた Alibaba Cloud Marketplace のイメージが利用できなくなった場合に ECS インスタンスを正常に起動する方法
Alibaba Cloud Marketplace から別の利用可能なイメージを選択してください。
スケールアウトアクティビティが "Alibaba Cloud Marketplace image unavailable" エラーで失敗する原因
症状:スケーリンググループが ECS インスタンスの作成を試行すると、次のエラーが表示されます:
Fail to create Instance into scaling group("The specified image is from the image market. You have not bought it or your quota has been exceeded.").
原因:このエラーは、スケーリング設定で Alibaba Cloud Marketplace の未購入のサードパーティイメージが使用されているか、そのイメージの購入クォータを超過している場合に発生します。
ソリューション:事前に購入していない場合、Auto Scaling は Alibaba Cloud Marketplace のサードパーティイメージから ECS インスタンスを自動的に作成できません。Alibaba Cloud Marketplace に移動して、必要なサードパーティイメージを購入してください。イメージを購入した後、そのイメージから Auto Scaling を使用して ECS インスタンスを作成できます。
1 つの製品コードを、異なるリージョンのイメージに使用できますか?
はい。イメージがそのリージョンで利用可能であることが条件です。
同じ製品コードのイメージ ライセンスを 100 個購入した場合、任意のリージョンで使用できますか?
Alibaba Cloud Marketplace のイメージはリージョン固有です。イメージは使用するリージョンごとに購入する必要があります。
繰り返しスケジュールタスクを設定できますか?
はい。詳細については、「スケジュールタスクの作成」をご参照ください。
イベントトリガータスクとスケジュールされたタスクの実行優先度
イベントトリガータスクとスケジュールされたタスクは独立しており、同時にトリガーされません。両者の間に実行優先度はありません。
イベントトリガータスクが失敗してもトリガー条件が引き続き満たされている場合、現在のスケーリングアクティビティが完了した後にタスクは再度実行されます。
スケジュールされたタスクに再試行間隔を設定すると、実行が失敗した後に再トリガーされます。詳細については、「スケジュールタスクの作成」をご参照ください。
Auto Scaling におけるイベントトリガータスクのトリガー条件
イベントトリガータスクは、CPU 使用率、メモリ使用率、システムの平均負荷、内部ネットワークトラフィックなどの監視メトリクスに基づいて、ECS または ECI インスタンスを自動的に追加または削除できます。詳細については、「システムモニタリングに基づくイベントトリガータスク」をご参照ください。
イベントトリガータスクのトリガー条件の設定
イベントトリガータスクを使用する前に、最新バージョンの CloudMonitor エージェントが ECS インスタンスにインストールされていることを確認してください。インストールされていない場合は、「CloudMonitor エージェント for Java のインストール」をご参照ください。
イベントトリガータスクを作成する際は、ビジネス要件に合うトリガー条件を選択してください。詳細については、「イベントトリガータスクの作成」をご参照ください。
イベントトリガータスクを使用した Auto Scaling (ESS) インスタンスの削除
イベントトリガータスクを作成する際に、インスタンスを削除するためのスケーリングルールをトリガーとして選択します。詳細については、「スケーリングルールの作成」および「イベントトリガータスクの作成」をご参照ください。
Auto Scaling は、CloudMonitor のカスタムメトリクスに基づいて動的スケーリングを実行できますか?
はい。詳細については、「カスタムモニタリングに基づくイベントトリガー タスク」をご参照ください。
Auto Scaling の問題でチケットを送信する際に必要な情報
チケットを送信する際は、問題を迅速にトラブルシューティングできるよう、スケーリングアクティビティ ID (ScalingActivityId) および関連するログをご提供ください。
スケーリングアクティビティを表示するには、「スケーリングアクティビティの詳細の表示」をご参照ください。
スケーリンググループが ECS インスタンスを作成する際のリソースエラー
以下のエラーメッセージが表示された場合、これらのエラーは ECS リソースの不足が原因である可能性があります。エラーメッセージに 「region」 と表示されていても、特定ゾーンでのリソース枯渇が原因である場合が多いため、別のゾーンに切り替えて再試行することを推奨します。
Fail to create Instance into scaling group("The resource is out of usage.").Fail to create Instance into scaling group("The specified region is in resource control, please try later.").
単一インスタンスタイプの在庫不足によるスケールアウト失敗の防止
異なるゾーンの vSwitch を選択して、スケーリンググループに複数のゾーンを設定します。さらに、スケーリング設定で複数のインスタンスタイプを指定します。あるゾーンでインスタンスタイプが利用できない場合、Auto Scaling は自動的に別の利用可能なゾーンで、指定された他のインスタンスタイプのインスタンスを作成しようとします。詳細については、「スケーリンググループの作成」および「ECS インスタンスのスケーリング設定の作成」をご参照ください。
スケーリンググループ内で解放保護を有効にしても、ECS インスタンスが自動解放されるのはなぜですか?
Auto Scaling が ECS インスタンスを自動的に作成した後、ECS コンソールのインスタンス一覧ページや ModifyInstanceAttribute API を使用してインスタンスの解放保護を有効にしても、Auto Scaling による自動解放は防げません。
スケールイン時にインスタンスが自動的に解放されないようにするには、スケーリンググループ内でインスタンスを保護状態に設定する必要があります。詳細については、「インスタンス保護の設定」をご参照ください。
手動で追加されたインスタンスがスケーリンググループから削除されないようにするには
ECS または ECI インスタンスが自動的に削除されないようにするには、スケーリンググループ内でインスタンスを保護状態に設定します。詳細については、「インスタンス保護の設定」をご参照ください。
Auto Scaling は、ApsaraDB RDS または Memcache インスタンスの IP ホワイトリストを自動更新しますか?
Auto Scaling は、関連付けられた ApsaraDB RDS インスタンスの IP アドレスホワイトリストに、ECS インスタンスの IP アドレスを自動的に追加または削除します。この機能は Memcache インスタンスには適用されません。
スケーリンググループに手動で追加されたインスタンスが自動的に削除されるのを防ぐ方法
手動で追加された 100 台の ECS または ECI インスタンスがスケーリンググループから自動的に削除されないようにするには、次の設定を行います:
-
最小インスタンス数を 100 以上に設定します。
-
第 1 レベルのスケールインポリシーを スケーリング設定が最も古いインスタンス に設定します。
手動で追加されたインスタンスはスケーリング設定によって作成されたものではないため、このポリシーは適用されません。スケーリンググループは、まず自動的に作成されたインスタンスを削除します。自動的に作成されたすべてのインスタンスが削除された後、はじめてスケーリンググループは最小インスタンス数に達するまで手動で追加されたインスタンスを削除します。
インスタンスが削除されるのを防ぎたい場合は、手動で追加されたインスタンスを停止しないでください。 Auto Scaling は、他の設定に関係なく、停止したインスタンスを異常と見なし、スケーリンググループから自動的に削除します。
ECS インスタンスがスケーリンググループから削除され、リリースされた後、インスタンス上のデータは保持されますか?
いいえ。
Auto Scaling は ECS インスタンスを自動的にリリースします。スケーリンググループ内のインスタンスには、セッションデータ、データベース、ログなどのステートフルな情報や重要なデータを保存しないようにしてください。アプリケーションで状態を維持する必要がある場合は、専用の ECS インスタンスなどの別のステートフルサーバー、ApsaraDB RDS などのマネージドデータベース、またはロギングサービスに状態情報を保存してください。
Auto Scaling によって作成されたインスタンスの削除
スケーリンググループ内のインスタンスリストから、自動的に作成された ECS または ECI インスタンスを削除できます。詳細については、「インスタンスの手動削除」をご参照ください。
スケールアウトアクティビティ中に一部の ECS インスタンスの作成に失敗した場合、どうなりますか?
Auto Scaling (ESS) は、スケーリングアクティビティレベルのトランザクションではなく、インスタンスレベルのトランザクションの完全性を保証します。コンソールでスケーリングアクティビティの完了ステータスを表示できます。詳細については、「スケーリングアクティビティの詳細の表示」をご参照ください。
例えば、スケーリングアクティビティで 20 個の ECS インスタンスの追加がリクエストされたものの、19 個のみが正常に作成され、1 個が失敗した場合、成功した 19 個のインスタンスはスケーリンググループに追加されます。システムは、失敗したインスタンスの作成を再試行しません。スケーリングアクティビティは完了しますが、そのステータスは 警告 に設定されます。別の例として、スケーリングアクティビティで 5 個の ECS インスタンスの追加がリクエストされたものの、SLB インスタンスのバックエンドサーバーのクォータを超過したために、2 個のみが正常に作成された場合を考えます。他の 3 個は無視されます。この場合、スケーリングアクティビティのステータスは [警告] に設定されます。「ロードバランサーのバックエンドサーバークォータを超過しました」などの失敗の原因、ステータス、および具体的な理由については、スケーリングアクティビティの詳細で確認できます。
Auto Scaling によって自動作成されたインスタンスのパスワードのリセットとログイン方法
スケーリング設定では、統一されたカスタムパスワードの設定はサポートされていません。Linux オペレーティングシステムを使用する場合は、スケーリング設定で SSH キーペアを指定してください。
SSH キーペアを使用せずにインスタンスにログインするには、コンソールでインスタンスのパスワードをリセットする必要があります。新しいパスワードは、インスタンスの再起動後に有効になります。
インスタンスパスワードがイメージパスワードと異なる理由
ECS インスタンスが作成されると、そのインスタンスはカスタムイメージからログインパスワードを継承しません。セキュリティ上の理由から、スケーリング設定で SSH キーペアを指定してください。
SSH キーペアを使用せずにインスタンスにログインする場合は、コンソールでインスタンスパスワードをリセットする必要があります。新しいパスワードは、インスタンスの再起動後に有効になります。
スケーリンググループ内の ECS インスタンスへのデータ同期
スケーリング設定の作成時に、カスタムイメージを使用して、データを事前設定したインスタンスを作成できます。実行中の ECS インスタンス間でデータを同期するには、rsync のようなツールをインストールして使用してください。
新しく起動したインスタンスで、 /etc/hosts に追加した 127.0.0.1 エントリがクリアされるのはなぜですか?
/etc/hosts ファイルを変更した後にカスタムイメージを作成した場合、そのカスタムイメージから ECS インスタンスが自動的に作成されると、ファイルがデフォルトのシステム設定に復元され、変更内容がクリアされます。 /etc/hosts の設定を保持する必要がある場合は、 rc.local ファイルに、 /etc/hosts ファイルに関連情報が存在するかどうかを確認し、存在しない場合に自動的にその情報を追加するスクリプトコードを追加してみてください。
スケーリンググループを SLB インスタンスと関連付ける目的
SLB インスタンスは、転送ルールに基づいて受信トラフィックを複数の ECS インスタンスに分散します。SLB インスタンスをスケーリンググループと関連付けることで、アプリケーションのキャパシティを拡張し、可用性を向上させることができます。負荷分散の詳細については、「クラシックロードバランサー (CLB) とは」をご参照ください。
スケーリンググループによる SLB インスタンスの使用方法
スケーリンググループを作成する際に SLB インスタンスを関連付けると、スケーリンググループは新しい ECS インスタンスをその SLB インスタンスに自動的に追加します。1 つの SLB インスタンスは複数のスケーリンググループに関連付けることができます。SLB インスタンスに追加された ECS インスタンスのデフォルトの重みは 50 です。バックエンドサーバーの詳細については、「デフォルトサーバーグループの管理」をご参照ください。
Auto Scaling が ECS インスタンスを作成する際、そのインスタンスは関連付けられた SLB インスタンスに自動的に追加されますか?
はい。事前にスケーリンググループに SLB インスタンスを関連付けている場合に限ります。
Auto Scaling (ESS) で作成したインスタンスを、複数の Server Load Balancer (SLB) インスタンスに追加できますか?
はい。
スケーリンググループを複数の SLB インスタンスに関連付けることができますが、制限があります。詳細については、「使用制限」をご参照ください。
関連付けられた SLB インスタンスで、スケーリンググループ内のインスタンスの重みを変更できますか?
はい。詳細については、「デフォルトサーバーグループの管理」をご参照ください。
SLB インスタンスは、バックエンドサーバーの重みを絶対値ではなく比率として計算します。たとえば、2 つのインスタンスがある場合、重みを 50 と 50 に設定しても、100 と 100 に設定しても、比率が 1:1 であるため同じ効果が得られます。通常、スケーリンググループ内のすべてのバックエンド ECS インスタンスは、同じタイプのトラフィックを処理し、仕様も同じです。Auto Scaling が設定する ECS インスタンスのデフォルトの重みは 50 です。
SLB がインターネット向けの場合、ECS インスタンスにパブリック帯域幅は必要ですか?
ECS インスタンスのパブリック帯域幅の設定は任意です。ただし、インスタンスを管理しやすくするため、スケーリング設定の作成時に少なくとも 1 Mbit/s のパブリック帯域幅を割り当てることを推奨します。
スケーリンググループ作成時のSLB インスタンスにおけるヘルスチェックエラー
以下のエラーが表示された場合、SLB インスタンスでヘルスチェックが有効になっていないことを示しています。
The current health check type of load balancer "xxxx" does not support this action.
スケーリンググループに関連付ける SLB インスタンスは、ヘルスチェックを有効にする必要があります。詳細については、「SLB インスタンスのヘルスチェックの設定と管理」をご参照ください。
新規作成された ECS インスタンスがトラフィックを処理できるかどうかの判断
スケーリンググループに SLB インスタンスを設定している場合、SLB インスタンスは、インスタンスがバックエンド ECS のポートに対するヘルスチェックに合格した後にのみ、新しいインスタンスにリクエストを転送します。
SLB インスタンスのレイヤー 7 HTTP リスナーのタイムアウトが 60 秒を超える理由
症状:SLB インスタンスが転送する単一の HTTP リクエストは、約 60 秒後にタイムアウトします。ただし、複数の ECS インスタンスがバックエンドサーバーとして設定されている場合、タイムアウトするか、504 エラーが返されるまでの合計時間は 60 秒よりも大幅に長くなります。
原因:SLB HTTP リスナーのタイムアウトは、リクエストへの応答が許容時間内に返されることを保証するための最終ガードレールです。合計タイムアウトは、設定されている ECS インスタンス数によって決まります。
複数の ECS インスタンスが設定されている場合、最初のインスタンスへのリクエストがタイムアウトすると、SLB インスタンスは 2 番目のインスタンスに対してリクエストを自動的に再試行し、すべてのインスタンスで試行が完了するまでこれを繰り返します。たとえば、SLB インスタンスにバックエンド ECS インスタンスが 3 台ある場合、実際の HTTP リクエストのタイムアウトは約 180 秒になる可能性があります。その他のサービスでも、SLB のタイムアウト設定に独自の使用制限が適用される場合があります。
解決策:SLB リスナーのタイムアウト設定に依存しないでください。代わりに、ECS インスタンスにデプロイされたアプリケーションでタイムアウトを直接設定してください。
スケーリンググループを ApsaraDB RDS インスタンスに関連付ける目的
ApsaraDB RDS は、安定した、信頼性の高い、スケーラブルなオンラインデータベースサービスです。ApsaraDB RDS インスタンスをスケーリンググループに関連付けると、自動でスケーリングされるアプリケーションインスタンスに、安定したデータベースアクセスを提供できます。ApsaraDB RDS の詳細については、「ApsaraDB RDSとは」をご参照ください。
スケーリンググループによる ApsaraDB RDS インスタンスの使用
スケーリンググループを作成する際に ApsaraDB RDS インスタンスを追加すると、スケーリンググループは新規作成されるすべての ECS インスタンスのプライベート IP アドレスを ApsaraDB RDS インスタンスの IP アドレスホワイトリストに自動的に追加します。これにより、ECS インスタンスとデータベース間の内部ネットワーク通信が可能になります。スケーリンググループは、複数の ApsaraDB RDS インスタンスに関連付けることができます。ApsaraDB RDS のホワイトリストの詳細については、「(非推奨) ApsaraDB RDS for MySQL インスタンスの IP アドレスホワイトリストの設定」をご参照ください。