[GCP入門] Cloud LoggingのログをCloud Storageへ転送する
この記事の概要
こんにちは。PharmaX でエンジニアをしている諸岡(@hakoten)です。
本記事では、Google CloudにおけるCloud LoggingからCloud Storageへのログ転送の仕組みについて、入門的な内容を紹介します。Google Cloudを利用している方やログ管理に興味のある方は、ぜひご覧ください。
YOJOプロダクトでのログの扱い
ログ転送のユースケース事例として、PhamaXのYOJOプロダクトにおけるログ管理の概要を説明します。
YOJOで管理されるログには、以下の種類があります。
- アプリケーションログ
- LLMなどの分析用ログ
- エラーログ
これらのログはすべてGoogle Cloud上で生成され、エラーログを除き、最終的にはGoogle BigQueryに転送されてデータ分析環境に集約されます。なお、エラーログの分析には現在、SentryというSaaSを利用しています。
構成は以下の図のようになります。
YOJOプロダクトでは、患者さんとのやり取りに使用されるLINEのチャットを処理する「メッセージワーカー」や、薬剤師がチャットの返信やその他の管理作業を行う「管理者アプリケーション」があり、これらはGoogle CloudのCloud Runサービスを利用しています。また、バックエンドにはCloud FirestoreとCloud SQL(PostgreSQL)をデータベースとして使用しています。
ここからは、上記のGoogle Cloud LoggingからCloud Storageへログを転送する方法について説明していきます。
Cloud Loggingのルーティング(シンク)の概要
前提として、Google Cloudのログルーティングの仕組みについて簡単に説明します。
Cloud Loggingのログを転送する仕組みとして「ログルーター」という機能があります。また、このログルーターを使用して、ログを転送するための制御の仕組みを「シンク(sink)」と呼びます。シンクを利用することで、Cloud Loggingに保存されたログをCloud StorageやBigQueryなどへ転送することができます。
上記の図のとおり、1つのGoogle Cloudプロジェクトには、あらかじめ「_Required」と「_Default」の2つのシンクが作成されています。
簡単に説明すると、_Requiredシンクから転送される_Requiredログバケットには以下のような監査系のログが含まれます。
- 管理アクティビティ監査ログ
- システムイベント監査ログ
- Google Workspace管理者監査ログ
- Enterpriseグループ監査ログ
- ログインの監査ログ
これに対し、_Defaultログバケットには、上記以外のログが保存されます。
このように、シンクを使用することで、Cloud Loggingで流れたログを任意の場所に転送し、ログの制御を行うことができます。
アプリケーションログをCloud Storageへログを転送する
Google Cloudを利用してアプリケーションを構築している場合、アプリケーションログはCloud Loggingにより管理されますが、シンクを利用することで、以下のような様々なリソースに任意のログを転送することができます。
- Cloud Loggingバケット
- BigQueryデータセット
- Cloud Storageバケット
- Pub/Subトピック
YOJOでは、Cloud Storageをアプリケーションログの永続的なアーカイブ環境として利用し、必要な情報のみを分析用データとしてBigQueryへ転送するという方式を取っています。
ちなみに、BigQueryへの転送方法は様々あります。Cloud Loggingバケットから転送する方法や、BigQueryへの転送用シンクを作成して直接ログをBigQueryのデータセットへ転送する方法など色々な方法で転送が可能ですので、各開発チームの要件に合わせて柔軟に構築すると良いかと思います。
Google Cloudコンソールから作成
Google Cloudコンソールからシンクを作成するのは次のような手順になります。
- シンクを作成するには、「ロギング」 -> 「ログルーター」を選択してください。
- 画面上部の「シンクを作成」するボタンを押下します。
- 「シンクの宛先」にログを転送する宛先のCloud Storageを選択してください。
- 転送する対象のログはあらかじめシンク上でフィルタすることが可能です。ここには、Cloud Loggingのクエリ を記入すると対象の抽出ログのみ転送することができます。
例えば、Cloud Runアプリケーションのログを転送する場合は次のようになります。
resource.type="cloud_run_revision"
- ログ全体から除外したいフィルタを設定することも可能です。
設定はこれだけで、作成後は自動的にCloud Storageへログが転送されます。
Terraformによるリソース管理
最後に、Terraformを使用してIaC(Infrastructure as Code)管理を行う方法について説明します。以下の設定例では、Cloud Loggingのフィルタをコンソールで指定したものと同様に設定することができます。なお、リソースの作成には「ログ構成書き込み(roles/logging.configWriter)」のロールが必要です。
resource "google_logging_project_sink" "cloud_run_sink" {
name = "cloud-run-sink"
destination = "storage.googleapis.com/${google_storage_bucket.sink-storage-bucket.name}"
filter = "resource.type = \"cloud_run_revision\""
project = <your-project-id>
}
resource "google_storage_bucket" "sink-storage-bucket" {
name = "sink-storage-bucket"
location = "asia-northeast1"
project = <your-project-id>
}
詳細は、公式のリファレンスも参照ください。
終わりに
以上、シンクを使ったCloud Loggingからのログルーティング設定についての説明でした。Google Cloudのログ設定に慣れていない方にもお役に立てれば幸いです。
PharmaXでは、様々なバックグラウンドを持つエンジニアの採用をお待ちしております。
弊社はAI活用にも力を入れていますので、LLM関連の開発に興味がある方もぜひ気軽にお声がけください。
もし興味をお持ちの場合は、私のXアカウント(@hakoten)や記事のコメントにお気軽にメッセージいただければと思います。まずはカジュアルにお話できれば嬉しいです!
![PharmaXテックブログ](https://storage.googleapis.com/zenn-user-upload/avatar/d155219d95.jpeg)
PharmaXエンジニアチームのテックブログです。エンジニアメンバーが、PharmaXの事業を通じて得た技術的な知見や、チームマネジメントについての知見を共有します。 PharmaXエンジニアチームやメンバーの雰囲気が分かるような記事は、note(note.com/pharmax)もご覧ください。
Discussion