AI エージェント向け: ドキュメントインデックスは https://www.mongodb.com/ja-jp/docs/llms.txt で利用できます。すべてのページの markdown バージョンは、いずれかの URL パスに .md を追加することで利用できます。
Make the MongoDB docs better! We value your opinion. Share your feedback for a chance to win $100.
MongoDB Branding Shape
Click here >
Docs Menu

ランディングゾーン設計

ランディング ゾーンとは、適切に設計され、事前に構成されたクラウド環境を確立するためのフレームワークです。MongoDB Atlas のランディング ゾーンは、運用効率、セキュリティ、信頼性、性能、コストなどに関する組織固有の要件を定義します。さらに、これらの要件を満たすためにチームが使用しなければならないツール、手順、および Atlas の構成も定義します。すべてのエンタープライズのお客様には、ワークロードを Atlas に移行する前にランディングゾーンを設計することを推奨いたします。

ランディングゾーンを設計して実装することで、後で初期設定を再設計する際のコストを回避できます。例、ワークロードを Atlas に移行するための最近のディスカッションでは、 MongoDB Enterprise のカスタマーの1 人が、ビジネスユニット間で一貫性のない暗号化ポリシーと冗長サーバーのために一貫性のないユーザーデータのリークとランタイムなクラウドコストに対処しているピア金融サービス会社に関する懸念事項を示しました。 これらのリスクを回避するために、このエンタープライズカスタマーは当社のプロフェッショナル サービスチームと連携して、会社の要件に基づいてすべてのチームとステークホルダーを整合させるランディングゾーンを設計します。これには、BYEKとFindOpsを使用した保管時の暗号化による保管時の暗号化と、支払いをタグ付けして追跡するためのFindOpsの統合が含まれます。

このアーキテクチャセンターのコンテンツは、適切にアーキテクチャされた Atlas 環境を構築するための開始点として使用できます。 次のリソースをドキュメントにコンパイルし、組織の目的に合わせてカスタマイズすることをお勧めします。MongoDB のプロフェッショナル サービスは、ランディングゾーンの設計をエンタープライズの要件に最適化するために調整するのに役立ちます。

ランディング ゾーンを作成する際には、次の考慮事項の要件を定義してください。

検討事項
説明

システム階層

Atlas の組織、プロジェクト、クラスターをグループ化する配置階層を選択して、必要に応じてビジネス ユニット、環境、請求可能なグループ間の権限の分離と分離を促進します。例、ビジネス ユニットを個々の組織にグループ化して、営業担当者が製品リソースを認証できないようにすることができます。また、開発環境と本番環境を個別のプロジェクトまたは組織に分けて、各環境で異なるセキュリティと回復力の要件を満たすことも推奨しています。

このトピックの詳細と推奨事項については、「Atlas の組織、プロジェクト、クラスターに関するガイダンス」を参照してください。

セキュリティ

デフォルトでは、Atlas はクラスターへのすべてのアクセスをブロックします。データベースへのすべての接続に対して TLS 暗号化を強制します。また、クラウドプロバイダーディスク暗号化 を使用して保管中のデータを暗号化します。クラスターへの安全なアクセスを可能にするには、次のセキュリティ要件を定義する必要があります。

  • IP アクセス リスト制限や、ネットワーク信頼境界の拡張を制限するために必要なプライベートエンドポイントとVPC接続などのネットワークセキュリティ構成

  • ユーザーを認証し、Atlas コントロール プレーン({{atlas-ui+} および Atlas API)、データベースリソース、データベース操作へのアクセスを承認する方法のメカニズム

  • 転送中、保存時、および使用中のデータに対する追加のデータ暗号化要件

このトピックに関する推奨事項および詳細については、以下のページをご覧ください。

コンプライアンス

配置データの所在地がデータ主権をどのように決定し、それによってどの法律がデータに適用されるかを検討してください。明確に定義されていない特定の法的および規制要件や、その他のカテゴリーに属する要件を特定し、考慮してください。

データの耐久性は、配置パラダイムでどのリージョンと地理的を選択するか、また地理間でデータをパーティション分割するかどうかによって異なります。

このトピックに関する推奨事項および詳細については、以下のページをご覧ください。

信頼性とレジリエンス

高可用性アーキテクチャと障害復旧プランの両方を通じて、信頼性と回復力の標準を定義し、レコード。これらの戦略は組み合わせることで、さまざまなタイプの障害から保護します。

  • 最初に、アプリケーションのクリティカル レベルに基づいて、組織に最適なRPORTOのターゲットを定義します。

  • 高可用性アーキテクチャ: 自動フェイルオーバーを通じて、ノード、ゾーン、リージョン、またはクラウドプロバイダーの停止時などのインフラストラクチャの障害から保護します。適切な配置構成と majority書込み保証 (write concern)を使用すると、高可用性ではRPO=0 のデータ損失がゼロになり、リカバリ時間は 秒単位でほぼゼロの RTO で実現されます。そのため、障害発生時にも投票権過半数を維持できるように、アベイラビリティーゾーン、リージョン、またはクラウドプロバイダー全体に十分なノードを配置し、メンテナンスウィンドウをスケジュールして、プライマリノードの再起動がビジネス時間外で発生するようにする必要があります。詳細については、Atlas の高可用性Atlas 配置パラダイムのガイダンス を参照してください。

  • 障害復旧計画:高可用性保護を超える、または配置の完全な失敗、データの破損、誤って削除など、データの整合性に影響を与えるシナリオから保護します。バックアップからのリカバリでは通常、バックアップ頻度に応じて RPO>0 によるデータ損失が行われ、 RTO では 分から 時間の復元時間が長くなります。完全な障害復旧プランでは、次のことが実行されます。

    • バックアップから復元する手順、ポイントインタイムリカバリを実行する手順、復元されたクラスターにワークロードを移行する手順など、リカバリ手順のドキュメントとテストを行います。

    • RPORTO 要件を満たすために、バックアップスナップショットのスケジュールとスナップショットの保持とマルチリージョン分散の要件を定義します。

    • データの破損やデータの誤削除など、手動で中断する必要があるシナリオを識別し、自動フェイルオーバーではデータを保護できないシナリオを識別します。

    詳細については、「Atlas 障害復旧に関するガイダンス」および「Atlas ビジネス継続性計画に関するガイダンス」を参照してください。

請求

レポート作成および請求用の FindOps ツールとの統合など、請求に関する特定の要件を特定します。これらの要件を Atlas クラスターのオートメーションとプロビジョニングのプロセスにビルドして、この統合を容易に行うことができます。

このトピックに関する推奨事項および詳細については「Atlas の請求データに関する機能」をご覧ください。

データの保持

データ保持ポリシーを識別してレコードしてください。これには、さまざまな法的要件や規制要件を伴う財務レコード、カスタマー データ、従業員情報など、データの性質と目的に応じてデータをアーカイブまたは消去するためのオートメーションと統合されたデータ分類フレームワークの作成が必要になる場合があります。アーカイブされたレコードの検索パフォーマンス特性を特定してください。

このトピックに関する推奨事項および詳細については、以下のページをご覧ください。

監視と観察権

どのログとメトリクスを、どのように監視するかを定義する観察可能性の標準を設定します。例、Atlasログファイル、監査するログ、またはアクティビティフィードデータを取り込む外部システム統合を設定します。または、特定のイベントタイプのアラートとレポート作成ガイドラインを構成します。

このトピックに関する推奨事項および詳細については、以下のページをご覧ください。

監査と変更制御

監査または変更管理の要件を定義してください。これには、変更承認プロセスやツール、レポート作成ガイドライン、保存と分析のためのサードパーティ システムへの統合などが含まれます。これらの要件は、本番環境と非本番環境で異なる場合があります。

このトピックに関する推奨事項および詳細については「Atlas の監査およびロギングに関するガイダンス」をご覧ください。

MongoDB の Professional Services チームは、企業のお客様と提携して、Atlas のカスタムランディング ゾーンを作成します。MongoDB の Professional Services をご利用の場合、このページのリソースは、こういった相談について計画する上でも役立ちます。

Atlas ランディングゾーンの開始点として次のリソースを使用します。ランディングゾーンの設計は、チーム全体の標準を確認して再調整する反復的なプロセスです。このページのすべての図、推奨事項、例をドキュメントにコンパイルし、組織の要件に合わせて調整することをお勧めします。

次の例の図では、Atlas アーキテクチャ センター全体のアーキテクチャ図の多くを 1 つの画像に統合して、ランディング ゾーンを視覚化しています。必要に応じて調整し、組織に合わせてカスタマイズできます。

「Atlas ランディングゾーン の例を示す図」。
クリックして拡大します

さまざまなクラウドプロバイダーを使用したその他の設定例については、次のランディングゾーンガイダンスを参照してください。

  • GCP の FAST MongoDB Atlas構成は、管理対象の Atlas クラスターを作成および構成し、それをプライベートエンドポイントを介してローカルVPCネットワークに接続するプロジェクトテンプレートです。

  • Amazon Web ServicesとMongoDB Atlasランディング ゾーンは、複数のアベイラビリティーゾーンにサブネットと NAT ゲートウェイ を持つAmazon Web Services VPCと並行して、Atlasプロジェクト、クラスター、プライベートエンドポイントのセットアップを自動化する Terraformスクリプトです。このランディングゾーンのセットアップは、安全なクラウドストレージソリューションの一部としてMongoDB Atlasサービスを採用するための開始点を提供します。

  • AzureにMongoDB Atlasを配置するでは、 Microsoft Azureの一般的なワークロードにMongoDB Atlasを配置するための推奨アーキテクチャについて説明しています。このランディングゾーンは、ワークロードのコンピューティング リソースとワークロード専用のMongoDB Atlasクラスター間で、安全なプライベート接続を確立します。

まず、「Atlas の組織、プロジェクト、およびクラスターに関するガイダンス」の関連するガイダンスと例をコピーします。これは、Atlas で最初の基礎コンポーネントを作成するのに役立ちます。

次に、Atlas アーキテクチャ センターの各 Well-Architected Framework の柱の下にネストされている各ページのガイダンスと例について検討します。お客様の組織に関連する図、推奨事項、ツール、および例をコピーします。

Atlas アーキテクチャ センターのページには、次のものが含まれます。

Atlas Architecture Center からコピーしたランディングゾーン図、推奨事項、および例を、組織の固有の要件に合うように調整します。例えば、クラウドプロバイダーとして Google Cloud のみを使用する場合は、ランディングゾーンにその要件を明記し、AWSAzure のみに適用される推奨事項や例を除外する必要があります。

組織に固有の考慮事項と要件をさらに特定するには、前のセクションの「ランディング ゾーンの考慮事項」をご覧ください。

移行」ページを参照して、Atlas への移行を計画するか、左側のナビゲーションを使用して各 Well-Architected フレームワークの柱の機能とベストプラクティスをご覧ください。