特に使用量が増加するにつれて、支出をよりよく理解して効率化するために、 MongoDB Atlas は組織のデータベースコストを管理および制御するツールを提供します。
すべての配置パラダイムに共通する推奨事項
次の推奨事項は、すべての配置パラダイムに適用されます。
Atlas のコストを最適化するには、これらの戦略を検討してください。
使用率の低いクラスターをスケールダウン
Performance Advisor とクラスター メトリクスを使用して、大きすぎるクラスターを識別します。完全に使用されていない System Max: User CPU utilization（45% 未満）または過大なRAMが一貫して低くなっているか、次に、実際のワークロードパターンに適した階層にダウンサイズします。
多くのチームは、より大きなクラスターから開始され、実際の使用パターンを学ぶにつれて調整することを忘れます。 Atlas はより軽量なワークロードと柔軟なサイズ設定の 低 CPU オプションを提供しており、推測的ではなくリソースを真実に照合できます。サイズを調整することは、多くの場合、プルできる単一で最大のコストDB になります。
詳細については、 「 クラスターのリアクティブなスケールダウン 」を参照してください。
使用状況に合わせ、オーバー プロビジョニングを防ぐために、クラスター階層でオートスケーリングを有効にする
スケール ダウンは6時間ごとに1回実行され、特定の条件に一致する必要があります。詳細については、「クラスター階層のスケール ダウン」を参照してください。
また、クラスターの CPU、WireTiger キャッシュ、メモリ、IOPS を通常の使用期間である 30 日間にわたって定期的に監視することで、手動で下位のクラスター階層に移行することもできます。一般的に、使用量が割り当てられたリソースの 45% を安定して下回る場合は、スケール ダウンすることをお勧めします。
専有クラスターの場合、長期間使用しない場合は、より低い階層にスケールダウンするか、クラスターを一時停止することを検討してください。
開発およびテスト環境には
M10またはM30クラスターを使用することをお勧めします。詳細については、「Atlas クラスター サイズ ガイド」を参照してください。開発環境およびテスト環境では、次のことを推奨します。
cron ジョブを有効にし、誰もクラスターに対してアクティブに開発していない夜間に、開発クラスターとテスト クラスターを一時停止します。次のいずれかの方法を使用して、
pausedフィールドをtrueに設定することで、Atlas 管理 API を使用してクラスターを一時停止できます。Modify One Cluster のエンドポイントとなる接続されたデバイス。
サードパーティのメトリクスまたはアラート システムにアラートを設定し、開発クラスターまたはテストクラスターのアクティビティが 1 週間以上ない場合にトリガーします。
未使用の開発クラスターとテストクラスターは、一定の時間が経過し、クラスター所有者に十分なメールアラートが送信された後、終了することを検討してください。クラスターを終了するには、次の方法があります。
Atlas Administration API （1 つのクラスターの削除 エンドポイントを使用）。
フィールドを に設定して、クラスターリソースをTerraform
termination_protection_enabledfalseします。
不均一なシャード分散を避ける
シャーディングされたクラスターの場合は、ホットシャードを回避するためにスケーリング戦略を検討してください。ホットシャードは、クラスター内の 1 つのシャードが他のシャードよりも不釣り合いに多くのトラフィックまたはデータを受け取った場合に発生し、その 1 つのシャードのみがより多くのリソースを必要とする場合は、クラスター全体を増やすアップする必要があります。
独立したシャード スケーリング を使用しない場合、クラスター全体で実際に必要のないリソースを増やすには、増やすがかかるため、ホットシャードのコストは高くなります。スマートシャーディングを通じて負荷をより均等に分散することで、設定を調整し、不要なコストを回避できます。節約は特定のワークロードによって異なりますが、これらのアプローチは、データパターンの変化に応じて安定してコスト効果の高い方法で拡張するのに役立ちます。
詳細については、「Atlas のスケーラビリティに関するガイダンス」を参照してください。
バックアップ構成の最適化
継続的なバックアップはコストがかかりますが、障害やコード ロジック エラーが発生した場合にバックアップウィンドウ内の任意の点からデータを回復するのが最も安全です。継続的なバックアップは、最もクリティカルなデータ階層にある本番アプリケーションに対してのみ有効にすることをお勧めします。
重要なデータを保存していないクラスターのバックアップ頻度を減らします。開発環境では、これらのクラスターを完全に終了することを検討してください。
データ転送パターンの最適化
可能な場合は、コストを最小限に抑えるために、同じプロバイダーの同じリージョンのデータ転送を選択してください。リージョン間転送またはインターネット転送は、別のリージョンでアプリケーションを復元する必要がある障害復旧シナリオなど、必要な場合にのみ使用してください。クラスターをトラフィックのほとんどのリージョン（通常はアプリケーションをホストする場所）に配置すると、データ転送コストを大幅に削減できます。
注意
クラウドプロバイダーに固有の詳細とガイダンスについては、「 データ転送コストを削減する方法 」を参照してください。
ネットワーク トラフィックを圧縮
クライアント ドライバでネットワーク圧縮を有効にし、クライアントとサーバー間のデータを圧縮します。例として、Node.js ドライバーのネットワーク圧縮オプションを設定できます。Atlas は、常にクラスター内通信を圧縮します。
詳細については、「データ転送コストの削減方法」を参照してください。
接続Poolingの最適化
アプリケーションの接続プールの設定を確認し、実際の同時使用パターンに合わせてサイズ設定します。ほとんどのアプリケーションは、適切な接続タイムアウトと再試行ロジックを追加しながら、最大プール サイズをデフォルト設定から安全に縮小できます。
各データベース接続は、アプリケーションとクラスター側の両方でリソースを消費します。接続プールが過剰にプロビジョニングされると不要なオーバーヘッドが発生し、接続スラッシュによって実際にパフォーマンスが低下する恐れがあります。
非効率的なクエリを避ける
データにアクセスするすべてのアプリケーションとプロセスに非効率性がないかどうかを確認してください。クエリで次のことが行われないようにしてください。
クライアント上にすでに存在するデータを再読み込みします。
既存のデータをクラスターに書き換えます。
詳細については、「データ転送コストの削減方法」を参照してください。
クエリの最適化
実行に長い時間がかかるクエリでは、リソース使用量が増加する可能性があり、上位のクラスターが必要になります。これらのクエリを最適化すると、リソースの消費が削減され、コストが削減されます。
チームと四半期ごとにクエリの調整を予定して、最も遅いクエリを確認し、インデックスのフットプリントを監査する。 Performance Advisor を使用して欠落しているインデックスを識別し、クエリプロファイラーを使用してコストのかかる操作を特定します。上位の10 コスト クエリとその最適化ステータスを追跡するための簡単なスプレッドシートを作成します。
クエリは、データが大きくなるにつれて低下します。 1 GBで優れたパフォーマンスを発揮するクエリは、100 GBの予算を簡単に超えることができます。一方、未使用のインデックスはストレージを消費し、値を提供せずに書込みを遅くします。定期的なレビューはパフォーマンスのドリフトを早期に検出し、インデックス戦略をクリーンで目的のあるものに保ちます。
詳細については、「 低速クエリの分析 」を参照してください。
一時停止した Atlas Search インデックス
次のいずれかの理由で、Atlas Searchインデックスが古くなっている可能性があります。
ディスク使用率が高くなっていたため、レプリケーションが停止した。
専用の Atlas Search ノードの場合、一時停止レプリケーションしきい値は 90% で、再開レプリケーションしきい値は 85% で、クラスター上のすべての書込みのディスク使用率です。専用の Atlas Search ノードがない場合、一時停止レプリケーションしきい値は 96% で、再開レプリケーションしきい値は 94% で、クラスター上のすべての書込みのディスク使用率になります。
レプリケーションがoplog ウィンドウよりも長い期間停止した場合、Atlas Search
mongotプロセスはoplogから削除されるため、再同期する必要があります。この状態は通常、現在のレプリケーション点が oplogで使用できなくなった場合に発生します。 Atlas
mongodは、mongotプロセスがoplog削除された場合にインデックスを再構築します。これはリソースが集中し、かなりの時間がかかる可能性があります。インデックスが 20 億ドキュメントの制限に達しました。
エラーが発生したため、レプリケーションに失敗しました。
既存のインデックス は引き続きクエリできます。ただし、古いインデックスに対するクエリの結果には古いデータが含まれる場合があります。検索ノードをアップグレードしてディスク容量を増やします。現在、ブロックしきい値を超えている場合は、既存のインデックスを削除してディスク容量を解放します。または、View status details モーダルウィンドウのエラーを使用して、問題のトラブルシューティングを行います。
スキーマ パターンの最適化
Atlasチームと連携して、肥大化したドキュメント、無制限の配列、コストのかかる操作を強制するスキーマなど、コストのかかるパターンがないかコレクションを確認してください。個々のドキュメントを適切なサイズ以下に維持しながら、まとめてアクセスされる関連データを埋め込む機会を探します。より単純なドキュメント構造が機能する場合に、複雑な集計またはコレクション間の検索を必要とするパターンを排除することに焦点を当てます。
スキーマ設計が低いと、非効率的なクエリとストレージの肥大化によってコストが上昇します。 Atlasドキュメントモデルは適切に設計されている場合、コストのかかるリレーショナル操作を自然に排除します。適切に設計されたコレクションは、コンピューティングのオーバーヘッドを削減し、インデックス要件を最小限に抑え、クエリパフォーマンスを向上させます。これらはすべて月額請求に直接影響。
詳しくは、「 スキーマ設計 」を参照してください。
ストレージの最適化
オンライン アーカイブやTTL インデックスなどの機能を使用して、古いデータを高価なホット ストレージから安価なコールド ストレージに移動したり、不要になったデータを削除したりします。データをアーカイブした後は、Atlas Data Federation を通じてデータにアクセスできます。
Cost Explorer の使用
Cost Explorer ツールを定期的に使用して、組織、プロジェクト、クラスター、およびサービス レベルでの支出パターンを監視します。ニーズに合わせて頻度を設定します。
アラートの設定
月額コストが一定の金額を超えた場合など、主要なしきい値の請求アラートを構成します。例、コストが $100 を超えたときにアラートを設定します。この先を見越したアプローチは、予期しない対応を回避するのに役立ちます。
請求書を確認する
毎月、請求書を確認して、以前の請求最適化の提案を使用して最もコストの高いサービスを評価します。 これは、コスト削減の機会を特定するための推奨ベストプラクティスです。
請求書に予期しない変更があった場合は、請求額の大部分を占めるクラウド コンピューティングコストを確認してください。 Atlas Billingセクション内の請求書のSummary By Serviceカードで、クラウドコンピューティングコストを確認できます。 Summary By Serviceビューには、すべてのクラスターのコストがプロバイダー、階層、リージョン別に表示されます。
適切な配置パラダイムとトポロジーを選択する
選択された配置パラダイムとトポロジーによって、Atlas のコストが変わることがあります。
異なるトポロジーにおけるコスト削減について詳しくは、「Atlas の高可用性に関するガイダンス」を参照してください。
リソース タグ付けを設定する
チーム、環境、またはコストセンターが Atlas プロジェクトとクラスターに一貫したタグを適用します。 「チームは、
適切にタグ付けしないと、Atlas の請求はぼかして表示され、どのチームやプロジェクトがコストを引き起こしているかを追跡することは不可能になります。リソース タグ付けにより、Cost Explorer は強力な説明ツールに変わり、コストの傾向を簡単に識別でき、コストの正確な割り当て、部門またはワークロードのタイプごとの最適化の機会を特定できます。
詳しくは、「 リソース タグ 」を参照してください。