次の方法で共有


クラウド アプリケーションのパフォーマンス テストとアンチパターン

パフォーマンスのアンチパターンは、設計パターンと同様に、組織内の一般的な欠陥のあるプロセスと実装です。 これらは、アプリケーションに負荷がかかっているときにスケーラビリティの問題を引き起こす可能性がある一般的なプラクティスです。 これらのプラクティスを認識することで、ソフトウェアの実践者間の高度な概念のコミュニケーションを簡素化できます。また、アンチパターンに関する知識は、コードを確認したり、パフォーマンスの問題を診断したりする際に役立ちます。

一般的なシナリオを次に示します。アプリケーションはパフォーマンス テスト中に適切に動作します。 運用環境にリリースされ、実際のワークロードの処理が開始されます。 ここで、ユーザー要求の拒否、失速、例外のスローなど、パフォーマンスが悪化し始めます。 その後、開発チームは次の 2 つの質問に直面します。

  • テスト中にこの動作が表示されなかったのはなぜですか?
  • どのように修正しますか。

最初の質問に対する答えは簡単です。 テスト環境で実際のユーザーをシミュレートすることは、動作パターンや実行される可能性のある作業量と共に困難です。 負荷の下でシステムがどのように動作するかを完全に確実に理解する唯一の方法は、運用環境でそれを観察することです。 明確にするために、パフォーマンス テストをスキップする必要はありません。 パフォーマンス テストは、ベースライン パフォーマンス メトリックを取得するために不可欠です。 ただし、ライブ システムで発生したパフォーマンスの問題を観察して修正する準備をしておく必要があります。

2 番目の質問に対する答え、問題を解決する方法は、あまり簡単ではありません。 さまざまな要因が影響を受け、場合によっては特定の状況でのみ問題が発生することがあります。 インストルメンテーションとログ記録は根本原因を見つける上で重要ですが、何を探すべきかも把握しておく必要があります。

Microsoft Azure のお客様とのエンゲージメントに基づいて、お客様が運用環境で見られる最も一般的なパフォーマンスの問題のいくつかを特定しました。 各アンチパターンについて、アンチパターンが通常発生する理由、アンチパターンの症状、および問題を解決するための手法について説明します。 また、アンチパターンと推奨されるスケーラビリティ ソリューションの両方を示すサンプル コードも提供します。

これらのアンチパターンの中には、説明を読むと明白に思えるものもありますが、思ったよりも頻繁に発生します。 アプリケーションは、オンプレミスで動作したが、クラウドではスケーリングしない設計を継承する場合があります。 または、アプリケーションは非常にクリーンな設計で始まるかもしれませんが、新機能が追加されると、これらのアンチパターンのいくつかが徐々に忍び込んできます。 関係なく、このガイドは、これらのアンチパターンを特定して修正するのに役立ちます。

アンチパターンのカタログ

識別したアンチパターンの一覧を次に示します。

アンチパターン 説明
ビジーデータベース データ ストアへの処理のオフロードが多すぎます。
ビジー状態のフロント エンド リソースを集中的に使用するタスクをバックグラウンド スレッドに移動する。
おしゃべりなI/O 多数の小さなネットワーク要求を継続的に送信します。
無駄なフェッチ 必要以上のデータを取得すると、不要な I/O が発生します。
不適切なインスタンス化 共有および再利用するように設計されたオブジェクトを繰り返し作成および破棄します。
モノリシック永続化 使用パターンが非常に異なるデータに対して同じデータ ストアを使用する。
キャッシュしない データをキャッシュできない。
騒がしい隣人 1 つのテナントでは、リソースの量が不均衡に使用されます。
再試行ストーム 失敗した要求をサーバーに再試行する頻度が高すぎます。
同期 I/O I/O の完了中に呼び出し元スレッドをブロックします。

次のステップ

パフォーマンス チューニングの詳細については、「Well Architected Framework のパフォーマンス効率」を参照してください。