Google Cloud でログ運用管理をする上で知っておくべき基礎知識

はじめに

Google Cloud でシステムを運用する際、ログの適切な管理は欠かせません。

ログを収集する目的はさまざまです。

• 迅速なトラブルシュート
• セキュリティインシデントの追跡
• 監査のためのアーカイブ
• リアルタイム振る舞い検知
• etc

ログはこれらの目的に合わせて適切に運用管理をする必要があります。
運用管理の適切な設計ができていないと「有事の際に必要なログが見つからない」「大量の不要ログの収集がコストを圧迫している」といった課題に直面します。

Google Cloud では Cloud Logging というサービスを中心にログ運用管理を行います。Cloud Logging は Google Cloud の各サービスとシームレスに連携し、セットアップ不要で利用が開始できるサービスです。

適切なログ運用管理を実現するためには、Cloud Logging のアーキテクチャを理解することが重要です。

本ブログでは、Cloud Logging におけるログ運用管理の仕組みを以下の観点から解説します。

• ログがどのように生成されるのか
• ログはどのように転送・保存されるのか
• 組織やフォルダレベルでログをどのように運用するのか
• ログ運用管理の目的に応じたコスト最適化のためにどのような選択肢があるのか

Google Cloud のログ運用管理の設計にお役立ていただければ幸いです。

ログの生成

Cloud Logging では Google Cloud 上の様々なログを取得することができます。取得するログの種類によって Cloud Logging 上での扱いが変わります。ここでは 監査ログ と 監査ログ以外のログ の2種類に大別して説明します。

監査ログ

Cloud Audit Logs というサービスで生成されるログです。API 操作ログや Google Cloud のシステムイベントログなどが Cloud Audit Logs で生成されます。Cloud Audit Logs で生成したログは Cloud Logging に連携されます。

Cloud Audit Logs の詳細な解説、Cloud Logging へどのように連携されるか、費用はどれぐらいかかるか、など以下ブログに纏めていますのでご参照ください。

https://dev.classmethod.jp/articles/google-cloud-cloud-audit-logs/

監査ログ以外のログ

Google Cloud の様々なサービスやアプリケーションで生成されたログは Cloud Logging に連携されます。ここでは代表的なログ連携方法について説明します。

Compute Engine

Compute Engine 上の OS システムログやジャーナルログなど、VM インスタンス上で発生するログは Ops エージェント をインストールすることによって Cloud Logging に連携できます。

Ops エージェントによって標準出力 stdout と標準エラー出力 stderr がデフォルトで収集されるため、アプリケーションは通常のログ出力を行うだけで Cloud Logging に連携できます。

Cloud Logging クライアントライブラリ

Logging クライアントライブラリを利用することでアプリケーションから直接 Cloud Logging にログを連携することができます。

Python、Java、Node.js、Go など主要な言語のクライアントライブラリが提供されており、コード内から柔軟にログを送信できます。

サーバーレス / GKE

Cloud Run、Vertex AI Agent Engine といったサーバレスサービスのランタイム環境や、GKE クラスタはログ連携のための構成が不要で、標準出力を Cloud Logging に自動的に送信します。

ネットワークログ

VPC フローログやファイアウォールルールのロギングを有効化した場合にサンプリングされるパケットのログも Cloud Logging に自動で連携されます。

ログの転送と保存(基本アーキテクチャ)

次に、Cloud Logging に連携されたログがどのように転送・保存されるのか、その仕組みについて説明していきます。

ログシンク

ログ収集対象のリソースから Cloud Logging に連携されたログは ログルーター で処理されます。ログルーターでは ログシンク と呼ばれる「どこにどのようなログを保存するか」の転送ルールが定義されており、このルールに従ってログが転送されます。

ログシンクと転送先の関係は1対1であり、一つの転送先に対し一つのログシンクが必要となります。

ログ転送と保存のアーキテクチャ

デフォルトで _Required, _Default の2種類のログシンクがあり、これらの転送先として _Required, _Default という同名の ログバケット にそれぞれ転送されます。

ログバケット

ログバケット とはCloud Logging 専用のストレージ領域である ログストレージ 上のバケットです。このログバケットに保存されたログは、GUI ツールである ログエクスプローラー から手軽に検索や分析が行えるようになります。
逆にいうとログエクスプローラーから検索するには、このログバケットにログを保存する必要があります。

ログエクスプローラー画面

ログのフィルタ

ログシンクでは、どのログを転送の対象とするかを 包含フィルタ 、どのログを転送の除外対象とするかを 除外フィルタ で定義します。条件式は Logging のクエリ言語 を使って表現します。

2つのデフォルトログシンク/ログバケットについて

_Required

_Required ログシンクは以下の包含フィルタが設定されています。

LOG_ID("cloudaudit.googleapis.com/activity") OR LOG_ID("externalaudit.googleapis.com/activity") OR LOG_ID("cloudaudit.googleapis.com/system_event") OR LOG_ID("externalaudit.googleapis.com/system_event") OR LOG_ID("cloudaudit.googleapis.com/access_transparency") OR LOG_ID("externalaudit.googleapis.com/access_transparency")

この条件によって Cloud Audit Logs(監査ログ)のうち、「管理アクティビティ監査ログ」「システムイベント監査ログ」「アクセスの透明性ログ」という種類のログがマッチします。

これらのログは _Required ログバケットに転送され 無償で400日間保存 されます。保存期間の変更やフィルタの設定変更はできません。

_Default

Default ログシンクは以下の包含フィルタが設定されています。

NOT LOG_ID("cloudaudit.googleapis.com/activity") AND NOT LOG_ID("externalaudit.googleapis.com/activity") AND NOT LOG_ID("cloudaudit.googleapis.com/system_event") AND NOT LOG_ID("externalaudit.googleapis.com/system_event") AND NOT LOG_ID("cloudaudit.googleapis.com/access_transparency") AND NOT LOG_ID("externalaudit.googleapis.com/access_transparency")

_Required の包含フィルタの否定文となっており、Required に転送されるログ以外のすべてのログ が _Default の対象となります。

これらのログは _Default ログバケットに転送され 有償で保存されます。 デフォルトでは 30 日間の保存期間になっていますが設定変更が可能です。また、フィルタの設定変更も可能です。

デフォルトのログシンクとログバケットについて以下にまとめます。

また、上記以外にカスタムログシンクを作成することが可能です。カスタムログシンクでは、ログフィルタと合わせて任意の転送先を指定できます。サポートされている転送先は以下です。

• ログバケット
• BigQuery データセット
• Cloud Storage バケット
• Pub/Sub トピック
• Google Cloud プロジェクト(対象プロジェクトで再ルーティングする場合に利用)

組織・フォルダレベルのログ運用

組織やフォルダ配下の複数プロジェクトのログを一元管理する必要がある場合に有用な機能として ログスコープ や 集約シンク があります。

ログスコープ

ログスコープ は、複数のプロジェクトのログバケットに分散したログをまとめて参照できる機能です。

ログエクスプローラーから複数プロジェクトのログを横断的に検索・分析できるため、以下のような場合に有効です。

• プロジェクトを横断したトラブルシュート
• 組織全体のセキュリティイベント分析
• マイクロサービスアーキテクチャでの統合ログ確認

ログスコープの対象とできるリソースはプロジェクトと ログビュー です。

ログビュー とは、ログバケット内のログに対してフィルタリングやアクセス制御を行うための仮想的なビューです。1つのログバケットに複数のログビューを作成でき、ログビューごとに IAM を使用したアクセス制御が可能です。

ただし、ログビューとプロジェクトは合わせて最大 100 個までログスコープに含めることができますが、プロジェクトは 5 つまでという制限があります。

集約シンク

組織やフォルダ配下の複数プロジェクトで発生したログを効率的に集約する機能として 集約シンク があります。

集約シンクは組織またはフォルダのみで有効化できるログシンクです。配下のリソースで発生したログを集約し、特定のプロジェクトのログバケットや Cloud Storage、BigQuery、Cloud Pub/Sub などに転送できます。たとえば、監査用の長期保管のためにログ管理用プロジェクトの Cloud Storage バケットに複数プロジェクトのログを一元的に集約したり、Cloud Pub/Sub 経由で Microsoft Sentinel や Splunk などの外部 SIEM に効率的に連携するような場合に利用します。

集約シンクでも包含フィルタ、除外フィルタを設定することができ、特定のログのみを転送できます。なお、集約シンクで転送されたログの保存料金は転送先のプロジェクトで発生します。

集約シンクの方式には「非インターセプト」と「インターセプト」の2つの方式があります。

非インターセプト

非インターセプト方式は、プロジェクトのログを複製して転送します。 集約シンクの対象ログは、ログ発生元のプロジェクトと転送先のプロジェクト両方にログが残るため、プロジェクト側でもログ分析が必要なケースで利用できます。ただし、ログ発生元プロジェクトと転送先プロジェクトでログ保存料金がかかるため注意が必要です。

インターセプト

インターセプト方式は、プロジェクトのログを移動して転送します。 集約シンクの転送対象となったログは集約シンクで転送し、集約シンクの転送対象ではないログのみプロジェクト上のログシンクで転送します。プロジェクト上ではログ分析が不要な監査ログなどの長期保管対象の転送に利用できコスト圧縮が図れます。なお、 _Required の転送対象となるログはプロジェクト上にも保存されます。 インターセプトされたログはプロジェクト側でのログ分析に利用できない点は注意が必要です。

コストの考慮

ログの運用管理においてコストは重要な検討事項です。活用できないログをとりあえず溜めておき不要なコストが発生しないよう目的に応じた保存戦略を決定しましょう。特に Cloud Logging の料金は念頭に置いておくとよいでしょう。

Cloud Logging 料金

Cloud Logging ログバケットへのストリーミングと保存に費用がかかります。ログシンクを利用した転送自体には費用はかかりません。また、前述のとおり _Required に対する料金はかかりません。

一度きりの課金とはなりますがストリーミングの単価が高いため、大量のログをログバケットに保存する場合は注意が必要です。Cloud Logging 料金が気になる場合は、短期のトラブルシュートで利用しないログや長期保管のみを目的とするようなログについてはログバケットではなく保存単価の安い Cloud Storage バケットに転送するといった保存戦略も必要かもしれません。

参考までに Cloud Storage の料金を記載します。

参考: Cloud Storage 料金

• Standard

• Nearline

• Coldline

• Archive

料金についての詳細は以下をご参照ください。

Cloud Logging 料金
Cloud Storage 料金

ログ運用管理の戦略

ここまで説明してきた Cloud Logging のアーキテクチャやコストを念頭にログ運用管理の戦略について考えていきます。
目的に応じて最適な保存先や運用方法を選択し、目的の達成とコストのバランスを最適化することが重要です。

ここから示すのはあくまでも一例ですので、組織のログ運用管理の参考にしていただけましたら幸いです。

目的に応じたログ保存先の例

プロジェクトを横断したログ運用方法の例

おわりに

本記事では、Google Cloud でログを運用管理するうえで必要となる Cloud Logging の基本的なアーキテクチャやコストについて説明しました。

ログは有事の際に重要な情報源となる一方で、適切に管理しないとコスト増につながる可能性もあります。本記事が Google Cloud における最適なログ運用管理の一助となれば幸いです。