シナリオ:Kai がサービスアップデートの上流と下流の依存関係を調べる 🔗
以下のシナリオでは、架空のeコマース企業であるButtercup Gamesの例を取り上げています。
Buttercup Games のサイト信頼性エンジニア(SRE)である Kai は、Kubernetes 環境で checkoutservice
アプリケーションサービスのアップデートを展開する責任者です。彼らは、 checkoutservice
の上流と下流の依存関係をすべて把握して、依存するチームに通知できるようにしたいと考えています。
Kai はまず自分たちのチームのアーキテクチャ図をチェックしますが、それが古くなっていることに気づきます。この図には、Kai のチームが最近追加したサービスが欠けているだけでなく、異なる言語やフレームワークにわたる包括的なサービスの依存関係も示されていません。
これはネットワークの問題であるため、Kai は次に Splunk Infrastructure Monitoring の Network Explorer を使用してサービスの依存関係を調査しようとします。Network Explorer のネットワークマップは、各サービスで使用されている言語やフレームワークに関係なく、ネットワークトラフィックに基づいてすべてのサービスを完全にグラフィカルに表示します。これはまさに Kai が探していたものでした。
Kai は checkoutservice
サービスを選択すると、すぐに checkoutservice
の上流と下流のすべての依存関係をドリルダウン表示します。
Network Explorer のネットワークマップを探索することで、Kai は、更新されるサービスのすべての依存関係を理解するために必要なコンテキストを得ることに成功した。この知識により、Kaiは依存関係にあるチームに間近に迫ったアップデートを通知できるようになりました。
さらに詳しく 🔗
Network Explorerのネットワークマップについては、ネットワークマップによるサービスの依存関係の監視 を参照してください。