Atlas Core クラスター ストレージをカスタマイズ

低 CPU クラス

一般的に、Low CPU オプションは、より多くのメモリとより少ない CPU を必要とするアプリケーションに対して、より低コストの代替手段を提供します。このオプションには、同じ階層の General オプションを持つインスタンスの vCPU の半分が含まれます。たとえば、General M40 インスタンスには 4 つの vCPU が含まれ、Low CPU M40 インスタンスには 2 つの vCPU が含まれています。クラスター階層によっては、このオプションでは最大接続数を少なくすることもできます。詳細については、「接続制限とクラスター階層」を参照してください。

NVMeストレージ

Local NVMe SSDAWSまたはAzure上で実行される一部の専用クラスターに対して、 ストレージオプションを選択できます。ローカルに接続されたエフェメラル NVMe SSD は、最高レベルの速度とパフォーマンスを提供します。 Atlas は NVMe クラスターのストレージをギガバイト（GB）単位でプロビジョニングします。

Atlas Core クラスターでは、最初の同期が必要な場合はいつでも、 ファイル コピー ベースの最初の同期 を使用して NVME クラスターのすべてのノードを同期します。

oplog サイズの動作

Atlas は、クラスターのデータベースエディションに応じて、クラスターのoplogサイズ とそのエントリを異なる方法で管理します。

• Atlas Infinite クラスターでは、Atlas はoplog をストレージレイヤーに保存し、Atlas Coreストレージのオートスケーリングは クラスターストレージ を管理しません。詳細については、「 Atlas Infinite クラスターの Oplog 」を参照してください。

• Atlas Core クラスターでは、 oplog管理は、クラスターのストレージオートスケーリングが有効になっているかどうかによって異なります。

  • Atlas では、クラスター ストレージのオートスケーリングがデフォルトで有効になります。ストレージのオートスケーリングを使用する場合、Atlas は oplog の最小保持ウィンドウ（oplogMinRetentionHours）設定に基づいて oplog エントリを管理します。oplog エントリにはタイムスタンプが付けられます。oplog window は、oplog 内の最新のタイムスタンプと最も古いタイムスタンプの間の時間差です。

    デフォルトでは、Atlas は oplog の最小保持ウィンドウを 24 時間に設定します。 つまり、oplog の最小保持ウィンドウを特定のカスタム値に設定しない限り、Atlas クラスターの mongod は、oplog が MongoDB のベストプラクティスで許可される最大サイズに達するまで、すべての oplog エントリを少なくとも 24 時間保持します。

    Atlas UIで、 oplog の最小保持ウィンドウ を特定の値に設定できます。ストレージオートスケーリングを正常に完了するには、Atlas ではoplog の最小保持ウィンドウ（oplogMinRetentionHours） が最大（60 秒） * （構成されたディスク容量のGB ）必要です。

    クラスターのストレージ容量が減少すると、Atlas は oplog サイズを自動的にスケールダウンして、減少したストレージ サイズに収まるようにします。

    注意

    移行などの一部の大量一括書き込みシナリオでは、クラスターが構成された最小の oplog 保持ウィンドウを維持できない場合があります。移行とその他の書き込み集中型操作をそれに応じて計画します。

  • Auto-scale セクションの Storage Scaling チェックボックスをオフにすることで、クラスターストレージのオートスケーリングをオプトアウトできます。ストレージのオートスケーリングをオプトアウトする場合、Atlas はoplogサイズを次のように管理します。

    • UI で oplog サイズを指定しない場合、Atlas は oplog サイズを次のように設定します。

      • General および Low-CPU クラスターの場合、クラスター作成時のディスク サイズの 5%

      • NVMeストレージを備えたクラスターのディスク サイズの 10%。

      EBS（非NVMe）ストレージを使用する専有クラスターの場合、ストレージサイズを変更すると、Atlas は新しいディスクサイズに合わせて oplog サイズを自動的に調整します。NVMeストレージを備えたクラスターでは、NVMeストレージを個別にサイズ変更できないため、oplog サイズはディスクサイズではなくインスタンスサイズに関連付けられます。クラスターの階層を変更すると、Atlas は oplog サイズを新しいインスタンスサイズと自動的に同期します。

    • クラスターのストレージをスケールアップするときに、oplog サイズをスケールアップすることもできます。この場合、クラスターを作成する際に、oplog サイズを特定の値に手動で設定します。クラスターのストレージを増やすと、Atlas は自動的に oplog サイズを次のようにスケーリングします。

      • General および Low-CPU クラスターの場合、oplog サイズはストレージ容量の 5% に留まるようにスケールアップされ、MongoDB のベストプラクティスに従って決定された特定の最大値を超えません。

      • NVMeストレージを使用するクラスターの場合、oplog サイズはストレージ容量の 10% に留まり、MongoDB のベストプラクティスに従って決定された特定の最大値を超えないようにスケールアップされます。

    • クラスターのストレージを増やすダウンすると、Atlas は以前の oplog とディスクの比率を使用して、 oplogを比例的に増やすダウンします。 例、 oplogが25 GB （ 0.25の比率）を使用して100 GBから50 GBに増やすすると、新しいoplogサイズの比率も0.25になり、次のようになります12.5 GB. ただし、新しいoplogサイズがストレージキャパシティーの5 % 未満（またはNVMeストレージの場合は10 % 未満）の場合を除きます。 その場合、Atlas はoplogサイズに大きい値を使用します。これはストレージキャパシティーの5 %（ NVMeストレージの場合は10 %）になります。

また、 oplog は各エディションによって異なる方法でオートスケーリングに影響します。

• Atlas Core クラスターでは、 oplog ウィンドウ が推定されるスケーリング時間をカバーするまで、Atlas はオートスケーリングイベントを遅延させます。ウィンドウがスケーリングをブロックしないようにするには、最小oplog保持ウィンドウを設定します。

• Atlas Infinite クラスターでは、 oplog の最小保持ウィンドウはオートスケーリングに影響しません。詳細については、「 Atlas Infinite クラスターの Oplog 」を参照してください。

AWS のストレージ容量または IOPS を変更する

Atlas は、 AWS上のストレージキャパシティーまたはストレージスループット（ IOPS ）を増やすか減らすかに応じて、変更を異なる方法で処理します。

Change Storage Capacity and IOPS on Azure

Azureに配置されたLow CPUまたはGeneralクラスターの場合、Atlas UI でIOPSとデータ ボリュームのストレージ容量を拡張できます。

Low CPUまたはGeneralクラスターのディスク ストレージを増やすと、次のことが可能になります。

• 同じクラスター層内のクラスターでより多くの IOPS を受信します。

• これらのクラスターは、シャーディングを構成してアプリケーションのワークロードをサーバー全体に分散する必要なく、高い IO ワークロード要件を持つアプリケーションをホストする場合に使用します。

Azure にはボリューム変更のクールダウン期間があり、ストレージ変更を行う頻度が制限される可能性があります。

次のステートメントでは、 Azure クラスターでの IOPS およびストレージ管理のために Atlas UI にあるオプションについて説明します。

1. 最初にAzureLow CPU またはGeneral クラスターを選択すると、Atlas は選択した階層に基づいてデフォルトのストレージサイズと IOPS を割り当てます。

2. リージョンで使用されているストレージ ボリュームの特定の特性と、クラスターが拡張ストレージ をサポートするリージョンにあるかどうかに応じて、次のいずれかのアクションを実行できます。

   • リージョンが拡張ストレージ をサポートしていない場合、ストレージ容量は事前に設定された量のみ変更でき、スライダーを使用して IOPS を変更することはできません。

   • リージョンが 拡張ストレージ をサポートしている場合は、Storage スライダーを使用して同じ階層内のデフォルトのストレージキャパシティーを増やすことができます。 Atlas は、ストレージサイズの増加に対応するように IOPS も増加させます。

3. ストレージボリュームのサイズを増やしても IOPS の増加数は依然として十分ではなく、クラスターの階層が IOPS拡張ストレージをサポートするリージョンにある場合は、 スライダーを使用して IOPS の数をさらに拡張できます。クラスター層 の変更。

4. さらに、拡張ストレージ をサポートするリージョンでは、クラスター階層のデフォルト制限を超えてクラスターの合計ストレージを拡張することもできます。 プロジェクト設定 で拡張ストレージ サイズを有効にします。

次のセクションでは、ストレージ サイズとIOPSを増やす方法について説明します。

• Azureのデータ ボリューム サイズを変更する

• Azureで拡張ストレージ/IOPS を構成する

Google Cloud のストレージ容量の変更

Google Cloud Platform は、次の条件を満たすクラスターの拡張ストレージをサポートしています。

• クラスターは Atlas Core クラスターです。

• クラスターはGeneralまたはLow-CPUクラスのいずれかです

• クラスターは単一リージョンです。拡張ストレージは、マルチリージョンクラスターでは利用できません。

• 拡張ストレージは、次の制限があるM40階層以上のクラスターで使用できます。

  • M40：最大 4TB

  • M50/M60: 最大 8TB

  • M80+：最大 14TB

  クラスターの階層を変更するには、「 Atlas Core クラスターの変更 」を参照してください。

拡張ストレージを有効にすると、最初の同期とプロジェクト間のスナップショット復元が遅くなり、高可用性が低下する可能性があります。拡張ストレージの有効化は、将来的に追加のストレージ キャパシティーが必要になる可能性があるクラスターに対する一時的な解決策です。長期的なストレージ容量の拡張のためにシャーディングを有効にすることを推奨します。

AWSとは異なり、Google Cloud にはボリューム変更のクールダウン期間がありません。そのため、前の変更が完了するのを待たずに、ストレージの変更をすぐに行うことができます。

クラスターのストレージキャパシティーを増やすと、Atlas はダウンタイムなしでサーバーのデータボリュームのサイズを段階的に変更します。Atlas は、データをコピーしたり最初の同期を実行したりすることなく、ストレージキャパシティーをその場で増やします。

ただし、Google Cloud では、その場でのストレージ容量の削減は許可されません。クラスターのストレージ容量を削減すると、Atlas は新しいボリュームをプロビジョニングし、その後、インプレースデータ同期プロセスを使用して古いボリュームから新しいボリュームにデータを同期します。これは Google Cloud Platform の制限を回避しますが、同期中は各ノードでダウンタイムが発生します。

ストレージ容量の削減を適用する前に、Review Changes ページで、この変更を行うと Atlas によってクラスターの再起動がトリガーされることが通知されます。

この間もクラスターにはアクセスできますが、Google Cloud Platform が変更する各ノードは、ノードのデータ同期プロセスが完了するまで使用できなくなります。大規模なクラスターの場合、各ノードでこのプロセスが完了するまでに数時間かかることがあります。

Atlas は単一のレプリカセットのディスク容量に制限があり、上位のクラスター階層では4 TB までスケールアップされます。 デフォルトの制限を超えてクラスターの合計ストレージを拡張するには、プロジェクト設定で拡張ストレージを有効にします。 将来のさらなるスケーリングに対応するため、長期的に展開できるようシャーディングを有効にします。

マルチクラウド プロバイダー クラスターのストレージ容量の変更

Atlas は、3 つのクラウドプロバイダー間で最も低い共通基準を選択します。これにより、マルチクラウド配置全体で整合性が確保されます。

マルチクラウドクラスターの IOPS を調整することはできません。

プロビジョニングされた IOPS および高パフォーマンス IOPS (AWS でホストされているクラスター向け)

プロビジョニングされた IOPS および高パフォーマンス IOPS1 Provision IOPS2High Performanceを使用すると、 AWSでホストされるクラスターの最大 IOPS レートをカスタマイズし、パフォーマンス上の利点が得られます。プロビジョニングされた IOPS と高パフォーマンス IOPS は同じ概念を指しますが、生成 クラスターでは Atlas UIの が使用され、生成 クラスターでは IOPS が使用されます。簡単にするために、ここでは両方を参照するために高パフォーマンス IOPS を使用しています。

標準 IOPS は、ベースライン パフォーマンスを99 % の時間で提供するように設計されているAWS汎用SSDボリュームを使用します。ハイパフォーマンス IOPS99 は、プロビジョニングされたパフォーマンス.9 % の時間で提供するように設計されているAWSプロビジョニングされた IOPS SSDボリュームを使用します。

標準 IOPS と比較すると、高パフォーマンス IOPS:

• 構成された IOPS レートをより一貫して提供します。

• クラスターの p90 レイテンシ（サーバーの応答時間の測定値）を下げます。サーバーリクエストの 90 パーセントは p90 レイテンシ値よりも速く応答するため、p90 レイテンシ値が低いほど、一般的に応答時間が速くなります。

詳しくは以下を参照してください。

• Amazon EBS ボリューム タイプ

• プロビジョニングされた IOPS と高パフォーマンス IOPS の構成

拡張標準 IOPS

2AWSまたは Google Cloud 上の生成 専用クラスターには、ベースラインの最小 IOPS があり、その上で追加の IOPS をプロビジョニングできます。

• ディスクストレージが1000GB （1TB ）未満のクラスターの場合、このベースラインは3000 IOPS です。

• 1000GBを超えるディスクストレージを使用するクラスターでは、このベースラインはストレージを使用して、 IOPS GBと3 の比率で:1 のストレージを使用してスケーリングします。

次の表は、このベースラインを様々なディスクサイズでどのように増やすかの一部の例を示します。

クラスターに追加の IOPS をプロビジョニングするには、 2AWSまたは Google Cloud でホストされている生成 クラスター向けの拡張標準 IOPS を使用できます。拡張標準 IOPS では、最大 をプロビジョニングできます。

• 80k AWS生成 専用クラスターの IOPS2

• 160k GCP生成 専有クラスターの IOPS2

IOPS を増やすと、クラスターの使用可能なディスクスループットも増加します。

2生成 専用クラスターでは、追加の IOPS をプロビジョニングし、ストレージキャパシティーを個別に増やすするため、一方をスケーリングしても他方をスケーリングする必要はありません。追加の IOPSのプロビジョニングとストレージキャパシティーのスケーリングは独立しているため、Atlas はそれぞれに対して個別に課金します。

詳しくは以下を参照してください。

• 生成2専有クラスター

• 生成クラスターの IOPS を設定する2

IOPS レートの設定

最小ディスク容量と RAM の比率

Atlas は、特定のクラスター階層に対して次の最小比率を強制します。これにより、大規模なデータセットでもクラスターのパフォーマンスの整合性が維持されます。

インスタンス サイズ M10 から M40 のディスク容量とシステム メモリの比率は 60:1 です。M40 以上のインスタンス サイズの比率は 120:1 です。

Atlas は単一のレプリカセットのディスク容量に制限があり、上位のクラスター階層では4 TB までスケールアップされます。 デフォルトの制限を超えてクラスターの合計ストレージを拡張するには、プロジェクト設定で拡張ストレージを有効にします。 将来のさらなるスケーリングに対応するため、長期的に展開できるようシャーディングを有効にします。