Microsoft AzureのNoSQLデータベース「Cosmos DB」における運用時の考慮ポイントを知る

Microsoft AzureのNoSQLデータベース「Cosmos DB」を使ってみよう 第5回

　Microsoft Azureの提供するNoSQLデータベースPaaS、「Cosmos DB」について紹介します。前回はCosmos DBに入ったデータを操作する実装を行いました。最終回である今回は、運用編としてCosmos DBを本番運用で利用する際の考慮ポイントやノウハウについて紹介します。

対象読者

• Microsoft Azureや他のクラウドサービスを利用している方
• NoSQLデータベースを利用している方
• Cosmos DBの仕組みを理解したい方

スループットに関する検討事項

　Cosmos DBのスループットの上限はRUで決定します。スループットを向上させる最も単純な方法はRUを上げる（スケールアップする）ことですが、RUを上げることは利用料金が上がることになるため、ここでは現在のスループットの調べ方や他のアプローチでスループットを向上させる方法について説明します。

現在のスループット使用量を調べる

　Azureポータル上のCosmos DBコンソールでは、コレクションの利用状況をグラフで確認することができます。アプリケーション全体での性能テスト等で、Cosmos DBがボトルネックとなっていないかを確認する際に有用です。

　AzureポータルからCosmos DB、データベースアカウントを選択し、メニューから［メトリック］をクリックするとグラフが表示されます。以下の図は、スループットを400RU/sに設定しているコレクションに対して約1時間にわたって一定の負荷（DocumentDB APIのアップサート処理）をかけた際のメトリックです。

図1　コレクションのメトリック画面

　それぞれの項目について説明していきます。

　「1分あたりの要求の数」は、コレクションに対して1分間にリクエストされたデータ操作の数を表します。図中では負荷をかけている時は約0.8千で推移しているため、1分間に約800回のAPI実行を受け付けていることが分かります。

　「1分あたりに容量を超過した要求の数」は、コレクションに割り当てたRU/sを超えてリクエストを受け取った際に、Cosmos DBがエラーとして返却したリクエストの数を表しています。

　「物理パーティションごとの使用された最大RU/秒」では、コレクションに割り当てられているパーティションのうち1つのRU/sの使用量を表示します。「パーティションごとのプロビジョニング」（濃紺の線）はパーティションに割り当てられているRU/sで、「パーティションごとの使用」（水色の線）が実際に消費しているRU/sです。図のコレクションはパーティション分割なしのコレクションのため、コレクションに設定したスループット（400RU/s）と「パーティションごとのプロビジョニング」の値が同じになります。このケースでは、400RU/sの割り当てに対して600RU/s近いリクエストが発生しているため、スケールアップや後述するスループットを向上させる対応が必要であることが推測できます。

　以下の図2はパーティション分割ありのコレクションの場合のグラフです。コレクションのスループットを2500RU/sで作成してパーティションが10個に分割されたとすると、グラフには250RU/sの「パーティションごとのプロビジョニング」が表示されます。

図2　パーティション分割コレクションの場合のあるパーティションのメトリック

　「1分あたりに容量を超過した要求の数」では設定したRU/sを超過した際にエラーとなってしまったリクエスト数が分かるのに対し、このグラフでは超過した際の最大RU/sがどれくらいであったかを把握することができます。

　「（指定した時間）の各物理パーティションによる1秒あたりの最大消費RU」は、時間を指定し、ピンポイントでパーティションごとのRU/sの消費量を調べることができるグラフです。このグラフでは「物理パーティションごとの使用された最大RU/秒」のグラフとは違い、全てのパーティションの情報を表示することができます。パーティション分割コレクション（2500RU/s）でのグラフの見え方は図3のようになります。

図3　パーティション分割コレクションの場合の各パーティションのメトリック

インデックス作成ポリシーの変更によるスループットの向上

　スループットを向上させるには、ドキュメントの書き込みと読み取りのそれぞれについて検討する必要があります。Cosmos DBでは「インデックス作成ポリシー」を変更することでスループットに影響を与えることができます。ドキュメントの書き込みには「インデックス作成モード」が、読み込みには「インデックス化するパスの指定」が関係します。

　インデックス作成ポリシーについては、本連載の第2回で取り上げているので、こちらもご確認ください。

ドキュメントを単純化する、クエリを単純化する

　DocumentDB APIにおける、SQLクエリを実行した際のRUの消費量には、ドキュメントのサイズやクエリの複雑さなどが関係しています。ドキュメントサイズは、大きければ大きいほどRUの消費量が増加します。RUを抑えるためには、ドキュメント設計の段階でフィールド数を抑えたドキュメント定義をすることや、ドキュメント取得のクエリで射影（SELECT）を使って取得するドキュメントのフィールド数を減らすなどの対応をします。

　クエリの複雑さは、IDを検索条件としたクエリ（WHERE c.id = 'xxx'）がその他のフィールドを使った検索や集約関数を使ったクエリに比べて最もRUの消費量が少なく、クエリを実行することができます。これはRDBMSのSQLと同様に、構文解析や実行計画の構築に要するリソースがSQLの複雑さに関係していることと同じと考えることができます。

　使用しているSQLの統計情報を取得する方法や、パフォーマンスの計測方法などについては、Cosmos DBのドキュメントに詳しくまとめられているので、クエリチューニングの際に参照してください。