Stackdriver コストの最適化

Stackdriver Logging、Stackdriver Monitoring、Stackdriver APM は、アプリサービスとインフラストラクチャ サービスを詳細に観察できるように設計されたクラウドベースのマネージド サービスです。Google Cloud Platform(GCP)上のマネージド サービスの利点の 1 つは、サービスが使用量に基づいていることです。つまり、使用した分に対してのみ料金が発生します。この料金設定モデルは、標準のソフトウェア ライセンスと比較してコストメリットがありますが、コストを予測するのは難しくなります。このソリューションでは、Stackdriver の使用量を把握し、コストを最適化する方法について説明します。

Stackdriver の料金設定について

Stackdriver スイート内のサービスのそれぞれはマネージド サービスです。そのため、これらのサービスを利用するために必要なインフラストラクチャではなく、Logging、Monitoring、APM から得られる分析情報の活用に集中できます。Stackdriver サービスを使用すると、仮想マシン、ソフトウェア ライセンス、セキュリティ スキャン、ハードウェア メンテナンス、データセンター内のスペースの料金を個別に支払う必要はありません。Stackdriver マネージド サービスはシンプルな従量課金です。

Stackdriver のコストには、Stackdriver TraceStackdriver ProfilerStackdriver Error ReportingStackdriver Debugger を含む LoggingMonitoringAPM の料金が含まれます。Profiler と Error Reporting はまだベータ版のためコストがかからず、Debugger も無料で使用できます。

Logging のコスト

Logging 料金は、取り込まれた課金対象ログのボリュームに基づきます。このプロダクトの料金設定はシンプルな GiB あたりの従量制課金です。毎月の無料割り当て量があり、Cloud Audit Logging などの特定のログは課金対象外です。

追加のログボリュームを通してコストが発生するプロダクトの使用例を以下に示します。

  • Cloud Load Balancing
  • Compute Engine 上の Logging エージェント
  • Amazon Web Services(AWS)上の Logging エージェント
  • Stackdriver Logging API での書き込み操作

Monitoring のコスト

Monitoring 料金は、課金対象指標の取り込み量と課金対象 API の呼び出し回数に基づきます。たとえば、エージェント、カスタム、外部、AWS 指標などの非 GCP 指標は課金対象です。Stackdriver Monitoring API の projects.timeSeries.list メソッドは API 呼び出しによって課金されますが、残りの API の使用は無料です。これは毎月の無料指標割り当て数であり、すべての GCP 指標を含む、多くの指標が課金対象外です。課金対象の指標に関する詳細については、Stackdriver の料金設定をご覧ください。

指標の数と API 呼び出しによるコストが発生するプロダクトの使用例を以下に示します。

  • Monitoring カスタム指標
  • Compute Engine 上の Monitoring エージェント
  • AWS 上の Monitoring エージェント
  • Monitoring API での読み取り操作

Trace のコスト

Trace 料金は、取り込まれたスパンとその後スキャンされたスパンの数に基づきます。App Engine スタンダード環境などの一部の GCP サービスでは、課金対象外のスパンが自動的に生成されます。Trace には毎月の無料割り当て量があります。

取り込まれたスパン数によるコストが発生するプロダクトの使用例には、以下のインストゥルメンテーションの追加が含まれます。

  • デフォルト スパン以外の App Engine アプリ用のスパン
  • Cloud Load Balancing
  • カスタム アプリ

Stackdriver の使用量について

Stackdriver の使用量を把握することで、Stackdriver スイートのどのコンポーネントでコストが発生しているかに関する分析情報を得ることができます。これは、最適化に適した領域の特定に役立ちます。

GCP 請求書分析

使用量を把握するための最初のステップは、GCP 請求書を確認して、Stackdriver 関連コストを把握することです。分析情報を得るための 1 つの方法は、Google Cloud Platform Console で利用可能な請求レポートを表示することです。

レポートのページには、時間、プロジェクト、プロダクト、SKU、ラベルで結果を絞り込むための便利なフィルタが用意されています。具体的に請求データを Stackdriver 関連コストに絞り込むには、すべての Stackdriver プロダクトを選択してからプロダクト別にグループ分けするプロダクト フィルタを追加します。次の図に示す結果のグラフには、Stackdriver プロダクト全体のコストの内訳が示されています。

Stackdriver によるコストの内訳

Logging

Logging は、ログの詳細なリスト、今月の現在までの使用量、今月の予想使用量をプロジェクトごとに提供します。プロジェクトごとにこれらの詳細を確認しながら、GCP 請求書上の Logging 料金を確認できます。これにより、使用量が最高(コストが最大)のログを簡単に確認できます。

プロジェクトで取り込まれたログ容量は、Logging の [ログの取り込み] セクションで確認できます。ログビューアには、ログの一覧、前月の取り込みログ容量、今月初めからの取り込みログ容量量、除外された取り込みログ容量、月末(EOM)までの予想ログ容量が表示されます。次の図では、各ログが Monitoring にリンクされています。Monitoring には、一定期間のログのボリュームのグラフが表示されます。

ログリンクを伴うログビューア

この分析を使用すれば、特定のプロジェクトでのログの使用量と使用量の経時変化に関する情報を得ることができます。この分析を使用して、最適化を検討する必要のあるログを特定できます。

Monitoring

Monitoring により、プロジェクトの詳細なリストと、先月の取り込み量、今月初めからの取り込み量、月末までの予想取り込み量がワークスペースに整理して表示されます。 次の図に示すように、Stackdriver ワークスペースには複数のプロジェクトが含まれていることもあるため、取り込み量はプロジェクトごとに表示されます。

複数のプロジェクトを伴うワークスペース

Workspace Monitoring の使用量の詳細を検索する方法を学びます。

Monitoring の Metrics Explorer で各プロジェクトの指標ボリューム指標の詳細なグラフを表示できます。これにより、一定期間にわたって指標の取り込み量に関する分析情報が得られます。

この分析では、特定した各プロジェクトの Monitoring 指標取り込み量を確認しながら、GCP 請求書上の Monitoring 料金を確認できます。その後で、特定の指標取り込み量を確認して、取り込み量とコストが最大のコンポーネントを把握できます。

Trace

Trace は、今月と先月に取り込まれたスパンの詳細なビューを提供します。GCP Console で特定したプロジェクトごとにこれらの詳細を確認しながら、GCP 請求書上の Trace 料金を確認できます。

この分析は、Stackdriver ワークスペース内の特定したプロジェクトごとに取り込まれたスパン数だけでなく、GCP 請求書上の Trace 料金も提供します。この分析を使用すれば、取り込まれた特定のスパン数を確認して、スパンとコストが最大のプロジェクトとサービスを把握できます。

Logging エクスポート

Logging には、Cloud StorageBigQueryCloud Pub/Sub にログをエクスポートするためのログシンクがあります。これらのエクスポートに関連したコストは、それぞれのプロダクトのコストに反映されるため、標準の Stackdriver 料金設定には含まれません。

たとえば、長期保存と分析のためにすべての Stackdriver ログを BigQuery にエクスポートする場合は、GiB 単位のストレージとクエリのコストを含む、BigQuery のコストが発生します。

エクスポートで発生するコストを把握するには、次のステップを考慮してください。

  1. ログシンクを探す。有効にしたログシンクがある場合は検索します。たとえば、プロジェクトには、セキュリティ操作のためや規制要件を満たすためなどのさまざまな目的で作成されたログシンクがすでに存在している場合があります。
  2. 使用量の詳細を確認する。エクスポート先の使用量を確認します。たとえば、BigQuery エクスポート用の BigQuery テーブルサイズや Cloud Storage エクスポート用のバケットサイズを確認します。

ログシンクを探す

ログシンクは、プロジェクト レベルで存在する(プロジェクトごとに 1 つ以上のシンク)場合もあれば、GCP 組織レベルで存在する(集約エクスポートと呼ばれる)場合もあります。シンクに同じ GCP 組織内の複数のプロジェクトのログが含まれていることもあります。

特定のプロジェクトを調査することで、ログシンクを確認できます。GCP Console には、シンクと宛先のリストが表示されます。組織の集約エクスポートを表示するには、gcloud logging sinks list --organization ORGANIZATION_ID コマンドラインを使用します。

使用量の詳細を確認する

Monitoring は、アプリだけでなく GCP プロダクトの使用量についても豊富な指標を提供します。Monitoring Metrics Explorer で使用量指標を表示することにより、Cloud Storage、BigQuery、Cloud Pub/Sub の詳細な使用量指標を取得できます。

Cloud Storage

Monitoring の Metrics Explorer を使用することにより、Cloud Storage バケットのストレージ サイズを確認できます。Metrics Explorer 内の次の値を使用して、ログシンクに使用された Cloud Storage バケットのストレージ サイズを確認します。

Metrics Explorer ページに移動

  1. [Resource type] に「gcs_bucket」 と入力します。
  2. [Metric] に「storage.googleapis.com/storage/total_bytes」と入力します。
  3. 次のフィルタを追加します。

    1. project_id をクリックしてから、GCP プロジェクト ID を選択します。
    2. dataset_name をクリックしてから、Cloud Storage エクスポート バケット名を選択します。

Cloud Storage バケットのストレージ サイズ

前のグラフは、一定期間にエクスポートされたデータのサイズを KB 単位で示しています。ここから、Cloud Storage への Logging エクスポートの使用量に関する分析情報が得られます。

BigQuery

Monitoring の Metrics Explorer を使用することにより、BigQuery データセットのストレージ サイズを表示できます。Metrics Explorer 内の次の値を使用して、ログシンクに使用された BigQuery データセットのストレージ サイズを確認します。

Metrics Explorer ページに移動

  1. [Resource Type] に「bigquery_dataset」と入力します。
  2. [Metric] に「bigquery.googleapis.com/storage/stored_bytes」と入力します。
  3. 次のフィルタを追加します。

    1. project_id をクリックしてから、GCP プロジェクト ID を選択します。
    2. dataset_id をクリックしてから、BigQuery エクスポート データセット名を選択します。
  4. [Group By] に「dataset_id」と入力します。

BigQuery データセットのストレージ サイズ

前のグラフは、一定期間のエクスポート データセットのサイズを GB 単位で示しています。ここから、BigQuery への Logging エクスポートの使用量に関する分析情報が得られます。

Cloud Pub/Sub

Monitoring の Metrics Explorer を使用することにより、Cloud Pub/Sub にエクスポートされたメッセージの数とサイズを表示できます。Metrics Explorer 内の次の値を使用して、ログシンクに使用された Cloud Pub/Sub トピックのストレージ サイズを確認します。

Metrics Explorer ページに移動

  1. [Resource type] に「pubsub_topic」と入力します。
  2. [Metric] に「pubsub.googleapis.com/topic/byte_cost」と入力します。
  3. 次のフィルタを追加します。

    1. project_id をクリックしてから、GCP プロジェクト ID を選択します。
    2. topic_id をクリックしてから、Cloud Pub/Sub エクスポート トピック名を選択します。

Cloud Pub/Sub トピックのストレージ サイズ

前のグラフは、一定期間にエクスポートされたデータのサイズを KB 単位で示しています。ここから、Cloud Pub/Sub への Logging エクスポートの使用量に関する分析情報が得られます。

Stackdriver のコスト管理の実装

以下のオプションは、Stackdriver のコストを削減する可能性のある方法を示しています。各オプションでは、アプリやインフラストラクチャに関して限られた分析情報しか得られません。可観測性とコストのバランスが最もよいオプションを選択してください。

Logging のコスト管理

Logging の使用量を最適化するには、Logging に取り込まれるログの数を減らします。デベロッパーやオペレーターに必要なログを維持しながら、ログ数を減らすのに役立ついくつかの戦略があります。

ログを除外する

デベロッパーやオペレーション チームに必要のないログのほとんどを Logging や Error Reporting から除外できます。

ログの除外は、ログが Logging UI や Error Reporting UI に表示されないことを意味します。ロギング フィルタを使用して、除外する特定のログエントリまたはログ全体を選択できます。サンプリング除外ルールを使用して、一定の割合のログエントリを除外することもできます。たとえば、ボリュームの多さや実用的価値のなさに基づいて特定のログを除外するように選択できます。

一般的な除外例を以下に示します。

  • Cloud Load Balancing からのログを除外する。ロードバランサは、トラフィックの多いアプリの場合に大量のログを生成する可能性があります。たとえば、ログフィルタを使用して、Cloud Load Balancing からのメッセージの 90% を除外するように設定できます。
  • Virtual Private Cloud(VPC Service Controls)フローログを除外する。フローログには、VPC Service Controls ネットワーク内の仮想マシン間の通信ごとのログが書き込まれます。そのため、大量のログが生成される可能性があります。ログ数を減らすには次の 2 つの方法があります。これらを一緒に使用することも別々に使用することもできます。

    • ログエントリの内容によって除外する。役に立つかもしれない特定のログメッセージだけを残し、ほとんどの VPC フローログを除外します。たとえば、外部ソースからの着信トラフィックを受信する必要のないプライベート VPC がある場合は、外部 IP アドレスからのソース フィールドを含むフローログだけを保持します。
    • 割合によって除外する。もう 1 つの方法は、フィルタによって特定された一定の割合のログだけをサンプリングすることです。たとえば、フローログの 95% を除外し、5% だけを保持します。
  • リクエストログから HTTP 200 OK レスポンスを除外する。アプリでは、HTTP 200 OK メッセージからあまり多くの分析情報を得られない場合があります。しかも、トラフィックの多いアプリの場合は大量のログが生成される可能性があります。

ロギング除外を実装するには、ログの除外をご覧ください。

ログをエクスポートする

ログをエクスポートすることで、それらを Logging への取り込みから除外できます。この方法を使用すれば、Logging からログを除外しながら、Cloud Storage と BigQuery でログを保持したり、Cloud Pub/Sub を使用してログを処理したりすることができます。これにより、コストが削減されます。つまり、ログは Logging に表示されずに、エクスポートされます。

この方法は、Logging への取り込みのコストをかけずに長期分析用にログを保持するために使用します。除外とエクスポートの相互作用の詳細については、ログのエクスポートの概要図(Life of a log)をご覧ください。この図は、エクスポートされたログエントリが Logging でどのように処理されるかを示しています。

Logging からのエクスポートを実装するには、Logging をエクスポートするための設計パターンの手順に従ってください。

Logging エージェントの使用量を減らす

Logging エージェントによって生成された追加のログを Logging に送信しないことにより、ログボリュームを減らすことができます。Logging エージェントは、Apache、Mongodb、MySQL などの一般的なサードパーティ アプリからログをストリーミングします。

たとえば、開発環境やその他の Logging に必要のない環境内の仮想マシンに Logging エージェントを追加しないことを選択することにより、ログ数を減らすことができます。仮想マシンは、引き続き、標準ログを Logging に報告しますが、サードパーティ アプリや syslog からのログは報告しません。

Monitoring のコスト管理

Monitoring の使用量を最適化するには、Monitoring に取り込まれる課金対象指標の数と Monitoring API への読み取り呼び出しの回数を減らします。デベロッパーやオペレーターに必要な指標を維持しながら、指標ボリュームを減らすのに役立ついくつかの戦略があります。

Stackdriver の指標数とラベルの使用量を最適化する

GCP コンポーネントにラベルを使用する方法は、Monitoring で指標に対して生成される時系列の使用量に影響を与える可能性があります。

たとえば、次の図に示すように、VM 上のラベルを使用して、GCP 請求書上のコストセンターに指標を適切に報告し、特定の GCP 環境が本番か開発かを示すことができます。

Google Kubernetes Engine クラスタ上のラベル

これらのラベルの追加は、Monitoring で新しい時系列が生成されることを意味します。仮想マシンに cost_centerenv の値でラベルを付けると、両方のラベルのカーディナリティを掛けて時系列の総数を計算できます。

total_num_time_series = cost_center_cardinality * env_cardinality

11 個の cost_center 値と 5 個の env 値がある場合は、55 個の時系列が生成されます。これが、ラベルを追加する方法では指標ボリュームが大幅に増え、コストが増大する理由です。指標カーディナリティの詳細については、Stackdriver のヒントとアドバイス: 指標の理解とチャートの作成に関するブログ投稿をご覧ください。

追加の時系列を最小限に抑えるために、次のことをおすすめします。

  1. 可能な限り、ラベルの数を制限します。
  2. 高いカーディナリティのラベル値を避けるようにラベル値を慎重に選択します。たとえば、IP アドレスをラベルとして使用すると、IP アドレスごとに 1 つずつの時系列が作成されます。そのため、VM の数が多ければ、大量の時系列が生成されます。
Monitoring エージェントの使用量を減らす

Monitoring エージェントから送信される指標は課金対象指標です。Monitoring エージェントは、Apache、MySQL、Nginx などの一般的なサードパーティ アプリからのアプリ指標とシステム指標の他に、追加の GCP VM レベルの指標もストリーミングします。詳細なシステム指標やサードパーティ アプリからの特定の VM に関する指標が必要ない場合は、このような指標を送信しないことにより、使用量を減らすことができます。Monitoring エージェントを使用する VM の数を少なくすることで指標数を減らすこともできます。

たとえば、開発環境やその他の Monitoring に必要のない環境内の GCP プロジェクトを追加しないことを選択することにより、指標数を減らすことができます。さらに、開発環境やその他の必要のない環境内の VM に Monitoring エージェントを含めないように選択することもできます。

カスタム指標の使用量を減らす

カスタム指標は、Monitoring API を使用して、ユーザーがインストゥルメント化した指標を監視することによって作成される課金対象指標です。この種の指標は、Monitoring API を使用するか、Stackdriver に統合されたツールを使用することにより、作成できます。

そのようなツールの 1 つが OpenCensus です。OpenCensus は単一配布のライブラリで、アプリから指標と分散トレースを収集します。OpenCensus でインストゥルメント化されたアプリは、カスタム指標を使用することにより、Stackdriver を含む複数のバックエンドに指標を報告できます。これらの指標は、Monitoring の custom.googleapis.com/opencensus プレフィックス リソースタイプに表示されます。たとえば、OpenCensus から報告されたクライアントの往復レイテンシは、Monitoring の custom.googleapis.com/opencensus/grpc.io/client/roundtrip_latency リソースタイプに表示されます。

指標を送信するためにインストゥルメント化されたアプリが多いほど、より多くのカスタム モニタリング指標が生成されます。指標ボリュームを減らすには、アプリから送信されるカスタム モニタリング指標の数を減らします。

Trace のコスト管理

Trace の使用量を最適化するには、取り込まれるスパン数とスキャンされるスパン数を減らします。スパンを Trace に報告するようにアプリをインストゥルメント化した場合は、サンプリングを使用してトラフィックの一部を取り込みます。サンプリングは、RPC 呼び出しなどのアプリ コンポーネントによって引き起こされるレイテンシの内訳に関する分析情報が得られるため、トレース システムの重要な部分です。これは Trace を使用するためのベスト プラクティスであるだけでなく、コスト削減の目的でスパン数を減らすことにもなります。

OpenCensus サンプリングを使用する

OpenCensus トレース用のエクスポート先として Trace を使用する場合は、OpenCensus のサンプリング機能を使用して、取り込まれるトレースの数を減らすことができます。

たとえば、5000 クエリ/秒を誇る人気のウェブアプリがある場合は、アプリ トラフィックの 20% ではなく 5% のサンプリングで十分な分析情報を得ることができます。これにより、Trace に取り込まれるスパンの数が 4 分の 1 に減少します。

Trace 用の OpenCensus Python ライブラリを使用することにより、インストゥルメンテーション構成でサンプリングを指定できます。として、OpenCensus Python エクスポータは、サンプリング レートの指定に使用可能な ProbabilitySampler を提供します。

from opencensus.trace.samplers import probability
from opencensus.trace import tracer as tracer_module

# Sampling the requests at the rate equals 0.05
sampler = probability.ProbabilitySampler(rate=0.05)
tracer = tracer_module.Tracer(sampler=sampler)
Stackdriver Trace API スパン割り当てを使用する

割り当てを使用して、Trace の使用量とコストを制限できます。GCP Console の API 固有の割り当てページでスパン割り当てを強制できます。

特定の割り当てをデフォルトのプロダクト割り当てよりも低く設定すると、プロジェクトで特定の割り当て制限を超えないようにすることができます。この方法でコストを確実に想定内に抑えることが可能になります。この割り当ては、次の図に示すように、API 固有の割り当てページからモニタリングできます。

API 固有の割り当てページのモニタリング

スパン割り当てを減らす場合は、Monitoring でのスパン割り当ての指標のモニタリングとアラート ポリシーの設定を検討し、使用量が割り当てに近づいたときにアラートを送信するようにする必要もあります。このアラートは、使用量を調べて、大量のスパンを生成しているアプリとデベロッパーを特定するように促します。設定したスパン割り当てを超えた場合は、割り当てを調整するまでスパンがドロップされます。

たとえば、スパン割り当てが取り込みスパン 50 M の場合は、API 割り当ての 80%(40 M)のスパンを使用したときにアラートを送信するように設定できます。以下に示すアラート ポリシーの管理手順に従って、アラート ポリシーを作成します。

Monitoring に移動

  1. [Resource type] に「global」と入力します。
  2. [Metric] に「cloudtrace.googleapis.com/billing/monthly_spans_ingested」と入力します。
  3. 次の [Filter] 値を追加します。

    1. project_id をクリックしてから、GCP プロジェクト ID を選択します。
    2. chargeable をクリックしてから、true を選択します。
  4. [Configuration] セクションで、次のフィールドに値を入力します。

    1. [Condition triggers if] で、[Any time series violates] を選択します。
    2. [Condition] で、[is above] を選択します。
    3. [Threshold] に「40000000」と入力します。
    4. [For] フィールドで、[most recent value] を選択します。

アラート ポリシーから生成されるアラートは、次のアラートのようになります。アラートでは、プロジェクトに関する詳細、アラートを生成したアラート ポリシー、指標の現在の値を確認できます。

アラートの詳細

サードパーティの呼び出し元を最適化する

アプリが他のアプリから呼び出される場合があります。アプリがスパンを報告する場合、アプリから報告されるスパンの数はサードパーティ アプリから受信される着信トラフィックによって異なります。たとえば、チェックアウト マイクロサービスを呼び出すフロントエンド マイクロサービスがあり、その両方が OpenCensus でインストゥルメント化されている場合は、トラフィックのサンプリング レートは少なくともフロントエンドのサンプリング レートと同じくらい高くなります。インストゥルメント化されたアプリがどのように相互作用するかを理解することで、取り込まれたスパンの数の影響を評価できます。

Logging エクスポート

Logging エクスポートに関連したコストが懸念される場合の 1 つの解決策は、ログフィルタを使用して、エクスポートするログの数を減らすようにログシンクを更新することです。不要なログをエクスポートから除外できます。

たとえば、Compute Engine 上で実行されるアプリを有し、さらに Cloud SQL、Cloud Storage、BigQuery を使用している環境では、エクスポートするログに含める情報をそれらのプロダクトに関する情報のみに制限することが考えられます。次のフィルタを使用すると、Cloud Audit Logging、Compute Engine、Cloud Storage、Cloud SQL、BigQuery のログのみがエクスポートされます。このフィルタをログシンクとして使用し、選択したログのみを含めることができます。

logName:"/logs/cloudaudit.googleapis.com" AND
(resource.type:gce OR
resource.type=gcs_bucket OR
resource.type=cloudsql_database OR
resource.type=bigquery_resource)

まとめ

Logging、Monitoring、APM スイートは、プロダクトの使用量データを表示する機能を備えているため、プロダクトの使用量の詳細を把握できます。この使用量データを使用すれば、使用量とコストを適切に最適化するようにプロダクトを構成できます。

次のステップ