説明
シナリオ: 小売店から実行され、account2 のデータをクエリする App2 という名前のアプリを開発します。
App2 が account2 にアクセスするときは、単一​​の DNS エンドポイントに制限する必要があります。
Azure Private Link を使用すると、プライベート エンドポイント経由で Azure Cosmos アカウントに接続できます。プライベート エンドポイントは、仮想ネットワーク内のサブネット内のプライベート IP アドレスのセットです。
ダイレクト モード接続を通じて Azure Cosmos アカウントで Private Link を使用している場合、使用できるのは TCP プロトコルのみです。HTTP プロトコルは現在サポートされていません。
参照：
https://docs.microsoft.com/en-us/azure/cosmos-db/how-to-configure-private-endpoints

トピック 1、Litware, Inc
ケーススタディを開始するには
このケーススタディの最初の質問を表示するには、「次へ」ボタンをクリックします。質問に答える前に、左側のペインのボタンを使用してケーススタディの内容を調べてください。これらのボタンをクリックすると、ビジネス要件、既存の環境、問題の説明などの情報が表示されます。ケーススタディに [すべての情報] タブがある場合、表示される情報は後続のタブに表示される情報と同じであることに注意してください。質問に答える準備ができたら、「質問」ボタンをクリックして質問に戻ります。
概要
Litware, Inc. は、米国に本拠を置く食料品小売業者です。Litware はシアトルに本社と主要データセンターを持っています。同社は全米に 50 の小売店を展開しており、オンラインでの存在感も高まっています。各店舗はインターネットに直接接続します。
既存の環境。クラウドおよびデータ サービス環境。
Litware には、次の表に示すリソースを含む Azure サブスクリプションがあります。

productdb の各コンテナーは手動スループット用に構成されています。
コンプロダクト コンテナには、会社の製品カタログ データが保存されます。con-product の各ドキュメントには、con-productvendor 値が含まれています。コンプロダクトのデータをターゲットとするクエリのほとんどは、次の形式です。
SELECT * FROM con-product p WHERE p.con-productVendor - '名前'
con-productVendor コンテナ内のデータをターゲットとするほとんどのクエリは、SELECT * FROM con-productVendor pv ORDER BY pv.creditRating, pv.yearFounded 既存の環境の形式になります。現在の問題。
Litware では次の問題が特定されています。
con-productVendor コンテナ内の製品カテゴリの更新は、con-product コンテナ内のドキュメントに自動的には反映されません。
製品内のアプリケーションの更新により、HTTP ステータス コード 429「リクエストが多すぎます」が頻繁に発生します。ステータス コード 429 が、更新中の過剰なリクエスト ユニット (RU) の消費に関連していることがわかりました。
要件。計画された変更
Litware は、iotdb という名前のデータベースを含む、account2 という名前の新しい Azure Cosmos DB コア (SQL) API アカウントを実装する予定です。iotdb データベースには、con-iot1 および con-iot2 という名前の 2 つのコンテナーが含まれます。
Litware は次の変更を行う予定です。
テレメトリ データを account2 に保存します。
複数の読み取り/書き込みリージョンをサポートするように account1 を構成します。
コンプロダクトコンテナの参照整合性を実装します。
Azure Functions を使用して、製品の更新に関する通知をさまざまな受信者に送信します。
すべての場所から実行され、account1 のデータをクエリする App1 という名前のアプリを開発します。
小売店から実行され、account2 のデータをクエリする App2 という名前のアプリを開発します。App2 が account2 にアクセスするときは、単一​​の DNS エンドポイントに制限する必要があります。
要件。ビジネス要件
Litware は次のビジネス要件を特定します。
要件に対して複数のソリューションがある場合は、追加コストが発生しない限り、最高のパフォーマンスを提供するソリューションを選択してください。
IoT 関連の処理に対する Azure Cosmos DB のコストが予測可能であることを確認します。
小売店でのファイアウォールの変更の数を最小限に抑えます。
要件。製品カタログの要件
Litware は、製品カタログに対して次の要件を特定します。
製品カタログ データのカスタム競合解決ポリシーを実装します。
副製品コンテナの更新中のエラーの頻度を最小限に抑えます。
マルチリージョン書き込みを構成したら、account1 のデータに対する App1 クエリのパフォーマンスを最大化します。
コンプロダクト コンテナー内のドキュメントが更新されるたびに、2 つの Azure 関数の実行をトリガーします。

説明
新規および更新された注文は contoso-erp.orders に追加されます: はい
コードは contoso-app からの一括データ取り込みを実行します: いいえ
contoso-app と contoso-erp の両方で Analytics ストアが有効になっています: はい
このコードは、spark.readStream メソッドを使用して、contoso-app という名前のデータベース内のorders という名前のコンテナーからデータを読み取ります。次に、データは条件によってフィルターされ、spark.writeStream メソッドを使用して contoso-erp という名前のデータベース内のorders という別のコンテナーに書き込まれます。書き込みモードは「追加」に設定されています。これは、新規および更新された注文が宛先コンテナーに追加されることを意味します。このコードは、contoso-app からの一括データ取り込みを実行するのではなく、ストリーム処理を実行します。一括データ取り込みは、大量のデータをデータ ストアにバッチでロードするプロセスです。ストリーム処理は、データがリアルタイムで到着すると継続的に処理するプロセスです。contoso-app と contoso-erp はどちらも、spark.cosmos.oltp メソッドを使用して Spark プールからアクセスされるため、Analytics ストアが有効になっています。