一般的なSplunkの導入構成

このページの内容

2-5で見たサーバー群は、実際にはデータ量や可用性の要件に応じて組み合わせて配置します。この節では、規模に応じた典型的な導入構成を、小さいものから大きいものへと順に説明します。

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

最もシンプルなのがシングルインスタンス構成です。 1台のSplunkサーバーが、Search Head(検索)とIndexer(保管・検索実行)の役割を兼ねて動作します。データはForwarderから、あるいはそのサーバー自身に直接取り込みます。

構築や管理が簡単なため、検証環境や小規模な利用、あるいは学習用途に向いています。一方で、1台にすべての処理が集中するため、データ量が増えると性能面で頭打ちになりやすく、そのサーバーが停止すると全体が止まってしまう点には注意が必要です。

データ量が増えてくると、役割を分けた分散構成へと発展させます。典型的には、検索を担うSearch Headを分離し、データの保管と検索実行を担うIndexerを複数台並べます。

2-1で学んだとおり、検索は複数のIndexerに分散して実行されます。 Indexerを増やせば、その分だけ保管容量と検索性能を伸ばせるため、扱うデータ量の増加に合わせて横方向に拡張(スケールアウト)できるのがこの構成の利点です。

さらに大規模になり、可用性(止まりにくさ)やデータ保全がより重要になると、クラスタ構成を採用します。クラスタには大きく2種類があります。

クラスタ	目的	関連する管理サーバー
インデクサークラスタ	Indexerを束ね、データを複製して保管する。1台が故障してもデータと検索を維持できる	Cluster Manager(CM)
サーチヘッドクラスタ	複数のSearch Headを束ね、検索の負荷分散と設定の共有を行う	Deployer

インデクサークラスタでは、同じデータを複数のIndexerに複製して持たせるため、一部のIndexerが停止してもデータを失わず検索を続けられます。サーチヘッドクラスタでは、複数のSearch Headで検索を分担しつつ、ダッシュボードや設定を共有できます。

クラスタ構成では、2-5で紹介したCMやDeployerといった管理系サーバーが必要になります。役割ごとのサーバーが増える理由は、こうした可用性・拡張性の要件にあります。

どの構成を選ぶかは、扱うデータ量と求められる可用性でおおよそ決まります。小さく始めて、必要に応じて段階的に拡張していくのが基本的な考え方です。

なお、前節で見たSplunk Cloudを使えば、こうした構成の設計や運用を Splunk社に任せられるため、規模の大きな環境でも運用負担を抑えられます。