APMとオブザーバビリティ：なぜあなたの定義は間違っているのか
著者: Leon Adato
翻訳: 逆井 晶子
この記事は米Catchpoint Systems社のブログ記事「APM vs observability: why your definitions are broken」の翻訳です。
Spelldataは、Catchpointの日本代理店です。
この記事は、Catchpoint Systemsの許可を得て、翻訳しています。
最近、アプリケーションパフォーマンス管理（Application Performance Management,APM）とオブザーバビリティ（o11y）について、それらがどのように重なり合い、競合し、対立するかについて意見を求められました。
私は、意見を求められた何人かのうちの一人だったため、当然のことながら、私の考えのすべてが元の記事に反映されたわけではありませんでした。
とはいえ、せっかく綴った言葉たちをこのまま埋もれさせてしまうのは惜しい気がして、ここで改めて整理してみることにしました。
元の記事のQ&A形式は避けて、これらのアイデアが少しでも自然に伝わることを願っています。
また、これはAPMdigest向けの回答であり、「APMとオブザーバビリティの対比」に関する議論であることも指摘しておく必要があります。
そのため、私の回答はこれら2つの技術に焦点を当てており、Internet Performance Monitoring（IPM）の素晴らしさやCatchpointが提供するさまざまな利点について詳しく説明するものではありません。
モニタリング2.0と呼ぶのはやめましょう
はっきりと言わせてもらいますが、APMとo11yに関して市場には多くの（編集者の許可があれば「蔓延する」と言いたい）混乱があります。
そのほとんどの混乱は、ベンダーが自社の都合（および製品）に合わせて用語を調整したことによる自業自得の結果だと残念ながら言わざるを得ません。
実際、オブザーバビリティとは何かを平易な言葉で説明するよう求められた際、私の以前の会社のある役員は記憶に残る（そして恐ろしい）返答をしました。
モニタリングはログを目視で確認すること。
オブザーバビリティは、お客様のニーズに応えるものだ。
そう、彼に言えるのはそれが限界でした。
彼はその発言以上のことをまったく理解していませんでした。
この例は、業界内の誤解がいかに蔓延しているかを浮き彫りにするだけでなく、人々が技術の定義をいかにして時に完全に創作するほどまでに脚色しているかを示しています。
APMやオブザーバビリティに限らずよくある話ではありますが、事態をややこしくする要因ではあるでしょう。
APMの力ずくのデータ収集
私の（控えめではない）意見ですが、APMとはその名のとおり、アプリケーションのパフォーマンスを、特定の視点（あるいは複数の場所）から把握するために行う一連の操作を指します。
たとえば、ある地点からアプリケーションの特定の部分に対してコマンドやユーティリティを実行し、その結果を測定可能なデータとして取得する、という具合です。
こうした一連の仕組み―コマンド、複数地点での実行、データの集約―は、APMベンダーが提供するソリューションにおける「機能」としてまとめられています。
APMは特定の操作の集合といえますが、すべてのAPMソリューションが、その全機能やツール、ユーティリティ、コマンドを備えているわけではありません。
各ソフトウェア製品と同様に、各APMツールも、重視する要素と最小限に留める、あるいは排除する要素とがあります。
オブザーバビリティ：「尋ねなくてもわかる」技術
さて、NOC（Network Operations Center）の話に戻しましょう。
オブザーバビリティは、特定のアクションやユーティリティ、ツール、機能といったものというより、むしろ“哲学”に近い概念です。
その本質は、どんなツールを使うかではなく、アプリケーション自体が自律的に状態を報告できるかどうか、という点にあります。
つまり、わざわざ指示を出したり、確認したり、テストを実行したりする必要がないということです。
また、カーディナリティ（データポイントの一意性）に関する考え方や、既知のイベントと予測不可能なイベントの違いなどの概念や理想も含まれるようになっています。
例えるなら、APMは船の一種です。
ヨットかもしれないし、戦艦かもしれないし、手こぎボートかもしれません。
一方でオブザーバビリティは、海そのものやそのときの天候を超えて、「それが湖なのか、急流なのか、外洋なのか、あるいは極地なのか」といった環境全体の“文脈”にあたります。
なぜ従来のAPMは網での漁に感じるのか
私が言いたいのは、従来の定義におけるAPMではもはや不十分であるということです。
APMがGartnerのmagic quadrantのカテゴリになった当時から、アプリケーションの世界は大きく変化しました。
現代のアプリケーション（Webでもモバイルでも）は、APIやマイクロサービスで構成され、地理的にもクラウドプラットフォーム的にも分散されたシステムの集合体となっています。
多くのAPMソリューションは、必要なツールの範囲や洞察の深さを備えていません。
APMにおける「効果的なオブザーバビリティ」（つまり哲学としてのオブザーバビリティ）の実現には、システム全体の理解が必要です。
この能力は、今日多くのAPMツールが理解する「アプリケーション」の枠を超えています。
ここで登場するのが、より新しいカテゴリであるIPMおよび／またはデジタルエクスペリエンスマネジメント（Digital Experience Management,DEM）です。
マイクロサービスの迷路を超えて、実際のユーザーの苦痛を見抜く
IPM / DEMは、APMのソリューションセットに階層を追加します。
これには、トレースによるコードレベルの洞察や、ネットワーク層（特にBGPおよびAS）とネットワーク認識が含まれます。
なぜなら、問題の原因は、悪いコードのデプロイである可能性もあれば、プロバイダのネットワークを経由する中で発生する不適切なルートにあるかもしれないからです。
それは、プロバイダ自身、あるいはその上流のプロバイダ、さらにはそのさらに上流のプロバイダにまで及ぶこともあります。
ただし、IPMは比較的新しい用語であるため、私たちが責任を持って、使用するツール、技術、テスト、手法にとらわれない形で、明確かつベンダーに依存しない方法で定義する必要があります。
これは、テレメトリの収集における視点そのものを根本から見直すという発想に基づいています。
この考えについては、いずれ改めて詳しく掘り下げるつもりですが、ひとまずここではこう締めくくります。
モニタリングがまだ曖昧だった時代、私たちはユーザー体験を直接的かつ決定的に示すデータを持っていませんでした。
手元にあったのは、ユーザーの画面の前で何が起きているのかを推測するための、より低レベルなメトリクスだけでした。
トレースの登場と、RUMやシンセティックモニタリングのような手法が、本番環境で現実的に使えるようになったことで、それは大きく変わりました。
しかし、IT技術者向けのプレゼンテーション（ダッシュボード、レポート、アラート）は、それに合わせて進化していません。
今でも、ユーザー体験を推測するための低レベルなデータが表示されるケースがほとんどです。
IPMは（APMとは異なり）その焦点を大きく転換するものです。
ユーザー体験を中心に据え、それが影響を受けたときにのみ、根本原因を探るためにより深くデータを掘り下げるというアプローチです。
APMとIPMでモニタリングできる内容を比較してみましょう。
脚注／補足
＊結局、彼はその言葉をしっかり紛れ込ませてきましたね――編集者より