Cloud Storage から Cloud Logging にログをインポートするジョブをデプロイする

Last reviewed 2025-02-19 UTC

このドキュメントでは、Cloud Storage から Cloud Logging にログをインポートするで説明されているリファレンス アーキテクチャをデプロイする方法について説明します。

以降で説明する手順は、ログのインポート ジョブを構成して実行するエンジニアとデベロッパー（DevOps、サイト信頼性エンジニア（SRE）、セキュリティ調査員など）を対象としています。また、Cloud Run のインポート ジョブの実行と、Cloud Storage および Cloud Logging の使用方法に精通していることを前提としています。

アーキテクチャ

次の図は、このリファレンス アーキテクチャで Google Cloud サービスがどのように使用されているかを示しています。

詳細については、Cloud Storage から Cloud Logging にログをインポートするをご覧ください。

目標

• Cloud Run インポート ジョブを作成して構成する
• ジョブを実行するサービス アカウントを作成する

費用

このドキュメントでは、課金対象である次の コンポーネントを使用します Google Cloud：

• Cloud Logging
• Cloud Run
• Cloud Storage

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。

新規の Google Cloud ユーザーの方は、無料トライアルをご利用いただける場合があります。

始める前に

1. インポートするログが、以前に Cloud Storage にエクスポートされたものであること、つまり、ログがすでに 想定される エクスポート形式で編成されていることを確認します。

2. コンソールで Cloud Shell をアクティブにします。 Google Cloud

   Cloud Shell をアクティブにする

3. プロジェクトを Google Cloud 作成または選択します。

   プロジェクトを選択または作成するために必要なロール

   • プロジェクトを選択する: プロジェクトの選択に特定の IAM ロールは必要ありません。ロールが付与されているプロジェクトを選択できます。
   • プロジェクトを作成する: プロジェクトを作成するには、プロジェクト作成者ロール （roles/resourcemanager.projectCreator）が必要です。これには resourcemanager.projects.create 権限が含まれています。詳しくは、ロールを付与する方法をご覧ください。

   • プロジェクトを作成する Google Cloud :

     gcloud projects create PROJECT_ID

     PROJECT_ID は、作成する Google Cloud プロジェクトの名前に置き換えます。

   • 作成した Google Cloud プロジェクトを選択します。

     gcloud config set project PROJECT_ID

     PROJECT_ID は、 Google Cloud プロジェクトの名前に置き換えます。

   PROJECT_ID は、宛先のプロジェクト ID に置き換えます。

   注: インポートするログ用に、指定するプロジェクトを新たに作成しておくことをおすすめします。既存のプロジェクトを使用すると、インポートされたログが意図しない宛先に転送されてしまう可能性があります。これにより、余分な料金が発生したり、誤ってエクスポートされたりする可能性があります。ログが意図しない宛先に転送されないようにするには、_Required と _Default を含むすべてのシンクのフィルタを確認します。シンクが組織またはフォルダから継承されていないことを確認します。

4. プロジェクトに対して課金が有効になっていることを確認します Google Cloud 。

5. Cloud Run API と Identity and Access Management（IAM）API を有効にします。

   API を有効にするために必要なロール

   API を有効にするには、serviceusage.services.enable 権限が必要です。プロジェクトを作成した場合は、オーナーロール（roles/owner）を通じてこの権限が付与されている可能性があります。それ以外の場合は、Service Usage 管理者ロール（roles/serviceusage.serviceUsageAdmin）を通じてこの権限を取得できます。ロールを付与する方法をご覧ください。

   gcloud services enable run.googleapis.com iam.googleapis.com

必要なロール

このソリューションのデプロイに必要な権限を取得するには、 次の IAM ロールを付与するよう管理者に依頼してください。

• ログバケットにログ書き込みロールを付与する: プロジェクト IAM 管理者 （roles/resourcemanager.projectIamAdmin） 宛先プロジェクトに対する
• ストレージ バケットに Storage オブジェクト閲覧者ロールを付与する: ストレージ管理者 （roles/storage.admin） ストレージ バケットがホストされているプロジェクトに対する
• サービス アカウントを作成する: サービス アカウントの作成 （roles/iam.serviceAccountCreator） 宛先プロジェクトに対する
• プロジェクトでサービスを有効にする: Service Usage 管理者 （roles/serviceusage.serviceUsageAdmin） 宛先プロジェクトに対する
• ログバケットをアップグレードして、インポートしたログを削除する: Logging 管理者ロール (roles/logging.admin) 宛先プロジェクトに対する
• インポート ジョブを作成、実行、変更する: Cloud Run デベロッパー （roles/run.developer） 宛先プロジェクトに対する

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

必要な権限は、カスタム ロールや他の事前定義 ロールから取得することもできます。

ログバケットをアップグレードしてオブザーバビリティ分析を使用する

デフォルトのログバケットを使用し、ログ分析を使用するようにアップグレードすることをおすすめします。 ただし本番環境では、デフォルトのバケットが要件を満たさない場合は、独自のログバケットを使用できます。独自のバケットを使用する場合は、宛先プロジェクトに取り込まれたログをそのログバケットにルーティングする必要があります。詳細については、ログバケットを構成するとシンクを作成するをご覧ください。

バケットをアップグレードすると、SQL を使用してログのクエリと分析を行えるようになります。 バケットのアップグレードやオブザーバビリティ分析の使用に追加費用はかかりません。

注: アップグレードしたバケットはダウングレードできません。設定と制限の詳細については、 オブザーバビリティ分析を使用するためにログバケットをアップグレードするをご覧ください。

宛先プロジェクトのデフォルトのログバケットをアップグレードするには、次の操作を行います。

• オブザーバビリティ分析を使用するようにデフォルトのログバケットをアップグレードします。

  gcloud logging buckets update BUCKET_ID --location=LOCATION --enable-analytics
  

  次のように置き換えます。

  • BUCKET_ID: ログバケットの名前（例: _Default）
  • LOCATION: サポートされているリージョン（例: global）

Cloud Run インポート ジョブを作成する

ジョブを作成する際は、このリファレンス アーキテクチャ用に提供されている事前構築済みのコンテナ イメージを使用できます。30 日間の保持期間を変更するように実装を変更する必要がある場合、またはその他の要件がある場合は、独自のカスタム イメージを構築できます。

• Cloud Shell で、構成と環境変数を使用してジョブを作成します。

  gcloud run jobs create JOB_NAME \
  --image=IMAGE_URL \
  --region=REGION \
  --tasks=TASKS \
  --max-retries=0 \
  --task-timeout=60m \
  --cpu=CPU \
  --memory=MEMORY \
  --set-env-vars=END_DATE=END_DATE,LOG_ID=LOG_ID,\
  START_DATE=START_DATE,STORAGE_BUCKET_NAME=STORAGE_BUCKET_NAME,\
  PROJECT_ID=PROJECT_ID
  

  次のように置き換えます。

  • JOB_NAME: ジョブの名前。
  • IMAGE_URL: コンテナ イメージへの参照。GitHub の手順に沿って作成した場合は、us-docker.pkg.dev/cloud-devrel-public-resources/samples/import-logs-solution またはカスタム イメージの URL を使用します。
  • REGION: ジョブを配置するリージョン。追加費用が発生しないように、ジョブのリージョンは Cloud Storage バケットのリージョンと同じにするか、同じマルチリージョン内にすることをおすすめします。たとえば、バケットが米国のマルチリージョンの場合は、us-central1 を使用できます。詳細については、 費用の最適化をご覧ください。
  • TASKS: ジョブが実行する必要があるタスクの数。デフォルト値は 1 です。タイムアウトが発生した場合は、タスクの数を増やすことができます。
  • CPU: CPU 数の上限（1、2、4、6、8 のいずれか）。デフォルト値は 2 です。タイムアウトが発生した場合は、この値を増やすことができます。詳細については、CPU 上限を構成するをご覧ください。
  • MEMORY: メモリの上限。デフォルト値は 2Gi です。タイムアウトが発生した場合は、この値を増やすことができます。詳細については、メモリ上限を構成するをご覧ください。
  • END_DATE: 期間の終了日（MM/DD/YYYY 形式）。この日付以前のタイムスタンプを持つログがインポートされます。
  • LOG_ID: インポートするログのログ ID。ログ ID は、ログエントリの logName フィールドの一部です。例: cloudaudit.googleapis.com。
  • START_DATE: 期間の開始日（MM/DD/YYYY 形式）。この日付以降のタイムスタンプを持つログがインポートされます。
  • STORAGE_BUCKET_NAME: ログが保存される Cloud Storage バケットの名前（gs:// 接頭辞は付けません）。

  max-retries オプションは、失敗したタスクの再試行を防ぐためにゼロに設定されています。再試行すると、ログエントリの重複を引き起こす可能性があります。

  タイムアウトによって Cloud Run ジョブが失敗すると、インポートが不完全になる可能性があります。タイムアウトによる不完全なインポートを防ぐには、tasks 値に加え、CPU リソースとメモリリソースを増やします。

これらの値を増やすと、費用が増加する可能性があります。費用の詳細については、費用の最適化をご覧ください。

Cloud Run ジョブを実行するサービス アカウントを作成する

1. Cloud Shell で、ユーザー管理のサービス アカウントを作成します。

   gcloud iam service-accounts create SA_NAME
   

   SA_NAME は、サービス アカウントの名前に置き換えます。

2. ストレージ バケットに対する Storage オブジェクト閲覧者ロールを付与します。

   gcloud storage buckets add-iam-policy-binding gs://STORAGE_BUCKET_NAME \
   --member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
   --role=roles/storage.objectViewer
   

   次のように置き換えます。

   • STORAGE_BUCKET_NAME: インポート ジョブ構成で使用したストレージ バケットの名前。例: my-bucket
   • PROJECT_ID: 宛先プロジェクトの ID。

3. ログバケットに対するログ書き込みロールを付与します。

   gcloud projects add-iam-policy-binding PROJECT_ID \
   --member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
   --role=roles/logging.logWriter
   

4. Cloud Run ジョブのサービス アカウントを設定します。

   gcloud run jobs update JOB_NAME \
   --region=REGION \
   --service-account SA_NAME@PROJECT_ID.iam.gserviceaccount.com
   

   REGION は、Cloud Run インポート ジョブをデプロイしたリージョンに置き換えます。

インポート ジョブを実行する

• Cloud Shell で、作成したジョブを実行します。

  gcloud run jobs execute JOB_NAME \
  --region=REGION
  

詳細については、ジョブを実行するとジョブ実行を管理するをご覧ください。

ジョブを再実行する必要がある場合は、重複を避けるため、以前にインポートしたログを削除してください。詳細については、このドキュメントの後半のインポートしたログを削除するをご覧ください。

インポートしたログをクエリしても、クエリ結果に重複は表示されません。Cloud Logging は、クエリ結果から重複（同じ挿入 ID とタイムスタンプを持つ同じプロジェクトのログエントリ）を削除します。詳細については、Logging API リファレンスの insert_id フィールドをご覧ください。

結果を検証する

ジョブが正常に完了したことを確認するには、Cloud Shell でインポート結果をクエリします。

  gcloud logging read 'log_id("imported_logs") AND timestamp<=END_DATE'

出力にはインポートされたログが表示されます。指定された期間内に、同じプロジェクトを使用して複数のインポート ジョブを実行した場合、出力にはそれらのジョブからインポートされたログも表示されます。

その他のオプションとログエントリのクエリの詳細については、gcloud logging read をご覧ください。

インポートしたログを削除する

同じジョブを複数回実行する必要がある場合は、エントリの重複と費用の増大を避けるため、以前にインポートしたログを削除します。

• インポートしたログを削除するには、Cloud Shell で logs delete を実行します。

  gcloud logging logs delete imported_logs
  

インポートしたログを削除すると、最後のインポート ジョブの実行結果だけでなく、宛先プロジェクトにインポートされたすべてのログエントリが完全に削除されることに注意してください。

次のステップ

• GitHub リポジトリで実装コードを確認する。
• オブザーバビリティ分析と SQL を使用して、インポートしたログを分析する方法を学習する。
• Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。

協力者

作成者: デベロッパー リレーションズ エンジニア | Leonid Yankulin

その他の寄稿者:

• Summit Tuladhar | シニア スタッフ ソフトウェア エンジニア
• Wilton Wong | エンタープライズ アーキテクト
• Xiang Shen | ソリューション アーキテクト