プロダクション ノート

Overview

MongoDB Atlas をデータプラットフォームとして使用すると、データベース インフラストラクチャの構築と維持に必要な単数形の運用タスクとワークフローから運用に集中することができ、エンジニアがビジネスに価値を追加できるようになります。 ハードウェアを維持してオペレーティング システムレベルのソフトウェア パッチに対応する代わりに、エンジニアは時間とリソースを費やして、企業の現在および将来の要件を満たすデータモデルを開発できます。

このドキュメントでは、 MongoDB Atlas クラスターを使用して MongoDB の本番環境へのデプロイを成功させるためのベストプラクティスについて説明します。

ロールと責任

MongoDB は、MongoDB Database Service をカスタマーに提供するために必要なインフラストラクチャを管理および運用しています。 MongoDB の責任には、以下が含まれます。

• データベースクラスターと基礎となるインフラストラクチャを管理し、MongoDB の可用性、安定性、パフォーマンスを確保し、サイズが M10以上のクラスターの99.995 % アップタイム サービス レベル契約（SLA）に基づきます。

• 基礎となるコンピューティング ノードの正常性を確認します。 が実行中であること、ネットワーク接続があること、およびアップタイム SLA を維持するために推奨される OS レベルのパッチがすべて含まれていることを確認します。

• インターフェースまたは MongoDBを介して行われたカスタマーの特定の設計選択に基づいて、Atlas userREST API データベース構成を管理します。

• すべての MongoDB メンテナンス アップグレードを自動的に適用し、製品の最新のバグ修正が使用されるようにします。

• ロールベースのアクセス制御、 IP アクセス リスト への IP アドレスの追加、ピアリングなど、セキュリティ プロファイルを管理し、カスタマーの指示ごとにクラスター セキュリティを最大化します。

• バックアップと復元サービスを提供します。

カスタマーは、基礎となるデータベース リソースやインフラストラクチャを直接管理することなく、MongoDB にアクセスするアプリケーションの開発と配置を続けるとなります。

クラスター管理

MongoDB Atlas はデータベース操作を抽象化し、高価値で高レベルのマネジメントの決定に集中できるようにします。 Atlas userロール を使用して、Atlas クラスターへのアクセスを管理できます。これらの権限は 、 組織レベル または プロジェクトレベル で のみ 適用できます。したがって、組織とプロジェクトの階層を慎重に計画する必要があります。

Atlas 内で組織とプロジェクトの適切に設計された階層を作成するには、クラスターをユースケースに適したプロジェクトに分割します。 これにより、運用コストを最小限に抑えながら、最大のエンタープライズ効率が得られます。

単一リージョンとマルチリージョンクラスター

高可用性とクラスターの耐久性は、クラスターの地理的配置構成によって異なります。 単一のリージョン内に配置されるクラスターは、そのリージョン内のアベイラビリティーゾーン全体に分散されるため、読み取りや書き込みの可用性を中断することなく、リージョンの部分的な停止に耐えられます。

オプションで、回復力とワークロードの分離を高めるために、クラスターを 2 つ以上のリージョンに分散することもできます。

リージョンの順序によって、プライマリ ノードのロケーションの優先順序が決まります。 したがって、そのリージョンが使用可能な場合にデータベース書込み (write) 操作をそのリージョンに送信する場合は、最初にそのリージョンをリストする必要があります。 リストの 2 番目のリージョンは、最初のリージョンが使用できない場合にGo 2 番目のリージョンです。

Atlasの クラスターの作成UI の次の例では、優先順位の高い順に 3 つの異なるリージョンに選択可能なノードを含むマルチリージョンクラスターを示しています。

クリックして拡大します

us-east-1リージョンが利用できなくなった場合は、 us-west-1リージョンで新しいプライマリが選出されます。

注意

プライマリ選択可能性を確保するには、クラスターに奇数のノードが必要です。 詳しくは、「レプリカセットの選挙 」を参照してください。

2 つのリージョンでの配置

クラスターを 2 つのリージョンに配置すると、データのコピーが常に複数のリージョンに保持されます。 ただし、クラスター内のノードの大部分を含む リージョンが失われると、管理者が中断するか、元のリージョンが使用可能になるまで、2 番目のリージョンは読み取り専用状態のままになります。

3 つ以上のリージョンでの配置

クラスターを 3 つ以上のリージョンに配置すると、アプリケーション層がフォールトトレランスがある場合、クラスターはリージョンレベルの完全な停止時に耐えられると同時に、読み取りおよび書込みの可用性を維持できます。

希望リージョンで常に書込み操作を維持することが優先順位が高い場合は、少なくとも 2 つの選出可能なノードが希望リージョン内の少なくとも 2 つのデータセンターに含まれるようにクラスターを配置することをお勧めします。

グローバルクラスター

グローバル配置で最高のデータベースパフォーマンスを得るため、ユーザーはロケーション認識型シャーディングを使用して読み取りと書込みのレイテンシを最小限に抑えるグローバルクラスターを構成できます。地理的ストレージ要件を持つユーザーは、特定の地理的領域にデータを保存することもできます。

アプリケーション管理

アプリケーション レベルの責任には、以下が含まれます。

• スキーマ設計（クエリやインデックスの最適化を含む）。

• クラスター階層とトポロジーの選択。 データベースのパフォーマンスを最適化するには、適切なクラスターサイズとトポロジー（レプリカセットまたはシャーディングされたクラスター）、およびストレージ容量と IOPSを選択することが重要です。

• 非本番クラスターのプロビジョニング。 本番環境のバックアップは、Atlas UI または API を使用して非本番環境のクラスターに復元できます。

• キャパシティー プランニング。 追加の計算容量が必要かどうかの判断は、通常 Atlas が提供するモニタリング テレメトリを使用して行われます。 アプリケーションのダウンタイムなしで追加の容量を追加でき、オプションでオートスケーリングを有効にして、使用量の急増に自動的に対応できます。

• データベースのメジャーバージョン アップグレードをいつ実装するかを決定します。

• バックアップと復元プランを実装してテストします。

• テストを通じて、アプリケーションがクラスターのフェイルオーバーをグレースフルに処理できるようにします。

• BI ConnectorやCharts などのツールを使用してデータ分析サービスを構成します。

マルチテナンシー

Atlas でマルチテナンシーを実装すると、アプリケーションの 1 つのインスタンスが複数のテナントにサービスを提供できます。 マルチテナント アーキテクチャの初期の設計上の決定は、要件の進化やスケーリングの期待の変化に伴い、時間の経過とともに意図しない結果をもたらす可能性があります。 詳細については、「マルチテナント アーキテクチャのビルド 」を参照してください。

アーカイブ データのオフロードとクエリ

データ ライフサイクルの一部として、コールド データを別のストレージ階層に移動する必要がある場合は、日付またはカスタム基準に基づいてデータを移動するための Atlas Online Archiveルールを設定できます。 Atlas でアクセス頻度の低いデータがアーカイブされると、読み取り専用のフェデレーティッドデータベースインスタンスから Atlas のデータと Online Archive のデータが一元的に表示されるようになります。

フェデレーティッド データのクエリ

Atlas Data Federation を使用して、さまざまなインフラストラクチャにわたるデータインプレースをクエリしたり、さまざまなシステム間でデータを移動したりできます。 集計パイプラインを複数のソースのデータに使用して、データからインサイトを抽出したり、データを他の目的で変換したりできます。 たとえば、 S3 には $ out を使用し、Atlas には $out を使用して、ストレージ階層間でデータを移動できます。また、 $outをS3に使用して、 AtlasクラスターのデータをJSON 、 BSON 、 CSV 、 TSV、Avro、Parquet、ORC に簡単に変換できます。また、それをAmazon Web Services S3に配置して、アクセスを必要とする下流のシステムをフィードすることもできます。

一時データベースユーザーの監査

アプリケーション サービス ユーザーを含むすべてのデータベース ユーザーに対して監査を有効にすると、クラスターのパフォーマンスに重大な影響を与える可能性があります。 一時データベース ユーザーのアクションを監査する必要がある場合は、監査対象のカスタムロールを作成し、昇格された権限を持つ一時ユーザーを作成して、そのユーザーにアクションを監査するためのカスタムロールを付与します。

一時データベースユーザーのアクションを監査するには、次の手順に従います。

オプションのモニタリングとロギングの統合

DataDog と Atlas のプッシュベースのモニタリング統合を構成できます。 Atlas Administration API を使用してモニタリング データをプルすることもできます。

jSONar を使用してプルベースのログ統合を構成できます。これは Splunk やSUmoLog などの他のサービスにプッシュできます。 Atlas Administration API を使用して5分ごとにログデータをプルすることもできます。

クラスター データ ボリュームの管理

Atlas には、クラスター データ ボリュームの管理に役立つ次の組み込みツールが用意されています。

• クラスターのオートスケーリングは、アプリケーションの負荷に自動的に対応し、クラスター階層を調整します。

• Atlas Online Archiveは、アクセス頻度の低いデータのアーカイブを自動化します。

• 検索ノードは独立してスケーリングし、クラスターからAtlas SearchおよびAtlas Vector Searchインデックス ストレージをオフロードします。

• TTL インデックスは、時系列コレクションからドキュメントを自動的に削除して領域を解放します。

これらのツールに加えて、クラスターのサイズをアップまたはダウンを調整する方法については、クラスターのサイズ設定 ガイドを参照してください。 また、クラスターを一時停止して、データを最大30日間保持している間に一時的にシャットダウンし、コストを節約することもできます。

サポート

開発カスタマー向けのオプションやエンタープライズ カスタマー向けのオプションなど、さまざまな階層のサポートが利用できます。

利用可能なサポート領域は次のとおりです。

• 管理対象の MongoDB クラスターに関する問題と懸念事項。

• パフォーマンス関連のクエリ。

• アプリケーション側とドライバーのコンサルティング。