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
Docs Home
Docs Home
Docs Home

運用データレイヤー

このリファレンスアーキテクチャでは、MongoDB Atlas上に運用データレイヤー（ODL）を実装し、サイロ化された運用データを統合して、下流の運用、分析、およびAIワークロードに提供する方法を説明します。

ODLは、既存の記録系システムのデータを中央集約されたクエリ可能なレイヤーに統合・整理するアーキテクチャパターンです。これにより、モダンアプリケーションやデータプロダクトをレガシープラットフォームから切り離し、単一ビュー、Data‑as‑a‑Service、AI/エージェント型AIユースケースなどの取り組みを、これらのシステムを全面的に置き換えることなく実現できます。MongoDB Atlasは、ODLの中核となるデータプラットフォームを提供し、柔軟なドキュメントモデルにトランザクション、検索、分析、およびベクトル機能を組み合わせ、単一のサービスとして提供します。

ODLの実装レベル

  • 読み取り専用：高性能なリードレプリカとして機能し、ソースシステムからのクエリ負荷をオフロードし、運用データに対する安定したAPIを提供します。

  • エンリッチド：ソースデータにメタデータや外部データセットを組み合わせ、上流システムを変更することなく、分析およびAI向けのコンテキストビューを提供します。

  • 読み書き：ビジネスワークフローの一部として書き込みを受け付け、運用をモダナイズするとともに、レガシーな記録系システムへの依存を段階的に低減します。

MongoDBを使用した運用データレイヤーの実装レベル

図1。MongoDBを使用した運用データレイヤーの実装レベル。

クリックして拡大します

注意

次の図は、オープンデータレイヤー（ODL）を実装できるさまざまなレベルを示しています。これは概念的な明確化のみを目的としており、このソリューションのリファレンスアーキテクチャを示すものではありません。

図

運用データ層参照アーキテクチャ

図2。運用データ層参照アーキテクチャ

クリックして拡大します

データフロー

  1. ソースシステム

    エンタープライズアプリケーション、運用データベース、サードパーティAPI、およびレガシープラットフォームは、記録系システムとして機能します。これらは、リアルタイムかつコンテキスト化されたアクセスのためにODLへ同期するビジネストランザクションおよびイベントを取得します。

    • 一般的なソースシステムには、メインフレーム、CRM、ERP、受注管理、サプライチェーン管理、人事、請求、マーケティングオートメーション、ウェブサイト、ソーシャルメディア、参照データ、サードパーティAPI、ログ、時系列データなどが含まれます。

  2. 取り込みレイヤー

    データは、バッチのExtract-Transform-Load（ETL）/Extract-Load-Transform（ELT）ジョブ、およびリアルタイムストリーミングまたは変更データキャプチャー（CDC）を通じて、ソースシステムからMongoDB Atlasに移動します。mongoimport、Bulk Write API、ETLプラットフォーム、MongoDB Kafka Connector、Atlas Stream Processingなどのツールを使用して、レイテンシやスループット要件に応じてイベントをロード、変換、ルーティングします。

  3. 運用データ層（MongoDB Atlas）

    MongoDB Atlasクラスターは、構造化データ、半構造化データ、非構造化データを、トランザクション処理、リアルタイム分析、全文検索、ベクトル検索をサポートするドキュメントデータモデルに統合し、統一されたクエリAPIを通じてハイブリッドワークロードに対応します。ODLはクラウド上で稼働し、シャーディングとレプリカセットによって水平方向にスケールします。

  4. 処理／提供レイヤー

    APIゲートウェイはエッジに配置され、認証、レート制限、および外部アクセスを管理します。サービスメッシュはサービス間通信を制御し、データプロキシレイヤーはワークロードの種類に応じてクエリをルーティングしながら、コネクションプーリング、キャッシュ、ポリシー適用を実施します。MongoDB Change StreamsおよびAtlas Stream Processingは、ポーリングなしでデータ変更を下流のコンシューマーに配信できます。

  5. 消費者向けアプリケーション

    運用アプリケーション、生成系AIおよびエージェント型AIシステム、ならびにBIツールは、MongoDBネイティブドライバー、Atlas SQL、およびコネクタを使用してODLに接続します。これらは、レガシーシステムに直接依存することなく、統合され、ガバナンスが適用され、ほぼリアルタイムのエンタープライズデータビューから恩恵を受けます。

例外、注意事項、トレードオフ

MongoDB Atlas上で高性能なODLを維持するには、複雑性とアーキテクチャ目標のバランスを取る必要があります。

  • 双方向型書込み (write) 調整（読み取り/書込み ODL）: 読み取り/書込み（「Y=loading」）ODL では、ODL とレガシーシステム間でデータがドリフトするリスクが導入されます。メッセージング プラットフォームやAPIゲートウェイをトランザクションのアウトボックスやsaraモデルなどのパターンと併用することで、分散ロックや 2PC（2 フェーズ コミット）に依存する代わりに、書込みを調整し、明確な整合性保証を定義できます。

  • ワークロードの分離 — OLTP、オンライン分析処理（OLAP）、AI：分析ワークロードやAIワークロードをプライマリノードで直接実行すると、トランザクションのパフォーマンスが低下します。これを避けるには、secondaryPreferred読み取りを使用するレプリカセット、シャーディングされたクラスター、および専用の検索インデックスとベクトルインデックスを使用して各ワークロードタイプを分離し、オンライントランザクション処理（OLTP）、分析、およびRetrieval-Augmented Generation（RAG）/AIクエリーが同じリソースを奪い合わないようにします。

  • レイテンシと取り込みコストのトレードオフ：ODLは低レイテンシのクエリを提供できますが、データの鮮度はデータの取り込み方法に依存します。バッチETL/ELT、CDC、およびリアルタイムストリーミング（例えばMongoDB Kafka ConnectorやAtlas Stream Processingを通じたもの）は、それぞれ異なる運用特性とコストプロファイルを持ちます。真にニアリアルタイムの更新が必要なユースケースにのみ、常時ストリーミングを利用するようにしてください。

  • スキーマの変化とドキュメントの増加: MongoDB の柔軟なドキュメントモデルはスキーマの迅速な変化をサポートしていますが、厳格な設計が必要です。確立されたスキーマ設計パターンと埋め込み「対」参照ガイダンスを適用して、ドキュメントの肥大化、深くネストされた構造、チーム間の互換性のないスキーマのドリフト（特に高度にエンコードされた ODL において）を回避してください。

  • ODLの適用領域：ODLは分断された運用データの統合に最適であり、純粋な分析基盤を置き換えることを目的としたものではありません。ODLは記録系システムの直接的な置き換えとして設計されているわけではありませんが、最終的にレガシーな記録系システムを置き換えるマルチステップの移行戦略の第一段階として機能します。

実装ガイド

1

アプローチの定義

  • 主要なユースケースおよびビジネスドメイン（例：ペイメントハブ、顧客360、統合コマース、ネットワーク保証など）を特定します。

  • イベント駆動型、マイクロサービス、API中心などのアーキテクチャスタイルを選択し、既存の環境に適合させます。

  • リスク許容度、レガシーシステムへの依存度、およびモダナイゼーションの目標に基づき、読み取り専用、エンリッチド、または読み書きのODLから開始するかどうかを決定します。

2

設計データの取り込みと モデリング

  • コレクションの設計：MongoDBのスキーマ設計パターンを使用します。頻繁に一緒に読み取るデータは埋め込み、大規模または独立したエンティティは参照して、重複を削減し、ドキュメントの管理性を維持します。

  • バッチ取り込み: ソース システムからのスケジュールされたエクスポートを読み込むには、mongoimport、一括書き込み API、Atlas Data Federation のマテリアライズド、またはETLツールを使用します。

  • ETL/ELT：MongoDB Spark Connectorおよびオーケストレーションツールを使用してデータを抽出し、ロード前に変換（ETL）するか、Atlasに生データをロードしてから集計パイプラインで変換（ELT）します。

  • リアルタイム取り込み：MongoDB Kafka ConnectorおよびAtlas Stream Processingを使用し、CDCストリームやトピックイベントを取り込むイベントドリブンのパイプラインを構築して、最小限のレイテンシでAtlasに書き込みます。

3

アクセスレイヤーを設計してください

  • ODLの周囲に三層のアクセスレイヤーを実装します。

    • APIゲートウェイ：外部クライアントとの接続を終端し、認証およびレート制限を処理するとともに、KongやTraefik.などのプラットフォームを使用して、プロトコル変換（REST、GraphQL、gRPC、WebSocket）を提供します。

    • サービスメッシュ：IstioやLinkerdなどのツールを使用し、mTLS、リトライ、トレーシングによってサービス間トラフィックを保護および可観測化します。

    • データプロキシレイヤー：ワークロードの種類に応じてMongoDB Atlasへのクエリをルーティングし、接続プーリング、キャッシュ、ポリシー適用をデータに近い場所で実行します。

4

クエリルーティングの構成

  • OLTP：トランザクションの読み取りおよび書き込みはプライマリノードにルーティングし、中核となるビジネスフローにおいて一貫性と低レイテンシのオペレーションを保証します。

  • OLAP/BI：分析およびレポーティングワークロードはsecondaryPreferredを使用してセカンダリノードにルーティングし、履歴データやコールドデータについては、運用ワークロードへの影響を回避するためにAtlas Data Federationやマテリアライズドビューの利用を検討します。

  • AI/RAG：MongoDB Vector Searchを使用して、運用データ内に格納された埋め込みに対するセマンティック検索およびハイブリッド検索を実行し、集計パイプラインを通じて結果をメタデータと組み合わせ、エージェント型およびLLM主導のアプリケーションに提供します。

5

セキュリティとデータトラストの確立

  • 転送中および保存時の暗号化：すべての外部アクセスポイントでTLSを強制し、Atlasの組み込み暗号化機能を使用してデータ保護要件を満たします。

  • アイデンティティとアクセスの管理：OpenID Connect（OIDC）やOAuth 2.0などの業界標準プロトコルを実装して認証を処理し、ロールベースのクレームを含む標準化されたトークン（JSON Webトークンなど）を発行します。分離された承認パターンを活用して、API層およびサービス層の両方でポリシーベースのきめ細かなアクセス制御を適用し、セキュリティロジックをアプリケーションコードから分離します。

  • シークレットの集中管理：OIDCやOAuth 2.0がユーザーおよびサービスのアイデンティティを管理する一方で、ODLはトークンライフサイクルの外部に存在する認証情報やキーに依然として依存します。これには、データベース接続資格情報、OAuthクライアントシークレット、TLS証明書および暗号化のキーなどが含まれます。これらは、Vaultサービス、HSMベースのキー管理、またはクラウドプロバイダーのネイティブなシークレットストアなどの専用のシークレット管理ソリューションを使用して保管およびローテーションし、設定ファイルに埋め込むのではなく、実行時に注入します。

  • 監査とガバナンス：ODLをデータマスキング、集約、およびアクセス制御ポリシーの適用ポイントとして使用し、ガバナンスをドメイン全体で一貫して適用しながら、プロデューサーとコンシューマーの疎結合を維持します。

詳細

さまざまな業界でODLがどのように実装されているかを確認します。

項目一覧