はじめに: 見えない問題に立ち向かうために

エンジニアとして仕事をしていると、わたしたちは日々、大小さまざまな問題に直面します。

• 「ユーザーから『サイトが重い』と報告があったが、手元では再現しない…」
• 「特定の条件下でのみ発生するバグで、ログにも何も残っていない…」
• 「リリース後から、なぜかエラーレートがじわじわ上がっている…」

こうした状況で、わたしたちはつい「きっとあの変更が原因だろう」「DBの負荷が高いに違いない」といった「推測」からデバッグを始めがちです。もちろん経験に基づく勘、つまり経験からの仮説は重要ですが、しかしシステムの複雑性が増すにつれて推測だけで根本原因にたどり着くのは困難になっています。また個人の経験と勘に頼るアプローチは属人性が高く再現性が低いため、その人がいなければ問題解決ができない状況を生み出します。

わたしたちエンジニアはユーザー価値を実現することが大きな役割です。ユーザー価値を実現するために、機能性を実現することに加えて、信頼性 / 可用性 / キャパシティ / パフォーマンス / セキュリティ / 持続性といった特性を実現するわけです。個人の経験と勘に頼るアプローチは即効性が高いので重宝されますが、一方でシステムの信頼性、可用性、そして長期的な持続性を損なうという本質的な課題に繋がります。

もしシステムの内部状態を自由自在に問いかけ、データに基づいて「何が起きているのか」を正確に把握できるとしたらどうでしょう。それは暗闇で手探りするような開発から、明確な地図を持って目的地へ向かうような「確信」の開発へシフトできます。

この記事ではこの「確信」をもたらす鍵となるオブザーバビリティ (Observability: 可観測性) と、その期待効果を解説します。

オブザーバビリティはシステムと対話する能力

オブザーバビリティとは、システムから出力されるデータを使い、たとえ本番環境で予期せぬ問題が発生したとしても、原因を調査するために新しいコードをデプロイすることなく、後からその内部状態について自由に問いかけ、データを引き出して、理解できる能力そのものを指します。

一義的にはシステム・サービスが対話に足る能力を備えている程度を指しますが、包括的にはそれを利用するエンジニアやそれらのデータをもとに判断・行動する組織が能力を備えている程度を指すことがあります。

オブザーバビリティを備えているということは、単にCPU使用率やエラー数を眺めること以上の意味を持ちます。あらかじめ「こうなったら問題だ」と想定できる事象をチェックするだけではシステムの振る舞いを捉えるにはデータ不足です。通常状態がわからないと異常状態との区別がつかないですよね。普段から多角的な視点でデータを収集しておくことが役に立つわけです。

ピンとこない方のためにたとえ話をしてみます。たとえば「最近なぜか特定のランニングコースでタイムが落ちて悩んでいる」という状況を想像してみてください。あなたはフィットネストラッカーを使い、走るたびに距離やペース、ピッチ、心拍数、コースの高低差、その日の天気や気温といったデータを記録しています。また「今日は足が重く感じた」といった主観的な感想もメモしています。さらに食事も記録しています。

走り終わった後からこれらの多様なデータを組み合わせて分析してみます。すると「タイムが悪い日は決まって、コース後半の焼肉屋の辺りでピッチが落ち、心拍数が急上昇している。そういう時は前の食事が控え目だった」という、本人も意識していなかった相関関係を発見できるかもしれません。

このように複数のデータを組み合わせてシステム(この場合は自身の体)に「問いかけ」、パフォーマンスが低下した根本原因を探っていけるということ、そしてこのプロセスがオブザーバビリティがもたらす力なのです。

このような「システムと対話する能力」を手に入れることで、わたしたちは複雑な現象の背後にある事実をデータから引き出し、自信を持って、「確信」をもって次のアクションに進むことができるようになるのです。

オブザーバビリティで広がる、システムとの対話

システムの内部状態を知るためのデータと言うと「システム監視」を想像する方がいると思います。それは正解です。わたしはオブザーバビリティが大好きですが、システム監視も大好きです。ここでオブザーバビリティが従来の「システム監視」とどう関わるのか、わたしの考えを整理しておきたいと思います。

まず明確にしたいのは、この2つは対立する概念ではないということです。オブザーバビリティはシステム監視を何段階か拡張した姿であり、その発展により、より多くのエンジニアにとって開かれたアプローチとなりました。

従来の「システム監視」は、サーバーのCPU使用率やディスクI/Oといった指標を追い、システムの健康状態を可視化するという非常に重要な役割を担ってきました。その価値がオブザーバビリティの登場によって変わることはありません。

その上で、オブザーバビリティの素晴らしい点は、システム監視の深い経験が前提条件ではないということです。むしろオブザーバビリティの恩恵を大きく受けるのは、いままでシステム監視に携わっていなかった開発者です。自身が書いたコードの挙動、ひいてはその信頼性に責任を持つアプリケーション開発者や、システム全体の信頼性をより高みに引き上げるためのデータが得られます。

「あのユーザーから申告があった「遅い画面」は具体的にこのAPI呼び出しのことだったのか」「今のところユーザーからの連絡はないが、この処理がエラーになってリトライが増えているようだ。このままいくとサイレントクレーマーが増えて解約が増えそうだぞ」といった具体的な問いを発見し、さらにその理由を見つけられるようになります。

もちろんシステム監視の知見やインフラレイヤーの知識があれば、より多角的な分析が可能になり、それは高付加価値なスキルとして大きなアドバンテージです。しかしそれは必須科目ではなく、強力な選択科目なのです。

オブザーバビリティの世界では、挙動の分析や理解・トラブルシューティングにおける「個別のシステムに関する暗黙知への依存度」、つまり「コンテキスト(文脈)への依存度」は下がります。その代わりにデータから仮説を立てて検証するエンジニアとしての基礎技術力と、未知の事象を探求する好奇心の比重が高くなります。

その意味で、オブザーバビリティはこれまでシステム監視に馴染みがなかった多くのエンジニアにとって、システムと対話し始めるための開かれた素晴らしい入り口と言えるのです。

この様子を指して「モニタリングの民主化」「データの民主化」などと呼ぶことがあります。

データで語る「確信」のサイクル

ではオブザーバビリティという能力を手にすると、日々の開発やトラブルシューティング、問い合わせ対応はどう変わるのでしょうか。開発の際に手元で動かしながらデバッガーで変数の値やコールスタックを追っていくと、コードの挙動がよく分かり、大変捗りますよね。オブザーバビリティは、このデバッガーの強力なコンセプトを、複雑で分散した本番環境に拡張するようなものだと考えることができます。

ですからエンジニアリングの原則である「推測するな、計測せよ」を、より高い解像度で実践できるようになります。もう少し具体的に言えば、「データから仮説を立てて検証する。そして、判断に必要なデータがなければ、まずデータを得ることから始める」というサイクルを回せるようになります。

問題が発生したとき、わたしたちは感情や経験則ではなく、データという客観的な事実に基づいて仮説を立て、それを検証するサイクルを回せるようになります。これは、わたしが好んで用いるOODAループ (Observe → Orient → Decide → Act) の考え方そのものです。

1. Observe (観察): 情報を集める
   • ➔能動的に情報収集する。特に都合の悪い情報を積極的に集める
   • 関連する期間のログを検索したり
   • レイテンシー(応答時間)やエラーレートのデータを確認したり
   • 分散トレーシングでリクエストの処理の流れを追跡したり
2. Orient (情勢判断): 情報を解釈する
   • Orient (情勢判断): 情報を解釈する
   • ➔集めた情報を論理的/倫理的/直感的に解釈する
   • 「レイテンシー(応答時間)の悪化は、DBクエリーの発行数と相関があるようだ。DBクエリー発行数が劇的に増えた理由はもしかしてこの検索条件に由来しているのでは…」
   • 「この時間帯のエラーレート増加は社内利用だから+20%でも大きな問題はないけれど、この時間帯のエラーレート増加はユーザーの基幹業務だから+3%でもかなりまずいぞ…」
   • 「この様子だと来月の月末処理はマズいことになりそうだ…」
3. Decide (意思決定): 次の行動内容を決定する
   • ➔解釈をもとに計画/仮説を構築する
   • 「該当のDBクエリにインデックスを追加して、効果を測定しよう」
   • 「該当ユーザーにヒアリングしてみよう」
   • 「改善できるか確認して、無理そうなら月末までにスペックアップしよう」
4. Act (行動): 行動する
   • ➔実際に行動/実行し、仮説を検証する

このサイクルを回すことで、「多分こうだろう」という「推測」は、「このデータがこう示しているから、こうなっている可能性が高い」という、データに裏打ちされた「確信」に変わっていきます。この小さな確信の積み重ねが、本番環境でしか・あるいは特定のデータ条件でしか発生しないバグやパフォーマンス問題の解決を劇的に早め、わたしたちエンジニアに自信と精神的な安定と、そして着実な成果をもたらしてくれるのです。

まずは今あるデータを見てみよう

「オブザーバビリティの重要性は分かったけれど、何から始めればいいのか分からない」と感じるかもしれません。(もちろんわたしたちX-Tech5にご相談いただくのが一番なのですが、それはそれとして)高価なツールを導入したり、アプリケーションに大きな変更を加えたりしなくても始められる方法を紹介します。
※もちろん高価なツールは相応に多くの機能や効果が期待できる良いものばかりです

今日からでも始められる、最も重要な第一歩は「今すでにあるデータを見る習慣をつける」ことです。

多くのシステム、特にAWSやGoogle Cloudなどのクラウドサービスを利用している場合、実はすでに多くのデータが自動的に収集されています。つまりシステム側は多少なりともオブザーバビリティを有しています。たとえばロードバランサーやWebサーバーのアクセスログです。このログにはユーザーからのリクエストひとつひとつについての貴重な情報が詰まっています。

システムがオブザーバビリティを有しているのですから、次は読み手側、つまりわたしたちエンジニアの番です。

もしどこから手をつければよいか迷ったら、まずはアクセスログに含まれる以下の指標に注目してみてください。

• レイテンシー (応答時間): リクエストを受け取ってから、レスポンスを返し終わるまでにかかった時間
• HTTPステータスコード: 200(OK)や404(Not Found)、500(Internal Server Error)など、リクエストの処理結果を示すコード。500番台の割合をエラーレート(エラー率)として見る場合も多くある

ログひとつひとつを眺めても傾向はわかりづらいので、グラフ化されているものを眺めるのがよいです。ログ、つまり詳細を記述したテキストではなく、横軸日時・縦軸発生数のグラフが用意されていることが多いです。横軸が日時・縦軸がレイテンシーの平均値やパーセンタイルというグラフや、横軸が日時・縦軸がステータスコードごとのリクエスト数(ないし割合)というグラフがあるはずです。

これらは、ユーザー体験をかなり直接的に表した、基本的で重要な健康指標です。これらの指標の状況を眺めるだけでも「特定の時間帯だけ応答時間が長いな。これはあの業務の影響を受けているのでは？」「500番台のエラーがこの時間帯に集中しているぞ、このバッチ処理は時間を変えたほうがよさそうだ」といった多くの気づきが得られます。

この「気づき」こそが、オブザーバビリティの肝である「システムに問いかける」ことの価値です。まずは今あるデータを活用し、自分のシステムの状態を観察する。この小さな習慣が、推測に頼らない「確信」の開発への大きな一歩となるのです。

まとめ

今回は「推測」ばかりではない新しい選択肢として、データに基づいて「確信」を持って開発・運用できるようになる能力「オブザーバビリティ」についてお話ししました。

• オブザーバビリティは「推測」を「確信」に変える、未知の問題を解決できる可能性
• オブザーバビリティとは、深いコンテキストを持たないエンジニアでも、新しいコードをデプロイすることなく、システムの内部状態を、事後に探求できる能力のこと
• オブザーバビリティは言わばシステム監視の拡張であり、システム監視やインフラレイヤーの知見はあるとさらに良いが必須ではなく、むしろより多くのエンジニアに開かれたアプローチ
• データに基づきOODAループを回すことで、エンジニアは「推測」ではなく「確信」を持って課題解決と改善に取り組める
• オブザーバビリティの第一歩は、まず「今あるデータを見る(アクセスログなど)」という日々の小さな習慣から始まる

システムが複雑化し続ける現代において、オブザーバビリティはもはや一部の担当者/専門家のためのものではありません。わたしは、すべてのWebエンジニアの役に立つ基礎能力だと考えています。

わたしたち自身のシステムとの向き合い方をより実態に即したものへと育てていきましょう。その変化は、必ずあなたのエンジニアとしての成長と、開発の楽しさに繋がっていきます。

もしあなたのチームや組織でオブザーバビリティを本格的に導入したい、あるいは専門家の視点からアドバイスが欲しい、「確信」へのシフトをリードして欲しい、オブザーバビリティは過去にチャレンジしたけど改めて挑戦したいなどと感じたなら、わたしたちのオブザーバビリティ実現代行や SRE サービス、伴走支援、 OBServeサービス がお力になるでしょう。ぜひ一度ご覧になってみてください。

またオブザーバビリティについては、より包括的な入門ガイドのホワイトペーパーを準備中です。ご期待ください。