パフォーマンス

製品定義段階でユーザーの期待を収集し、ビジネス要件を定量化し、これを後の製品アーキテクチャーと設計の基礎として使用します。

適切に設計されたソリューション内のコンポーネントは、たとえばサービスの別のインスタンスを追加するなど、個別に拡張できますが、コンポーネントの追加や削除は、ソリューションの他の部分にも影響を与える可能性があります。たとえば、Webトラフィックの急増に対応するために別のWebサーバーを追加すると、バックエンド・サービスとの通信のために、より多くのメッセージ・キューが必要になる場合があります。スケーリングの依存関係を事前に知ることで、ソリューションの運用動作を理解し、単一リソースのオーバースケーリングによるリソースの枯渇を回避できます。

適切に設計されたハイブリッドクラウド・ソリューションは、マルチプラットフォーム・アーキテクチャーを活用してスケーリングおよびバースト戦略を採用し、パフォーマンス、セキュリティー、運用コスト、エンドユーザーの期待を最適化します。たとえば、強力なパフォーマンス保証と固定運用コストを備えたオンプレミス・インフラストラクチャーでワークロードを実行し、ワークロードのピーク時にパブリッククラウド・サービス・プロバイダーにバースト/スケーリングできます。

データを移動するのはコストがかかります。適切に設計されたソリューションは、コンテナ化されたワークロードのポータビリティーとモビリティーを活用し、消費するデータにできるだけ近い場所にサービスを配置します。

ソリューションでは、そのアーキテクチャーの価値を最大化するために、適切なプラットフォームとリソースを選択する必要があります。ハイブリッドクラウド・ソリューションは、オンプレミス・インフラストラクチャーを含む複数のクラウドにまたがることができるため、アーキテクトはソリューションのパフォーマンス・ニーズを満たす最適なリソースの組み合わせを自由に選択できます。

ソリューションは、たとえばサーバーにCPUを追加するなどして既存のユニットの容量を変更するのではなく、個別のユニット（サーバー、サービス、ネットワーク・インターフェースなど）を追加または削除することで処理能力を増減させるように設計する必要があります。これを達成するには、ソリューションは次のアーキテクチャーの原則を採用する必要があります。

• ステートレス・コンポーネントは、やり取りする間にクライアントまたはセッションの状態（ユーザーIDや以前の呼び出しで提供されたデータ入力など）を保持しないコンポーネントであり、クライアントとコンポーネントの特定の1つのインスタンス間の依存関係を排除します。コンポーネントとその消費者の間にこの依存関係がないため、ソリューションがコンポーネントのサービスの利用者に影響を与えることなく、コンポーネント・インスタンスを追加または削除してスケールアップおよびスケールダウンできます。ステートレス・コンポーネントの良例は、食料品店のレジ係です。利用可能なレジ係が少なくとも1つあれば、買い物客は食料品の支払いを行うことができ、買い物客の数に応じてレジ係を増やしたり減らしたりすることができます。これとは逆に、買い物客が買い物する際、最初に特定のレジ係を割り当てられたとします。割り当てられたレジ係が行き詰まったり、さらに悪いことに利用できなくなったりすると、買い物客は待たされたり最初からやり直さなければならず、食料品店の全体的な業績（1時間あたりの買い物客数で測定）が低下します。

• 長時間実行されるタスクは避けてください。ソリューションが長時間実行されるタスク（複雑な科学計算の実行など）をサポートする必要がある場合は、ソリューションをシャットダウンして再起動できるようにする割り込みおよびチェックポイント機能を通じて、スケールインまたはスケールアウトをサポートするようにタスクを設計する必要があります。

• 両端のデータ。ステートレス・コンポーネントは、理論的には無限に拡張可能であり、クライアント間で再利用可能です。優れた能力を発揮するソリューションは、状態（ユーザーとアプリケーションのデータ）をソリューション・アーキテクチャーの最終段階のクライアント・アプリケーションとデータベースにプッシュし、その間にあるアーキテクチャー層には状態を保持しません。

リソース:
ステートフルとステートレスの比較

一貫性の高い疎結合コンポーネントのセットとしてソリューションを設計すると、提供するサービスの需要に応じてコンポーネントを独立して拡張できます。アーキテクチャー・アプローチ、たとえばサービス指向アーキテクチャーやマイクロサービスには、このプラクティスがコアの設計原則として組み込まれています。つまり、高レベルの疎結合APIを介して通信する高い一貫性のある一連のサービスになります。

ソリューションのコンポーネント間でのデータの移動は、多くの場合、トランザクションの中で最も時間がかかる要素です。コンポーネントは、利用可能な帯域幅に対して通信頻度と量を最適化するように設計する必要があります。たとえば、データベースから個々の値を取得するために繰り返し呼び出しを行うアプリケーションは、ローカル・ネットワークに展開された場合は「十分に」機能するかもしれませんが、データベース・コンポーネントがクラウド・サービス・プロバイダーに再配置されると遅延する可能性があります。

Webベースのアプリケーションで一般的に使用されるREST（表現の転送）アーキテクチャー方式は、適切に設計されたソリューションが示すバランスの好例です。リソースの完全な表現状態がJSON、XML、その他のドキュメントとして転送され、転送される情報量とWebベースのやり取りにおける高いレイテンシーとのバランスが取られています。

キャッシュは、データを生成するリソースとサービスの需要を制限するのに役立ちます。存続期間が長く、比較的静的なデータや、生成に「コストがかかる」データに対しては、キャッシュを使用することを検討してください。適切に設計されたソリューションでは、ソリューションのアーキテクチャーのすべての層にキャッシュ・メカニズムが実装されます。キャッシュを論理的に消費者のできるだけ近くに配置して、消費者とキャッシュの通信を制限し、全体的な応答時間を改善します。

アーキテクトは、キャッシュが過剰になる可能性があることを念頭に置く必要があります。キャッシュ・メカニズムの設計が不適切であったり、キャッシュが大きすぎたりすると、ソリューション全体のパフォーマンスに悪影響を及ぼす可能性があります。アーキテクトは、キャッシングの種類と戦略を評価し、パフォーマンス・テストと分析中にキャッシュの効果を測定する必要があります。

メッセージ・キュー、コールバック・モデル、またはその他の手段を使用した非同期メッセージングにより、ソリューションを効率的に拡張できると同時に、リソースが使い果たされた場合に負荷が軽減されるようになります。適切に設計されたソリューションでは、非同期通信、特にメッセージ・キューを活用して、応答性の高いユーザー体験をエンドユーザーに提供し、コンポーネントに障害が発生した場合にユーザー・リクエストが「失われる」のを回避します。この同じメカニズムを使用して、サービス・レベルや稼働時間が異なるシステムを相互接続することもできます。たとえば、メッセージ・キューを備えた、9時から17時まで対応の記録システムに接続されている24時間365日対応アプリケーションでは、記録システムが利用できない場合でも、エンドユーザーの要求を受け入れることができます。

ソリューションは時間の経過とともに変化し、それに伴ってパフォーマンスも変化する可能性があります。開発、テスト、運用の各チームがアプリケーションの性能指標を非侵入的に収集できるようにする性能計測機能を組み込むと、エビデンス主導の手法を使用する堅牢な製品の開発およびテストが可能になります。この計測機能は、機能テストや欠陥分析にも役立ち、ソリューションの性能維持や、本番環境におけるパフォーマンス問題の原因を特定するうえで非常に貴重なツールとなります。構成可能で非侵入型の計測機能は製品モニタリングをサポートし、運用中のソリューションのオブザーバビリティーを確保することで、DevOpsチームとSREチームをサポートします。

ビジネスの観点からは、ソリューション全体のパフォーマンスが重要であり、これを総合的な非機能要件に反映させる必要があります。ただし、事業単位レベルのパフォーマンス・テスト、シフトレフト・パラダイムを実装する初期のパフォーマンス・テスト、パフォーマンス問題の根本原因分析では、個々の呼び出しの継続時間の制限、ネットワーク・レイテンシーなど、低レベルの要件を指定する必要があるかもしれません。

そのため、高レベルのパフォーマンス要件は通常、プロセス・レベルまたはトランザクション・レベルで定められます。たとえば、「融資実行プロセスは2分以内に完了する必要がある」といった場合、個々のプロセス・ステップやサブプロセスのパフォーマンスが最終結果にどのように寄与するかは考慮されません。開発段階でプロセス内の各ステップに目標を割り当てるパフォーマンス予算を作成すると、機能開発チームに測定可能な目標が提供され、潜在的な問題領域を特定し、パフォーマンスの最適化と修復の取り組みを最も有益な部分に集中させることができます。

パフォーマンス予算では、ハードウェアからアプリケーション・コードに至るまで、ソリューションのすべての層を考慮する必要があります。これらのいずれかを省略すると、ソリューションがユーザーの期待に応えられなくなるリスクがあります。

パフォーマンスをテストする際には、実際に試してみることが何よりも重要です。つまり、エンドツーエンドのソリューションをテストしないと、それが要件を満たしていることを確認できません。これは、パフォーマンス分析の総合的な性質を反映しています。個々のコンポーネント（たとえば、データベース、ミドルウェアなど）をテストすると、ソリューションのパフォーマンス分析について貴重な知見が得られ、パフォーマンスのボトルネックを特定できます。しかし、コンポーネント・テストだけでは十分ではありません。コンポーネント間の相互作用によって、予期せぬボトルネックやその他の障害が発生し、最適でない結果が生じる可能性があるからです。

ユーザーの認識に重点を置くということは、主に認識された応答時間とユーザー・インターフェースの全体的な応答性に焦点を当てることを意味します。容量の低下は通常、製品のパフォーマンスに影響が出るまでユーザーには見えません。1968年の研究では、人間とコンピューターのやり取りには次の3つの明確な桁の違いがあることが判明しました。

• 100ミリ秒の応答時間は瞬時として認識されます。人間の平均反応時間は250ミリ秒であるため、これより短いものは非常に高速で瞬時に反応すると認識されます。
• 応答時間が1秒以下であれば、一般的にユーザーはシステムのパフォーマンスによって動作が遅くなっているとは感じないほど十分速いと言えるでしょう。
• 応答時間が10秒を超えると、ユーザーは完全に注意散漫になります。

このことから、2 秒の応答時間が理想的であると考えられ、可能な場合は2秒かそれよりわずかに長い時間がハイブリッドクラウド・ソリューションの適切な応答時間の目標となります。もちろん、ユーザーの期待は、その作業内容によって異なります。例えば、ボタンを押すアニメーションが2秒かかることは誰も期待していませんが、ユーザー向けアプリケーションの場合は、2～3秒が一般的な目標です。

この原則に基づき、ソリューションはユーザー・インターフェース・テスト・ツールを使用して、品質保証サイクルの一環としてユーザー応答時間テストを組み込む必要があります。API呼び出しのレイテンシーは製品全体のパフォーマンスにとって重要ですが、ユーザーが感じるパフォーマンスはユーザーベースを惹きつけ、維持するための鍵となります。

多くの場合、ユーザーは、「優れた」パフォーマンスを構成するものに対してさまざまな期待を抱いています。たとえば、アプリケーションを1日に数回使用する「パワー・ユーザー」と、同じアプリケーションを月に1回使用する人では、パフォーマンスの期待値が大きく異なります。また、ユーザーは「十分なパフォーマンス」とは何かを定量化することに苦労することが多く、「十分な速度」などの要件（これは達成が非常に困難な目標）などにとらわれることもよくあります。また、ユーザー向けの製品のパフォーマンスに対する認識は、人によって異なります。たとえば、一部の人にとっては、10秒のログイン時間は許容されますが（特にこれが単一イベントの場合）、他の人々にとっては、非常に遅すぎる可能性があります（特にログインがワークフローの中で頻繁に行われる場合）。

ユーザーの期待を定量化して管理するには、次のことをお勧めします。

• ユーザーベースと典型的なアプリケーションの使用パターンを十分に理解して、非機能要件を作成してください。
  
  
• ソリューション設計サイクルの早い段階でユーザーに連絡して、どの機能が頻繁に使用され、高い応答性が期待されるのか、またどの機能の使用頻度が低く、応答時間の低下を許容できるのかを把握します。
  
  
• パーセンタイルを使用して、平均または中央値の応答時間のしきい値を定義します。そうすることで、製品の応答性の避けられないランダムな変動を許容し、わずかな外れ値によって製品全体の受け入れが失敗するのを防ぎます。
  
  
• ソリューションの早期リリースとプレビューには、現実的な応答時間のテストとフィードバックを含めてください。ソリューションの開発の最終段階までパフォーマンス・テストを先送りすると、ソリューションのアーキテクチャの大部分を「元に戻す」ことなしには、パフォーマンス上の問題に対処できなくなることがあります。開発サイクルの後半にパフォーマンスの問題を修正するにはコストがかかります。
  
  
• ユーザーがアプリケーションが動作していることを認識できるよう、UIデザインにはスピナーやステータスバーなどの要素を含めるようにしてください。これにより、製品のパフォーマンスが遅いと感じることによる不必要な不満を回避できます。
  
  
• 必要に応じて、類似の「クラス最高」ソリューションに関する調査を実施し、業界の傾向や出版物を分析し、対象分野の専門家にインタビューして、適切な応答時間と容量目標を策定します。

パフォーマンスの境界を監視し、顧客に伝えます。

製品またはソリューション・コンポーネントの誤用や構成ミスは、パフォーマンスの低下やユーザー体験の悪化の原因となる可能性があります。この状況を回避するために、アーキテクトは次のことを行う必要があります。

• ソリューション内のパフォーマンスの制約を認識し、それをあらかじめユーザーに伝えます。たとえば、ソリューションが低速/低帯域の通信チャネルを使用している場合、アーキテクトは、高解像度画像のダウンロードに影響が出ることをエンドユーザーに周知すべきです。

• 可能な場合は、要求がソリューションの設計パラメーターの範囲外にある場合に、システムが検知して通信できるようにします。たとえば、速度の遅いチャネルで大きなファイルをユーザーがダウンロードしようとしたときに、システムでユーザーに能動的に警告するようにします。

パフォーマンス・テストの一般的なアプローチは、想定される最大負荷において、ソリューションが応答時間の目標を満たしているかどうかをテストすることです。これは、想定される最大負荷においてソリューションが良好なパフォーマンスを発揮すれば、それ以下の負荷においても良好なパフォーマンスを発揮するという前提に基づいています。このアプローチの課題は、ほぼ合否判定のように、テストされた最大負荷ごとに1つのデータ点しか得られないことです。

適切に設計されたソリューションは、規模、ユーザー・タイプ、テスト対象機能の組み合わせが異なるさまざまな負荷に対して、応答性を評価するために探索的アプローチを用いてテストされます。これにより、ソリューション・チームは、ソリューション・コンポーネントがどのように相互作用してパフォーマンスや潜在的なボトルネックに影響を与えるか、また、ワークロードの増減に対処するためにソリューションを拡張する方法について、多面的な貴重な情報を得ることができます。

このアプローチにより、予想される負荷目標が変更され、異なる負荷条件下で性能指標を収集する必要がある場合に、追加のテストを回避できます。負荷の大きさに対するパフォーマンスの既存の依存関係の内挿/外挿により、最初にテストされた負荷の範囲内（ゼロからブレークポイントの大きさ、およびそれ以上）のあらゆる負荷に対して性能指標を計算できます。

パフォーマンステストに対する一般的なアプローチは、「特定の負荷/スループットで応答時間を測定する」という単純化されたパターンに従います。このアプローチは、主要なトランザクションのピーク時の応答時間が、既存のサービス・レベル契約（SLA）を満たしているかどうかという問いに答えるものです。また、通常テストされる強度は「低」、「ピーク」、「ストレス」に限定されます。このアプローチでは、一般的な負荷時の応答時間に関する問いには答えられますが、考えられるすべての状況下のシステムのパフォーマンスの全体像を把握することはできません。

より高度な「探索的パフォーマンス・テスト」のアプローチでは、テスト済みソリューションの「パフォーマンス・スナップショット」の作成を目標としています。スナップショットには、単一ユーザーの測定からブレークポイント後の負荷（可能な場合、システムのクラッシュ時を除く）まで、サポートされている最も広い負荷の範囲で収集された包括的な性能指標が含まれます。これには、トランザクションの応答時間、トランザクションとデータ・スループット、および増分負荷条件で収集されたリソース・データの収集が含まれます。「トランザクション」とは、システムによる有限の処理単位を指します。これには、ログインやアカウントの更新といったマクロ・トランザクションから、個々のサブトランザクション（ログイン・トランザクション内の認証呼び出しなど）、あるいは単純なHTTPリクエストまでが含まれます。

包括的なパフォーマンス・データセットであるパフォーマンス・スナップショットには、低負荷の「線形」負荷範囲（この場合、個別に処理されたスレッドが互いの存在を感じず、負荷が増加しても応答時間が長くならない）、負荷の増加に伴って応答時間が長くなる「非線形」範囲、負荷の増加に伴ってスループットの増加が停止し、飽和レベルに達する飽和点、およびスループットが最大に達して応答時間がSLAレベルを超えた後にパフォーマンスが低下するブレークポイント後の範囲に関する上記のメトリクスが含まれます。

負荷の全範囲を網羅するテストは通常、「ピーク」および「ストレス」負荷でのテストや耐久テストを行うのと比べて、テスト・チームはそれほど多くの労力を必要としません。なぜなら、同じテスト・スクリプトが使用されるからです（そして、主な労力は通常、これらのスクリプトを作成することにあります）。しかし、このようなパフォーマンス・スナップショットを作成することには次のようなメリットがあります。

• 「適切な」トランザクション・スループット（「ピーク」または「ストレス」）を生み出す適切なテスト設定を推測するために時間と労力を費やす必要はありません。負荷を段階的に増やし、サポートされているすべての負荷規模とスループットを網羅すればよいのです。

• 応答時間がどの負荷で増加し始めるか、どの負荷でSLAレベルを超えるか、そしてどの負荷でスループットが最大レベルに達するかを特定することができます。

• これにより、システムの処理能力を直接測定することが可能になります。たとえば、ブレークポイント条件が満たされる負荷の大きさ（応答時間がSLAを超過した場合、スループットが最大値に達した場合、あるいはシステムリソースの使用率が指定された「レッドゾーン」に入った場合、たとえば、CPU使用率が90%に達した場合やシステムがクラッシュした場合など、いずれか早い方）を測定できます。つまり、容量分析と計画策定において、典型的な推測に基づくアプローチを使用する必要がないということです。

• 本番運用の予想条件が変化した場合（たとえば、予想される平均負荷とピーク負荷が企業によって再定義された場合）、パフォーマンス・テストを再実行する必要はありません。さまざまな負荷の大きさに対して求められる性能指標は、既存のテスト結果の内挿または外挿によって簡単に取得できます。

• 事前定義された少数の負荷値だけでなく、あらゆる範囲の負荷を網羅することで、システムのパフォーマンスを包括的に把握できるようになり、極端な条件下でのテストを怠ることで生じる可能性のあるパフォーマンス上の問題を見逃すこともなくなります。

• テストにシステム・パフォーマンスのブレークポイントが含まれるようにすることは、パフォーマンスのボトルネックがどこにあるか、負荷が上昇したときに最初にどのリンク、コンポーネント、層が失敗するかを把握できることを意味します。これにより、製品の堅牢性とパフォーマンスを向上させるために、アーキテクチャーおよび設計チームに有益で証拠に基づくフィードバックを提供することができます。

ソリューションに対して実行できるパフォーマンス・テストには複数の種類があります。適切に設計されたソリューションは、それらすべてを利用します。

• 手動ベンチマークは、その名のとおり、ソリューション機能を手動で実行して、ソリューションがユーザーにどのように反応するかを直接感じることができます。
• 校正テストは、自動テスト・ツールの結果を手動テストや組み込みの性能指標などの他のソースと比較し、テスト・スクリプトとテスト・ツールの結果の精度を検証するために実施されるテストです。
• 浸漬試験（耐久テスト）とは、ソリューションに負荷をかけた状態で長時間テストを行い、負荷下でも安定しており、時間の経過とともに劣化せず、確実に動作し、想定通りのリソース消費（つまり、メモリー・リークがないこと）を示すことを確認するものです。
• ピーク・テストでは、たとえば一年で最も忙しい日など、予想されるピーク・ワークロードでソリューションをテストし、ソリューションの安定性を確認し、予想される最大負荷の下での応答時間やリソースなどの主要な測定値を収集します。
• ストレスおよびスパイク・テストは、予想されるピーク負荷の倍数（2倍や3倍など）で短期間に予想されるピーク負荷（ストレス・テスト）、または非常に短時間に高い負荷（スパイク・テスト）でソリューションをテストするために使用されます。これらは、ソリューション内のボトルネックを特定し、ソリューション・チームがソリューション・スケーリングの依存関係を特定するのに役立ちます。
• 負荷変動テスト（ブレークポイント・テスト）は、さまざまな負荷条件でソリューションをテストするために使用され、さまざまな負荷の大きさでのソリューションのパフォーマンスを理解し、ソリューション・チームがソリューション内の傾向とリソースの制限を発見するのに役立ちます。これらのテストでは、製品のブレークポイントの登録、ソリューションの容量の測定、製品の最も弱いコンポーネント（故障する可能性が最も高いコンポーネント）の検出も可能です。

テストで取得するさまざまなパフォーマンス・データを最大限に活用することを目指します。

• 創造的かつ探索的な方法でテスト結果を分析します。「what-if」アプローチを使用して、追加のシナリオを調査します。
• パフォーマンスをさまざまな規模やアーキテクチャーの環境にマッピングして、さまざまなプラットフォームや導入環境におけるソリューションの結果を予測します。
• 予期しないパターンや傾向（負荷が「増加」するとトランザクション・レートが「低下」するなど）を検出して、取得したパフォーマンス・データの不一致を検出します。
• 想定される使用パターンに基づいて、測定されたシステム容量と対応するユーザーベースの規模を関連付けるために、モデリング技術を使用します。
• 本番環境で同時に実行できるさまざまなワークフローについては、パフォーマンスへの相互の影響を常に評価することを忘れないでください。
• パイロット・プロジェクトから単体テストや機能テスト、DevOpsやサイト信頼性エンジニアリングのゴールデン・シグナルまで、さまざまなパフォーマンス・データ・ソースを使用します。パフォーマンス分析に関しては、どのようなデータでも価値があります。
• 分析の結果を利害関係者と共有します。多くの場合、他のユーザーから有益な情報を得るのに役立ち、パフォーマンスのテストと分析の進行状況についての認識を向上させ、他のユーザーがパフォーマンスや容量の分析などの「技術」領域をより深く理解するのに役立ち、機能以外の検証作業全体の可視性を向上させます。