モデリングベースのパフォーマンスエンジニアリング入門

全てに影響を及ぼすCPU

2006年
著者: Dominique A. Heger
2020年4月2日
訳者:竹洞 陽一郎

概要

協調するコンポーネント（モジュール）の階層的な構成として効率的なアプリケーションを構築するには、コンポーネントの性能とコンポーネントの相互作用の両方についての知識を十分に持っていることが重要です。
したがって、構成、配置、および相互接続に関する効果的な意思決定を行うためには、従来のアプリケーション開発プロセスを補完するパフォーマンスエンジニアリング（PE）手法を開発することが重要です。
理想的には、測定、分析、モデリングなどのパフォーマンス技術が、プログラミングと実行環境を拡張して、パフォーマンスを観測可能であり、かつパフォーマンスを認識できるようにし、方法論をサポートする必要があります。
また一方で、機能の多様性と実装の複雑さ（異なるプログラミング言語、ハードウェアプラットフォーム、スレッド並列化モードなど）は、より健全な解決策を提供するために、パフォーマンス技術の領域に挑戦しています。

ソフトウェアエンジニアリング（SE）の分野は、ソフトウェア開発プロセスを制御する手順、方法、およびツールを包含しています。
SEは、効率的かつ効果的な方法で高品質のソフトウェア製品を構築するための基礎を提供します。
ソフトウェア品質には、可用性、保守性、スケーラビリティ、機能性、柔軟性、セキュリティ、パフォーマンスなど、多くの側面があります。
今日使用されている多くの SE 方法論は、ソフトウェア製品が機能要件を満たしていることを確認しながら、一定の時間枠と予算内で開発されていることを確認することにのみ焦点を当てています。
今日の市場では、パフォーマンス要件の管理がますます困難になっていると同時に、ますます顕在化されています。
複雑で多階層、クライアント・サーバベースのソフトウェアシステムの展開は、純粋な分析モデルに基づくパフォーマンス分析のアプローチをより複雑なものにしてしまい（それでも非常に価値のあるものではありますが）、その結果、数学とキューイング理論についてより深い経験を必要とするパフォーマンスモデルへと帰着します。
ソフトウェアやコンピュータシステムの性質が進化してきたように、ユーザコミュニティも進化してきました。
今日のシステムは、主に顧客との直接の接触を目的としたものであるため、ほとんどの企業は、もはや自社の内部使用のためだけにシステムを設計、開発、展開することはありません。
インターネット（特にEコマースの分野）の進化により、システムの可用性、保守性、スケーラビリティ（実際のシステム性能に主眼を置いた）がより重視されるようになりました。

この記事では、システム・パフォーマンス・エンジニアリングを可能にする方法論の概要を説明します。
基本的には、システムテスト段階、品質保証段階、あるいは初期導入段階のいずれかでパフォーマンスの問題が特定されるケースを回避することに焦点を当てています。
潜在的なパフォーマンスリスクの軽減（システムライフサイクルの初期段階で）、システムのスケーラビリティの決定と評価（利用可能な追加の物理的・論理的リソースに基づく）、システムサポートの側面の評価は、この方法論に直接貢献し、影響を与える主要なコンポーネントです。
多階層環境におけるエンドツーエンドのパフォーマンスを評価するためには、分析的アプローチとペトリネットベースの（シミュレーション）モデリングアプローチの組み合わせが適用可能であり、インフラストラクチャ全体のダイナミクスの分析と評価を可能にします。
これには、共有された（ハードウェアやソフトウェアの）リソースを争う他のアプリケーションなど、外部からの潜在的な影響も含まれます。
ソフトウェアの設計・開発チームが行うデータモデリング、プロトタイピング、ユースケーススタディと同様に、ペトリネットベースのシミュレーションモデリングは、さまざまな状況下でのシステム性能の精緻化、評価、分析に重点を置いています。
シミュレーションモデリングでは、システム全体のモデルを開発、較正、検証、検証、利用して、応答時間、スループット、リソース利用率などの主要な性能指標を分析、評価、推定します。
実際のモデルは、設計チームが提供するシーケンス図（SD）またはユースケースマップ（UCM）のいずれかから導き出され、システムアーキテクトによって決定されたハードウェアとソフトウェアのインフラストラクチャが組み込まれています。

序章

商業環境では、ビジネスプロセスは、システムの実際の必要性を誘発する原動力となります。
ユーザーがシステム上で特定のタスクを実行すると、アプリケーションは基本的にデータを取得したり、計算や比較を実行したり、情報を更新したりすることが求められます。
パフォーマンス・エンジニアリング・プロセスに不可欠なのは、実行されなければならない作業量の見積もりです。
作業量は、解析モデルまたはシミュレーションモデルへの入力パラメータの1つとして考慮されます。
繰り返しになりますが、ユーザーアプリケーションはビジネスプロセスの実行をサポートします。起動されるとき、アプリケーションは（ライブラリまたはシステムコールを介して）実際の物理的および論理的なリソースを利用します。 主要な物理リソースのいくつかは、CPU、メモリ、I/O、ネットワーク関連のコンポーネントですが、論理リソースのいくつかは、メモリテーブル、ファイルシステムのブロックサイズ、またはネットワークのパケットサイズとして識別することができます。
呼び出されたリソースは、モデルへの追加入力パラメータを表すため、特定して定量化する必要があります。
実際には、これらのリソースは、経験的な推測プロセスを経て決定されるか、経験的な分析を経て類似のシステムから抽出されるか、または実際のシステムを模倣した「計測済み」プロトタイプから得られるかのいずれかです。
一例として、ARM(※訳注 Application Response Management) のようなツールをプロトタイプと組み合わせて利用することで、アプリケーションは、トランザクション全体のためだけでなく、個々のビジネス機能コンポーネントのための詳細な応答時間の測定値を報告することができます。
一例として、収集したデータに基づいて、思考時間と実際のシステム処理時間を分離し、どのアプリケーション機能が全体の応答時間やリソース利用に最も貢献しているかを判断することが可能です。

エンドツーエンドのパフォーマンス分析を行うための方法論

既存の製品への性能改善のレトロフィットは、困難で高価な作業であり、システムの導入を遅らせる可能性があります。
以下のセクションでは、包括的なシステム性能分析に変換できるいくつかのカスケード・ステップからなる、非常に実用的な分割と征服に基づいたアプローチの概要を説明します。
この方法論は、Smith, Jain, Siddiqui らによって実施された研究を青写真として利用しています（参考文献を参照）。
一言で言えば、システム全体を基本的には、特定のパフォーマンスバジェットを持っていると識別されたシステムの責任に対応する部分に分割する。
性能バジェット（バジェットは推測されているか、経験的な分析によって決定されている）を利用して、システムの全体的な性能を推定し、潜在的な設計変更を動的に分析することができます。
繰り返しになりますが、解析モデルまたはシミュレーションモデルは、全体的な応答時間を予測するためだけでなく、特定の性能目標を定義し評価するためにも使用できます。
言い換えれば、全体的な性能目標を満たすために実現可能な性能予算を決定し、定量化することができ、その結果、性能分析のインクリメンタルな変化をサポートすると表現できるプロセスになります。
システムの複雑さと回答すべき質問に基づいて、分析モデルまたはシミュレーションモデルのいずれかが、個々のパフォーマンス予算を理解し、全体的なパフォーマンス目標を達成するための鍵となります。
モデルが開発されると、分析は、順方向ベースまたは逆方向ベースの分析アプローチを利用して実施することができます。
順方向ベースの分析では、論理的な流れは、個々のパフォーマンス予算から始まり、システム全体の全体的な定量化で終わるため、システムの要件に関する実現可能性分析を行うために使用することができます。
すでに議論したように、初期の性能予算は、経験に基づいて（通常は偶発的な事態に備えて予備を組み込んで）決定するか、プロトタイプベースのアプローチを利用して決定する必要があるかもしれません。
逆方向ベースの研究では、全体的なパフォーマンス目標から分析を開始し、それを個々のパフォーマンス予算に分解します（オペレーションレベルで）。
逆方向ベースのアプローチは、基本的には、達成すべき個々のパフォーマンス予算を（ここでも、オペレーションごとのレベルで）生成し、実現不可能なパフォーマンス目標を識別するためのツールとして役立つかもしれません。

ステップ1：設計仕様

設計仕様では、システムの動作をシナリオのセットとして（一定の抽象度で）キャプチャし、呼び出されたソフトウェア・サブシステム、操作、およびビジネス機能レベルでの責任を概説します。
シーケンス図（SD）またはユースケース・マップ（UCM）は、モデルを開発し、感度調査やキャパシティ・スタディを実施するために必要な柔軟性と詳細を提供します。

ステップ2：パフォーマンス（需要）予算

モデリング活動の前にパフォーマンス目標を特定するだけでなく、研究でどのようなパフォーマンスの質問に答えることになっているのかを非常に明確に把握しておくことが不可欠です。
パフォーマンス目標が、パフォーマンスの質問に答えるために必要な（モデリングの）詳細レベルを駆動するので、これは非常に重要です。
個々のパフォーマンス予算は、SD または UCM で特定された業務と責任のリソース需要を記述する実際の値である。
例として、決定される単位は、CPU秒、オペレーションカウント、パケットサイズ、ネットワーキングおよび/またはI/Oサブシステムを介して移動されたMバイトなどです。
繰り返しになりますが、初期予算は、経験に基づいて想定または推測されたもの、類似のシステムから得られたもの、既存のコンポーネントを利用して測定されたもの、またはプロトタイプを使用して実施された経験的な分析に基づいて決定されたもののいずれかでなければなりません。
さらに、（現実世界のシナリオで想定されているような）オペレーションミックスを特定するために、特定のワークロードプロファイルを特定することが不可欠です。

ステップ3：ハードウェア、ソフトウェア、通信インフラストラクチャの特定

アプリケーションの仕様は、それ自体がシステム全体を完全に定義するものではありません。多層環境で動作するほとんどのパフォーマンス研究では、ハードウェアのレイアウト、オペレーティングシステムの仕様、組み込みのネットワークとミドルウェアのインフラストラクチャを取得する必要があります。 アーキテクチャ・チームからの情報を得ることができます。
これらの要素はすべて、モデルを開発する前に決定されなければなりません（このプロセスは仮定に基づいている場合もあります）。

ステップ4: (確率的シミュレーション)モデルの開発

性能分析を行っている間、アナリストは通常、分析モデル、シミュレーションモデル、および経験的分析に基づいた技術の組み合わせを利用します。
解析モデルは、システムの挙動をシミュレートし、方程式によって構築され、実際の性能は数学的に導出されます。
解析モデルでは、通常、システムコンポーネントの作業負荷特性を近似した多数のパラメータ化された関数を構築する必要があります（図1を参照）。
言い換えれば、実際の作業負荷分布は通常無視されるため、解析モデルは平均と標準偏差のタイプの統計量を提供します。モデルをトレースするためには、多くの単純化された仮定が必要です。
これらの仮定がどのように実世界の挙動を反映しているか、また、それらが数学的な方程式として定式化できるかどうかが、基本的にこのアプローチの精度と有用性を決定します。
解析モデルは一般的にシミュレーションモデルよりも安価で迅速に構築でき、システムの性能に関連する様々な側面を解析して予測するために（モデルを較正した後に）簡単に調整することができます。