Digital experinces bg
eBook

開発者のためのオブザーバビリティガイド

最新のオブザーバビリティは単なる運用ツールではなく、開発者による利用を前提に構築されています。IDE、パイプライン、AI活用型の開発ワークフローにオブザーバビリティを取り入れることで、サービス、環境、チーム全体をコンテキストとしてコードの動作を可視化できます。

はじめに

ある決済サービスにタイムアウトが発生していますが、これは米国西部地域のユーザーにのみ影響しています。ダッシュボードは正常であり、エラー率は許容範囲内、外形監視は通過しています。しかし、実際のユーザーはセッションを放棄しています。

そこで、フロントエンドからカート、プロモーション、決済サービスに至るフロー全体でリクエストをトレースすることにしました。決済サービスでテールレイテンシの急増が確認できますが、これは最近のノードアップグレード後に再スケジュールされたポッドだけで発生しています。gRPCの再試行処理方法がわずかに変更されたことで、米国西部地域でリクエストの滞留が発生していました。ホットパス上の1つのコードレベルのスナップショットから、回路遮断ロジックをスキップする誤設定されたインターセプターが検出されました。

このため、構成ミスがあったリクエストハンドラーを修正し、自動スケーリングを復元してパフォーマンスを安定させると、テールレイテンシは落ち着きました。再導入も推測に頼る必要もなく、数分で根本原因を特定して解決できました。

これは、すばやく的確で、実際の状況に基づいた理想的な対処法であり、最近はより頻繁に開発者に求められていることでもあります。ソフトウェア開発がシフトレフトする中で、開発者の責任範囲は広がっています。ただ機能を開発していればいいというわけではなく、本番環境でコードがどう動作するかを理解する必要があります。つまり、パフォーマンスと信頼性に対して責任を負うということです。

問題は、ツールや手法の大半が、新しい責任に歩調を合わせられず、複数のサービスから取得したログをたどり、他のチームからの回答を待ちながら、環境間で発生したバグをトレースせざるを得ない状態なのです。時間も手間もかかる上、問題の真相を見失いやすくもなります。

ここで一役買うのが、最新のオブザーバビリティです。これは、単なる運用ツールではなく、開発者による利用を前提に構築されています。IDE、パイプライン、AI活用型の開発ワークフローにオブザーバビリティを取り入れることで、サービス、環境、チーム全体をコンテキストとしてコードの動作を可視化できます。オブザーバビリティはノイズを削減します。推測に頼る必要をなくし、デバッグを加速化し、コラボレーションは必然的にソフトウェア開発ライフサイクルの一部となります。オブザーバビリティは散在するシグナルを統合し、実際の事象に対する単一で共有された理解へと転換します。

オブザーバビリティとは

CNCFはオブザーバビリティの定義として、「システムが実用的なインサイトを生成できる水準を定義するシステムの特性。これにより、ユーザーは、これらの外部出力からシステムの状態を理解し、(是正)措置を講じることができる」と規定しています。これには通常、CPU使用率、メモリ消費量、ディスクI/Oといった低レベルのシステムメトリクスと、APIレイテンシ、エラー率、トランザクションスループットといった高レベルのメトリクスの両方の分析が含まれます。目的は、有意義で実用的な情報を提供することです。

オブザーバビリティは、単なるデータ収集に留まりません。スタックの全体像を把握し、不具合の場所だけでなく、その原因究明も含まれます。開発者にとっては、稼働中のシステムについてアドホックな質問をし、すぐに回答を得て、確信を持ってコードを変更できることを意味します。オブザーバビリティとは、AIとクラウドネイティブ環境向けのアプリケーションパフォーマンス監視であると考えることができます。

オブザーバビリティ:インサイトを取得する最短ルート

オブザーバビリティは開発者に明確性をもたらします。アプリケーションの動作を、環境、チーム、時間を超えて明確に示します。いわば、対症療法と病理診断との違いです。その明確性により、開発者は、集中力を維持し、摩擦を和らげ、長期にわたって運用可能な回復力と保守性を備えたソフトウェアを提供できるようになります。

開発者が直面している壁

現代の開発は高速化が進んでいます。開発者の責任範囲が広がるにつれ、機能の実装、システムの保守、インシデントへの対応が同時進行で求められる場面も増えています。俊敏さが求められるプレッシャーは、信頼性の構築ニーズと両立しない場合があり、その緊張関係が摩擦を引き起こしています。

多くのチームは、担当するシステム全体をエンドツーエンドで可視化できていません。何らかの不具合が発生しても、不具合がどこにあるのかを調べることがそもそも難しいため、不具合の修正方法は暗中模索です。本番環境のバグを低環境で再現しようとして何時間も奮闘する開発者をよく見かけますが、こうした努力が現実の状況を反映することは稀で、解決を遅らせるだけです。コンテキストは環境全体に分散しており、支援を目的としたツールは大抵の場合、サイロ化しています。ログ、メトリクス、トレースはそれぞれ別の場所にあり、どれも連携しておらず、開発者の視点に立って設計されたものは一つもありません。

こうした断片化がすべてを停滞させています。ツールの切り替え、欠損データの追跡、他チームからの回答待ちといったすべての作業が、時間の浪費とストレスの蓄積につながっています。開発者は、問題の解決よりも複雑性への対応に多くの労力を費やしています。

欠けているもの

  • 開発者ワークフローとの統合。ツールは開発者の作業場所にあるべきであり、問題が発生した場合にだけ確認する別のダッシュボードにあるべきではありません。Microsoft/GitHub Developer Experience Labにより、認知負荷の軽減(特にコンテキストの切り替えの最小化)は、開発者の生産性と満足度を向上させることが確認されています。
  • すべての環境の明確な可視化。開発者には、ローカル開発からステージング、本番環境に至る各段階でコードの動作を理解するために役立つ一貫性のある指標が必要です。
  • 複数部門の横断的な連携の強化。チームは、すばやく連携し、問題を共同で解決するために、システムの健全性と動作に関する共通認識を必要としています。

オブザーバビリティによる開発者体験の向上

  1. 問題が発生した時点で検出
    オブザーバビリティにより、アプリケーションの動作を可視化できます。パフォーマンスのボトルネック、エラー率、異常なパターンが発生した時点で監視でき、多くの場合、ユーザーに影響が及ぶ前に対応が可能になります。障害には、後手に回るのではなく、率先的に対応することで、システム健全性を維持できます。
  2. バグのトレースと根本原因分析の自動化
    分散システムで障害が発生すると、根本原因の特定が困難になる場合があります。オブザーバビリティがあれば、サービス、コンテナ、クラウドの境界を越えてリクエストを追跡し、問題が発生した正確な箇所を特定できます。理想的なオブザーバビリティプラットフォームは、AIを活用して異常をハイライトし、想定される原因を提示することで、ログやダッシュボードを調査する時間を削減します。
  3. チーム間で単一のビューを共有
    オブザーバビリティプラットフォームは、全員が理解できる共有ダッシュボードと統合されたテレメトリーを提供します。開発者、SRE、プロダクトチームは、同じデータと言語を使用して、共同でトラブルシューティングを行うことができます。これにより、コミュニケーションの齟齬が減り、インシデント対応が高速化され、目標と優先順位についてチーム間で足並みを揃えやすくなります。
  4. 高品質なソフトウェアをスピーディに構築
    オブザーバビリティにより、実環境におけるコードの動作を理解できます。変更の影響を追跡し、リグレッションを早期に検出し、パフォーマンス、信頼性、セキュリティに関するデータに基づく意思決定が行えます。デリバリーパイプラインにオブザーバビリティを組み込むことで、確信を持ってシステムをリリースし、継続的に向上できます。

オブザーバビリティ実装のベストプラクティス

オブザーバビリティプラットフォームで重視すべき点

すべてのオブザーバビリティプラットフォームが開発者の視点に立って構築されているわけではありません。適切なソリューションは、ワークフローに摩擦を生じさせず、提示されたデータに基づいて対応できるよう支援するものでなければなりません。以下に、主な機能をご紹介します。

状況のライブ監視

現在進行中の状況を把握する必要があります。優れたプラットフォームは、サービスがKubernetesクラスター、サーバーレス関数、あるいは複数のクラウドで実行されているかにどうか関わらず、ハイブリッド環境全体にわたるアプリケーションの健全性をリアルタイムで可視化します。これにより、問題を早期に発見し、その影響を把握できます。

コードレベルでのデバッグ

非中断ブレークポイント、リアルタイムスナップショット、変数、スタックトレース、プロセスメタデータのインコンテキストでの可視化をサポートするツールを検討してください。

シームレスなツール統合

オブザーバビリティツールを導入するために、ワークフローを変更する必要はありません。IDE、CI/CDパイプライン、問題追跡ツールと連携するプラットフォームを検討してください。目標は、問題が発生した場合にだけ確認する別の場所ではなく、普段の作業環境でインサイトを引き出すことです。

ノイズを削減するAI

AIを活用して異常を検出し、イベントを相関分析し、根本原因を提示するプラットフォームがあれば、アラートに悩まされずに重要な課題に集中できます。

AIのオブザーバビリティ

アプリケーションにAIやLLMコンポーネントが含まれる場合、オブザーバビリティプラットフォームは、それらのシステムに対する可視性をサポートする必要があります。つまり、従来のテレメトリーに加え、モデルのパフォーマンス、遅延、トークン使用量、モデルドリフトを追跡することです。

組み込みのセキュリティインサイト

開発者は、脆弱性が本番環境に到達する前に検出・対処できる必要があります。

オープン標準のサポート

OpenTelemetryなどのオープン標準をサポートするプラットフォームを検討してください。これにより、開発者はカスタムコードの計測、サードパーティのライブラリの統合、将来を見据えたオブザーバビリティ戦略の構築を柔軟に行えます。

開発ワークフローにオブザーバビリティを導入する

オブザーバビリティは、問題がインシデントになる前に検出し、導入を検証し、コードが実環境でどのように動作するかを理解するうえで役立ちます。次に、開発者にとって有益で、負担にならないオブザーバビリティワークフローの構築方法をご紹介します。

IDEに直接オブザーバビリティを組み込む

VS CodeやJetBrains IDE向けのDynatrace Live Debuggerなど、最新の統合機能により、エディタを離れずに、稼働中のワークロードを検査し、リクエストをトレースし、本番環境の問題をデバッグできるようになります。

優れたIDE統合により実現可能な機能は、次のとおりです。

  • ライブデバッグのブレークポイント:選択した環境で実行中のインスタンスに適用されるブレークポイントを、コードに設定できます。これらは非中断型であり、ランタイムの動作を中断することはありません。
  • 環境フィルタリング:デバッグする環境とインスタンスを選択できるため、無関係なデータに手間取ることはありません。
  • スナップショット:次のスナップショットを表示できます。
    • ローカル変数
    • スタックトレース
    • プロセスメタデータ
    • トレースデータ
  • 再導入せずにデバッグ:本番環境でコードレベルのデバッグデータに即時にアクセスすることで、問題をすばやく特定し、サービス中断を回避し、再導入を省略でき、コストのかかる欠陥環境の再構築も不要になります。
  • エージェント型AIをIDEに導入:MCPを使用して、オブザーバビリティプラットフォームのAI機能をAIコーディングエージェントに統合し、IDEを離れずに、コードベースに関するパフォーマンスとセキュリティのインサイトを即時に取得できます。

チームに適したローンチパッドを構築する

まず、使用頻度の高いツールやデータにすばやくアクセスできる、シンプルで一元化されたビューの作成から始めましょう。これには、社内開発者ポータル内のダッシュボード、IDEの固定タブ、あるいはオブザーバビリティプラットフォームのカスタムホームページなどがあります。

次へのリンクを含めてください。

  • サービスの健全性とパフォーマンスのメトリクス
  • 最近の導入に関するログとトレース
  • CI/CDの状況
  • ソースコードと問題追跡

重要な理由:必要なツールを探すために、メニューをその都度スクロールしたり、URLを覚えておいたりする必要はありません。パーソナライズされたローンチパッドがあれば、時間を節約し、集中力を維持できます。

サービスカタログでオブザーバビリティを表示する

チームがBackstage、Port、Humanitecなどの社内開発者ポータルを利用している場合は、オブザーバビリティデータがサービスカタログに直接組み込まれていることを確認してください。コンポーネントを参照すると、次の内容が表示されます。

  • 導入場所
  • 健全性
  • 最近の問題や脆弱性の有無

たとえば、Kubernetesベースのサービスの場合、オブザーバビリティ機能は導入の状態、ポッドの健全性、クラスターレベルのメトリクスをカタログビューに直接表示する必要があります。

重要な理由:カタログを使用して所有権やリポジトリのリンクを検索している場合は、サービスのパフォーマンスも確認してみましょう。

CI/CDの検証を自動化する

導入のたびに、パイプラインはサービスが基本的なオブザーバビリティ基準を満たしていることを自動的に検証する必要があります。ログとトレースは取得されていますか。外形監視テストは合格していますか。パフォーマンスしきい値は達成されていますか。

コードチェックインのたびに実行される品質ゲートなどの自動検証チェックを設定し、問題が本番環境に到達する前に特定してください。これにより、プラットフォームの健全性に関する継続的なフィードバックループが確立されます。ただし、そのループの価値は、ループに組み込むチェックの品質にかかっていることに注意してください。

重要な理由:テレメトリーなしでサービスがリリースされていたことや、主要なパフォーマンスメトリクスを達成できていなかったことが事後に判明するような事態を回避できます。

プルリクエストにオブザーバビリティを表示する

プルリクエストを開く際は、コードの品質だけでなく、変更がサービスの動作に与える影響についてもフィードバックを取得する必要があります。リグレッションを導入しましたか。テストを中断しましたか。遅延のしきい値を超過しましたか。

Gitワークフローに、オブザーバビリティの検証や自動フィードバックを直接統合してください。

重要な理由:PRに多くの時間を費やしている場合は、ここがマージ前に問題を発見する最適な段階です。

オブザーバビリティが違いをもたらすユースケース

本番環境における問題のデバッグ

オブザーバビリティは、開発者が表面的な現象ではなく真の原因を明らかにするうえで役立ちます。開発者は、散在するログを精査したり運用チームの回答を待ったりする代わりに、リクエストの全経路をトレースし、障害の発生した箇所を特定し、推測に頼ることも遅延もなくその原因を理解できます。ライブデバッグは、最新のオブザーバビリティ戦略において急速に標準的な手法となりつつあります。開発者は再導入やステージング環境を必要とせずに、本番環境の問題をリアルタイムで調査できるようになります。

分散システムにおけるエンドツーエンドの可視性

最新のアプリケーションは、サービス、コンテナ、クラウドにまたがっています。オブザーバビリティはこれらのレイヤーを横断して全体像を可視化し、開発者にシステム動作の統合ビューを提供します。ユーザージャーニーを追跡する場合も、連鎖的な障害を診断する場合も、オブザーバビリティにより、コンポーネント間の相互作用や問題の発生箇所が明らかになります。

マルチクラウド環境におけるボトルネックの特定

オブザーバビリティは、クラウド境界を越えた遅延、スループット、リソース使用状況を可視化します、これにより、チームはサービスの低下や、過負荷のリージョン、非効率な依存関係を特定できます。

地域固有のバグやパフォーマンス問題のトラブルシューティング

すべての問題がすべてのユーザーに同じ影響を及ぼすわけではありません。オブザーバビリティにより、開発者は、地理、デバイスタイプ、ユーザーセグメントなどでテレメトリーを絞り込むことができます。これにより、特定の条件下でのみ発生する地域的な障害、モバイル特有のバグ、またはパフォーマンスのリグレッションを特定しやすくなります。

想定外のAI動作のデバッグ

チャットボットが関連性のない回答を返すようになったり、レコメンデーションエンジンに負荷がかかって動作が遅くなったり、要約サービスがトークン制限を超過してコストを押し上げたりすることもあります。AIのオブザーバビリティは、開発者がプロンプトと回答のフローをトレースし、トークンの使用状況や遅延を監視し、モデルの動作における異常を検出するうえで役立ちます。これにより、問題を速やかに修正し、AIを活用した機能の信頼性と効率性を維持しやすくなります。

シングルページアプリケーション(SPA)におけるハイドレーションと再レンダリングの問題の診断

シングルページアプリケーション(SPA)には、クライアントサイドレンダリングと状態管理に関して特有の課題があります。オブザーバビリティにより、開発者はハイドレーションのタイミング、再レンダリングの頻度、コンポーネントレベルのパフォーマンスを追跡できます。こうした可視化は、現代のフロントエンドにおけるページの読み込み遅延、UIのちらつき、想定外の動作を診断するうえで極めて重要です。

他社と差別化するDynatraceの特長

Dynatrace Observability for Developersは、開発者の視点に立って設計されています。必要な情報とコンテキストを収集し、開発者の作業環境、つまり手元で直接利用できるようにしています。これにより、問題を速やかに解決し、高品質なソフトウェアを開発できるようになります。

統合型オブザーバビリティ
Dynatraceは、単一のデータストアからサービスや環境を横断して、ログ、メトリクス、分散トレースを自動的に相関分析することで、開発者にアプリケーションの完全かつ連携したビューを提供します。Dynatraceは、開発者が問題を速やかに解決するために必要なコンテキストとともに、すべてのオブザーバビリティデータを1か所に集約します。

本番環境対応のAIオブザーバビリティ
Dynatraceは、OpenLLMetryとネイティブ統合を活用し、LLMの遅延、トークン使用量、モデルドリフトを含むAIワークロードのメトリクスを自動的に収集し、相関分析します。これにより、インストルメンテーションツールを追加しなくても、開発者は本番環境におけるAI機能の動作をリアルタイムで把握できます。

再導入不要のリアルタイムデバッグ
Dynatraceの最も開発者向けの機能の1つは、サービスを再起動したり新しいビルドをプッシュしたりすることなく、アーキテクチャの複数階層にわたるライブコードレベルのデータをリアルタイムで検査できる機能です。IDEから直接、本番環境の問題を詳細に調査できるため、ダウンタイムを削減し、解決を高速化できます。

ノイズを削減するAIを活用したインサイト
Dynatraceは、予測AIと生成AIを組み合わせ、自動的な根本原因分析、異常検出、コンテキストに応じた推奨事項を提供します。開発者が問題をより速やかに修正したり、完全に防止したりするうえで役立つ、実践的なインサイトを提供します。

IDEとCI/CDの密接な統合
Dynatraceは、VS CodeやIntelliJなどの主要なIDEとネイティブに統合されます。これにより、開発者は、ワークスペースを離れずに、パフォーマンスの監視、問題のデバッグ、コードの最適化を行うことができます。また、開発フローにオブザーバビリティを直接組み込むこともできます。Dynatraceは、CI/CDパイプラインとも連携し、ビルドの自動検証、リグレッションの検出、デリバリープロセスの各段階でログ、トレース、パフォーマンスメトリクスなどのテレメトリー情報を可視化します。

実用的なログ分析
Dynatraceは、ログを独立したデータストリームとして扱うのではなく、自動的にトレースやメトリクスと相関付けます。これにより、テレメトリーデータを手作業で結合するという時間がかかる工程が不要になり、開発者は本番環境で発生している事象の全体像を明確に把握できるようになります。

ワークフローに組み込まれたセキュリティ
Dynatraceは、開発プロセスに自動脆弱性検出機能を組み込んでいます。開発者は、デリバリーの遅延もコンテキストの切り替えもなく、開発サイクルの早い段階でセキュリティリスクを特定して対処できます。

長期的な影響

オブザーバビリティへの投資は、長期的に見て大きな利益をもたらす可能性があります。組織が拡大し、システムが複雑化するにつれ、可視性、速度、開発者の集中力を維持する機能の重要性はさらに増していきます。こうした機能を可能にするのが、Dynatraceのようなプラットフォームです。

Dynatraceは、チームが生産性を維持し、連携を図れるよう支援します。開発者は、トラブル対応に費やす時間を削減し、生産的な時間を増やすことで、ソフトウェアの品質とチームの健全性を高めることができます。

これは、時間の経過とともに、チーム間の連携強化、デリバリーサイクルの短縮、開発者の満足度向上につながります。

Dynatraceは、進化を続けています。AI、セキュリティ、開発者体験への十分な投資により、現代のソフトウェア開発とともに成長し、将来の事象にも対応できるよう設計されています。

Ready to learn more about how observability fits into your workflow?

Explore how Dynatrace can help you debug faster, ship with confidence, and stay focused on what matters.