このリファレンス アーキテクチャでは、以前に Cloud Storage にエクスポートしたログを Cloud Logging に再インポートする方法について説明します。
このリファレンス アーキテクチャは、ログのインポート ジョブを構成して実行するエンジニアとデベロッパー（DevOps、サイト信頼性エンジニア（SRE）、セキュリティ調査員など）を対象としています。このドキュメントは、Cloud Run ジョブの実行と、Cloud Storage および Cloud Logging の使用方法に精通していることを前提としています。
アーキテクチャ
次の図は、このリファレンス アーキテクチャで Google Cloud の各サービスがどのように使用されているかを示したものです。
このワークフローには、次のコンポーネントが含まれています。
- Cloud Storage バケット: 以前にエクスポートした、Cloud Logging に再インポートするログが含まれています。このようなログは以前にエクスポートされたものなので、想定されるエクスポート形式で編成されています。
- Cloud Run ジョブ: 以下のようなログのインポート プロセスを実行します。
- ログエントリを格納するオブジェクトを Cloud Storage から読み取ります。
- エクスポートされたログの編成に基づき、リクエストされた期間内に指定されたログ ID でエクスポートされたログを Cloud Storage バケット内で検索します。
- オブジェクトを Cloud Logging API の
LogEntry構造に変換します。Cloud Logging API の割り当ての消費量を減らすため、複数のLogEntry構造がバッチに集約されます。このアーキテクチャは、必要に応じて割り当てエラーを処理します。 - 変換されたログエントリを Cloud Logging に書き込みます。同じジョブを複数回再実行すると、エントリが重複することがあります。詳細については、インポート ジョブを実行するをご覧ください。
- Cloud Logging: 変換されたログエントリを取り込み、保存します。ログエントリは、ルーティングとストレージの概要の説明に従って処理されます。
- BigQuery: SQL を使用して、インポートされたログに対して分析クエリを実行します（省略可）。Cloud Storage から監査ログをインポートするため、このアーキテクチャではログ ID が変更されます。インポートしたログをクエリする際は、この名前変更を考慮する必要があります。
ユースケース
インシデント調査やその他の過去のイベントの監査のために追加のログ分析が必要な場合は、このアーキテクチャのデプロイを選択できます。たとえば、データベース アクセス監査の一環として、前年の第 1 四半期のデータベースへの接続を分析する必要がある場合などです。
設計の代替案
このセクションでは、このリファレンス アーキテクチャ ドキュメントに記載されているデフォルト設計の代替案について説明します。
保持期間とインポートされたログ
Cloud Logging では、受信ログエントリのタイムスタンプが 30 日間の保持期間を超えないようにする必要があります。インポートされたログエントリのうち、タイムスタンプがインポート時間から 30 日以上経過しているものは保存されません。
このアーキテクチャでは、Cloud Run ジョブに設定された期間を検証し、1 日分の安全マージンを確保して、29 日以上経過したログのインポートを回避します。
29 日以上前のログをインポートするには、実装コードに次の変更を加えてから、Cloud Run ジョブで使用する新しいコンテナ イメージをビルドする必要があります。
- 30 日間の期間検証を削除する
- 元のタイムスタンプをユーザーラベルとしてログエントリに追加する
- ログエントリのタイムスタンプ ラベルをリセットして、現在のタイムスタンプで取り込まれるようにする
この変更を使用する場合は、ログ分析のクエリで timestamp フィールドではなく、labels フィールドを使用する必要があります。ログ分析のクエリの詳細とサンプルについては、サンプル SQL クエリをご覧ください。
設計上の考慮事項
次のガイドラインは、組織の要件を満たすアーキテクチャを開発するために役立ちます。
費用の最適化
このリファレンス アーキテクチャを使用してログをインポートした場合、複数の要因によって費用がかかります。
課金対象である次の Google Cloud コンポーネントを使用することになります。
- Cloud Logging（ログの保持期間の費用が適用されます）
- Cloud Run
- Cloud Storage API
次の要因により費用が増加する可能性がある点を考慮してください。
- ログの重複: 追加のログストレージ費用が発生しないように、同じ構成でインポート ジョブを複数回実行しないでください。
- 追加の宛先のストレージ: 追加のログストレージ費用が発生しないようにするには、宛先のプロジェクトでルーティング ポリシーを無効にして、追加の場所でログストレージが発生しないようにするか、ログを他の宛先（Pub/Sub や BigQuery など）に転送しないようにします。
- 追加の CPU とメモリ: インポート ジョブがタイムアウトした場合は、インポート ジョブの構成でインポート ジョブの CPU とメモリを増やす必要があります。これらの値を増やすと、Cloud Run の費用が増加する可能性があります。
- 追加のタスク: 期間内にインポートされる 1 日あたりのログの予測数が多い場合は、インポート ジョブの構成でタスク数を増やす必要があります。ジョブはタスク間で期間を均等に分割するため、各タスクは期間内の同程度の日数を同時に処理します。タスク数を増やすと、Cloud Run の費用が増える可能性があります。
- ストレージ クラス: Cloud Storage バケットのストレージ クラスが Nearline、Durable Reduced Availability（DRA）、Coldline など Standard 以外の場合は、追加料金が発生する可能性があります。
- 異なるロケーション間のデータ トラフィック: インポート ジョブは、ログのインポート元である Cloud Storage バケットと同じロケーションで実行されるように構成します。そうしないと、下り（外向き）ネットワークの費用が発生する可能性があります。
Cloud Run ジョブなどの予想使用量に基づいて費用の見積もりを出すには、料金計算ツールを使います。
業務の効率化
このセクションでは、ソリューションのデプロイ後に分析クエリを管理する際の考慮事項について説明します。
ログ名とクエリ
ログは、ログエントリの logName フィールドで定義されているプロジェクトに保存されます。選択したプロジェクトにログをインポートするために、このアーキテクチャでは、インポートされた各ログの logName フィールドを変更します。インポートログは、ログ ID imported_logs を持つ、選択したプロジェクトのデフォルトのログバケットに保存されます（ただし、保存先を変更するログ ルーティング ポリシーが設定されている場合を除きます）。logName フィールドの元の値は labels フィールドに保持され、キーは original_logName になります。
インポートしたログをクエリする場合は、元の logName 値の場所を考慮する必要があります。ログ分析のクエリの詳細とサンプルについては、サンプル SQL クエリをご覧ください。
パフォーマンスの最適化
インポートするログの量が Cloud Run の容量の上限を超えると、インポートが完了する前にジョブがタイムアウトすることがあります。不完全なデータ インポートを回避するには、インポート ジョブの tasks 値を増やすことを検討してください。CPU とメモリの各リソースを増やせば、タスク数を増やす場合にもタスクのパフォーマンスを向上させることができます。
デプロイ
このアーキテクチャをデプロイするには、Cloud Storage から Cloud Logging にログをインポートするジョブをデプロイするをご覧ください。
次のステップ
- GitHub リポジトリで実装コードを確認する。
- ログ分析と SQL を使用して、インポートしたログを分析する方法を学習する。
- Cloud Storage バケットにログをエクスポートする方法を学習する。
- Cloud Architecture Center で、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
協力者
作成者: デベロッパー リレーションズ エンジニア | Leonid Yankulin
その他の関係者:
- シニア スタッフ ソフトウェア エンジニア | Summit Tuladhar
- エンタープライズ アーキテクト | Wilton Wong
- クラウド ソリューション アーキテクト | Xiang Shen