いくつか検索した結果、ASAPIまたは一般的なジョブのASを管理する方法が2つあることがわかりました。
1つの方法は、ワーカー自体の内部からサーバーの正常性を直接操作することです。これはかなりの数のサイトが行っていることであり、ワーカーがシステムでジョブや冗長性を検出しなくなったときに、サーバーが異常であるとマークするので効果的です。このようにして、AS APIが登場し、一定期間後に自動的に停止します。
したがって、この方法では、一定期間のSQSキューサイズに基づいたスケールアップポリシーがあります（たとえば、100を超えるSQSメッセージの5分ごとに2台のサーバーを追加します。SQSメッセージの10分ごとに500を超える2倍のネットワーク容量50％）。スケールダウンは、アクティブなポリシーではなくコードによって処理されます。
この方法はゼロクラスターでも機能するため、使用されていないときにクラスターをサーバーなしまでダウンさせることができ、費用対効果が非常に高くなります。
利点：
- セットアップが簡単
- AWSAPI関数の使用
- おそらくセットアップが最も速い
- AWSマネージAPIを使用してクラスターサイズを管理する
短所：
- 完全なAWSAPIを使用せずに管理するのは困難です。つまり、新しいサーバーを作成するときに、すべてのインスタンスIDの完全なAPIコマンドリターンを実行しないと、インスタンスIDを取り戻すことはできません。クラスタを自己制御する要素が必要な場合は、AWS AS APIが邪魔になり、生活が少し難しくなる場合があります。
- あなたの財布に最適なものを知るためにAmazonに頼っています。正しくスケーリングするためにAmazonAPIに依存しています。これは多くの人にとっては利点ですが、一部の人にとっては欠点です。
- ワーカーはサーバープールコードの一部を格納する必要があります。つまり、ワーカーは汎用ではなく、構成を変更せずにすぐに別のクラスターに移動することはできません。
これを念頭に置いて、2番目のオプションであるDIYがあります。EC2スポットインスタンスとオンデマンドインスタンスAPIを使用して、カスタムルールに基づいて独自のASAPIを作成します。これは説明するのが非常に簡単です：
- 実行が開始されると、たとえば10台のサーバーを使用するCLIスクリプトがあります。
- 特定の条件を満たすことを検出すると、サーバーがダウンするか、さらにアップするcronジョブがあります。
利点：
- あなたの終わりを管理するための簡単でクリーン
- ジェネリックワーカーを作ることができます
- サーバープールは多くのクラスターの管理を開始できます
- ルールを作成し、AWSのメトリクスから数値を取得し、それらを比較および時間範囲で使用して、状況を変更する必要があるかどうかを理解することは、それほど複雑ではありません。
短所：
- マルチリージョンを取得するのは難しい（SQSはシングルリージョンであるため、SQSにとってそれほど悪くはありません）
- リージョンの容量とワークロードのエラーに対処するのは難しい
- 独自のサーバーの稼働時間と独自のコードに依存して、cronjobが正常に実行され、サーバーが正常にプロビジョニングされ、必要なときにサーバーが分解されるようにする必要があります。
ですから、実際には、エンドユーザーにとってより快適な戦いのようです。私は個人的に2つをまだ検討していて、自分で機能する小さなセルフホストサーバープーラーを作成しましたが、同時に、これをAWS独自のAPIで機能させるようにしたいと思っています。
これが人々に役立つことを願っています、
編集：これらの方法のいずれでも、入札方法を予測するための関数が必要になることに注意してください。そのため、スポットタイプ（EC2タイプ）で入札履歴APIを呼び出し、入札方法を計算する必要があります。
別の編集：システムの冗長性を自動的に検出する別の方法は、SQSキューの空の応答メトリックをチェックすることです。これは、ワーカーがキューにpingを実行し、応答を受信しなかった回数です。これは、ワーカーの期間中、アプリで排他ロックを使用する場合に非常に効果的です。