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

このドキュメントでは、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. Google Cloud コンソールで、「Cloud Shell をアクティブにする」をクリックします。

   Cloud Shell をアクティブにする

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

   • 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 に置き換えます。

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

5. Cloud Run and Identity and Access Management (IAM) API を有効にします。

   gcloud services enable run.googleapis.comiam.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 Storage バケットにログをエクスポートする方法を学習する。
• Cloud Architecture Center で、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。

協力者

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

その他の関係者:

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