アクセス パターンを分析する

Google Cloud consoleの [アクセス パターン] ページを使用して、アプリケーションが Bigtable でデータを読み書きする方法を視覚的に分析できます。また、Cloud Monitoring API をプログラムで呼び出して、基盤となるアクセス パターンの指標をクエリすることもできます。

このドキュメントを読む前に、読み取り、書き込み、モニタリングを確認してください。

概要

Bigtable は、受信データ リクエストを Cloud Monitoring のクエリタイプに自動的に分類します。ワークロードのアクセス パターンは、さまざまなクエリタイプの組み合わせです。たとえば、ワークロードのアクセス パターンは、ポイント読み取り、ショート スキャン、ポイント書き込みのクエリタイプで構成されます。Bigtable では、10 種類のクエリタイプが定義されています。

[システム分析情報] ページには全体的なリソース使用率が表示され、Key Visualizer には Bigtable が行キー範囲全体にトラフィックを分散する方法が表示されます。[アクセス パターン] ページには、クラスタ、テーブル、アプリ プロファイルのレベルで、ワークロードのクエリ中心の内訳が表示されます。[アクセス パターン] ページでは、次のタスクを行うことができます。

  • ワークロードを把握する: 各クラスタの読み取り、書き込み、読み取り / 書き込みクエリタイプの割合とレートを表示し、テーブルまたはアプリ プロファイルごとに指標をグループ化します。
  • 非効率なクエリパターンを検出してレイテンシのトラブルシューティングを行う:
    • 選択フィルタやガベージ コレクションを待機している未収集のセルが原因で、Bigtable が返す行数やセル数よりも大幅に多くの行やセルをスキャンするスパース読み取りを特定する
    • フォワード スキャンよりも効率が低いリバース スキャンをモニタリングする
    • サーバーサイドのレイテンシのパーセンタイルを、スキャンされた行、返された行、表示されたセルと比較して、レイテンシの急増の原因となっているアクセス パターンを特定します。
  • 機能の導入に適したワークロードを特定する:
    • Enterprise Plus エディションのインメモリ ティアのメリットを享受できる、ポイント読み取り量の多いテーブルまたはアプリ プロファイルを特定する
    • Data Boost サーバーレス コンピューティングを使用して、サービス提供トラフィックから分離できる大規模なスキャンまたはバッチ読み取りワークロードを特定する

制限事項

Bigtable は、Bigtable 用 GoogleSQL クエリをアクセス パターンとして分類せず、行、セル、バイトのアクセス パターン指標にこれらのクエリを含めません。[QPS 分布]、[QPS]、[レイテンシ] のグラフでは、SQL クエリとその他の未分類のリクエストが QUERY_TYPE_UNKNOWN として表示されます。

必要なロール

Google Cloud コンソールで [アクセス パターン] ページを表示するために必要な権限を取得するには、プロジェクトに対する次の IAM ロールを付与するよう管理者に依頼してください。

ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

これらの事前定義ロールには、 Google Cloud コンソールで [アクセス パターン] ページを表示するために必要な権限が含まれています。必要とされる正確な権限については、「必要な権限」セクションを開いてご確認ください。

必要な権限

Google Cloud コンソールで [アクセス パターン] ページを表示するには、次の権限が必要です。

  • インスタンスの詳細を表示します。 bigtable.instances.get
  • クラスタ、アプリ プロファイル、テーブルを一覧表示します。 bigtable.clusters.list, bigtable.appProfiles.list, bigtable.tables.list
  • Query Monitoring の指標: monitoring.timeSeries.list

カスタムロールや他の事前定義ロールを使用して、これらの権限を取得することもできます。

アクセス パターン

アプリケーションで Bigtable クライアント ライブラリを使用すると、クライアント ライブラリはメソッド呼び出しを Bigtable Data API リクエストに変換します。

Bigtable は、クライアント ライブラリのメソッド名だけでなく、次の要素に基づいて、完了後にサーバーで受信した各 Data API リクエストを分類します。

  • リクエスト パラメータ: リクエストが単一の行キー、複数の行キー、または行範囲をターゲットにしているかどうか、リクエストが reversed を設定しているかどうか、適用するフィルタ
  • 実行統計: スキャンされて返された行数とセル数、バイト ペイロード

たとえば、readRow などの単一行読み取りメソッドを呼び出すか、単一行キーで readRows を呼び出すと、Bigtable は通常、リクエストをポイント読み取りとして分類します。これは、インメモリ ティアの対象となります。ただし、その単一行読み取りで複雑なフィルタを使用するか、多数のセルをスキャンする場合、Bigtable はそれをスパース読み取り、一括読み取り、またはその他の読み取りとして分類することがあります。逆に、readRows を呼び出して複数の行キーを読み取るか、行範囲をスキャンすると、Bigtable はリクエストをバルクリードまたはスキャンとして分類します。これは、インメモリ ティアの対象外です。

読み取りの評価順序

1 つの ReadRows Data API リクエストが複数のカテゴリの特性に一致する可能性があるため、Bigtable は次の順序で読み取りリクエストを評価し、最初に一致したアクセス パターンを割り当てます。

  1. ポイント読み取り
  2. ショート スキャン(フォワード スキャンの場合)またはリバース ショート スキャン(reversed が true に設定されている場合)
  3. リバース スキャン(reversed が true に設定されている残りの読み取りリクエスト)
  4. スパース読み取り(一括読み取りの前に評価されるため、Bigtable は、マルチキー読み取りまたは大規模な前方スキャンを、重いフィルタの削除を伴うスパースとしてフラグを立てます)
  5. 一括読み取り
  6. その他の読み取り(残りの ReadRows リクエスト)

クエリタイプの定義

次の表に、各アクセス パターン カテゴリ、Monitoring の対応する query_type ラベル、適用される一般的なクライアント ライブラリ オペレーションと基盤となる Data API メソッド(method 指標ラベル)、Bigtable がリクエストをそのカテゴリに分類する方法を示します。メソッド名はプログラミング言語によって異なるため、表には代表的なクライアント ライブラリのメソッド名が記載されています。言語固有のコードサンプルについては、読み取りの例と書き込みの例をご覧ください。単純なフィルタと複雑なフィルタについては、このドキュメントの単純なフィルタと複雑なフィルタをご覧ください。

クエリの形式 query_type 指標ラベル クライアント オペレーションと Data API メソッド 分類の基準
ポイント読み取り QUERY_TYPE_POINT_READ

単一行の読み取り(readRow や単一キーの readRows など)

Data API: ReadRows

フィルタを使用しないか、単純なフィルタを使用する単一行キーの前方読み取り。スキャンされて返されるセルの数と合計レスポンス サイズは、小さな単一行の制限内に収まります。

ショートスキャン QUERY_TYPE_SHORT_SCAN

行範囲または接頭辞スキャン(単一の範囲または接頭辞を持つ readRows など)

Data API: ReadRows

フィルタを使用しない、または単純なフィルタを使用する、単一の連続した行範囲の前方スキャン。スキャンされて返される行数とセル数、および合計レスポンス サイズは、小さな制限内に収まります。

後方ショート スキャン QUERY_TYPE_REVERSE_SHORT_SCAN

リバース スキャン。たとえば、逆方向に単一の範囲または接頭辞を持つ readRows。

Data API: ReadRows

フィルタを使用しないか、単純なフィルタを使用し、ショート スキャンと同じ制限された行、セル、バイト数の範囲内にとどまる、単一の連続した行範囲のリバース スキャン。

リバース スキャン QUERY_TYPE_REVERSE_SCAN

リバース スキャン(逆方向の readRows など)

Data API: ReadRows

リバース ショート スキャンとして適格でないリバース読み取り。たとえば、ショート スキャンの行、セル、バイトの上限を超えるリバース スキャン、個々の行キーの指定、複数の行範囲のスキャン、複雑なフィルタの使用などです。

スパース読み取り QUERY_TYPE_SPARSE_READ

readRow または readRows を使用した、未収集のセルにわたるフィルタリングされた読み取りまたはスキャン

Data API: ReadRows

フィルタの削除やガベージ コレクションを待機している未収集のセルのために、Bigtable が返される行やセルよりも大幅に多くの行やセルをスキャンする前方読み取りリクエスト(ポイント読み取り、ショート スキャン、リバース スキャンの後に評価)。

一括読み取り QUERY_TYPE_BULK_READ

複数行の読み取り(複数キーの readRows や bulkReadRows など)、または readRow を使用した大規模な単一行の読み取り

Data API: ReadRows

フィルタなしまたは単純なフィルタで行キーを 1 つ以上指定する前方読み取り。ポイント読み取りの上限を超え(複数の行キーをリクエストする、大きな単一行を読み取るなど)、スパース読み取りとして適格でないもの。

その他の読み取り QUERY_TYPE_OTHER_READ

readRow または readRows を使用した大規模な範囲スキャン、マルチ範囲スキャン、またはフィルタされた読み取り

Data API: ReadRows

前述の読み取りカテゴリに一致しない ReadRows リクエスト。たとえば、大規模な前方範囲スキャン、マルチ範囲スキャン、行キーと行範囲を組み合わせたリクエスト、スパースとして適格でない複雑なフィルタを使用した読み取りなど。

ポイント書き込み QUERY_TYPE_POINT_WRITE

単純な書き込み、増分アップデート、または小規模なバッチ書き込み(mutateRow や bulkMutateRows など)

Data API: MutateRow、MutateRows

1 行の MutateRow リクエスト、または少数の行とセルを小さな合計バイト ペイロードで変更する小さな MutateRows バッチ リクエスト。

その他の書き込み QUERY_TYPE_OTHER_WRITE

bulkMutateRows や mutateRow などの大規模なバッチ書き込みまたは大規模な単純な書き込み

Data API: MutateRow、MutateRows

ポイント書き込みの上限を超える MutateRow リクエストまたは MutateRows リクエスト(大規模なバッチ書き込み、多数のミューテーションまたはバイト ペイロードを含む書き込みなど)。

読み取りと書き込み QUERY_TYPE_READ_WRITE

条件付き書き込みまたは追加(checkAndMutateRow、readModifyWriteRow など)

Data API: CheckAndMutateRow、ReadModifyWriteRow

ペイロード サイズに関係なく、条件付き書き込み(CheckAndMutateRow)またはアトミックな増分または追加(ReadModifyWriteRow)リクエスト。

リクエスト数とレイテンシの指標では、Bigtable は、Bigtable 用 GoogleSQL クエリなどの未分類のリクエストに QUERY_TYPE_UNKNOWN というラベルを付けます。

シンプルなフィルタと複雑なフィルタ

ポイント読み取り、ショート スキャン、リバース ショート スキャン、一括読み取りとして認定されるには、ReadRows リクエストでフィルタを使用しないか、単純なフィルタを使用する必要があります。

Bigtable では、次のフィルタタイプのみを単独で使用するか、制限付きの chain フィルタで組み合わせて使用する場合、フィルタを単純なフィルタとして分類します。詳細については、Chain をご覧ください。

  • フィルタなし(FILTER_NOT_SET)
  • pass_all_filter または block_all_filter
  • column_range_filter、column_qualifier_regex_filter、または family_name_regex_filter
  • cells_per_column_limit_filter、cells_per_row_limit_filter、または cells_per_row_offset_filter
  • timestamp_range_filter

Bigtable は、リクエストが上記のリストにないフィルタタイプ(次のようなフィルタタイプ)を使用している場合、または多数のフィルタを連結している場合、ReadRows リクエストを複雑なフィルタを使用しているものとして扱います。

  • value_regex_filter
  • value_range_filter
  • row_key_regex_filter
  • row_sample_filter
  • interleave
  • condition
  • sink
  • strip_value_transformer
  • apply_label_transformer

Bigtable は、reversed が true の場合は、このようなリクエストをリバース スキャンとして分類します。それ以外の場合は、スパース読み取り(返される行またはセルよりも大幅に多くの行またはセルをスキャンする場合)またはその他の読み取りとして分類します。

アクセス パターンを表示する

Google Cloud コンソールの [アクセス パターン] ページは、インスタンス レベルまたはクラスタレベルで表示できます。

インスタンスのアクセス パターンを表示する

  1. Google Cloud コンソールで、Bigtable インスタンスのリストを開きます。

    インスタンスのリストを開く

  2. 指標を表示するインスタンスをクリックします。

  3. ナビゲーション パネルの [オブザーバビリティ] で、[アクセス パターン] をクリックします。

  4. [クラスタ] リストで、アクセス パターンを検査するクラスタを選択します。デフォルトでは、 Google Cloud コンソールはインスタンスの最初のクラスタを選択します。

  5. [グループ化] リストで、グラフの内訳を選択します。

    • なし: すべてのグラフをアクセス パターン(QUERY_TYPE_POINT_READ など)で分類するデフォルトのオプション。
    • アプリ プロファイル: すべてのグラフをアプリケーション プロファイル ID とアクセス パターンの両方で分類します。
    • テーブル: すべてのグラフをテーブル ID とアクセス パターンの両方で分類します。
  6. 省略可: 期間を変更するか、自動更新を切り替えるには、期間セレクタを使用します。

クラスタのアクセス パターンを表示する

  1. Google Cloud コンソールで、Bigtable インスタンスのリストを開きます。

    インスタンスのリストを開く

  2. 指標を表示するインスタンスをクリックします。

    インスタンスの概要ページが開きます。

  3. クラスタ テーブルで、クラスタ ID をクリックします。

  4. ナビゲーション パネルで [アクセス パターン] をクリックします。選択したクラスタの指標がページに表示されます。

  5. [グループ化] リストで、グラフの内訳を選択します。

    • なし: すべてのグラフをアクセス パターン(QUERY_TYPE_POINT_READ など)で分類するデフォルトのオプション。
    • アプリ プロファイル: すべてのグラフをアプリケーション プロファイル ID とアクセス パターンの両方で分類します。
    • テーブル: すべてのグラフをテーブル ID とアクセス パターンの両方で分類します。
  6. 省略可: 期間を変更するか、自動更新を切り替えるには、期間セレクタを使用します。

アクセス パターン ページのグラフと指標

[アクセス パターン] ページには、次の指標のグラフが表示されます。

指標 対象 説明
QPS 分布 クラスタ
テーブル
アプリ プロファイル

クラスタの選択した期間全体で集計された 1 秒あたりのリクエスト数(QPS)の割合と平均レート。query_type と選択したグループ条件オプションで分類されます。

レイテンシ クラスタ
テーブル
アプリ プロファイル

サーバーサイド リクエストのレイテンシの経時変化。query_type と選択したグループ化オプションで分類されます。グラフのパーセンタイル メニューを使用して、99 パーセンタイル(デフォルト)、95 パーセンタイル、50 パーセンタイルを切り替えます。

QPS クラスタ
テーブル
アプリ プロファイル

1 秒あたりのリクエスト数の推移。query_type と選択したグループ化オプション別に分類されます。

返された行 クラスタ
テーブル
アプリ プロファイル

フィルタの適用後に、読み取りリクエストと読み取り / 書き込みリクエストに対して Bigtable がクライアントに返す 1 秒あたりの行数。

スキャンされた行数 クラスタ
テーブル
アプリ プロファイル

読み取りリクエストと読み取り / 書き込みリクエストの処理中に、フィルタを適用する前に Bigtable が 1 秒あたりに読み取る行数。[スキャンされた行] と [返された行] を比較すると、非効率な読み取りフィルタを特定できます。

変更された行 クラスタ
テーブル
アプリ プロファイル

書き込みリクエストと読み取り / 書き込みリクエストによって 1 秒あたりに変更された行数。

表示されたセル クラスタ
テーブル
アプリ プロファイル

読み取りリクエストと読み取り / 書き込みリクエスト中に、フィルタを適用する前に Bigtable が 1 秒あたりに検査するセルの数。これには、フィルタで除外されたセルや、ガベージ コレクションを待機しているセルも含まれます。

送信されたセル クラスタ
テーブル
アプリ プロファイル

フィルタの適用後に Bigtable がクライアントに返す 1 秒あたりのセル数。[表示されたセル] と [送信されたセル] を比較すると、返されたセルごとに多くのセルを検査する読み取りリクエストを特定できます。

送信バイト数 クラスタ
テーブル
アプリ プロファイル

1 秒あたりに返されるエンコードされた行データのバイト数。

また、Cloud Monitoring API を使用してこれらの指標をプログラムでクエリしたり、Metrics Explorer で表示したり、カスタム ダッシュボードに追加したりすることもできます。bigtable_table モニタリング対象リソースの各 bigtable.googleapis.com/query_type/* 指標には、次のラベルが含まれます。

  • リソースラベル: project_id、instance、cluster、table
  • 指標ラベル: query_type、app_profile、method

Monitoring で Bigtable 指標をクエリする方法については、Monitoring でモニタリングすると指標をご覧ください。

アクセス パターンに基づいてワークロードを最適化する

[アクセス パターン] ページの指標を使用して、次の決定を行うことができます。

  • 低レイテンシのポイント読み取り用にインメモリ ティアを有効にする: QPS 分布、QPS、レイテンシのグラフで、読み取りレイテンシの目標が厳しいテーブルまたはアプリ プロファイルで大量の QUERY_TYPE_POINT_READ リクエストが表示されている場合は、Enterprise Plus エディションで使用可能なインメモリ ティアを有効にすることを検討してください。グラフをテーブルまたはアプリ プロファイルでグループ化して、最も効果的なテーブルとワークロードを特定します。
  • Data Boost を使用して大規模なスキャンとバッチ読み取りを分離する: レイテンシの影響を受けやすいサービス提供トラフィックとクラスタを共有する QUERY_TYPE_BULK_READ リクエストまたは QUERY_TYPE_OTHER_READ リクエストの大量または定期的な急増が確認された場合は、アプリ プロファイルでグループ化して、スキャンのソースを特定します。バッチ、レポート、分析の読み取りを、Data Boost サーバーレス コンピューティングを使用するように構成された専用のアプリ プロファイルにルーティングします。これにより、大規模なスキャンが CPU リソースをめぐってサービス提供ノードと競合することがなくなります。
  • フィルタのオーバーヘッドを削減し、ガベージ コレクションを調整する: QUERY_TYPE_SPARSE_READ リクエストの割合が高い場合、スキャンされた行が返された行よりもはるかに多い場合、または表示されたセルが送信されたセルよりもはるかに多い場合、読み取りリクエストは Bigtable がクライアントに返さないデータをスキャンしています。読み取り効率を向上させるには、次の操作を行います。
    • 値や正規表現フィルタを使用して行を破棄するのではなく、読み取りリクエストで行キーの範囲または接頭辞を絞り込みます。
    • アプリケーションで最新のセル バージョンのみが必要な場合は、cells_per_column_limit_filter などのセル制限フィルタを含めます。詳細については、列あたりのセル数の上限をご覧ください。
    • 期限切れまたは古いセル バージョンが蓄積してスキャンが遅くならないように、ガベージ コレクション ポリシーを確認します。詳細については、ガベージ コレクションの概要をご覧ください。
  • リバーススキャンをフォワードスキャンに置き換える: QUERY_TYPE_REVERSE_SCAN リクエストまたは QUERY_TYPE_REVERSE_SHORT_SCAN リクエストが頻繁に発生し、レイテンシが増加している場合は、アプリケーションがフォワードスキャンを発行できるように行キーを設計することを検討してください。詳細については、スキーマ設計のベスト プラクティスをご覧ください。

次のステップ