Cloud Logging によってログを効率的に一元化するためのベスト プラクティス

※この投稿は米国時間 2024 年 7 月 31 日に、Google Cloud blog に投稿されたものの抄訳です。

分散システムの健全性に関する分析情報を入手することは、システムの稼働維持、パフォーマンスの最適化、エンドユーザーに影響が及ぶ前の問題の迅速な解決に不可欠です。とりわけ、一元化されたログ管理システムは、特に運用チームにとって強力なツールになります。ログを一元化するメリットは次のとおりです。

• 一括表示による統合された可視性: アクセスしやすい単一のリポジトリにログを統合することで、システムの健全性とパフォーマンスを包括的に把握できます。一括表示によって、トレンドや潜在的な問題の特定と、アクティビティのモニタリングが容易になります。

• 使い慣れた環境での大規模で効率的な管理: ログを一元化することで、運用が効率化され、コストが削減されるだけでなく、使い慣れた統合インターフェースですべてのオブザーバビリティ データを管理できます。この統合アプローチによって、特に従来のロギング ワークフローに慣れており、単一のインターフェースですべてのオブザーバビリティを実現しているチームでは、分析とトラブルシューティングが簡素化されます。

• セキュリティとコンプライアンスの強化: ログを一元化することで、セキュリティ アナリストが潜在的な脅威や異常を調査するための統合データソースが構築されます。インフラストラクチャ全体のログを統合することで、根本原因の分析とインシデント対応のスピードおよび効率性が向上します。また、組織は 1 つの場所を監査することで、ロギングのコンプライアンス要件を確認、適用できます。

Cloud Logging は、Google Cloud Observability スイートの核となるコンポーネントであり、多様なソースからのログを一元化して管理しやすくします。このブログ投稿では、Cloud Logging を活用してログ管理の複雑さを克服し、クラウドのオブザーバビリティを強化するためのベスト プラクティスをいくつか紹介します。

1. 集約シンクを利用してルーティングを効率化する

集約シンクは、フォルダ内や組織内のあらゆる子リソースのログを自動的に集約することで、ログ ルーティング管理を効率化します。これにより、プロジェクト レベルでの手動構成と個別のルーティングが不要になり、ログの収集と管理が簡素化されます。

• 各環境（本番環境、非本番環境など）に対してフォルダレベルで集約シンクを設定して、すべての子リソースのログを集約します。

• 集約シンクでインターセプトのオプションを有効にし、ログが子プロジェクトに送信されないようにして、冗長ストレージのコストを回避します。

• 一元的なログストレージについて詳しくは、こちらのドキュメントをご覧ください。  

2. 中央のオブザーバビリティ プロジェクトを管理ハブとして確立する

中央のオブザーバビリティ プロジェクトによって多様なソースからのログの管理が一元化され、構成、アクセス制御、分析を容易にする管理ハブが確立されます。これによってログの管理タスクが簡素化され、運用チームのワークフローが効率化されます。

• 各環境と、場合によっては各ビジネス ユニットに対して中央のオブザーバビリティ プロジェクトを作成し、ステップ 1 で作成された集約シンクの宛先として指定します。

• このプロジェクトを、最終宛先に達する前の集約シンクのきめ細かいフィルタとルーティングを目的とするセントラルハブとして使用することで、柔軟性と管理性を高めます。

• このアプローチについて詳しくは、こちらをご覧ください。

3. ログストレージをカスタマイズする

ログストレージをカスタマイズすることで、保持と費用対効果が最適化されます。特定の保持期間を定義し、それに応じてログをグループ化することで、重要なデータを保持しながら、費用を効果的に管理します。また、組織構造に応じてログストレージをカスタマイズすることで、管理とアクセス制御をさらに効率化します。

• 保持のニーズに応じて、新しいユーザー定義のログシンクとログバケットを作成します。デフォルトの保持期間を超えてログを保存すると、追加のコストが発生するのでご注意ください。そのため、保持期間が同じであるログを同じバケットにグループ化して、ストレージの費用を最適化します。ログバケットの作成時には、デフォルトの [グローバル] オプションではなく必ず特定のリージョンを選択し、すべての新規ログバケットに対して同じリージョンを選択してください。

• 中央のオブザーバビリティ プロジェクトの作成時には、デフォルトのログバケットがその他すべてのログバケットと同じリージョンで作成されるようプロジェクトを構成します。デフォルトのログシンクを無効にすることを検討できますが、宛先が設定されていないログに対しては「キャッチオール」バケットを作成してください。

• アクセス制御を簡素化し、ロギングコストをよりきめ細かく配分するため、組織構造（アプリケーションやチームなど）別にログバケットをさらに分割することを検討します。また、VPC フローログやデータアクセス ログなどの特定のログタイプ専用のバケットを作成して、環境全体でクエリと分析を効率化することもできます。

• 新しいログバケットで [オブザーバビリティ分析] を有効にして、ログデータに対する SQL を使用した高度な分析を追加料金なしで実行します。BigQuery でログを分析するには、直接クエリ用のリンクされたデータセットを作成して、BigQuery の取り込みとストレージの費用が発生しないようにします（BigQuery のクエリ費用は発生します）。

• ログストレージのカスタマイズについて詳しくは、こちらをご覧ください。

4. ログストレージのアクセス制御を管理する

ログデータへのアクセスを制御することは、機密情報を保護し、コンプライアンスを確保するために不可欠です。ロールと責任に基づいて権限を制限することで、データ セキュリティを維持し、不正アクセスを防止できます。

• ユーザーにオブザーバビリティ プロジェクトへのアクセスを許可します。一元化されたプロジェクトに保存されているログの、ソース プロジェクトからの表示を許可することもできます。

• 権限管理の粒度を高めるため、ログビュー レベルでアクセスをよりきめ細かく制御します（バケット内で複数のログビューを作成できます）。

• アクセス制御についてはこちら、ログビューについてはこちらで、詳細をご覧ください。

5. ログボリュームをモニタリングする

ログボリュームを積極的にモニタリングすることで、発生しうるログの急増や異常を特定できるため、ストレージの費用をプロアクティブに管理し、ログデータの予期しない増加を調査できるようになります。

• [ログルーター] ページと [ログストレージ] ページの組み込み UI で、ログボリュームを定期的にモニタリングします。

• 以下のような無料のシステム指標を使用して、ダッシュボードとアラートを設定します。

• logging.googleapis.com/exports/byte_count - ログシンクによってエクスポートされたログエントリのバイト数。適切なラベルでフィルタできます。たとえば、「宛先」ラベルによって宛先や宛先の種類別にグループ化でき（正規表現を使用）、「名前」ラベルによってプロジェクト ボリュームを個別のログシンク別に分類できます。

• logging.googleapis.com/billing/log_bucket_bytes_ingested - ログバケットにストリーミングされたバイト数。これは課金対象のデータ量です。適切なラベルでフィルタできます。たとえば、「Log_source」ラベルによってソース プロジェクト別にグループ化できます。また、「Resource_type」によってモニタリング対象リソースタイプ別、「Log_bucket_id」によって特定のログバケット別に分類できます。

• ロギングに関する無料のシステム指標のリストは、こちらをご覧ください。  

ソリューションを視覚化する

下の図は、ログ管理を一元化するための Cloud Logging の構成方法を視覚的に概説したものです。複数のプロジェクトのログを一元的なハブに統合することで、環境の全体像を把握し、モニタリングとトラブルシューティングを効率化できます。

追加の推奨事項と参考情報

まとめると、Cloud Logging を使用することで、ログ管理のプラクティスを一元化しやすくなります。また、このガイドで概説されているベスト プラクティスを適用することで、クラウド環境の可視性が向上し、運用が効率化され、セキュリティ ポスチャーが強化されます。

ログの一元化に関する追加のヒントとコツを知りたい方は、以下の追加の推奨事項をご覧ください。

• ログ ルーティング戦略を試験的に実施する: まずは小さなプロジェクトのグループで、Cloud Logging ルーターの設定をテストします。これにより、構成を大規模に適用する前にファインチューニングできます。

• ログベースの指標を活用する: 中央のオブザーバビリティ プロジェクトでログベースの指標を設定して、環境全体のログからカスタマイズされた分析情報を取得します。

• Cloud Monitoring による予防的モニタリングを使用する: Cloud Logging ルーターを Cloud Monitoring と統合することで、アラートとダッシュボードを作成し、中央のオブザーバビリティ プロジェクトに関するリアルタイムの分析情報を取得して、問題を迅速に検出、解決できるようになります。

• Cloud Billing でコストを管理する: Cloud Billing 内で予算とアラートを設定することで、ロギングコストをリアルタイムでモニタリングします。これにより、実際の支出と予測コストを比較し、必要な調整を行うことができます。

• ログの取り込み範囲を広げる: Cloud Logging の対象を Google Cloud のワークロードのみに制限しないでください。Cloud Logging は、あらゆる環境の一元的なロギングハブとして使用できます。GCP 外のソースからログを取り込むには、以下のオプションを検討してください。

• OpenTelemetry Collector は、Windows VM と Linux VM で使用できます。また、Docker コンテナとして使用することも、Kubernetes クラスタで使用することもできます。

• BindPlane Observability Pipeline をデプロイして、BindPlane エージェントを大規模に構成し、インストールできます。

• OpenTelemetry エージェントを使用できない場合は、多くの Google Cloud パートナーのいずれかと連携して、外部ソースからログを読み取り、Google Cloud Logging に送信することを検討できます。

-プロダクト マネージャー Keith Chen

-カスタマー エンジニア Jose Andrade