パフォーマンスの達成と維持
 システムの使用中やシステムの進化に伴うパフォーマンスの低下から保護します。 |
|---|
開発は、一度きりの作業ではありません。 継続して行うプロセスです。 機能が変更されたら、パフォーマンスの変更も想定しておきましょう。 ユーザーのパターンやプロファイルはさまざまですが、他の Azure Well-Architected の柱の最適化からの変更もさまざまです。 変更が行われると、ワークロード リソースに負担が生じかねません。
変更からシステムを保護して、パフォーマンス目標が後退しないようにします。 開発プロセスでテストと監視を統合します。 実負荷を使用して運用環境でのシステムのパフォーマンスをテストし、運用前の自動テストでその負荷をシミュレートします。 どちらの場合も、検証に向けた監視プラクティスの実施が必要です。
開発ライフサイクル全体を通して、さまざまなステージでさまざまな種類のテストを実施します。 最初のステージでは、概念実証をテストして、パフォーマンスの結果がまったくの予想外ではないことを確認します。 開発の進行に従い、手動の、作業量が少ないテストを実施して、ベンチマークを確立します。 ビルド ステージでは、自動ルーチン パフォーマンス テストの開発を開始します。このテストでは、待機時間、ストレス レベル、負荷容量に加え、テスト計画に定義されているその他の特性を評価します。
監視は、このような作業で決して欠くことのできない部分であり、別個に実施するものではありません。 システムとそのリソースのパフォーマンスを時系列で確認できます。 次に、微調整を行い、それらの価値を最大限に高めて、パフォーマンス基準を満たし続けられるようにします。
パフォーマンス目標は、変更に応じて、時間の経過とともに変わってゆくことを念頭に置いておきましょう。 テスト済みで監視対象のメトリックに基づいて、パフォーマンス モデルを更新します。 増加、減少、影響なしなど、フローのパフォーマンスに対する影響を明確に示します。
ビジネス関係者との再交渉や期待値の再設定については、常に準備を整えておきましょう。
サンプル シナリオ
Contoso Event Solutions では、モバイル デバイスでチケットをスキャンして承認された人たちがチケットを持って会場にすばやく入場できるようにイベントの入場口のスタッフが使用する製品を提供しています。 このシステムは、完全なオフライン モードでも、チケットの複製が懸念される会場向けのクラウド接続バージョンとしても、どちらでも使用できます。 オフライン モードは高パフォーマンスですが、オンライン モードはパフォーマンス目標に達していませんでした。 近頃、開発チームが、いくつかの開発サイクルをつぎ込んでこれに取り組んだところ、今ではパフォーマンスが大幅に向上し、目標を達成するようになりました。 ビジネス関係者は、より大きな会場に対応するための顧客ベースを、すぐにでも拡大したいと考えています。
開発時のパフォーマンスのテスト
リリース プロモーションおよび運用環境への最終デプロイを承認または却下する品質ゲートとして、パフォーマンス テストを正式化します。
次のチェックポイントを使用すると、デプロイの各ステージで必要なパフォーマンス基準を確実に満たしたうえで、次に進むことができます。 チェックポイントは、意図しないパフォーマンスの低下を防ぐのに役立ちます。 たとえば、パフォーマンスが予想を大幅に下回っている場合は、改善が実施されるまでリリースをブロックできます。
"Contoso の課題"
- チームは、このアプリケーションのオンライン バージョンのパフォーマンスが許容可能なレベルを達成できるように、並々ならぬ時間と労力をつぎ込んできましたが、今のところ、低下を防ぐためのシステムはありません。
- 次に追加を予定している機能は、追加認証のスキャンと併せて、参加者の写真の提示を会場でオプトインできる機能です。 写真の検索とダウンロードが追加となり、プロセスに時間がかかるというリスクがあります。
- 正式なプロセスがなければ、オンライン バージョンとオフライン バージョンの両方のパフォーマンスが、追加機能による悪影響を受けて目標を下回るかもしれないというリスクがあります。
"アプローチの適用と結果"
- チームは、自動パフォーマンス テストをビルド パイプラインに統合しています。 厳密なパフォーマンスベースの "go/no-go" 条件をビルド パイプラインに実装することで、チームは、パフォーマンスの低下を伴う新機能はリリースされないという確信を強めています。
- チームは、ビルドの最新バージョンでバグをキャッチしたため、賢明にもこのテストを実装しました。 このバグにより、アプリでは画像をダウンロードしようとしてインターネットへの接続が強制的に試行されましたが、スキャナーがオフライン モードに設定されていたため、チケットをスキャンするたびにタイムアウトが発生していました。 自動テストでこのバグをキャッチしたことで、チームは、新しいバージョンをリリースする前にこのバグを修正することができました。
監視による最適化
運用環境の実際のトランザクションとパフォーマンス目標からの偏差を監視するための反復可能なプロセスを設定します。 さらに、運用環境で代理トランザクションを使用し、パフォーマンスの低下に関する監視アラートを設定します。
テストではシミュレートできない実際の負荷下でのシステムの実際のパフォーマンスについての分析情報が必要です。 そのうえで、潜在的なボトルネック、使用率の低いリソース、およびその他の懸念事項など、問題や改善の領域を事前に特定することができます。
"Contoso の課題"
- オンライン チケット検証を使用しているイベントでは、バックエンド システムを頻繁に使用します。
- アプリケーション パフォーマンス監視 (APM) システムはありますが、運用環境のトランザクションの正常性の監視には使用されてきませんでした。
"アプローチの適用と結果"
- チームは、正常性メトリックをより適切にキャプチャするために、更新されたプロセスを採用することにしました。
- パフォーマンスのパーセンタイルに基づくとともにパフォーマンスの外れ値に対して、アラートを構成しています。 ほとんどのチケット スキャンでは、システムが許容可能な範囲内で実行されていることを示すアラートはありません。
- オフライン イベントが完了すると、チケット スキャンのテレメトリがバッチでアップロードされ、これらのメトリックに対して、許容可能なパフォーマンスからの偏差を探すプロセスが完了します。
- また、チームでは、代理トランザクション テストを実装して、パフォーマンスの監視を強化しています。 ほとんどすべてのイベントは週末や夜に行われるので、チームでは、1 週間を通して代理トランザクション テストを使用して、より一貫性の高いパフォーマンス ベースラインを生成しています。
ワークロードの変更のインテリジェントな処理
経時的な使用量の増加、機能の変更、データの蓄積に伴うパフォーマンスの低下に対処し、パフォーマンスを維持します。 微調整を行っても短期的なメリットしか得られない場合は、期待値をリセットし、新しい目標を立てます。
このアプローチの採用により、パフォーマンスの低下が問題へと発展して許容可能な範囲を超える悪影響がユーザー エクスペリエンスに及ぶ前に、パフォーマンスの状態を維持することができます。
目標を変更すると、パフォーマンス モデルがリセットされるとともに、既に容量に達しているシステムの最適化に時間を無駄に費やすことがなくなります。
"Contoso の課題"
- 営業チームは、新しいイベント会場を積極的にシステムにオンボードしてきました。 ビジネスは順調です。
- 新しい機能を導入していないにもかかわらず、パフォーマンスの予算が徐々に増加していることに、ワークロード監視システムは気づき始めています。
- 変更が行われなければ、この軌道は許容しがたいパフォーマンスの低下を引き起こす可能性があり、インシデントが発生した場合には、ワークロードが停止する危険があります。
"アプローチの適用と結果"
- オンボードする顧客の増加に伴い、オンライン イベントのデータ検索メカニズムによって、多数のクエリに対してデータが非常に大規模にスキャンされていることに、チームは気づいています。
- 一部のクエリの最適化では、使用量が増加しても、それ以上損害が生じないようにすることができました。 今後数か月間で、チームは、クエリ スキャンの必要性を軽減するために、さまざまなイベントをさまざまなデータ パーティションに分割することを予定しています。 これを行うと、ワークロードからの継続的なスケールアウトがサポートされます。
- また、以前のイベントのチケット データを削除して、システムをさらに最適化して拡張できることについても認識しています。 以前のイベントの検索は、チケット検証システムで行う必要がありません。そのため、レポートと履歴検索専用のストアにデータを移動することができます。