開発者にとってのオブザーバビリティとは？従来のログデバッグとオブザーバビリティデバッグの違いを解説

近年、注目を集めている「オブザーバビリティ（Observability）」。商用環境や稼働環境での調査を旧来のログでデバッグすることには限界があります。オブザーバビリティの真価は、ログを追跡する従来の方法よりも、はるかに容易かつスピーディーに問題を特定でき、開発中だけではなくプロダクション環境も含めたデバッグが実現できるという点にあります。

この記事では、運用者だけでなく開発者にとっても大きな利益となるオブザーバビリティの概念や従来のデバッグとの違い、オブザーバビリティのポイントについて解説します。

オブザーバビリティとは、予期せぬトラブルを防ぎ、スピーディーなデバッグができる仕組み

オブザーバビリティ（Observability）は、オブザーブ（Observe）：「観測する」と、アビリティ（Ability）：「能力」を組み合わせた複合語で、日本語では「可観測性」あるいは「観測する能力」などと訳されます。複雑なシステムやアプリケーションの動きを監視し、把握し続けることを指し、何らかの異常が起こった際、どこで何が起きたのか、なぜ起きたのかを把握することが可能です。異常が発生した場合に、単にアラートを出すだけでなく、エラーに至った道筋をたどり、どこにその原因があったのかを探り出せます。それにより、予期せぬトラブルに対しても有効に機能するため、問題部分のデバッグをスピーディーに行うことができるのです。

開発者を取り巻く環境の変化による課題

近年、開発者にとってもオブザーバビリティの必要性が注目されています。その背景には、開発者が置かれている環境の変化と、それによる課題があります。詳しく見てみましょう。

システムの複雑性が増大

デジタルビジネスが急激に進化するにつれ、テクノロジーも進化しています。従来のモノリシックな環境から、独立して機能する個々のサービスを組み合わせてアプリケーションを構築するマイクロサービスを取り入れる企業が増えてきました。

こうした環境の変化により、開発や構築期間は早くなり、開発効率が上がったのはメリットといえるでしょう。その一方で、アーキテクチャがより複雑になったため、一度障害が起こると原因特定が難しく、復旧に時間がかかり、結果的にビジネス機会の損失を引き起こすこともあります。開発者は障害時のトラブル対応に、多くの時間を費やしているのが課題となっているのです。

開発者のカバー範囲の拡大

開発者の本来の業務は、新しい機能をできるだけ早くデプロイし、世に送り出すことです。しかし、多くの開発者の業務範囲は、拡大傾向となっています。

かつては新しい機能を早くリリースしたい開発者と、システムを安定化させたい運用者の対立もよく見られましたが、今は、ソフトウェアライフサイクルを早く回すことでお客様に価値を早く届けることを共通ミッションとして、開発者と運用者が連携する「DevOps」のようなモダンな開発手法を採用している企業も多くあります。この変化によって、開発者がコンテナ開発をしてデリバリーまで行うといったような、開発者の業務範囲が拡大しているのが現状です。

また、営業チーム、インフラチーム、運用チームなど、多くのステークホルダーからさまざまな要望があり、ソフトウェアライフサイクルを早く回せないといった事態が起こることも少なくありません。

DevOpsについては、下記の記事をご覧ください。
DevOpsを効果的に実践するポイントと陥りやすい課題への解決策

開発者におけるオブザーバビリティの必要性

このような開発者の環境変化に伴う課題を解決するためには、どうしたらいいのでしょうか。

IDEデバッグやログデバッグ、プロファイラ、テスト駆動開発（TDD）といった手法を用いて、課題を対応しようとすることは広く普及しています。しかしながら、モダンな開発手法や組織、アーキテクチャ下においては、これらでは根本的な解決に至らないことも増えてきました。お客様からクレームが来ることで、原因究明のために、また調査、デバッグを繰り返し…といった場面は減らさねばなりません。

そこで、デバッグ高度化の視点で活用したいのがオブザーバビリティです。

アジャイル・アジリティが求められ、開発者に対する期待は開発環境のみならず、本番環境における迅速なトラブルシューティングへと広がりを見せています。これまで、オブザーバビリティは監視、モダン監視の延長線で語られることが多く、運用者向けのテクノロジーと思われがちでした。しかし、開発者を取り巻く環境が大きく変わってきた昨今では、開発者こそがオブザーバビリティのある環境を活用すべき時代になったのです。

自身が担当するシステムを、異常を検知してその原因を容易に特定できデバッグまで行える特性を持ったシステム　ー　つまり、オブザーバビリティのあるシステムに進化させておけば、開発生産性を阻害する要因を低減することができます。具体的にはアプリケーションやシステムの性能を管理・監視するAPM（アプリケーションパフォーマンス管理）を中核に、インフラからモバイル・ブラウザまでをフルスタックで一気通貫にカバーするツールを導入することで、開発者が抱える課題を解決でき、本来の目的である機能のリリースを迅速に行うことを可能にします。

オブザーバビリティのデバッグと従来のデバッグとの違い

オブザーバビリティを備えたシステムは、そうでないシステムと比較すると、デバッグ作業に決定的な違いが生まれます。どのような点が異なるのか、新旧のデバッグの特徴を比べてみましょう。

従来のデバッグの特徴

従来のデバッグの方法では、統合開発環境であるIDE上でデバッグしたり、あるいはコンソールに出力されるログそのものを分析して、原因を特定します。想定どおりであれば早期に解決できますが、原因が見つからない場合はより詳細なチェックが必要になり、本番環境でのデバッグや障害調査の状況によってはデバッグコードを追加して、ソフトウェアの動きを確認します。

こうした従来のデバッグ作業は、開発フェーズでは非常に使いやすく現在でももちろん有効ですが、商用環境や本番環境ではトラブルが起こるたびに面倒なプロセスを繰り返すことになり、対応が後手に回りがちです。現場の開発者は、直接原因特定ができないエラーログとの終わりの見えない不毛な戦いに引きずり込まれることも少なくありません。

オブザーバビリティのデバッグの特徴

オブザーバビリティでは、稼働するシステムの中で、重要なデータ（特に、デバッグに必要なデータ）を常に取得し、その動きを追跡しています。システム全体が常に分析可能な状態にあるため、想定外のトラブルが発生しても、そのときどこで何が起こったのかを把握し、異常の要因を素早く特定できます。バグを見つけるためにコードを追加する必要もありません。

オブザーバビリティにおけるデバッグ作業は、従来のような問題が発生してから対応するリアクティブな手法ではなく、いつ異常が発生しても顧客からのクレームや問い合わせが発生するより先取りして対応できるプロアクティブな手法であり、被害が拡大する前に素早く対処することが可能です。

オブザーバビリティのメリット

オブザーバビリティを導入することで、システムの開発・運用に多くのメリットが生まれます。そのうちの主なメリットについてご紹介しましょう。

DevEx（開発者体験）が向上する

従来の障害対応の手法では、障害が発生するたびに、その対処のために開発者が時間と手間を割いてきました。しかし、開発者の本来の仕事は、優れた機能を生み出し、ユーザーにメリットのあるソフトウェアを作り出すことです。インシデントの対応はもちろん重要ではありますが、生産的な仕事ではありません。

オブザーバビリティが導入されれば、開発者が障害対応に要する手間と時間は、大幅に削減されます。その結果、開発者はより価値の高い仕事に時間と労力を注ぐことができ、生産性も高まるでしょう。

こうした「DevEx（Developer Experience：開発者体験）」の向上で生まれる時間的・精神的余裕は、個人のワーク・ライフ・バランスの向上やイノベーションの呼び水になることも期待できます。

サービスの信頼性が向上する

これはあらゆる業界に共通することですが、何らかのサービスを提供する際に重要なのは、信頼性です。デジタルサービスであれば、いつでも利用でき、安定して作動し、ユーザーが目的を果たせるようでなくてはなりません。たとえ、洗練された新たな機能を開発したとしても、動作が不安定ではユーザーに不安を与え、離脱を招きかねません。

あなたのデジタルサービスを形作るシステムにオブザーバビリティがあれば、システム全体の把握が可能になります。まず全体の状況が常に把握でき、さらに異常を検知することで、迅速な原因特定・改善・復旧を実現することが可能です。ユーザーにメリットのある機能性とともに、サービスの信頼性を高めることができるのです。

例えば、外形監視やリアルユーザーモニタリング（RUM）などのクライアントサイドのモニタリングを通して、WEBサイトのパフォーマンスだけでなく、顧客体験としてのサービス信頼性を理解することもできます。このことは開発面でのメリットであると同時に、自社のブランドイメージの向上にもつながるでしょう。

チーム間コラボレーションを促進する

開発（Dev）チームと運用（Ops）チームのあいだには、しばしば対立が生まれがちです。開発側はより洗練された機能をいち早く実装したいと考えますが、運用側はトラブルのリスクをおそれ、安定した状態を保ちたいと考えます。一見するとまったく反対の考えのように見えますが、実はユーザーに対して「洗練された機能で、優れたサービスを安定的に提供する」という「顧客価値を向上したい」ことに違いはありません。つまり、両者が目指すところは同じというわけです。

オブザーバビリティを高めれば、異常の検知から原因特定、さらに解決までの時間が劇的に短縮されます。ソフトウェアのライフサイクルすべてにおいてフィードバックが得られ、サービスレベルを高く維持でき、トラブルに対してチームで対処することで、DevとOpsだけに限らずBiz、Dev、Sec、Opsといった事業全体のチーム間コラボレーションが促進されるでしょう。

ビジネスと収益の成長を助ける

現代では、インターネットで検索を行い、目的の情報や商品にたどり着くと、その先の購買やサービス利用へと進んでいくことが多く、デジタルとビジネスはほぼ一体化しているといえます。

このような環境下で、デジタルサービスに何らかの異常が起こり、サービスの提供に悪影響が出ると、それはビジネス上の損失に直結します。「画面表示が◯秒遅れると、売上が◯％落ちる」という話は、多くの人が何度も耳にしたことでしょう。

これは裏を返せば、洗練された高機能高品質なサービスを安定的に提供できれば、ビジネス上の利益につながるということです。オブザーバビリティによって開発・運用チームが効果的に連携し、成長していけば、ビジネスの成長を助けることにもなるのです。

オペレーショナルエクセレンスが向上する

オブザーバビリティを導入すると、システム上で発生した複数の問題に対して、原因の特定とともに優先順位をつけて対処していくことができます。つまり、障害対応の作業そのものが短時間で、しかも効率良く行えるようになり、エンジニア全体の生産性の向上、つまりオペレーショナルエクセレンス（Operational Excellence）の向上につながります。

開発・運用の区別なく、すべてのエンジニアの生産性が高まれば、それはビジネスの生産性向上にもつながります。競合他社が簡単にまねのできないレベルに達したならば、他社に対して大きな優位性を保つことができるでしょう。

オブザーバビリティは、4つのデータを活用するのがポイント

オブザーバビリティでは、システムから収集されるテレメトリデータを活用するのがポイントになります。

一般的に、「メトリクス」「ログ」「トレース」の3つをテレメトリデータ、あるいは単にテレメトリと呼びます。これらはオブザーバビリティを支える3本柱とされますが、ここに「イベントデータ」を加えることで、より迅速で的確な対応が可能になります。それぞれの要素について、詳しく見ていきましょう。

メトリクス：システムの状況を示す数値情報

メトリクスは、システムの内部状況を把握するために測定し、数値化したデータです。よく使われるのはメモリやCPU、ネットワークの使用率などです。

メトリクスは、刻々と変化しながら稼働しているシステムの状態を、測定の瞬間ごとに数値化し、表示します。このデータによって、ハードウェアの状態やアプリケーションの動きを可視化して、異常が発生した際に何が起きたのかを明らかにします。

ログ：ログ分析によって、根本的な原因に到達する

ログは、アプリケーションやOS、ミドルウェアなどから出力されるテキスト情報です。何らかの原因で発生した異常の結果、何が起こったのかを記録したものです。このログを分析することが、根本的な原因を探り当てる糸口となります。

ただし、ログはあくまでも「結果」であって、プロセスではありません。その結果に行き着くルートが複数考えられるとなると、その複数の可能性を検証していく必要があります。これは、メトリクスも同様ですが、ただ収集しただけのデータであれば、旧来の手法の延長になってしまいます。どのような経緯を経て結果に至ったのか、そこを明確にできなければ、真のオブザーバビリティとはいえません。

単にデータを集めるだけではなく、デバッグできるように有機的にデータを収集することが真のオブザーバビリティであることを覚えておきましょう。

トレース：障害対応の最初のアクション

トレースは、異常を検知した際にシステムの動きをたどる作業のために、問題が起こった処理のプロセスを可視化したデータです。複雑なシステム環境であっても、オブザーバビリティでは、システムの構成要素をすべて関連付けているため、トレースによって「どこで問題が起こったのか」を容易に突き止め、対処することができます。

イベントデータ：「いつ」「何が」起きたのか？ オブザーバビリティを実現する4本目の柱

メトリクス、ログ、トレースに追加しておきたい4本目の柱が、イベントデータです。ここでいうイベントデータとは、New Relic特有の概念ですが、「いつ」「何が」起きたのかという記録データを指します。

イベントデータはトレースやログとは別に、属性データとして「いつ」「何が」起きたかを分析可能な生データの形で記録したものです。イベントデータを活用することで、どのような状態・事象が一連の異常の引き金になったのか、を高速かつ容易に分析可能です。特に障害の根本的な原因の特定に大きな効果が見込めます。

システムの動きを数値化したメトリクスや、各レイヤーから出力されたログは、それぞれ加工済みデータです。これらのデータからは「どのような状態のとき、どのような結果が生まれたのか」といった障害のきっかけを特定するのは困難を極めます。一連のプロセスのどこに問題があるのかを生データで属性データを持つイベントデータを利用して突き止める。これが「いつでもデバッグ可能」という真のオブザーバビリティです。

オブザーバビリティを実践するNew Relic

自社のシステムに高度なオブザーバビリティを導入するなら、New Relicがおすすめです。New Relicは、オブザーバビリティに必要な多くの機能をひとつのプラットフォームに凝縮。すべてのエンジニアが高いモチベーションを維持しながら、ハイパフォーマンスを発揮できる環境を提供します。

New Relicには、開発者の負荷を軽減し、本来の業務に注力するための機能が多くあります。その一部をご紹介しましょう。

CodeStream

CodeStreamは、IDEの拡張機能で、IDE内でコードを起点としたコミュニケーション、コラボレーションが行える機能です。Code Level Metricsという機能では、コード上のメソッド単位で実際の該当メソッドのパフォーマンスを定量的に確認ができます。これによって、非機能要件を意識したプログラミングまでをサポートします。

Change Tracking（変更管理）

Change Tracking（変更管理）を使えば、アプリケーションデブロイメントや構成変更後にどのようなシステムの変化があったのかを容易に追うことができます。

SLM & Error Inbox

SLM ＆ Errors Inbox は、サービスレベルの低下を把握できるだけでなく、原因分析まで容易にでき、エラーのユーザー影響や詳細な分析が可能です。

CodeStream & Errors Inbox

CodeStream & Errors Inboxを利用することで、New RelicのErrors InboxからIDEへジャンプし、エラーが発生した該当のリビジョンのソースコードをリポジトリから展開して修正が可能になります。

CodeStream & New Relic AI

CodeStream & New Relic AIの機能を使えば、生成AIを利用したNew Relic AIがIDE上でのエラーについて修正コード案まで提示してくれます。

これらの機能を活用することで、エラーのデバッグを効率的に行うだけでなく、非機能要件におけるデバッグもIDE上を含めて効率的に行うことができ、開発者は開発に集中できるようになるのです。

開発者にとっても有益なオブザーバビリティの実現を目指す際は、ぜひNew Relicの導入をご検討ください。