Google Cloud から Splunk にログをストリーミングする

Last reviewed 2023-11-16 UTC

このドキュメントでは、Google Cloud のリソースから Splunk にログとイベントをストリーミングする、本番環境に対応したスケーラブルでフォールト トレラントなログ エクスポート メカニズムの作成に役立つリファレンス アーキテクチャについて説明します。Splunk は、セキュリティとオブザーバビリティの統合プラットフォームを提供する一般的な分析ツールです。実際、ロギングデータは、Splunk EnterpriseSplunk Cloud Platform のいずれかにエクスポートすることを選べます。管理者であれば、IT オペレーションやセキュリティのユースケースにもこのアーキテクチャを使用できます。このリファレンス アーキテクチャをデプロイするには、デプロイ: Google Cloud から Splunk にログをストリーミングするをご覧ください。

このリファレンス アーキテクチャでは、次の図のようなリソース階層を想定しています。組織、フォルダ、プロジェクト レベルのすべての Google Cloud リソースログが集約シンクに収集されます。次に、集約シンクがこれらのログをログ エクスポート パイプラインに送信し、それがログを処理して、Splunk にエクスポートします。

Splunk にエクスポートするための組織レベルの集約ログシンク。

アーキテクチャ

次の図は、このソリューションをデプロイするときに使用するリファレンス アーキテクチャを示しています。この図は、Google Cloud から Splunk へのログデータの流れを示しています。

Google Cloud から Splunk へのログのフロー。

このアーキテクチャには次のコンポーネントが含まれています。

  • Cloud Logging -プロセスを開始するには、Cloud Logging が組織レベルの集約ログシンクにログを収集し、Pub/Sub に送信します。
  • Pub/Sub - Pub/Sub サービスは、ログに単一のトピックとサブスクリプションを作成し、メインの Dataflow パイプラインにログを転送します。
  • Dataflow - このリファレンス アーキテクチャには 2 つの Dataflow パイプラインがあります。
    • プライマリ Dataflow パイプライン - プロセスの中心にあるメインの Dataflow パイプラインは、Pub/Sub から Splunk へのストリーミング パイプラインであり、Pub/Sub サブスクリプションからログを取得して Splunk に配信します。
    • セカンダリ Dataflow パイプライン - プライマリ Dataflow パイプラインと同様に、セカンダリ Dataflow パイプラインは Pub/Sub から Pub/Sub へのストリーミング パイプラインであり、配信が失敗した場合にメッセージを再生します。
  • Splunk - プロセスの最後に、Splunk Enterprise または Splunk Cloud Platform が HTTP Event Collector(HEC)として機能し、詳細な分析のためにログを受信します。Splunk をオンプレミスにデプロイすることも、Google Cloud で SaaS として使用することもできます。また、ハイブリッド アプローチも可能です。

ユースケース

このリファレンス アーキテクチャでは、クラウドの push ベースのアプローチを使用します。この push ベースの方法では、Pub/Sub to Splunk Dataflow テンプレートを使用して、ログを Splunk HTTP Event Collector(HEC)にストリーミングします。リファレンス アーキテクチャでは、Dataflow パイプラインの容量計画と、サーバーまたはネットワークに一時的な問題が発生した際に生じる可能性のある配信エラーを処理する方法についても説明します。

このリファレンス アーキテクチャは Google Cloud ログに焦点を当てていますが、同じアーキテクチャを使用して、リアルタイムのアセット変更やセキュリティ検出結果など、他の Google Cloud データをエクスポートすることもできます。Cloud Logging のログを統合することで、Splunk などの既存のパートナー サービスを統合ログ分析ソリューションとして引き続き使用できます。

Google Cloud データを Splunk にストリーミングする push ベースの方法には、次の利点があります。

  • マネージド サービス。マネージド サービスとして、Dataflow は、ログ エクスポートなどのデータ処理タスク用に Google Cloud で必要なリソースを保持します。
  • 分散ワークロード。この方法では、ワークロードを複数のワーカーに分散して並列処理できるため、単一障害点は発生しません。
  • セキュリティ。Google Cloud はデータを Splunk HEC に push するため、サービス アカウントキーの作成と管理に関連するメンテナンスとセキュリティの負担はありません。
  • 自動スケーリング。Dataflow サービスが、受信ログの量とバックログの変動に応じてワーカー数を自動的にスケーリングします。
  • フォールト トレラント。一時的なサーバーまたはネットワークの問題がある場合、push ベースの方法では、Splunk の HEC へのデータの再送信が自動的に試みられます。そこでは、配信できないログメッセージによるデータ損失を回避するため、未処理のトピック(デッドレター トピック)もサポートされます。
  • シンプル。管理オーバーヘッドと、Splunk で 1 つ以上の負荷の高いフォワーダーの実行にかかるコストを回避できます。

このリファレンス アーキテクチャは、製薬や金融サービスなど、規制対象の業種をはじめとするさまざまな業種のビジネスに適用されます。Google Cloud データを Splunk にエクスポートすることを選ぶ際は、次の理由でそうすることを選ぶ場合があります。

  • ビジネス分析
  • IT 運用担当者
  • アプリケーション パフォーマンスのモニタリング
  • セキュリティ運用
  • コンプライアンス

代替案を設計する

Splunk にログをエクスポートする別の方法として、Google Cloud からログを pull するものがあります。この pull ベースの方式では、Google Cloud APIs を使用して、Google Cloud の Splunk アドオンによってデータを取得します。次の状況では、pull ベースの方法を使用することを選ぶこともできます。

  • Splunk のデプロイメントで Splunk HEC エンドポイントが提供されない。
  • ログの量が少ない。
  • Cloud Monitoring の指標、Cloud Storage オブジェクト、Cloud Resource Manager API メタデータ、または少量のログを分析したい。
  • すでに 1 つ以上の負荷の高いフォワーダーを Splunk で管理している。
  • ホストされている Splunk Cloud の Inputs Data Manager を使用する。

また、この pull ベースの方法を使用する際に発生する追加の考慮事項にも留意する必要があります。

  • 単一のワーカーがデータ取り込みワークロードを処理しますが、ここで自動スケーリング機能は提供しません。
  • Splunk では、負荷の大きいフォワーダーを使用してデータを pull すると、単一障害点が発生する場合があります。
  • pull ベースの方法では、Google Cloud の Splunk アドオンを構成するのに使用するサービス アカウントキーを作成、管理する必要があります。

Splunk アドオンを有効にするには、次の手順を実行します。

  1. Splunk で Splunk の手順に沿って、Google Cloud の Splunk アドオンをインストールします。
  2. Google Cloud で、Pub/Sub トピックを作成してロギングデータをエクスポートします。
  3. このトピックの Pub/Sub pull サブスクリプションを作成します。
  4. サービス アカウントを作成します
  5. 作成したサービス アカウントのサービス アカウント キーを作成します
  6. Pub/Sub 閲覧者(roles/pubsub.viewer)と Pub/Sub サブスクライバー(roles/pubsub.subscriber)のロールをサービス アカウントに付与して、アカウントが Pub/Sub サブスクリプションからメッセージを受信できるようにします。
  7. Splunk で Splunk の指示に沿って、Google Cloud の Splunk アドオンで、新しい Pub/Sub 入力を構成します。

    ログ エクスポートからの Pub/Sub メッセージが Splunk に表示されます。

アドオンが機能していることを確認するには、次の手順を実行します。

  1. Cloud Monitoring で Metrics Explorer を開きます。
  2. [リソース] メニューで、pubsub_subscription を選択します。
  3. [指標] カテゴリで、pubsub/subscription/pull_message_operation_count を選択します。
  4. 1~2 分間、メッセージ pull オペレーションの数をモニタリングします。

設計上の考慮事項

次のガイドラインは、セキュリティ、プライバシー、コンプライアンス、業務の効率化、信頼性、フォールト トレラント、パフォーマンス、費用の最適化に関する組織の要件を満たすアーキテクチャの開発に役立ちます。

セキュリティ、プライバシー、コンプライアンス

以降のセクションでは、このリファレンス アーキテクチャのセキュリティの考慮事項について説明します。

プライベート IP アドレスを使用して Dataflow パイプラインをサポートする VM を保護する

Dataflow パイプラインで使用されるワーカー VM へのアクセスを制限する必要があります。アクセスを制限するには、これらの VM をプライベート IP アドレスでデプロイします。ただし、これらの VM は、HTTPS を使用して、エクスポートされたログを Splunk にストリーミングし、インターネットにアクセスできる必要もあります。この HTTPS アクセスを提供するには、Cloud NAT IP アドレスが必要な VM にそれらを自動的に割り振る Cloud NAT ゲートウェイが必要です。VM を含むサブネットを Cloud NAT ゲートウェイにマッピングしてください。

限定公開の Google アクセスを有効にする

Cloud NAT ゲートウェイを作成すると、限定公開の Google アクセスが自動的に有効になります。ただし、プライベート IP アドレスを持つ Dataflow ワーカーが Google Cloud APIs とサービスが使用する外部 IP アドレスにアクセスできるようにするには、サブネットの限定公開の Google アクセスを手動で有効にする必要があります。

Splunk の HEC 上り(内向き)トラフィックを Cloud NAT で使用