Microsoft AZ-204: Azure Cosmos DB — 学習ガイド

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

こちらの一部です： Microsoft Azure Developer Associate AZ-204 — 学習ガイド. 検証済みの解答で練習： Microsoft試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

Azure Cosmos DBは、フルマネージドでグローバルに分散された、マルチモデルデータベースです。低レイテンシーで弾力的にスケーラブルなアプリケーション向けに設計されています。共通のパーティション化されたストレージおよびレプリケーションエンジン上で複数のAPIを公開し、5つの調整可能な整合性レベルを提供し、可用性、レイテンシー、スループット、整合性に関する包括的なSLAを提供します。データは、アカウント、データベース、コンテナー（APIによってはコレクション/テーブル/グラフ）に整理されます。コンテナーはパーティションキーによって水平にパーティション分割およびスケーリングされ、すべての操作はリクエストユニット（RU）で測定されます。RUは、CPU、IOPS、メモリを抽象化する正規化された通貨です。

APIとプログラマビリティ

Cosmos DBは、いくつかのワイヤ互換APIをサポートしているため、データモデルを書き直すことなくネイティブのSDKやドライバーを使用できます。

• SQL (Core) API: 新しいワークロードに推奨されるデフォルトです。豊富なSQLライクなクエリ（ドキュメント内のSELECT、WHERE、ORDER BY、JOIN、集計）を持つJSONドキュメントを格納し、計算された述語/射影のための決定論的なUDFをサポートします。サーバーサイドのビジネスロジックは、単一の論理パーティション内でJavaScriptのストアドプロシージャおよび事前/事後トリガーとして実行され、パーティションキーを共有する複数の項目にわたるACIDトランザクションを可能にします。TransactionalBatchは、パーティション内での複数項目の操作を提供します。ポイント読み取り（id + パーティションキー）が最もRU効率が高いです。new CosmosClient(endpoint, key)のようなコードで.NETクライアントを作成します。

• MongoDB API: MongoDBとワイヤ互換であり、標準のMongoDBドライバーやツール（例えば、移行用のmongodump/mongorestore）の使用を可能にします。Cosmos DBの分散、自動スケーリング、SLAに支えられたMongoDBの機能を使用できます。複数ドキュメントのトランザクションは、同じ論理パーティション内でサポートされます。ユーザーごとの厳密な原子性を確保するには、非シャードコレクションを使用するか、usernameなどのプロパティでシャーディングして、関連ドキュメントがパーティションを共有するようにします。

• Cassandra API: Apache CassandraドライバーおよびCQLと互換性があります。ワイドカラムや時系列のアクセスパターンに最適です。ノード管理の代わりに、自動的なグローバル分散とRUベースのスケーリングを利用できます。

• Gremlin API: TinkerPop Gremlinクエリとトラバーサルを備えたプロパティグラフモデルです。スケーラブルなトラバーサルのためには、頂点とエッジを分散させるパーティショニングが不可欠です。

• Table API: Azure Table Storage互換のSDKとセマンティクスを持つキーバリューモデルですが、Cosmos DBのグローバル分散、RUスループット、低レイテンシーのインデックスに支えられています。

API間で共通のSDK操作には、CRUD、ETagによるオプティミスティック同時実行制御、アップサート、サーバーサイドスクリプト（ストアドプロシージャ、トリガー）、およびUDF（SQL API）が含まれます。クエリはパラメータ化され、RUを削減しセキュリティを向上させます。一括操作とストリーミングAPIは、高スループットの取り込みにおいて、クライアントのオーバーヘッドとRUコストを最小限に抑えます。

整合性、インデックス作成、クエリセマンティクス

Cosmos DBは、アカウントごとに5つの明確に定義された整合性レベルを提供します（多くのSDKではリクエストごとにオーバーライド可能）。

• Strong (強固): 線形化可能性—読み取りは、グローバルで最新のコミットされた書き込みを認識します。正確性を最大化しますが、書き込みレイテンシーとリージョンの柔軟性を制限し、複数リージョンでの書き込みが有効な場合は利用できません。

• Bounded Staleness (有界整合性): 読み取りは、書き込みに対して最大でKバージョンまたはT時間遅れます。単調な読み取りと書き込みの順序を保証します。限定的な遅延を許容できるグローバル分散読み取りにとって、良いトレードオフです。

• Session (セッション、デフォルト): セッションごとに、Read-your-writes（自身の書き込みの読み取り）、Write-follows-reads、単調な読み取りを保証します。各クライアントはセッショントークンを維持します。これをノード間で共有する（例えば、SDKのリクエストオプション経由で）ことで、それらのノード間でRead-your-writesが維持されます。

• Consistent Prefix (一貫性のあるプレフィックス): 読み取りは順序が狂った書き込みを観測することはありませんが、ログのプレフィックスを見る可能性があります。

• Eventual (最終的): 順序の保証なしで、最高の可用性と最低のレイテンシーを提供します。

SQL APIでは、デフォルトでインデックス作成は自動的かつ一貫性があります。すべての項目とプロパティがスキーマ管理なしでインデックス付けされ、書き込みは即座にインデックスを更新します（インデックス作成モードはConsistent）。インデックス作成ポリシーを調整して、以下を行うことができます。

• RUの書き込みコストを下げるために、大きいパスや書き込みの多いパスを除外する。
• 複数のプロパティに対する効率的なORDER BYや、異なるプロパティにまたがるフィルターとソートを組み合わせたクエリをサポートするために、複合インデックスを追加する。
• GeoJSONタイプ（Point、LineString、Polygon、MultiPolygon）に空間インデックスを追加し、ST_DISTANCE、ST_WITHIN、ST_INTERSECTSなどの空間関数でクエリする。 インデックス作成モードは、id/パーティションキーのみで読み取られる書き込み最適化コンテナーに対してNoneに設定することもできます。異なるAPIは、それぞれのネイティブなパラダイム（例：MongoDBやCassandraのドライバー構成）を介してインデックス作成を公開しますが、すべてが基盤となるCosmosのインデックス作成エンジンを活用します。

項目のサイズとクエリの形状に注意してください。SQL APIは項目サイズ制限（例：2MB）を強制し、クロスパーティションクエリ、大きなプロジェクション、複雑な述語はRU消費を増加させます。選択的なプロジェクション、適切なフィルター、パーティションを意識したクエリを使用して、RUコストを最小限に抑えます。

パーティション分割とスループット (RU)

Cosmos DBは、論理パーティションと物理パーティションを分離しています:

• 論理パーティションは、パーティションキーの値によって項目をグループ化します。同じキーを共有するすべての項目は、トランザクションバッチやサーバーサイドスクリプトに一緒に参加します。
• 物理パーティションはサービスによって管理され、多数の論理パーティションをホストします。スループット (RU) とストレージは物理パーティション全体に分散されます。「ホット」な論理パーティションは、物理パーティションのスループットのボトルネックになる可能性があります。

カーディナリティが高く、時間の経過とともにアクセスが均等に分散される効果的なパーティションキーを選択してください。優れたキーは、プライマリアクセスパス (例: userId, deviceId, tenantId, orderId) と相関しています。スキュー (偏り) を引き起こすような、カーディナリティの低いキーや時間で区切られたキー (例: country, status, day) は避けてください。単一のプロパティが適切でない場合:

• 複数のプロパティを連結した合成キーを使用します。
• プレフィックスによるクエリ実行可能性を維持したり、ルックアップを保持したりしながら、ランダムまたはハッシュ化されたサフィックスを追加して、パーティション全体に負荷を分散させます。
• 階層パーティションキーを検討して複数のプロパティを組み合わせ、より良い分散と効率的なプレフィックスクエリを可能にします。

スループットモデル:

• プロビジョニング済みスループット: コンテナーまたはデータベース (子コンテナーで共有) に RU/s を予約します。コストが安定し、パフォーマンスが予測可能です。手動または API/CLI を介してスケーリングします。
• 自動スケーリング: 最大 RU/s を設定します。Cosmos DB は負荷に応じて、その最大値の 10% から 100% の間で弾力的にスケーリングします。1時間あたりの最大 RU 使用量に基づいて課金されます。変動の激しいワークロードや未知のピークに最適です。
• サーバーレス: プロビジョニングされた RU/s はありません。操作ごとの RU 消費量に対して支払います。開発、突発的、または予測可能なベースラインのない低スループットのワークロードに最適です。

RU の最適化手法には、id+パーティションキーによるポイントリード、パラメーター化クエリ、選択的プロジェクション、JOIN のようなパターンを減らすための非正規化、複雑な複数コンテナーのクエリの代わりに派生ビューのために変更フィードを使用することなどが含まれます。RU を大量に消費する再試行を避けるため、同時実行制御には If-Match とともに ETags を使用します。RU メトリクスとスロットリング (HTTP 429) を監視し、SDK でジッターを含む再試行ポリシーを実装します。

グローバル分散と変更フィード

Cosmos DBのターンキーなマルチリージョン分散機能により、いつでもリージョンを追加または削除できます。すべてのリージョンは読み取り可能であり、マルチリージョン書き込みを有効にすると、近接リージョンにおいて99パーセンタイルで10ミリ秒未満の読み取りレイテンシで、あらゆる場所で同時に書き込みが可能になります。クライアントSDKは、トラフィックをローカルにルーティングし、正常にフェイルオーバーするために、優先リージョンで設定する必要があります。.NETでは、CosmosClientOptionsのApplicationPreferredRegions（または他のSDKの同等の機能）を介して優先リージョンを指定します。マルチリージョン書き込みには、競合解決ポリシーが必要です。

• Last Write Wins（最終書き込み者優先）: 競合解決パス（例：タイムスタンプやバージョンプロパティ）を使用します。指定しない場合、システムタイムスタンプが使用されます。
• カスタム解決: マージストアドプロシージャを使用して、競合を決定論的に調整します。
• 手動: 競合フィードを調査し、明示的に解決します。

変更フィードは、論理パーティションキーごとに、順序付けられた追記専用の変更ログを提供します。以下のような用途に最適です。

• イベント駆動型アーキテクチャとCQRS（ドキュメントを読み取り最適化ビューに投影する）。
• ダウンストリームパイプライン（データレイクへの取り込み、検索インデックス作成、キャッシュの無効化）。
• ほぼリアルタイムの分析と監査。 主な利用パターンは2つあります。
• Change Feed Processorライブラリ: leasesコンテナーを使用してワーカー間でパーティションのバランスを取り、安全にスケールアウトする、分散型でフォールトトレラントな処理。
• FeedIteratorによるプルモデル: 自身で制御するチェックポイントロジックで変更を明示的に反復処理し、FeedRangeをまたいで作業をセグメント化して並列化します。 Azure Functionsは、サーバーレス処理のためにプロセッサーパターンをラップするCosmos DBトリガーを提供します。最初から、または「現在」から開始できます。また、完全忠実性変更フィードは、中間更新と削除をキャプチャして、完全な監査証跡を提供します。leaseコンテナーを十分なスループットで設計し、リトライと少なくとも1回の配信に対応するために、べき等なハンドラーを選択してください。

実践的な問題シナリオ

Spotifyは、ユーザーのインタラクションをリアルタイムで取り込み、ユーザーごとのレコメンデーションを更新し、最も近いリージョンから低レイテンシで読み取りを提供する、グローバルに利用可能なパーソナライゼーションサービスを提供する必要があります。書き込みは世界中のモバイルクライアントから発生する可能性があり、レコメンデーションの更新はダウンストリームシステムにファンアウトする必要があります。

1. マルチリージョン書き込みを備えたCosmos DB SQL (Core) APIを選択する

• 理由: Core APIは豊富なクエリとサーバーサイドのプログラマビリティを提供します。マルチリージョン書き込みは、グローバルでの書き込みレイテンシを最小限に抑え、書き込みのダウンタイムなしでリージョンのフェイルオーバーを許容します。

2. 高カーディナリティのパーティションキーと階層キーを定義する

• アプローチ: userIdでパーティション分割します。非常にアクティブなユーザーには、[“userId”, “bucket”]のような階層キーを使用します。ここで、bucketはハッシュのサフィックスです。
• 理由: 書き込みと読み取りの負荷を均等に分散し、ユーザーごとのトランザクション更新を可能にし、ホットパーティションを回避します。

3. プライマリコンテナーで自動スループットスケーリングを構成する

• 理由: トラフィックは日内変動し、キャンペーンに左右されます。自動スケーリングは、実際の負荷に比例したコストを維持しながら、設定された最大RU/sまでのバーストに対応します。

4. アカウントレベルで整合性をSessionに設定する

• 理由: モバイルクライアントは、Strongのレイテンシ制約なしで、ユーザーエクスペリエンスのためにread-your-writes（読み書き一貫性）を必要とします。セッショントークンは、クライアントとゲートウェイ層によって運ばれ、ノード間でセッションのセマンティクスを維持します。

5. Azure FunctionsとChange Feed Processorで変更フィード処理を実装する

• アプローチ: interactionsコンテナーにバインドされたCosmos DBトリガーを持つFunctionsアプリを作成します。専用のleasesコンテナーを使用し、並列処理のために複数のインスタンスを有効にします。
• 理由: これにより、マテリアライズドビュー（例：recommendationsコンテナー）を更新し、ストリーミング分析のためにEvent Hubsにイベントを発行するための、回復力があり、スケーラブルで、運用負荷の低い処理が提供されます。

6. カスタマイズされたインデックスポリシーを持つ派生recommendationsコンテナーを作成する

• アプローチ: 書き込み負荷の高い大きなプロパティをインデックスから除外します。TOP-Kクエリをサポートするために、(userId, score DESC)の複合インデックスを追加します。
• 理由: パーソナライズされたフィードのための効率的なソート済みルックアップを可能にしながら、RUの書き込みコストを削減します。

7. SDKで優先リージョンを指定してグローバル分散を有効にする

• アプローチ: 北米、ヨーロッパ、APACにリージョンを追加します。アプリのデプロイリージョンに基づいて、CosmosClientOptionsのApplicationPreferredRegionsを設定します。
• 理由: 読み取りがローカルで処理され、10ミリ秒未満のレイテンシが保証され、フェイルオーバーが透過的になります。

8. 競合解決と可観測性を構成する

• アプローチ: べき等な更新のためにサーバー生成の論理クロック（バージョンプロパティ）を持つLast Write Winsを使用し、まれなエッジケースのために競合を監視キューにルーティングします。
• 理由: 同時マルチリージョン書き込み下での決定論的な収束を保証し、運用上の可視性を提供します。

このアーキテクチャは、グローバルな低レイテンシの読み書き、変更フィードによる回復力のあるイベント処理、コスト効率の高い自動スケーリング、およびパーソナライゼーションワークロードに適した堅牢な整合性セマンティクスを提供します。

← Azure Storage と Blob Storage · すべてのドメイン · Azure コンテナーソリューション →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Microsoftを閲覧 →