次の方法で共有

コードとインフラストラクチャを最適化するための推奨事項

  • [アーティクル]

この Azure Well-Architected Framework パフォーマンス効率チェックリストの推奨事項に適用されます。

PE:07 コードとインフラストラクチャを最適化します。 パフォーマンスの高いコードを使用し、プラットフォームに責任をオフロードします。 コードとインフラストラクチャは、コア目的でのみ使用し、必要な場合にのみ使用します。

このガイドでは、コードとインフラストラクチャのパフォーマンスを最適化するための推奨事項について説明します。 コードとインフラストラクチャを最適化するには、コンポーネントをコア目的にのみ使用し、必要な場合にのみ使用する必要があります。 コードとインフラストラクチャを過剰に使用すると、不要なリソース消費、ボトルネック、応答の遅さを生み出します。 これらの非効率性を補うためには、同じタスクを実行するためにさらにリソースを追加する必要があります。

定義

期間 定義
コンカレンシー 複数のタスクまたはプロセスが一度に実行されるが、必ずしもまったく同時に実行されない場合。
CPU アーキテクチャ コンピューターの動作に影響を与えるコンポーネントと原則。
データ圧縮 冗長データを最小限に抑えることでファイルのサイズを小さくするアクション。
ヒープ ランタイム メモリ割り当てに使用されるメモリ内の領域。
メモリ リーク メモリが不要になった後に、ワークロードが割り当てられたメモリを解放できない場合。
Parallelism 複数のタスクまたはプロセスが同時に実行される場合。

主要な設計戦略

コードとインフラストラクチャを最適化するには、コードとサポート インフラストラクチャを微調整してパフォーマンス効率を向上させる必要があります。 タスクをすばやく実行し、リソースを無駄にしないパフォーマンスの高いコードが必要です。 不要な複雑さを回避するために合理化された適切に設計されたインフラストラクチャが必要です。 ワークロードでは、プラットフォーム固有の機能を使用する必要があります。 これは、コードとインフラストラクチャの両方が主にコア目的で使用され、必要な場合にのみ使用されるようにするのに役立つアプローチです。

コードのパフォーマンスを最適化する

コードのパフォーマンスを最適化するには、リソースの使用量を減らし、ランタイムを最小限に抑え、パフォーマンスを向上させるためにコードを変更します。 コードを変更して、ソフトウェア プログラムの効率と速度を向上させることができます。 ブルート フォースでパフォーマンスの問題をマスクしないでください。 ブルート フォースとは、ソースに対処する代わりに容量を追加するなどの、コードのパフォーマンスを補うためにコンピューティング リソースを追加することを意味します。 最適化に関するパフォーマンスの問題を修正する必要があります。 コードのパフォーマンスを最適化すると、システム リソースの使用率を最大化し、応答時間を改善し、待機時間を短縮し、ユーザー エクスペリエンスを向上させることができます。

コードをインストルメント化する

コードのインストルメント化とは、実行時にデータを収集し、コードのパフォーマンスを監視するコードにコード スニペットまたはライブラリを追加する方法を指します。 コード インストルメンテーションを使用すると、開発者はリソース消費 (CPU、メモリ使用量) や実行時間などの主要なメトリックに関する情報を収集できます。 コードをインストルメント化することで、開発者はコードのホット パスに関する分析情報を取得し、パフォーマンスのボトルネックを特定し、パフォーマンス効率を向上させるためにコードを最適化できます。

理想的な環境では、ソフトウェア開発ライフサイクルの早い段階でコード分析を行う必要があります。 コードの問題を早く見つけたほど、修正する方が安くなります。 このコード分析を可能な限り自動化したいと考えています。 動的および静的コード分析ツールを使用して、手作業を減らします。 ただし、このテストはまだ運用環境のシミュレーションであることに注意してください。 運用環境では、コードの最適化を最も明確に理解できます。

トレードオフ: コード監視ツールによってコストが増加する可能性があります。

ホット パスを識別する

コードをインストルメント化することで、さまざまなコード パスのリソース消費量を測定できます。 これらの測定値は、ホット パスを識別するのに役立ちます。 ホット パスは、パフォーマンスとリソースの使用に大きな影響を与えます。 これらは、高パフォーマンスと低待機時間を必要とするプログラムの重要なセクションまたは頻繁に実行されるセクションです。 コード ホット パスを識別するには、次の手順を検討します。

  • ランタイム データの分析: ランタイム データを収集し、それを分析して、CPU、メモリ、I/O 操作など、重要なリソースを消費するコードの領域を特定します。 頻繁に実行されるコードのパターンまたはセクションを探すか、完了するまでに時間がかかります。

  • パフォーマンスの測定: プロファイリング ツールまたはパフォーマンス テスト フレームワークを使用して、さまざまなコード パスの実行時間とリソース消費量を測定します。 これは、ボトルネックと改善のための領域を特定するのに役立ちます。

  • ビジネス ロジックとユーザー効果を考慮する: アプリケーションの機能または重要なビジネス操作との関連性に基づいて、さまざまなコード パスの重要性を評価します。 ユーザーに価値を提供したり、パフォーマンス要件を満たすのに重要なコード パスを決定します。

コード ロジックを最適化する

コード ロジックの最適化は、リソースが少ないタスクを実行するようにコードの構造と設計を調整することです。 ロジックが改善され、不要な操作が減ります。 より少ないリソース消費で高速な実行が作成されます。 パフォーマンスに影響を与える可能性があるコード パス内の不要な操作は削除する必要があります。 ホット パスの最適化に優先順位を付けて、最大のパフォーマンス効率の向上を確認します。 コード ロジックを最適化するには、次の方法を検討します。

  • 不要な関数呼び出しを削除する: コードを確認し、目的の機能に不可欠でなく、パフォーマンスに悪影響を及ぼす可能性がある関数を特定します。 たとえば、関数呼び出しがコードの前に完了した検証を実行した場合、不要な検証関数呼び出しを削除できます。

  • ログ記録操作を最小限に抑える: ログ記録はデバッグと分析に役立ちますが、過剰なログ記録はパフォーマンスに影響を与える可能性があります。 各ログ操作の必要性を評価し、パフォーマンス分析に重要ではない不要なログ呼び出しを削除します。

  • ループと条件を最適化する: コード内のループと条件を分析し、不要なイテレーションまたは不要な条件を特定します。 これらの構造を簡略化して最適化すると、コードのパフォーマンスが向上します。 ループ内の関数呼び出しを最小限に抑え、冗長な計算を排除します。 計算をループ外に移動するか、ループのアンロールを使用することを検討してください。

  • 不要なデータ処理を減らす: 冗長な計算や変換など、不要なデータ処理操作についてコードを確認します。 これらの不要な操作を排除して、コードの効率を向上させます。

  • データ構造を最適化します。 データを効率的に格納および取得するには、配列、リンク リスト、ツリー、ハッシュ テーブルなどの適切なデータ構造を選択します。 特定の問題に最適なデータ構造を選択します。 適切なデータ構造により、アプリケーションのパフォーマンスが向上します。

  • ネットワーク要求を最小限に抑える: コードでネットワーク要求を行う必要がある場合は、要求の数を最小限に抑え、使用を最適化します。 可能な場合はバッチ要求を行い、不要なラウンド トリップを回避してパフォーマンスを向上させます。

  • 割り当てを最小限に抑える: 過剰なメモリ割り当てが発生する領域を特定します。 不要な割り当てを減らし、可能な場合は既存のリソースを再利用することで、コードを最適化します。 割り当てを最小限に抑えることで、メモリ効率と全体的なパフォーマンスを向上させることができます。 プログラミング言語に適したメモリ管理とガベージ コレクション戦略を使用します。

  • データ構造のサイズを小さくする: クラスなどのデータ構造のサイズを評価し、削減できる領域を特定します。 データ要件を確認し、不要なフィールドやプロパティを排除します。 適切なデータ型を選択し、データを効率的にパッキングすることで、メモリ使用量を最適化します。

  • パフォーマンス最適化 SDK とライブラリを使用します。 ネイティブ SDK またはパフォーマンス最適化ライブラリを使用します。 ネイティブ SDK は、プラットフォームまたはフレームワーク内のサービスとリソースと対話するように設計されています。 たとえば、クラウドネイティブ SDK は、カスタム API アクセスよりもクラウド サービス のデータ プレーンで優れた動作をします。 SDK は、ネットワーク要求の処理と対話の最適化に優れています。 Math.NET などのパフォーマンス最適化ライブラリには、パフォーマンス最適化関数が含まれています。 関数を適切に適用すると、ワークロードのパフォーマンスを向上させることができます。

  • クロスカット実装: ミドルウェアやトークン チェックなどのクロスカット実装の影響を考慮し、パフォーマンスに悪影響を与えるかどうかを評価します。

使用しているプログラミング言語に固有のパフォーマンスに関する推奨事項を確認します。 これらの推奨事項に対してコードを評価して、改善のための領域を特定します。

トレードオフ:

  • コードとホット パスを最適化するには、コードの非効率性を識別するための開発者の専門知識が必要であり、他のタスクに必要な高度なスキルを持つ個人である可能性があります。
  • SDK は利便性を提供し、API との対話の複雑さを排除します。 ただし、SDK では、カスタム コードの制御オプションとカスタマイズ オプションが制限される場合があります。

メモリ管理を最適化する

メモリ管理を最適化するには、効率を向上させるために、ワークロードでメモリ リソースを使用、割り当て、解放する方法を調整する必要があります。 適切なメモリ管理により、メモリ操作のオーバーヘッドが軽減されるため、コードのパフォーマンスが向上します。 効率的なメモリ使用量により、待機時間が短縮され、システムの速度低下やクラッシュが防止され、計算タスクのスループットが最大化されます。 メモリ管理を最適化するには、次の戦略を検討してください。

メモリの問題をデバッグします。 メモリ ダンプは、アプリケーション メモリ スナップショットです。 特定の時点でのアプリケーションのメモリ状態をキャプチャします。 メモリ ダンプを使用すると、メモリ関連の問題を振り返って分析できます。 診断しようとしている問題の性質と使用可能なリソースに基づいて、適切な種類のメモリ ダンプを選択します。 ルーチン デバッグにはミニチュア ダンプを使用し、複雑で重大な問題については完全ダンプを使用する必要があります。 この戦略では、リソースの使用状況と診断機能のバランスが取られます。 多くのコード ホスティング サービスでは、メモリ デバッグがサポートされています。 そうでないサービスよりも、メモリ分析をサポートするサービスを優先する必要があります。 メモリの問題をデバッグするための基本的な手順を次に示します。

  1. メモリ ダンプのキャプチャ: まず、アプリケーションの実行時にメモリ ダンプをキャプチャするメカニズムを設定します。 キャプチャは、手動、自動的、または特定の条件 (過剰なメモリ消費など) が満たされたときにトリガーできます。 一部のクラウド サービスでは、このプロセスが既に提供されている場合があります。

  2. メモリ ダンプの分析: メモリ ダンプを収集した後、それらを分析します。 Windows アプリケーションの WinDbg や Unix ベースのシステムの GDB など、これらのダンプの検査に役立つツールが多数あります。

  3. メモリ リークの特定: 分析中のメモリ リークの特定に重点を置く。 メモリ リークは、アプリケーションがメモリを割り当てるが、メモリが不要になったときに解放できない場合に発生します。 割り当てを解除する必要がある場合でも、メモリに残っているオブジェクトまたはデータ構造を検索します。

  4. 修正とテスト: 問題のあるコードを特定したら、メモリの問題の解決に集中します。 解決策には、メモリの正しい解放、データ構造の最適化、またはメモリ管理プラクティスの再評価が含まれる場合があります。 ソリューションの有効性を確認するために、厳密なテストを実施していることを確認します。

  5. 反復処理と監視: メモリ管理は継続的なプロセスです。 アプリケーションのメモリ使用量を定期的に監視し、運用環境でのメモリ ダンプの収集に保持します。 分析と最適化の段階を定期的に見直して、後続のコード変更でメモリの問題が再び表示されないようにします。

ソフトウェア開発ライフサイクルにメモリ ダンプ分析を組み込むことで、アプリケーションの信頼性と効率を向上させることができます。 これは、運用環境でメモリ関連の問題が発生する可能性を減らすのに役立ちます。

メモリ割り当てを減らします。 メモリ割り当てを最小限に抑えて、コードの全体的なメモリ占有領域を減らします。 ワークロードでは、使用可能なメモリを効率的に利用できます。 ガベージ コレクターが未使用のメモリを再利用する必要が少なくなり、ガベージ コレクション サイクルの頻度と期間が短縮されます。 メモリ割り当ては、特に頻繁に実行する場合にコストがかかる場合があります。 メモリ割り当てを最小限に抑え、コードを迅速かつ効率的に実行できるようにします。

キャッシュは、頻繁にアクセスされるデータをプロセッサの近くに格納するため、パフォーマンスが向上します。 メモリ割り当てを最小限に抑えると、キャッシュ領域の競合が少なくなり、キャッシュを効果的に利用できます。 メモリ割り当てが多い場合、アプリケーションのパフォーマンスが低下し、エラーが発生する可能性があります。 メモリ割り当てを最小限に抑えるその他の方法は次のとおりです。

  • ローカル変数: メモリ消費量を最小限に抑えるには、グローバル変数の代わりにローカル変数を使用します。

  • 遅延初期化: 必要になるまでオブジェクトまたはリソースの作成を延期する遅延初期化を実装します。

  • バッファー: バッファーを効果的に管理して、大きなメモリ バッファーの割り当てを回避します。

  • オブジェクト プール: ラージ オブジェクトを割り当ておよび割り当て解除する代わりに、オブジェクト プールを使用して再利用することを検討してください。

詳細については、「 メモリ割り当てを減らす 」と 「Windows システムのラージ オブジェクト ヒープ」を参照してください。

コンカレンシーと並列処理を使用する

コンカレンシーと並列処理を使用するには、コンピューティング リソースを効率的に使用するために、複数のタスクまたはプロセスを同時に、または重複する方法で実行する必要があります。 これらの手法により、全体的なスループットと、ワークロードで処理できるタスクの数が増加します。 タスクを同時または並列に実行すると、アプリケーションの実行時間が短縮され、待機時間が短縮され、応答時間が増加します。 コンカレンシーと並列処理により、CPU コアや分散システムなどのコンピューティング リソースを効率的に利用できます。 コンカレンシーと並列処理は、コンピューティング リソース間でワークロードを効果的に分散します。

並列処理を使用します。 並列処理とは、複数のコンピューティング リソースで複数のタスクまたはプロセスを同時にトリガーするシステムの機能です。 並列処理により、ワークロードが並列で実行される小さなタスクに分割されます。 並列処理を実現するには、マルチプロセッサや分散コンピューティングなどの手法を使用します。 マルチコア プロセッサ間でタスクを分散して、ワークロード管理を最適化します。 CPU アーキテクチャ、スレッド モデル、マルチコア プロセッサを利用するようにコードを最適化します。 コードを並列で実行すると、ワークロードが複数のコアに分散されるため、パフォーマンスが向上します。

コンカレンシーを使用します。 コンカレンシーは、システムが複数のタスクまたはプロセスを実行する機能です。 コンカレンシーを使用すると、プログラムのさまざまな部分が個別に進行し、全体的なパフォーマンスを向上させることができます。 複数のスレッドが 1 つのプロセス内で同時に実行されるマルチスレッドなどの手法を使用して、コンカレンシーを実装できます。 また、タスクが同時にトリガーされる非同期プログラミングを使用することもできます。

  • 非同期プログラミング: 非同期プログラミングは、メイン スレッドをブロックせずにタスクをトリガーする方法です。 非同期プログラミングを使用すると、実行時間の長い操作が完了するまで待機している間に、プログラムでタスクをトリガーできます。 非同期プログラミングを使用すると、プログラムは複数のタスクを開始し、非同期的に完了するまで待機できます。 プログラムは、各タスクが完了するのを待ってから次のタスクに進む必要はありません。

    プログラミング言語とプラットフォームに応じて、多くの非同期プログラミング手法とパターンがあります。 一般的な方法の 1 つは、C# のような言語で、 や などのasyncawait非同期キーワードとコンストラクトを使用することです。 これらのキーワードを使用すると、非同期メソッドを定義できます。 HTTP トラフィックの場合は、 非同期 Request-Reply パターンの使用を検討してください。

    多くのフレームワークとライブラリでは、非同期プログラミングのサポートが組み込まれています。 たとえば、.NET プラットフォームでは、 タスク ベース の非同期パターンやイベント ベースの非同期パターンなどのパターンを使用して非同期操作 を実装できます。 非同期プログラミングの具体的な実装は、アプリケーションのプログラミング言語、プラットフォーム、要件によって異なります。

  • キュー: キューは、要求コンポーネント (プロデューサー) とワークロードの処理コンポーネント (コンシューマー) の間にあるストレージ バッファーです。 1 つのキューに対して複数のコンシューマーが存在する場合があります。 タスクが増えるにつれて、需要に合わせてコンシューマーをスケーリングする必要があります。 プロデューサーは、タスクをキューに配置します。 キューは、コンシューマーが容量を持つまでタスクを格納します。 多くの場合、キューは、需要のピークを経験する処理サービスに作業を渡す最善の方法です。 詳細については、「 キューベースの負荷平準化パターン 」および 「ストレージ キューと Service Bus キュー」を参照してください。

接続プールの使用

接続プールは、すべての要求に対して新しい接続を作成するのではなく、確立されたデータベース接続を再利用する方法です。 データベースへの接続を確立するとコストがかかる場合があります。 リモート データベース サーバーへの認証されたネットワーク接続を作成する必要があります。 データベース接続は、新しい接続を頻繁に開くアプリケーションでは特にコストがかかります。 接続プールは既存の接続を再利用し、要求ごとに新しい接続を開くコストを削減します。 接続プールにより、接続の待機時間が短縮され、サーバー上で高いデータベース スループット (1 秒あたりのトランザクション数) が可能になります。 現在よりも多くの接続を処理できるプール サイズを選択する必要があります。 目標は、接続プールで新しい受信要求をすばやく処理することです。

接続プールの制限について理解します。 一部のサービスでは、ネットワーク接続の数が制限されます。 この制限を超えると、接続の速度が低下したり終了したりする可能性があります。 接続プールを使用して、起動時に固定の接続セットを確立し、それらの接続を維持できます。 多くの場合、既定のプール サイズは、基本的なテスト シナリオで迅速に実行される少数の接続のみで構成される場合があります。 アプリケーションでは、スケールの下で既定のプール サイズが使い果たされ、ボトルネックが発生する可能性があります。 各アプリケーション インスタンスでサポートされている同時実行トランザクションの数にマップされるプール サイズを確立する必要があります。

接続プールをテストします。 各データベースとアプリケーション プラットフォームには、プールの設定と使用に関する要件が若干異なります。 接続プールをテストして、負荷の下で効率的に動作することを確認します。

リスク: 接続プールによってプールの 断片化 が発生し、パフォーマンスが低下する可能性があります。

バックグラウンド ジョブを最適化する

多くのアプリケーションでは、UI とは無関係に実行されるバックグラウンド タスクが必要です。 アプリケーションはジョブを開始し、ユーザーからの対話型要求の処理を続行できます。 バックグラウンド ジョブの例としては、バッチ ジョブ、プロセッサを集中的に使用するタスク、実行時間の長いプロセス (ワークフローなど) などがあります。 バックグラウンド タスクでは、アプリケーションをブロックしたり、システムの負荷が高いときに操作が遅れたために不整合が発生したりしないでください。 パフォーマンスを向上させるために、バックグラウンド タスクをホストするコンピューティング インスタンスをスケーリングできます。 詳細については、「 バックグラウンド ジョブ 」と 「スケーリングとパフォーマンスに関する考慮事項」を参照してください。

インフラストラクチャのパフォーマンスを最適化する

インフラストラクチャのパフォーマンスを最適化することは、ピーク時の運用とワークロードに対するリソースの最適な使用を確保するために、インフラストラクチャ要素を強化および調整することを意味します。 インフラストラクチャを微調整することで、無駄を最小限に抑え、ラグを減らし、利用可能なリソースでより多くのことを実現できます。 これにより、ワークロードが確実かつ迅速に実行され、ユーザー エクスペリエンスが向上し、コストが削減されます。 インフラストラクチャのパフォーマンスを最適化するには、次の戦略を検討してください。

使用制限を追加します。 一部のワークロード コンポーネントに使用制限を実装できます。 たとえば、不安定なポッドを削除するには、Azure Kubernetes Service (AKS) でポッドの CPU とメモリの制限を定義できます。 パフォーマンスを最適化するために、 Java 仮想マシン (VM) でメモリ制限を定義できます。

インフラストラクチャを合理化します。 ワークロードを簡素化して、相互作用、依存関係、互換性の問題の可能性を減らします。 ワークロードを簡素化する場合は、メモリ、処理能力、ストレージのリソース使用率を最適化します。

負荷が過剰な場合は軽減します。 ワークロードの負荷を軽減するには、アプリケーションに対する要求を最小限に抑え、リソースがプライマリ タスクを実行できるようにします。 たとえば、コード内または個々のコンピューティング インスタンスでセキュリティ ソリューションを実行しないようにするのが一般的です。 代わりに、Web サーバーは HTTP 要求を処理する必要があります。 Web アプリケーション ファイアウォールとゲートウェイ リソースは、セキュリティ チェックを処理できます。 次の戦略は、ワークロードの負荷を軽減するのに役立ちます。

  • 最終的な整合性: 最終的な整合性モデルを採用して、データを少し日付付けできるようにすることでパフォーマンスを向上させます。 最終的な整合性により、一定のデータ更新に対する CPU サイクルとネットワーク帯域幅に対する即時の需要が減少します。

  • 委任タスク: サーバー タスクをクライアントまたは仲介者 (検索インデックスやキャッシュなど) に委任します。 データの並べ替え、データのフィルター処理、ビューのレンダリングなどのタスクを委任します。 これらのタスクをオフロードすると、サーバーのワークロードが削減され、パフォーマンスが向上します。

ネットワークを最適化します。 パフォーマンスのためにワークロード ネットワークを最適化するには、ネットワーク インフラストラクチャを構成して微調整します。 ワークロードが最高レベルの効率で動作できることを確認します。

  • ネットワーク プロトコル: HTTP/2 などの最新のプロトコルにアップグレードします。これにより、1 つの接続経由で複数の要求を送信できます。 最新のプロトコルでは、新しい接続を確立するオーバーヘッドが軽減されます。

    トレードオフ: 最新のプロトコルでは、古いクライアントが除外される場合があります。

  • ネットワーク チャット: ネットワーク要求をまとめてバッチ処理し、要求の数を減らします。 複数の小さな要求を行う代わりに、それらをより大きな要求に結合して、ネットワークのオーバーヘッドを減らします。

  • データベース クエリ: データベース クエリが必要な情報のみを取得することを確認します。 大量の不要なデータを取得しないようにします。これにより、ネットワーク トラフィックが増加し、パフォーマンスが低下する可能性があります。

  • 静的データ: コンテンツ配信ネットワークを利用して、ユーザーに近い頻繁にアクセスされる静的コンテンツをキャッシュします。 データをキャッシュするときに、長距離を移動する必要はありません。 キャッシュを使用すると、応答時間が短縮され、ネットワーク トラフィックが削減されます。

  • ログ収集: 要件をサポートするために必要なログ データのみを収集して保持します。 Log Analytics のコストを最適化するために、データ収集ルールを構成し、設計上の考慮事項を実装します。

  • データ圧縮: HTTP コンテンツ と ファイル データ を圧縮およびバンドルして、クライアントとサーバー間の高速転送を可能にします。 圧縮は、ページまたは API が返すデータを圧縮し、ブラウザーまたはクライアント アプリに送り返します。 圧縮によってネットワーク トラフィックが最適化され、アプリケーション通信が高速化される可能性があります。

    トレードオフ: 圧縮により、サーバー側とクライアント側の処理が追加されます。 アプリケーションでは、データの圧縮、送信、および圧縮解除を行う必要があります。 マルチキャスト通信または複数の受信者への通信では、圧縮解除のオーバーヘッドが発生する可能性があります。 データ圧縮を実装する前と実装後にパフォーマンスの変動をテストして測定し、ワークロードに適しているかどうかを判断する必要があります。 詳細については、「ASP.NET Core の応答の圧縮」を参照してください。

Azure ファシリテーション

コードのインストルメンテーション: Azure Monitor Application Insights では、アプリケーション コードの自動インストルメンテーション (自動侵入) と手動インストルメンテーションがサポートされます。 自動侵入により、アプリケーションのコードに触れることなくテレメトリ収集が可能になります。 手動インストルメンテーションでは、Application Insights または OpenTelemetry API を実装するためのコード変更が必要です。 Application Insights Profiler を使用して、ホット パスを最適化できます。

コード ロジックの最適化: Azure には、Azure サービスと対話するためのさまざまなプログラミング言語用の SDK とライブラリが用意されています。 SDK を使用して、アプリケーションと Azure リソース間の対話を簡略化します。 SDK は、Azure サービスとの最適な対話を提供します。これにより、待機時間が短縮され、効率が向上します。

メモリ管理の最適化: Application Insights のスマート検出機能 を使用してメモリ消費量を分析し、メモリ リークの特定と対処に役立ちます。

Azure App Serviceには、プロファイラーとメモリ ダンプの収集と分析機能があります。 App Service自動加熱機能では、.NET アプリと Java アプリのメモリ ダンプとプロファイル トレースを自動的に取得できます。

コンカレンシーと並列処理の使用: Azure Cosmos DB、Azure Functions、BLOB ストレージなど、さまざまな Azure サービスで一意のコンカレンシーがサポートされます。 並列処理のために、サービス AKS はコンテナー化されたアプリケーションのデプロイをサポートしているため、並列処理が向上します。

Azure Batchはクラウドベースのジョブ スケジューリング サービスであり、インフラストラクチャのセットアップを必要とせずに並列で高パフォーマンスのコンピューティングを有効にするために使用できます。 詳細については、「 バックグラウンド ジョブ」を参照してください。

インフラストラクチャのパフォーマンスの最適化: コードを使用してインフラストラクチャを定義してデプロイするために、Azure Resource Manager テンプレートを実装します。 これらのテンプレートを使用して、効率的で反復可能で一貫性のあるリソース デプロイを実装します。 Azure Policyは、リソースのデプロイが組織のベスト プラクティスと標準に準拠していることを確認するためのガバナンス機能を提供します。

非同期プログラミングの場合は、Azure Queue Storage や Azure Service Bus などのスケーラブルなキュー サービスを使用して、非同期プログラミングを容易にします。 タスクをキューに登録し、個別に処理することができます。 非同期操作をサポートするために、Azure Marketplaceには、Azure サービスと統合できるサードパーティのキューとツールが用意されています。

パフォーマンス効率のチェックリスト

推奨事項の完全なセットを参照してください。

パフォーマンス効率チェックリスト