分散およびマイクロサービス展開の監視

多くのシステムの動作における最も根本的な変更のいくつかは、ソフトウェアが設計できる新しい抽象化レイヤーの爆発によるものです。 コンテナテクノロジーは、展開されたソフトウェアと基盤となるオペレーティングシステムとの関係を変更しました。 コンテナにデプロイされたアプリケーションは、外の世界、他のプログラム、およびホストオペレーティングシステムと、従来の方法でデプロイされたアプリケーションとは異なる関係を持ちます。 カーネルとネットワークの抽象化は、チェックするレイヤーに応じて、オペレーティング環境の異なる理解につながる可能性があります。

このレベルの抽象化は、一貫した展開戦略を作成し、ホスト間での作業の移行を容易にし、開発者がアプリケーションのランタイム環境を厳密に制御できるようにすることで、多くの点で非常に役立ちます。 ただし、これらの新しい機能は、複雑さを増し、各プロセスを駆動するリソースとのより遠い関係を犠牲にします。

新しいパラダイム間の共通点の1つは、タスクを調整および達成するための内部ネットワーク通信への依存度の増加です。 以前は単一アプリケーションのドメインであったものが、情報の調整と共有を必要とする多くのコンポーネントに広がっている可能性があります。 これには、通信インフラストラクチャと監視の面でいくつかの影響があります。

まず、これらのモデルは小規模で個別のサービス間の通信に基づいて構築されるため、ネットワークの健全性はこれまで以上に重要になります。 従来のよりモノリシックなアーキテクチャでは、タスクの調整、情報の共有、および結果の整理は、通常、通常のプログラミングロジックを備えたアプリケーション内で、または比較的少量の外部通信を介して行われました。 対照的に、高度に分散されたアプリケーションの論理フローは、ネットワークを使用して同期し、ピアの状態を確認し、情報を渡します。 ネットワークの健全性とパフォーマンスは、以前よりも多くの機能に直接影響します。つまり、正しい動作を保証するには、より集中的な監視が必要です。

ネットワークはこれまで以上に重要になりましたが、参加者の数が増え、個々の通信回線が増えているため、ネットワークを効果的に監視することはますます困難になっています。 少数のアプリケーション間の相互作用を追跡する代わりに、同じ機能を確保するために、数十、数百、または数千の異なるポイント間の正しい通信が必要になります。 複雑さの考慮に加えて、トラフィック量の増加は、利用可能なネットワークリソースに追加の負荷をかけ、信頼性の高い監視の必要性をさらに悪化させます。

上記では、現代のアーキテクチャが多くのより小さな個別のコンポーネント間で作業と機能を分割する傾向を渡すことに言及しました。 これらの設計は、明確さとわかりやすさを特に価値がありますが、ますますわかりにくいため、監視の状況に直接影響を与える可能性があります。

正常に機能するためには、より堅牢なツールと計装が必要です。 ただし、特定のタスクを完了する責任は断片化され、さまざまなワーカー間（潜在的に多くの異なる物理ホスト上）に分割されるため、パフォーマンスの問題やエラーの責任の所在を理解することは困難です。 多くが可能な候補のプールから選択される多数のコンポーネントに関係する要求と作業単位は、従来のメカニズムを使用して要求パスの視覚化または根本原因分析を非実用的にすることができます。

従来の監視の適応におけるさらなる苦労は、短命または一時的なユニットを賢明に追跡することです。 関心のあるユニットがクラウドコンピューティングインスタンス、コンテナインスタンス、またはその他の抽象化であるかどうかにかかわらず、これらのコンポーネントは、従来の監視ソフトウェアによって行われたいくつかの仮定に違反することがよくあります。

たとえば、問題のあるダウンしたノードとスケールダウンのために意図的に破壊されたインスタンスを区別するために、監視システムは、以前必要だったよりもプロビジョニングおよび管理レイヤーをより深く理解する必要があります。 最近の多くのシステムでは、これらのイベントが頻繁に発生するため、毎回監視ドメインを手動で調整することは実用的ではありません。 これらの設計では展開環境がより迅速に移行するため、監視レイヤーは価値を維持するために新しい戦略を採用する必要があります。

多くのシステムが直面しなければならない1つの質問は、破壊されたインスタンスからのデータをどうするかです。 ワークユニットは、変化する要求に対応するために迅速にプロビジョニングおよびプロビジョニング解除できますが、古いインスタンスに関連するデータをどう処理するかについて決定する必要があります。 基礎となるワーカーが使用できなくなったからといって、必ずしもすぐにデータの価値が失われるわけではありません。 毎日数百または数千のノードが出入りする可能性がある場合、短命のインスタンスの断片化されたデータからシステムの全体的な稼働状態に関するナラティブを最適に構築する方法を知ることは困難です。

サービス数の増加による総トラフィック量の増加は、考えるべき最も簡単な問題の1つです。 新しいアーキテクチャに起因する転送数の増加を超えて、監視アクティビティ自体がネットワークを行き詰まらせ、ホストリソースを盗み出す可能性があります。 ボリュームの増加に最適に対処するには、監視インフラストラクチャをスケールアウトするか、使用するデータの解像度を下げることができます。 どちらのアプローチも検討する価値がありますが、より拡張性があり広く有用なソリューションであるため、2番目のアプローチに焦点を当てます。

データのサンプリングレートを変更すると、システムがホストから収集する必要があるデータの量を最小限に抑えることができます。 サンプリングは、メトリックの新しい値を要求する頻度を表すメトリックコレクションの通常の部分です。 サンプリング間隔を長くすると、処理しなければならないデータ量が減りますが、データの解像度（詳細レベル）も下がります。 最小の有効解像度を注意深く理解する必要がありますが、データ収集率を調整すると、システムが適切にサービスを提供できる監視クライアントの数に大きな影響を与える可能性があります。

より低い解像度から生じる情報の損失を減らすための1つのオプションは、ホスト上で同じ頻度でデータを収集し続けますが、ネットワーク上で転送するためにより消化しやすい数にコンパイルすることです。 個々のコンピューターは、メトリック値を集​​約および平均化し、サマリーを監視システムに送信できます。 これにより、多数のデータポイントが依然として考慮されるため、精度を維持しながらネットワークトラフィックを削減できます。 これは、ネットワークへのデータ収集の影響を軽減するのに役立ちますが、ホスト内でこれらの数値を収集することに伴う負担をそれ自体では役立たないことに注意してください。

前述のように、従来のシステムと最新のアーキテクチャの主な差別化要因の1つは、要求の処理に関与するコンポーネントの内訳です。 分散システムおよびマイクロサービスでは、何らかのタイプのスケジューリング層または調停層を介して、作業単位がワーカープールに与えられる可能性がはるかに高くなります。 これは、監視を中心に構築できる自動化されたプロセスの多くに影響を及ぼします。

交換可能なワーカーのプールを使用する環境では、ヘルスチェックとアラートポリシーが成長して、監視対象のインフラストラクチャと複雑な関係を持つようになります。 個々の労働者のヘルスチェックは、欠陥のあるユニットを自動的に廃止し、リサイクルするのに役立ちます。 ただし、大規模な自動化を実施している場合、単一のWebサーバーが大規模なプールで障害を起こしても大した問題ではありません。 システムは、正常なユニットのみがリクエストを受信するアクティブなプールにあることを確認するように自己修正します。

ホストのヘルスチェックは欠陥のあるユニットを検出できますが、プール自体のヘルスチェックはアラートに適しています。 現在のワークロードを満たすプールの能力は、個々のワーカーの能力よりもユーザーエクスペリエンスに大きく影響します。 正常なメンバーの数、プール集約の待ち時間、またはプールエラー率に基づくアラートは、自動的に軽減するのが難しく、ユーザーに影響を与える可能性が高い問題をオペレーターに通知できます。

一般に、分散システムの監視層は、展開環境とプロビジョニングメカニズムをより完全に理解する必要があります。 自動化されたライフサイクル管理は、これらのアーキテクチャに関与する個々のユニットの数のため、非常に貴重になります。 ユニットが未加工のコンテナ、オーケストレーションフレームワーク内のコンテナ、またはクラウド環境の計算ノードであるかどうかに関係なく、ヘルス情報を公開し、イベントをスケーリングして応答するコマンドを受け入れる管理レイヤーが存在します。

プレイ中のピースの数は、失敗の統計的可能性を高めます。 他のすべての要因が等しい場合、これらの問題に対応して軽減するには、より多くの人間の介入が必要になります。 監視システムは障害とサービスの低下を特定する役割を担っているため、プラットフォームの制御インターフェースに接続できれば、これらの問題の大部分を軽減できます。 監視ソフトウェアによってトリガーされる即時の自動応答は、システムの運用状態を維持するのに役立ちます。

監視システムと展開プラットフォームのこの密接な関係は、他のアーキテクチャでは必ずしも必要ではなく、一般的でもありません。 しかし、自動化された分散システムは、事前設定されたルールと観察されたステータスに基づいてスケーリングおよび調整する能力を備えた自己調整を目指しています。 この場合の監視システムは、環境の制御とアクションを実行するタイミングの決定において中心的な役割を果たします。

監視システムがプロビジョニング層の知識を持たなければならないもう1つの理由は、一時的なインスタンスの副作用に対処するためです。 稼働中のインスタンスで頻繁に離職が発生する環境では、監視システムは、サイドチャネルからの情報に基づいて、アクションが意図的に行われたかどうかを把握します。 たとえば、プロビジョニング担当者からAPIイベントを読み取ることができるシステムは、サーバーが関連イベントなしで突然応答しなくなった場合と、オペレーターが意図的にサーバーを破棄した場合の反応が異なります。 これらのイベントを区別できると、基盤となるインフラストラクチャが頻繁に変更される場合でも、監視が有用で、正確で、信頼できるままになります。

高度に分散されたワークロードの最も困難な側面の1つは、さまざまなコンポーネント間の相互作用を理解し、根本原因分析を試みる際の責任を分離することです。 単一の要求が多数の小さなプログラムに触れて応答を生成する場合があるため、ボトルネックやパフォーマンスの変化がどこから発生したかを解釈するのは困難です。 各コンポーネントが遅延と処理のオーバーヘッドにどのように寄与するかについてより良い情報を提供するために、分散トレースと呼ばれる技術が登場しました。

分散トレースは、各コンポーネントにコードを追加することで機能するシステムのインストルメントへのアプローチであり、サービスを通過するリクエスト処理を明らかにします。 各リクエストには、インフラストラクチャのエッジで一意の識別子が付与され、タスクがインフラストラクチャを通過するときに渡されます。 次に、各サービスはこのIDを使用して、リクエストを最初に検出したときと次の段階に渡したときのエラーとタイムスタンプを報告します。 要求IDを使用してコンポーネントからレポートを集約することにより、正確なタイミングデータを含む詳細なパスをインフラストラクチャで追跡できます。

この方法を使用して、プロセスの各部分に費やされる時間を把握し、遅延の深刻な増加を明確に特定できます。 この追加のインスツルメンテーションは、メトリックコレクションを多数の処理コンポーネントに適合させる方法です。 x軸の時間とともに視覚的にマッピングすると、結果の表示には、異なるステージ間の関係、各プロセスの実行時間、および並行して実行する必要があるイベント間の依存関係が表示されます。 これは、システムの改善方法と時間の消費方法を理解するのに非常に役立ちます。

システムの問題に確実に対応できるようにするための最初のステップは、問題がいつ発生するかを知ることです。 https://www.digitalocean.com/community/tutorials/gathering-metrics-from-your-infrastructure-and-applications [インフラストラクチャおよびアプリケーションからメトリックを収集]のガイドで、4つのゴールデンシグナル監視インジケータを導入しましたGoogle SREチームによって、追跡するのに最も重要であると特定されました。 4つの信号は次のとおりです。

これらは、システムをインスツルメントするときに開始するのに最適な場所ですが、高度に分散されたシステムでは通常、監視する必要のあるレイヤーの数が増えます。 基盤となるインフラストラクチャ、オーケストレーションプレーン、およびワーキングレイヤーには、それぞれ重要な変更を特定するための思慮深いアラートを設定した堅牢な監視が必要です。 アラート条件は、プラットフォームに固有のはかない要素を説明するために複雑になる場合があります。

システムが異常を特定し、スタッフに通知したら、チームはデータの収集を開始する必要があります。 この手順を続行する前に、影響を受けるコンポーネント、インシデントの開始時期、およびトリガーされた特定のアラート条件を理解する必要があります。

インシデントの範囲を理解し始めるための最も便利な方法は、高いレベルから始めることです。 システム全体から情報を収集して一般化するダッシュボードと視覚化を確認して、調査を開始します。 これにより、相関する要因をすばやく特定し、ユーザーに直接的な影響を理解できます。 このプロセス中に、さまざまなコンポーネントおよびホストからの情報をオーバーレイできるはずです。

この段階の目標は、アイテムの精神的または物理的なインベントリの作成を開始して、より詳細に確認し、調査の優先順位付けを開始することです。 異なる層を横断する関連する問題のチェーンを特定できる場合、最下層が優先されます。基礎層の修正により、より高いレベルで症状が解決されることがよくあります。 影響を受けるシステムのリストは、緩和策が展開されたときに修正を検証するための場所の非公式のチェックリストとして機能します。

インシデントの妥当な高レベルのビューが得られたと感じたら、リストのコンポーネントおよびシステムを優先順に詳細にドリルダウンします。 個々のユニットに関する詳細なメトリックは、障害のルートを最も責任のあるリソースまで追跡するのに役立ちます。 より詳細なダッシュボードとログエントリを確認しながら、影響を受けるコンポーネントのリストを参照して、システムを介した副作用の伝播方法をさらに理解してください。 マイクロサービスの場合、相互依存するコンポーネントの数は、問題がより頻繁に他のサービスに波及することを意味します。

この段階では、最初のインシデントの原因となっているサービス、コンポーネント、またはシステムを分離し、発生している特定の問題を特定することに焦点を当てています。 これは、新しくデプロイされたコード、物理インフラストラクチャの障害、オーケストレーションレイヤーの間違いやバグ、またはシステムが適切に処理できなかったワークロードの変更などです。 何が起こっているのか、そしてその理由を診断することで、問題を軽減し、運用状態を回復する方法を発見できます。 この問題を解決して他のシステムで報告された問題を修正できる程度を理解することで、緩和タスクの優先順位付けを継続するのに役立ちます。

詳細を特定したら、問題の解決または軽減に取り組むことができます。 多くの場合、より多くのリソースを提供するか、ロールバックするか、トラフィックを別の実装に再ルーティングすることにより、サービスを復元するための明白で迅速な方法があります。 これらのシナリオでは、解決は3つのフェーズに分けられます。

多くの分散システムでは、冗長性と高可用性コンポーネントによってサービスが迅速に復元されますが、冗長性を復元したり、システムを劣化状態から回復するには、バックグラウンドでより多くの作業が必要になる場合があります。 以前に測定スティックとしてコンパイルされた影響を受けるコンポーネントのリストを使用して、最初の緩和策がカスケードサービスの問題を解決するかどうかを判断する必要があります。 監視システムの高度化に伴い、プロビジョニングレイヤーにコマンドを送信して障害のあるユニットの新しいインスタンスを起動したり、動作不良のユニットを循環させたりすることで、これらの完全な回復プロセスの一部を自動化することもできます。

最初の2つのフェーズで可能な自動化を考えると、運用チームにとって最も重要な作業は、多くの場合、イベントの根本原因を理解することです。 このプロセスから収集した知識を使用して、新しいトリガーとポリシーを開発し、将来の発生を予測し、システムの反応をさらに自動化することができます。 監視ソフトウェアは、多くの場合、各インシデントに対応して新しい機能を獲得し、新たに発見された障害シナリオから保護します。 分散システムの場合、分散トレース、ログエントリ、時系列の視覚化、最近の展開などのイベントにより、イベントのシーケンスを再構築し、ソフトウェアと人間のプロセスを改善できる場所を特定できます。

大規模な分散システムに固有の特定の複雑さのため、重要なイベントの解決プロセスをシステムを学習および微調整する機会として扱うことが重要です。 関連する個別のコンポーネントと通信パスの数は、複雑さの管理を支援する自動化とツールに大きく依存しています。 これらのコンポーネントの応答メカニズムとルールセット（およびチームが遵守する運用ポリシー）に新しいレッスンをエンコードすることは、監視システムがチームの管理フットプリントをチェックするための最良の方法です。