「オブザーバビリティ・エンジニアリング」の訳者が語るオブザーバビリティに取り組む重要性とSplunk活用のポイント
ITシステムの複雑化が進む中、単なる監視に留まらず「システムの本質的な状態」を見える化する「オブザーバビリティ（Observability）」のアプローチが注目されています。システムが「どれだけ自らを説明できるか」という観点から評価され、システム全体の挙動や依存関係を包括的に把握し、インシデント発生時には根本原因の究明や再発防止などに寄与することが期待される手法です。
今回は、オブザーバビリティ製品やソリューションをはじめとする、データ分析のプラットフォームを提供しているSplunk Services Japan合同会社（以下、Splunk社）にお話を伺いました。オブザーバビリティが具体的にどのようなシーンで役立ち、実際の運用現場ではどのように実践されているのか。Qiita開発マネージャー・清野によるインタビューを通じて、ざっくばらんにお話しいただきました。
目次
プロフィール
シニアソリューションアーキテクト オブザーバビリティ
プロダクト開発部 Qiita開発G マネージャー
入社後はQiita、QiitaJobsのプロダクト開発や機能改善などを担当。2020年1月から「Qiita」のプロダクトマネジメントとメンバーのマネジメントを行う。
オブザーバビリティ向上へのファーストステップとは
清野：Splunkのサービスについて伺う前に、そもそもオブザーバビリティとはどのような概念なのかについて、改めて教えてください。
大谷：人によって様々な定義があるとは思いますが、例えば「オブザーバビリティ・エンジニアリング」という本では、オブザーバビリティは「システムでどのようなことが起こっても、何が起こったか説明できる尺度」と説明しています。
ですから、例えばシステムが止まって復旧までにかかった時間が、3時間の場合と10分の場合があるとすると、10分で復旧できたほうがオブザーバビリティがより高いと言えます。オブザーバビリティはゼロということも、逆に完璧ということもなく、「どうすれば高められるのか」という改善の余地がある概念になります。
清野：「こうすればオブザーバビリティが完了する」という話ではなく、あくまでひとつの指標という考え方なんですね。
大谷：そうですね。基本的には、各種ログやトレース、メトリクスなど、システムから出てくる様々な情報を取り出して、かつ分析できる状態にしておくことが、オブザーバビリティ向上へのファーストステップになります。
清野：モニタリングとはまた違う概念なのでしょうか？
大谷：モニタリングでは「異常な事象が起こってから、いかに早く検知して人間に知らせるか」が一番重要なポイントでした。従って、起こった事象に対して「どう調査するか」を考え判断する大半は人間次第です。
一方でオブザーバビリティは、様々な環境がある場合でも、検知から調査までを一元化して実施しやすくする考え方になります。例えばCPUが上がっているという検知だけでなく、なぜ上がっているかの分析と、それ以降の施策まで、調べられるデータを含めて用意されている状態になっています。
清野：どこまでがオブザーバビリティの範囲になる、などはあるのでしょうか？
大谷：難しい質問ですね（笑）。オブザーバビリティの範囲に入らないかもしれないものを挙げると、CI/CDの仕組みやデプロイの自動化そのものが挙げられそうですね。逆に、サーバーのログやトリガーとなるメトリクスはもちろん、プロダクトの画面で会員登録がうまくいっている／いっていないとか、Qiitaであれば記事の閲覧が上手くできているか否かなどの観点も、オブザーバビリティを高めるための観点に含まれると言えるでしょう。
チームが障害対応に自信を持つことで、よりリスクをとったデプロイができるようになる
清野：具体的に、どのようなケースでオブザーバビリティソリューションの導入が検討されるのですか？
大谷：先ほどもお伝えした通り、オブザーバビリティにはゼロという概念がなく、どの会社でも、オブザーバビリティに向けた取り組みを何かしらされています。ダッシュボードを整備したり、様々なメトリクスを設計したり。従来に比べればずっと良くなっていますが、そこから先、さらに良くしていくにはどうしたら良いのかという観点で、オブザーバビリティソリューションの導入を検討されている印象です。
具体的なケースを紹介します。例えばプロダクトのレスポンスタイムが遅れていて、人力で調べた結果よく分からなかったが、事象が落ち着いた場合です。この段階で一旦OKとしているケースがしばしば見受けられますが、そのまま放置していると、まあまあの頻度で再発することがあります。再発するたびに調査工数がかかりますし、社内外からの再発防止の圧力も高まっていきますよね。
清野：耳の痛い話です。
大谷：一方で、複数のメトリクスやアラートを追加することで、原因を突き止められる場合もあります。しかしアラートが増えると関係ない状況でもアラートが鳴り、メトリクスやアラートの管理が複雑化する恐れがあります。こうした課題から、オブザーバビリティソリューションを導入する企業が増えているのが現状です。
清野：オブザーバビリティを高めるメリットとして、どのようなことが挙げられますか？
大谷：ここまでお伝えしてきた通り、まずは調査能力が身について、早くコンパクトに障害対応できるようになります。例えば今までチームの中でも経験豊かなエンジニアに頼りっきりになっていたところが、オブザーバビリティを高めれば属人的でなくなると期待できます。
またチームが障害対応に自信を持つようになると、よりリスクをとったデプロイができるようにもなります。障害の影響が限定的になるからこそ、完璧なテストを実施して石橋を叩きながらデプロイをするのではなく、よりスピーディーに機能追加できるようになります。この点も、オブザーバビリティを高める副次的な効果だと考えています。
もちろん、今お話しした内容は、オブザーバビリティを高めるだけで実現するものではありません。何か障害が発生したときに「戻しやすいか」を考えると、システムのアーキテクチャによって変わりますし、開発組織の体制にも左右されるでしょう。あくまで一つの指標であり、問題を解消できる可能性のある一つの選択肢としてご理解いただければと思います。
清野：先ほどのオブザーバビリティの範囲についての話も踏まえると、開発だけに閉じた話ではなく「いかにビジネスインパクトを大きくするか」という話だとよく分かりました。
OpenTelemetryにチャレンジしたい方は、ぜひSplunkを試してみてほしい
清野：ここまでオブザーバビリティについてお話しいただきましたが、読者の皆さまに対して「こういうことから始めてみてはどうか」というアドバイスがあれば、ぜひいただきたいです。
大谷：皆さまの状況によって変わるかなと思います。例えばインフラなど、基本的なサービスのメトリクスだけをとっている場合は、ぜひAPMのソリューションを試していただきたいです。APMを入れると、例えばアプリケーションがどれくらいのレイテンシで、どれくらいのスループットがあり、どれくらいのエラーを吐いているのかなど、メトリクスはもちろん「どう動いているか」の情報も含めて把握できますので、今までよりもシステムに対する把握能力が格段に上がります。
そうすると新機能の追加や障害対応の能力も高まります。すでにAPMを使っているのであれば、Splunkであるか否かに関わらず、ぜひご活用いただきたいとも考えています。活用する上で様々な課題が出てくるとは思うので、必要に応じてSplunkにもご相談いただければと考えています。
清野：ありがとうございます。「Splunk」の特徴や強みについても教えてください。
大谷：弊社には「Splunk Observability」というソリューションがありまして、インフラやアプリのモニタリングをはじめ、ネイティブアプリ上のリアルユーザーモニタリングなどの仕組みを使って、稼働状況に関するデータを集めて可視化や分析ができるようになっています。加えて、APMからのトレースデータへリッチにデータを入れることで、様々なビジネスデータと紐付けることも前提にしています。
例えばQiitaであれば、ユーザーがログインしているのか否かとか、ログインしているとしたらどういうユーザー属性なのか、どのような行動をしようとしているのかなど。基本的にはイベントデータと考えていただければ問題ないです。もちろん、社内管理のシステムだけでなく、他ベンダーさんによるシステムのログなども収集・分析の対象にできます。このように様々な情報を集約し、比較的リアルタイムに分析できるスピード感に、価値を感じていただいている印象です。
Splunk Observability Cloudで収集したメトリクスやトレースと、Splunkのサーチやレポートで収集したログデータを組み合わせて可視化することで、トラブルシューティングを迅速に行えるようになっている
（https://www.splunk.com/ja_jp/products/observability.html ）
清野：ユーザーには、どのような観点でSplunkを使ってほしいですか？
大谷：例えばですが、最近話題のOpenTelemetryにチャレンジしたい方は、ぜひSplunkを試してみていただきたいですね。公式でサポートしているので、親和性高く導入いただけるかと思います。「UIが分かりやすい」と評価いただくことも多いので、管理画面などが分かりにくく運用に支障がある、というケースでも検討いただくと良さそうです。
導入して終わりではなく、活用に向けた伴走までご一緒する
清野：SplunkのAPMソリューションを導入するとなった場合、具体的にどう進めていくのでしょうか？
大谷：しばしば私も導入の提案をさせていただくのですが、最初に「APMに何を期待しているか？」と質問します。ここで期待値を合わせておかないと、後々齟齬が発生する可能性があるので、非常に重要なポイントです。
そこで問題がなさそうであれば、次はアーキテクチャについて質問します。そしてOpenTelemetryなど、エージェントの構成をご提案します。それによって導入の作業手順が大体分かるようになります。
そして実際に作業をしていただいてデータが集まったら、どう読めるのかのレクチャーをさせていただきます。APMソリューションって、ちょっとだけ見慣れないと、どこに何が格納されていて、どういう意味のデータなのかが分かりにくいです。ですから導入して終わりではなく、活用に向けた伴走までご一緒するのがポイントだと考え、ご支援しています。
清野：サポート体制も充実しているのですね。
大谷：そうですね。カスタマーサクセスにも力を入れていて、画面の解説とかUIイントロダクション、データの読み方など活用支援は、積極的にやらせていただいています。これから使い始める人のためのワークショップをはじめ、Splunk活用に向けた様々なイベントをこちらのイベントページでご案内しているので、ぜひ併せてご覧いただきたいです。
もちろん私たちからの発信以外にも、例えば自社の中で勉強会をしたり毎週の定例会議内でSplunk APMの話を入れるなど、より多くのメンバーが目にする形で学べる機会を設けるのもおすすめです。そういう会社さまほど、よりSplunkを活用いただけている印象です。
清野：具体的なユースケースも教えていただきたいです。
大谷：ありがたいことに多くの事例があって悩みますが、例えばSansanさまではインボイス管理サービス「Bill One」で導入いただいており、本番環境のレスポンス低下などが発生した際の属人性排除や、対応スピードの向上に寄与できています。具体的には、OpenTelemetryに完全準拠したSplunk Application Performance Monitoringを採用いただき、サービス全体の可視性を高めて、オブザーバビリティの高度化を実現できています。
またKDDIさまでは、スマホ決済サービス「au PAY」の残高管理システムでのオブザーバビリティ向上に向けてSplunk Enterpriseを活用いただいています。こちらの事例の場合は、定常業務の効率化に貢献して、リードタイムの9割以上削減に成功しています。
このようなミッションクリティカルな領域の他にも、様々な業種業態でのユースケースがあります。ぜひこちらのお客様事例で、気になるものをご覧いただければと思います。
オブザーバビリティを高めれば、企業のあらゆるシステムの質が上がる
清野：オブザーバビリティソリューションって、リプレイスのタイミングが難しいと思うのですが、使ってもらいたいタイミングなどはありますか？
大谷：今ある仮想マシン（VM）をコンテナ化したいタイミングや、モノリシックなシステムをマイクロサービス化したいタイミングなどは、良いきっかけかなと考えています。あとポイントとしては「小さく始める」です。小さく始めて、知見が溜まっていったら少しずつ社内の対応領域を広げていく。いきなり全社導入ではなく、まずはそのようなアプローチが、リスクヘッジの観点からも望ましいと考えています。
清野：今回お話を伺って、今までぼんやりと「大事そうだな」くらいに感じていたオブザーバビリティの解像度がグッと上がりました。 Qiitaとしても非常に勉強になりました！ 最後に、読者の皆さまへのメッセージをお願いします。
大谷：オブザーバビリティに関して何かしら具体的な課題を持たれているようでしたら、ぜひSplunkにご相談いただければと思います。まだまだ具体的な課題に落とし込めてはいないものの「まずは話を聞きたい！」という方ももちろん大歓迎です。
オブザーバビリティはシステムに閉じた話ではなく、使う人も含めた包括的なアプローチが必要になりますので、その観点を前提に、どう始めるかのアプローチからステップ・バイ・ステップでお話しできたらと思います。我々も、この領域のリーディングカンパニーとしてオブザーバビリティを高めることで、あらゆる企業の様々なシステムの質を上げられる、と信じて取り組んでいます。ぜひ気になることがあれば、まずはお気軽にご相談ください。
編集後記
執筆担当である私自身、モニタリングとオブザーバビリティの違いを理解しきれていなかったので、今回のお話は非常に学びになりました。大谷さんからご紹介いただいた事例ページでは様々なユースケースが掲載されています。今後デジタルレジリエンスの向上がますますテーマになると想定されるので、まずはスモールスタートでの導入を検討してみてはいかがでしょうか？
取材／文：長岡 武司
撮影：平舘 平