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

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

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

• なぜこの動作がテスト中に現れなかったのか。
• どうやって直すか。

最初の質問の答えは単純です。 テスト環境で、実際のユーザーをその行動パターン、および実行する可能性がある作業のボリュームとともにシミュレートするのは困難です。 システムが負荷の下でどのように動作するかを理解する確実な方法は、実稼働環境で観察することだけです。 パフォーマンス テストを省略するようにお薦めしているのではないことに注意してください。 パフォーマンス テストはベースラインのパフォーマンス メトリックを得るために不可欠です。 しかし、パフォーマンスの問題が稼働中のシステムで発生した際に観察して解決できるように準備しておく必要があります。

この状況を直す方法という 2 つ目の質問の回答は単純ではありません。 いくつもの要因が関係している可能性があり、場合によっては特定の状況のみで問題が発生します。 インストルメント化とログは根本原因を突き止めるために重要ですが、何を調べるべきかを知ることも必要です。

マイクロソフトでは、Microsoft Azure の顧客エンゲージメントに基づいて、お客様が実稼働環境で目にする一般的なパフォーマンスの問題の一部を特定しています。 各アンチパターンについて、一般的にそのアンチパターンが発生する理由、アンチパターンの症状、問題を解決する方法を説明します。 また、アンチパターンと推奨されるスケーラビリティ ソリューションの両方を示すサンプル コードも提供しています。

説明を読むとアンチパターンのいくつかはあまりにも明白なために回避できそうですが、想像するよりも頻繁に発生しています。 アプリケーションは、オンプレミスで機能していたがクラウドでは拡張しない設計を継承することがあります。 あるいは、アプリケーションの開発当初は設計がきわめて明確だったが、新しい機能が追加されるにつれて、このようなアンチパターンが知らない間に入り込むことがあります。 いずれにせよ、このガイドではアンチパターンを見つけて直す方法を説明します。

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

特定できたアンチパターンの一覧を次に示します。

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

次のステップ

パフォーマンスチューニングの詳細については、「分散アプリケーションのパフォーマンス チューニング」を参照してください