• ログイン今すぐ開始

本書は、お客様のご参考のために原文の英語版を機械翻訳したものです。

英語版と齟齬がある場合、英語版の定めが優先するものとします。より詳しい情報については、本リンクをご参照ください。

問題を作成する

信頼性エンジニアリング診断: アプリケーション パフォーマンスのトラブルシューティングの初心者向けガイド

このガイドは、顧客に影響を与える問題を診断するスキルを向上させるための入門書です。このガイドの手順に従うことで、アプリケーションのパフォーマンスの問題からより迅速に回復できるようになります。

このガイドは、オブザーバビリティの成熟度に関するシリーズの一部です。

前提条件

このガイドを使用するための要件と推奨事項を次に示します。

期待される成果

概要

ビジネスにとっての価値は次のとおりです。

  • 業務に支障をきたすインシデントの発生を抑制する
  • 問題解決に要する時間 (MTTR) の短縮
  • インシデントの運用コストを削減

IT 運用と SRE の価値は次のとおりです。

  • 理解と解決にかかる時間を短縮

事業成果

Gartner は、IT ダウンタイムの平均コストは 1 分あたり 5,600 ドルと見積もっています。ビジネスに影響を与えるインシデントの累積コストは、知るまでの時間、頻度、修復にかかる時間、収益への影響、およびインシデントをトリアージして解決するエンジニアの数などの要因によって決まります。簡単に言えば、パフォーマンスへの影響を解決するために必要な人員を減らして、ビジネスに影響を与えるインシデントを減らし、インシデントの期間を短縮し、診断を高速化する必要があります。

最終的に、ビジネスの目標は、稼働時間を最大化し、ダウンタイムを最小化することです。ダウンタイムのコストは次のとおりです。

Downtime minutes x Cost per minute = Downtime cost

ダウンタイムは、ビジネスを混乱させるインシデントの数とその期間によって決まります。ダウンタイムのコストには多くの要因が含まれますが、最も直接的に測定できるのは運用コストと収益の損失です。

ビジネスは、以下の削減を推進する必要があります。

  • ビジネスを混乱させるインシデントの数
  • インシデントの運用コスト

運用成果

必要な運用上の結果は、製品層のサービス レベル目標への準拠を維持することです。これを行うには、低下したサービス レベルを診断し、診断を伝え、迅速な解決策を実行します。しかし、予期しない劣化やインシデントは常に発生するため、迅速かつ効果的に対応する必要があります。

このシリーズの他のガイドでは、知るまでの時間を短縮することに重点を置いています。アラートの品質管理ガイドでは、知るまでの時間を改善する事後対応的な方法に焦点を当てサービス レベル管理ガイドでは事前対応的な方法に焦点を当てています。

あなたが今読んでいるガイドでは、理解するまでの時間と解決するまでの時間の短縮に焦点を当てています。

主要業績評価指標 - 運用

「インシデント管理」と SRE 理論の世界では、多くの指標が議論され、議論されています。ただし、主要業績評価指標の小さなセットに注目することが重要であることにほとんどの人が同意しています。

以下の KPI は、成功した SRE およびインシデント管理プラクティスで使用される最も一般的な指標です。

信頼性に対するエンドユーザーの認識

顧客が製品のパフォーマンスをどのように認識しているかは、緊急性と優先度を測定する方法を理解する上で重要です。また、顧客の視点を理解することは、ビジネスが問題をどのように見ているかを理解するのにも役立ち、影響を受ける機能をサポートするために必要なワークフローを理解するのにも役立ちます。顧客とビジネスの認識を理解すると、その機能の信頼性に影響を与えている可能性があるものをよりよく理解できます。

最終的に、顧客の視点から見たオブザーバビリティは、信頼性エンジニアリングに積極的かつ熟練するための最初のステップです。

デジタル製品のパフォーマンスとその機能に対するエンド ユーザーの認識に影響を与える 2 つの主要なエクスペリエンスがあります。以下の条件は、一般的な顧客用語を使用した顧客の観点からのものです。

可用性、別名「うまくいかない」

可用性は、接続性、稼働時間、到達可能性とも呼ばれます。しかし、それはまた、成功 (非エラー) と混同されています。

エンド ユーザーは、ログイン、ブラウズ、検索、インベントリの表示などの必要な機能にアクセスできないと述べる場合があります。または、サービス全体が利用できないと単に述べている場合もあります。これは、サービスに接続できないか、エラーを返すサービスのいずれかの症状です。

従来、「可用性」または「アップタイム」は、サービスへの接続能力を測定することにより、バイナリの「アップ/ダウン」方法で測定されていました。従来の方法には、サービス全体が完全に利用できなくなった場合にのみ測定するという重大なギャップがあります。この従来の信頼性の尺度では、可観測性のギャップが大きくなり、診断が困難になり、対応する前にエンド ユーザーが大きな影響を受けることになります。

可用性は、「稼働時間」とも呼ばれる「サービスに到達する能力」と、「期待される応答を返すサービスの能力」(つまり、「エラーがないこと」) の両方によって測定されます。New Relic の可観測性成熟度フレームワークは、入力パフォーマンス(接続性) と出力パフォーマンス(応答の成功とレイテンシー) によって 2 つを区別します。

パフォーマンス、別名「遅すぎる」

パフォーマンスは、レイテンシーおよび応答時間としても知られています。

エンド ユーザーは、サービスが遅すぎると言うことがあります。

IT リーダーとビジネス リーダーの両方にとって、「パフォーマンス」という用語にはさまざまな問題が含まれます。New Relic のサービス レベル管理では、「速度」は「出力」と「クライアント」の両方のカテゴリで測定されます。ただし、速度の問題の大部分は、従来「バックエンド サービス」と呼ばれていたものに起因する出力の問題が原因で発生します。

根本原因と問題 (直接原因)

問題の根本原因は、問題と同じではありません。同様に、問題を修正しても、通常、問題の根本原因が修正されたことにはなりません。この区別をすることは非常に重要です。

パフォーマンスの問題を探すときは、まず「何が変わったの?」という質問をして、問題の原因を見つけようとする必要があります。通常、変更されたコンポーネントまたは動作は根本的な原因ではありませんが、実際には最初に解決する必要がある問題です。根本原因を解決することは重要ですが、通常、インシデント後の遡及的な議論と長期的な問題管理が必要です。

たとえば、ログイン機能のサービス レベルが突然低下します。トラフィック パターンが通常よりもはるかに多いことがすぐにわかります。パフォーマンスの問題を追跡して、TCP 接続キューがはるかに大きくなるオープン TCP 接続制限の構成にたどり着きます。TCP 制限の引き上げといくつかの追加のサーバー インスタンスを展開することで、問題をすぐに解決します。短期的には問題を解決しましたが、根本的な原因は、不適切なキャパシティ プランニング、マーケティングからの連絡の欠落、またはロード バランサーの構成変更の失敗によるものである可能性があります。

この区別は、ITIL/ITSMインシデント管理問題管理でも行われます。インシデント後の話し合いで根本原因が議論され、その後、長期的な問題管理プロセスで解決されます。

診断手順 (概要)

ステップ 1: 問題文を作成する

最初のルールは、問題のステートメントをすばやく確立することです。問題文を作成するためのガイドはたくさんありますが、シンプルで効果的なものが一番です。適切に構成された問題ステートメントは、次のことを行います。

  1. エンドユーザー、顧客、または消費者にとって何が変わったかを説明してください。エンドユーザーまたは消費者が以前はできたが、現在はできないことは何ですか?これは、問題に対するお客様の認識です。
  2. 製品機能の予想される動作を説明します。これは、問題の技術的評価です。
  3. 製品機能の現在の動作を説明します。これは、修正の望ましい結果の技術的な説明です。

問題文では、仮定を避けてください。事実に固執する。

ステップ 2: ソースを見つける

「ソース」は、症状の原因となっている問題に最も近いコンポーネントまたはコードです。

多くのジャンクション、スプリッター、およびバルブを介して接続された多くの小さな水ホースを考えてみてください。給水サービス レベルが低下しているというアラートが表示されます。どの接合部、スプリット、バルブ、またはホースが問題を引き起こしているかを特定するまで、コンポーネントを通る水の出力から問題を追跡します。バルブの 1 つがショートしていることがわかりました。そのバルブがソースです。ショートが問題(直接の原因)です。

これは、複雑なテクノロジー スタックを診断する場合と同じ概念です。ログイン機能が制限されている場合 (出力)、その制限の原因となっているコンポーネントまでさかのぼって修正する必要があります。それは、API ソフトウェア (サービス境界)、ミドルウェア サービス、データベース、リソースの制約、サード パーティ サービスなどです。

IT には、3 つの主要なブレークポイント ソースがあります: OutputInput 、およびClientです。これらのカテゴリの測定については、サービス レベル管理ガイドで説明しています。診断でそれらを使用する方法を理解するには、読み続けてください。

ステップ 3: 変化を見つける

問題の原因に近づいたら、何が変わったのかを特定します。これにより、短期間で問題を即座に解決する方法をすばやく判断できます。ステップ 2の例では、ハードウェアの劣化によりショートが発生したため、バルブが機能しなくなったという変化がありました。

IT における一般的な変更の例は次のとおりです。

  1. スループット (トラフィック)
  2. コード (デプロイ)
  3. リソース (ハードウェアの割り当て)
  4. アップストリームまたはダウンストリームの依存関係の変更
  5. データ量

パフォーマンスに影響を与える問題のその他の一般的な例については、以下の問題マトリックスを参照してください。

ヘルス データ ポイントを使用する

診断の旅をすぐに開始できる 3 つの主要なパフォーマンス カテゴリがあります。これらの正常性データ ポイントを理解すると、問題の原因がどこにあるかを理解するための時間が大幅に短縮されます。

出力性能

これには次のものが必要です: APM

出力パフォーマンスとは、期待される応答 (出力) をエンドユーザーに提供するための内部テクノロジ スタックの能力です。これは伝統的に「バックエンド」サービスと呼ばれています。

大多数のシナリオでは、出力パフォーマンスは単に応答の速度と応答の品質によって測定されます (つまり、エラーがないかどうか)。上記のユーザーの視点を思い出してください。エンドユーザーは、サービスが遅い、機能していない、またはアクセスできないと述べます。

最も一般的な問題は、エンド ユーザーの要求にタイムリーかつ適切に応答する能力です。

これは、問題のある製品機能をサポートするサービスのレイテンシ異常またはエラー異常によって簡単に識別されます。

入力性能

これには次のものが必要です。

入力パフォーマンスとは、サービスがクライアントからの要求を受け取る能力です。これは、リクエストを送信するクライアントの機能と同じではありません。

出力パフォーマンス、つまりバックエンド サービスが、期待されるパフォーマンス レベルを超えている可能性があります。ただし、クライアントとサービスの間の何かが、要求と応答のライフサイクルを壊しています。これは、クライアントとサービスの間のあらゆるものである可能性があります。

クライアントパフォーマンス

これには以下が必要です: ブラウザ監視および/またはモバイル監視

クライアント パフォーマンスとは、ブラウザーやモバイル アプリケーションが要求を作成し、応答をレンダリングする能力です。出力 (バックエンド) と入力パフォーマンス (シンセティックス) の両方がすぐに除外されると、ブラウザーやモバイルが問題の原因として簡単に特定されます。

出力と入力のパフォーマンスは、除外 (または除外) するのが比較的簡単です。入力および出力診断の診断の深さにより、ブラウザとモバイルは将来的に高度な診断ガイドでカバーされる予定です。

問題マトリックス

問題マトリックスは、3 つの健康データ ポイントによって分類された一般的な問題のチート シートです。

問題の原因は、頻度の高い順に並べられており、最も一般的なものが一番上の行の左側に表示されます。より詳細な内訳を以下に示します。サービス レベル管理が適切に行われていれば、これらのデータ ポイントの 3 つのうち 2 つを迅速に除外することができます。

この表は、健康データ ポイントごとに並べ替えられた問題マトリックスです。

データポイントプラットフォーム機能一般的な問題の原因
出力APM、インフラ、ログ、NPMアプリケーション、データ ソース、ハードウェア構成の変更、インフラストラクチャ、内部ネットワーク、サード パーティ プロバイダー (AWS、GCP)
入力合成、ログ外部ルーティング (CDN、ゲートウェイなど)、内部ルーティング、インターネット上のもの (ISP など)。
クライアントブラウザ、モバイルブラウザまたはモバイル コード

問題は複雑化する傾向がありますが、サービス レベルを迅速に回復するために、「原因を突き止め」、「何が変化したか」を特定することが目標です。

たとえば、最近の新製品の導入によりリクエストが大幅に増加すると、許容できない応答時間が発生します。ソースは、ログイン ミドルウェア サービスで検出されました。問題は、TCP キュー時間が跳ね上がったことです。

この状況の内訳は次のとおりです。

  • カテゴリー: 出力性能
  • 出典:ログインミドルウェア
  • 問題: 追加の要求負荷による TCP キュー時間
  • 解決策: TCP 接続制限の増加とリソースのスケーリング
  • 根本原因: ログイン ミドルウェアに影響を与えるダウンストリーム サービスのキャパシティ プランニングと品質保証テストが不十分

別の状況例を次に示します。

  • ログイン時に 500 のゲートウェイ エラーが突然増加しました...
  • ログイン API の応答時間は、タイムアウトが始まるポイントまで増加しました...
  • タイムアウトは、ミドルウェア層のデータベース接続まで追跡されました...
  • トランザクション追跡により、ログイン要求ごとのデータベース クエリ数が大幅に増加していることが明らかになりました...
  • 問題の直前に発生した展開の展開マーカーが見つかりました。

この状況の内訳は次のとおりです。

  • カテゴリ: 入力パフォーマンスの障害につながる出力パフォーマンスの低下
  • 出典:ミドルウェアサービス呼び出しデータベース
  • 問題: コードのデプロイ後にデータベース クエリが 10 倍に増加
  • 解決策: 展開のロールバック
  • 根本原因: 不十分な品質保証テスト

以下の表は、ソース別にソートされた問題マトリックスです。

ソース

一般的な問題

アプリケーション

  1. 最近の展開 (コード)
  2. ハードウェア リソースの制約
  3. データベースの制約
  4. 構成の変更 (ハードウェア / ルーティング / ネットワーキング)
  5. サードパーティの依存関係

情報源

  1. データベースの制約
  2. クエリ ロジックの変更 (n+1)
  3. メッセージ キュー (通常、プロデューサーまたはコンシューマーのパフォーマンスが低下します)

内部ネットワーキングとルーティング

  1. ロードバランサー
  2. プロキシ
  3. API ゲートウェイ
  4. ルーター (まれ)
  5. ISP/CDN (まれ)

パターン異常の特定

パターンの識別に関する優れた情報や無料のオンライン クラスはたくさんありますが、診断のための強力なスキルを可能にするかなり単純なプロセスです。

パフォーマンス データのパターンと異常を特定するための鍵は、サービスがどのように実行されているかを知る必要がないことです。最近の動作が変化したかどうかを判断するだけで済みます。

このセクションで提供される例では、メトリックとして応答時間または待機時間が使用されますが、エラー、スループット、キューの深さなど、ほぼすべてのデータセットに同じ分析を適用できます。

ノーマル

以下は、APM での一見不安定な応答時間チャート (7 日間) の例です。よく見ると、応答時間の動作が反復的であることがわかります。つまり、7 日間にわたって行動に劇的な変化はありません。スパイクは反復的であり、タイムラインの残りの部分と比較して異常ではありません。

実際、データの表示を経時的な平均から経時的な**パーセンタイル**に変更すると、応答時間の変化がいかに「規則的」であるかがさらに明確になります。

異常な

このグラフは、最近の動作と比較して異常に増加したと思われるアプリケーションの応答時間を示しています。

これは、週ごとの比較を使用して確認できます。

パターンが変化し、先週の比較から悪化しているように見えます。

ソースを見つける

最近の行動パターンの否定的な変化を特定したら、その行動をその相対的な原因までたどることができます。

ここで問題マトリックスを参照します。ほとんどの場合、問題は、ユーザー エクスペリエンスに影響を与える遅延またはエラーの出力パフォーマンスです。問題は、エンドポイント API アプリケーション (要求を受け取る最初のアプリケーション) が問題の原因なのか、それともそのエンドポイントの背後にある依存関係なのかということです。

エンド ユーザーが経験した遅延またはエラーの原因となっているアプリケーションを見つけます。これは、アプリケーション コードが問題であることを意味するわけではありませんが、そのアプリケーションを見つけることで、ソースに近づくことができます。次に、コード、データベース、構成、リソースなどから始まるコンポーネントを除外できます。

現在、分散トレースを使用できますが、最初にソース トランザクションを特定する必要があります。これは、1 つ、いくつか、またはすべてのトランザクションがレイテンシーの影響を受けているかどうかを特定するために、APM トランザクション分析を調べる必要があることを意味します。

影響を受けるトランザクションが特定されたら、そのトランザクションの分散トレースを検索します。これらの分散トレースにより、そのトランザクション グループ内のエンド ツー エンド サービスのより完全で全体的なビューが得られます。分散トレースを使用すると、遅延が発生している場所やエラーが発生している場所をより迅速に特定できます。

上記の手順をまとめると、次のようになります。

  1. APM を使用して、影響を受ける機能をサポートするアプリケーションを調べます。
  2. 問題が遅延なのかエラーなのかを特定します。
  3. 遅延またはエラーをソース アプリケーションまで追跡します。
  4. 問題を見つけます。

要約

以下の要約は、信頼性診断の旅を始めるのに役立つすべてのステップの要約です。

  1. サービス レベル管理を使用して、機能に関する製品レベルの正常性データ ポイントを測定します。
  2. 運用上の主要業績評価指標を使用して、成功を測定します。
  3. パフォーマンス パターンを使用して、エラー、レイテンシ、またはスループットの異常な動作を特定します。
  4. 明確な問題ステートメントを定義します。
  5. レイテンシーまたはエラーに影響を与えるソース アプリケーションを見つけます。
  6. レイテンシーまたはエラーに影響を与える変更を特定します。その変化が直接の原因であり、「問題」とも呼ばれます。

さあ、素晴らしい SRE になりましょう!

Copyright © 2022 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.