システムの進化と統合が激しく進む現代では、うまく動かないときに利用者から問い合わせが来たりアラートが上がったりしても、現象の判断や対応の方針を立てるのが難しくなりがちです。状況を把握し、どのような現象が起きているかを的確に判断できるアプローチのオブザーバビリティが話題になっていますが、定義にややあいまいな部分があることは否めません。
オブザーバビリティとは何か、特定の誰かによる定義ではなく、さまざまなレポートから実体を絞り込むような理解をするアプローチも有効ではないでしょうか。
オブザーバビリティの有力製品「Splunk」を扱う、シニアソリューションアーキテクトによる『Developer eXperience Day 2024』（主催：日本CTO協会）での講演に、カギがありました。Splunk Services Japan合同会社の大谷和紀氏が登壇した、「オブザーバビリティに関するグローバルレポートを読み解く」をレポートします。
スピーカー紹介
大谷和紀 Splunk Services Japan合同会社 シニアソリューションアーキテクト、オブザーバビリティ
Splunk Observabilityの導入支援を行う。CARTA HOLDINGSの広告配信サービス子会社CTOなどを経験しつつ、アプリケーション開発、DevOpsの推進、開発組織の改善などを担当。「オブザーバビリティ・エンジニアリング」共訳。趣味はバックカントリースキー。
ーーー
大谷と申します。Splunkではオブザーバビリティ製品専門の導入支援をしています。「オブザーバビリティエンジニアリング」という本が2023年1月に出版されましたが、共訳で関わらせていただきました。今日は本書からも少し紹介いたします。
目次
オブザーバビリティとは何か
まず、オブザーバビリティとは何か、認識を合わせておきましょう。
サービスを運営・運用している中で、ユーザーさんから画面が動かない、遅いなどのクレームがあったとします。しかし、アラートが鳴っていない、ダッシュボードを見ても異常が見つからないこともあります。現代のサービスは複雑で、インターネット越しに使うサービスであれば、インターネットが不安定になるだけでも使えません。バックエンドは大丈夫だとしてもです。
どこで何が起こっているかを把握して、それに対応する力が必要になります。対応できないと、一般ユーザー向けのサービスでは競合サービスに逃げられて売り上げが落ちます。社内システムであれば、業務効率が悪くなります。頻発すると、IT部門や皆さんのチームに対する信頼性がなくなります。続けて、社内政治力が落ちます。新しいことができなくなりますし、予算のコントロール権も失います。皆さんが思った通りの改革ができなくなり、サービスレベル・信頼性を維持する投資もできなくなります。
こうならないよう、システムの信頼性をある程度担保してコントロールすることを考えたのが、オブザーバビリティというコンセプトです。
あらためて「オブザーバビリティとは何か」ですが、2023年10月のSplunkの公式ブログにはこう書いてあります。
「システムの出力を調べることによって、システムの内部状態を測定する能力」
ここでいうシステムの出力は、たとえばログやメトリクスです。トレースやAPMの情報もシステムの出力の1つです。それらを集めて分析することで、障害のときにその原因を特定したり、システムのパフォーマンスがよくないときにそれを向上したり、インフラコストを下げたりすることを検討します。
書籍「オブザーバビリティエンジニアリング」では
「私たちが考えるソフトウェアシステムの『オブザーバビリティ』とは、システムがどんな状態になったとしても、それがどんなに斬新で奇妙なものであっても、どれだけ理解し説明できるかを示す尺度です」
とあります。「状態」には、障害は当然含まれます。場合によっては普通に動いているのも、普通に動いているように見えるけど、文句を言ってきている人がいるのも「状態」です。初めてみるエラーや現象でも、その状態をどれだけ理解して説明できるか、状況を把握しないと必要なアクションが取れません。
「尺度」がちょっとおもしろいポイントです。メトリクスやログを取っていない方はいないですよね。ということは、ある程度、尺度0で運用している人はたぶんいません。尺度に100％の概念があるとしたら、何かが起こってもすぐに状況を把握して必要なアクションも取れる状態です。残念ながら、世の中のどのソリューションでも、さすがに無理だと思います。なので、今の、例えば30や40の尺度を50、60に上げていくためにはどうするか、検討していくものと考えます。
オブザーバビリティとは何か、さまざまな人が語っていますが、このコンセプトは、なんとなくふんわりしています。ですから、ふんわりとこの辺の話だと理解していただくとよいと思います。「Practical OpenTelemetry」という本の中では、このような図で説明しています。
モニタリングは、障害発生を検知してから知らせるまでが最も重要なポイントです。そのためにメトリクスやログを集めて、そこからアラートを上げます。上がったアラートに対して、エンジニアが対応し、解決するのが一連の動きです。
一方、オブザーバビリティはどうでしょうか。これに加えて、このTime to Knowの部分ですね、根本原因の発見をどれだけサポートできるかが主な関心ごとです。エラーが起こって、とりあえず一次対応してアラートや障害状態は収まった。けれど、それで終わりではありません。次に起こらないようにするための調査に時間がかかると思います。ログを集めたり、状況を再現する実験をしたりします。そうした調査をして根本原因を知るためにはどういうデータをあらかじめ集めておくとよいか。それがオブザーバビリティの関心領域です。
それでは、それぞれのレポートを確認していきましょう。
ダウンタイムの隠れたコスト
最初に、ダウンタイムの隠れたコストについてお話しします。オブザーバビリティ・IT運用・サービス運用に関して、ダウンタイムはとても重要な関心部分です。
調査対象は「Forbes Global 2000」に入っている企業です。フォーブス誌が毎年発表する世界の公開会社上位2000社で、日本からも約200社が対象になっています。
ダウンタイムの直接的なコストは利益の9％
レポートの1番のポイントはここです。この調査によると、ダウンタイムによって利益の9％を失っています。収益の損失額としては4900万ドルです。収益を失った他にも罰金・SLA違反金・和解訴訟費用など怖い文字が並んでいます。利益の9％を食いつぶすインパクトが起こっており、しかもその回復にはおよそ75日かかるという調査結果が出ています。
このレポートのおもしろいところは、他に隠れたコストがどれだけあるかを調べているところです。
障害が起こってダウンタイムが広がるとどうなるかというと、生産性が低下します。障害対応の後の原因調査は、場合によっては1週間から3週間くらいかかるものです。新機能のリリースが遅れることを、イノベーションの停滞という言い方をしています。製品リリースが遅れて、競争力が低下して、市場での価値を失います。具体的な合計額は、計算が難しすぎるので、最終的に数千万ドルに達する可能性があると幅を持たせて書かれています。
株価低下に影響
株価がなんと1％から9％、平均2.5％低下するそうです。さらに、回復には80日くらいかかります。皆さんが働く際、障害が頻発していたら気持ちよく新しい機能を開発できますか？といえば、絶対にそうではないと思います。心配ごとが増えるし、CTOのような立場の方の場合は、それに対する説明責任が発生したり、直接的に「この人、ダメなんじゃないか」と思われたりする可能性もあります。
さきほど、回復まで何十日という話をしていましたが、それも、自然に回復するわけではありません。マーケティング領域においても、信頼回復のための広告費は増えるし、マーケティングチームのワークロードも発生します。営業チームと連携して、お客様にどういう対応をする必要があるか検討しなければなりません。時間がかかるだけでなく、システム部門の手間だけがかかるわけでもなく、全社的に対応に時間がかかることをこのレポートで示しています。
ダウンタイムのよくある原因
なぜ、ダウンタイムは起こるのでしょうか。
1、2番目が人的ミス、3番目がソフトウェア障害です。セキュリティ方面・サービス開発、運用方面など、いろいろな方面でダウンタイムが起こることがわかります。
生成AIは幅広く活用できますが、一方で生成AIがダウンタイムを増加させるという話もあります。それは、システムの攻撃者側も生成AIを使うからです。攻撃者が、攻撃のためにAIを活用し、その活用レベルを上げていきます。それに応じて私たちも、ダウンタイムを増加させないよう積極的に生成AIを活用するレベルを上げていかなければいけません。
レジリエンスリーダーに学ぶ
レポートの中には、レジリエンスのリーダーに学ぶことについても書かれています。「予期せぬ事態が起きても事業は継続できるという自信を持つことで、夜ぐっすり眠れるようになるということです」とあるので、夜はぐっすり眠りましょう(笑)。
日本で同様の調査がないか調べました。軽くググった感じですと、この2つのレポートが検索できました。
1つ目がIPAの「情報システムの障害状況一覧」で、2019年まであるレポートだそうです。コロナ直前でキャッシュレス支払いが流行しだした時期、あとは消費税の変更があったり、パブリッククラウドの大規模障害が起きた時期です。
2つ目が今年もレポートが出ている「金融機関のシステム障害に関する分析レポート」です。この中でも障害の割合を分析しています。一番の要因がソフトウェア障害、2番目が管理面・人的要因です。ソフトウェア障害はどこでも発生していて、改善の余地があるということです。
GigaOm Radar for Cloud Observability
2番目のレポートです。「GigaOm Radar for Cloud Observability」は、オブザーバビリティ製品の比較レポートです。
GigaOm社は市場調査の会社です。トップ21のクラウドオブザーバビリティソリューションを調査して、機能要件と非機能要件について製品比較をしています。Splunkを含むオブザーバビリティ製品についても、21社分、すべて星をつけて比較している詳細なレポートです。
この中で面白いのが「モニタリングからインテリジェンスへ」です。
ここではモニタリングを「ソフトウェアとハードウェアが動いているか」「ネットワークは動いているか」のYes or Noの状態で紹介していました。また、バックエンドに合わせたエージェントを入れる必要がありました、とレポートされています。OpenTelemetryを使うべきという話が結構載っていました。
次にオブザーバビリティが出ていました。「サービスのパフォーマンスがいいか悪いか」「IT運用やビジネスサービス」というキーワードが含まれています。実際に修正されるまでを関心ごとにしている部分がポイントです。
最後にインテリジェンスです。オブザーバビリティを越えてインテリジェンスまでいこうというのが、このレポートの興味深いところです。今までの話は、システム・サービス・デジタルサービス、もしくはIT運用がターゲットでしたが、ここではITでない領域も含め、仕組みとしてうまく回っているかに関心を持つこと。そして、ビジネスの貢献度合い、障害として大きそうなもの、それを予測して予防することがポイントとして紹介されています。
主な機能と新たな機能の紹介もあります。LLMサポートが主な機能として数えられているのは、ここ1、2年で状況が変わっていて面白いですね。ビジネス基準とは、導入のしやすさや、コストの妥当性などです。これらの項目について、21社の評価が本当に並んでいます。
Splunkの評価について抜き出しました。
・あらゆる規模の組織に対応している
・OpenTelemetryに大きく貢献している
・すぐに使えるインテグレーションを数多く提供している
オブザーバビリティ調査レポート2023
オブザーバビリティ調査レポートの2023はSplunkの調査です。オブザーバビリティについて、定着度・メリット・教訓・ベストプラクティスなどをまとめています。
システムは複雑化しながら、さまざまなツールを導入します。そうなると、それらのツールを全部管理しないといけません。そこで、ツール管理ソリューションを入れたり、ツール自体を統合したくなります。
セキュリティやアプリケーションパフォーマンスなどの監視対象によって、このような統合状況になっていることを紹介しています。システムは、たとえばシンプルなベアメタルやバーチャルマシンの三層構造アーキテクチャから、マイクロサービス・コンテナもしくはサーバレスなどを組み合わせる形に移行します。しかし、移行は一気にできません。新旧のシステムが混在しながらなんとかうまくやっている企業がほとんどです。そして、新しいものを作るときに新しいアーキテクチャを導入するため、世の中のシステムは常に移行状態にあると考えていただくと良いでしょう。常に移行状態にある状況をどう過ごすかが課題です。
AIOpsへの期待はどのくらいあるかという調査もあります。この91％という割合に、期待の大きさが表れています。そして、結果が期待を上回った企業が64％あります。低くはないけど高くはない印象です。1番のメリットは、MTTD（平均検出時間）です。
ダウンタイムのコストに関してはこのレポートにもあります。最初のレポートと調査は違いますが、似たような内容が出ています。
オブザーバビリティのメリットも書かれています。右下を見ていくと、ハイブリッドアーキテクチャの可視化を大きく向上させています。
いろんなアーキテクチャが混在する中でうまくやっていかないといけないので、それをどう統合して、可視化して把握するかがポイントです。
推進のポイントです。最初のステップの1つは、右下ですね。標準化して、オブザーバビリティのパイプラインをつくることが重要と書かれています。パイプラインを標準化する、メトリクス・ログ・トレースを標準化することについて、この文脈では、オープンテレメトリーをまず試してみましょうといった感じになっています。他の分野と積極的にコラボレーションすることも重要です。
オブザーバビリティ製品はSplunkも競合製品も安くありません。さらに、ベンダーにお金を払うだけでなく、導入の手間もかかりますし、活用にも手間がかかります。必要な投資、学習、トライができるかは、自分たちの分野だけではなく、他の人たちと協調しながらやっていく必要があることがいい教訓です。
日本の状況もレポートの最後の方にあります。オブザーバビリティのリーダー組織は、なんと日本は1％です。北米では30～40％弱で、日本は後進的になっていることがわかります。
日本のエンジニアは優秀なのに、いろいろなところで全体的な取り組みが遅れている印象があります。皆さんにとっては、付け入るスキがいっぱいありますということなので、いろいろやっていきましょう。
Splunkによる2024年の予測 – オブザーバビリティ編
最後のレポートを紹介します。「Splunkによる2024年の予測・オブザーバビリティ編」です。
AIとオブザーバビリティは2024年にどうなるかということを2023年末に予測したものです。Splunkのプロダクトマネージャーなどが予測をまとめています。結論は、オブザーバビリティの重要性がいっそう高まるといった内容です。急激な変化は起こらないと予測の1番目にあります。
ツールの統合も必要というトピックは、今までのレポートの流れとだいたい一致しています。AIを活用する前にツールの統合をといった警告は興味深いですね。テレメトリーデータの標準化が重要というレポートもありました。まずは足元の基盤を整えることが大事です。
異常検出はAIによってやり方が変わるかもしれませんが、手動のトラブルシューティングは残ると警告されています。これは重要です。ChatGPTを使ったことがある方はわかると思いますが、上手に質問しないと答えを出してくれません。人と話すように質問をして答えを得るのが重要です。質問ができない人は使いこなすことができない、と警告されているのかもしれません。
次に、CTOとCIOへのアドバイスです。予算関連はコントロールしてくださいと書いてあります。オブザーバビリティのベンダーなので、予算削減しすぎないか気をつけて、と警告しているのは面白いですが、予算のコントロールをちゃんとしていきましょうね。焦りすぎない方がいいと言っています。
最後に、なんと2044年の予測があります。20年後には、自動掃除機が掃除をしやすくなるように家の間取りを決めて、あとは芝刈り機が芝を刈りやすくなるように庭を整えると書かれています。要するに、AIを今までのものに加えて、AIで分析させるわけではなく、足回りをきれいにしないと活用が進まないよと警告されています。
取材後記：大きなビジネスインパクトを防ぐための全社防衛
情報システムだけのログやアラートだけでは、システムの複雑さや利用者の悪体験への対応ができない状況になってきています。全社で取り組む下地になるべき情報の取得がオブザーバビリティの肝といえそうです。
世界でオブザーバビリティがどのように捉えられているのかを把握することで、自社でのありようを確立させる。そんな方向性も示唆しているようなレポートの読み解きでした。
（取材／文：奥野大児）
