概要

Splunk EnterpriseのSmart Store機能を使用した場合のインフラのコストについて試算してみました。
この記事は、Splunk Enterpriseのアーキテクチャについてやや専門的な知識を持った方を対象にしています。

導入

私は誰？

とある企業のプライベートSOC（セキュリティオペレーションセンター）でSplunkによるログ分析基盤の構築・運用などをしています。
なお、この記事に記載の内容は個人の見解であり、Splunk社や筆者が所属する組織の統一的見解ではないことを、あらかじめお断りします。

Splunkとは

Splunkとは、一言で言うと「統合ログ解析・管理ツール」です。様々なログを収集して解析することができ、特にSIEM（Security Information and Event Management）の分野では長年に渡りリーダーの地位を獲得しています。

参考： ガートナー社による2020年SIEM部門マジック・クアドラント

Splunkの魅力は以下の2点だと個人的には考えています。
- データの収集・蓄積・検索・可視化を1つの製品で完結できるので学習コストが低いこと
- スキーマレスでまずデータを取り込んで後から様々な加工を行なえる柔軟性の高さ
RDBや全文検索エンジンなどで似たようなことはできるかもしれませんが、収集・蓄積・検索・可視化を行なうには多くの場合様々な製品を組み合わせる必要があり、そう簡単にはSplunkを代替できないと思います。

なお、特に断りのない限り、この記事内でSplunkと記載した場合は、2021年4月時点で最新版の Splunk Enterprise 8.1 系を指すものとします。

Splunk社はEULAにてベンチマーク結果を勝手に公開することを禁止しています。この記事内で性能について触れている場合は、公開情報からの推測ですのでご承知おきください。

参考： Splunk Software License Agreement

Unless otherwise expressly permitted by Splunk, Customer will not and has no rights to: ...
(f) provide to any third party the results of any benchmark tests or other evaluation of any Splunk Materials without Splunk's prior written consent; 

Smart Storeとは

Smart Store (略してS2とも言う) とは、SplunkのIndex(Warm Buckets)をローカルストレージの代わりに、AWS S3などのオブジェクトストレージ（リモートストレージ）に格納することができる機能です。Splunkのバージョン7系から実装された機能で、比較的新しい機能と言えます。

Smart Storeを使う最もわかりやすいメリットとして、ストレージのコストを削減できることが挙げられます。特にAWSなどのIaaSの環境でメリットが顕著です。AWS上にEC2でSplunkを構築する場合、Smart Storeを使わないと、EBSにIndexを格納することになりますが、EBSは容量に比例して料金が増大するので、たとえば数十TBの規模になるとかなり高価になってしまいます。

この記事では、Smart Storeを使うことでどの程度コスト削減効果があるのか試算してみました。

参考： Splunk Enterprise - Managing Indexers and Clusters of Indexers - About SmartStore

前提知識

Smart Storeの動作

前提知識として、少しSplunkのIndexerの内部の話をします。
Indexerでは、IndexをBucketという単位で管理します。Bucketはファイルシステム上のディレクトリです。Bucketが複数集まったものをBucketsと呼びます（日本語だとどっちもバケツになってしまいますが）。Bucketsは、データの新しさによって、Hot Buckets、Warm Buckets、Cold Buckets、Frozen Bucketsという段階に分けられており、Bucketに格納されているデータが古くなると順番に移動されていきます。ColdとFrozenは使わない場合もあります。

Splunkでは、Buckets毎に格納先を分けることができます。たとえばHot Bucketsは頻繁に検索されるのでSSD, 古いデータが格納されるCold BucketsはHDDに格納するようなことができます。
Smart Storeを使うと、Hot Bucketsはローカルストレージに書き込みますが、Warm Bucketsに移動するタイミングでAWS S3などのリモートストレージに書き込まれるようになります。
Indexをサーチする場合、Hot Bucketsにあるデータはローカルストレージから直接読み込まれるので、Smart Storeを使わない場合と動作はさほど変わりません。Warm Bucketsにあるデータを検索する場合は、リモートストレージからローカルストレージに一時的にデータを読み込む動作になります。読み込んだデータはローカルストレージにキャッシュされます。

サーチ時にデータがHot Bucketsもしくはキャッシュにないと、リモートストレージから読み込む必要があるのでオーバーヘッドが生じます。Splunk社の資料によると、概ね30%程度の性能低下があるとのことです。
なお、IndexingについてはHot Bucketsが使われるので、Smart Storeのありなしで動作に変わりはないとのことです。

Smart Storeを使う場合、ローカルストレージの容量は少なくて済みますが、キャッシュとしても使われるのでより高いIO性能（IOPS, スループット）が必要になります。IO性能が高いストレージは高価なので、ある程度大容量（つまり長期間）のIndexを保存する場合でないと、Smart Storeのコストメリットは出づらいということになります。

Smart Storeの動作についてはこちらの資料がわかりやすいと思います。

参考： Splunk .conf19 Smart Store Deep Dive

Splunk のサイジング

Splunkを載せるインフラのサイジングは、（ワークロードが読みづらいWebアプリケーションなどと比べると）比較的容易な部類だと個人的には思います。
Splunk社がリファレンスハードウェアを公開しているので、そのスペックに従えば大幅にサイジングを外すことはあまりないと思います。

サイジングの際に、特に重要だと考えるパラメータは以下です。

• 1日あたりのログ取り込み容量： 主にIndexerの台数とストレージ容量に関係します
• 保存期間： 主にIndexerのストレージ容量に関係します
• 同時サーチ数： 主にSearch Headの台数（CPUコア数）に関係します
• Indexerの可用性： Indexer Clusterの要否に関係します
• Search Headの可用性： Search Head Clusterの要否に関係します
• SF(Search Factor), RF(Replication Factor): Indexer Clusterを使用する場合のストレージ容量に関係します

参考： Splunk Enterprise - Capacity Planning Manual - Reference hardware

ストレージ容量の見積もりは、Splunk社が用意しているツールを使うと便利です。

参考： Splunk Storage Sizing

Splunk のアーキテクチャ

Splunk社は、Splunkのコンポーネントの妥当な構成をまとめた Splunk Varlidated Architecture (SVA) という文書を公開しています。
このSVAと、サイジングの情報があれば、ほとんどの場合において妥当なSplunkの構成を見積もることができると思います。

この記事では、中～大規模構成に対応できて、可用性も確保できる、Distributed Clustered Deployment + SHC - Single Site (C3) 構成をベースに考えます。

参考： Splunk Validated Architectures

コスト試算

Splunk要件

前置きが長くなりましたが、ようやくコスト試算に入ります。
Splunkの要件は以下のようなものを考えてみます。

• 1日あたりのログ取り込み容量： 200GB
• 保存期間： 3ヶ月 or 1年
• 同時サーチ数： 20～30程度
• Indexerの可用性： 必要
• Search Headの可用性： 必要
• SF,RF： 2 （Smart Storeを使う場合は値を揃える必要があります）

システム構成はSVAを参考に以下のようにします。

見積条件

インフラはAWS上に構築することを前提とします。EC2のインスタンスタイプはSplunk社のホワイトペーパーに準ずることとします。Splunkのリファレンスハードウェアの条件を満たした構成なので、これに従えば大幅にサイジングを外すことはあまりないと思います。

Splunk社によると、Smart Storeを使う場合は、IO性能に優れたi3インスタンスを使用するのがよいようです。c5インスタンスなどでも動くには動きますが、EBSのIO性能が問題になるようです。具体的には、高性能のio2でも最大のスループットは1000MBytes/secですが、S3のスループットは10Gbps（=1250MBytes/sec）に達するのでEBS側がボトルネックになり、キャッシュとしての性能を発揮できないようです。
EBSはSSDとはいっても裏側はiSCSIでつながってるNASみたいなもんで、本物のNVMe接続のSSDと比べると桁違いに性能が低いので当然といえば当然です。

参考： Amazon Web ServicesへのSplunk Enterpriseの導入

参考： Splunk Communityの投稿

i3インスタンスはローカルストレージとしてNVMeのSSDを搭載しているので、キャッシュとして使うのに向いています。注意点として、ローカルのNVMeはエフェメラルストレージ（電源OFF/ONすると消える）なので、実運用するには起動時にLVMを自動設定するなどの工夫が必要になります。

Search Headのインスタンスについては、ホワイトペーパーではc5.9xlargeになっていますが、私の趣味で、AMDのCPUを搭載した似たようなスペックのc5a系のインスタンスで試算してみます。
Splunkはずっと起動しているソフトウェアなので、On Demandインスタンスだとコストパフォーマンスが悪くなります。ここでは、EC2 Instance Saving Plans の1年前払い無しプランで計算してみます。AWSのリージョンは、ap-northeast-1（東京）にします。
コストの計算は AWS Pricing Calculater を使用します。

参考： AWS Pricing Calculator

構成1： 保存期間3ヶ月、Smart Store なし

保存期間3ヶ月、Smart Store なしという、オンプレのSplunkでもよく使われそうなパターンを見積もってみます。
必要なストレージ容量をSplunk社のサイジングツールで見積もってみます。典型的なログファイルを取り込む場合は、1日あたりの容量と保存期間を入力するだけで、それほど大きくサイジングを外すことはないと思います。

参考： ストレージ容量サイジング（ローカルストレージ）

Indexer 1台あたりの必要容量は5.9TBなので、20%ほどファイルシステムの余裕を見て、EBSのサイズは7TBにしておきます。
なお、Indexer故障時の縮退については考慮しないこととします。

見積もり結果は以下のようになりました。月額90万円といったところです。なかなかいい値段ですが、ぶっちゃけこの規模だとSplunkのライセンスの方が高いです。

構成2： 保存期間3ヶ月、Smart Store あり

保存期間3ヶ月で、Smart Store ありのパターンを見積もってみます。
Smart Storeを使う場合は、ローカルストレージとして1ヶ月程度の容量を確保するのがよいようです。試算だと2TBですが、i3.8xlargeは1900GBのNVMeストレージが4個付いてるので、それでRAID0を組めば十分な容量と言えそうです。

参考： ストレージ容量サイジング（ローカルストレージ）

Smart Storeの必要容量は、SF/RFを考慮しない値と同じになるはずなので、ざっくり10TBとしておきます。

参考： ストレージ容量サイジング（リモートストレージ）

構成1と比べると、EBSのコストは減りますが、i3インスタンスの単価が高いので、構成1より若干高くなってしまいました。この見積条件では、保存期間3ヶ月程度だとコストメリットが出ないようです。

構成3： 保存期間1年、Smart Store なし

保存期間1年、Smart Store なしのパターンで見積もってみます。必要なストレージ容量は70TB程度になってきます。今どきのオンプレのストレージだと70TBはもはや小容量ですが、EBSだとなかなかの大容量だと思います。

余談ですが、逸般的な誤家庭の住人だと自宅に100TB超のストレージを持ってる人もいるとかいないとか。我が家はまだ一般的だと思いますが、生のストレージの容量を合計すると30TBくらいはあります。AWS上に大容量のデータを置くなら、EBSのような高価なストレージを使うとコストがつらいですね。

Indexer 1台あたりの必要容量は23.4TBなので、構成1と同じ考え方で、EBSのサイズは28TBにしておきます。なお、EBS1個あたりの容量は16TBまでなので、この場合は1台のEC2に複数のEBSをアタッチしてRAID0を組むなどの対応が必要になります。

参考： ストレージ容量サイジング（ローカルストレージ）

構成1と比べるとEBSの容量だけが違いますが、これだけの容量のEBSを使うと、EBSのコストがEC2のコストを超えて支配的になってきますね。

構成4： 保存期間1年、Smart Store あり

保存期間1年、Smart Store ありのパターンで見積もってみます。Indexの大部分はS3に保存されるようになるので大きなコスト効果を見込めそうです。
Smart Storeの必要容量は、構成2と同じ考え方で、ざっくり40TBとしておきます。

参考：ストレージ容量サイジング（リモートストレージ）

構成3と比べると月額で60万円程度のコスト削減効果を見込めそうです。保存期間が長くなると、Smart Store のコストメリットが効いてきますね。

比較

グラフで比較すると以下のようになります。保存期間の長さと、Smart Storeのありなしで、EC2とストレージ（EBS/S3）のコスト構造が変わることがよくわかると思います。

まとめ

Splunk Smart Store を使う場合のインフラのコストを試算してみました。
Indexの保存期間が長い場合は、Smart Storeを使うことでコスト削減できそうであることがわかりました。しかし、保存期間が短い（概ね3ヶ月程度）の場合は、コストメリットが出づらいことがわかりました。Smart Storeのメリットはコスト以外にもあるので、サーチ性能の低下や、高価なインスタンスタイプを使う必要があるなどのデメリットとのトレードオフで考えるのがよいと思います。
AWSなどのIaaS上でSplunkを利用するときは使ってみる価値があると思いますので、参考にしてもらえればと思います。