ITにおける個別の方向としてのアプリケーションパフォーマンスの分析

こんにちは、ダニエルと申します。5年以上にわたり、国際的な大企業のITインフラストラクチャのグローバルテクニカルサポートサービスに携わっています。 アプリケーションパフォーマンスの分析を別の領域に分離するというアイデアは、約2年前に生まれました。現在、最初の作業結果をまとめることができる段階にあります。 この記事を書くきっかけになった主な理由は、この分野の発展過程を調整するために将来それらを使用するために、外部から建設的なレビュー（このリソースへの尊敬される訪問者を含む）を受け取りたいという欲求です。

アプリケーションパフォーマンス管理

アプリケーションパフォーマンス管理[1]（その分析に関するより一般的な）のトピックは、私たちの時代に非常に人気があります。 多くの大企業は、この分野を発展させることの重要性を認識しているか、認識に近づいています。 しかし、実際の実装と取り組みの効果の評価の問題は単純なものとはほど遠い。 特定のアプリケーションまたはサービスごとの「最適なパフォーマンス」とは、あいまいな状態や結論を伴う簡単な作業ではありません。 また、今日では、この分野への投資の財務効率を測定するための単一の信頼できる方法はありません。 この領域の開発で信頼できる唯一のものは、各ケースで使用される常識です。 これらの問題はすべて、エンタープライズマネジメントアソシエイツのグローバル調査[2]によく反映されています。



典型的な例を見てみましょう。 組織にはいくつかの重要なアプリケーションがあります。 1時間ごとのダウンタイムが非常に顕著な損失につながるため、ビジネスにはこのアプリケーションの可用性に対する厳しい要件があります。 関連するSLAが署名されています。 IT部門は、特別なデバイスが定期的にユーザーインターフェイスをポーリングし、単純な要求を送信し、通常の応答を待機するときに、可用性の継続的な自動監視を確立します。 回答がない場合、自動インシデントが作成され、対応するサポートチームによって削除されます。 IT部門が業務を遂行し、ビジネスの利益を完全にサポートしていると言えますか？ わからない。



ある日、ユーザーはアプリケーションが非常に速く起動することを発見しますが、その主要な操作は非常に遅いです。 自動監視は無音で、この問題が重大な損失につながる前に電話を取り、テクニカルサポートサービスに電話をかけるユーザーが少なくとも1人いる場合、非常に幸運です。 私の実践では、原則として、ユーザーはそのような問題を報告しないことを示しています。 困難で主観的な症状を呼び出して説明したくないという平凡な態度から、地元のサポートサービスに対する不信に至るまで、多くの理由があります。 そのような問題は何年も続き、ビジネスに隠れた損害をもたらし、人々の神経を台無しにし、IT部門の評判を著しく損ないます。 システムパフォーマンスの低下による損失が明らかになりすぎて、ビジネス管理の焦点に該当する場合、彼らは依然として問題を発見することがあります。 その後、かなり魅力的な物語が始まります。 上級ITエグゼクティブは、部下に問題をすぐに解決することを要求します。 個々のチームの代表者からなる円卓が組み立てられ、それぞれが彼に委ねられたインフラストラクチャの一部をチェックし、誰もが素晴らしい結論に達します。 サーバーは正常です-CPUもメモリも過負荷ではありません。 ネットワークは正常です-パケット損失はなく、通信回線は過負荷になりません。 クライアント部分も正常である必要があります-残りのアプリケーションは正常に動作しています。 問題は、すべてが1つのシステムに統合されたとき-それはひどく動作しますが、根本原因を探す場所はどこですか？ プログラムの製造者も、他のクライアントが苦情を言っていないという事実を参照してあまり助けにはならず、「何らかのインフラストラクチャの問題」を指摘しています。 その後、通常、次の3つのいずれかが発生します（組み合わせることもあります）。

• 長い研究の後、彼らは問題を忘れるかもしれません（ビジネスは現在は機能しており、より速くはならないという事実と一致しています）が、その過程でインフラストラクチャの個々の要素の混elementsとした改善に多くのお金を費やしました。 悲しいかな、それは助けにはなりませんでしたが、私たちは試しました！
• ビジネスは、このシステムのパフォーマンスの低下に対応できず、IT部門が問題を解決できなかったため、外部コンサルタントを雇います。 彼は多額のお金で、個々のインフラストラクチャ要素とテクノロジーの接合部のどこかに根本原因を見つけましたが、IT部門の評判は完全に損なわれています。
• 内部の専門家からの誰かが理由を推測しますが、彼らの責任の範囲をはるかに超えて行動します。

IT部門は後者の場合にのみ顔を救うことができますが、このようにして何が起こるかは残念ですが、保証はありません。 さらに、人々が直接的な責任を超えて働き、業界の透明性と管理性を維持するように人々を動機付ける方法は完全に不明確です。

主要なアプリケーションパフォーマンス分析機能

会社の経営陣は、アプリケーションパフォーマンスの分析を別の領域に分離するという私のイニシアチブをサポートしました。 これは、私たちの組織のニーズに合わせて開発し、私が最善を尽くすために、つまり企業で機能するさまざまなシステムのクロステクノロジー分析を行うために、公式に機会を与えてくれました。 ここで、この領域が何を理解しているかを理解しましょう。



次の機能をアプリケーションパフォーマンス分析の分野（以降、APAまたはアプリケーションパフォーマンス分析と呼びます）に割り当てました（使用可能なツールとスキルに従って）。

• 新しいアプリケーションのパフォーマンスとアーキテクチャの初期分析
• 運用サポートチームがアプリケーションパフォーマンスインシデントの原因を特定するのに役立ちます
• 主要アプリケーションの自動運用パフォーマンス監視

図1



主なAPAツールの1つはナレッジベースであり、これはAPAの焦点となったすべてのアプリケーションの機能的な目的、アーキテクチャ、および関連するインシデントを反映しています。 同じ仕事を2回しないことが役立ちます（特に、複数の専門家がチームで働いている場合）。 このベースは、エンタープライズアーキテクチャ[3]のより一般的な領域であるAPA領域、つまり技術ブランチに関連していると言えます。 過度の期待を作成しないために、責任範囲の明確な境界をすぐに定義します。

• APAは、実装チームが新しいアプリケーションの初期パフォーマンス分析を行うことを支援しますが、このアプリケーションを総合的に評価する責任は負いません。 機能、冗長性、フォールトトレランスなどの問題は、APA調査の範囲外のままです。
• APAは、サポートチームが問題のあるインフラストラクチャまたはアプリケーションアイテムを識別するのに役立ちますが、それを修正する責任はありません。
• アプリケーションパフォーマンスの監視のニーズに対して、APAは技術的なツールを提供し、顧客のニーズに応じてそれらを微調整しますが、特定された問題の解決の成功については責任を負いません。

APAエリアの仕事の本質は、そのロゴに反映されています（図2を参照）。 灯台は正しいコースを決定するのに役立ちますが、ルートの選択は常に船長の良心にかかっています。



図2

他のサービスの主なAPAニッチは、次のように定義できます。

• 他のチームが停止している問題とインシデントの分析
• クロステックの専門知識
• アプリケーションパフォーマンスインシデントの防止

ITILの用語では、Performance Managementエリアは、Capacity Managementエリアの従来の概念を超えており、正式に参照されていると言えます[4]。

上記からわかるように、APAはアプリケーションパフォーマンス管理プロセスで重要な役割を果たしますが、完全に置き換わるものではありません。 これは、最も複雑なコンポーネントの一種の集中化と統合です。ただし、監視と分析ですが、直接的なアプリケーション管理の問題は関連するチームに残っています。 ここでは、彼らはより効果的です：彼らはソフトウェアメーカーとの個別の接触を確立する方が簡単です、彼らは彼らのサービスまたはアプリケーションの成功に最も興味があります。 APAは最も複雑な領域をカバーするツールであり、他のすべては標準的な手順で解決されます。

アプリケーションのパフォーマンスを分析するための基本的な方法

APAの専門家がネットワークトラフィックを分析して、パフォーマンスの問題の原因を特定します。 ネットワークは、アプリケーションのさまざまなアーキテクチャコンポーネントを組み合わせた普遍的な環境であり、ほとんどの場合、ネットワークトランザクションの分析は、不良要素を見つけるために必要かつ十分な情報を提供します。 ただし、この方法には制限があります。 たとえば、このサーバーがユーザー操作の実行に最大の遅延をもたらすことがわかります。また、最も問題のある呼び出し、たとえば、Webページと対応する長いSQLクエリをデータベースに読み込むときのGETまたはPOST要求を強調表示することもできます。 ただし、この時点でサーバー内部で発生することは、画面外のままです。 さらに、何らかの理由でデータベースサーバーが同じホスト内のアプリケーションサーバーと組み合わされた場合、このメソッドを使用して操作の合計実行時間への影響を分離することはほとんど不可能です。 幸いなことに、ほとんどの場合、この方法を適用すると良い結果が得られます。 私の練習から、私への電話の約99％が正常に解決されたと言えます。 ただし、APAサービスが受信する情報は重要です。



現在、市場にはアプリケーションのパフォーマンス管理に役立つ多くのソフトウェアおよびハードウェア製品があります。 主に2つのツールを使用します。1つは事前に記録されたトランザクションの詳細な調査用、もう1つはネットワークトラフィックのデコードと分析によるアプリケーションパフォーマンスの継続的な監視用です。



次に、APAの個々の領域を実装する方法を詳しく見ていきましょう。

運用サポート方法

アプリケーションパフォーマンスの運用サポートを成功させる鍵は、各インシデントの明確な形式化です。 原則として、ユーザーは問題を主観的かつ非常に感情的に説明します。 最初の段階では、感情の要素（コーヒーが強すぎる、気分が悪い、またはアプリケーションに対する敵意）を問題の直接的な定義から分離することが非常に重要です。 これを行うために、インシデントの作成中にユーザーが回答する必要がある質問の特別なリストを作成しました。 APAはユーザーとの直接的な作業を意味するものではないことに注意することが重要です。すべての必要な答えは、第1レベルおよび第2レベルのサポートのユニバーサルスペシャリストによって受け取られます。 アプリケーションのパフォーマンスの自動監視を使用して、必要な情報の一部を取得できる場合があります。



さらに、このアプリケーションを担当するチームは、アーキテクチャのかなり完全な説明を提供します（どのホストが、どの問題を担当し、それらの間のネットワークトランザクションは、問題のある操作の実行中に予期されます）。 不完全な情報が提供されることもありますが、これは調査の妨げにはなりません。 また、アプリケーションのクライアント側とサーバー側に必要なエージェントをインストールするよう依頼することもできます。 エージェントは、ネットワークインターフェイスから統計情報を収集するために使用されます。 それらは指示に従って厳密に配置されており、99％の場合、インストールによって問題は発生しません。



次に、問題のある操作を直接テストする手順に同意します。指示に従って自分で問題を再現するか、ユーザーにコマンドでこれを行うように依頼します。 同時に、エージェントで記録プロセスをアクティブにします。 結果として得られる資料は、いくつかの観測ポイントでの問題のある操作の実行中に同時に記録されたトレースファイルのセットです。 これらには、選択したホストでのネットワーク操作の完全な履歴が含まれます。 分析に使用するツールの主な利点は、これらのファイルを1つの時間調整された状態に結合できることです（つまり、クライアントから取得したトレースファイルの0秒は、サーバートレースファイルの0秒に正確に対応します）。 これにより、クライアントリクエストがネットワークを介してアプリケーションサーバーに到達した時間、必要なリクエストをデータベースに送信する前に処理に費やした時間、データベースがこのリクエストを処理した時間など、操作の全過程を時間内に追跡する機会が与えられます。 具体例を見てみましょう。



興味のあるアプリケーションのアーキテクチャのフラグメントを次に示します（図3を参照）。



図3

記録と処理の後、図4に示すような問題のある操作が表示されます。



図4

次に、操作の合計時間に対する各要素の効果を判断できます（図5を参照）



図5

問題はアプリケーションサーバーとCUBEサーバーに関連していることがわかりますが、もう少し深く理解できます。 たとえば、最も問題のある課題を強調します（図6を参照）。



図6



このソフトウェアの製造元との合理的な会話のトピックがあります。

また、この方法は、サポートチームが停滞している非パフォーマンス機能の問題を調査するのに劣らず効果的であることに注意することも重要です。

新しいアプリケーションのパフォーマンスとアーキテクチャの初期分析

このタイプのアクティビティは、運用サポートで使用される方法に完全に基づいています。 それらに加えて、集中型アプリケーションのさまざまな地域でのユーザーインターフェイスのパフォーマンスを数学的に予測することもできます。

アプリケーションパフォーマンスの監視

前述のように、ユーザーからアプリケーションのパフォーマンスを客観的に評価することは非常に困難です。 質問自体の主観性のためです。 一方、その作業における技術サポートは主観的な測定基準では機能しません。 この矛盾はしばしば、存在しないまたは本質的でない故障を修正しようとしているという事実につながりますが、本当に重要な問題は無視されます。 主な結論は、企業にインストールされたアプリケーションのパフォーマンスを効果的に管理するには、自動パフォーマンス監視のための独立したシステムが必要だということです。 この問題でユーザーに依存することは無意味です。



この問題を解決するには、ネットワークトラフィックをデコードおよび分析して、アプリケーションのパフォーマンスを継続的に監視するツールを使用します。 ここで、情報のソースは、対象のスイッチに設定されたSPANポートです。 つまり、私たちは実際に関心のあるシステムの作業に干渉しません。サーバー上のエージェントは必要ありません。 受信した情報は、特別なプローブサーバーで収集およびフィルタリングされ、中央サーバーに送信されます。 このサーバーは、受信したデータの分析と保存を行い、レポートインターフェイスとアプリケーションパフォーマンスの問題の自動通知を提供します。



このソリューションは、既存の問題をすばやく見つけるのに役立つだけでなく、多くの場合、それらの発生の根本原因を探す場所のヒントを提供します。 運用サポートによって実行できるほど詳細かつ正確ではありませんが、調査プロセスを大幅に高速化するには十分です。 さらに、アプリケーションパフォーマンスの変化の長期的な傾向を確認し、インフラストラクチャに加えられた変更の影響を評価できます。

私たちが使用するレポートの例をいくつか挙げましょう。



過去8時間にわたるアプリケーションのWebユーザーインターフェイスの負荷とパフォーマンスの全体的な評価（図7を参照）





図7

ここで： 操作 （左スケール）-測定間隔ごとの操作の合計数。 「遅い操作」と「速い操作」に分けられます。 実行時間がこのインターフェイスに定義された特定のしきい値を超える場合、操作は遅いと見なされます。 平均操作時間 （右スケール）-各測定間隔の操作の平均時間。



同じアプリケーションのデータベースサーバーの同時パフォーマンスと負荷を図8に示します。





図8



必要に応じて、特定のSQLクエリが「平均操作時間」を8 30から9 00の間でジャンプさせたかどうかを判断できますが、ユーザーインターフェイスに影響を与えないため、特別な必要はありません。

社内または外部委託

サービスとしてのアプリケーションパフォーマンスの分析を提供する市場には、企業があります。 私が理解できる限り、彼らは私とほぼ同じ方法でそれを行いますが、さまざまなバリエーションや追加が可能です。 企業でこの分野を開発するという課題に直面している場合、決定すべき最初の質問は、外部サービスを使用するか、社内でサービスを開発することです。 この段階を経て、最終決定を下したいくつかの重要な要素を強調しました。 彼らもあなたにとって興味深く、役に立つことを願っています。



考えるべき最初の要因の1つは価格です。 外部サービスの場合、インストールの初期コストは、内部インストールに必要なものよりも大幅に低くなる可能性があります。 さらに、固定資産の増加は実質的に回避できます（サービスを購入します）。 すべてを内部にインストールする場合は、サーバー、ライセンス、雇用とトレーニングの担当者、年間メンテナンス、これらすべてのインストールとデバッグのためのリソースなど、いくつかのコストに備える必要があります。 そして、あなたがすべてを自分でやると、努力と費用が利益をもたらし始めるのに必要な時間がかなり長くなる可能性があります。 これらの議論は短期的に考えると非常に重要ですが、時間が経つにつれてバランスが変わる可能性があります。 サービスプロバイダーは、主に営利団体です。 彼も、スペシャリストとサービス製品のメンテナンス費用を負担し、自分のためにそれを行う必要があります。 長期的に多かれ少なかれ密集した負荷で、サードパーティ企業のサービスを使用する場合、このサービスは高いコストを必要とする可能性があります。 各オプションの所有コストを比較するのに多くの時間を費やしました。 私は、既存の経験に基づいていくつかの仮定をしなければなりませんでした。1年に何回の調査を行う必要があるか、平均してどれくらいの時間がかかるか、最終的にどれくらいの費用がかかるかです。



同様に重要な問題は、このお金で得られるもの（重大なインシデントの調査の品質、量、および速度）です。



アウトソースサービスの重要な機能は、プロバイダーが契約の一部として常に機能することです。 内部サービスとは異なり、彼は私たちのビジネスの成功に全く興味がありません。 これは、境界線の状況におけるサプライヤーの柔軟性の欠如を意味します。 契約書に明記されていないものはすべて、原則として不可能または非常に高価です。 たとえば、パフォーマンスに関係しない複雑な重大なインシデントが発生しました。 そのような場合、パフォーマンスの問題を分析するために使用されるのと同じツールと方法が役立ちます。 内部のAPAチームは間違いなく役立ちますが、サードパーティプロバイダーが言うことは不明です。 正式には、彼にとってこれは契約と通常の作業の範囲をはるかに超えています。 そして、彼は技術に精通していない可能性があり、多くの議論が彼にうまくいかないので、その側のマネージャーを助けるように説得するのは簡単ではないという事実ではありません。



APAの調査により、既存のインフラストラクチャを大幅に変更することが推奨される場合があります。 これは、現在のインシデントを解決するだけでなく、他のアプリケーションで同様の問題を防ぐためにも行われます。 外部のサプライヤがまだ発生していない問題を解決することは完全に不利です。 これが彼らの収入です。 さらに、提供される推奨事項の責任レベルは非常に高くなります。これは、推奨事項が企業内の情報技術開発の全体的な戦略に影響を及ぼすことが多いためです。 これらの問題を外部企業の裁量に委ねることは必ずしも賢明ではありません。



重大なインシデントの調査速度に関する複雑な問題はありません。 一般に、パフォーマンスの問題の調査は複雑な領域です。 分析にかかる時間を事前に言うことはできません-未知の要因が多すぎます。 いずれにしても、これは契約に反映できるものではありません。 しかし、緊急に理解する必要がある場合はどうでしょうか？ いずれにせよ、内部部門はビジネスの成功に依存しますが、外部企業はそうではありません。



さらに、外部プロバイダーとの連携には、リクエストと取得した結果の特定の形式化が含まれます。 そして今、問題は次のとおりです。すべての内部ユニットは要求を明確に定式化する準備ができており、正確に何が回答されたかを理解できますか 多くの場合、人々は私のところに来て、本当に必要なものについてはまったく尋ねません。 社内には、社内の適切な人材を知っており、外部のサプライヤーとその言語でコミュニケーションを取る方法を理解している翻訳者として行動する人がまだ必要です。 同時に、この役割は、独立した調査を実施するために必要なものとほぼ同じ、優れた技術的専門知識の存在を意味します。



上記の議論を考慮すると、APAを内部サービスとして残す決定に至りました。 もちろん、それぞれの場合で、最適なソリューションは異なる場合があります。 問題の性質上、議論は演prior的に物議をかもします。 私は自分の経験を共有するだけです。

おわりに

上記のすべては、大企業でのアプリケーションパフォーマンスの分析および管理プロセスの実際的な実装のバージョンです。 私たちの場合、それは良い結果をもたらします。 過去1年間、APAは多くの重要な問題の調査に関与しており、ほとんどの場合、根本原因の特定に重要な役割を果たしてきました。 さらに、多くの場合、APAメソッドを使用せずに検出されたエラーを特定する方法を想像することは困難でした。 私たちの仕事は経営陣に感謝されています。

参照資料

[1] en.wikipedia.org/wiki/Application_Performance_Management 。

[2]「小売ITサービスの運用：ビジネスエコシステム全体でのアプリケーションパフォーマンスの低下の影響の計算」。 エンタープライズマネジメントアソシエイツ。 2011

[3] en.wikipedia.org/wiki/Enterprise_architecture_framework

[4] en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library