コンテナのスケーリングの技術: 監視

コンテナのスケーリングは、サービスの前にプロキシを配置してそのまま放置するだけではありません。 スケーリングには配布以上のものが必要であり、急速に変化するコンテナの世界では、スケーリングを確保するために、再試行、サーキットブレーカー、検出、配布、監視という 5 つの異なる機能が必要です。

コンテナのスケーリングに関するこの投稿では、監視について詳しく説明します。

監視

監視。 車の運転速度から冷蔵庫の中身まで、あらゆるものがあらゆることを聞いていたり見たりしているような時代において、この言葉は多くの人にとって不快なものです。 代わりに「可視性」という言葉を使うこともできますし、実際によく使いますが、その意味論的な詭弁によって私たちのやっていることが変わるわけではありません。私たちは注意深く見守っているのです。

スケールに関するすべては監視、つまりリクエストを分散しているリソースの状態を知ることに依存します。 リソースがクラッシュしたか、最近シャットダウンされたために「デッドゾーン」にリクエストを送信することは、コンセントのない袋小路に曲がるようなものです。 それは時間の無駄です。

監視にはさまざまな種類があります。 ネットワーク層では、 pingによる「連絡が取れるか」の監視が行われます。 TCP 接続の「家にいますか」監視があります。 そして、HTTP リクエストの「ドアに応答していますか」という質問があります。 さらに、「コーヒーを飲みましたか」というモニタリング機能があり、サービスが正しく応答しているかどうかを判断します。

サービスの健全性と実行状況を確認するだけでなく、パフォーマンスの監視も行います。 応答時間に基づいてリクエストを分散している場合、サービスがどれだけ速く応答したかが重要です。 パフォーマンスの突然の変化は問題を示している可能性があり、それは歴史的に重要なデータであり、監視する必要があることを意味します。

アクティブ モニタリング (実際のリクエストを送信します)、合成モニタリング (架空のリクエストを送信します)、パッシブ モニタリング (実際のリクエストに何が起こるかをただ座って見守る) があります。 それぞれに長所と短所があり、いずれも有効な監視方法です。 重要なのは、プロキシがステータスを判断できることです。アップしているか、ダウンしているか、エルビスと一緒に建物から出たかなどです。

到達可能性、可用性、パフォーマンスはすべて監視の側面であり、スケーラビリティを確保するために必要です。 つまり、監視だけではなく、負荷分散プロキシがリクエストを送信する可能性のある各リソースのステータスに関する最新情報を確実に取得することが重要です。

コンテナの性質と、それらをマイクロサービス ベースのアーキテクチャと組み合わせる傾向について考えると、監視がすぐに悪夢のような提案になることがわかります。 これは、コンテナ環境内での負荷分散の最も一般的なモデルがフォワード (およびサイドカー) プロキシであるためです。 どちらの場合も、すべてのノードが、リクエストを送信する必要がある可能性のあるすべてのリソースの健全性と状態を認識している必要があります。 つまり、ほぼすべてのリソースを監視することになります。

特定のリソースが、そのステータスに関して 15 または 20 のフォワード プロキシに応答するために自身の限られたリソースを費やすのは、あまり効率的ではないことは想像に難くありません。 このようなモデルでの監視は、パフォーマンスと容量の両方に重大な悪影響を及ぼし、スケーリングがさらに困難になります。

コンテナの場合ほど、監視が規模に大きな影響を与えたことはかつてありませんでした。

しかし、上で述べたように、これは非常に重要です。なぜなら、できれば「行き止まり」のリソースで時間を無駄にしたくないからです。

必要な監視の課題は、サービス メッシュがコンテナ環境内の将来のスケール モデルとして支持 (および牽引) され続けている理由の 1 つです。

監視はオプションではありませんが、負担になるものでもあってはならないからです。