本番環境でシーケンス図の答え合わせ: オブザーバビリティしませんか？
「なんか、たまにレスポンスが遅い時がある気がするんですよね」
→「わかります。でも、いまいち再現できないんですよねぇ…」
こうした会話は現場でよく見られます。ユーザーからの問い合わせや、QAチームやカスタマーサクセスチームでの発見、チーム内での気づきなどに端を発することが多く、そのほとんどは明確なデータに基づかない「感覚」から始まります。
この「感覚」は非常に重要です。
しかし「感覚」は主観的なものですから、扱いが難しい側面があります。重要だが緊急ではないと判断されて後回しに…これまた、よくある光景です。
もしこの「感覚」をデータで確認できたらどうでしょうか？
データをもとに、状況確認や定量化ができれば、より適切に優先順位をつけられます。それにデータがあれば適切なゴール設定や原因分析、対処の勘所の特定もスムーズです。
特にマイクロサービスやクラウドネイティブ技術が普及し、システムがますます複雑で動的になっている現代において、「推測するな、計測せよ」という原則は、かつてないほど重要になっています。
この記事は、インフラやSREの専門家ではない、すべてのWeb開発者の皆さんに向けたものです。インフラやSRE、監視(モニタリング)、オブザーバビリティという言葉や領域に馴染みがない方に「オブザーバビリティ」がどのように役に立つかお伝えし、オブザーバビリティの世界に興味を持っていただくために書きました。
でも、その本質的な価値と、それが日々の開発業務をどう変えるのかをご理解いただけるよう、専門用語を極力避け、具体的なイメージを交えながら解説していきます。
オブザーバビリティは本番環境の「デバッガー」
オブザーバビリティの隣接領域に監視(モニタリング)があります。「監視は、うちでもやっているよ」という方も多いでしょう。
「監視は継続的なテストである」というのは奥一穂さん(kazuho)の名言です。監視は本番環境での異常挙動 / パフォーマンス遅延 / ランタイムエラーなどを検出して、開発者に報告してくれます。
何か変なことが起きたらデバッガーで実際にどのように動作したのかを確認したいのが人情です。本番環境において・本番のデータでプログラムがどのように動作したのかという「内部的な振る舞い」を知りたいですよね。このデバッガーに相当するのがオブザーバビリティです。
たとえばオブザーバビリティツールによって、本番環境での外部通信が追跡できます。プログラム上でのRDBMSへのクエリー発行内容と発行回数・所要時間、プログラムAからプログラムBへの通信内容とタイミング・所要時間、プログラムBでのKVS接続頻度と所要時間などが可視化できます。
このような動的な「振る舞い」を記録し、わたしたちの問いに答えられるようにすること、これがオブザーバビリティという能力・特性であり、パフォーマンスチューニングや本番環境でのデバッグを可能にする鍵です。
なぜ「開発者」にオブザーバビリティを気にしてほしいのか
「それはインフラ担当者やSREの仕事でしょう？」と思われるかもしれません。それは現場によるでしょう。良し悪し/適不適はここでは置いておきます。わたしが断言したいのは、オブザーバビリティが高くなって助かる / 捗るのは開発者とマネージャーだと言うことです。
思い描いていた・予定していたシーケンス図は、本番環境で本当にその通りに動いているでしょうか？オブザーバビリティの代表格である「トレース」を使うと、この設計時の想定と、本番環境での現実の動作との「答え合わせ」ができるようになります。
これは画期的ですね。いままで「こうなっているはず」とまでしか言えなかったのが「こうなっていることが実際に確認できた」となります。
コードを書いた / 承認した身として責任を果たすために、これほど頼りがいのある裏付けはありません。
オブザーバビリティは、開発者に「自分の仕事の結果に対する、解像度の高いレンズ」を与えてくれます。これは、より良い設計、より効率的なコード、トレードオフの答え合わせ、そして何よりユーザーにとって価値のあるプロダクト開発へと繋がっていきます。
なぜ「マネージャー層」にオブザーバビリティを気にしてほしいのか
プロダクト開発は基本的に一発モノの積み重ねですから、不確実性の塊です。その不確実性をコントロールしつつアウトプットを出してアウトカムを得ていくのがマネージャーの腕の見せ所なわけですが、言うは易し行うは難しで大変難易度が高いですよね。
特に不具合対応やパフォーマンスチューニングは、かけた時間と成果の期待値が読みづらいものです。しかし「重要だが緊急でない」を後回しにして大事故になる例は枚挙に暇がありません。
しかしだからといって無尽蔵に開発リソースを投入することもできません。そこでデータが欲しいわけです。適切なデータがあると、不確実性を抑制することができますよね。
システムやチームがオブザーバビリティを獲得することで、チームはデータをもとにトラブルシューティングを着実に前にすすめることができるようになり、またパフォーマンスチューニングの投入コストと期待値の目安が立てやすくなります。
オブザーバビリティはマネージャーを支えて、チームに秩序と安心をもたらすのです。
ようこそ!オブザーバビリティの世界へ(インフラ用語は少なめに)
「面白そうだけど、何から始めたらいいかわからない」
「DatadogとかNew Relicとか、ツールが難しそう…」
ご安心ください。オブザーバビリティは高価なツールがなくても始められます。実はクラウドサービス付属のツールでも始めることができるのです。またツールの全てをマスターする必要はありません。大切なのは、まず「何が見えるようになると、何が嬉しいのか」を把握することです。
たとえば、オブザーバビリティツールが提供してくれる、このような可視化グラフを見たことはありますか？
- トレース / 分散トレーシング (ウォーターフォール): ユーザーの一つのリクエストが、システム内部をどのように渡り歩いたかを可視化したものです。想定外のDB接続クエリー発行や外部連携などが発見できます。まさにシーケンス図の「答え合わせ」です
- ヒートマップ: レスポンスタイムの「分布図」です。たとえば「平均応答時間が3秒だと思っていたけれど、実は応答時間1秒と5秒に集中していて、約半分のユーザーにとっては応答時間は5秒だった」といった事実を浮かび上がらせることができます
- サービスマップ: システム全体の「相関図」です。どのサービスが、どのデータベースやAPIと、どれくらいの頻度で通信しているか一目でわかります。想定外の矢印が伸びていれば、あるいはそれが想定外の量や回数であれば、そこがパフォーマンス問題の隠れた原因かもしれません
これらの可視化表現は、わたしたちの「推測」を「確信」に変える強力な武器です。
最初の一歩を応援するガイドブックをご用意しました
この記事ではオブザーバビリティの世界に興味を持っていただくべく開発者やマネージャー層にとっての嬉しさを紹介しました。
とはいえ、ここでご紹介したのは、オブザーバビリティのほんの入り口だけです。
「他にもよくわからないグラフがあるんだよね」
「ログやメトリクス、トレースって、結局何なの？」
「チームで始めるにはどういうステップを踏めばいいの？」
そんな皆さんのために、インフラの専門用語を少なめにした、Web開発者の視点からオブザーバビリティの基本を解説した入門ガイドを作成しました。
▼『インフラ用語少なめのオブザーバビリティ入門ガイド』を無料でダウンロードする
このガイドでは、以下のような内容を豊富な図解と共に詳しく解説しています。
- よく目にする11種類のグラフの基本的な意味と読み解き方
- ウォーターフォール、ヒートマップ、サービスマップ、ヒストグラム、フレイムグラフなど
- オブザーバビリティを支える基本的な仕組みの入門的な解説
- 分散トレーシング、Logs to Metricsなど
- 「推測」から「確信」のサイクルを回し、チームの開発文化を変えていくための具体的なヒント
特定のツールに依存しない普遍的な知識なので、あなたのチームがどんな環境であっても必ず役立つはずです。
データという強力な武器を手に入れ、日々の開発をもっと創造的で、確信に満ちたものにしませんか？このガイドが、そのための確かな一歩となることを願っています。
