この参照アーキテクチャでは、 MongoDB Atlasに運用データ層（ODL）を実装して、サイジングされた運用データを統合し、下流の運用、分析、およびAIワークロードを提供する方法について説明します。
ODL は、既存のレコードシステムのデータを一元化されたクエリ可能なレイヤーに統合して整理するアーキテクチャ パターンです。最新のアプリケーションとデータ製品をレガシープラットフォームから切り離することで、シングルビュー、データ❌データを使用するためのサービス、 AI/エージェントエージェントAIなどのプロジェクトを、これらのシステムを完全に置き換える必要なく有効にします。 MongoDB Atlas は、ODL の主要データプラットフォームを提供し、柔軟なドキュメントモデルとトランザクション、検索、分析、ベクトル機能を単一サービスで組み合わせます。
ODL実装レベル
読み取り専用: ソース システムからクエリをオフロードし、運用データに対して安定した API を公開するための高性能読み取りレプリカとして機能します。
強化: ソースデータとメタデータおよび外部データセットを組み合わせて、上流のシステムを変更せずに分析とAIのコンテキストに応じたビューを提供します。
読み取り書込み: 操作を最新化し、レコードのレガシーシステムへの依存関係を徐々に軽減するために、ビジネス ワークフローの一部として書込みを受け入れます。
図の 1。 MongoDBを使用した操作データ層の実装レベル。
注意
次の図は、オープン データ レイヤー（ODL）を実装できるさまざまなレベルを示しています。これは概念を明確にするためのみであり、このソリューションの参照アーキテクチャとして意図するものではありません。
図
図の 2。運用データ層参照アーキテクチャ
データフロー
ソース システム
エンタープライズ アプリケーション、運用データベース、サードパーティ API、レガシープラットフォームは、レコードのシステムとして機能します。ビジネストランザクションとコンテキストに同期したイベントを ODL に同期し、リアルタイムかつコンテキストに応じたアクセスを可能にします。
一般的なソース システムには、メインフレーム、CRM、ERP、注文管理、サブスクライブ マネジメント、人間リソース、請求、マーケティング オートメーション、ウェブサイト、ソーシャル メディア、参照データ、サードパーティ API、ログ、時系列データなどがあります。
取り込み層
データは、バッチするエクスポート-変換ロード（ETL）/抽出ロード-変換（ELT）ジョブとリアルタイムストリーミングまたは 変更データ キャプチャ（CDC）を通じてソース システムからMongoDB Atlasに移動されます。 mongoimport、一括書き込み API、 ETLプラットフォーム、 MongoDB Kafka コネクタ、Atlas Stream Processing などのツールを使用して、レイテンシとスループットの要件に従ってイベントをロード、変換、ルーティングします。
操作データレイヤー（MongoDB Atlas）
MongoDB Atlasクラスターは、構造化データ、半構造化データ、非構造化データをドキュメントデータモデルに統合し、統合クエリAPIを通じてトランザクション処理、リアルタイム分析、全文検索、ベクトル検索などのハイブリッド ワークロードをサポートします。 ODL はクラウド内で実行され、シャーディングとレプリカセットによって水平方向にスケーリングします。
プロセシング/サーバーング レイヤー
APIゲートウェイはエッジに配置され、認証、レート制限、外部アクセスを管理します。サービス キャッシュは、サービスとサービスの通信を制御し、データプロキシレイヤーは接続プーリング、キャッシュ、およびポリシーの適用を適用しながら、ワークロードタイプに基づいてクエリをルーティングします。 MongoDB Change Streams と Atlas Stream Processing は、ポーリングなしで下流の利用者にデータ変更を公開できます。
コンシューマー アプリケーション
運用アプリケーション、生成AIおよびエージェントAIシステム、およびBIツールは、 MongoDBネイティブドライバー、Atlas SQL、およびコネクターを使用してODLに接続します。レガシーシステムに直接依存することなく、エンタープライズ データを統合して管理し、ほぼリアルタイムのビューでメリットをもたらすことができます。
例外、警告、トレードオフ
MongoDB Atlasで高パフォーマンスの ODL を維持するには、アーキテクチャの目的に対して複雑さを分散する必要があります。
双方向型書込み (write) 調整（読み取り/書込み ODL）: 2読み取り/書込み（「Y❌ ロード」）ODL では、ODL とレガシーシステム間でデータがドリフトするリスクが導入されます。メッセージング プラットフォームやAPIゲートウェイを、トランザクション アウトボックス や sala モデルなどのパターンと併用して、書込みを調整し、分散ロックや PC（2 フェーズ コミット）に依存する代わりに、明確な整合性保証を定義します。
ワークロード分離 — OLTP、オンライン分析プロセシング (OLAP)、 AI: 分析ワークロードまたはAIワークロードを直接プライマリ ノードで直接実行すると、トランザクション パフォーマンスが低下します。これを回避するには、
secondaryPreferred読み取り、シャーディングされたクラスター、専用の検索とベクトルインデックスを含むレプリカセットを使用して各ワークロードタイプを分離し、オンライン トランザクション処理（OLTP）、分析、検索拡張生成（RAG）を確保します/ AIクエリは同じリソースをめぐって競合しません。レイテンシと取り込みコスト: ODL は低レイテンシのクエリを提供できますが、データの最新性はデータの取り込み方法によって異なります。バッチETL/ELT、CDC、およびリアルタイムストリーミング（例、 MongoDB Kafka コネクタや Atlas Stream Processing）では、運用プロファイルとコストのプロファイルが異なります。ほぼリアルタイムの更新が実際に必要なユースケースについては、 常時オンのストリーミングを予約してください。
スキーマの変化とドキュメントの増加: MongoDB の柔軟なドキュメントモデルはスキーマの迅速な変化をサポートしていますが、厳格な設計が必要です。確立されたスキーマ設計パターンと埋め込み「対」参照ガイダンスを適用して、ドキュメントの肥大化、深くネストされた構造、チーム間の互換性のないスキーマのドリフト（特に高度にエンコードされた ODL において）を回避してください。
ODL が収まる場所: ODL は、断片化された運用データを統合するのに最適です。単一の分析プラットフォームを置き換えることを意図したものではありません。 ODL は、レコードのコア システムを直接置き換えるようには設計されていませんが、複数のステップに移行戦略の最初のステップとして、最終的にはレガシーレコードのシステムを置き換えることができます。
実装ガイド
データの取り込みとモデリングを設計する
コレクションのデザイン: MongoDB スキーマ設計パターンを使用します。頻繁にまとめたデータを埋め込みます。大規模なエンティティまたは独立したエンティティを参照重複を減らし、ドキュメントを管理可能にします。
バッチ取り込み: mongoimport、一括書き込み API、Atlas Data Federation のマテリアライズド、またはETLツールを使用して、ソースシステムからスケジュールされたエクスポートを読み込みます。
ETL/ELT: MongoDB Spark コネクタとオーケストレーション ツールを使用してデータを抽出し、ロードする前に変換する（ETL）か、未加工のデータを Atlas にロードして 集計パイプライン で変換します（ELT）。
リアルタイム取り込み: MongoDB Kafka コネクタと Atlas Stream Processing を使用して、 イベントストリームまたはトピックイベントをキャプチャし、最小限のレイテンシで Atlas に書込みます。
クエリルーティングの設定
OLTP: トランザクションの読み取りと書込みをプライマリ ノードにルーティングして、主要ビジネス フローの整合性と低レイテンシ操作を保証します。
OLAP/ BI: secondaryPreferred を使用して分析ワークロードとレポート作成ワークロードをセカンダリ ノードにルーティングし、履歴データまたはコールド データには Atlas Data Federation またはマテリアライズド ビュー を検討して、運用ワークロードへの影響を回避します。
AI/RAM: MongoDB ベクトル検索を使用して、運用データと並行して保存された埋め込みをセマンティックおよびハイブリッド検索で使用し、結果を集計パイプライン を通じてメタデータと組み合わせて、エージェントや LM で動作するアプリケーションを提供します。
セキュリティとデータ信頼の確立
転送中と保存時の暗号化: すべての外部アクセス ポイントに TLS を強制し、Atlas に組み込まれている暗号化機能を使用して、データ保護要件を満たします。
ID とアクセスを管理:認証を処理し、ロールベースのクレームを含む標準化されたトークン（ JSON Web トークンなど）を発行するために、OpenID Connect（OIDC）や OAuth などの業界標準のプロトコルを実装します。デグループ化された認可パターンを活用して、 APIとサービス レイヤーの両方で、きめ細かなポリシーベースのアクセス制御を強制し、セキュリティ ロジックをアプリケーションコードから分離します。2.0
シークレットを一元化する: OIDC と OAuth2.0 はユーザーとサービス ID を処理しますが、ODL は引き続きトークンのライフサイクルの外部に存在する認証情報とキーに依存します。これらには データベースが含まれます。接続認証情報、OAuthクライアントシークレット、TLS 証明書を参照してください。や暗号化のキーなどの更新操作で識別します。専用の SE を使用して、これらを保存してローテーションします。資格ド サービス（マネージャー、またはクラウドプロバイダーネイティブのシークレット ストアでは、 t が挿入されます。構成ファイルに埋め込むのではなく、ランタイムにヘッジします。
監査とガバナンス: データのマスク、集計、およびアクセス ポリシーの適用点として ODL を使用し、ガバナンスがドメイン全体に一貫して適用されている間で、プロデューサーとコンシューマーが切り離された状態に維持します。
詳細
さまざまな業界が ODL を実装する方法を調べます。
金融サービス: エージェント向けAIによる運用ポートフォリオ マネジメント
製造: 統合名前空間データの整合性
小売: 統合管理ソリューション
運用データレイヤーについて詳しくは、ホワイトペーパー「 運用データ層 」を参照してください。