Cloud Run設計と脆弱性管理入門

Google CloudのProfessional Cloud Developer認定試験では、単にアプリケーションを開発するだけでなく、運用性・セキュリティ・可観測性まで含めたクラウドネイティブなシステム設計が求められます。

特にCloud Runを中心としたアプリケーション開発では、ログ設計によるオブザーバビリティの確保、コンテナイメージの脆弱性管理、そしてサーバーレス環境に適したアプリケーション設計を理解しておくことが重要です。

本記事では、Cloud Loggingを活用したログ管理、Artifact Analysisによる脆弱性監視、Cloud Runの設計・デプロイ戦略という3つの重要テーマを取り上げます。

これらは試験で頻出するだけでなく、実際の開発現場でも求められる知識です。各サービスの役割とベストプラクティスを整理しながら、Professional Cloud Developer合格に必要なポイントを体系的に学んでいきましょう。

今回も音声ファイルも挿入していますので、ブログの内容を音声でご確認いただけます。通勤中などにご利用いただければと思います。

是非、最後までご覧いただけると嬉しいです。

Cloud Run × Cloud Logging 完全ガイド
Artifact Analysis 脆弱性メタデータ完全ガイド
Cloud Run アプリケーション設計・デプロイ完全ガイド
まとめ

Cloud Run × Cloud Logging 完全ガイド

Cloud Runでアプリケーションを運用する際、障害調査や性能分析を効率的に行うためには、適切なログ設計が欠かせません。しかし、サーバーレス環境では従来のようにログファイルをサーバーへ保存する運用は適しておらず、Cloud Loggingを前提とした設計が求められます。

本記事では、stdout/stderrを利用した基本的なログ出力から、構造化ログによる高度な検索・分析、さらにCloud Loggingクライアントライブラリを活用した実践的な運用方法までを解説します。

Cloud Runにおけるログ収集の仕組みを理解し、運用性と可観測性を高めるためのベストプラクティスを学んでいきましょう。

1. 基本編：コンテナの標準出力（stdout / stderr）を活用する

Cloud Runは、コンテナ内のアプリケーションが書き出す標準出力（stdout）と標準エラー出力（stderr）を自動的に監視し、すべてキャッチしてCloud Loggingにリアルタイムで転送します。

デフォルトでは、stdoutへの書き込みはINFOレベル、stderrへの書き込みはERRORレベルとしてCloud Loggingに記録されます。

＜JavaScript＞

// Node.js の例
// これだけでCloud Loggingの「INFO」に書き込まれる
console.log("ユーザーがログインしました。");

// これだけでCloud Loggingの「ERROR」に書き込まれる
console.error("データベースへの接続に失敗しました。");

アプリケーションを通常通り gcloud run deploy でデプロイするだけで、このログ収集基盤は自動的に有効になります。

2. 推奨編：stdoutへの構造化JSON出力

「標準出力に書くだけでは INFO しか出せない」と思われがちですが、それは誤りです。

stdoutであっても、JSON形式で severity フィールドを含む構造化ログを出力すれば、Cloud Loggingはそのseverityを正しく解釈します。構造化ログを書き込む場合は、アプリケーションをシリアライズされたJSONオブジェクトを書き込むように設定します。

この方法は外部ライブラリへの依存がなく、言語を問わず使えるため、Google公式が推奨する方法の一つです。

＜JavaScript＞

// Node.js：stdoutにJSONを書くだけで任意のseverityを指定できる
console.log(JSON.stringify({
  severity: "WARNING",
  message: "リソースが不足しています",
  userId: "user_123",        // 検索可能なカスタムフィールド
  requestId: "req_abc"
}));

console.log(JSON.stringify({
  severity: "ERROR",
  message: "データベース接続に失敗しました",
  errorCode: "DB_CONN_FAIL"
}));

＜Python＞

# Python：jsonモジュールだけで構造化ログ出力
import json, sys

def log(severity, message, **kwargs):
    entry = {"severity": severity, "message": message, **kwargs}
    print(json.dumps(entry))

log("INFO",    "ユーザーがログインしました", userId="user_123")
log("WARNING", "リソースが不足しています")
log("ERROR",   "処理が中断されました", errorCode="PROC_FAIL")

＜指定できる主なseverity値＞
DEBUG / INFO / NOTICE / WARNING / ERROR / CRITICAL

3. 応用編：Cloud Logging クライアントライブラリの導入

外部ライブラリを使うことで、JSON構築を自動化し、HTTPリクエストとログの自動紐付けなどより高度な機能を利用できます。エラーのスタックトレースが複数行に分割されてしまう問題の解消にも効果的です。

＜Python＞

# Python：Cloud Logging クライアントライブラリの例
import logging
import google.cloud.logging

# 1. Cloud Logging クライアントを初期化
client = google.cloud.logging.Client()

# 2. 標準の logging ハンドラをCloud Loggingに接続
client.setup_logging()

# 3. 通常通りロガーを使用（自動的にCloud Loggingに適した形式で送信される）
logging.info("通常のインフォメーションログ")
logging.warning("警告ログ：リソースが不足しています")
logging.error("エラーログ：処理が中断されました")

クライアントライブラリを使う主なメリット

リクエストとログの自動紐付け（Cloud RunのHTTPリクエストと処理ログを1画面で確認可能）
スタックトレースの自動まとめ（複数行エラーを1エントリとして記録）
ログメタデータの自動付与（trace ID等）

4. アプローチの選び方

アプローチ	難易度	外部依存	推奨シーン
stdout/stderr（テキスト）	最小	なし	開発・簡易ログ
stdout（構造化JSON）	低	なし	本番推奨・ライブラリ不要
Cloud Logging クライアントライブラリ	中	あり	リクエスト紐付けが必要な場合

5. デプロイとログ確認手順

ステップ1：デプロイの実行

＜gcloudコマンド＞

gcloud run deploy my-logging-app \
    --source . \
    --region asia-northeast1 \
    --allow-unauthenticated

ステップ2：Logs Explorerでの確認

resource.type="cloud_run_revision"
resource.labels.service_name="my-logging-app"

6. 運用のベストプラクティス

ログのバッファリングを無効化する（重要）

多くの言語（特にPython）では標準出力がバッファリングされており、クラッシュ直前のログが届かないことがあります。Dockerfileで以下を設定してください。

＜Dockerfile＞

# Python の場合（慣例として 1 を使用）
ENV PYTHONUNBUFFERED=1

Cloud Run × Cloud Logging 完全ガイドのまとめ

Cloud Runでは、stdoutやstderrへ出力したログが自動的にCloud Loggingへ転送されるため、ログファイルを管理する必要はありません。さらに、構造化JSONログを利用することで、ライブラリ不要でログレベルやカスタムフィールドを柔軟に扱えるようになります。

より高度な運用が必要な場合は、Cloud Loggingクライアントライブラリを導入することで、リクエストとの自動紐付けやスタックトレースの集約などの機能を活用できます。また、ログのバッファリング対策や適切なログレベル設計を行うことで、障害発生時の調査効率を大幅に向上できます。

これらのベストプラクティスを実践することで、Cloud Run上で信頼性の高いオブザーバビリティ基盤を構築できるようになるでしょう。

Artifact Analysis 脆弱性メタデータ完全ガイド

コンテナイメージの脆弱性管理では、「スキャンしたはずなのにレポートから結果が消えている」という事象に遭遇することがあります。これはArtifact Analysisのライフサイクル管理によるものであり、不具合ではありません。
Artifact Analysisでは、イメージのプッシュやプルを基準として脆弱性メタデータの継続監視期間が決められています。

そのため、長期間利用されていないイメージは監視対象から外れ、最終的にはメタデータが参照できなくなります。
本記事では、30日ルールと90日ルールの仕組みを解説するとともに、古いイメージの脆弱性情報を維持する方法や、オンデマンドスキャンの活用方法について詳しく解説します。

コンプライアンス対応や継続的な脆弱性管理を行うために、Artifact Analysisの正しい運用方法を理解しておきましょう。

1. なぜ30日以上経つとレポートから漏れるのか？（原因）

Artifact Analysisの「自動スキャン」は、リソース最適化のためにライフサイクルが設定されています。

自動スキャンの仕組み：イメージがArtifact Registryにプッシュされた瞬間、自動的に最初のスキャンが走ります。
30日間の継続的監視：スキャン後、Artifact Analysisは脆弱性ソースから1日に複数回新しい脆弱性情報を受け取り、既存の脆弱性occurrenceを更新・追加・削除しながら継続監視します。
30日後の停止：Artifact Analysisが継続監視するのは、過去30日以内にプッシュまたはプルされたイメージのみです。30日を過ぎると脆弱性メタデータの更新が停止し、結果は古くなります。
90日後のアーカイブ：さらに90日間古い状態が続くと、Artifact Analysisはメタデータをアーカイブします。アーカイブされたメタデータはコンソール・gcloud・APIで参照できなくなります。

経過時間	状態
プッシュ/プル後〜30日	継続的に監視・更新される
30日超〜90日	メタデータが古くなり更新停止
90日超	アーカイブされ参照不可

2. 解決策①（最も簡単）：イメージをプルして30日ウィンドウをリセットする

スキャン結果が古くなったイメージのメタデータを更新するには、そのイメージをプルするだけです。メタデータの更新には最大24時間かかります。

＜dockerコマンド＞

# イメージをプルするだけで30日の監視ウィンドウがリセットされる
docker pull asia-northeast1-docker.pkg.dev/my-project/my-repo/my-image@sha256:...

⚠️ 注意
古くなったりアーカイブされたパッケージは再スキャンできません。メタデータのアーカイブ（90日超）が進む前にプルで更新しておくことが重要です。

3. 解決策②：オンデマンドスキャン（On-Demand Scanning）の実行

ローカル環境やCI/CDパイプライン内でスキャンを任意のタイミングで実行したい場合は、オンデマンドスキャンが有効です。

⚠️ 重要な制約
オンデマンドスキャンの結果はスキャン完了後48時間しか保持されません。また、スキャン完了後に脆弱性情報が更新されることもありません。永続的な監視にはなりません。

ステップ1：APIの有効化と権限付与

＜gcloudコマンド＞

gcloud services enable ondemandscanning.googleapis.com

実行するユーザーまたはサービスアカウントに roles/ondemandscanning.admin（オンデマンドスキャン管理者）の付与を確認します。

ステップ2：オンデマンドスキャンの実行

＜gcloudコマンド＞

gcloud artifacts docker images scan [IMAGE_URI]
# 例: asia-northeast1-docker.pkg.dev/my-project/my-repo/my-image@sha256:...

ステップ3：スキャン結果の取得

スキャン完了後、出力されたスキャンのフルパスを使って結果を取得します。

＜gcloudコマンド＞

# scan の出力に含まれるフルパスを指定する
gcloud artifacts docker images list-vulnerabilities \
    projects/[PROJECT_ID]/locations/[LOCATION]/scans/[SCAN_ID]

4. 解決策の使い分け

状況	推奨する対処法
イメージが30日以内に古くなった（90日以内）	`docker pull` でリセット（最もシンプル）
CI/CDパイプラインでスキャン結果を確認したい	オンデマンドスキャン（48時間有効）
90日超のアーカイブ済みイメージを監視対象に戻したい	プルを試みる（ただし対象外になっている可能性あり）

5. 運用のベストプラクティス

定期的なプル自動化：本番で稼働中の重要なイメージは、30日ごとに自動プルするCronジョブを設定し、継続監視の対象に保ち続けます。これが最もコスト効率の良い方法です。
Artifact Registryのクリーンアップポリシーの活用：本番環境でも稼働しておらず、監視不要な古いイメージは、Artifact Registryの自動クリーンアップポリシーで削除します。管理対象を絞ることで、監査コストとストレージコストの両方を削減できます。

Artifact Analysis 脆弱性メタデータ完全ガイドのまとめ

Artifact Analysisでは、プッシュまたはプルから30日以内のイメージのみが継続的な脆弱性監視の対象となります。
30日を超えるとメタデータの更新が停止し、さらに90日経過するとアーカイブされて参照できなくなります。
継続監視を維持したい場合は、定期的に docker pull を実行して監視ウィンドウを更新する方法が最もシンプルです。

一方、CI/CDパイプラインで任意のタイミングにスキャンを実施したい場合は、オンデマンドスキャンを活用できます。また、不要な古いイメージはArtifact Registryのクリーンアップポリシーで整理し、管理対象を適切に絞ることも重要です。

これらの仕組みを理解して運用することで、効率的かつ継続的なコンテナ脆弱性管理を実現できるようになります。

Cloud Run アプリケーション設計・デプロイ完全ガイド

Cloud Runは、コンテナ化されたアプリケーションを手軽に実行できるサーバーレス基盤ですが、本番環境で安定運用するためには単純なデプロイだけでは不十分です。高い可用性とコスト効率を実現するには、サービス・リビジョン・インスタンスからなるリソースモデルを正しく理解する必要があります。

また、アプリケーションをステートレスに設計し、Cloud Run特有のCPU割り当てやスケーリング特性を考慮することも重要です。さらに、本番環境ではIngress制御やVPC接続などのセキュリティ設計も欠かせません。

本記事では、Cloud Runで本番品質のアプリケーションを構築するために押さえておきたい設計・デプロイ・ネットワーク構成のポイントを体系的に解説します。

1. Cloud Runの基本構造とリソースモデル

Cloud Runでアプリケーションを効率的に管理するためには、まずそのリソースモデルを理解することが重要です。Cloud Runは主に以下の3つのコンポーネントで階層的に構成されています。

サービス (Service)：アプリケーション全体を表す最上位のリソースです。固有のドメイン名（エンドポイント）を持ち、トラフィックを制御します。
リビジョン (Revision)：サービスに対する「変更の履歴（バージョン）」です。コードのデプロイや環境変数の変更を行うたびに、新しく不変（Immutable）なリビジョンが自動作成されます。これにより、簡単に過去のバージョンへロールバックしたり、トラフィックを複数バージョンに分散（カナリアリリース）したりできます。
インスタンス (Instance)：リクエストを実際に処理する最小単位のコンテナです。トラフィックの増減に応じて、Cloud Runがインスタンスの数を自動で伸縮（0から最大数まで）させます。

2. デプロイ前に確認すべきアプリの条件（Fit for Run）

あらゆるコンテナがCloud Runで快適に動作するわけではありません。Cloud Runの特性を最大限に活かすために、アプリケーション側で満たすべき主要な条件があります。

ステートレス（無状態）であること：インスタンスはいつでも新設・破棄されます。ローカルディスクに保存したデータは消滅するため、セッションやファイルはCloud SQL、Firestore、Cloud Storageなどの外部サービスに保存してください。
リクエスト駆動であること：特定のポート（デフォルトは 8080）でHTTPリクエストを待ち受け、レスポンスを返すWebサーバーやAPIの形態である必要があります。
バックグラウンド処理とCPU割り当ての理解（重要）：Cloud RunにはCPU割り当てに関して2つの設定があります。デフォルトの「リクエストベースの課金」では、CPUはリクエスト処理中にのみ割り当てられます。一方、「インスタンスベースの課金（旧：CPU always allocated）」を選択すると、インスタンスのライフサイクル全体にわたってCPUが割り当てられ、バックグラウンドタスクや非同期処理タスクの実行に有用です。

設定	CPUの割り当て	向いているユースケース
リクエストベース（デフォルト）	リクエスト処理中のみ	スポット的なAPIサービス、コスト最適化
インスタンスベース	インスタンスの生存期間全体	バックグラウンド処理、非同期タスク

デフォルトのリクエストベース設定では、リクエスト処理が終了した後のバックグラウンド処理でCPUがスロットル（抑制）されます。バックグラウンド処理が必要な場合はインスタンスベースの課金設定に変更してください。

3. Cloud Runへのデプロイ手順（2つのアプローチ）

Cloud Runへのデプロイには、開発のフェーズや要件に応じて2つの標準的なアプローチがあります。

アプローチA：ソースコードから直接デプロイ（開発・検証向け）

Dockerfileを用意していなくても、Google Cloudが提供するBuildpacks（またはリポジトリ内のDockerfile）を利用して、ソースコードから一発でビルド＆デプロイまでを完了させる方法です。

＜gcloudコマンド＞

gcloud run deploy my-web-app \
    --source . \
    --region asia-northeast1 \
    --allow-unauthenticated

⚠️ --allow-unauthenticated フラグをつけると、インターネット全体に公開されます。

アプローチB：コンテナイメージからデプロイ（本番・CI/CD向け）

すでにArtifact Registryなどのリポジトリにプッシュ済みのコンテナイメージを指定してデプロイする方法です。CI/CDパイプライン（Cloud Buildなど）と連携する際は、こちらが標準となります。

＜gcloudコマンド＞

gcloud run deploy my-web-app \
    --image asia-northeast1-docker.pkg.dev/[PROJECT_ID]/[REPO]/[IMAGE]:[TAG] \
    --region asia-northeast1

4. 本番運用のためのネットワークとセキュリティ

アプリケーションを安全に運用するためには、ネットワークの境界防御とプライベート接続の設計が不可欠です。

① 内向きトラフィック（Ingress）の制限

設定値	アクセスを許可する範囲	ユースケース
すべてのトラフィック (All)	インターネット全体からの直接アクセス	一般公開のWebサイト、パブリックAPI
内部通信のみ (Internal)	同じVPC内、または他のGoogle Cloudサービスからのみ	社内ツール、非公開のマイクロサービス
内部＋外部ロードバランサ	VPC内、およびCloud Load Balancing経由のみ	Cloud Armor（DDoS防御、WAF）を前段に挟む本番システム

② 外向きトラフィック（Egress）とプライベートネットワーキング

Cloud Runから、VPC内部にあるデータベース（Cloud SQLなど）や社内システムに安全にアクセスしたい場合、グローバルなインターネットを経由させるのはNGです。

ダイレクトVPCエグレス (Direct VPC Egress)：Cloud Runインスタンスを直接VPCネットワークにサブネット経由で接続させる機能です。高速かつ低レイテンシで、VPC内部のプライベートIPアドレスを持つリソースと安全に通信することができます。

Cloud Run アプリケーション設計・デプロイ完全ガイドのまとめ

Cloud Runへのデプロイはコマンド一つで完了するほどシンプルですが、その裏には強力なリソース管理とセキュリCloud Runを効果的に活用するためには、サービス・リビジョン・インスタンスのリソースモデルを理解し、適切な運用設計を行うことが重要です。

アプリケーションはステートレスに設計し、データはCloud StorageやFirestore、Cloud SQLなどの外部サービスで管理することで、サーバーレスの恩恵を最大限に活かせます。
また、CPU割り当て方式をユースケースに応じて選択することで、コストとパフォーマンスの最適化が可能になります。

本番環境ではIngress制御やDirect VPC Egressを活用し、通信経路を適切に保護することも欠かせません。
さらに、リビジョンを活用したロールバックや段階的リリースを取り入れることで、安全なデプロイ運用を実現できます。

これらのベストプラクティスを押さえることで、高可用性・高セキュリティ・低運用負荷を兼ね備えたCloud Run基盤を構築できるようになるでしょう。