分散クラウドアプリケーションをマップ化するアプローチの比較

アプリケーションマップは、分散アプリケーションのコンポーネントとネットワーク、またはプロセス間の相互作用をトポロジーで表現したものだ。AppDynamis、OpenTracing、Netsilなどの様々なツールで採用されたアプリケーションマップのアプローチの概要が最新の記事で紹介されている。

アプリケーションマップは、コンポーネントを表す頂点と、コンポーネント間の相互作用を表す辺のグラフによって描かれる。コンポーネントは（同一マシンにおける）プロセスや、コンピューターインスタンス、あるいはその組合せでもよい。前者であれば辺はプロセス間通信（IPC）の相互作用を表し、後者であればネットワーク越しの通信となる。アプリケーションマップの重要な特徴はインスタンスのグループ化、アプリケーションレベルの詳細、そしてエラー率のような重要なメトリクスの可視化だ。

なぜアプリケーションマップが重要なのだろうか？それは、アプリケーションマップがコンポーネントの依存性を可視化し、インシデント対応時に根本原因の救命に役立ち、モニタリングとアラート通知のクリティカルパスを特定し、データドリブンなキャパシティ計画に役立ち、起こりうるセキュリティ課題を特定してくれるからだ。

記事はアプリケーションマップの2つのアプローチを要約している。それは静的なものと動的なものであり、動的なものについて詳細に説明されている。マッピングのソフトウェアは、分散型アプリケーションにおいて様々なコンポーネントがアプリケーションマップにたどり着くまでのリクエストのパスをトレースする。

Application Perfomance Management（APM）などのエンドツーエンド（E2E）のトレースソフトウェア、およびコーディング補助のSDKは、いずれもローカルソフトウェアエージェントやアプリケーション内のコード変更が必要だ。AppDynamics、Dynatrace、New Relicは、マップを生成するためにコードプロファイリングを行いトランザクションパスを追跡する。新しい技術スタックの急増はAPMツールにとってのチャレンジであり、そうしたツールは新しいスタックへのサポートを継続的に追加していくひつようがある。OpenTracing、Datadog APM、AWS X-Rayのようなトレース用のSDKは、リクエストにヘッダーを注入することで様々なコンポーネント感の相関情報を収集する。ヘッダー内のユニークIDとメタデータはマップの構築に役立つ。

エンドツーエンドのトレースはリクエストの確実なパスをたどるのに役立つが、同時に大量のデータを生成し、統合の観点から邪魔になることもある。パフォーマンスの課題に関する兆候が示されることもない。ただしZipkinのように、パフォーマンスに関する洞察を提供しようとしているツールもある。

個別トレース（流入（Ingress）と流出（Egress）とも呼ばれる）は、ログファイルとOSレベルのトレースの価値を高める。この2つのデータ元は技術スタックと比較して変更される頻度が低く、安定した手法を提供している。この技術はネットワーク層で作用するため、E2Eの手法でトレースできないものも含め、ネットワーク越しに通信するコンポーネントであればマップ化できる。しかし、この手法の低レベルにおいては否定的な側面もある。あるリクエストのライフサイクルにおいて、特定のデータパケットがどこで発生したかというコンテキストを、このトレースでは明確にすることができない。このコンテキストを派生させるとアプリケーションソフトウェアの複雑な依存性を生んでしまう。この手法は暗号化された呼出しでは作用せず、データとビジネストランザクションを関連付けるために詳細なパケット検査が必要となる。