適切なサービスを選択するための推奨事項

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

このガイドでは、ワークロードに適したサービスを選択するための推奨事項について説明します。 次の推奨事項は、ワークロードの要件と要求を最適に満たすサービスを選択するのに役立ちます。 ワークロードの要件を処理するように設計されたサービスを使用する場合は、ワークロードがパフォーマンス 目標を満たしていることを確認できます。 ワークロードに不適切なサービスを選択した場合、サービスがワークロードの要求を処理できない可能性があります。 サービスが不十分な場合、応答時間、ボトルネック、またはワークロードエラーが発生する可能性があります。

定義

主要な設計戦略

選択するサービスは、ワークロードのパフォーマンス 目標に合わせ、将来の容量ニーズに適応できる必要があります。 ワークロードが拡大または進化するにつれて、使用するサービスは、大きな調整を必要とせずにパフォーマンス標準に一致する必要があります。 プラットフォーム機能とカスタム実装のバランスを考慮してください。 プラットフォーム機能は即時のソリューションを提供しますが、カスタム構築されたオプションは正確な調整を提供します。 サービスの選択は、利便性とカスタマイズのトレードオフを考慮して、事前に考え、特定のニーズに合わせて調整する必要があります。

ワークロードの要件を理解する

ワークロードの要件を理解することは、ワークロードの技術的および機能的な要求を把握することです。 この分析は、ワークロードの実行に必要なリソース、ストレージ、コンピューティング、ネットワーク、およびその他の仕様を決定するのに役立ちます。 サービスをワークロードの特定のニーズに合わせることは、リソースの過剰プロビジョニングや過小使用を防ぐのに役立ちます。

ワークロードのニーズと特性を評価して要件を決定し、ワークロードの要件をすべてのレベルのパフォーマンス 目標に合わせます。 制約または依存関係を考慮する必要があります。 ワークロードの要件を理解したら、情報に基づいた意思決定を行うことができます。 適切なインフラストラクチャを決定し、ピーク時の負荷や需要の変動を処理する戦略を実装できます。

• パフォーマンス目標を達成する。 ワークロードのパフォーマンス 目標を満たせるようにするサービスを選択します。 サービスがパフォーマンスのニーズをサポートできることと、そのパフォーマンスを監視できることを確認します。 重要なコンポーネントのパフォーマンス データを収集します。

• 組織の制限を検討してください。 デプロイするサービスでorganizationが持つ可能性がある制限について理解しておいてください。 ソリューションを設計するときは、これらの制限を考慮してください。

• コンプライアンスとセキュリティの要件を検討してください。 コンプライアンスとセキュリティの要件は、選択したサービスと構成に影響を与える可能性があります。 選択したサービスが、ストレージ、暗号化、アクセス制御、監査ログ、データの場所に関連する要件を満たしていることを確認します。

• チームのスキルを検討する。 チームはワークロードを構築して管理します。 サービスによって必要なスキルは異なります。 チームが使用する方法を知っているサービスを選択するか、サービスを選択する前にトレーニングにコミットします。 チーム メンバーが、サービスを効果的に使用し、パフォーマンスを最適化するための専門知識と知識を持っていることを確認します。

トレードオフ: 特殊化されたサービスは特定の機能を提供しますが、カスタマイズが制限される可能性があります。 柔軟なリソースでは、特殊なサービスと比較して、より多くの管理と構成が必要です。 マネージド サービスは管理が容易ですが、セルフマネージド リソースと比較して、基になるインフラストラクチャの制御が少ない場合があります。

サービスについて

サービスを理解することは、ベンダーのツールとオファリングの機能、制限、および機能を理解することです。 サービスの理解は、組み込みの機能を使用し、複雑なカスタム ソリューションの必要性を減らし、パフォーマンス効率を向上させるのに役立ちます。

さまざまな要因を考慮し、サービスを選択する前に包括的な理解を得る。 プロバイダーが提供するサービスとツールを調査および評価します。 ワークロードの要件に最も適したサービスとツールを決定します。 マネージド サービス、サーバーレス オプション、特殊なサービスなどの要因を考慮してください。

サービスの制限について

サービスの制限は、サービス プロバイダーが設定する定義済みのしきい値または境界です。 サービスの制限は、そのサービス内のリソースまたは機能の最大使用量を定義します。 サービスの制限に慣れている場合は、リソースの競合、パフォーマンスの低下、予期しないサービスの中断などの問題を回避できます。 インフラストラクチャを適切に計画およびスケーリングできます。 計画では、データ 量、処理能力、データ所在地の要件などの要因が考慮されます。

プラットフォーム機能を優先する

プラットフォーム機能の優先は、プロバイダーによって提供される組み込みの機能を使用して、カスタム コードなしで特定のタスクを処理することです。 ベンダーは、特定のタスクを大規模に効率的に処理するようにプラットフォーム機能を設計し、これらの機能を定期的に維持します。 プラットフォーム機能を使用すると、クラウド インフラストラクチャ機能をより適切に活用できます。 独自のカスタム コードを記述して維持する代わりに、プラットフォームに機能をオフロードできるサービスを選択します。 多くの場合、サービスとしてのプラットフォーム (PaaS) ソリューションでは、カスタム コードよりもパフォーマンス効率が向上します。 カスタム コードにより複雑さが増し、ワークロードのパフォーマンスの問題が発生しやすくなります。 サービス機能が十分でない場合にのみ、カスタム コードを開発します。

トレードオフ: ワークロードに最適なサービスは、チームが熟練していないテクノロジ、余裕がないテクノロジ、または追加のセキュリティ 層が必要な場合があります。 たとえば、パブリック ロード バランサーは、パフォーマンスのニーズに合う場合があります。 ただし、Web アプリケーション ファイアウォールがない場合は、ワークロードをセキュリティで保護するためにファイアウォールをデプロイする必要があります。

インフラストラクチャの要件を評価する

リソースのパフォーマンス効率は、リソースが存在するインフラストラクチャに関連付けられています。 これにより、適切なインフラストラクチャの選択がサービスのパフォーマンス効率に不可欠になります。 インフラストラクチャ要件を評価することは、ワークロードをサポートするのに最適な地理的リージョンと可用性ゾーンを特定することを意味します。 この意思決定における主な考慮事項は次のとおりです。

• リージョンと可用性ゾーンについて理解する。 すべてのリージョンは、異なる地理的な場所に対応します。 可用性ゾーンは、特定のリージョン内の個々の物理データセンターを表します。

• 単一リージョンと複数リージョンのデプロイ モデル。 単一リージョンデプロイ モデルでは、すべてのリソースが 1 つのリージョンにデプロイされます。 複数リージョンのデプロイ モデルは、複数のリージョンにリソースをデプロイします。 複数リージョンのデプロイでは、エンド ユーザーへの待機時間を短縮し、容量の制約を軽減できます。 ただし、ワークロードのコストと複雑さを増やすこともできます。 ワークロードのニーズに最適なデプロイ モデルを選択します。

• 使用可能な機能について理解します。 リージョンによって、サービスの数や可用性ゾーンなど、使用可能な機能が異なります。 選択する前に、リージョンで使用できる機能について理解します。 リージョンがワークロードのパフォーマンスニーズを満たしていることを確認します。

• 待機時間を検討してください。 待機時間は、データがソースから宛先に移動するのにかかる時間であり、相互にサービスが増加します。 リージョンまたは可用性ゾーン間で通信するサービスでは、待機時間が長くなる可能性があります。 頻繁に通信するサービスを特定し、同じリージョン内に配置することをお勧めします。 さらに、プライマリ ユーザー ベースに近接するリージョンを選択すると、待機時間を最小限に抑え、ユーザー エクスペリエンスを向上させることができます。

• データセンターのマッピングについて理解する。 可用性ゾーンは、異なるサブスクリプション間で同じデータセンターに一貫してマップされない場合があります。 たとえば、'サブスクリプション A' の 'ゾーン 1' は、'サブスクリプション B' の 'ゾーン 1' とは異なる場合があります。 複数のサブスクリプションで操作する場合は、これらのマッピングを把握して、パフォーマンスを最適に強化するゾーンを選択する必要があります。

ネットワーク要件を評価する

ネットワークのニーズを評価して、適切なワークロード サービスと構成を決定します。 ネットワークがワークロードをサポートできることを確認します。 ネットワーク要件を評価するには、次の点を考慮してください。

• ネットワーク トラフィックについて理解する。 ワークロードに予想されるネットワーク トラフィックを評価します。 データ転送のニーズとネットワーク要求の頻度を理解します。

• 帯域幅の要件について理解します。 ワークロードの帯域幅要件を決定します。 ネットワーク経由で送受信されるデータの量を考慮してください。

• ネットワーク待機時間について理解します。 ワークロードに必要な待機時間を評価します。 パブリック インターネットを走査する代わりに、プライベート仮想ネットワークとバックボーン ネットワークを使用します。 この手法により、ワークロードの待機時間が短縮されます。

• スループットを理解する。 ワークロードに必要なスループットを考慮してください。 スループットとは、特定の時間内にネットワーク経由で送信できるデータの量を指します。 ネットワーク スループットの利点を活用するようにネットワーク ルーティング オプションを構成します。

トレードオフ: プライベート仮想ネットワークではパブリック アクセスが制限され、リソースのデプロイと管理が困難になります。

コンピューティング要件を評価する

コンピューティング要件の評価には、インスタンスの種類、スケーラビリティ、コンテナー化などの要因を含む、ワークロードの特定のコンピューティング ニーズを評価する必要があります。 コンピューティング サービスによって、ワークロードのパフォーマンスに影響を与える可能性があるさまざまな機能と特性があります。 最適なコンピューティング サービスを選択して、ワークロードが効率的に実行されるようにします。 次の戦略を考えます。

• インスタンスの種類について理解します。 CPU 最適化、メモリ最適化、GPU インスタンスなど、さまざまなワークロードに対してさまざまなインスタンスの種類が最適化されます。 ニーズに合わせてインスタンスの種類を選択します。

• 自動スケーリングを検討してください。 ワークロードに変動する需要がある場合は、需要に基づいてコンピューティング容量を自動的に調整できる自動スケーリング機能を備えたコンピューティング サービスを検討してください。 自動スケーリングを使用すると、ピーク時に十分なリソースを確保し、需要の低い期間中に過剰プロビジョニングを防ぐことができます。

• コンテナー化を検討してください。 コンテナーは、コンテナー化されていないワークロードと比較してパフォーマンス上の利点を提供します。 アーキテクチャのニーズに合う場合は、コンテナー化の使用を検討してください。 コンテナーは、分離、リソース効率、起動時間の短縮、移植性によってコンピューティング パフォーマンスを向上させます。

  コンテナーを使用する場合は、すべてのアプリケーション コンポーネントのコンテナー化などの設計要因を検討してください。 軽量イメージには Linux ベースのコンテナー ランタイムを使用します。 コンテナーを変更不可にして置き換え可能にするための短いライフサイクルをコンテナーに提供します。 コンテナー、コンテナー ホスト、基になるクラスターから関連するログとメトリックを収集します。 このデータを使用して、パフォーマンスを監視および分析します。 コンテナーは、アーキテクチャ全体の 1 つのコンポーネントにすぎません。 パフォーマンスとスケーラビリティをさらに向上させるために、Kubernetes などの適切なコンテナー オーケストレーターを選択します。

  コンテナー特典	説明
  分離:	コンテナーは、アプリケーション用に分離された環境を提供します。 コンテナーは、アプリケーション リソースが相互に干渉しないようにします。 この分離により、コンテナーに割り当てられたコンピューティング リソースが特定のアプリケーションの実行専用になり、パフォーマンスが向上します。
  リソースの効率性	コンテナーは軽量であり、ホスト オペレーティング システムのカーネルを共有します。これにより、効率的なリソース使用率が可能になります。 複数のコンテナーを同じ仮想化インフラストラクチャで実行できるため、コンピューティング リソースの使用が最大化されます。
  高速起動時間	コンテナー イメージは事前構築済みであり、必要に応じてすぐに開始されます。 この高速な起動時間により、迅速なスケーラビリティが可能になります。 これにより、アプリケーションは需要に基づいてスケールアップまたはスケールダウンし、パフォーマンスのボトルネックを回避できます。
  移植性	コンテナーは、イメージ内のすべての必要な依存関係とライブラリをカプセル化します。 コンテナーを使用すると、異なるオペレーティング システムまたは環境間でアプリケーションを移動する方が簡単です。 この移植性により、アプリケーションを柔軟にデプロイでき、クラウド プロバイダーまたはオンプレミス環境間で簡単に移行できます。

• 適切なレベルを選択します。 各コンピューティング サービス内で、コンピューティング容量の設定、機能の選択、機能の有効化を行うことができます。 パフォーマンス目標に基づいて、コンピューティング サービスに適したサービス レベルを選択します。

• インスタンス数を決定します。 ワークロードに必要な最小インスタンス数を決定します。 ワークロードによっては、最小限の負荷であっても、コンピューティング リソースの複数のインスタンスが必要になる場合があります。 それに応じて、最小インスタンス数を設定します。

負荷分散の要件を評価する

負荷分散により、ネットワーク トラフィックが均等に分散され、単一サーバーが要求に圧倒されるのを防ぐことができます。 負荷分散は、ボトルネックを防ぎ、応答時間を短縮するのに役立ちます。 クラウド プロバイダーが提供するさまざまな負荷分散サービスを評価します。 クラウド プロバイダーのドキュメントと比較ツールを確認して、機能を理解します。 ワークロードに最適なサービスを選択します。 負荷分散サービスを選択するには、次の点を考慮してください。

• トラフィックの種類を理解する: 負荷分散サービスが、HTTP や HTTPS などの Web トラフィックを処理する必要があるか、または伝送制御プロトコル (TCP) やユーザー データグラム プロトコル (UDP) などの他のプロトコルを処理する必要があるかを判断します。

• グローバル ルーティングまたはリージョン ルーティングを把握する: ワークロードで、特定のリージョン内または複数のリージョン間で負荷分散が必要かどうかを判断します。

• サービス レベルの目標 (SLO) を把握する: サービス レベル アグリーメント (SLA) を検討します。 負荷分散サービスによって提供されるパフォーマンスレベルは異なります。

• 機能を理解する: サイトアクセラレーション、最適なトラフィック分散、低遅延レイヤー 4 負荷分散を提供する負荷分散サービスを検討します。

データ ストアの要件を評価する

データ ストアの要件の評価は、データの格納、取得、管理に関する特定のニーズと条件を評価することです。 この評価では、データ量、アクセス速度、一貫性、持続性などの要因が考慮されます。 ワークロードでは、さまざまなビジネス要件と技術要件に基づいて、複数の種類のデータ ストアが必要になる場合があります。 適切なデータ ストア サービスと適切な実装を特定すると、ボトルネックを防ぎ、データ への迅速なアクセスを確保できます。

データベースの要件を評価する

データベースは、データの格納と取得、トランザクション処理、一貫性の保証、大きなデータまたは急速に変化するデータの処理などの要因に影響を与える可能性があります。 データベースのニーズと条件を評価します。 これらの要件を満たすことができるデータベース システムを選択します。 データベースを選択する前に、データベースの要件を評価します。 データベース要件を評価し、適切なデータベースを選択するには、次の手順に従います。

• ワークロードのニーズを特定します。 データ ボリューム、予想されるトランザクションレート、コンカレンシー、データ型、予想される増加など、ワークロードの特定の要件を理解します。 ワークロードのニーズに基づいて、さまざまなデータベース システムを評価します。 たとえば、ワークロードで高パフォーマンスのリアルタイム データ処理が必要な場合は、高速なデータ インジェストと短い待機時間のために最適化されたデータベース システムを選択できます。

• データ モデルについて考えてみましょう。 ワークロードに最適なデータ モデルを決定します。 データベース要件を評価して、選択したデータベースが必要なデータ構造、リレーションシップ、および整合性制約をサポートしていることを確認します。 たとえば、データに高度なリレーショナル構造がある場合は、トランザクションと参照整合性の堅牢なサポートを提供するリレーショナル データベース管理システム (RDBMS) を選択できます。 データ モデルは、階層、ネットワーク、リレーショナル、オブジェクト指向、または NoSQL のいずれかです。 データ モデルの複雑さを評価します。 選択したデータベースで、必要なデータ構造とリレーションシップがサポートされていることを確認します。

• 機能を評価します。 読み取り/書き込みパターン、クエリの複雑さ、待機時間の要件、スケーラビリティのニーズなどの要因を考慮してください。 それに応じて、さまざまなデータベース システムのパフォーマンス機能を評価します。 読み取り負荷の高いワークロードに優れているデータベースもあれば、書き込み負荷の高いワークロードや分析ワークロード用に最適化されているデータベースもあります。

• 負荷を評価します。 データ量、トランザクションレート、読み取り/書き込み比率、予想される増加などの要因を考慮してください。 予想されるワークロードを処理できるデータベースを選択して、円滑な運用を確保し、ワークロードのスケーリング時にパフォーマンスのボトルネックを回避します。 ワークロードのスケーラビリティ要件を検討します。 これらの要件には、予想されるデータの増加、同時ユーザー アクセス、水平方向または垂直方向のスケーリングの必要性が含まれます。 さまざまなデータベース システムが提供するスケーラビリティ オプションと可用性機能を評価します。

ストレージ要件を評価する

データ アクセス パターン、持続性の要件、パフォーマンスのニーズに合ったストレージ サービスを選択します。 ほとんどのクラウド ワークロードでは、ストレージ テクノロジの組み合わせを使用します。 この手法は、ポリグロット永続化アプローチと呼ばれます。 ワークロードに適したストレージ サービスの組み合わせを決定します。 また、汚染を避けるためにデータを分離することもできます。 たとえば、データとビジネス データを監視するための個別のストレージ アカウントがあるとします。 アプリケーションのパフォーマンスを最適化するために、適切な組み合わせと正しい実装を選択することが重要です。

キャッシュ要件を評価する

キャッシュには、頻繁にアクセスされるデータが格納されます。 キャッシュを使用すると、データ アクセスの待機時間が短縮され、データ ストレージ コンポーネントの負荷が軽減されます。 これにより、ワークロードはスケーリングなしでより多くの要求を処理できます。 ワークロード データと静的コンテンツをキャッシュするのが一般的です。 Redis キャッシュには、セッション データ、データベースの結果、API 応答、および構成設定などの参照データを格納できます。 コンテンツ配信ネットワークまたは静的 Web アプリは、静的コンテンツをキャッシュして提供できます。 ワークロードのパフォーマンスを向上させるためにデータをキャッシュすることを検討してください。 ワークロードに適したキャッシュ オプションを選択します。カスタムまたはセルフホステッドサービスよりも、Azure Redis Cache などのプラットフォーム キャッシュ サービスを優先します。

Azure ファシリテーション

要件について: Azure Monitor を使用して、ワークロードからデータを収集および分析します。 Monitor は、ワークロードのパフォーマンスと正常性に関する分析情報を提供し、問題を特定してトラブルシューティングできるようにします。

サービスの理解と評価: Azure サービスと製品 を確認して、パフォーマンス要件を満たしているかどうかを判断します。 Azure には、同じ結果を実現するいくつかのサービスが用意されています。 サービスの選択を、パフォーマンス ニーズ、チーム スキル セット、コスト要件に合わせて柔軟に調整できます。

最も一般的な Azure の制限の一覧については、「Azure サブスクリプションとサービスの制限、クォータ、制約」をご覧ください。

クエリの制限とクォータのサンプルは、一般的に使用されるリソースの制限とクォータを照会する方法を示しています。

Azure には、あらゆるワークロードに対応できる多くのサービスがあります。 各サービスの種類の 選択ガイダンス を確認して、要件に基づいて選択を効率化します。 選択するには、次のガイドを参照してください。

• リージョン
• Compute Services
• コンテナー サービス
• データ ストア サービス
• 負荷分散サービス
• ストレージ サービス

関連リンク

• 可用性ゾーンをサポートする Azure リージョン
• パフォーマンス ターゲットを定義するための推奨事項
• 可用性ゾーンとリージョンを使用するための推奨事項
• 可用性ゾーンとは
• Azure リージョンを選択する

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

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