はじめまして。NTTドコモのサービスデザイン部の渡辺と申します。NTTドコモ R＆D ADvent Calendar 2022の22日目を担当いたします。

本記事ではログの統合分析ソフトウェアであるSplunkについて、実際に利用してみて有用だと思ったクラスタ構成におけるSplunkの再起動方法についてご紹介します。どなた様かのお役に立てれば幸いです。

1.　Splunkとは？

この記事を読もうとした方は既にご存知かもしれないですが、Splunkの簡単な説明をしようと思います。
ただこちらについては、私の先輩が以前執筆したこちらの記事がわかりやすいので引用させていただきます。

Splunkアーキテクチャ

（画像引用）https://docs.splunk.com/File:Horizontal_scaling_new2_60.png

基本的なコンポーネント * Search Head（SH）：Indexer（後述）に格納されたログを検索するためのコンポーネント。ユーザはSHのWeb UIにSPL（後述）と呼ばれるSplunk独自の検索処理言語（Splunk版のSQLのようなもの）を記述しログの検索が可能。資材配布のためのコンポーネントであるDeployer を用意し、クラスタ構成(SHC： Search Head Cluster)を組むことで可用性が向上する。 * Indexer（IDX）：ログを格納（インデックス）するためのコンポーネント。クラスタ構成（IDXC：Indexer Cluster）を組む場合はクラスタ管理コンポーネントであるCluster Master(CM)が必要となる。 * Forwarder（FWD）：ログ転送用のコンポーネント。Universal Forwarder（UF）と Heavy Forwarder（HF）の二種がある。詳細な説明は割愛するが、UFはほとんど無加工で転送し、HFはログのパースも可能という理解で良い。

その他管理系コンポーネント
* Licence Master（LM）：ライセンス管理コンポーネント。 * Deployment Server：FWD, IDX（非クラスタ構成）, SH（非クラスタ構成）への資材配布用コンポーネント。

全体の流れとしては、FWD→IDX→SHというフローでデータが転送され、ユーザはSHのGUIでSPLを記述し必要な情報を抽出するというイメージです。

この後の話に関連するところとしてはデータを格納するIDX、格納したデータを検索（サーチ）するSHの2つを覚えていただければ問題ないです。
引用した記事では、実際にユーザとして使うときに知っておくとためになる”かゆいところに手が届く”情報を知ることができるので、一読していただければSplunkへの理解が深まると思います！

2.　再起動で困ったこと

私が携わっているプロジェクトにおけるSplunkの使用用途では、24時間365日稼働することが求められ、ログの欠損や遅延も業務に影響があるという環境で利用しています。
そのため、以下のようにクラスタ構成を組んで冗長化することで、可用性の高い環境を用意して対応しています。

IDX：100台以上（クラスタ構成）
SH：4台（うち3台はクラスタ構成）その他の必須コンポーネント

しかし、ここで問題が…
クラスタ構成を組んだらもう完璧と思っていましたが、実際はそうではなく再起動時にはサーチができないということがわかりました。
ログの欠損や遅延をできるだけ避けたい中、私たちの環境ではIDXが100台以上あるため、再起動で数十時間かかる可能性があり大きな影響があります。
数十時間の停止はどうしても許容できないということで、Splunkのドキュメントを読み込んだり、サポートへ問い合わせをするなどしてがんばって方法を模索しました！
その結果、サーチを止めずに再起動できる方法を見つけたので皆様にご紹介します！

3.　リスタートやアップグレードに関して知っておいてほしい知識

再起動は厳密にはリスタートとアップグレードとして、Splunk内のドキュメントに記載されているのでここからはそのように表現します。ただ、基本的にやっていることは変わらないので同じようなものという理解でよいです。

サーチの種類

サーチには以下の2種類があります。

アドホックサーチ（ad hoc search）
検索バーなどから実施する通常のサーチ。
スケジュールサーチ、定期サーチ（scheduled search）
毎日、2時間ごとなど特定のタイミングで実施するように予約し、そのタイミングに自動的に実行されるサーチ。

さらにスケジュールサーチには以下の2種類のモードが存在します。

リアルタイムスケジューリングモード（realtime scheduling mode）
実行状況に応じてリアルタイムに次の実行予定時間を決定するモード。
具体的には、ある実行予定時間に同時実行サーチ数が最大値に達していた場合、サーチができるまで待機するが、そのまま次の実行予定時間を迎えるとスキップされる。
そのため、リアルタイム性が求められる、もしくはその瞬間のサーチじゃないと意味がないといったサーチに適している。
また、リスタート、アップグレード中は必ずスキップされる。
連続スケジューリングモード（continuous scheduling mode）
最後のサーチ実行時間に基づいて次の予定時間を設定するモード。
具体的には、ある実行予定時間に同時実行サーチ数が最大値に達していた場合、サーチができるまで待機し、そのまま次の実行予定時間を迎えても後で実行される。
そのため、とりあえず決まった回数実行してほしいサーチなどに適している。

IDXCのリスタート、アップグレードの種類

IDXのクラスタ環境においてはローリングリスタートを用いるのが一般的であるため、そちらをご紹介いたします。
通常のリスタート時はデータの取り込みができなくなりますが、ローリングリスタートはデータの取り込みを止めることなく実施できるという特徴があります。
ローリングリスタートには以下の3種類があります。

ローリングリスタート（Rolling Restart（RR））
クラスタ内の一定数のサーバ（デフォルトは10%）を一度に再起動する。
リスタート中のサーバにサーチしたいデータがある可能性があるため、サーチができる（サーチャブルである）保証はない。
※ここでいうサーチャブルでないとは、サーチを受け付けない、サーチがスキップされる、サーチが延期されることを指す。
サーチャブルローリングリスタート（Searchable RR）
実施中のサーチの中断を最小限に抑えるため1台ずつサーバをリスタートする。ただし、必ず中断を抑えられるわけではない。
SRR中に順次再起動するサーバは実施中のサーチが完了するかタイムアウトになるまで待機する。
サーチャブル状態を維持するため、再起動対象のサーバがもつデータは他のサーバに再割り当てする。
スケジュールサーチは以下のようにモードとオプションによりskip/defer（延期）/execute（実行）が決まる。
- リアルタイムスケジューリングモードはスキップ
- 連続スケジューリングモードはオプションによって以下の動作をする。
  -defer_scheduled_searchable_idxc
  true：SRR中のスケジュールサーチはdeferredされ、SRR完了後に再開しようとする。
  false：SRR中のスケジュールサーチは強制的に実行しようとするが、部分的な結果を返す可能性がある。
  
  ”部分的な結果を返す可能性がある”ここが重要です！！
  
  SRRで”スケジュールサーチ”を”連続スケジューリングモード”かつ”defer_scheduled_searchable_idxc = false”で実施すれば問題なくサーチを継続できそうですが、部分的な結果を返す可能性がある以上完全ではありません。
  しかしここさえクリアできればサーチを止めない再起動を実現できます。
  どうやってクリアするかですが、まずこの事象がどういう場合に部分的な結果を返すのか、これについてはドキュメント上では語られていません。（なぜだ…）
  ということで、サポートに頼ったところ、この事象はサーチがタイムアウトした場合に発生することがわかりました。
  このサーチのタイムアウト値は自分達で変更することができるので、使っているサーチの走行時間より長いタイムアウト値に設定することでサーチを止めずに再起動ができます。
強制サーチャブルローリングリスタート（SRR with force option）
こちらは2つ目のSRRの派生系で開始時に行うヘルスチェックがNGでも処理を継続するという方式。
それ以外はSRRと同様で、重要なところではないので詳細は割愛いたします。
詳しくは下記ドキュメントを見ていただければと思います。

参考ドキュメント

Managing Indexers and Clusters of Indexers
https://docs.splunk.com/Documentation/Splunk/latest/Indexer/Userollingrestart

また、リスタートの設定とアップグレードの設定は共通になっているため、割愛いたします。

SHCのリスタート、アップグレードの種類

SHCもIDXCと基本的には同じですがよりシンプルです。
RRとSRRは存在し同じような仕組みですが、サーチの種類によるスキップや遅延などの挙動の違いがないです。
なので、ユーザとしてはサーチの種類による挙動の違いの考慮は不要で、SRRでタイムアウト値のみを考慮すればサーチを止めずに再起動ができます。
詳しくは下記ドキュメントを見ていただければと思います。

参考ドキュメント

Restart the search head cluster
https://docs.splunk.com/Documentation/Splunk/9.0.2/DistSearch/RestartSHC

4.サーチを止めずに継続できるリスタートやアップグレード時の設定

3章の”リスタートやアップグレードに関して知っておいてほしい知識”でところどころ触れましたが、サーチ影響が出ない方法は具体的に次の条件で実施するというものです。

サーチャブルローリングリスタート（アップグレード）で実施する。
リスタート（アップグレード）時にサーチがスキップされないように、スケジュールサーチは全て連続スケジュールで実施し、「defer_scheduled_searchable_idxc」の設定をfalseにする。（SHCの場合は不要）
部分的な結果を返さないように、サーチの待ち時間を十分長くする。

このやり方のデメリットはリスタート（アップグレード）の時間が長くなるということです。サーチをスキップさせず、かつサーチが終わるまで待つため、通常よりも長く時間がかかる可能性が大きいです。ただ、実施中もサーチ影響はないため、そこまで気にすることはないと思います。

参考として、IDXCとSHCのそれぞれにおいてどこにどのような設定を入れればよいか具体的に記載します。

■IDXCのリスタート・アップグレード

[clustering]
rolling_restart = searchable //本設定でローリングリスタート／アップグレード中でもサーチ可能となる。

[default]
defer_scheduled_searchable_idxc = 0　//本設定でローリングリスタート／アップグレードでも連続スケジュールサーチが可能となる。

[clustering]
decommission_search_jobs_wait_secs = N　//本設定によって、サーチジョブ実行中に当該ピアが停止される場合に、そのサーチジョブが終了するまで最長N秒間ピアの停止が保留されるようになる。なおN秒を超えてもサーチジョブが終了しなかった場合には、サーチ結果が不完全なものとなる可能性がある。

■SHCのリスタート・アップグレード

[shclustering]
rolling_restart = searchable　//本設定でローリングリスタート／アップグレード中でもサーチ可能となる。
decommission_search_jobs_wait_secs = N　//本設定によって、サーチジョブ実行中に当該メンバが停止される場合に、そのサーチジョブが終了するまで最長N秒間メンバの停止が保留されるようになる。なおN秒を超えてもサーチジョブが終了しなかった場合には、サーチ結果が不完全なものとなる可能性がある。