コンテンツに移動
管理ツール

Cloud Logging のイベントをリアルタイムで検出して対応する

2020年7月14日
Google Cloud Japan Team

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

ロギングはクラウド インフラストラクチャの重要なコンポーネントであり、システムとアプリケーションのパフォーマンスを掘り下げるための有用な分析情報を得られます。Google Cloud の Cloud Logging は、ご利用の Google Cloud Platform(GCP)インフラストラクチャのサービスとアプリケーションについて、ログのデータとイベントを保存、検索、モニタリングし、アラートを受け取ることができるサービスです。ログのデータは、ログビューア、コマンドライン、Cloud SDK を使用してリアルタイムで表示、分析できます。 

これらのロギングツールは、ログを見つけ、ログに表れている状況を理解するうえで有用です。日々の業務では、ビジネス プロセスまたは技術的なプロセスで自動アクションが必要になる場面や、DevOps チームの負担を軽減したいと考える場面があります。たとえば、Cloud Audit Logs に表れる変化に応じて対策を講じ、インフラストラクチャの不注意な変更で生じたセキュリティ上の脆弱性を修正する場合です。

Logging のシンクを使用すると、イベント ドリブンのシステムを構築して、リアルタイムでログイベントを検出して対応できます。Cloud Logging は、Cloud Pub/Sub のほか、Cloud FunctionsCloud Run などのサーバーレス コンピューティング サービスとの統合を活かして、イベント ドリブンのアーキテクチャの構築を実現します。

アーキテクチャの概要

イベント ドリブンであるこのシステムのアーキテクチャを概観してみると、シンプルで柔軟性に富んでいます。主なコンポーネントは次の 4 つです。

  • ログイベント: アプリケーションとインフラストラクチャから Cloud Logging に
    ログが送信される

  • ロギング: ログルーターの Cloud Logging シンクで、作成した個別のフィルタに基づいて Pub/Sub トピックにログイベントを送信できる

  • Pub/Sub: 受信したログイベントに基づいて、Cloud Functions を非同期で起動する

  • Cloud Functions: ログイベントを処理し、対応するためのビジネス ロジック

https://storage.googleapis.com/gweb-cloudblog-publish/images/cloud_logging.max-800x800.jpg

このイベント ドリブン システムは緩やかな結合で成り立っており、ログイベントの量に基づいて自動スケーリングできます。お客様によるキャパシティ プランニングや管理は必要ありません。サーバーレス コンピューティング オプションを利用すると、費用を大幅に削減し、プログラマーの生産性を向上させることも可能になります。たとえば、ログエントリの分析、データの保存、他の API またはサービスの呼び出しには、必要に応じて Cloud Functions 関数のコードを利用できます。 

ログイベント

Cloud Logging に書き込まれる個々のログイベントには、ログ名、タイムスタンプ、ログソースのリソース、ペイロード、メタデータといった LogEntry が含まれています。ペイロードのデータは、ログの書き込み方法に応じて、Unicode 文字列(textPayload)、JSON オブジェクト(jsonPayload)、プロトコル バッファ(protoPayload)の 3 タイプのいずれかとして保存されています。ログのペイロードを調査すると、エラー、例外、特定のメッセージなどの有用なイベントを抽出できます。Cloud Functions 関数のロジックで、これと同じペイロードを使用することが可能です。

たとえば、Cloud Storage バケットに公開読み取り権限が追加された場合、次のような監査ログエントリが Cloud Logging に送信されます。このペイロードを抽出し、アクションに基づいて処理できます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/cloud_logging_1.max-900x900.jpg

使用事例

イベント ドリブンのシステムを導入すると、多種多様な状況でログイベントを処理し、対応できるようになります。具体例を紹介するため、3 つの Cloud Functions 関数を参照コードとして作成しました。どのコードも、それぞれ別の種類のログメッセージに対応するものです。参照コードでは、Cloud Functions を使用して、コードのホスティングと実行を担うロジックを実装しました。これと似たロジックは、Cloud Run または App Engine を使用して実装することもできます。必要なサーバーレス コンピューティング オプションが不明な場合は、検討の一助として、サーバーレス オプションのプロダクトの比較ページをご覧ください。

ここでは、ログイベント用のイベント ドリブン アーキテクチャに関して、検討の材料になり得る 3 つの一般的な使用事例を紹介します。

1. ファイアウォール ルールを自動的に適用する

最初の使用事例は、社内向けのサービスに関してインターネットからの完全アクセスを許可するなど、Google Cloud を利用する場合の「明確なポリシー違反」に対して、ファイアウォールの設定を自動的に変更することです。多くの組織には、アプリケーションへの上り(内向き)トラフィックの場合、80 や 443 といった特定のポートでのアクセス、または特定の IP 範囲内からのアクセスのみ許可するというセキュリティ ポリシーが存在しています。ファイアウォール ルールに加えられる変更がそれらのポリシーに違反している場合、セキュリティ上の脆弱性が生じる恐れや、システムがセキュリティ侵害に対して無防備のままになる恐れがあります。たとえば、インターネットのトラフィックを受信することが意図されていない限定公開サービスであっても、すべての上り(内向き)トラフィック(0.0.0.0/0)を許可するファイアウォール ルールが適用された場合、外部にさらされた状態になり得ます。ファイアウォールに関して、ポリシーを遵守していない変更が検出された場合に変更内容を修正できます。 

イベント ドリブンのアーキテクチャを基盤として、ここでは次の 3 つのコンポーネントを実装しています。

  1. Logging シンク: Logging シンクを使用すると、特定のログエントリをビジネス ロジックに誘導できます。この例では、Compute Engine の Cloud Audit Logs でリソースタイプ gce_firewall_rule を使用して、目的のログをフィルタできます。イベントタイプ GCE_OPERATION_DONE をフィルタに追加すると、完了したログイベントのみを捕捉することも可能です。ログの識別に使用する Logging フィルタを下に示します。ログビューアでこちらのクエリを実行してみてください。

    resource.type="gce_firewall_rule"
    operation.last=true

  2. Pub/Sub トピック: Pub/Sub では、ログシンクの誘導先になるトピックを作成できるほか、Pub/Sub メッセージを使用して Cloud ファンクションをトリガーできます。 

  3. Cloud Functions 関数: Cloud Functions では、ロジックを作成して、受信したログをビジネス要件に基づいて評価できます。

Cloud Audit Logs でファイアウォール ルールの変更を捕捉したら、次の Cloud Functions 関数を呼び出します。

  • compute.firewalls.patch

  • compute.firewalls.insert

  • compute.firewalls.update

前述のログエントリのいずれかが監査ログに記述されている場合は、そのエントリによって Cloud Functions 関数のロジックがトリガーされます。このリファレンス実装では、Compute Engine API を使用してファイアウォール ルールの詳細情報全体を Cloud Functions 関数で取得し、詳細情報に含まれているすべてのアイテムを確認しています。今回の例では、違反が見つかったファイアウォール ルールを単純に削除します。追加のロジックを使用して、ルールにパッチを適用することや、ルールをロールバックすることもできます。

コードを作成した後は、Infrastructure as Code(IaC)のアプローチでデプロイできます。たとえば、Cloud Deployment Manager で次の構成を使用して、デプロイを自動化することが可能です。 

この構成では、Logging シンク、Pub/Sub トピック、Cloud Functions 関数がどのようにプロビジョニングされるのかを見ることができます。また、Sendgrid を構成して、指定したメールアドレスにメール通知を送信することもできます。

読み込んでいます...

2. 構成の不適切なバケットを自動的に修正する

2 番目の使用事例では、Cloud Storage に構成の不適切なバケットが生じないようにする処理に焦点を当てます。バケットの構成が不適切な場合、機密データが外部にさらされて、組織が被害を受ける恐れがあります。そのような状況に陥らないようにするには、バケットの構成に対する変更をモニタリングします。たとえば、管理者がバケットを不用意に公開して読み取りや書き込みが可能になった場合は、Cloud Functions 関数を使用してその変更を捕捉し、公開アクセスを取り消すことができます。この手法が特に有効なのは、Google Cloud 組織のすべてのログを捕捉する集約シンクと組み合わせる場合です。

次に、Cloud Audit Logs で捕捉された下記の Cloud Storage バケットの変更に対して、Cloud Functions 関数を呼び出します。

  • storage.buckets.create

  • storage.buckets.update

  • storage.setIamPermissions


上のいずれかの変更が監査ログに記述されている場合は、バケット ポリシーを調査し、allUsers または allAuthenticatedUsers に関連付けられているルールを削除します。

3. ビジネス イベント ロジックを自動化する

最後の使用事例では、システムを他のサービスと統合して拡張する方法を紹介します。Cloud Logging では、ログベースの指標を作成できます。この指標は、Cloud Monitoring でログエントリから収集するカスタム指標です。たとえば、e コマース アプリケーションの決済サービスの場合、決済プロセスの進行中には、各種の例外がロギングされます。ログベースの指標を作成すると、それらの例外をすべてカウントできます。その後、指標が短期間のうちにしきい値を超えた場合に、第 1次の対応担当者宛てにアラートが送信されるアラート ポリシーを作成します。

組み込みのログベースの指標は、ログエントリの数をカウントして、ログの値の分布をトラックする処理に適しています。一方、ログエントリの内容に基づいて計算を実行する処理や、お客様固有のラベルを指標に付加する処理が必要なケースには必ずしも向きません。そのような用途の場合は、ログベースのイベント ドリブン アーキテクチャを使用して指標を書き込みます。 

たとえば、お客様の e コマース アプリケーションのおすすめ商品をリアルタイムで確認したいとします。お客様固有のビジネス指標を捕捉するには、ログベースの指標を使用します。たとえば、このマイクロサービスのデモ用アプリケーションは、デモ用のシンプルな e コマース アプリケーションであり、デプロイすることも可能です。アプリケーションの中でユーザーが商品をクリックすると、サイトにある関連商品のおすすめが生成され、ログエントリとして書き込まれます。ログベースのイベント ドリブン アーキテクチャのパターンを利用すると、ログエントリを Cloud Functions 関数で捕捉した後、アプリケーションでおすすめされる商品にお客様固有のラベルを使用したうえで、カスタム ビジネス指標を作成できます。それらの指標を使用すると、Cloud Monitoring のその他の指標の場合と同様に、Cloud Monitoring でアラート ポリシーを作成できます。

Pub/Sub と Cloud Functions 関数のパターンを再利用する

Google では、アラート用の Pub/Sub 通知チャネルを先日リリースしました。これにより、ログから生成されたものではない指標についても、上で説明した 3 つの例と同じイベント ドリブン アーキテクチャを使用して、アラートを自動化できます。

使ってみる

Google のロギングサービスとサーバーレス コンピューティング サービスを利用すると、自動化されたリアルタイムの分析とオペレーション機能を簡単に構築できます。今回取り上げた事例のコードは GitHub で公開しています。Cloud Loggingサーバーレス コンピューティングをまだご利用になっていない場合は、Cloud Functions でのモニタリングとロギングに関する Qwiklab から始めてみてください。メーリング リストのディスカッションにぜひご参加ください。皆様からのフィードバックをお待ちしております。


- Google Cloud プロダクト マネージャー Charles Baer、ソリューション アーキテクト Xiang Shen

投稿先