このドキュメントでは、Google Cloud のリソースから Splunk にログとイベントをストリーミングする、プロダクション レディ、スケーラブル、フォールト トレラントなログ エクスポート メカニズムの作成に役立つリファレンス アーキテクチャについて説明します。Splunk は、セキュリティとオブザーバビリティの統合プラットフォームを提供する一般的な分析ツールです。実際、ロギングデータは、Splunk Enterprise と Splunk Cloud Platform のいずれかにエクスポートすることを選べます。管理者であれば、IT オペレーションやセキュリティのユースケースにもこのアーキテクチャを使用できます。このリファレンス アーキテクチャをデプロイするには、デプロイ: Google Cloud から 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 アドオンを有効にするには、次の手順を実行します。
- Splunk で Splunk の手順に沿って、Google Cloud の Splunk アドオンをインストールします。
- Google Cloud で、Pub/Sub トピックを作成してロギングデータをエクスポートします。
- このトピックの Pub/Sub pull サブスクリプションを作成します。
- サービス アカウントを作成します。
- 作成したサービス アカウントのサービス アカウント キーを作成します。
- Pub/Sub 閲覧者(
roles/pubsub.viewer
)と Pub/Sub サブスクライバー(roles/pubsub.subscriber
)のロールをサービス アカウントに付与して、アカウントが Pub/Sub サブスクリプションからメッセージを受信できるようにします。 Splunk で Splunk の指示に沿って、Google Cloud の Splunk アドオンで、新しい Pub/Sub 入力を構成します。
ログ エクスポートからの Pub/Sub メッセージが Splunk に表示されます。
アドオンが機能していることを確認するには、次の手順を実行します。
- Cloud Monitoring で Metrics Explorer を開きます。
- [リソース] メニューで、
pubsub_subscription
を選択します。 - [指標] カテゴリで、
pubsub/subscription/pull_message_operation_count
を選択します。 - 1~2 分間、メッセージ pull オペレーションの数をモニタリングします。
設計上の考慮事項
次のガイドラインは、セキュリティ、プライバシー、コンプライアンス、業務の効率化、信頼性、フォールト トレラント、パフォーマンス、費用の最適化に関する組織の要件を満たすアーキテクチャの開発に役立ちます。
セキュリティ、プライバシー、コンプライアンス
以降のセクションでは、このリファレンス アーキテクチャのセキュリティの考慮事項について説明します。
- プライベート IP アドレスを使用して Dataflow パイプラインをサポートする VM を保護する
- 限定公開の Google アクセスを有効にする
- Splunk の HEC 上り(内向き)トラフィックを Cloud NAT で使用される既知の IP アドレスに限定する
- Secret Manager に Splunk の HEC トークンを保存する
- 最小権限のベスト プラクティスに沿ったカスタム Dataflow ワーカー サービス アカウントを作成する
- プライベート CA を使用する場合に、内部ルート CA 証明書の SSL 検証を構成する
プライベート 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 で使用される既知の IP アドレスに限定する
Splunk HEC へのトラフィックを既知の IP アドレスのサブセットに制限する場合は、静的 IP アドレスを予約して Cloud NAT ゲートウェイに手動で割り当てます。Splunk のデプロイによっては、これらの静的 IP アドレスを使用して Splunk の HEC 上り(内向き)ファイアウォール ルールを構成できます。Cloud NAT の詳細については、Cloud NAT でネットワーク アドレス変換を設定、管理するをご覧ください。
Secret Manager に Splunk の HEC トークンを保存する
Dataflow パイプラインをデプロイすると、次のいずれかの方法でトークン値を渡すことができます。
- 平文
- Cloud Key Management Service 鍵で暗号化された暗号テキスト
- Secret Manager によって暗号化、管理されるシークレットのバージョン
このリファレンス アーキテクチャでは、Splunk HEC トークンを保護する最も簡単で最も効率的な方法である、Secret Manager オプションを使用します。このオプションは、Dataflow コンソールまたはジョブの詳細からの Splunk HEC トークンの漏洩も防止します。
Secret Manager のシークレットには、シークレット バージョンのコレクションが含まれています。各シークレット バージョンには、実際のシークレット データ(Splunk の HEC トークンなど)が格納されています。後で追加のセキュリティ対策として Splunk HEC トークンをローテーションする場合は、新しいトークンを新しいシークレット バージョンとしてこのシークレットに追加できます。シークレットのローテーションの一般的な情報については、ローテーション スケジュールについてをご覧ください。
最小権限のベスト プラクティスに沿ったカスタム Dataflow ワーカー サービス アカウントを作成する
Dataflow パイプラインのワーカーは、Dataflow ワーカー サービス アカウントを使用してリソースにアクセスし、オペレーションを実行します。デフォルトでは、ワーカーはプロジェクトの Compute Engine のデフォルト サービス アカウントをワーカー サービス アカウントとして使用します。これにより、プロジェクト内のすべてのリソースに対する幅広い権限が付与されます。ただし、Dataflow ジョブを本番環境で実行するには、最小限のロールと権限のセットでカスタム サービス アカウントを作成することをおすすめします。このカスタム サービス アカウントは、Dataflow パイプライン ワーカーに割り当てることができます。
次の図は、Dataflow ワーカーが Dataflow ジョブを正常に実行するために、サービス アカウントに割り当てる必要があるロールを示しています。
図に示すように、Dataflow ワーカーのサービス アカウントに次のロールを割り当てる必要があります。
- Dataflow 管理者
- Dataflow ワーカー
- Storage オブジェクト管理者
- Pub/Sub サブスクライバー
- Pub/Sub 閲覧者
- Pub/Sub パブリッシャー
- シークレット アクセサー
Dataflow ワーカー サービス アカウントに割り当てる必要があるロールの詳細については、デプロイガイドの Dataflow ワーカー サービス アカウントにロールとアクセス権を付与するセクションをご覧ください。
プライベート CA を使用する場合に、内部ルート CA 証明書を使用して SSL 検証を構成する
デフォルトでは、Dataflow パイプラインは Dataflow ワーカーのデフォルトのトラストストアを使用して、Splunk HEC エンドポイントの SSL 証明書を検証します。プライベート認証局(CA)を使用して、Splunk HEC エンドポイントで使用される SSL 証明書に署名する場合は、内部ルート CA 証明書をトラストストアにインポートできます。Dataflow ワーカーは、インポートされた証明書を SSL 証明書の検証に使用できます。
自己署名証明書または非公開署名の証明書による Splunk のデプロイでは、独自の内部ルート CA 証明書を使用してインポートできます。SSL 検証は、完全に内部の開発とテストの目的でのみ無効にすることもできます。この内部ルート CA 方式は、インターネットに接続しない内部 Splunk のデプロイに最適です。
詳細については、Pub/Sub to Splunk Dataflow テンプレートのパラメータ rootCaCertificatePath
と disableCertificateValidation
をご覧ください。
業務の効率化
以降のセクションでは、このリファレンス アーキテクチャの業務の効率化に関する考慮事項について説明します。
UDF を使用して、処理中のログまたはイベントを変換する
Pub/Sub to Splunk Dataflow テンプレートは、カスタム イベント変換のユーザー定義関数(UDF)をサポートしています。使用例として、レコードにフィールドを追加して拡張する、一部の機密性のフィールドを消去する、必要のないレコードをフィルタにより除外するなどが挙げられます。UDF によって、テンプレート コード自体の再コンパイルや保持をすることなく、Dataflow パイプラインの出力形式を変更できます。このリファレンス アーキテクチャでは、UDF を使用して、パイプラインが Splunk に配信できないメッセージを処理します。
未処理のメッセージを再生する
パイプラインが配信エラーを受信し、メッセージの配信を再試行しない場合があります。この場合、次の図に示すように、Dataflow はこれらの未処理のメッセージを未処理のトピックに送信します。配信エラーの根本原因を修正したら、未処理のメッセージを再生できるようになります。
次のステップは、前の図に示したプロセスの概要を示しています。
- Pub/Sub から Splunk へのメイン配信パイプラインでは、ユーザーの調査のため、配信不能のメッセージが自動的に未処理トピックに転送されます。
オペレーターまたはサイト信頼性エンジニア(SRE)が、未処理のサブスクリプション内の失敗したメッセージを調査します。オペレーターがトラブルシューティングを行い、配信エラーの根本原因を解決します。たとえば、HEC トークンの構成ミスを修正すると、メッセージが配信される場合があります。
オペレーターが、再生に失敗したメッセージ パイプラインをトリガーします。この Pub/Sub から Pub/Sub へのパイプライン(前の図の点で強調表示された部分)は一時的なパイプラインで、失敗したメッセージを未処理のサブスクリプションから元のログシンクのトピックに戻します。
メイン配信パイプラインは、以前失敗したメッセージを再処理します。この手順では、パイプラインでサンプル UDF を使用して、失敗したメッセージ ペイロードを正しく検出およびデコードする必要があります。次のコードは、追跡目的の配信試行の集計を含む、条件付きデコード ロジックを実装する関数の一部を示しています。
// If the message has already been converted to a Splunk HEC object // with a stringified obj.event JSON payload, then it's a replay of // a previously failed delivery. // Unnest and parse the obj.event. Drop the previously injected // obj.attributes such as errorMessage and timestamp if (obj.event) { try { event = JSON.parse(obj.event); redelivery = true; } catch(e) { event = obj; } } else { event = obj; } // Keep a tally of delivery attempts event.delivery_attempt = event.delivery_attempt ||