はじめてのSplunk ― 概要から応用までを体系的に学ぶ

第2章 Splunkのアーキテクチャ

2-6 一般的なSplunkの導入構成

このページの内容
  1. Splunk Enterpriseの構成案
  2. Splunk Cloudの構成案
  3. まとめ

Splunkを導入する際、Splunk Cloudであればサーバーのサイジングや構成はSplunkがおおよそ決定してくれますが、 オンプレ版であるSplunk Enterpriseを導入するときは、ユーザー側で構成を決定する必要があります。

ここでは、Splunk Enterprise/Splunk Cloudそれぞれにおいて、よくある構成/アーキテクチャを紹介します。

Splunkには、SVA(Splunk Validated Architectures)という公式ドキュメントが存在しています。 以下も参考にしてください。

About Splunk Validated Architectures

https://help.splunk.com/en/splunk-cloud-platform/splunk-validated-architectures/introduction-to-splunk-validated-architectures/about-splunk-validated-architectures

1. Splunk Enterpriseの構成案

Splunk Enterpriseの場合、ユーザー側で要件を踏まえて構成を決定する必要があります。 パフォーマンスや可用性を高くすればするほど、構成は複雑になりサーバーコストも増加するためバランスが難しいという問題があります。

OS/ハードウェア要件

Splunkは、主要なLinuxおよびWindows Server上で動作します。 ただし、やや高めのハードウェア要件があることに注意してください。 具体的には、シングルインスタンス構成であっても、CPU12物理コア, メモリ12GB, SSDストレージがリファレンスハードウェア要件となっています。 リアルタイムにデータを取り込み、継続的にサーチが実行されるというシステムの特性上、使用するハードウェアリソースは高めと考えておいたほうがよいでしょう。

必要なOS/ハードウェア要件は以下を参考にしてください。

System requirements for use of Splunk Enterprise on-premises

https://help.splunk.com/en/splunk-enterprise/get-started/install-and-upgrade/10.4/plan-your-splunk-enterprise-installation/system-requirements-for-use-of-splunk-enterprise-on-premises

Reference hardware

https://help.splunk.com/en/splunk-enterprise/get-started/deployment-capacity-manual/10.4/performance-reference/reference-hardware

シングルインスタンス構成

1台のサーバーにSearch HeadロールとIndexerロールをはじめとした全ロールを同居させる最もシンプルな構成です。 シンプルな構成ながら、取り込むデータ量が300GB/day、総ユーザー数4以下であればおおよそ対応可能と思われるため、最初はこの構成から始めることが最もシンプルで運用負荷が低いと思われます。

flowchart RL
  fwd1["Forwarder"] -->|"9997/TCP"| si
  fwd2["Forwarder"] -->|"9997/TCP"| si
  si["Splunk Enterprise"]
  user(["ユーザー"]) -->|"8000/TCP(ブラウザ)"| si
  si ~~~ user
シングルインスタンス構成

サーバー構成の目安は以下を参考にしてください。

Summary of performance recommendations

https://help.splunk.com/en/splunk-enterprise/get-started/deployment-capacity-manual/10.4/performance-reference/summary-of-performance-recommendations

Search Head - Indexer分離構成

Search HeadサーバーとIndexerサーバーを分離させた構成です。 Splunkで負荷の高い処理はIndexerが行うことが多いため、Indexerは自身のロールに専念させます。 管理系ロールはSearch Headサーバーが行う構成としたほうがよいでしょう。

flowchart RL
  fwd1["Forwarder"] -->|"9997/TCP"| idx["Indexer"]
  fwd2["Forwarder"] -->|"9997/TCP"| idx
  sh["Search Head"] -->|"8089/TCP"| idx
  user(["ユーザー"]) -->|"8000/TCP(ブラウザ)"| sh
  idx ~~~ sh
  sh ~~~ user
Search Head - Indexer分離構成

シングルインスタンスを発展させた構成ですが、個人的にあまりこの構成を見たことはありません。 サーバーを分離させることによって、パフォーマンスは向上しますが、逆にサーバーが二台となってしまうために可用性は下がってしまっているためです。 本番環境などで、Splunkに高い信頼性を求める場合は、Indexer Clusterの導入またはSplunk Cloudを採用したほうがよいと思われます。

Indexer Cluster構成

Indexerのクラスター構成です。 新しく、Indexer Cluster Manager(Cluster Manager)を導入する必要があります。 このCluster Managerが、Indexer Clusterサーバー間のデータの同期処理を管理したり、障害発生時に障害発生中のサーバーの切り離しなどを担当します。 導入に関しては、おそらくSplunkの専門スキルを持った人員が必要となります。

flowchart RL
  fwd1["Forwarder"] -->|"9997/TCP"| idxc
  fwd2["Forwarder"] -->|"9997/TCP"| idxc
  sh["Search Head"] -->|"8089/TCP"| idxc
  user(["ユーザー"]) -->|"8000/TCP(ブラウザ)"| sh
  cm["Cluster Manager"] -.->|"8089/TCP"| idx1
  cm -.->|"8089/TCP"| idx2
  cm -.->|"8089/TCP"| idx3
  idxc ~~~ sh
  sh ~~~ user
  subgraph idxc["Indexer Cluster"]
    idx1["Indexer"]
    idx2["Indexer"]
    idx3["Indexer"]
    cm
  end
Indexer Cluster構成

Indexer Clusterは2台から構成可能です。 2台の場合、基本的にはデータをお互いレプリケーションして持つことになります。 3台以上でクラスターを組んだ場合は、常に全台がデータの全レプリケーションを持たないよう設定し、パフォーマンスやリソース量を効率化することも可能です。

Search Head Cluster & Indexer Cluster構成

Indexerだけでなく、Search Headもクラスター化した構成です。 更にDeployer(Search Head Cluster Deployer)も導入されます。 Deployerは、Search Head Clusterを管理するサーバーではなく、Search Headに整合性を持った状態でAppや設定を配布する存在であることに注意が必要です。

flowchart RL
  fwd1["Forwarder"] -->|"9997/TCP"| idxc
  fwd2["Forwarder"] -->|"9997/TCP"| idxc
  shc -->|"8089/TCP"| idxc
  user(["ユーザー"]) -->|"8000/TCP(ブラウザ)"| shc
  cm["Cluster Manager"] -.->|"8089/TCP"| idx1
  cm -.->|"8089/TCP"| idx2
  cm -.->|"8089/TCP"| idx3
  dep["Deployer"] -.->|"8089/TCP"| sh1
  dep -.->|"8089/TCP"| sh2
  dep -.->|"8089/TCP"| sh3
  idxc ~~~ shc
  shc ~~~ user
  subgraph shc["Search Head Cluster"]
    sh1["Search Head"]
    sh2["Search Head"]
    sh3["Search Head"]
    dep
  end
  subgraph idxc["Indexer Cluster"]
    idx1["Indexer"]
    idx2["Indexer"]
    idx3["Indexer"]
    cm
  end
Search Head Cluster & Indexer Cluster構成

Indexer Clusterと違い、Search Head ClusterはSearch Head3台からクラスター化が可能になります。 これは、IndexerとSearch Headでは、クラスター化の仕組みそのものが異なっていることが理由です。

ここまでくると用意しなければならないサーバーもかなり多くなります。 非常に大規模にSplunkを利用しており、かつ極めて高い可用性を要求する環境でなければこの構成を見かけることはあまりないかもしれません。

2. Splunk Cloudの構成案

Splunk Cloudの場合、構成についてはSplunk側が決定します。 Search Headは規模によってシングル構成かクラスター構成が決定され、Indexerは基本的には複数のアベイラビリティゾーンに分散配置されるようです。

Splunk Cloudの構成を知りたい場合は以下を参考にしてください。

Splunk Cloud Platform Experiences

https://help.splunk.com/ja-jp/data-management/splunk-validated-architectures/splunk-cloud-platform/splunk-cloud-platform-experiences

Splunk Cloudを利用する場合のデータ転送経路

オンプレ版のSplunk Enterpriseを利用する場合はそこまで問題にならないことも多いのですが、 SaaS版のSplunk Cloudを利用する場合は、どのようにオンプレ環境からSaaSのSplunkにデータを転送するのか気になると思われます。

ほとんどのケースで、オンプレ環境からSplunk Cloudにデータを転送する場合は、 オンプレ環境側にIntermediate Forwarderをプロキシサーバーとして構築し、 Intermediate Forwarder経由でデータを転送する経路にすることが一般的です。 Intermediate ForwarderとSplunk Cloud間の転送中のデータはSSLにて暗号化されます。

flowchart RL
  fwd1["Forwarder"] -->|"9997/TCP"| intf
  fwd2["Forwarder"] -->|"9997/TCP"| intf
  intf["Intermediate<br/>Forwarder<br/>(UF or HF)"] -->|"9997/TCP(TLS暗号化)"| cloud["Splunk Cloud"]
  user(["ユーザー"]) -->|"HTTPS"| cloud
  cloud ~~~ user

  subgraph onprem["オンプレ環境"]
    fwd1
    fwd2
    intf
  end
Splunk Cloudを利用する場合のデータ転送経路

3. まとめ

  • Splunkはシステムの特性上、要求されるハードウェアリソースは高め
  • Splunk Enterpriseの場合、最初はシングルインスタンス構成から始めるのが個人的なお勧め
  • 高い可用性を要求する環境向けにクラスター構成をとることも可能。ただし導入にはそれなりのスキルが必要
  • Splunk Cloudの場合はSplunkが構成を決定し、かつデフォルトでIndexerは分散配置される