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