Atlas はクラスター コンピュートのオートスケーリングを使用して、クラスター階層を調整することでリソース使用率とコストを最適化します。Atlas はストレージのオートスケーリングを使用して、クラスターのストレージキャパシティーを自動的に増やします。
このセクションでは、次の内容を学ぶことができます。
クラスター階層のオートスケーリング
Atlas は、クラスター階層に対してリアクティブかつ予測的なオートスケーリングを使用します。Atlas は、クラスターのタイプ、階層、ワークロードパターンに基づいて、オートスケーリング メカニズムを選択します。
リアクティブなオートスケーリング。Atlas は、現在のリソース使用量に基づいてスケーリング イベントをトリガーするために、予測ではなくしきい値を使用します。リアクティブなオートスケーリングは、リソースの使用率が継続的に高いまたは低い後に発生します。詳細については、クラスター階層のリアクティブなオートスケーリングを参照してください。
予測可能なオートスケーリング。Atlas は機械学習を使用して、履歴使用パターンに基づいて将来のスケーリング ニーズを予測し、予測されたワークロードの急増が発生する前にスケーリング イベントをトリガーしようとします。
予測的オートスケーリングは、クラスター階層のオートスケーリングの拡張機能であり、リアクティブなオートスケーリングにフォールバックします。Atlas は、周期的でも予測可能でもないワークロードの予期せぬ急増を管理するために、リアクティブなオートスケーリングに依存し続けます。Atlas は、適格なクラスターを予測するオートスケーリングを使用します。詳細については、クラスター階層の予測オートスケーリング。をご覧ください。
重要
Atlas でクラスターを作成し、その後、Atlas はクラスターのタイプ、階層、ワークロードに基づいてオートスケーリング メカニズムを使用します。Atlas 管理API を使用する場合は、オートスケーリングを明示的に有効にする必要があります。
クラスター階層のリアクティブなオートスケーリング
注意
オートスケーリング期間の使用
Atlas のすべてのドキュメントでは、「予測」という単語なしでオートスケーリング期間が使用されている場合は常に、リアクティブなオートスケーリング メカニズムを指します。「 予測オートスケーリング 」も参照してください。
Atlas が使用するクラスター階層範囲を構成して、クラスターの使用状況に応じてクラスター階層、ストレージ容量、またはその両方をオートスケーリングできます。
リソース使用率を最適化し、コストプロファイルを改善するため、Atlas のリアクティブなオートスケーリングにより、持続的な高い需要と短期間のピークトラフィックを検出し、リアルタイムのリソース使用量に基づいてクラスター階層を調整します。
コストを管理しやすくするために、クラスターが自動的に増やすことができる最大クラスターサイズと最小クラスターサイズの範囲を指定できます。
リアクティブなオートスケーリングは順次動作するため、プロセスによるダウンタイムは発生しません。Atlas はこのプロセス中にプライマリノードを維持しますが、ノードは 1 つずつアップグレードされ、アップグレード中は使用できなくなります。
リアクティブなオートスケーリングを備えたコード ツールとしてインフラストラクチャを使用する場合のリソースドリフトの回避など、スケーラビリティに関する推奨事項については、Atlas アーキテクチャ センターのAtlas スケーラビリティに関する推奨事項を参照してください。
リアクティブなオートスケーリングに適したクラスター
Atlasクラスター層のリアクティブなオートスケーリングは、General および Low-CPU クラスター クラス配下にあるすべての専有クラスター階層で利用できます。
Atlas によるクラスター階層の増加方法
注意
階層の可用性
リアクティブなオートスケーリングは、General クラスと Low-CPU クラスのクラスター階層では機能しますが、not Local NVMe SSDクラスのクラスターでは機能しません。
Atlas は、オートスケーリングの決定のためにホストpingデータに依存します。専用クラスター データ ノードは、オートスケーリングが有効になっているかどうかに関係なく、このpingデータをコントロール プレーンに継続的に送信します。オートスケーリングを有効にすると、スケーリング条件が満たされている場合、Atlas はこの履歴データを使用してすぐに増やすできます。
Atlas は次のクラスターのメトリクスを分析して、クラスターをリアクティブに増やすタイミングと、クラスター階層を増やすか、または減らすかを決定します。
Normalized System CPU 使用率
システムメモリ使用率
Atlas は、使用可能なノードメモリと合計メモリに基づいて、次のようにシステムメモリ使用率を計算します。
(memoryTotal - (memoryFree + memoryBuffers + memoryCached)) / (memoryTotal) * 100
前の計算では、memoryFree、memoryBuffers、および memoryCached は、Atlas が他の目的で再利用できる使用可能なメモリの量です。詳しくは、「利用可能なメトリクスを確認する」の System Memory を参照してください。
注意
Atlas がオートスケーリングの決定に使用する System Memory Utilization 値は、Atlas メトリクス パネルに表示される値と若干異なる場合があります。
新しいクラスター階層が指定した Minimum と Maximum Cluster Size の範囲から外れる場合、Atlas はクラスター階層をスケーリングしません。
Atlas では、クラスターを同じクラスにある別の階層にスケーリングします。たとえば、Atlas は General クラスターを他の General クラスタークラスにスケーリングしますが、General クラスターを Low-CPU クラスタークラスにスケーリングしません。
適切なクラスターリソースの使用率を確保するために、正確なリアクティブ オートスケーリング基準は変更される可能性があります。
重要
また、移行中に、宛先クラスターのストレージ容量よりも大きいサイズのスナップショットを復元すると、クラスターはオートスケーリングされません。
もし読み取り専用ノードを配置しており、クラスターのスケールを速めたい場合は、レプリカセットのスケーリングモードを調整することを検討してください。
クラスター階層をリアクティブに拡大する
アプリケーションの動的ワークロードを管理するために、Atlas はこのセクションに記載されている条件下でクラスター内のノードをリアクティブに増やします。
条件を解釈するために、Atlas では次の CPU 使用率の概念を使用します。
ベースライン CPU 使用率:クラウドプロバイダーによってインスタンスに保証されたフル CPU の割合。バースト可能なインスタンスタイプでは通常 20% ～ 50% です。Atlas メトリクスには表示されません。
絶対システム CPU 使用率: すべてのコアで合計された CPU 使用率の合計。Atlas メトリクスで System CPU として表示されます。Atlas は、この値をオートスケーリングの決定で直接使用することはありません。
相対的システム CPU 使用率: Atlas が
M10クラスターとM20クラスターのオートスケーリングの決定に使用する値。Normalized System CPU 値をベースライン CPU 使用率で割った値として計算されます。この値は Atlas メトリクスには直接表示されず、ベースライン CPU 割合はメトリクス パネルに表示されません。これを見積もるには、Normalized System CPU の読み取りを、バースト可能なインスタンスタイプに一般的な 20%-50% 範囲のベースライン値で割ります。Atlas では、計算がそれを超える場合でも、この値は 100% に上限されます。
次のクラスター層がMaximum Cluster Size 範囲内にある場合、このタイプの任意のクラスター ノードに対して次の条件の少なくとも 1 つが当てはまる場合、Atlas はクラスター内の稼働ノードを次の層までスケールアップします。
注意
次のリストは、CPU 関連の基準をグループ化し、その後にメモリ関連の基準を続けて示します。各グループ内では、基準は最も制限の厳しいものから最も緩やかなものの順に表示され、特定のクラウドプロバイダーの基準が存在する場合は最初に表示されます。
M10およびM20クラスター:Amazon Web Services 。正規化された相対的システム CPU 90使用率の平均が過去20 分間で % を超え、CPU スティール率の平均非正規化絶対 CPU 30使用率が過去3 分間で % を超えています。
Azure。正規化されたシステム CPU の相対使用率の平均が過去 20 分間で 90% を超え、正規化されていないシステム CPU の絶対使用率の平均が、softIRQにおいて過去 3 分間で 10% を超えています。
正規化されたシステムCPU の絶対使用率の平均が、過去 20 分間にクラスターで利用可能なリソースの 90% を超えました。
正規化されたシステム CPU の相対使用率の平均が、過去 1 時間にクラスターで利用可能なリソースの 75% を超えました。
平均 System Memory Utilization が過去 10 分間にクラスターで利用可能なリソースの 90% を超えている。 Atlas がシステムメモリ使用率の量を計算する方法については、「 Atlas がクラスター階層をスケーリングする方法 」を参照してください。
過去 1 時間の平均 System Memory Utilization が、クラスターで使用可能なリソースの 75% を超えています。
注意
M10およびM20階層の場合、Atlas は標準の 100% ベースラインではなく、インスタンスの ベースライン CPU 使用率 に CPU しきい値を決定します。ベースラインは Atlas メトリクス パネルでは表示されず、バースト可能なインスタンスタイプでは 20% ～ 50% の範囲で指定されます。Baseline CPU utilization per vCPU 列については、AWS のバースト可能なインスタンスのドキュメントを参照してください。20% を下限値の推定値として使用すると、有効な絶対 CPU しきい値は次のようになります。75% 相対システム CPU 使用率のしきい値は、15% 絶対 CPU（20% の 75%）に等しくなります。
90% 相対システム CPU 使用率のしきい値は、18% 絶対 CPU（20% の 90%）に等しくなります。
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% を超えています。
これらのしきい値により、クラスターは高負荷に対応して迅速にスケールアップし、アプリケーションはトラフィックや使用量の急増に対応しながら、パフォーマンスと信頼性を維持できます。
注意
このセクションの条件は、運用ノードについて説明します。任意のクラウドプロバイダー上の分析ノードの場合、平均 Normalized System CPU または System Memory Utilization が過去 1 時間で任意のクラスターノードで使用可能なリソースの 75% を超えている場合、Atlas はそれらを次の階層にスケールアップします。
例
AWS M10 クラスターのスケーリング条件
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 つ目のしきい値を満たしていません。
結果: 満たしていません。いずれのしきい値も true である必要があります。
条件 2: 20 分間の平均 Normalized System CPU > 90% が必要です。
Normalized System CPU は 60% で、90% を超えることはありません。
結果: 満たしていません。
条件 3: 平均相対システム CPU 使用率 が 1 時間で 75% 以上である必要があります。
相対的 CPU: 60% 割 20% = 300%、上限は 100%。
結果: メトリクス。Atlas はオートスケーリングをトリガーします。
最適なリソース利用とコストプロファイルを達成するために、Atlas は次の条件が満たされる場合にクラスターを次の階層にスケールアップすることを避けます。
M10またはM20クラスターが、過去 20 分または 1 時間（しきい値による）以内にスケールアップされた。M30+クラスターが、過去 10 分または 1 時間（しきい値による）以内にスケールアップされた。
たとえば、12:00 以降クラスター階層が変更されていない場合、クラスターの現在の正規化されたシステム CPU 使用率が 90% を超えると、Atlas は M30+ クラスターを 12:10 にスケールアップします。
重要
ワークロードの急増
より大きなクラスター階層にスケールアップするには、バッキングリソースを準備するのに十分な時間が必要です。クラスターが一括挿入などのアクティビティのバーストを受け取った場合、オートスケーリングが実行されない可能性があります。リソース不足のリスクを軽減するには、一括挿入やその他のワークロードの急増が発生する前にクラスターのスケールアップを計画します。
注意
Atlas は、リージョン停止時がシミュレーションされた場合、クラスター階層のオートスケーリングをトリガーしません。この動作は、クラスターにスケーリング操作をサポートするための正常なノードが不十分な場合、実際のリージョン停止時時に発生する可能性があります。
クラスター階層のリアクティブなスケールダウン
コストを最適化するために、Atlas はこのセクションに記載されている条件下でクラスター内のノードの増やす量を反応的に減らします。
次に低いクラスター階層が Minimum Cluster Size の範囲内にある場合、Atlas は、指定されたクラスタータイプのすべてのノードに対して次の条件のすべてが当てはまる場合、クラスター内のノードを次の最も低い層にスケールダウンします。
注意
Atlas では、遡及ではなく、ダウンスケーリングを有効にした時点からこれらの条件のチェックが開始されます。ダウンスケーリングを有効にする前にクラスターがこれらの条件を満たしていても、機能を有効にしてから必要な時間が経過するまで、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 に示します。
新しい下位クラスター階層での予測される合計システムメモリ使用率が、少なくとも過去 10 分間および過去 4 時間で 60% を下回っている。Atlas は、上述の予測される合計メモリ使用率を次のように計算します。
Atlas は、現在のメモリ使用率を測定し、現在の WiredTiger キャッシュ使用量を新しい下位階層クラスターの WiredTiger キャッシュサイズの 80% に置き換えます。
次に、Atlas は、予測される合計メモリ使用量が新しい階層サイズで少なくとも過去 4 時間および少なくとも過去 10 分間、60% を下回っているかどうかを確認します。
注意
Atlas は、フルキャッシュを持つクラスターが増やすする可能性を高めるために、メモリ計算にWiredTigerキャッシュを含めます。このチェックでは 2 つのしきい値が適用されます。
90%: 現在の階層のWiredTigerキャッシュの使用量は、最大サイズの 90% を下回っている必要があります。これを超える場合、Atlas は増やすダウンしません。
60%: 新しい下位階層の予測される合計メモリは 60% 未満である必要があります。このプロジェクションを計算するために、Atlas は新しい階層でのWiredTigerキャッシュ使用量がその階層の最大キャッシュサイズの 80% であると想定しています。
これらの条件により、Atlas はクラスター内の稼働中のノードをスケールダウンして、高使用率の状態を防ぐことができます。
注意
Atlas は、Atlas UIに表示される System Memory Utilization とは異なるプロジェクション メトリクスを使用してメモリベースのスケーリングを評価します。System Memory Utilization が低く表示されてもスケールダウンが発生しない場合は、 MongoDBサポートにお問い合わせください。
- 分析ノード:
- 過去 24 時間の平均 Normalized System CPU と System Memory Utilization が、クラスターで利用可能なリソースの 50% を下回っている。
注意
M10とM20クラスターは、バースト期間後にクラウドプロバイダーが設定した CPU 使用率の上限を考慮して、より低いしきい値を使用しています。これらのしきい値は、クラウドプロバイダーとクラスター階層によって異なります。
シャーディングされたクラスターの増加
Atlas は、レプリカセットと同じ基準を使用して、シャーディングされたクラスターの階層をオートスケールします。Atlas は、次のルールを適用します。
独立したシャード スケーリングは、オートスケーリング機能を持つシャーディングされたクラスターではデフォルトで有効になっています。独立したシャード スケーリング が有効になっている場合、Atlas のオートスケーリングは各シャードを個別に評価およびスケーリングします。独立したシャードスケーリングでは、可用性とパフォーマンスを維持するために、最小シャードサイズが最大シャードの下の 2 つのクラスター階層より小さくない必要があります。Atlas がこのようなクラスターに対してオートスケーリングをトリガーし、最大のシャードをスケールアップする場合、コンシステントな可用性とパフォーマンスを確保するために必要に応じて小さいシャードもスケールアップします。
シャード内の運用ノードまたは分析ノードがオートスケールの基準を満たす場合、その特定のシャード上の運用ノードまたは分析ノードのみが変更階層になります。
コンフィギュレーションサーバーのレプリカセットはオートスケールされません。ただし、Config シャードはオートスケールされます。
AWS Gen2 専有クラスターの拡大
Atlas は、レプリカセットと同じ基準を使用して、AWS Gen2 専有クラスターのクラスター階層をオートスケールします。Atlas は、次のルールを適用します。
クラスターの現在の階層、最小オートスケーリング境界、および最大オートスケーリング境界は、すべて同じ世代内である必要があります。
M10また、M20クラスターは世代に依存しません。Atlas はM10またはM20クラスターを Gen1 または Gen2 クラスターにオートスケールできます。たとえば、最大オートスケーリング境界が Gen1 クラスター階層である場合、Atlas はクラスターを Gen1 にオートスケールします。オートスケーリングの最大境界が AWS Gen2 クラスター階層である場合、Atlas はクラスターを Gen2 にオートスケールします。Gen1 クラスターと Gen2 クラスターの両方で、最小オートスケーリング境界として
M10またはM20を使用することもできます。
重要
クラスターの世代切り替え時のオートスケーリング境界
クラスターのオートスケーリング境界は、そのクラスターと同じ世代に属している必要があります。
M10 また、M20 クラスターは世代に依存しません。オートスケーリングの境界は任意の世代に設定でき、M10 および M20 クラスターを任意のクラスター世代のオートスケーリング境界として使用できます。
次のいずれかを行おうとすると、Atlas Administration API は INVALID_ATTRIBUTE エラーを返します。
クラスターの世代を、そのクラスターのオートスケーリング境界の世代とは異なる世代に変更します。
クラスターのオートスケーリングの境界を、そのクラスターとは異なる世代に属する
M30+階層クラスターに設定します。
クラスター階層の予測オートスケーリング
予測型オートスケーリングは、オートスケーリングの拡張機能です。
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 はリアクティブなオートスケーリングに依存します。
Atlas によるクラスター ストレージの増加方法
Atlas では、クラスター ストレージのオートスケーリングがデフォルトで有効になります。 Atlas では、クラスター内の任意のノードで使用済みディスク容量が90 % に達すると、クラスター ストレージが自動的に増加します。
クラスター ストレージのスケーリングをオプトアウトするには、Auto-scale セクションの Storage Scaling チェックボックスをオフにします。
次の考慮事項が適用されます。
Atlas はクラスター ストレージのみをオートスケールします。クラスターの編集ページからのクラスターストレージの手動削減が可能です。
AWS、 Azure、 GCPクラスターでは、Atlas はクラスターのストレージキャパシティーを増やして、ディスク領域の70 % が使用可能になります。詳細については、 「 AWSのストレージ容量または IOPS の変更 」、 「 Azureのストレージ容量と IOPS の変更 」、および「 Google Cloud のストレージ容量の変更 」を参照してください。
クラスターを増やす予定の場合は、高速な書き込みアクティビティを避けます。 クラスターをより大きなストレージ キャパシティーにスケールアップするには、データを準備して新しいディスクにコピーするのに十分な時間が必要です。 クラスターが一括挿入などの高速書込みアクティビティを大量に受信した場合、ディスク ストレージ容量が一時的に急増し、オートスケーリングが実行されない可能性があります。 ディスク ストレージが実行中のリスクを軽減するには、一括挿入やインスタンスの高速書込みアクティビティの前にクラスターを増やすを計画します。
ベースノードに 1 つのクラスター階層クラスを指定し、分析ノードに別のクラスター階層クラスを指定すると、Atlas はディスクの自動スケーリングを無効にします。たとえば、Base Tier で運用ノードに General クラスタークラスを指定し、Analytics Tier で分析ノードに Low-CPU クラスタークラスを指定すると、Atlas は次のエラーメッセージを表示してディスクのオートスケーリングを無効にします:
Disk auto-scaling is not yet available for clusters with mixed instance classes。ディスクのオートスケーリングがトリガーされると、後続のディスクのオートスケーリングと手動ディスク拡大が数時間利用できなくなることがあります。
クラスター階層とクラスター ストレージは並行して拡張される可能性があります
Atlas がオートスケーリングの一環としてクラスターのストレージキャパシティーを自動的に増やすしようとすると、現在のクラスター階層がサポートする範囲外でストレージを増やす必要がある場合があります。クラスターでダウンタイムが発生しないよう、Atlas はクラスター階層（クラスターストレージに加えて）を新しいストレージキャパシティーに対応するように増やします。
注意
オートスケーリングイベントでは、現在の階層に必要なストレージキャパシティーがない場合、Cluster Tier Scaling が無効になっていても、Atlas はクラスター層を増加させる可能性があります。
Azureでは、拡張ストレージ/IOPS をサポートするリージョンの 1 つに配置されたクラスターでオートスケーリングが有効になっており、現在の IOPS がオートスケーリング ディスク サイズのデフォルトIOPS より小さい場合、Atlas は 割り当て数を増加させます。IOPS は、IOPS スライダーの に表示され、 UIの で通知されます。詳しくは、Azureで拡張ストレージ/IOPS を構成する を参照してください。
例
M30 クラスターの最大ストレージキャパシティーは 480 GBです。最大ストレージが割り当てられている M30 クラスターがあり、使用済みディスク容量が 90% に達した場合、ストレージのオートスケーリングイベント、ストレージキャパシティーを600 GBに増やす必要があります。この場合、Atlas ではクラスター階層が M40 までスケールアップされます。これは、必要な新しいストレージキャパシティーをサポートできる最低のクラスター階層だからです。Azureでは、拡張ストレージ/IOPS をサポートするリージョンの 1 つにクラスターを配置した場合、Atlas はその階層のクラスターの IOPS レベルに一致するように IOPS も自動的に増加します。詳しくは、Azureで拡張ストレージ/IOPS を構成する を参照してください。
指定した最大クラスター階層が新しいストレージ容量をサポートできない場合、Atlas は次の処理を実行します。
お使いの最大クラスター階層を、新しいストレージ容量に対応できる次に低い階層まで引き上げます。
クラスター階層をその新しい最大階層に増やします。
注意
Atlas が最大クラスター階層を上書きすると、クラスターの自動スケールダウンも無効になります。下方オートスケーリングを再度有効にするには、クラスター設定で構成してください。「 クラスター階層の下方拡大に関する考慮事項 」も参照してください。
Atlas がクラスター階層のスケールダウンを試み、対象の階層が現在のディスク容量、プロビジョニングされた IOPS、またはその両方をサポートできない場合、Atlas はクラスターをスケールダウンしません。この場合、Atlas は現在のクラスター階層と構成済みの最大クラスター階層との関係に基づいて、オートスケーリング設定を更新します。
クラスターが現在構成されている最大クラスター階層にある場合、すべての小さい層が必要なストレージ設定に対応できないため、Atlas はクラスターの自動スケールダウンを無効にします。下方オートスケーリングを再度有効にする場合は、クラスター設定から手動で有効にする必要があります。
クラスターが現在設定されている最大クラスター階層にない場合、Atlasは最小クラスター階層を現在のクラスター階層まで引き上げます。この場合、Atlas は下方オートスケーリングを無効にしません。
このオートスケーリング ロジックにより、ストレージ設定がワークロードと一致しない場合でも、ダウンタイムを軽減できます。
oplog に関する考慮事項
ストレージのオートスケーリングを使用するかどうかに応じて、Atlas は oplog の最小保持ウィンドウまたは oplog サイズに基づいて oplog エントリを管理します。詳しくは、「Oplog サイズの動作」を参照してください。Atlas では、ストレージのオートスケーリングはデフォルトで有効になっています。
クラスター階層の下方拡大に関する考慮事項
クラスターの編集ページから、クラスター階層を手動で削減できます。クラスター層を 手動で増やすダウン する場合は、次の考慮事項が適用されます。
配置のワークロードの範囲を見積もり、Minimum Cluster Size の値を、配置のワークロードを処理するのに十分なキャパシティーがあるクラスター階層に設定します。クラスターの活動が急上昇または急降下する可能性を考慮する必要があります。
M10より小さいクラスター階層にはスケールできません。クラスターの現在のディスク構成より低い最小クラスター階層は選択できません。最小クラスター階層でサポートされる範囲を超えてストレージが増加し、最小クラスター階層がサポートする範囲を超えてクラスターのストレージ構成が増加した場合、Atlas はクラスターが現在のストレージ要件に対応できるよう、最小クラスター階層を自動的に調整します。
例
自動スケーリング範囲を
M20〜M60に設定しました。現在のクラスター階層はM40で、ディスク容量は 200 GB です。現在のディスク使用量が 180 GBを超えており、これが 200 GB キャパシティーの 90% を超えているため、Atlas はディスクのオートスケーリングイベントをトリガーしてキャパシティーを 320 GB に増やします。Atlas は、次のアクションを実行します。
使用している最小クラスター階層を、新しいストレージ容量に対応できる次に低い階層である
M30まで引き上げる。M20はストレージ容量最大 256 GB まで対応しているため、有効なオートスケーリングの限界ではなくなる。現在のインスタンスサイズ
M40が新しいディスク構成をサポートしているかどうかを決定します。ディスクのオートスケーリングイベントは成功します。
オートスケーリングオプションを構成する
クラスターを作成または変更するときに、オートスケーリング オプションを構成できます。新しいクラスターの場合、Atlas はクラスター層のオートスケーリングとストレージのオートスケーリングを自動的に有効にします。
次のいずれかの操作を実行できます。
クラスターをオートスケーリングするときに Atlas が使用する必要がある上位クラスター階層と下位クラスター階層を確認して調整するか、 または
オートスケーリング の使用をオプトアウトします。
Atlas では、General クラスター階層および Low-CPU クラスター階層のクラスター ビルダーの Auto-scale セクションにオートスケーリング オプションが表示されます。
デフォルトで有効になっているオートスケーリング
新しいクラスターを作成すると、MongoDB Atlas はクラスター層とストレージのオートスケーリング（予測的およびリストレージ）を有効にします。（予測オートスケーリングはクラスター階層にのみ影響し、ストレージには影響しません。）オートスケーリングを明示的に有効にする必要はありません。必要に応じて、クラスター階層とクラスター ストレージをオプトアウトすることもできます。
注意
Atlas では、Atlas UIでクラスターを作成すると、デフォルトでクラスター階層のオートスケーリングが有効になります。API を使用してクラスターを作成する場合、クラスターのオートスケーリングはデフォルトで選択されておらず、1 つのプロジェクトで 1 つのクラスターを更新するエンドポイントのautoScalingオブジェクトのオプションを使用して明示的に有効にする必要があります。
オートスケーリングを有効にすると、クラスターは自動的に次の操作を実行できます。
クラスターとワークロードの適格性に応じて、リアクティブまたは予測的なオートスケーリングのいずれかを使用して、より高いクラスター階層で機能を増やします。
リアクティブなオートスケーリングを使用して、現在のクラスター階層をより低いクラスター階層に減少させます。
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 コマンドで指定します。
Atlas API クラスター updateCluster コマンドを使用して直接 API を呼び出し、既存のクラスターでオートスケーリング設定を有効にします。新しいクラスターを作成する際にオートスケーリングを有効にするには、atlas api clusters createCluster コマンドを使用してください。
ペイロード ファイルを作成します。
次の内容で payload.json ファイルを作成します。プレースホルダー値を、お客様のクラスター構成に合わせた値に置き換えてください。
{ "replicationSpecs": [ { "regionConfigs": [ { "providerName": "{CLOUD-PROVIDER}", "regionName": "{REGION-NAME}", "priority": 7, "electableSpecs": { "instanceSize": "{INSTANCE-SIZE}", "nodeCount": 3 }, "analyticsSpecs": { "instanceSize": "{ANALYTICS-INSTANCE-SIZE}", "nodeCount": 1 }, "autoScaling": { "compute": { "enabled": true, "scaleDownEnabled": true, "minInstanceSize": "{MIN-INSTANCE-SIZE}", "maxInstanceSize": "{MAX-INSTANCE-SIZE}" }, "diskGB": { "enabled": true } }, "analyticsAutoScaling": { "compute": { "enabled": true, "scaleDownEnabled": true, "minInstanceSize": "{MIN-ANALYTICS-INSTANCE-SIZE}", "maxInstanceSize": "{MAX-ANALYTICS-INSTANCE-SIZE}" }, "diskGB": { "enabled": true } } } ] } ] }
リクエスト本文にオートスケーリング構成を指定することで、Atlas Administration API を使用してオートスケーリングを有効化できます。
autoScaling オブジェクトを含めることでオートスケーリングを有効化するには、1 つのプロジェクトに 1 つのクラスターを更新エンドポイントを使用します。
注意
この curl コマンドは、サービス アカウント アクセス トークン（OAuth 2.0）を使用して認証します。詳細については、Atlas 管理APIの使い始める を参照してください。
curl --header "Authorization: Bearer {ACCESS-TOKEN}" \ --header "Accept: application/vnd.atlas.2025-03-12+json" \ --header "Content-Type: application/json" \ --include \ --request PATCH "https://cloud.mongodb.com/api/atlas/v2/groups/{GROUP-ID}/clusters/{CLUSTER-NAME}" \ --data '{ "replicationSpecs": [ { "regionConfigs": [ { "providerName": "{CLOUD-PROVIDER}", "regionName": "{REGION-NAME}", "priority": 7, "electableSpecs": { "instanceSize": "{INSTANCE-SIZE}", "nodeCount": 3 }, "autoScaling": { "compute": { "enabled": true, "scaleDownEnabled": true, "minInstanceSize": "{MIN-INSTANCE-SIZE}", "maxInstanceSize": "{MAX-INSTANCE-SIZE}" }, "diskGB": { "enabled": true } }, "analyticsSpecs": { "instanceSize": "{ANALYTICS-INSTANCE-SIZE}", "nodeCount": 1 }, "analyticsAutoScaling": { "compute": { "enabled": true, "scaleDownEnabled": true, "minInstanceSize": "{MIN-ANALYTICS-INSTANCE-SIZE}", "maxInstanceSize": "{MAX-ANALYTICS-INSTANCE-SIZE}" }, "diskGB": { "enabled": true } } } ] } ] }'
クラスター階層のオートスケーリング オプションを検討する
クラスター階層とストレージに対して有効になっているオートスケーリング オプションを確認するには、次の手順を行います。
クラスター階層のオートスケーリングをオプトアウトする
クラスターのオートスケーリング（クラスター階層の増加）をオプトアウトするには、新しいクラスターを作成するときに、Cluster Tier メニューに移動し、Auto-scale セクションの Cluster Tier Scaling チェックボックスをオフにします。
クラスターのオートスケーリング（クラスター階層の減少）をオプトアウトするには、新しいクラスターを作成するときに、Cluster Tier メニューに移動し、Auto-scale セクションの Allow cluster to be scaled down チェックボックスをオフにします。
オートスケーリング アクティビティフィードを検討する
アクティビティフィードを表示して、各Atlasプロジェクトのイベントを検討できます。オートスケーリングイベントが発生すると、Atlas はそのイベントをプロジェクトActivity Feed にログします。
Atlas では、次の監査するオートスケーリング イベントが使用されます。
アクティビティフィード内の各オートスケーリングイベントには、拡大アクションをトリガーした要因に関する詳細情報が含まれ、次のようなものがあります。
オートスケーリングイベントをトリガーした特定のメトリクス（CPU 使用率、メモリ使用量、ディスク容量など）。
超えたしきい値。
スケーリングがトリガーされたのはリアクティブなオートスケーリング（現在のリソース使用量に応じて）か、予測用オートスケーリング（予測された需要を想定して）か。
オートスケーリング イベントのみを表示またはダウンロードするには、次の手順に従います。
Atlas で、 Project Activity Feed ページに移動します。
まだ表示されていない場合は、希望するプロジェクトを含む組織を選択しますナビゲーション バーのOrganizationsメニュー
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
サイドバーで、Security ヘッダーの下の Activity Feed をクリックします。
プロジェクト アクティビティ フィードページが表示されます。
Terraform の効果的なフィールドによるオートスケーリングの強化
注意
この機能は、M10 階層以上の専有クラスターにのみ適用され、Flex クラスターではサポートされていません。
クラスターでオートスケーリングが有効になっている場合、Atlas はワークロードに基づいてインスタンスサイズとストレージキャパシティーを自動的に調整します。
クラスターインスタンスのサイズ設定とストレージ構成にMongoDB & HashiCorp Terraform を使用する場合、クラスター サイズ値のサブセットに有効なフィールドを指定できます。このアプローチは、次のように推奨されます。
指定属性は、Terraform 構成で定義したとおりに正確に維持されます。
デフォルト値とオートスケール値は効果的な仕様で個別に使用できます（例: 、
effectiveElectableSpecs）。Atlas がクラスターをオートスケールする場合、リソースドリフトは発生しません。構成はクリーンなままで、プロビジョニングの意図を表現しますが、効果的な仕様は Atlas が実現したことの実現を示します。
有効なフィールドは、特定のタイプのオートスケーリングによって管理されているフィールドへの変更のみを無視します。次の表では、有効なフィールドと特定のタイプのオートスケーリングが有効になっている場合に無視されるフィールドの詳細を示しています。
有効なオートスケーリングのタイプ | specs | 無視されたフィールド | ノード タイプ |
|---|---|---|---|
コンピュートまたはストレージ |
|
| |
コンピュートまたはストレージ |
|
| |
分析 |
|
|
検索ノードには有効なフィールドを使用できません。
有効なフィールドの有効化
有効なフィールドを有効にするには、APIリクエストに次のヘッダーを含めます。
--header "Use-Effective-Instance-Fields: true"
次の例に示すように、クラスターのリソース定義で use_effective_fields 引数を true に設定します。
resource "mongodbatlas_advanced_cluster" "this" { project_id = mongodbatlas_project.this.id name = var.cluster_name cluster_type = var.cluster_type use_effective_fields = true replication_specs = var.replication_specs tags = var.tags }
「有効フィールド モジュールの例」を参照してください。
重要
有効なフィールドを有効にしない場合は、オートスケーリングが発生したときにリソースドリフトを防ぐために、 lifecycle.ignore_changes ブロックを手動で構成する必要があります。このアプローチは推奨されません。詳細については、Terraform ドキュメントのオートスケーリングを参照してください。
有効なフィールドの動作
全体的には、効果的なフィールドの動作は次の 3 つのシナリオのいずれかに該当します。
注意
ベストプラクティスとして、効果的なフィールドを有効にすることをお勧めします。
{ "replicationSpecs": [ { "regionConfigs": [ { "analyticsAutoScaling": { "compute": { "maxInstanceSize": "M30", "minInstanceSize": "M10", "enabled": true, "scaleDownEnabled": true }, "diskGB": { "enabled": true } }, "autoScaling": { "compute": { "maxInstanceSize": "M30", "minInstanceSize": "M10", "enabled": true, "scaleDownEnabled": true }, "diskGB": { "enabled": true } }, "effectiveAnalyticsSpecs": { "instanceSize": "M30", "diskIOPS": 3000, "diskSizeGB": 100.0, "ebsVolumeType": "STANDARD", "nodeCount": 0 }, "effectiveElectableSpecs": { "instanceSize": "M30", "diskIOPS": 3000, "diskSizeGB": 100.0, "ebsVolumeType": "STANDARD", "nodeCount": 3 }, "effectiveReadOnlySpecs": { "instanceSize": "M30", "diskIOPS": 3000, "diskSizeGB": 100.0, "ebsVolumeType": "STANDARD", "nodeCount": 0 }, "electableSpecs": { "instanceSize": "M20", "diskSizeGB": 50.0, "nodeCount": 3 }, "priority": 7, "providerName": "AWS", "regionName": "US_EAST_1" } ], "zoneId": "6924a70c67695449ba5625ce", "zoneName": "Zone 1" } ] }
注意
ベストプラクティスとして、効果的なフィールドを有効にすることをお勧めします。
{ "replicationSpecs": [ { "regionConfigs": [ { "effectiveAnalyticsSpecs": { "instanceSize": "M30", "diskIOPS": 3000, "diskSizeGB": 100.0, "ebsVolumeType": "STANDARD", "nodeCount": 0 }, "effectiveElectableSpecs": { "instanceSize": "M30", "diskIOPS": 3000, "diskSizeGB": 100.0, "ebsVolumeType": "STANDARD", "nodeCount": 3 }, "effectiveReadOnlySpecs": { "instanceSize": "M30", "diskIOPS": 3000, "diskSizeGB": 100.0, "ebsVolumeType": "STANDARD", "nodeCount": 0 }, "electableSpecs": { "instanceSize": "M30", "diskSizeGB": 100.0, "nodeCount": 3 }, "priority": 7, "providerName": "AWS", "regionName": "US_EAST_1" } ], "zoneId": "6924a70c67695449ba5625ce", "zoneName": "Zone 1" } ] }
重要
有効なフィールドを有効にしない場合は、オートスケーリングが発生したときにリソースドリフトを防ぐために、 lifecycle.ignore_changes ブロックを手動で構成する必要があります。このアプローチは推奨されません。詳細については、Terraform ドキュメントのオートスケーリングを参照してください。
{ "replicationSpecs": [ { "regionConfigs": [ { "analyticsAutoScaling": { "compute": { "maxInstanceSize": "M30", "minInstanceSize": "M10", "enabled": true, "scaleDownEnabled": true }, "diskGB": { "enabled": true } }, "autoScaling": { "compute": { "maxInstanceSize": "M30", "minInstanceSize": "M10", "enabled": true, "scaleDownEnabled": true }, "diskGB": { "enabled": true } }, "effectiveAnalyticsSpecs": { "instanceSize": "M30", "diskIOPS": 3000, "diskSizeGB": 100.0, "ebsVolumeType": "STANDARD", "nodeCount": 0 }, "effectiveElectableSpecs": { "instanceSize": "M30", "diskIOPS": 3000, "diskSizeGB": 100.0, "ebsVolumeType": "STANDARD", "nodeCount": 3 }, "effectiveReadOnlySpecs": { "instanceSize": "M30", "diskIOPS": 3000, "diskSizeGB": 100.0, "ebsVolumeType": "STANDARD", "nodeCount": 0 }, "analyticsSpecs": { "instanceSize": "M30", "diskIOPS": 3000, "diskSizeGB": 100.0, "ebsVolumeType": "STANDARD", "nodeCount": 0 }, "electableSpecs": { "instanceSize": "M30", "diskIOPS": 3000, "diskSizeGB": 100.0, "ebsVolumeType": "STANDARD", "nodeCount": 3 }, "readOnlySpecs": { "instanceSize": "M30", "diskIOPS": 3000, "diskSizeGB": 100.0, "ebsVolumeType": "STANDARD", "nodeCount": 0 }, "priority": 7, "providerName": "AWS", "regionName": "US_EAST_1" } ], "zoneId": "6924a70c67695449ba5625ce", "zoneName": "Zone 1" } ] }
オートスケーリング イベントのアラートの構成
重要
2024 年 8 月上旬に、Atlas はレガシーのオートスケーリング通知メールを、設定可能なオートスケーリングイベントに置き換えました。デフォルトでは、Atlas はすべてのアラート通知を引き続きプロジェクト所有者に送信します。オートスケーリングアラートの送信をカスタマイズして、アラートの受信者または送信方法を変更できます。
オートスケーリング アクティビティは、 Atlas アラートのサブセットです。
Atlas が オートスケーリング イベント のいずれかをトリガーするたびに、デフォルトのAtlasアラートを受け取ります。
プロジェクトレベルで、一部またはすべてのオートスケーリング イベントについて、 をオプトアウトしたり、アラート構成を変更したりできます。
重要
オートスケーリング アラートは、プロジェクト内のすべてのクラスターに適用されます。特定のクラスターにアラートをスコープ設定することはできません。アラート通知では、クラスター名とIDによってイベントがトリガーされたクラスターが識別されます。
アラート構成を変更するには、Category セクションで [Atlas Auto Scaling] を選択し、リストから [Condition/Metric] を選択します。次に、アラート受信者のロールを変更したり、メールや SMS などの通知方法を変更したり、Slackなどの通知機能を追加したりできます。詳細については、オートスケーリング アラートの構成を参照してください。
Atlas オートスケーリングのMongoDBサポート
質問や心配な場合は、サポートにお問い合わせください 。