Atlas はクラスター コンピュートのオートスケーリングを使用して、クラスター層 を調整することでリソース使用率とコストを最適化します。 Atlas はストレージのオートスケーリングを使用して、 クラスターのストレージキャパシティーを自動的に増やします 。
このセクションでは、次の内容を学習できます。
クラスター階層のオートスケーリング
Atlas は、クラスター階層に対してリアクティブかつ予測的なオートスケーリングを使用します。 Atlas は、クラスターのタイプ、階層、ワークロードパターンに基づいて、オートスケーリング メカニズムを選択します。
リアクティブなオートスケーリング。 Atlas は、現在のリソース使用量に基づいてスケーリング イベントをトリガーするために、予測ではなくしきい値を使用します。リアクティブなオートスケーリングは、リソースの使用率が継続的に高いまたは低い後に発生します。詳細については、「 クラスター階層のリアクティブなオートスケーリング 」を参照してください。
予測可能なオートスケーリング。 Atlas は機械学習を使用して、履歴使用パターンに基づいて将来のスケーリング ニーズを予測し、予測されたワークロードロードの急増が発生する前にスケーリング イベントをトリガーしようとします。
予測的オートスケーリングは、クラスター層のオートスケーリングの拡張機能であり、リアクティブなオートスケーリングにフォールバックします。 Atlas は、定期的に、または予測できないワークロードの予期しない急増を管理するために、リアクティブなオートスケーリングに依存し続けます。 Atlas は、適格なクラスターを予測するオートスケーリングを使用します。詳細については、「 クラスター階層の予測オートスケーリング 」を参照してください。
クラスター層のリアクティブなオートスケーリング
注意
オートスケーリングタームの使用
Atlas のすべてのドキュメントでは、「予測」という単語なしでオートスケーリングタームが使用されている場合は常に、リアクティブなオートスケーリング メカニズムを指します。 「 予測オートスケーリング 」も参照してください。
Atlas が使用するクラスター階層範囲を構成して、クラスターの使用状況に応じてクラスター階層、ストレージ容量、またはその両方をオートスケーリングできます。
リソース使用率を最適化し、コストプロファイルを改善するため、Atlas のリアクティブなオートスケーリングにより、持続的な高い需要と短期間のピーク トラフィックを検出し、リアルタイムのリソース使用量に基づいてクラスター層を調整します。
コストを管理しやすくするために、クラスターが自動的に増やすことができる最大クラスターサイズと最小クラスターサイズの範囲を指定できます。
リアクティブなオートスケーリングは順次動作するため、プロセスによるダウンタイムは発生しません。 Atlas はこのプロセス中にプライマリノードを維持しますが、ノードは 1 つずつアップグレードされ、アップグレード中は使用できなくなります。
リアクティブなオートスケーリングを備えたコード ツールとしてインフラストラクチャを使用する場合のリソースドリフトの回避など、スケーラビリティに関する推奨事項については、Atlas アーキテクチャ センターの「 Atlas スケーラビリティに関する推奨事項 」を参照してください。
リアクティブなオートスケーリングに適したクラスター
Atlasクラスター層のリアクティブなオートスケーリングは、General Low-CPUクラスター クラスおよび クラスター クラス配下にあるすべての専有クラスター階層で利用できます。
Atlas によるクラスター階層の増加方法
注意
階層の可用性
リアクティブなオートスケーリングは、 クラスと クラスのクラスター階層では機能しますが、General Low-CPULocal NVMe SSDクラスのクラスターでは機能しません 。
Atlas は次のクラスターメトリクスを分析して、クラスターをリアクティブにスケーリングする増やすと、クラスター層を増やすか、または減らすかを決定します。
Normalized System CPU 使用率
システムメモリ使用率
Atlas は、使用可能なノードメモリと合計メモリに基づいて、次のようにシステムメモリ使用率を計算します。
(memoryTotal - (memoryFree + memoryBuffers + memoryCached)) / (memoryTotal) * 100
前の計算では、memoryFree、memoryBuffers、および memoryCached は、Atlas が他の目的で再利用できる使用可能なメモリの量です。詳しくは、「利用可能なメトリクスを確認する」の System Memory を参照してください。
新しいクラスター階層が指定した Minimum と Maximum Cluster Size の範囲から外れる場合、Atlas はクラスター階層をスケーリングしません。
Atlas では、クラスターを同じクラスにある別の階層にスケーリングします。たとえば、Atlas は General クラスターを他の General クラスタークラスにスケーリングしますが、General クラスターを Low-CPU クラスタークラスにスケーリングしません。
適切なクラスターリソースの使用率を確保するために、正確なリアクティブ オートスケーリング基準は変更される可能性があります。
重要
また、移行中に、宛先クラスターのストレージ容量よりも大きいサイズのスナップショットを復元すると、クラスターはオートスケーリングされません。
もし読み取り専用ノードを配置しており、クラスターのスケールを速めたい場合は、レプリカセットのスケーリングモードを調整することを検討してください。
クラスター層をリアクティブにスケールアップする
アプリケーションの動的ワークロードを管理するために、Atlas はこのセクションに記載されている条件下でクラスター内のノードをリアクティブにスケールアップします。
次のクラスター層がMaximum Cluster Size 範囲内にある場合、このタイプの任意のクラスター ノードに対して次の条件の少なくとも 1 つが当てはまる場合、Atlas はクラスター内の稼働ノードを次の層までスケールアップします。
注意
次のリストは、CPU 関連の基準をグループ化し、その後にメモリ関連の基準を続けて示します。各グループ内では、基準は最も制限の厳しいものから最も緩やかなものの順に表示され、特定のクラウドプロバイダーの基準が存在する場合は最初に表示されます。
M10およびM20クラスター:AWS。正規化されたシステム CPU の相対使用率の平均が過去 20 分間で 90% を超え、正規化されていないシステム CPU の絶対使用率の平均が、CPU スティールにおいて過去 3 分間で 30% を超えています。
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% を超えています。
M30+クラスター:平均 System CPU Utilization が過去 10 分間にクラスターで利用可能なリソースの 90% を超えました。
過去 1 時間の平均 System CPU Utilization が、クラスターで使用可能なリソースの 75% を超えています。
平均 System Memory Utilization が過去 10 分間にクラスターで利用可能なリソースの 90% を超えました。
過去 1 時間の平均 System Memory Utilization が、クラスターで使用可能なリソースの 75% を超えています。
これらのしきい値により、クラスターは高負荷に対応して迅速にスケールアップし、アプリケーションはトラフィックや使用量の急増に対応しながら、パフォーマンスと信頼性を維持できます。
注意
このセクションの条件は、オペレーショナルノードについて説明しています。任意のクラウドプロバイダーの分析ノードの場合、正規化された System CPU Utilization の平均または System Memory Utilization が、過去 1 時間にクラスターノードで利用可能なリソースの 75% を超えた場合、Atlas はそれらを次の層にスケールアップします。
最適なリソース利用とコストプロファイルを達成するために、Atlas は次の条件が満たされる場合にクラスターを次の階層にスケールアップすることを避けます。
M10またはM20クラスターが、過去 20 分または 1 時間（しきい値による）以内にスケールアップされた。M30+クラスターが、過去 10 分または 1 時間（しきい値による）以内にスケールアップされた。
たとえば、12:00 以降クラスター階層が変更されていない場合、クラスターの現在の正規化されたシステム CPU 使用率が 90% を超えると、Atlas は M30+ クラスターを 12:10 にスケールアップします。
重要
ワークロードの急増
より大きなクラスター階層にスケールアップするには、バッキングリソースを準備するのに十分な時間が必要です。クラスターが一括挿入などのアクティビティのバーストを受け取った場合、オートスケーリングが実行されない可能性があります。リソース不足のリスクを軽減するには、一括挿入やその他のワークロードの急増が発生する前にクラスターのスケールアップを計画します。
クラスター層のリアクティブなスケールダウン
コストを最適化するために、Atlas はこのセクションに記載されている条件下でクラスター内のノードをリアクティブにスケールダウンします。
次に低いクラスター階層が Minimum Cluster Size の範囲内にある場合、Atlas は、指定されたクラスタータイプのすべてのノードに対して次の条件のすべてが当てはまる場合、クラスター内のノードを次の最も低い層にスケールダウンします。
すべてのノード:
Atlas は過去 24 時間以内にクラスターを（手動または自動で）スケールダウンしていません。
Atlas は過去24時間にクラスターをプロビジョニングまたは一時停止解除していません。
Atlas で過去 12 時間でクラスター ノードを停止して再起動したことはありません。
正規化された System CPU Utilization の平均値は、少なくとも過去 10 分および過去 4 時間にわたって、クラスターで使用可能なリソースの 45% を下回っています。Atlas は、CPU 負荷が観測されたレベルに安定したことを示す指標として、「4 時間平均」チェックポイントを使用します。Atlas は、Atlas が「4 時間平均」チェックポイントで捉えられなかった最近の CPU スパイクが発生していないことを示す指標として、「10 分平均」チェックポイントを使用します。
WiredTiger のキャッシュ 使用量の平均が、現在の クラスター階層サイズで直近の 10 分および 4 時間で、WiredTiger の最大キャッシュサイズの 90% を下回っている。これは、現在のクラスターが過負荷になっていないことを Atlas に示します。
新しい下位クラスター階層での予測される合計システムメモリ使用率が、少なくとも過去 10 分間および過去 4 時間で 60% を下回っている。Atlas は、上述の予測される合計メモリ使用率を次のように計算します。
Atlas は、現在のメモリ使用率を測定し、現在の WiredTiger キャッシュ使用量を新しい下位階層クラスターの WiredTiger キャッシュサイズの 80% に置き換えます。
次に、Atlas は、予測される合計メモリ使用量が新しい階層サイズで少なくとも過去 4 時間および少なくとも過去 10 分間、60% を下回っているかどうかを確認します。
注意
Atlas はメモリ計算に WiredTiger キャッシュを含めて、クラスターが完全なキャッシュを持っているものの、それ以外の場合にトラフィックが少なければ、スケールダウンする可能性を高くします。つまり、Atlas はWiredTiger キャッシュのサイズを検査して、クラスターの WiredTiger キャッシュがクラスターの最大 WiredTiger キャッシュサイズの 90% に達する可能性があり、それ以外の状況では Normalized System CPU 使用率が低いアイドルクラスターは、安全にダウンスケールできると判断します。
これらの条件により、Atlas はクラスター内の稼働中のノードをスケールダウンして、高使用率の状態を防ぐことができます。
過去 24 時間の平均 Normalized System CPU Utilization と System Memory Utilization が、クラスターで利用可能なリソースの 50% を下回っている。
注意
M10とM20クラスターは、バースト期間後にクラウドプロバイダーが設定した CPU 使用率の上限を考慮して、より低いしきい値を使用しています。これらのしきい値は、クラウドプロバイダーとクラスター階層によって異なります。
シャーディングされたクラスターの増加
Atlas は、レプリカセットと同じ基準を使用して、シャーディングされたクラスターの階層をオートスケールします。Atlas は、次のルールを適用します。
独立したシャード スケーリング が有効になっているクラスターの場合、Atlas のオートスケーリングは各シャードを個別に評価およびスケーリングします。独立したシャードスケーリングでは、可用性とパフォーマンスを維持するために、最小シャードサイズが最大シャードの下の 2 つのクラスター階層より小さくない必要があります。 Atlas がこのようなクラスターに対してオートスケーリングをトリガーし、最大のシャードをスケールアップする場合、一貫した可用性とパフォーマンスを確保するために必要に応じて小さいシャードもスケールアップします。
シャード内の運用ノードまたは分析ノードがオートスケールの基準を満たす場合、その特定のシャード上の運用ノードまたは分析ノードのみが変更階層になります。
Config サーバーのレプリカセットはオートスケールされない。
クラスター内のシャードを独立してスケーリングするためのAPI
バージョン管理された Atlas Administration API の API リソース バージョン 2024-08-05 では、各シャードのクラスター階層を個別にスケーリングできます。この API バージョンは、Atlas クラスターの基礎にあるスケーリングモデルに対する重要な変更です。
警告
API バージョン 2024-08-05 は重大な変更です。新しい API を使用してクラスター内のシャードを非対称に記述するリクエストを送信すると、以前の対称専用 API は、そのクラスターで利用できなくなります。以前の API バージョンに戻るには、まずすべてのシャードが同じ階層で動作するようにクラスターを再構成してください。
新しい API は、非対称クラスターを記述できます。replicationSpec.numShards フィールドは、新しい API スキーマには存在しません。その代わりに、すべてのシャードが同一に構成されている対称クラスターであっても、各シャードは個別の replicationSpec によって指定されます。
クラスター層の予測オートスケーリング
予測型オートスケーリングは、オートスケーリングの拡張機能です。
Atlas はホストリソース使用率に 需要予測 を使用し、クラスター コンピュートの事前スケールアップを実行して最適なリソース使用率を確保します。予測可能なオートスケーリングにより、Atlas は定期的なワークロードの急増が発生する前に、クラスターのプロアクティブな増やすアップを試みます。
予測的なオートスケーリングは、履歴パターンに基づく機械学習モデルによって強化されます。モデルが高いリソース使用率を予測する場合、Atlas はクラスターをスケールアップします。 MongoDB は、Atlas のパフォーマンスを最適化するために、モデルとその基準を継続的に更新します。
予測的オートスケーリングには、予測的かつ定期的なワークロードを持つクラスターに対して次のメリットがあります。
定期的なワークワークロードパターン（毎日または毎週ごとのスパイクなど）のクラスターを自動的に増やすアップします。
予測可能な高負荷期間中に一貫したパフォーマンスと可用性を維持します。
Atlas の管理キャパシティーが増加することで、手動スケーリング タスクまたはスケジュールされたスクリプトを削減します。
クラスターのワークロードへの変更が予測可能なパターンの範囲外で、非定期的または予測できない場合は、リアクティブなオートスケーリングにシームレスにフォールバックします。
予測オートスケーリングの動作
次のステートメントは、予測型オートスケーリングの仕組みを説明しています。
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 では、Base Tier ノードと Analytics Tier ノードを異なるクラウドプロバイダーのリージョンを配置すると、ディスクリアクティブのオートスケーリングが無効になります。
クラスター階層とクラスター ストレージは並行して拡張される可能性があります
Atlas がオートスケーリングの一環としてクラスターのストレージキャパシティーを自動的に増やすしようとすると、現在のクラスター層がサポートする範囲外でストレージを増やす必要がある場合があります。クラスターでダウンタイムが発生しないよう、Atlas はクラスター層（ クラスターストレージに加えて）を新しいストレージキャパシティーに対応するようにスケーリングします。
Azure 上で、拡張ストレージをサポートするリージョンの 1 つにデプロイされたクラスターで自動スケーリングを有効にし、現在の IOPS が自動スケーリングされたディスクサイズにおいてデフォルトの IOPS よりも低い場合、Atlas は IOPS スライダーで割り当てられた IOPS 数を増やし、UI 上でお知らせします。詳細については、ストレージ容量と IOPS の Azure での変更を参照してください。
例
M30クラスターの最大ストレージ容量は480 GB です。 最大ストレージが割り当てられているM30クラスターがあり、使用済みディスク容量が90 % に達した場合、ストレージのオートスケーリング イベントにより、ストレージ容量を600 GB に増やす必要があります。 この場合、Atlas ではクラスター階層がM40までスケールアップされます。これは、必要な新しいストレージ容量をサポートできる最低のクラスター階層だからです。 Azure では、 拡張ストレージ をサポートするリージョン の 1 つにクラスターを配置した場合、Atlas は、その階層のクラスターの IOPS レベルと一致するように IOPS も自動的に増加します。
指定した最大クラスター階層が新しいストレージ容量をサポートできない場合、Atlas は次の処理を実行します。
お使いの最大クラスター階層を、新しいストレージ容量に対応できる次に低い階層まで引き上げます。
クラスター階層をその新しい最大階層に増やします。
注意
Atlas が最大クラスター階層を上書きすると、クラスターの自動スケールダウンも無効になります。下方オートスケーリングを再度有効にするには、クラスター設定で構成してください。「クラスター階層とストレージの下方オートスケーリングに関する考慮事項」も参照してください。
Atlas がクラスター階層のスケールダウンを試み、ターゲット層が現在のディスク容量、プロビジョニングされた IOPS、またはその両方をサポートできない場合、Atlas ではクラスターがスケールダウンされません。このシナリオでは、Atlas で、現在のクラスター階層と構成済みの最大クラスター階層との関係に基づいてオートスケーリング設定が更新されます。
クラスターが現在構成されている最大クラスター階層にある場合、すべての小さい層が必要なストレージ設定に対応できないため、Atlas はクラスターの自動スケールダウンを無効にします。下方オートスケーリングを再度有効にする場合は、クラスター設定から手動で有効にする必要があります。
クラスターが現在設定されている最大クラスター階層にない場合、Atlasは最小クラスター階層を現在のクラスター階層まで引き上げます。この場合、Atlas は下方オートスケーリングを無効にしません。
このオートスケーリング ロジックにより、ストレージ設定がワークロードと一致しない場合でも、ダウンタイムを軽減できます。
oplog に関する考慮事項
ストレージのオートスケーリングを使用するかどうかに応じて、Atlas は oplog の最小保持ウィンドウまたは oplog サイズに基づいて oplog エントリを管理します。詳しくは、「Oplog サイズの動作」を参照してください。Atlas では、ストレージのオートスケーリングはデフォルトで有効になっています。
クラスター階層とストレージの下方オートスケーリングに関する考慮事項
MongoDB 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 は予測可能なオートスケーリングを使用する場合があります。
クラスター階層のオートスケーリング オプションを検討する
クラスター階層とストレージに対して有効になっているオートスケーリング オプションを確認するには、次の手順を行います。
選択した Auto-Scale チェックボックスで、Maximum Cluster Size と Minimum Cluster Size の値を確認し、必要に応じて調整します。
新しいクラスターを作成するときにデフォルトでチェックされる Allow cluster to be scaled down オプションを確認してください。
デフォルトでチェックされている Storage Scaling チェックボックスの下のオプションを確認します。
クラスター階層のオートスケーリングをオプトアウトする
クラスターのオートスケーリング（クラスター階層の増加）をオプトアウトするには、新しいクラスターを作成するときに、Cluster Tier メニューに移動し、Auto-scale セクションの Cluster Tier Scaling チェックボックスをオフにします。
クラスターのオートスケーリング（クラスター階層の減少）をオプトアウトするには、新しいクラスターを作成するときに、Cluster Tier メニューに移動し、Auto-scale セクションの Allow cluster to be scaled down チェックボックスをオフにします。
オートスケーリング アクティビティ フィードの確認
アクティビティ フィード を表示して、各 Atlasプロジェクトのイベントを確認できます。オートスケーリングイベントが発生すると、Atlas はそのイベントをプロジェクトActivity Feed に記録します。
Atlas では、次の監査するオートスケーリング イベントが使用されます。
オートスケーリング イベントのみを表示またはダウンロードするには、次の手順に従います。
Atlas で、 Project Activity Feed ページに移動します。
まだ表示されていない場合は、希望するプロジェクトを含む組織を選択しますナビゲーション バーのOrganizationsメニュー
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
ナビゲーション バーの Activity Feed & Alerts アイコンをクリックします。
Project ヘッダーの下の Activity Feed をクリックします。
プロジェクト アクティビティ フィードページが表示されます。
Activity Feedで、 Filter by event(s)メニューをクリックし、 Atlasを確認します。
リストの上の検索ボックスに、「
auto-scaling」と入力し始めます。メニューの右側には、すべてのオートスケーリング イベントが表示されます。 表示されたくないものの選択を解除します。 フィードリストは、変更を加えるたびに自動的に更新されます。
オートスケーリング イベントのアラートの構成
重要
2024 年 8 月上旬に、Atlas はレガシーのオートスケーリング通知メールを、設定可能なオートスケーリングイベントに置き換えました。デフォルトでは、Atlas はすべてのアラート通知を引き続きプロジェクト所有者に送信します。オートスケーリングアラートの送信をカスタマイズして、アラートの受信者または送信方法を変更できます。
オートスケーリング アクティビティは、 Atlas アラートのサブセットです。
Atlas がオートスケーリング イベントのいずれかをトリガーするたびに、デフォルトのAtlas アラートが受け取ります。
プロジェクトレベルで、一部またはすべてのオートスケーリング イベントについて、 をオプトアウトしたり、アラート構成を変更したりできます。
アラート構成を変更するには、Category セクションでAtlas Auto Scaling []Condition/Metric を選択し、リストから [] を選択します。次に、アラート受信者のロールを変更したり、メールや SMS などの通知方法を変更したり、 Slackなどの通知機能を追加したりできます。詳細については、「 オートスケーリング アラートの構成 」を参照してください。
Atlas オートスケーリングのMongoDBサポート
質問や心配な場合は、 サポートにお問い合わせください 。