最新ネットワーク・テレメトリー実践ガイド (Japanese Edition)

第6章 ネットワークテレメトリの活用と 他のレイヤーとの連携

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

「もし手持ちの道具がハンマーだけなら……」というマズローの格言が示す通り、私たちの経験やツールは、問題解決へのアプローチに関する視点を形作る。 これは技術の世界でも例外ではない。私たちは（第4章で述べたように）単一の要素、あるいはアプリケーションスタックの単一のレイヤー（第5章で取り上げたネットワーク層であれ、それ以外のレイヤーであれ）に過度に集中してしまう罠に陥りがちだ。

実のところ、実世界の問題のほとんどは、コードからサーバ、データベースやAPIといったサブシステム、さらにはネットワークに至るまで、アプリケーションの複数の側面が関わっている。かつてのニューヨーク・テレフォンの広告を借りれば、「すべてはつながっている」のだ。

この章では、ネットワークテレメトリが、一般的に可観測性解決策の一部と見なされているプラットフォームから提供されるデータをどのように補完し、強化するかについて、いくつかの例を挙げて見ていく。これには、トレーシング、アプリケーションロギング、実ユーザ監視などのツールやテクニックが含まれる。

第4章や第5章と同様、ここではフルスタック・可観測性を実現する方法を網羅的に列挙することが目的ではない。重要なのは、ネットワーク監視が（依然として）重要であり、アプリケーションファーストやアプリケーション中心のユースケースと見なされがちなシナリオにおいても重要であるという点だ。

さっそく見ていこう！

（Meta）ユースケース1：自分のマシンでは動かない

これを「メタユースケース」と呼ぶのは、これ以降に続くほぼすべて（そして正直なところ、前の章にある多くの例にも）当てはまるからだ。問題は、すべての場所のすべてのユーザに発生しているのか？ それとも、限られた場所の多くのユーザに発生しているのか？ あるいは、単一の場所の少数のユーザにのみ影響しているのか？

より明確に言えば、パフォーマンス、稼働時間、可用性を、十分な数の場所からテストしているか。そうすることで、障害が地理的に広範囲に及んでいるのか、限られた地域や配信ポイントに局所化しているのか、あるいは単一（または少数の）ユーザによる固有の問題なのかを、信頼性を持って把握できるだろうか。その答えによって、トラブルシューティングのプロセスをどこから始めるか、またどの程度のレスポンスを期待できるかが大きく変わってくる。

単純な例として、ありふれたtracerouteを使ってみよう。自分のノートPCから実行しても、エンドユーザの体験は把握できない。同様に、アプリケーションをホストしている同じクラウドプロバイダーから実行すれば、クラウド内の局所的な問題はわかるかもしれないが、問題がインターネット上や遠隔先のネットワークにある場合、多くの場合、有益な情報は得られない。 また、同じCloudプロバイダーの別のリージョンや、単一のコロケーションプロバイダー（コロ）など、たった1か所から実行するだけでは、一般的に不十分だ。

traceroute（ひいては他のほとんどの監視手法）を包括的なものにするには、すべてのユーザの所在地からテストを行う必要がある。それは明らかに現実的ではないが、その目標に近づけば近づくほど良い。テストは、複数の地理的場所、複数のISPネットワーク内、そしてユーザベースを代表する複数の「ラストマイル」の場所から実行すべきだ。 ...