前書き

• オブザーバビリティは技術的な概念
• うまくいくかどうかは適切な文化的足場を備えているかどうかが重要
• モニタリングとオブザーバビリティを分けるのはシステムの動作の状態空間がポイント
• これをどのように探索するか、どの程度の詳細さで探索するかに違いがある
• モニタリングは健全性を大まかに把握するためのもの
• オブザーバビリティはシステムの状態空間を詳細にマッピングしてシステムをよりよく理解するために必要

序文

• この本の目的
  • ソフトウェアのデイバリーと運用の文脈におけるオブザーバビリティの意味
  • オブザーバビリティを達成するための基本的なコンポーネントの構築方法
    *オブザーバビリティがチームのダイナミクスに与える影響
  • 大規模システムでオブザーバビリティにするための考慮点
  • あなたの組織でオブザーバビリティの文化を構築するための実践的な方法

1章 オブザーバビリティへの道

1. オブザーバビリティの重要性

• 現代のソフトウェアシステムは、マイクロサービスや分散システムなどの複雑なアーキテクチャを採用しており、従来のモニタリング手法では内部状態や動作を把握することが困難になっている。
• オブザーバビリティは、システム内部を深く理解し、予期せぬ問題を調査・解決するために不可欠なアプローチ。

2. オブザーバビリティとモニタリングの違い

• モニタリングは、既知の障害モードを検出するためのリアクティブなアプローチ。事前に定義されたメトリクスやしきい値に基づいてアラートを発生させる。
• オブザーバビリティは、未知の未知の障害モードを調査・解決するためのプロアクティブなアプローチ。システムのあらゆる側面を詳細に記録し、柔軟なデータ探索を可能にする。

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

• 複雑なシステムにおける問題解決の迅速化: 深いコンテキストと探索可能性により、問題の原因を効率的に特定できる。
• ユーザー体験の向上: システムの健全性を詳細に把握し、安定したサービスを提供できる。
• ビジネスの成長: システムの信頼性とパフォーマンスを向上させ、ビジネス目標達成に貢献。

4. オブザーバビリティを実現するための要素

• 高カーディナリティ・高ディメンションのデータ収集: システムのあらゆるイベントや状態を詳細に記録する。
• 柔軟なデータ探索: 任意の切り口でデータを照会し、隠れたパターンや相関関係を発見する。
• チームとツールの連携: 開発者、運用担当者、SREなど、組織全体でシステムを理解し、オブザーバビリティツールを活用する文化を醸成する。

5. オブザーバビリティの未来

ソフトウェア開発の標準的なプラクティスとして定着し、AIや自動化技術との融合により、さらに進化していく。

2章 オブザーバビリティとモニタリングにおけるデバッグ方法の違い

• 従来のモニタリングツールは、システムの状態を既知のしきい値と照合し、以前に発生したことのあ
  るエラー状態が存在するかどうかを示すことで機能する
• オブザーバビリティツールは、パフォーマンスの問題がどこで、なぜ発生しているかを体系的に判断するための反復探索的な調査が可能になっていることで機能する
• オックスフォード英語辞典は、「モニタリング（monitoring、監視）」を「体系的な見直しを行うために
  （何かの）経過や品質を一定期間にわたって観察し確認すること」と定義
  • 従来のモニタリングはメトリクスによってこれを行う
• 静的ダッシュボードは、一般的にサービスごとにひとつずつ組み立てられ、エンジニアがモニタリン
  グ対象のシステムにおける特定の側面を理解するための有効な出発点となる
  • ダッシュボードの本来の目的である、一連のメトリクスがどのように追跡されているかの概要を提供し、注目すべき傾向を表面化させること
  • デバッグで新しい問題を発見するのには向いていない
  • 最近のサービスでは、一般的に非常に多くのメトリクスが収集されるため、それらをすべて同じダッシュボードに収めることは不可能
• メトリクスを使用して新しいシステムの洞察を表面化させることは、本質的にリアクティブなアプローチ
• 歴史的に、エンジニアは物事がうまくいかないときに適切な診断を下す目的で、必要なデータから1～2層離れた解釈のデータが密集している静的なダッシュボードに依存してきた
  • しかし、新しい問題を発見したとき、その有用性の限界が見えてきた
• モニタリングは、既知の問題や以前に特定されたパターンを検出するのに最適なリアクティブなアプローチ
  → このモデルはアラートや停止という概念を中心
• オブザーバビリティがあれば、問題がどこでどのように発生しているかを最初に予測する必要がなく、あらゆるディメンションやその組み合わせによって、問題の原因を明示的に発見できる
• モニタリングとオブザーバビリティの違いを「組織的知識に頼る」「隠れた問題を発見する」「本番
  環境上の問題を診断する自信がある」で比較
• 組織的知識とは、ある人には知られていても、組織内の他の人にはあまり知られていない不文律の
  情報のこと
  → 長年のエンジニアは知っているが、途中で参加したエンジニアはわからない、結果として長年のエンジニアに頼らざらずおえなくなる
• 従来のモニタリングによるダッシュボードの限界の 1 つとしてメトリクスやログの相関を自力で見る必要がありツールの切り替えも発生してエンジニアが疲弊してしまう
• オブザーバビリティツールはテレメトリーデータからコンテキストを 1 箇所に集めて調査者が簡単に切り刻んで拡大・縮小し決定的な答え見つけられるようにすること
  → 必要に応じてどのエンジニアも探索できることが重要

まとめ

• リアクティブ vs プロアクティブ: モニタリングは既知の問題を検出するリアクティブなアプローチであるのに対し、オブザーバビリティは未知の問題を発見し、根本原因を調査するためのプロアクティブなアプローチです。
• 静的 vs 動的: モニタリングは静的なダッシュボードに依存し、既知のメトリクスに基づいてアラートを発しますが、オブザーバビリティは動的な探索を可能にし、あらゆる角度からデータを分析できます。
• 組織的知識への依存: モニタリングはしばしば組織的知識、つまり特定の個人にのみ知られている情報に依存しますが、オブザーバビリティはデータを一箇所に集約することで、誰でも問題を調査できるようにします。
• データの相関: 従来のモニタリングでは、メトリクスやログを個別に分析する必要があり、相関関係を見つけるのが困難ですが、オブザーバビリティツールはデータを統合し、簡単に相関関係を調査できます。
• 問題解決への自信: オブザーバビリティは、問題の原因を特定し、解決策を見つけるための自信を高めることで、エンジニアの負担を軽減します。

3章 オブザーバビリティを用いないスケーリングからの教訓

• 現代的な分散型システムへの進化により、エンジニアと本番環境との関係を変えるような三次的な効果がもたらされる
  • ユーザー体験はもはや、すべてのユーザーにとって同じであると一般化できない
  • モニタリングのアラートは、本番環境におけるエッジケースを探し、システム状態が既知のしきい
    値を超えた場合、膨大な数の偽陽性や偽陰性、無意味なノイズが発生する
  • デバッガーはもはや、特定のランタイムのみにアタッチできなくなる
  • 手作業で修正する必要があったり、手順書で定義できるような繰り返し発生する既知の障害は、標準的ではなくなる
  • メトリクスや従来のモニタリングツールを使えば、パフォーマンスのスパイクや問題の発生に簡単に
    気づくことができたが、これらのツールでは、スタックを任意に切り刻んで掘り下げて問題の原因を特定したり、 他の方法では発見できないようなエラー同士の相関関係を見れない
    → 未知のエラーに対しては、もっとも長く在籍する人が最高のデバッガーであるといことはなくなった
• アプリケーションのテレメトリーを収集し、適切な抽象度で、ユーザー体験を中心に集計し、リアルタイムで分析できるようになった
  → 理想の姿としては、事実ベースの情報を関連させて考察できることで、こちらの問いを繰り返し投げて原因究明が可能なこと

まとめ

• ユーザー体験の多様化: 従来のモニタリング手法は、画一的なユーザー体験を前提としていたが、現代の分散システムでは、ユーザー体験が多様化し、個別の問題把握が困難になっている。
• アラートの限界: 単純なしきい値ベースのアラートは、複雑なシステムにおいては大量のノイズを生み出し、真の問題を見逃すリスクを高める。
• デバッグの複雑化: 分散システムでは、従来のデバッガーのように特定のランタイムにアタッチするだけでは問題解決が難しく、システム全体の挙動を俯瞰する必要がある。
• 未知のエラーへの対応: 経験則や手順書に頼った問題解決は、未知のエラーに対しては効果が薄く、システム全体から情報を収集・分析するアプローチが求められる。
• オブザーバビリティの役割: ユーザー体験を中心としたテレメトリデータの収集・分析により、問題の根本原因を特定し、未知のエラーにも迅速に対応できるようになる。

4章 オブザーバビリティとDevOps、SRE、クラウドネイティブとの関連性

オブザーバビリティの位置づけ

1. 最新のソフトウェア開発手法との関連性
   オブザーバビリティは、DevOps、SRE、クラウドネイティブといった最新のソフトウェア開発手法と密接に関連しています。これらの手法は、システムの複雑性や変化のスピードを加速させており、従来の監視手法では対応が困難になっています。
2. オブザーバビリティの必要性
   DevOps や SRE は、開発と運用が連携してシステムの信頼性とパフォーマンスを向上させることを目指しています。クラウドネイティブは、スケーラブルで回復力のあるシステムを構築するために、マイクロサービスやコンテナなどの技術を活用します。これらの手法では、システムの内部状態を理解し、問題を迅速に検出して解決することが重要であり、オブザーバビリティが不可欠となります。
3. オブザーバビリティの統合
   オブザーバビリティは、これらの手法に統合されており、継続的な投資が必要です。オブザーバビリティツールや手法を用いて、システムのメトリクス、ログ、トレースを収集・分析することで、システムの健全性やパフォーマンスを把握し、問題解決や改善に役立てます。
4. テスタビリティとの類似性
   オブザーバビリティは、テスタビリティと同様に、システムの理解を深めるための特性です。テスタビリティがシステムの動作確認を容易にするのに対し、オブザーバビリティはシステムの内部状態を可視化することで理解を助けます。どちらも継続的な取り組みが必要です。
5. オブザーバビリティのメリット
   オブザーバビリティは、開発者とエンドユーザーの双方にメリットをもたらします。開発者は、システムの問題を迅速に特定し、解決することができます。エンドユーザーは、安定性とパフォーマンスの高いシステムを利用できるようになります。

クラウドネイティブとオブザーバビリティの必要性

1. 旧来の開発手法との対比
   従来のモノリシックでウォーターフォール型の開発手法とは異なり、現代のソフトウェア開発では、クラウドネイティブやアジャイルといった手法が主流となっています。これらの手法は、開発チームの自律性やリリース速度の向上など、多くのメリットをもたらします。
2. クラウドネイティブの複雑性
   しかし、クラウドネイティブなシステムは、複雑性が増すというトレードオフがあります。マイクロサービスやコンテナなどの技術は、システムをより動的でスケーラブルなものにしますが、同時に管理や監視を困難にします。
3. オブザーバビリティの重要性
   従来のシンプルな監視手法では、クラウドネイティブシステムの複雑性に対応できません。オブザーバビリティは、システムの内部状態を理解し、問題を迅速に検出して解決するために不可欠となります。
4. クラウドネイティブとオブザーバビリティの関係
   CNCF は、クラウドネイティブを「最新の動的環境でスケーラブルなアプリケーションを構築し実行すること」と定義しており、オブザーバビリティを重要な要素として挙げています。オブザーバビリティツールや手法を用いて、システムのメトリクス、ログ、トレースを収集・分析することで、開発者はシステムの健全性やパフォーマンスを把握し、問題解決や改善に役立てます。
5. DevOps、SRE との連携
   DevOps や SRE の手法も、オブザーバビリティと密接に関連しています。これらの手法は、開発と運用の連携や自動化を重視しており、オブザーバビリティはシステムの信頼性とパフォーマンスを向上させるために不可欠な要素となります。

オブザーバビリティの実現方法とクラウドネイティブシステムへの適用

1. オブザーバビリティの目標
   オブザーバビリティの目標は、システムやアプリケーションの内部状態を理解するための情報を提供することです。ログ、メトリクス、トレースなどの手法を組み合わせることで、システムの内部状態を推測し、問題をデバッグすることが可能となります。

2. クラウドネイティブシステムにおける課題
   従来のモノリシックなシステムでは、シンプルな監視手法でも問題のデバッグが可能でした。しかし、クラウドネイティブシステムは、マイクロサービスやコンテナなどの技術により、複雑性が増しています。従来の手法では、これらのシステムの内部状態を把握することは困難です。

3. クラウドネイティブにおけるオブザーバビリティの必要性
   クラウドネイティブシステムでは、コンポーネント間の相互依存性、一時的な状態、バージョン管理の互換性など、新たな課題が存在します。これらの課題に対処するためには、分散トレースなどのオブザーバビリティツールが不可欠となります。

4. 分散トレースの利点
   分散トレースは、特定のイベントが発生したときのシステム内部の状態を把握するのに役立ちます。各イベントにコンテキストを追加することで、システムの各部分で何が起こっているのかを視覚的に理解することができます。

5. オブザーバビリティのメリット
   オブザーバビリティは、システムの複雑さに関係なく、チームが協力して問題をデバッグするための共有コンテキストを提供します。これにより、問題解決の効率化やシステムの信頼性向上につながります。

DevOps、SREとオブザーバビリティ

1. オブザーバビリティの重要性
   DevOpsチームやSREチームは、システムの複雑性を理解し、管理するためにオブザーバビリティを重視しています。オブザーバビリティツールは、障害の原因を特定し、解決するための洞察を提供します。

2. 症状ベースのモニタリングへの移行
   従来の原因ベースのモニタリングから、症状ベースのモニタリングへの移行が進んでいます。これは、既知の障害を監視するだけでなく、ユーザーが実際に体験する問題を検出することに重点を置くことを意味します。

3. オブザーバビリティによる障害対応の効率化
   オブザーバビリティツールを使用することで、チームは誤報に時間を費やすことなく、実際の障害に集中することができます。また、障害の原因を迅速に特定し、解決策を考案することも容易になります。

4. オブザーバビリティとエンジニアリング技術の連携
   オブザーバビリティは、機能フラグ、継続的検証、インシデント分析などのエンジニアリング技術と連携することで、その効果をさらに高めます。

5章 構造化イベントはオブザーバビリティの構成要素である

オブザーバビリティの定義と技術的前提条件

1. オブザーバビリティの定義
   オブザーバビリティとは、システムの内部状態をどれだけ理解し説明できるかを示す尺度です。予測できない状況においても、あらゆる質問に答えられるように、システムの情報を収集・分析できる能力が求められます。

2. 技術的前提条件
   オブザーバビリティを実現するためには、以下の技術的前提条件を満たす必要があります。

• 詳細なテレメトリの収集: システムのあらゆる側面を詳細に把握するために、メトリクス、ログ、トレースなどのテレメトリデータを収集する必要があります。
• 任意の分析: 収集したテレメトリデータを、任意のディメンションに沿って分析できる必要があります。これにより、予測できない質問にも対応することが可能となります。
• コンテキストの保持: テレメトリデータが収集されたときのコンテキストを保持する必要があります。これにより、イベント間の因果関係を理解し、問題の原因を特定することができます。
  構造化されたイベント: テレメトリーデータは、任意の幅で構造化されたイベントとして収集する必要があります。これにより、柔軟な分析が可能となります。

3. 従来の監視手法との違い
   従来の監視手法では、あらかじめ定義されたメトリクスを収集していました。これに対して、オブザーバビリティは、予測できない質問にも対応できるように、より詳細で柔軟なデータ収集・分析を可能にします。

4. オブザーバビリティの重要性
   オブザーバビリティは、システムの複雑性が増す現代のソフトウェア開発において、不可欠な要素となっています。オブザーバビリティツールを活用することで、システムの信頼性向上、障害対応の効率化、新機能の安全なリリースなどが可能となります。

構造化イベントとオブザーバビリティ

1. 構造化イベントの定義
   構造化イベントとは、特定のリクエストがサービスとやりとりしている間に発生したすべての記録を、キーバリューペアとして整理したものです。これには、リクエスト ID、変数値、ヘッダー、実行時間、リモートサービスへのコールなど、デバッグに役立つあらゆるコンテキストが含まれます。

2. 構造化イベントの利点
   異常値の特定: 構造化イベントを比較することで、異常な動作を容易に特定することができます。
   柔軟な分析: イベントに含まれる様々なディメンションによるフィルタリングやグループ化が可能であり、柔軟な分析が可能です。
   コンテキストの保持: イベント発生時のコンテキストを保持することで、問題の原因特定に役立ちます。

3. 構造化イベントに取り込むべき情報
   リクエスト情報: リクエスト ID、ユーザー ID、セッション トークンなど
   ランタイム情報: コンテナ情報、バージョン管理情報など

4. 従来のデバッグ手法との違い
   従来のデバッグ手法では、ログファイルやデバッガーを使用してシステムの状態を把握していました。これに対して、構造化イベントは、より詳細で柔軟な分析を可能にし、問題の原因を迅速に特定することができます。

メトリクスとイベントの違い

1. メトリクスの定義
   メトリクスとは、システムの状態を表すために収集されたスカラー値です。タグを付加することでグループ化や検索を容易にすることができます。

2. メトリクスの限界
   メトリクスは、あらかじめ定義された期間にわたるシステム状態の集計レポートであるため、以下の限界があります。

• 粒度の不足: 集計された数値であるため、個々のイベントの詳細な情報を把握することができません。
  コンテキストの欠如: イベントのコンテキストを保持しないため、因果関係を理解することが困難です。
• 柔軟性の欠如: あらかじめ定義されたメトリクスしか収集できないため、予測できない質問に対応することができません。

3. イベントの利点
   イベントは、特定の時点で発生した事象のスナップショットであり、以下の利点があります。

• 詳細な情報: 個々のイベントの詳細な情報を把握することができます。
  コンテキストの保持: イベント発生時のコンテキストを保持するため、因果関係を理解することができます。
• 柔軟な分析: 様々なディメンションによるフィルタリングやグループ化が可能であり、柔軟な分析が可能です。

4. メトリクスとイベントの使い分け
   メトリクスは、システム全体の傾向を把握するのに適しています。一方、イベントは、個々の問題の原因を特定するのに適しています。

非構造化データと構造化イベント

1. 非構造化データの課題
   従来のログファイルは、人間が読めるように設計された非構造化データであり、機械による解析が困難です。そのため、問題の原因特定や分析に時間がかかるという課題がありました。

2. 構造化イベントの利点
   構造化イベントは、キーバリューペアとして整理されたデータであり、機械による解析が容易です。これにより、以下の利点が得られます。

• 効率的な検索: 特定のイベントやパターンを効率的に検索することができます。
• 柔軟な分析: 様々なディメンションによるフィルタリングやグループ化が可能であり、柔軟な分析が可能です。
• 自動化: ログデータの解析や可視化を自動化することができます。

3. 構造化イベントに取り込むべき情報
   構造化イベントには、デバッグに役立つあらゆる情報をできる限り取り込むべきです。例としては、リクエスト情報、ランタイム情報、ユーザー情報、システム情報などが挙げられます。

4. 高いカーディナリティと高いディメンション
   オブザーバビリティツールは、高いカーディナリティを持つフィールドや、高いディメンションのクエリを処理できる必要があります。これにより、複雑なシステムにおける問題の原因を特定することができます。

5. スキーマの制限
   オブザーバビリティツールは、データスキーマを事前に定義する必要がないように設計する必要があります。スキーマの制限は、柔軟な分析を妨げるため、オブザーバビリティの目標と矛盾します。

まとめ

1. オブザーバビリティとは
   オブザーバビリティとは、システムの内部状態を理解し説明できる能力を指します。複雑なシステムにおいても、問題の原因を特定し解決するために必要な情報を収集・分析できることが重要です。

2. オブザーバビリティを実現するための要素

• 構造化イベント: デバッグに必要な情報をキーバリューペアとして整理したデータ。
• 詳細なテレメトリ: メトリクス、ログ、トレースなど、システムの状態を把握するための様々なデータ。
• 柔軟な分析: 収集したデータを様々な角度から分析できる能力。
• 高いカーディナリティと高いディメンション: 複雑なシステムにおける問題を特定するために必要な機能。

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

• システムの信頼性向上: 問題を迅速に検出し解決することで、システムの安定性を高めることができます。
• 障害対応の効率化: 問題の原因を特定しやすくなり、解決までの時間を短縮できます。
• 開発チームと運用チームの連携強化: システムの状態を共有することで、チーム間のコミュニケーションが円滑になります。

4. オブザーバビリティの重要性
   現代のソフトウェア開発において、システムはますます複雑化しています。オブザーバビリティは、このような複雑なシステムを理解し管理するために不可欠な要素となっています。

6章 イベントをトレースにつなぐ

分散トレーシング：複雑なシステムを紐解くデバッグ技術

1. 分散システムにおけるデバッグの課題
   従来のソフトウェアデバッグ手法は、複雑な分散システムでは効果が限定的であり、新たなデバッグ技術が求められています。
2. 分散トレーシングの役割
   分散トレーシングは、リクエストが複数のサービスやコンポーネントをどのように処理されるかを追跡することで、問題の診断、コードの最適化、サービスの信頼性向上に役立ちます。
3. マイクロサービスアーキテクチャへの対応
   分散トレーシングは、マイクロサービスアーキテクチャの普及に伴い、複雑なサービス間の相互作用を理解するための重要なツールとして注目されています。
4. 分散トレーシングの普及と標準化
   Google の Dapper 論文をきっかけに、Zipkin や Jaeger などのオープンソースプロジェクトや商用ソリューションが登場し、分散トレーシングが広く普及しています。
5. 相互依存関係の可視化
   分散トレーシングは、サービス間の複雑な依存関係を可視化することで、問題の原因究明を容易にし、システム全体の最適化を支援します。

分散トレーシングの実装：トレースデータの構成要素

1. ウォーターフォール型可視化
   分散トレーシングでは、リクエストの各処理段階をウォーターフォール形式で可視化することで、ボトルネックの発生箇所を迅速に把握できます。
2. トレーススパン
   ウォーターフォールを構成する各箱はトレーススパンと呼ばれ、リクエスト処理の各ステップを表します。スパンは入れ子構造を持ち、親子関係で表現されます。
3. 必須データ
   トレースを構築するためには、トレースID、スパンID、親ID、タイムスタンプ、継続時間の5つのデータが必須です。
4. 追加データ
   サービス名やスパン名などのタグを追加することで、スパンを特定しやすくし、システムにおける関連性を明確にできます。
5. コードの計装
   トレースに必要なデータを収集するためには、既存のコードに適切な計装を施す必要があります。

分散トレーシングの実装：手動計装によるトレースデータの伝播

1. 単純化されたトレースシステム
   過度に単純化した手動のトレースシステムを例に、分散トレーシングの仕組みを解説しています。
2. クライアントサイドの計装
   トレースに必要なデータは、クライアントサイド (サービス側) でコードに計装を施すことで収集されます。
3. トレースデータの生成
   Go 言語で記述されたサンプルコードでは、UUID を用いたトレースIDとスパンIDの生成、タイムスタンプと継続時間の記録、サービス名とスパン名の追加などが行われています。
4. HTTPヘッダーによる伝播
   トレースデータは、X-B3-TraceId と X-B3-ParentSpanId といった HTTP ヘッダーを使用して、サービス間で伝播されます。
5. ウォーターフォール型可視化の構築
   各サービスが生成したスパンはトレースバックエンドに送信され、ウォーターフォール型の可視化によってリクエストの処理の流れを把握できます。

分散トレーシングの実装: カスタムフィールドによる詳細情報の追加

1. カスタムフィールドの追加
   トレーススパンには、親子関係や実行時間以外にも、ホスト名やユーザー名などのカスタムフィールドを追加できます。
2. デバッグ情報の充実
   カスタムフィールドによって、デバッグに必要な情報をスパンに含めることで、問題の原因究明をより効率的に行えます。
3. サンプルアプリケーション
   本章では、カスタムフィールドを追加した完全なサンプルアプリケーションのコードが示されています。
4. トレースライブラリの活用
   多くの分散トレーシングシステムは、定型的な計装作業を自動化するライブラリを提供しており、手動でのコーディングを削減できます。
5. ベンダーロックインの問題
   ベンダー固有のトレースライブラリは、他のソリューションとの互換性が低い場合があり、移行時に再計装が必要になる可能性があります。

分散トレーシング：オブザーバビリティのあるシステムへの応用

1. トレースとイベントの関係
   トレースは、サービス間の呼び出しだけでなく、リクエスト処理中に発生する様々なイベントを相互に接続することで、システム全体の動作を把握するための手段として活用できます。
2. 構造化ログへの応用
   従来の構造化されていないログも、トレースの概念を適用することで、より構造化された形式で収集・可視化できます。
3. 非分散作業の分割
   分散トレーシングは、分散システムだけでなく、モノリシックなアプリケーションやバッチ処理など、非分散的な作業の分析にも有効です。
4. ホットブロックの可視化
   CPU 集約的な処理など、特定のコードブロックを独自のトレーススパンで囲むことで、詳細なパフォーマンス分析が可能になります。
5. イベントの集合としてのトレース
   オブザーバビリティのあるシステムでは、サービス間の呼び出しに限らず、あらゆるイベントをトレースとして繋ぎ合わせることができます。

まとめ

1. 分散トレーシングの必要性
   現代の複雑な分散システムにおいて、従来のデバッグ手法は限界を迎え、分散トレーシングという新たな技術が不可欠となっています。
2. 分散トレーシングの仕組み
   リクエストがシステム全体をどのように処理されるかを追跡し、ウォーターフォール形式で可視化することで、問題の診断、パフォーマンス分析、信頼性向上を実現します。
3. トレースデータの構成要素
   トレースID、スパンID、親子関係、タイムスタンプ、継続時間などの基本情報に加え、カスタムフィールドによる詳細な情報の追加も可能です。
4. 実装方法
   手動計装による基本的な実装方法から、自動化されたトレースライブラリを活用した効率的な実装方法まで、様々なアプローチが存在します。
5. オブザーバビリティとの関連
   分散トレーシングは、サービス間の呼び出しだけでなく、あらゆるイベントをトレースとして捉えることで、システム全体の可観測性を向上させる強力なツールとなります。

7章 OpenTelemetry を使った計装

アプリケーション計装の課題：ベンダーロックインと重複

1. テレメトリーデータの重要性
   アプリケーションを計装してテレメトリーデータを収集することは、システムの状態を把握し問題を診断するための確立された手法となっています。
2. ワイドイベントとトレース
   ワイドイベントは、オブザーバビリティを実現するための理想的なデータ形式であり、トレースは複数のワイドイベントを相互に接続することで構成されます。
3. 従来の計装アプローチの問題点
   従来のアプリケーション計装は、ベンダー固有のライブラリやエージェントに依存することが多く、ベンダーロックインを引き起こします。
4. ベンダーロックインによる課題
   別の監視システムに移行する場合、既存の計装を別のライブラリで再実装する必要があり、コードの重複や計測のオーバーヘッド増加につながります。
5. オープンな計装の必要性
   ベンダーロックインを回避するためには、複数の監視システムで利用可能なオープンな計装方法が求められています。

OpenTelemetry：ベンダーロックインからの解放とオブザーバビリティの実現

1. ベンダーロックインからの脱却
   従来のアプリケーション計装は特定のベンダーに依存するケースが多く、移行の際に課題となっていました。OpenTelemetry は、このベンダーロックイン問題を解決するためのオープンソースの標準規格です。
2. OpenTelemetry の誕生
   OpenTracing と OpenCensus という2つのオープンソースプロジェクトが統合され、CNCF (Cloud Native Computing Foundation) 傘下で OpenTelemetry プロジェクトが開始されました。
3. OpenTelemetry の機能
   トレース、メトリック、ログなど、様々な種類のテレメトリーデータを収集し、ユーザーが選択したバックエンドシステムに送信できます。
4. 一度の計装で柔軟な選択
   OpenTelemetry を使用することで、アプリケーションコードの計装を一度行うだけで、様々なオープンソース/商用バックエンドにデータを送信できるようになり、柔軟性が向上します。
5. オブザーバビリティの実現
   OpenTelemetry は、アプリケーションを効率的に計装し、オブザーバビリティを実現するための強力なツールです。

解説

• 従来、アプリケーションの監視には、各ベンダーが提供する独自のツールやライブラリを使用するのが一般的でした。しかし、この方法では、特定のベンダーに縛られてしまい、他のツールへの移行が困難になるという問題がありました (ベンダーロックイン)。
• OpenTelemetry は、この問題を解決するために生まれたオープンソースの標準規格です。OpenTelemetry を使うことで、アプリケーションのコードを変更することなく、様々な監視ツールにデータを送信できるようになります。
• これは、例えるなら、家電製品のプラグが世界共通の規格になったようなものです。従来は、国ごとに異なるプラグ形状が使われていたため、海外旅行の際には変換プラグが必要でした。しかし、世界共通の規格が採用されれば、どんな国でも同じプラグで家電製品を使うことができます。
• OpenTelemetry も同様に、監視ツールの「共通規格」を提供することで、ベンダーロックインを解消し、ユーザーが自由にツールを選択できるようにします。

OpenTelemetry を使った計装: 実践的な導入と活用

1. OpenTelemetry の多言語サポート
   OpenTelemetry は Go、Python、Java など、多くのプログラミング言語に対応しており、幅広いアプリケーションで利用可能です。
2. Go 言語による解説
   本書では、Go 言語を用いた具体的なコード例を通して、OpenTelemetry の概念と使い方を分かりやすく解説しています。
3. OpenTelemetry の主要コンポーネント
   API、SDK、トレーサー、メーター、コンテキスト伝搬、エクスポーター、コレクターといった主要なコンポーネントとその役割を理解することが重要です。
4. 自動計装による効率化
   OpenTelemetry は gRPC、HTTP、データベース呼び出しなどを自動的に計装する機能を提供し、開発者の負担を軽減します。
5. カスタム計装による詳細な分析
   自動計装に加えて、カスタムスパンや属性を追加することで、アプリケーション固有のロジックや状態をより深く分析できます。

解説

• OpenTelemetry は、アプリケーションを「可観測性」のある状態にするための強力なツールです。 可観測性とは、システムの内部状態を外部から把握できる能力を指します。
• OpenTelemetry を使うことで、アプリケーションの実行状況を詳細に記録し、様々な角度から分析できるようになります。 これは、飛行機のフライトレコーダーのようなものです。フライトレコーダーは、飛行中のあらゆるデータを記録することで、万が一事故が起こった際に原因究明を可能にします。
• OpenTelemetry も同様に、アプリケーションの実行状況を記録することで、パフォーマンスの問題やエラーの原因を特定し、システムを改善するのに役立ちます。
• 本章では、OpenTelemetry の基本的な概念と使い方を、Go 言語のコード例を交えながら解説しています。 特に、自動計装とカスタム計装という2つの重要な機能について詳しく説明しています。
• 自動計装: gRPC や HTTP などの一般的な通信フレームワークを自動的に計装し、開発者の負担を軽減します。
• カスタム計装: 開発者が独自のコードを追加することで、アプリケーション固有のロジックや状態を監視できます。
• これらの機能を活用することで、OpenTelemetry はアプリケーションの可観測性を向上させるための強力なツールとなります。

まとめ

1. ベンダーロックインからの解放
   OpenTelemetry は、従来のベンダー固有の計装が抱えていたロックイン問題を解決する、オープンソースの標準規格です。
2. 多様なテレメトリーデータの収集
   トレース、メトリック、ログなど、アプリケーションの状態を把握するための様々な種類のデータを収集できます。
3. 柔軟なバックエンド選択
   一度の計装で、様々なオープンソース/商用のバックエンドシステムにテレメトリーデータを送信できるため、将来的な変更にも柔軟に対応できます。
4. 効率的な計装
   自動計装機能により、一般的な通信フレームワークの計装を自動化し、開発者の負担を軽減します。
5. 詳細な分析
   カスタムスパンや属性を追加するカスタム計装によって、アプリケーション固有のロジックや状態をより詳細に分析できます。

8章 オブザーバビリティを実現するためのイベント解析

オブザーバビリティ駆動のデバッグ：既知の条件からの脱却

1. 従来のデバッグの限界
   従来のデバッグは、システムに関する深い知識を持つ上級エンジニアの経験や直感に頼ることが多く、手順書やダッシュボードの作成は、システムの変化の速さに追いつけず、効果が限定的でした。
2. オブザーバビリティによるパラダイムシフト
   オブザーバビリティは、システムの未知の振る舞いを理解し、予期せぬ問題を解決するための新しいアプローチを提供します。
3. 既知の条件からの脱却
   従来のデバッグは、既知の条件に基づいて問題箇所を特定しようとしますが、オブザーバビリティでは、未知の条件に対しても柔軟に対応できることが重要です。
4. 高カーディナリティな質問
   オブザーバビリティツールを活用することで、従来の方法では難しかった、多様な属性に基づいた詳細な分析が可能になります。
5. 第一原理からのデバッグ
   問題の発生原因や影響範囲が不明な場合でも、オブザーバビリティデータに基づいて、根本原因を体系的に追跡し、解決することができます。

解説

• 従来のシステム管理やトラブルシューティングは、「システムについて知っていること」をベースに、経験豊富なエンジニアの勘と経験に頼ることが多かったと言えるでしょう。
• しかし、システムが複雑化し、変化のスピードが加速する現代において、このアプローチは限界を迎えています。 予期せぬ問題が発生した場合、過去の経験や知識だけでは対応できず、問題解決に時間がかかってしまうからです。
• オブザーバビリティは、「システムについて知らないこと」を発見し、未知の事象にも対応できる能力を提供します。
• これは、探偵が事件を解決する過程に似ています。探偵は、限られた情報から手がかりを収集し、様々な可能性を検討することで、真実に近づいていきます。
• オブザーバビリティツールは、探偵にとっての「証拠」のようなものです。 システムのあらゆるデータを収集し、分析することで、問題の根本原因を特定し、解決することができます。
• オブザーバビリティ駆動のデバッグでは、以下の点が重要になります。
  • システムのあらゆるデータを収集する
  • 様々な角度からデータを分析できるツールを用意する
  • 既知の条件にとらわれず、柔軟な思考で問題解決に取り組む

オブザーバビリティ駆動のデバッグ：コア分析ループによる自動化と第一原理からのアプローチ

1. オブザーバビリティと第一原理からのデバッグ
   オブザーバビリティにより、システムの事前知識に頼らず、客観的なデータに基づいて問題解決を行う「第一原理からのデバッグ」が可能になります。
2. コア分析ループ
   オブザーバビリティ駆動のデバッグでは、「全体像の把握」→「変化の検証」→「要因の探索」→「仮説の検証」というサイクルを繰り返す「コア分析ループ」が重要になります。
3. コア分析ループの自動化
   オブザーバビリティツールは、膨大な量のデータを分析し、異常値や関連性の高い属性を自動的に検出することで、コア分析ループを効率化します。
4. Honeycomb BubbleUp
   Honeycomb の BubbleUp 機能は、コア分析ループを自動化する具体的な例であり、異常な領域と基準値を比較し、差異の大きい属性をハイライト表示します。
5. オブザーバビリティツールとデータ形式
   コア分析ループは、任意の幅で構造化されたイベントデータがあってこそ実現可能であり、メトリックや従来のログでは実現できません。

解説

• 従来のデバッグは、システムの専門家による「職人技」に頼ることが多く、属人的な知識や経験に基づいて問題解決が行われていました。
• しかし、現代の複雑なシステムでは、このようなアプローチは限界を迎えています。 システムの規模が拡大し、変化のスピードが加速するにつれて、すべてのエンジニアがシステムの専門家になることは現実的ではなく、属人的な知識に頼らない、より体系的なデバッグ手法が求められるようになりました。
• オブザーバビリティは、この課題を解決するための新しいパラダイムです。 システムのあらゆるデータを収集し、強力な分析ツールを活用することで、誰でも「第一原理からのデバッグ」を実践できるようになります。
• 第一原理からのデバッグ とは、システムに関する事前知識に頼らず、客観的なデータに基づいて問題解決を行う方法です。 これは、科学的なアプローチであり、仮説を立て、データを分析することで、真実に近づいていくプロセスと言えます。
• オブザーバビリティツールは、このプロセスを自動化し、効率化するのに役立ちます。 例えば、Honeycomb の BubbleUp 機能は、異常な領域と基準値を比較し、差異の大きい属性を自動的に検出することで、問題の原因究明を加速します。
• 重要なのは、オブザーバビリティツールは万能ではない ということです。 ツールが効果的に機能するためには、適切なデータ形式で、十分な量のデータが収集されている必要があります。
• 従来のメトリックやログでは、コア分析ループを効果的に回すための情報が不足しているため、オブザーバビリティを実現するためには、任意の幅で構造化されたイベントデータ を収集することが不可欠です。

AIOps の限界と人間知能の重要性：オブザーバビリティ駆動のデバッグにおける協調

1. AIOps の限界
   AIOps は運用タスクの自動化を目指していますが、異常検知の精度や変化の激しいシステムへの対応には限界があります。
2. 異常検知の難しさ
   システムの挙動が常に変化する状況下では、AI が正常と異常を正確に区別することは難しく、誤検知や検知漏れが発生する可能性があります。
3. 人間の知能の価値
   人間の知能は、AI に比べて文脈理解や適応力に優れており、AIOps が苦手とする状況においても、柔軟かつ的確な判断を下すことができます。
4. 人間と AI の協調
   オブザーバビリティツールは、膨大なデータの分析やパターン検出を自動化することで、人間の知能を補完し、より効果的な問題解決を支援します。
5. コア分析ループの自動化
   コア分析ループの自動化は、人間と AI の協調による問題解決の好例であり、コンピューターの処理能力と人間の洞察力を組み合わせることで、複雑な問題にも効率的に対処できます。

解説

• AIOps は、AI を活用して IT 運用を自動化・効率化することを目指す技術ですが、万能ではありません。特に、常に変化する現代のシステムにおいては、AI がすべての問題を解決できるわけではありません。
• AIOps の異常検知機能は、過去のデータに基づいて正常な状態を学習し、そこから逸脱するものを異常として検出します。 しかし、システムの構成や動作が頻繁に変わる場合は、過去のデータが役に立たなくなり、誤検知や検知漏れが増加する可能性があります。
• 一方、人間の知能は、文脈を理解し、状況に応じて柔軟に判断することができます。 例えば、新しい機能のリリースやシステムのアップデートに伴う変化は、AI にとっては異常と判断されるかもしれませんが、人間はそれが意図的な変更であることを理解できます。
• オブザーバビリティ駆動のデバッグでは、AIOps と人間の知能を組み合わせることで、両者の強みを活かすことが重要です。
  • AIOps: 膨大な量のデータ分析、パターン検出、異常の早期発見など、人間には不可能な処理を高速に行う。
  • 人間の知能: AI が検出した異常の原因分析、文脈に基づいた判断、最終的な解決策の実行など、AI が苦手とするタスクを遂行する。
• この協調関係を実現するのが、コア分析ループの自動化です。 コンピューターが大量のデータを分析し、人間がその結果を解釈することで、複雑な問題にも効率的に対処できます。
• オブザーバビリティツールは、人間と AI を繋ぐ架け橋 として機能し、両者の能力を最大限に引き出すことで、より高度な問題解決を可能にします。

まとめ

1. 従来のデバッグからの脱却
   複雑なシステムでは、経験や直感に頼る従来のデバッグ手法は限界を迎えており、オブザーバビリティという新しいアプローチが必要とされています。
2. 第一原理からのデバッグ
   オブザーバビリティは、システムの事前知識に頼らず、客観的なデータに基づいて問題解決を行う「第一原理からのデバッグ」を可能にします。
3. コア分析ループ
   オブザーバビリティ駆動のデバッグの中核となるのは、「全体像の把握」→「変化の検証」→「要因の探索」→「仮説の検証」というサイクルを繰り返す「コア分析ループ」です。
4. オブザーバビリティツールの役割
   オブザーバビリティツールは、膨大な量のデータを分析し、コア分析ループを自動化することで、問題解決を効率化します。 特に、任意の幅で構造化されたイベントデータの収集と分析が重要になります。
5. 人間と AI の協調
   AIOps は強力なツールですが、万能ではありません。人間の知能と AI の処理能力を組み合わせることで、複雑な問題にも効果的に対処できます。