ここでハマる！ AWSにEC2インスタンスとしてSplunkログ基盤を構築、検証してみた：セキュリティログ基盤クラウド化検討大解剖（2）

リクルートのSOCによるログ基盤クラウド化検討プロジェクトの概要や失敗談、そこから得た学びを紹介する連載。今回は、EC2インスタンスとしてSplunkを構築する上でハマったポイントや、「最適」と考えるアーキテクチャについて。

[田村由佳，リクルート]

訂正（2021年4月23日19時40分）

本稿公開時に、記事の一部に不正確な箇所があったので、表現を見直しました（編集部）。

　セキュリティオペレーションセンター（SOC）によるログ基盤クラウド化検討プロジェクトの概要や失敗談、そこから得た学びを紹介する本連載「セキュリティログ基盤クラウド化検討大解剖」。前回は、ログ基盤クラウド化検討プロジェクト（以降、本プロジェクト）の背景や概要、クラウドを検討した理由、その中でもAmazon Web Services（AWS）を検討した理由を紹介しました。

　今回は、AWSに「Amazon EC2」のインスタンスとして「Splunk」ログ基盤を構築する上で、ハマったポイントにも触れながら、われわれが「最適」と考えるアーキテクチャについて、主に技術的な観点で解説します。

本プロジェクトの流れ

　前回の再掲ですが、下図のスケジュールでプロジェクトを推進しました。

プロジェクト推進スケジュール

　本稿では、【3】機能検証と【4】取り込み／検索性能検証を中心に紹介します。【3】機能検証ではログの取り込み方式やSmart Storeの設定方法や動作を中心に、【4】取り込み／検索性能検証ではログの取り込み性能とSmart Storeの検索性能を確認しました（【6】〜【8】の検証内容や結果については、次回触れる予定です）。

検証構成

　今回の検証を実施するに当たって、下記の構成としました。

• Splunk Enterprise バージョン7.3.3
• Splunk Add-on for Amazon Web Services バージョン4.6.1

全体構成図

　弊社では、セキュリティ監視で利用するログをストリーム処理で、監査レポートで利用するログを日次のバッチ処理でSplunk基盤に取り込んでいます。本検証では、ストリーム処理での取り込み（以降、リアルタイムログ取り込み）に「Amazon Kinesis Data Firehose」（以降、KDF）を使って、バッチ処理での取り込み（以降、バッチログ取り込み）に「Splunk Add-on for Amazon Web Services」を使いました。

　このアドオンはSplunk社によって開発され、公式にサポートされています。詳細については公式サイトをご参照ください。

　今回の構成では、AWSのマネージドサービスを有効に使うことで可用性や性能などといった管理すべきポイントを減らして、運用負荷の軽減を狙いました。また、取り込み対象のデータを「Amazon Simple Storage Service」（以降、S3）に集約することによって、不測の事態における再取り込みや同じデータを持った環境を、容易に何面でもビルド＆スクラップできる設計としています。

　下記は、使用したインスタンスです。

インスタンス一覧

機能検証

ログの取り込み

　ログの取り込みには、オンプレミスで利用しているログを幾つかサンプリングして使用しました。使用したログは下記の通りです。

使用したログ一覧

　まずは、リアルタイムログ取り込みのアーキテクチャを解説します。ストリーミング処理が可能でSplunkと連携可能なマネージドサービスを検討した際、候補として上がったものがKDFでした。そこで、KDFを使用した取り込み方法の確認と仕様を確認しました。

リアルタイムログ取り込み構成図

　「fluentd」を使って、アップロードマシンからKDFにデータを転送しました。KDFでは、期間またはデータサイズでバッファーして、エンドポイントに指定した「Classic Load Balancer」（以降、CLB）にデータを送信するとともに、S3にもデータをバックアップできるようにしました。CLBはHTTP Event Collector（通称「HEC」）で、Indexer（またはHeavy Forwarder）に分散してデータ送信します。

　KDFの宛先にSplunkを指定した場合、S3にバックアップするためのバッファー期間やサイズを指定できますが、Splunkにデータを送信するまでのバッファー期間やサイズを指定することはできませんでした。データを送信してみた結果、リアルタイム性を期待していたもののインデクシングされるまでに数十秒〜1分程度の時間がかかりました。

　また、S3にバックアップされているデータから再取り込みを実施する場合、「どのログファイルに再取り込みしたいイベントが含まれているか」を判断しにくいという課題を得ました。データの重複取り込みを防ぐために、既にSplunkに取り込まれたデータを、期間を絞って削除して、再度同じ期間のデータ取り込むことを想定していました。しかし、この方式では不測の事態のリカバリーには対処が難しいことが分かりました。

　次は、バッチログ取り込みのアーキテクチャについてです。

　バッチログ取り込みには、アドオンに含まれている「SQS-Based S3 inputs」を使いました。このアドオンを利用してS3からデータを取り込むには3通りの方式があります。本検証で利用したログは、AWSサービスの出すログではなく、カスタムログと分類されるログ種別です。このカスタムログを取り込むことができて、スケールアウト構成が取れる方式はSQS-Based S3 inputsのみでした。

Splunk Add-on for AWSを使用したS3からのログ取り込み方法

　取り込み時の各コンポーネントの連携図は下記の通りです。

バッチログ取り込み構成図

　S3にデータがアップロードされると、S3イベント通知で「Amazon Simple Notification Service」（以降、SNS）に通知され、メッセージが「Amazon Simple Queue Service」（以降、SQS）のメッセージキューにたまります。メッセージ内にはアップロードされたログデータのS3保存場所がパスで記載されており、Heavy Forwarder（以降、HF）はメッセージ内のパスを確認して、S3にデータを取りにいきます。

　ログデータがS3にアップロードされてからSNSとSQSを経由し、HFでデータを処理するため、インデクシングされるまでにそれなりの遅延が発生することを想定していました。しかし、いざ検証してみると、想定よりも遅延は少なく、数秒程度で取り込みが完了する結果となりました。また、Splunk内に取り込まれたログデータが、どのファイルに含まれているか明確なため、再取り込みが容易であったこともうれしいポイントでした。

　以上の結果からログの取り込み方式について、当初想定していた方式から見直しを図ることとしました。詳細については後述します。

Smart Storeとは

　前回少し触れましたが、弊社ではSplunkをフォレンジック業務にも活用しています。フォレンジック業務では、監視と比べると比較的長期間にわたる年単位のログを保管するので、数十TBのディスク容量が必要になるケースがあります。

　「Smart Store」は、S3の非常に安価なオブジェクトストレージをSplunkのデータ保管領域として使える機能です。EC2インスタンスの高価な「Amazon Elastic Block Store」（以降、EBS）に年単位でTBクラスのデータを保管する必要がないので、保持すべきデータ量が増えれば増えるだけコスト削減が図れる利点があります。

　下図は、Smart Storeを使用した場合と使用しない場合のコスト比較です。1カ月当たり48万円近いコスト削減効果が期待できそうだと分かりました。

Smart Store使用によるコスト削減効果

　また、S3は使用量の上限がないので、「ストレージの空きがなくなって必要な保持期間を保証できない」という問題が起きません。この2つの圧倒的な優位性に魅力を感じつつも、「本当にそんなことが可能なのか？」と疑問を抱えながら、Smart Storeの技術検証を決断しました。

　われわれが想定するSmart Storeの用途は、主にフォレンジック業務などのデータ保持期間が長期間になるものとして、監視業務のように必要なデータが比較的短期間であり、即時性が求められるものについてはインデックスを別にして、EBSに保持することにしました。

　ここで少しSmart Storeのアーキテクチャと動作について触れます。下図は、データ取り込み時の処理フローです（参考：【GOJAS Meetup-10】Splunk：Smart Storeを使ってみた）。

Smart Storeのアーキテクチャ図（取り込み時）

　Splunkのインデックスには「バケツ」という概念があり、デフォルトでHotバケツ、Warmバケツ、Coldバケツという3種類のバケツが存在します。Hotバケツは新しいデータが格納されるバケツです。次のWarmバケツは、Hotバケツから一定期間過ぎたデータが格納され、Coldバケツはアクセス頻度の低くなった古いデータがWarmバケツから移動してきます。

　WarmバケツとColdバケツは読み取りのみ可能なバケツです。Smart Storeを使用すると、仕様によりHotバケツとWarmバケツのみでColdバケツは存在しなくなります。バケツがHotからWarmにローテーションされた際に、S3にアップロードされる仕組みとなっており、Warmバケツは、S3とローカルディスク上のキャッシュ領域に保持されます。

　ではキャッシュ領域からデータが削除されるタイミングがいつかというと、設定したしきい値にローカルディスクの使用量が達した際に、S3にアップロード済みのキャッシュが削除されます。キャッシュポリシーの設定として、キャッシュの保持期間に関する設定がありますが、ローカルディスクの使用量がしきい値に達していないとキャッシュは削除されません。削除するデータの優先順位には、幾つかのロジックが存在します。詳細は、性能検証のパートで後述します。

　取り込むデータ量が増加した際は、ローカルディスクに保管されている期間が短くなりますが、S3に保管されているので、ディスクがいっぱいになってもデータをロストすることはありません。

　続いて、検索時のSmart Storeの処理フローを説明します。検索時は、最初にローカルディスク内のデータを探し、存在しない場合はS3にデータを探しに行きます。S3に対象データが存在する場合は、ローカルディスクのキャッシュ領域にデータをダウンロードし、Search Headにデータを渡します。キャッシュ領域にダウンロードされたデータは指定期間後に削除されます（参考：【GOJAS Meetup-10】Splunk：Smart Storeを使ってみた）。

Smart Storeのアーキテクチャ図（検索時）

性能検証

Smart Store