Splunkの導入により、本番環境で発生する信頼性の問題を簡単に解決できるように

参考になった

レビュー投稿日の情報になります

Sansan株式会社 / kotakato

テックリード / テックリード / 従業員規模: 1,001〜5,000名 / エンジニア組織: 301名〜500名

最終更新日2024/09/10投稿日2024/05/24

利用プラン	ツールの利用規模	ツールの利用開始時期	事業形態
Splunk APM Enterprise Edition, Splunk Infrastructure Monitoring	11名〜50名	2023年6月	B to B

利用プラン	Splunk APM Enterprise Edition, Splunk Infrastructure Monitoring
ツールの利用規模	11名〜50名
ツールの利用開始時期	2023年6月
事業形態	B to B

アーキテクチャ

アーキテクチャの意図・工夫

トレースと一部のメトリクスだけをSplunkに送信しており、ログはSplunk導入前から変わらずにCloud Loggingに送信しています。これは、Splunkを検証した結果、APMだけでも十分に価値を感じられたためです。

導入の背景・解決したかった問題

導入背景

導入前の状況・課題

Splunk導入以前からGoogle CloudのCloud LoggingでトレースIDに紐づくログを収集しており、必要に応じてログからシステムの挙動を読み取ることはできていました。また、サービス全体のSLOのアラートは設定されていました。

しかし、ログからシステムの挙動を読み取ることは可能であるものの、スキルが必要で、問題の発生時にはシステムに詳しい有識者しか原因箇所を特定できませんでした。加えて、SLOのアラートはシステム全体でしか設定できておらず、問題発生時に原因箇所の特定に時間が掛かっていたのが課題でした。

目指していた状態

本番環境で信頼性の問題が発生し、SLO (Service Level Objective) を達成できない可能性があるときに、誰でも簡単に原因箇所を絞り込み、早期に解決できる状態を目指していました。

また、システム全体だけでなく、マイクロサービス単位でのSLO違反の可能性を検知できるようにしたいと考えていました。

比較検討したサービス

Datadog
Cloud Trace

比較した軸

予算の範囲内で、信頼性の問題が発生した際の解決しやすさが向上すること。

選定理由

サービスマップでシステム全体のエラーやレイテンシの状況を可視化でき、問題発生時に原因を特定するのが容易になること。

導入の成果

信頼性の問題が発生した際に導入前よりも簡単に対応できるようになりました。ただ、現状では信頼性への関心が高めのメンバーに限られており、「誰でも簡単に」と言えるレベルには至っていないため、今後も利用促進を継続します。

また、マイクロサービス単位でのSLO違反の検知に関して、一部の主要マイクロサービスで導入したことにより、マイクロサービス担当チームへの直接のアラート発報が可能になりました。

導入時の苦労・悩み

料金体系が柔軟な反面、複雑で理解に苦労しました。見積もりにもベンダー独自の単位が登場し、どういう条件で料金が変わるのかが分かりにくかったため、営業担当者に何度か確認しました。

導入に向けた社内への説明

上長・チームへの説明

パフォーマンスの懸念が発生していたので、今後の安定的なサービス運営に必要だと説明しました。

社内への展開・導入推進

導入当初に開発チーム向けに操作方法などの説明会を開催し、気軽に試してもらえるよう推進しました。また、パフォーマンス懸念が発生したときに、SplunkでできることをSREチームから共有し、有用性を実感できるように働きかけました。

活用方法

よく使う機能

APM機能
信頼性の問題が発生した際にサービスマップからドリルダウンして見たり、パフォーマンス改善活動をしたりする際に、遅い処理を探すためにTag Spotlight機能を活用しています。
Dashboard機能
SREチームでダッシュボードを毎日見て、信頼性悪化の兆候がないか確認しています。
Detector機能
アラートを設定し、信頼性の問題が発生した際に気づけるようにしています。

ツールの良い点

OpenTelemetryにしっかりと対応しており、ベンダーロックインの懸念なく使い始められる。
サービスマップから信頼性が悪化している箇所をドリルダウンして探索できる。
ホスト数やユーザー数ではなくトレース量に応じた課金体系があり、システムに応じて柔軟に選べる。

ツールの課題点

UIの操作性がやや特殊で、慣れないと使いづらく、プリセールスエンジニアに説明会を開いてもらわないと使い方が分からない機能があった。
ダッシュボードで少し凝ったカスタマイズをするのには、スクリプトを書く必要があり、気軽にカスタマイズできない。
（仕方ないかもしれませんが、）インデックスを張っていないトレース属性での検索が遅く、探索的な検索は難しい。

その他

Google CloudのMonitoringで使っていたインフラのメトリクスをSplunkに載せ替えようとしたものの、現状のSplunkではメトリクスのデルタ指標を表現できず、載せ替えが不可能であることがわかりました。

ツールを検討されている方へ

OpenTelemetryで計装したアプリケーションであれば、ベンダー独自の要素はほとんどなくSplunk APMを使うことができるので、気軽に試してみてください。

Sansan株式会社 / kotakato

テックリード / テックリード / 従業員規模: 1,001〜5,000名 / エンジニア組織: 301名〜500名

新卒で入社したSIerでプロジェクトへの技術支援や先進技術の推進を担当。2018年にSansanに入社し、営業DXサービス「Sansan」の開発に関わった後、クラウド請求書受領サービス「Bill One」のアーキテクトとして、技術選定から立ち上げに関わり、現在に至るまで開発および技術マネジメントに従事しています。