Twitter
Facebook
Hatena
超ベテラン運用保守担当者とSplunkエンジニアに聞く!Splunkで何が変わるのか

システム運用保守をしていると「ログ管理が大変」「障害対応に時間がかかる」といった課題に直面します。
そんな中、近年注目されているのが、統合ログ管理プラットフォームSplunk Enterprise(以下、Splunk)。導入すると何が変わるのでしょうか。
今回は、PM(プロジェクトマネージャー)経験の豊富な大石 淳ファシリテートのもと、長年運用を担当しているエキスパート梅田 智康と、Splunk構築で様々な困難を攻略してきたエンジニア松本 哲也が本音で語ります。

Splunkとは?

大石:梅田さんは、あるECサイトの超ベテラン運用保守担当者です。“24時間365日止められない”“1時間止めると数千万の損害”というプレッシャ―の中で運用保守を担っています。
運用の大変さを理解している人なので、そういった話を交えながら、Splunkの有効性、Webサービスの運用者の負担を軽減できる箇所を探っていきたいと思っています。
一方で松本さんはSplunkを使用してシステムを運用保守する業務を担当しています。ツールの有効性を熟知しており、実際にツールを使って業務改善を実践しています。この2名から話を聞くことで新しい価値を創造できそうですね。
松本さん、Splunkの簡単な説明をお願いできますか。

松本:Splunkは企業内の様々な大量データを収集・分析、可視化できる統合ログ管理プラットフォームです。システムの運用管理やセキュリティ対策、ビジネス分析などに役立ちます。
私は2019年から現在まで、SOC(Security Operation Center:企業の情シス(情報システム)部門を監視する専門組織)向けのSplunk構築とその運用保守に携わってきました。
SIEM(Security Information and Event Management:セキュリティ情報イベント管理)基盤としてSplunkが導入し インシデント対応に利用されています。SOCではセキュリティ装置のログを収集し、可視化・分析を行っています。各セキュリティ装置が出力するイベントログは本来それぞれ操作しなければならないのですが、イベントログをSplunkに取り込むことでログを一元的に調査できます。
参考:Splunk公式 https://www.splunk.com/ja_jp/products/splunk-enterprise.html

社内PCにおけるセキュリティインシデントの検出

大石:Splunkの具体的な使用例を教えてください。
例えば会社という組織の中では様々なミッションを持った人が各々作業をしています。
その中で情シス(情報システム)部門の人が、“会社のルールに反して不審なサイトにアクセスしていないか”、“機密情報をダウンロードしていないか”等を監視する必要があると思うのですが、監視にもSplunkは活用できるのでしょうか。

松本:はい。WebフィルタリングサーバーやプロキシーサーバーのWebアクセスログと認証サーバーのログを取り込むことで不正アクセスの検知が可能です。
Webアクセスログから、アクセスサイトURLとアクセスした端末IPアドレスが分かります。また、認証サーバーのログからアクセス時の時間帯に絞り込むことで、端末のIPアドレスを認証したユーザを特定できます。
ダウンロード等の操作は、操作ログを取り込むことで検知できます。
ログをSplunkで一元化することにより、容易に解析できます。

大石:要するに、Splunkは、“ログを監視しているソフトウエア”という理解で合っていますか。

松本:そうですね。Splunkは大量のログを収集してデータ検索できるようにするソフトウエアなので、データを可視化したり、監視してアラートで通知したりということが可能です。
例えば今いるSOCオフィスでは1日250GBのログを取り込んでいますが、その日々のログ1年間分を対象として検索することもできます。

ECサイトの不正アクセス検知

大石:それではWebサービスで何ができるか探っていきましょう。
ECサイトの運用保守では、何か障害が発生して“その原因がバグかもしれないし、ユーザの利用の仕方によるものかもしれない”という状況になった際、梅田さんのようなベテラン運用保守担当者に、ユーザがどのような行動をとっていたかの調査をお願いすることがよくあります。
ログはある程度集約されているものの、ロードバランサ(負荷分散装置)で振り分けられてしまうものもあり、点在している状態の場合、
自作のスクリプト等を駆使して、時刻やキーワード等をうまく見ながらログの分析をしてもらい、ユーザのアクセス経路や動作、それによって何が起きたか、という詳細な調査報告を出してもらうことになります。
このような緊急性の高いインシデント発生の状況下では、梅田さんのような仕事が早いベテラン運用保守担当者に声がかかるのは、サービス維持の観点では仕方ない部分もあるのですが、本来は誰もが同じくらいのスピードで対応できるのが理想だと思っています。
Splunkを使えば誰でもできるようになりますか。

松本: Splunkの得意とする部分なので、容易に実現できるのではないかと思います。
ロードバランシングされた各サーバーの複数ログがあるということでしたが、同じ種類のログであれば、リソースは複数台に点在していても意識することなく、単一の装置ログとして扱えます。
複数の装置ログを検索対象とすれば、時間軸で複数の装置をまたがったイベント経過を追えます。

1つのログでうまくいかない場合でも2つのログを介して突き合わせて分析することが可能です。
例えば、ログ解析する順番をダッシュボードに作っておく形、つまり“1つ目のサーチ(SPL)を行い、その結果を条件に2つ目のサーチ(SPL)につなげる等、段階を踏んで解析をする仕組み”をあらかじめ作成しておけば、ある程度近いものは実現できるはずです。
※SPLとは、Splunk独自のサーチ言語で、Search Processing Languageの意

梅田:行動履歴が載っているログはありますが、それとは別のログと突き合わせた情報解析を現場でやっているので、それができると便利ですね。
仕組みを作っておくことで、一発でできるのであれば、運用担当者はかなり楽になりそうだと思いました。

インシデント対応の課題

大石:梅田さんが運用保守をするうえでこういったところができればいいな、こういうところが苦手だな、と思うことはありますか。

梅田:私がログを追う場合は「このあたりがあやしい」という目星をだいたいつけられるのですが、経験が浅い人には難しいと思います。
ログをざっと見たとき「このメッセージが妙に多いな」というところから見つけていくことが多いです。一字一句同じメッセージであれば集計は楽ですが、「このワードの発生率が妙に多いです」という傾向を自動で検出できると手助けになりそうです。

松本:Splunkは、エラー種類やエラーコードによる件数を集計、グルーピングして表示できるのはもちろん、エラーメッセージの内容が同じ(一部の値のみ異なる)といった文章のイメージでもグルーピングできます。

大石:厳密にリアルタイムというのは難しいと思うのですが、リアルタイムもしくは早いタイミングで検知・集計できるのでしょうか。

松本:スケジュールサーチという仕組みがあり、定期的にサーチしてダッシュボードに表示することはできます。件数等、閾値を設定しておけば、アラートで通知もできます。

大石:“いつもと違う”という傾向が分かりやすくなりますか。

梅田:どういうワードでひっかけるか、がポイントになりそうです。キーワードはあらかじめ決めておく必要がありますか。

松本:ステータスの値である程度の件数が増えたらアラートで通知することや、メッセージを決め打ちできないときは、件数で拾ったり、昨日の値と比較したり、といったこともできます。

梅田:例えば、Javaで例外発生時にトレースをログに出力した場合、クラス名だけをスクリプトにかけて抽出して、対時間あたりの発生数を見て「この処理がおかしい」というような探し方をします。
そういうことがSplunkでもできると良さそうだなと思います。

松本:ログに出力されたクラス名や特定のキーワードを正規表現で指定して、その出現数をスケジュールサーチでカウントする形であれば、結果をダッシュボードで監視したり、閾値を設けてアラートで通知したりがSplunkで実現できます。

大石:サーチを組み合わせれば、あたりをつけて、今あるデータやプログラムを見て判断という流れにできるので、運用負荷は下げられるし、初動は早くできそうですね。
運用負荷が下がると、さらに高度なことに取り組んだり、開発リソースをサービス向上に充てたり、ということもできそうですね。

Splunk導入のメリット

梅田:AWSのCloudWatch Logs Insightsや、Google CloudのCloud Logging等、サービスごとにログ分析の機能はそれぞれ存在していますが、Splunkを使用することで一元的にログを可視化できるのは非常にありがたいです。
 SPLのドキュメントを拝見したところ、既にCloudWatch Logs Insightsを利用している担当者であれば、スムーズに理解できる内容であり、さらにはChatGPTを利用するとCloudWatch Logs Insightsで書かれたクエリをSPLへ変換できるので、導入のハードルはそれほど高くないように感じました。

大石:Webサービスのシステム状態を可視化しようとした場合、DB(データベース)のコンディション等を監視するだけでは不十分で、“今のアクセスの中で異常が起きているのかどうか”等も検知する必要があります。
 例えば、“機能をリリースしたあと、そこで使用したデータが回りまわって他の処理で失敗する”ということは起こりがちです。
 そういった対策の1つとしてSplunkを使用するのは有効であると考えます。

Splunkの導入について検討のお客様はお気軽にご相談ください。ベテラン運用保守担当者がサポートします。

この記事の執筆者

大石 淳Jun Oishi

システムインテグレーション事業本部
ビジネスソリューション事業部
副事業部長 / プリンシパルPM

BizDevOps
梅田 智康Tomoyasu Umeda

システムインテグレーション事業本部
ビジネスソリューション事業部
主任 / エキスパート

AWS アプリ開発
松本 哲也Tetsuya Matsumoto

システムインテグレーション事業本部
ビジネスソリューション事業部
第1技術部 第2技術グループ
担当 / シニアマスター

Splunk 運用保守