このページでは、反応型と予測型の両方のクラスター階層オートスケーリングをサポートする Atlas Infinite クラスターでのクラスター階層オートスケーリングについて説明します。各メカニズムの仕組みについて学ぶには、クラスター階層のリアクティブオートスケーリングおよびクラスター階層の予測的オートスケーリングを参照してください。
クラスター階層のオートスケーリング
Atlas は、クラスター階層に対してリアクティブかつ予測的なオートスケーリングを使用します。Atlas は、クラスターのタイプ、階層、ワークロードパターンに基づいて、オートスケーリング メカニズムを選択します。
リアクティブなオートスケーリング。Atlas は、現在のリソース使用量に基づいてスケーリング イベントをトリガーするために、予測ではなくしきい値を使用します。リアクティブなオートスケーリングは、リソースの使用率が継続的に高いまたは低い後に発生します。詳細については、クラスター階層のリアクティブなオートスケーリングを参照してください。
予測可能なオートスケーリング。Atlas は機械学習を使用して、履歴使用パターンに基づいて将来のスケーリング ニーズを予測し、予測されたワークロードの急増が発生する前にスケーリング イベントをトリガーしようとします。
予測的オートスケーリングは、クラスター階層のオートスケーリングの拡張機能であり、リアクティブなオートスケーリングにフォールバックします。Atlas は、周期的でも予測可能でもないワークロードの予期せぬ急増を管理するために、リアクティブなオートスケーリングに依存し続けます。Atlas は、適格なクラスターを予測するオートスケーリングを使用します。詳細については、クラスター階層の予測オートスケーリング。をご覧ください。
クラスター階層のリアクティブなオートスケーリング
注意
オートスケーリング期間の使用
Atlas のすべてのドキュメントでは、「予測」という単語なしでオートスケーリング期間が使用されている場合は常に、リアクティブなオートスケーリング メカニズムを指します。「 予測オートスケーリング 」も参照してください。
Atlas が使用するクラスター階層の範囲を構成して、クラスターの使用状況に応じてクラスター階層を自動的に増やすことができます。
リソース使用率を最適化し、コストプロファイルを改善するため、Atlas のリアクティブなオートスケーリングにより、持続的な高い需要と短期間のピークトラフィックを検出し、リアルタイムのリソース使用量に基づいてクラスター階層を調整します。
コストを管理しやすくするために、クラスターが自動的に増やすことができる最大クラスターサイズと最小クラスターサイズの範囲を指定できます。
リアクティブなオートスケーリングは順次動作するため、プロセスによるダウンタイムは発生しません。Atlas はこのプロセス中にプライマリノードを維持しますが、ノードは 1 つずつアップグレードされ、アップグレード中は使用できなくなります。
リアクティブなオートスケーリングを備えたコード ツールとしてインフラストラクチャを使用する場合のリソースドリフトの回避など、スケーラビリティに関する推奨事項については、Atlas アーキテクチャ センターのAtlas スケーラビリティに関する推奨事項を参照してください。
リアクティブなオートスケーリングに適したクラスター
Atlas クラスター階層のリアクティブオートスケーリングは、General および Low-CPU クラスタークラスに該当するすべての専用 Atlas Core クラスター階層で利用できます。リアクティブオートスケーリングは、Atlas Infinite クラスターでも利用できます。
Atlas によるクラスター階層の増加方法
Atlas Infinite クラスターでは、クラスター階層を拡大すると、クラスターで利用できるストレージ IOPS とストレージ スループットも変更されます。各階層のストレージのパフォーマンス値を検討するには、Atlas Infinite Storage IOPs およびクラスター階層ごとのスループット値を参照してください。
注意
特定の階層のストレージ パフォーマンス値は更新できません。ストレージ パフォーマンスを変更するには、クラスター階層を変更します。
Atlas は、オートスケーリングの決定のためにホストpingデータに依存します。専用クラスター データ ノードは、オートスケーリングが有効になっているかどうかに関係なく、このpingデータをコントロール プレーンに継続的に送信します。オートスケーリングを有効にすると、スケーリング条件が満たされている場合、Atlas はこの履歴データを使用してすぐに増やすできます。
Atlas では、クラスターを同じクラスにある別の階層にスケーリングします。たとえば、Atlas は General クラスターを他の General クラスタークラスにスケーリングしますが、General クラスターを Low-CPU クラスタークラスにスケーリングしません。
新しいクラスター階層が指定した Minimum と Maximum Cluster Size の範囲から外れる場合、Atlas はクラスター階層をスケーリングしません。
もし読み取り専用ノードを配置しており、クラスターのスケールを速めたい場合は、レプリカセットのスケーリングモードを調整することを検討してください。
適切なクラスターリソースの使用率を確保するために、正確なリアクティブ オートスケーリング基準は変更される可能性があります。
重要
専用のAtlas Coreクラスターの場合、宛先クラスターのストレージ容量よりも大きいサイズのスナップショットを復元すると、クラスターは自動的に拡大されません。
Atlasでは、以下のリソース使用率と操作アドミッション制御の概念を使用して、クラスターを増やすか減らすかを判断します。
絶対システム CPU 使用率: ノード上のすべてのプロセスの合計 CPU 使用率。Atlas メトリクスでは System CPU として表示されます。
相対システム CPU 使用率：Atlas が
M10およびM20クラスターの自動スケーリングの判断に使用する値です。これは次のように計算されます。Relative System CPU Utilization = Normalized System CPU / Baseline CPU Utilization以下の条件に一致するもの。
正規化されたシステムCPU: すべてのコアで合計されたCPU使用率。ベースラインのCPU使用率に正規化されています。Atlasのメトリクスでは正規化されたシステムCPUとして表示されます。
ベースラインCPU使用率: クラウドプロバイダーによってインスタンスに保証されているフルCPUの割合。バースト可能なインスタンスタイプの場合は通常20%～50%です。Atlasのメトリクスには表示されません。詳細については、ベースラインCPU使用率を参照してください。
例として、Baseline CPU Utilizationの下限見積もりとして20%を使用した場合、次のRelative System CPU Utilizationの値は、Atlasメトリクスの正規化されたシステムCPUの値に対応します。
75%相対システムCPU使用率が15%Normalized System CPU (75% / 20%) になりました。90%相対システムCPU使用率が18%Normalized System CPU (90% / 20%) になりました。
計算結果が 100% を超える場合でも、Atlas は Relative System CPU Utilization を % に制限します。Normalized System CPU が低いときに増やすことが発生した場合は、MongoDB サポートにお問い合わせください。
システムメモリ利用率: ノード上のすべてのプロセスにおけるメモリの総使用量、ノードで利用可能なメモリ総量に対する割合として表示されます。これは次のように計算されます。
System Memory Utilization = Memory Used / Total Memory * 100以下の条件に一致するもの。
使用メモリ: ホスト上で現在使用されている物理メモリのバイト数。AtlasメトリクスではSystem Memory: Memory Used (bytes)として表示されます。
合計メモリ: オペレーティングシステムによって報告される、ノードで使用可能な物理メモリの合計。Atlas はこの値を個別のメトリクスとして表示しません。Atlas のメトリクスには表示されません。
注意
Atlasが自動スケーリングの決定に使用する System Memory Utilization 値は、Atlasメトリクスパネルに表示される値とわずかに異なる場合があります。System Memory Utilization が低いように見えるのにスケールダウンが発生しない場合は、MongoDBサポートにお問い合わせください。
キューに入れられた操作または拒否された操作: Intelligent ワークロード マネジメント (IWM) の一部として、クラスターの過負荷を防ぐために Atlas がキューに入れるか拒否する操作の合計レート。Atlas はこれを次のように計算します。
Queued or Rejected Operations = Queued Operations + Rejected Operations以下の条件に一致するもの。
キューに入れられた操作: クラスターへの受け入れを待つために、Atlasがイングレスリクエストレートリミッターキューに追加する受信操作の1分あたりの平均レート。1秒あたりのレートは、Atlasメトリクスの操作レート制限: キューに入れられた操作として表示されます。
拒否された操作: クラスターが過負荷状態でロードシェディングがアクティブなためにAtlasが拒否した、1分あたりの受信操作の平均レート。1秒あたりのレートは、Atlasメトリクスの操作レート制限: 拒否された操作として表示されます。
クラスターの過負荷に応じて操作をキューに入れるか拒否するIWMの仕組みを学ぶ方法については、「Intelligent ワークロード マネジメント」を参照してください。
合計値が0を超える場合、クラスターが過負荷状態であることを意味します。
以下のセクションでは、Atlasがこれらのメトリクスを使用して、クラスターを増やすか減らすかを判断する方法について説明します。
拡大の条件
アプリケーションの動的ワークロードを管理するために、Atlas はこのセクションに記載されている条件下でクラスター内のノードをリアクティブに増やします。
最適なリソース利用とコストプロファイルを達成するために、Atlas は次の条件が満たされる場合にクラスターを次の階層にスケールアップすることを避けます。
M10またはM20クラスターが、過去 20 分または 1 時間（しきい値による）以内にスケールアップされた。M30+クラスターが、過去 10 分または 1 時間（しきい値による）以内にスケールアップされた。クラスターは、Queued or Rejected Operations の基準により、過去 10 分間にスケールアップされました。
たとえば、12:00 以降クラスター階層が変更されていない場合、クラスターの現在の正規化されたシステム CPU 使用率が 90% を超えると、Atlas は M30+ クラスターを 12:10 にスケールアップします。
次のクラスター層がMaximum Cluster Size 範囲内にある場合、このタイプの任意のクラスター ノードに対して次の条件の少なくとも 1 つが当てはまる場合、Atlas はクラスター内の稼働ノードを次の層までスケールアップします。
注意
このセクションの条件は、ノードについて説明しています。任意のクラウドプロバイダーの分析ノードの場合、Normalized System CPU の平均または System Memory Utilization が、過去 1 時間にクラスター ノードで利用可能なリソースの 75% を超えた場合、Atlas はそれらを次の階層に増やします。Atlas は、分析ノードに Queued or Rejected Operations 基準を適用しません。
以下のリストは、クラスター階層ごとに基準をグループ化しています。各階層内で、CPU関連の基準が最初に表示され、次にメモリ関連の基準が続きます。これら2つのセットのそれぞれにおいて、クラウドプロバイダー固有の基準が最初に表示されます。残りの基準は、最も制限の厳しいものから順に表示されます。過負荷の基準はすべての専用階層に適用され、最後に表示されます。
M10およびM20クラスター:AWS。正規化された Relative System CPU Utilization の平均が過去 20 分間で 90% を超え、CPU スティールにおける非正規化された Absolute System CPU Utilization の平均が過去 3 分間で 30% を超えています。
Azure。正規化された Relative System CPU Utilization の平均が過去 20 分間で 90% を超え、正規化されていない Absolute System CPU Utilization の平均が、softIRQにおいて過去 3 分間で 10% を超えています。
平均正規化 Absolute System CPU Utilization が過去 20 分間にクラスターで利用可能なリソースの 90% を超えました。
過去 1 時間の平均正規化 Relative System CPU Utilization が、クラスターで使用可能なリソースの 75% を超えています。
平均 System Memory Utilization が過去 10 分間にクラスターで利用可能なリソースの 90% を超えました。
過去 1 時間の平均 System Memory Utilization が、クラスターで使用可能なリソースの 75% を超えています。
注意
Normalized System CPU が低く表示されているときにスケールアップが発生する場合は、 MongoDBサポートにお問い合わせください。
M30+クラスター:平均 Normalized System CPU が過去 10 分間にクラスターで利用可能なリソースの 90% を超えました。
過去 1 時間の平均 Normalized System CPU が、クラスターで使用可能なリソースの 75% を超えています。
平均 System Memory Utilization が過去 10 分間にクラスターで利用可能なリソースの 90% を超えました。
過去 1 時間の平均 System Memory Utilization が、クラスターで使用可能なリソースの 75% を超えています。
すべての専有クラスター、
M10+:Queued or Rejected Operations 過去 10 分間のすべてのサンプルでゼロを超えたままです。
Atlasでは、平均値ではなく10分間のウィンドウ全体でレートがゼロを上回っている必要があるため、トラフィックが急増した際にキューイングや操作の拒否が短時間発生しても、クラスターは増えません。ロードシェディングが継続的に発生している場合は、ワークロードが現在の階層で許容できる範囲を超えていることを示しているため、Atlasは過負荷を軽減するために増やすを実行します。
注意
この基準は、Atlasが負荷を軽減したかどうかを測定するものであり、どれだけ軽減したかを測定するものではありません。ゼロを超える持続的なレートはすべて、しきい値を満たします。
これらのしきい値により、クラスターは高負荷に対応して迅速にスケールアップし、パフォーマンスと信頼性を維持できます。
注意
Atlas は、リージョン停止時がシミュレーションされた場合、クラスター階層のオートスケーリングをトリガーしません。この動作は、クラスターにスケーリング操作をサポートするための正常なノードが不十分な場合、実際のリージョン停止時時に発生する可能性があります。
重要
ワークロードの急増
より大きなクラスター階層にスケールアップするには、バッキングリソースを準備するのに十分な時間が必要です。クラスターが一括挿入などのアクティビティのバーストを受け取った場合、オートスケーリングが実行されない可能性があります。リソース不足のリスクを軽減するには、一括挿入やその他のワークロードの急増が発生する前にクラスターのスケールアップを計画します。
例
Atlasがどのように拡大条件を評価するかを確認するために、次の値を使用した例のシナリオを検討してください。ベースラインのCPU使用率はAtlasのメトリクスパネルには表示されず、バースト可能なインスタンスタイプでは20%から50%の範囲になる可能性があります。その範囲内の任意の値を使用して上限と下限を推定できます。この例では、その範囲の下限として20%を使用します。
Normalized System CPU: 60%
ベースライン CPU 使用率: 20%
CPU スティール: 10%
条件を評価するとします。
条件 1（AWS）: 20 分間、平均相対的システム CPU 使用率 > 90% かつ、3 分間、平均CPU スティール > 30% が必要です。
相対的 CPU: 60% 割 20% = 300%、上限は 100%。最初にしきい値に達しました。
CPU スティール率は 10% で、30% を超えることはありません。2 つ目のしきい値を満たしていません。
結果: 条件 1 が満たされていません。両方のしきい値が真である必要があります。
条件 2: 20 分間の平均 Normalized System CPU > 90% が必要です。
Normalized System CPU は 60% で、90% を超えることはありません。
結果: 条件 2 が満たされていません。
条件 3: 平均相対システム CPU 使用率 が 1 時間で 75% 以上である必要があります。
相対的 CPU: 60% 割 20% = 300%、上限は 100%。
結果: 条件 3 が満たされました。Atlasがオートスケーリングをトリガーします。
拡大の条件
コストを最適化するために、Atlas はこのセクションに記載されている条件下でクラスター内のノードの増やす量を反応的に減らします。
Atlas では、遡及ではなく、ダウンスケーリングを有効にした時点からこれらの条件のチェックが開始されます。ダウンスケーリングを有効にする前にクラスターがこれらの条件を満たしていても、機能を有効にしてから必要な時間が経過するまで、Atlas は増やすダウンしません。
次に低いクラスター階層が Minimum Cluster Size の範囲内にある場合、クラスター内のすべてのノードに対して次の条件の すべて が当てはまる場合、Atlas では、クラスター内のノードが次に低い階層にスケールダウンされます。
すべてのノード:
Atlas は過去 24 時間以内にクラスターを（手動または自動で）スケールダウンしていません。
Atlas は過去24時間にクラスターをプロビジョニングまたは一時停止解除していません。
Atlas で過去 12 時間でクラスター ノードを停止して再起動したことはありません。
平均Normalized System CPU は、少なくとも過去の45 10分かつ過去の 時間でクラスターで利用可能なリソースの %4 を下回っている。Atlas は、CPU 負荷が監視レベルで安定したことを示すインジケーターとして「4時間平均」チェックポイントを使用します。Atlas は、Atlas が "4 時間平均 チェックポイント でキャプチャしなかった直近の CPU 使用率の上昇が発生していないことを示す指標として、「10 分平均」チェックポイントを使用します。
注意
M10およびM20階層の場合、Atlas は標準の 100% ベースラインではなく、インスタンスのベースライン CPU 使用率に対して 45% CPU のしきい値を適用します。20% を下限値の推定値として使用すると、スケールダウンに有効な絶対 CPU しきい値は約 9%（20% の 45%）になります。WiredTiger のキャッシュ 使用量の平均が、現在の クラスター階層サイズで直近の 10 分および 4 時間で、WiredTiger の最大キャッシュサイズの 90% を下回っている。これは、現在のクラスターが過負荷になっていないことを Atlas に示します。
新しい下位クラスター階層での Projected Memory Utilization が、少なくとも過去 10 分間および過去 4 時間で 60% を下回っている。
Projected Memory Utilization を計算するには、Atlas は、Atlas メトリクスのSystem Memory: Memory Used (bytes) として表示される現在のメモリ使用量から開始します。Atlas は現在の WiredTiger キャッシュ 使用量を引き、新しい下位階層の最大 WiredTiger キャッシュ サイズの 80% を追加し、その階層の総 RAM で結果を分割します。
この値は、現在の階層のRAMに対して使用中のすべてのメモリを測定するSystem Memory Utilizationとは異なります。
注意
Atlas はこの計算に WiredTiger キャッシュを含めて、クラスターが完全なキャッシュを持っているものの、それ以外の場合にトラフィックが少なければ、スケールダウンする可能性を高くします。スケールダウンするには、次のスレッショルドの両方を満たす必要があります。
90%: 現在の階層のWiredTigerキャッシュ使用率は、最大サイズの90%未満である必要があります。
60%: 新しい下位階層のProjected Memory Utilizationは60%未満である必要があります。
これらの条件により、Atlas はクラスター内の稼働中のノードをスケールダウンして、高使用率の状態を防ぐことができます。
注意
Atlas は、メモリに基づいた拡大を **予測メモリ使用率** System Memory Utilizationを使用して評価します。これは Atlas UI に表示される とは異なります。System Memory Utilizationが低いように見えるときにスケールダウンが発生しない場合は、MongoDB サポートにお問い合わせください。
- 過去 24 時間の平均 Normalized System CPU と System Memory Utilization が、クラスターで利用可能なリソースの 50% を下回っている。
注意
M10とM20クラスターは、バースト期間後にクラウドプロバイダーが設定した CPU 使用率の上限を考慮して、より低いしきい値を使用しています。これらのしきい値は、クラウドプロバイダーとクラスター階層によって異なります。
クラスター階層の予測オートスケーリング
予測型オートスケーリングは、オートスケーリングの拡張機能です。
Atlas はホストするリソース使用率に需要予測を使用し、クラスター コンピュートの事前拡大を実行して最適なリソース使用率を確保します。予測可能なオートスケーリングにより、Atlas は定期的なワークロードの急増が発生する前に、クラスターのプロアクティブな増やすアップを試みます。
予測的なオートスケーリングは、履歴パターンに基づく機械学習モデルによって強化されます。Atlas は、拡大の決定を行うためにプライマリノードのリソース使用率を分析します。モデルは、履歴使用パターンに基づいてリソース使用率が高くなるタイミングを予測し、モデルが高いリソース使用率を予測する場合は、Atlas はクラスターをスケールアップします。MongoDB は、Atlas のパフォーマンスを最適化するために、モデルとその基準を継続的に更新します。
このモデルは、定期的にパターンを識別するためにローリング4週の入力ウィンドウを分析します。このウィンドウ内で確認可能なパターン（1 時間例、毎日、毎週ごと、または毎週ごとのサイクルなど）はキャプチャできます。毎月や四半期ごとのサイクルなど、期間が長いパターンは 4 週のウィンドウの外側に表示されるため、検出できません。
注意
ウィンドウの上限に近いパターンでは、ウィンドウ内で発生する完全なサイクルが少なくなるため、精度が低下する可能性があります。
予測的オートスケーリングには、予測的かつ定期的なワークロードを持つクラスターに対して次のメリットがあります。
4 週の入力ウィンドウ内に定期的なワークワークロードパターンのクラスターを自動的に増やすアップします。
予測可能な高負荷期間中にコンシステントなパフォーマンスと可用性を維持します。
Atlas の管理キャパシティーが増加することで、手動スケーリング タスクまたはスケジュールされたスクリプトを削減します。
クラスターのワークロードへの変更が予測可能なパターンの範囲外で、非定期的または予測できない場合は、リアクティブなオートスケーリングにシームレスにフォールバックします。
予測オートスケーリングをtriggerするには、クラスターが 2 週間継続的なアクティビティ ログを維持する必要があります。この基準を満たすと、システムは予測可能なオートスケーリングを有効にします。
注意
クラスターを一時停止した場合、再開するには 2 週間連続で予測されるオートスケーリングのアクティビティが必要です。
予測オートスケーリングの動作
次のステートメントは、予測型オートスケーリングの仕組みを説明しています。
Atlas は、予測された負荷が到達する前にクラスターのインスタンスサイズを増やすアップしようとします。
Atlas が予測メトリクスに基づいてクラスターを予測的に増やす場合、一度に最大 2 階層ずつ増やすことができます。
予測オートスケーリングは、ストレージではなく、コンピュートにのみ適用されます。
予測的なオートスケーリングは、既存のオートスケーリングの最小インスタンスサイズと最大インスタンスサイズを尊重します。
Atlas が予測オートスケーリングを使用してクラスターを増やすアップできない場合は、リアクティブなオートスケーリングを使用するようにフォールバックします。
予測オートスケーリングはアップスケーリングのみをサポートします。ダウンスケーリングを予測することはできません。Atlas はリアクティブなオートスケーリングを使用して、ワークロードが減少するとクラスターを自動的に増やすします。
予測的なアップ拡大が今後の 1 時間以内に実行されるようにスケジュールされている場合、Atlas はリアクティブなダウン拡大をスキップします。
予測型オートスケーリングに適したクラスター
Atlas は、適格なクラスターを予測するオートスケーリングを使用します。予測オートスケーリングに適したクラスターは、次の条件をすべて満たしている必要があります。
General と Low-CPU のクラスター クラスに属します。
階層が
M30以上であること。オートスケーリングを有効にします。ダウンスケーリングを有効にする場合、オートスケーリングの最小インスタンスサイズは
M30以上である必要があります。少なくとも 2 週間アクティブであること。
M30階層以上のAtlas Infiniteクラスターは、Amazon Web Services Gen2ハードウェアで実行されます。予測オートスケーリングは、これらのクラスターをサポートします。
さらに、次の基準は、Atlas が適格なクラスターに対して予測オートスケーリングを使用するかどうかに影響します。
予測オートスケーリングは、選択可能なノードと読み取り専用ノードにのみ適用されます。Atlas は、検索するノードまたは分析ノードに予測型オートスケーリングを使用しません。
予測的オートスケーリングでは、適格なクラスターで非定期的で非常に動的なワークロードの急増を予測できない可能性があります。このような場合、Atlas はリアクティブなオートスケーリングに依存します。
クラスター階層の下方拡大に関する考慮事項
クラスターの編集ページから、クラスター階層を手動で削減できます。クラスター層を 手動で増やすダウン する場合は、次の考慮事項が適用されます。
配置のワークロードの範囲を見積もり、Minimum Cluster Size の値を、配置のワークロードを処理するのに十分なキャパシティーがあるクラスター階層に設定します。クラスターの活動が急上昇または急降下する可能性を考慮する必要があります。
M10より小さいクラスター階層にはスケールできません。
オートスケーリングオプションを構成する
クラスターを作成または変更するときに、オートスケーリング オプションを構成できます。Atlasでは、Atlas Infiniteクラスターに対してコンピューティングのオートスケーリングを推奨しています。クラスターを作成または変更する際に、それを使用するかどうかを選択します。
次のいずれかの操作を実行できます。
クラスターをオートスケーリングするときに Atlas が使用する必要がある上位クラスター階層と下位クラスター階層を確認して調整するか、 または
オートスケーリング の使用をオプトアウトします。
Atlas では、General クラスター階層および Low-CPU クラスター階層のクラスター ビルダーの Auto-scale セクションにオートスケーリング オプションが表示されます。
Atlas CLI と Atlas Administration API を使用したオートスケーリングを有効にする
Atlas CLI または Atlas Administration API を使用してクラスターを作成または更新する際に、コンピュートのオートスケーリングを有効化できます。次の例では、選挙可能な ノードおよび分析ノードの両方でオートスケーリングを有効化する方法を示します。必要なクラスター階層とプロバイダー設定に置き換えます。
Atlas CLI でオートスケーリングを構成するには、オートスケーリング構成を含む JSON ファイルを作成し、それを atlas api clusters updateCluster コマンドで指定します。
クラスター階層のオートスケーリング オプションを検討する
クラスター階層に対して有効になっているオートスケーリング オプションを検討するには、次の手順を行います。
クラスター階層のオートスケーリングをオプトアウトする
クラスターのオートスケーリング（クラスター階層の増加）をオプトアウトするには、新しいクラスターを作成するときに、Cluster Tier メニューに移動し、Auto-scale セクションの Compute Auto-Scale チェックボックスをオフにします。
クラスターのオートスケーリング（クラスター階層の減少）をオプトアウトするには、新しいクラスターを作成するときに、Cluster Tier メニューに移動し、Auto-scale セクションの Allow cluster to be scaled down チェックボックスをオフにします。