メイン コンテンツにスキップ

 Subscribe

この記事は、2 つのパートから成るシリーズのパート 2 で、組織が Azure Cosmos DB を使用して実世界のニーズを満たす方法と、それが生み出す違いについて説明します。パート 1 では、Microsoft Office ライセンス サービス チームが、Azure Table Storage から Azure Cosmos DB に移行する原因となった課題と、チームが新しいサービスに運用ワークロードを移行した方法について説明しました。パート 2 では、チームの取り組みの成果について考察します。

最小限の労力で最大のメリット

Microsoft Office ライセンス サービス (OLS) チームの Azure Table Storage から Azure Cosmos DB への移行はシンプルでわかりやすく、チームが最小限の労力ですべてのニーズを満たすことを可能にしました。

簡単な移行

Azure Cosmos DB への移行において、Table API のおかげで、OLS チームはほとんどのデータ アクセス コードを再利用できました。また、ダウンタイムを回避するために作成した移行エンジンは、短時間で簡単に構築できました。

OLS 開発チームをリードする、マイクロソフトのソフトウェア エンジニアの Danny Cheng 氏は、次のように説明しています。

「移行エンジンは、私たちが記述する必要のあった、唯一の実際の‘新しいコード’です。そして、3 つの構成要素すべてのコード サンプルは公開されているため、一から開始しなければならないということがありませんでした。全体として、私たちが開発した移行ツールに必要だったのは、3 人の開発者と、それぞれに 4 週間の時間だけです。」

ほぼ無制限のスループット

現在、データベース スループットは OLS チームにとってもはや問題ではありません。Table Storage では、ストレージ アカウントあたり 1 秒に 20,000 回の操作というスループット制限があったため、18 個のテーブルのそれぞれを異なるストレージ アカウントで維持して、最大スループットを実現する必要がありました。チームは今では 1 つの Azure Cosmos DB アカウントを維持しており、そこではスループットの上限はなく、テーブルあたり 1 秒に 1,000 万回の操作をサポートします。すべてが専用で、SLA によって裏打ちされています

保証された高可用性

Azure Cosmos DB は、OLS チームにすべてのマルチリージョン アカウントに対する 99.999% の読み取り可用性 SLA を提供します。これは、ストレージのサービス品質 (QoS) の大幅な向上につながります。このことは、社内で開発されたツールを使用してキャプチャされた以下の指標で示されています。

「ピーク トラフィック時には、Azure Cosmos DB は Table Storage の時よりもはるかに高いストレージ QoS を提供します」と Cheng 氏は述べています。「現在私たちはファイブ ナイン (99.999%) を達成しています。以前はスリー ナイン (99.9%) くらいでした」

Azure Cosmos DB の正常性と Azure Table Storage の正常性のグラフ。

Azure Cosmos DB の正常性と Azure Table Storage の正常性の平均値。

自動フェールオーバー

OLS チームは今では、自動または手動のフェールオーバーを構成して、リージョンの障害が万一発生した場合に保護を提供すると同時に、すべての SLA を維持できます。また、チームはマルチリージョンのアカウントに対してフェールオーバーの優先順位を付けたり、手動のフェールオーバーをトリガーして OLS のエンドツーエンドの可用性をテストしたりすることもできます。

「私たちは自動フェールオーバーを構成していますが、サービスの信頼性が非常に高いため、まだ必要としていません」と Cheng 氏は言います。

待機時間の短縮

Table Storage では、待機時間の上限がありませんでした。それとは対照的に、Azure Cosmos DB は読み取り/書き込みに対して 1 桁の待機時間を提供します。これは、世界中どこでも規模を問わない 99 パーセンタイルで 10 ミリ秒未満の読み取り/書き込みの待機時間の保証によって裏付けられています。以下の指標は、OLS サービスにおいて、Table Storage と Azure Cosmos DB で発生する待機時間の違いを示しています (DbTable は Azure Table Storage で CosmosDbTable は Azure Cosmos DB Table API です)。

待機時間の違い:  Azure Cosmos DB と Azure Table Storage。

ターンキー型のデータ分散

Table Storage では、グローバル分散のオプションは限られていました。さらに、OLS チームは独自のフェールオーバーを実装できませんでした。Azure Cosmos DB によって、チームは今では任意の数のリージョンへの分散を実現しています。これにはマルチマスター機能が含まれ、この機能を有効にすると、任意のリージョンで書き込み操作を受け入れるようにすることができます。

「マップ上でクリックするだけで、データを世界中のどの Azure リージョンにでも自動的にレプリケートできます」と Cheng 氏は述べています。「この機能は大変便利なので、もうすぐ使用する予定です」

その他の技術的メリット

上記に加えて、Azure Cosmos DB は OLS チームに、Table Storage よりも優れた以下のような追加のメリットがあります。

自動インデックス作成。Table Storage では、プライマリ インデックスは PartitionKey と RowKey に限定され、セカンダリ インデックスはありません。Azure Cosmos DB では、既定ですべてのプロパティにおいて自動および完全なインデックス作成が提供され、インデックス管理は必要ありません。

クエリ時間の短縮。Table Storage では、クエリの実行にプライマリ キーに対してはインデックスが使用され、それ以外ではスキャンが行われます。Azure Cosmos DB では、クエリですべてのプロパティにおける自動インデックス作成を活用できるため、クエリ時間の短縮を実現できます。

整合性。Table Storage では、OLS チームはプライマリ リージョン内での厳密な整合性と、セカンダリ リージョン内での最終的な整合性に限定されていました。Azure Cosmos DB では、ソリューション設計時に明確に定義された整合性レベルから選択することができ、読み取りの整合性と、待機時間、可用性、およびスループットとの間のトレードオフを最適化することができます。

今すぐ Azure Cosmos DB をご利用ください

  • Explore

     

    Let us know what you think of Azure and what you would like to see in the future.

     

    Provide feedback

  • Build your cloud computing and Azure skills with free courses by Microsoft Learn.

     

    Explore Azure learning


Join the conversation