ログ、メトリクスなどを監視してパフォーマンスとセキュリティを向上

このシリーズの前回の記事 — DevSecOps におけるデータ収集のすべてのガイド— では、データ収集の重要性について説明しました。この記事では、可観測性における監視の役割、特にセキュリティ、パフォーマンス、信頼性に関連するものについて説明します。

監視は、本番環境で発生した問題や外れ値を検出するために不可欠であり、DevSecOps チームが重大な損害を引き起こす前に問題を特定して対処できるようにします。パフォーマンスの低下や疑わしいアクティビティを監視すると、潜在的な問題や攻撃を特定するためのアラートと自動応答が発生する可能性があります。

この記事では、モニタリングについて詳しく見ていき、いくつかのユース ケースとベスト プラクティスを提供し、オブザーバビリティを通じてモニタリングがセキュリティ、パフォーマンス、および信頼性を具体的にどのように向上させるかについて説明します。

可観測性における監視の役割は何ですか?

監視可能なシステムでは、ログ、メトリック、および分散トレースからデータを収集します。また、非常に小規模なシステムの場合は、手動でログを参照して検索し、メトリックをチャートとして視覚化し、問題を特定するためにトラフィックがシステムをどのように流れるかを示す図をトレースすることができますが、大規模になると、これでは十分ではありません.このデータを監視し、適切に警告する自動化されたプロセスである監視が必要です。 (監視とオブザーバビリティの違いに関するより詳細な処理については、このリソースを参照してください。)

企業では、このすべてのデータをフィルタリング、集約、強化、および分析するための自動化された方法が必要です。企業はまた、何か異常が検出されたときにアクションを実行するための自動化された方法を必要としています。自動化された応答により、担当チームに通知したり、修復アクションを直接実行したりすることさえできます。

医療などの他の分野では、患者のバイタル サインを監視することは、命を救う重要な活動です。ソフトウェア システムの監視は非常に似ており、ヘルス チェックを実行してさまざまなコンポーネントの状態について議論する際にも同じ方法論を使用します。

理論は十分なので、監視の具体的な例をいくつか見てみましょう。

可観測性を監視するユースケース

監視を利用する典型的な使用例を次に示します。

• Web アプリケーションは、多くの大規模な分散システムの主要部分であり、デジタル ファースト ビジネスの成功の鍵を握っています。コンテナー化された Kubernetes アプリケーションまたは単純に Web サーバーのログを監視して、過剰なエラー コード ( 4xxや5xxなど) が発生していないかどうかを確認することで、パフォーマンスと信頼性の問題が重大な問題になる前にチームが対処するのに役立ちます。
• インフラストラクチャ レベルでは、サーバーの CPU、メモリ、およびストレージを監視することが重要です。ほとんどの企業と同様に、システムがより多くの容量を割り当てることができるように、自動スケーリングを使用している可能性があります。プラットフォーム ログは、リソースがプロビジョニング、プロビジョニング解除、または再構成されたときなど、リソースに変更があったときにキャプチャされます。ただし、これらのリソース メトリックとログを監視すると、クォータと制限内で作業していることを確認するのに役立ち、リソースの計画と予算編成に関して組織に役立ちます。
• データストアは、ほとんどの大規模システムの中心です。データが失われたり、破損したり、利用できなくなったりすると、深刻な状況に陥ります。データを追跡するには、データベース接続、クエリ期間のメトリック、ディスク容量、バックアップ、およびエラー率を監視する必要があります。また、クエリが遅い、エラー率が高い、ディスク容量が少ないなど、想定範囲外の値が観測された場合は、データ ストアを理解し、アラートを設定する必要があります。データベースのログを設定して、接続、クエリ、およびフィールドやテーブルへの変更をキャプチャすることもできます。データベース ログを監視すると、パフォーマンスと信頼性を改善できる箇所だけでなく、悪意のある (または意図しない) 操作が実行されている場合のセキュリティも検出できます。

監視は、単純な条件 (「2 分以内にordersデータベースに対して 5 回以上のINSERTクエリ」など) を設定し、その条件が満たされたときにアラートを発するよりもはるかに複雑であることに注意してください。 1 日、1 週間、または 1 年の特定の時間にスパイクを引き起こす使用パターンで、季節性が影響している可能性があります。予期しない動作を検出する効果的な監視では、コンテキストが考慮され、過去のデータに基づいて傾向を認識できます。

このタイプのモニタリングは、特にオブザーバビリティ、モニタリング、およびセキュリティを大規模に組み合わせたツールを使用して実装すると、非常に効果的です。たとえば、この Sumo Logic と Infor のケース スタディのように、Infor は業務に費やす時間を 5,000 時間節約することができました。事件。

監視は、パフォーマンスと信頼性の向上に具体的にどのように貢献しますか?

監視は、問題を早期に検出して劣化を回避することで、システムのパフォーマンスと信頼性を向上させます。パフォーマンスの問題は、可用性と信頼性の問題になることがよくあります。これは、タイムアウトが存在する場合に特に当てはまります。たとえば、アプリケーションが 60 秒後にタイムアウトしたとします。最近のパフォーマンスの問題により、多くのリクエストの処理に突然 60 秒以上かかるようになりました。これらの要求はすべて失敗し、アプリケーションは信頼できなくなります。

これに対処するための一般的なベスト プラクティスは、優先度の高いサービスとアプリケーションのクリティカル パスにあるコンポーネントの 4 つのゴールデン シグナル (レイテンシ、トラフィック、エラー、飽和) を監視することです。

レイテンシー

リクエストの処理にはどのくらい時間がかかりますか?成功したリクエストのレイテンシーは、失敗したリクエストとは異なる場合があることに注意してください。遅延が大幅に増加すると、システム パフォーマンスが低下している可能性があります。一方、大幅な減少は、一部の処理がスキップされたことを示している可能性があります。いずれにせよ、監視により、起こりうる問題に注意が向けられます。

トラフィック

トラフィックを監視すると、各コンポーネントの全体的な負荷を把握できます。トラフィックは、コンポーネントごとに異なる方法で測定できます。例えば：

• REST API: リクエスト数
• バックエンド サービス: キューの深さ
• データ処理コンポーネント: 処理されたデータの合計バイト数。

トラフィックの増加は、有機的なビジネスの成長によるものである可能性があり、これは良いことです.ただし、以前より異常に多くのトラフィックを生成するアップストリーム システムの問題を示している可能性もあります。

エラー

コンポーネントのエラー率の増加は、システムの信頼性と有用性に直接影響します。さらに、失敗したオプションが自動的に廃止されると、トラフィックが増加し、パフォーマンスの問題が発生する可能性があります。

飽和

利用可能なリソースのうち、サービスまたはアプリケーションが使用している量は?これが、飽和監視が教えてくれることです。たとえば、ディスクがいっぱいの場合、そのディスクにログを書き込むサービスは、後続のすべてのリクエストで失敗します。より高いレベルでは、Kubernetes クラスターのノードに使用可能なスペースがない場合、新しいポッドは保留され、スケジュールされず、遅延の問題が発生する可能性があります。

お気づきのように、4 つのゴールデン シグナルは互いに関連しています。問題は、多くの場合、複数のシグナルにまたがって現れます。

モニタリングは、特にセキュリティの向上にどのように貢献しますか?

システムの正常性の問題はセキュリティに直接的または間接的に影響を与える可能性がありますが、監視が検出および軽減に役立つ直接的な脅威がいくつかあります。

• 過剰な CPU 使用率や大量のリクエストなどの異常。攻撃者がセグメンテーション フォールトを引き起こしたり、違法な暗号マイニングを実行したり、システムに対して DDoS 攻撃を仕掛けたりしようとしている可能性があります。
• 異常なポートに異常な数のパケットがヒットする場合は、ポート ノッキング攻撃である可能性があります。
• 有効なユーザー名と無効なパスワードを使用した多数の 401 エラー (認証エラー) は、辞書攻撃である可能性があります。
• 多数の 403 エラー (アクセス禁止) は、侵害されたアカウントを使用した攻撃者による権限昇格の可能性があります。
• 公開 API への無効なペイロードにより 400 エラーが増加した場合、公開 Web アプリケーションを攻撃者が悪意を持ってクラッシュさせようとしている可能性があります。
• 営業時間外に大量のデータや機密データをダウンロードすることは、侵害された従業員または不正な内部関係者による流出攻撃である可能性があります。

パフォーマンスとセキュリティを向上させるための監視のベスト プラクティス

システムは複数のコンポーネントで構成されていますが、それはその部分の合計以上のものです。基本的なレベルでは、4 つのゴールデン シグナルについて、システムのすべてのコンポーネント (少なくともクリティカル パス上) を監視する必要があります。これは実際にはどういう意味ですか？

• 主要指標の観察
• 通常運用のメトリック範囲の確立
• コンポーネントが許容範囲から逸脱した場合のアラートの設定

また、外部依存関係にも細心の注意を払う必要があります。たとえば、クラウドで実行したり、サードパーティのサービス プロバイダーと統合したりする場合は、依存しているパブリック エンドポイントを監視し、アラートを設定して問題を検出する必要があります。サード パーティがダウンしているか、そのパフォーマンスが低下している場合、これによりシステムにカスケード障害が発生する可能性があります。

100% 信頼できるコンポーネントを持つことは不可能です。ただし、監視は、コンポーネント (内部および外部の両方) の問題を検出し、それらを交換するか、サービスを適切に低下させることにより、信頼できないコンポーネントから信頼できるシステムを作成するのに役立ちます。たとえば、マルチゾーン構成でシステムを実行していて、1 つのゾーンに問題がある場合、監視によってこれが検出され、他のゾーンへのすべてのトラフィックの再ルーティング (手動または自動) がトリガーされます。

セキュリティの場合、4 つの信号はセキュリティ侵害の補助的な指標にもなる可能性があります。これは特に、エンドポイント デバイスまたはクラウド ワークロードの CPU でスパイクが発生した場合や、ログイン試行の失敗回数が増加した場合に当てはまります。ただし、悪意のある攻撃者に対処するため、セキュリティ監視は慎重に行う必要があります。各コンポーネントとシステム全体の攻撃サービスを定義し、収集する情報が問題を検出するのに十分であることを確認する必要があります。たとえば、データの流出を検出するために、さまざまなアプリケーションやサービスによって内部ネットワークの外部に送信された IP アドレスとデータ量を監視できます。そのデータがなければ、その攻撃方法が見えなくなります。

監視戦略の実施

データ収集を設定したら、以下の手順に従って、堅牢で効果的な監視戦略を展開できます。

1. 重要な資産を特定します。

データ収集の一環として、すべての資産の包括的なインベントリを既に実行しています。ここでのタスクは、災害を防止および軽減するために綿密に監視する必要がある重要な資産を特定することです。 「すべてを監視すればよい」と言うのは簡単ですが、監視には考慮すべきコストがあります。ステージング環境や開発環境、または実験的なサービスの監視とアラートの生成は、エンジニアに多くの不必要なストレスを与える可能性があります。重要でない問題に対して頻繁に午前 3 時にアラートが発生すると、アラート疲労が発生し、本当に重要な問題に対処しようとするチームの意欲が損なわれます。

2. 重要な資産ごとに所有者を割り当てます。

重要な資産を特定したら、それぞれの明確な所有者が必要です。所有者は個人またはチームです。人の場合は、必ずフォールバックも特定してください。また、人々が組織に参加したり退職したり、他の役割やチームに移動したりしても、資産の所有権を維持することも重要です。

3. 重要な資産のアラートを定義します。

最終的に、監視戦略は、異常または侵害された可能性のある資産に対するアラートをどのように定義するかに基づいて、生死を左右します。各アセットの正常性を理解する必要があります。

メトリックを監視している場合、「通常」の定義は、属性 (CPU 使用率など) を値の範囲 (「50%-80%」など) に関連付けることを意味します。通常のバンドは、ビジネスに合わせて動的に変化する可能性があり、時間や場所によって変化する可能性があります。場合によっては、天井または床だけを使用することもできます。通常の範囲を定義することで、資産が通常の範囲外で動作しているときに資産所有者に通知するアラートを作成します。

ログを監視している場合、アラートは通常、特定のログ クエリの結果 (「過去 5 分間にすべての API サービスでログに記録された 404 エラーの数」など) に基づいて定義され、条件 (「は10 未満」）。ログ管理と分析ツールが役に立ちます。

4. アラートごとにランブックを定義します。

重大なアラートが発生したとき、あなたは何をしますか?あなたがしたくないのは、顧客があなたの会社の信頼できない製品についてつぶやき、経営陣がパニックに陥っている間に、その場で戦略を考え出そうとすることです.

ランブックは、追加情報を収集するために事前に準備してテストする、フォローアップしやすい手順のレシピです (たとえば、どのダッシュボードを確認し、どのコマンド ライン スクリプトを実行して根本原因を診断するかなど)。アクションを軽減します (たとえば、以前のバージョンのアプリケーションをデプロイします)。ランブックは、問題を特定の問題にすばやく特定し、それを処理するのに最適な担当者を特定するのに役立ちます。

5. オンコール プロセスを設定します。

所有者、アラート、Runbook があります。多くの場合、アラートは所有者に直接マップできるほど具体的ではありません。ベスト プラクティスは、オンコール エンジニアをビジネスのさまざまな分野に割り当てることです。このオンコール エンジニアは、アラートを受け取り、ランブックに従い、ダッシュボードを見て、根本原因を理解しようとします。問題を理解または修正できない場合は、所有者にエスカレートします。このプロセスは複雑になる可能性があることに注意してください。多くの場合、問題を解決するには複数の利害関係者が協力する必要がある一連の失敗が原因で問題が発生します。

6. 自己治癒に向かって進みます。

ランブックは優れていますが、複雑なランブックを維持し、オンコール エンジニアをトレーニングしてそれに従うには、多くの労力が必要です。そして最終的には、修正プロセスは依然として遅く、エラーが発生しやすい人間に依存しています。ランブックが最新でない場合、それに従うと危機が悪化する可能性があります。

理論的には、Runbook はプログラムで実行できます。ランブックに「アラート X が発火したら、プロセス Y を再起動する必要があります」と記載されている場合、スクリプトまたはプログラムはアラート X の通知を受信し、プロセス Y を再起動できます。同じプログラムで再起動後のプロセス Y を監視し、すべてが正常であることを確認できます。そして最終的にインシデントのレポートを生成します — オンコール エンジニアを起こす必要はありません。自己修復アクションが失敗した場合は、オンコール エンジニアに連絡できます。

7. 事後分析プロセスを確立します。

自己修復は素晴らしいものですが、1 オンスの予防は 1 ポンドの治療に値するため、最初に問題を防ぐことが最善です。すべてのインシデントは、一連の問題全体を学習し、場合によっては防止する機会です。たとえば、バグのあるコードが本番環境に移行したために複数のインシデントが発生した場合、インシデントの事後分析からの教訓は、ステージングでのテストを改善することになる可能性があります。オンコール エンジニアのアラートへの応答が遅すぎたり、ランブックが古かったりした場合、チームは自己修復プラクティスに投資する必要があることを示唆している可能性があります。

結論

監視は、一般的に可観測性、特にセキュリティの可観測性にとって重要な部分です。問題を検出するために、人間がさまざまなダッシュボードやグラフを「ときどき見るだけ」で大規模に作業することは、現実的ではありません。所有者の特定、アラートの設定、ランブックの作成、ランブックの自動化、オンコール プロセスと事後分析プロセスの設定を含む一連のインシデント対応プラクティスが必要です。

本当に素晴らしい一日を！