クラウドでホストされるワークロード用に設計されたアプリケーションは、ソリューションのビジネス要件に対応し、クラウドネイティブのコンポーネントと機能を組み込んでいます。 適切に設計されたクラウド アプリケーションは、信頼性、セキュリティ、コスト、運用、パフォーマンスに関する考慮事項に対処します。 これらの考慮事項は、ビジネス要件、クラウド ホスティング プラットフォームの特定の特性、プラットフォームが提供する機能と一致します。
マイクロサービスなどの特定のアプリケーション スタイルを使用して、クラウド ワークロード用のアプリケーションを設計する必要はありません。 ただし、クラウド ホスティングでは、アプリケーションとデータ プラットフォームのオプション、スケーリング機能、セキュリティ制御、メッセージング オプションの多様な選択をネイティブに提供しないホスティング ソリューションよりも、多くのアプリケーション設計パターンの方がアプローチしやすくなります。 クラウド ワークロードは、設計によって小規模で分散型のサービスに分解されるアプリケーションの恩恵を受けます。 これらのサービスは、API を介して、あるいは非同期メッセージングまたはイベントを使用して通信します。 需要が増加したときに新しいインスタンスを追加することで、アプリケーションは水平方向にスケーリングされます。
クラウドのアプリケーション ホスティング プラットフォーム、メッセージング機能、分解されたサービスを使用するアプリケーションは、分散システムに関する一般的な懸念事項の対象となります。 これらのシステムでは、アプリケーションの状態が分散され、操作が並列および非同期で実行されます。 障害が発生しても、アプリケーションは回復力があることが必要です。 悪意のある攻撃者は継続的にアプリケーションを標的にします。 デプロイは自動的に行い予測可能であることが必要です。 監視とテレメトリは、システムに関する分析情報を得るために非常に重要です。
次の列では、オンプレミスの設計とクラウド設計の一般的な特性を示します。
一般的なオンプレミスの設計
- モノリシックかつ共存する機能とデータ
- 予測可能なスケール向けに設計されているか、オーバープロビジョニングされています
- リレーショナル データベース
- 同期された処理
- 障害を回避し、故障間の平均時間を測定するように設計されています (MTBF)
- リソースは IT 機能を通じてプロビジョニングされます
- Snowflake サーバーとペット サーバー
一般的なクラウド設計
- 分解および分散された機能とデータ
- 柔軟なスケーラビリティ向けに設計
- ストレージ技術を組み合わせたポリグロット持続性
- 非同期処理
- 故障に耐え、MTBFを測定するように設計されている
- 故障に備え、平均修復時間を測定
- リソースは、コードとしてのインフラストラクチャを通じて必要に応じてプロビジョニングされます
- 不変で置き換え可能なインフラストラクチャ
Azure 用のアプリケーションを設計する
クラウド ホスティングに関する専門知識を持ち、戦略的なトレードオフの決定を行うことができるクラウド アーキテクトは、クラウド アプリケーションを設計する必要があります。 Azure には、アーキテクトがアプリケーションを開発し、それらを実装するための開発チームをガイドするためのリソースが用意されています。 優れたワークロードとアプリケーション設計を実現するには、アーキテクトは次の作業を行う必要があります。
- 組織のクラウド導入標準に合わせます。
- 設計が Azure Well-Architected Framework に従っていることを確認します。
- 一般的な アーキテクチャのスタイル、 ワークロード、 ベスト プラクティスについて説明します。
- 設計パターンを使用して一般的な問題を解決し、戦略的なトレードオフを導入します。
- 情報に基づいたテクノロジの選択を行います。
- 参照アーキテクチャを評価します。
- サービス固有のガイドを確認します。
Azure を使用して、クラウド用に設計されていないアプリケーションをホストおよび再ホストできます。 ワークロード アプリケーションはクラウド機能を使用するように調整できますが、固定リソースとスケール用に設計されたアプリケーションを再ホストすることは、クラウドネイティブのデプロイとは見なされません。
組織のクラウド導入標準に合わせる
アプリケーションは、組織の標準とガバナンスを満たす必要がある可能性が高いワークロードの一部です。 あらゆる規模とクラウドの成熟度を持つ組織は、 Azure 向けのクラウド導入フレームワーク を使用して、Azure 全体の導入戦略、準備、イノベーション、管理、ガバナンス、およびセキュリティイニシアチブを正式化できます。 そのアプローチの一部は、 Azure ランディング ゾーンの使用など、ワークロード間で一貫したアプローチを標準化することです。 Azure ランディング ゾーンは、組織全体のガバナンスを提供し、ワークロード チームとアーキテクトに、ローカライズされたビジネス目標を達成するためにリソースへの民主化されたアクセスを提供します。 アプリケーションを設計するアーキテクトとして、マクロ環境と、アプリケーションランディングゾーンなどのワークロード運用に対する期待を理解することが重要です。
組織の Azure 導入戦略は、選択したアーキテクチャ スタイルに影響を与えるべきではありませんが、テクノロジの選択やセキュリティの境界が制約される可能性があります。
Well-Architected フレームワークに従う
さまざまなレンズを使用して、ワークロードの設計と実装を評価できます。 Well-Architected Framework を使用して、次の 5 つの主要なアーキテクチャの柱で決定を評価し、設計原則に合わせます。
これらの原則に従い、これらのアーキテクチャの柱間のトレードオフを評価することで、ビジネス要件を満たし、Azure で実行するために十分に耐久性があり、保守可能で、セキュリティで保護され、コスト最適化された設計を作成できます。 これらの決定は、アーキテクチャ スタイルの選択を通知し、特定のワークロードのニーズに関連するテクノロジの選択肢またはセキュリティ境界を絞り込むのに役立ちます。
チームまたは組織には、ワークロードの評価に使用できる 、持続可能性 や倫理などの他の設計原則がある場合があります。
一般的なアーキテクチャ のスタイルを理解する
アプリケーションが存在する組織環境と、Well-Architected Framework に基づく優れたアーキテクチャ設計の基礎を理解したら、構築するアーキテクチャの種類を決定する必要があります。 マイクロサービス アーキテクチャ、従来の n 層アプリケーション、またはビッグ データ ソリューションも考えられます。 これらのアーキテクチャ スタイルは、異なる結果のために個別に設計されています。 アーキテクチャ スタイルを評価するときは、状態管理に対処するためにデータ ストア モデルも選択する必要があります。
さまざまな アーキテクチャ スタイル と データ ストア モデル を評価して、各オプションが提示する利点と課題を理解します。
Well-Architected Framework のワークロード
Well-Architected フレームワーク ワークロードに関する記事では、さまざまなワークロードの分類や種類について説明しています。 ミッション クリティカルなワークロード、AI と機械学習のワークロード、またはサービスとしてのソフトウェア ワークロードに関する記事を見つけることができます。 これらのワークロード固有の記事では、Well-Architected Framework の 5 つの主要な柱を特定のドメインに適用します。 アプリケーションが、これらの文書化されたパターンのいずれかに一致するワークロードの一部である場合は、アプリケーション プラットフォーム、データ プラットフォーム、ネットワークなどの一般的な設計領域にわたる一連のワークロード固有の設計原則と推奨事項に従って、設計に取り組むのに役立つそれぞれのガイダンスを確認してください。 ワークロードの種類によっては、特定のアーキテクチャ スタイルまたはデータ ストア モデルを選択することでメリットが得られる場合があります。
ベスト プラクティス
API の設計、自動スケーリング、データのパーティション分割、キャッシュなど、さまざまな設計上の考慮事項の詳細については、「 クラウド アプリケーションのベスト プラクティス」を参照してください。 これらの考慮事項を確認し、アプリケーションに適したベスト プラクティスを適用します。
設計パターンを使用して一般的な問題を解決し、戦略的なトレードオフを導入する
アプリケーションには、成功の特定のビジネス要件、目標、測定があります。 これらの機能要件と非機能要件を個別のアクティビティに分解して、お客様と顧客の期待を満たすソリューションを実現する必要があります。 これらのアクティビティは、通常、ソフトウェア業界が確立したパターンに従います。 ソフトウェア設計パターンは、処理またはデータ ストレージに適用できる名前付きの反復可能なアプローチです。 これらのパターンは、既知のトレードオフに関する特定の問題を解決することが証明されています。
Azure の クラウド設計パターンのカタログは、 分散システムにおける特定の課題に対処します。
情報に基づいたテクノロジの選択
ビルドするアーキテクチャの種類と使用する予定の設計パターンを決定したら、アーキテクチャの主要なテクノロジ コンポーネントを選択できます。 次のテクノロジの選択肢が不可欠です。
コンピューティング とは、アプリケーションが実行されるコンピューティング リソースまたはアプリケーション プラットフォームのホスティング モデルを指します。 詳細については、コンピューティング サービスの選択に関するページをご覧ください。 特定のアプリケーション プラットフォームについては、 Azure コンテナー サービスの選択 や Azure ハイブリッド オプションなどの特殊なガイダンスを参照してください。
データ ストア には、ファイル、キャッシュ、ログ、アプリケーションがストレージに保持する可能性のあるその他のデータベースとストレージが含まれます。 詳細については、「 データ ストアの分類 」と 「ストレージ オプションの確認」を参照してください。
メッセージング テクノロジを使用すると、システムのコンポーネント間の非同期メッセージングが可能になります。 詳細については、「 非同期メッセージング オプション」を参照してください。
AI テクノロジは、従来のアプリケーション コードで実装する計算が複雑な問題を解決します。 詳細については、「 Azure AI サービス テクノロジの選択」を参照してください。
その過程で他のテクノロジを選択することもできますが、コンピューティング、データ、メッセージング、AI は、ほとんどのクラウド アプリケーションの中心であり、設計のさまざまな側面を決定します。
参照アーキテクチャを評価する
Azure Architecture Center には、ソリューションのアイデア、ワークロードの例、参照アーキテクチャに関する記事があります。 これらの記事では、通常、Well-Architected Framework と一致する一般的なコンポーネントと考慮事項を示します。 これらの記事の一部には、GitHub でホストされているデプロイ可能なソリューションが含まれています。 これらのシナリオのいずれも、実際に構築しているシナリオとは考えにくいですが、出発点として適しています。 ガイダンスは、特定のニーズに合わせて調整できます。
Azure アーキテクチャ センター でアーキテクチャのカタログ を参照します。
サービス固有のガイドを確認する
コア テクノロジを選択し、参照アーキテクチャを参照したら、アーキテクチャ内のサービスに固有のドキュメントとガイダンスを確認します。 サービス固有のガイダンスには、次のリソースを使用します。
Well-Architected Framework サービス ガイド: Well-Architected Framework には、多くの Azure サービスに関する記事が用意されています。 この記事では、各サービスにアーキテクチャの 5 つの柱を適用します。
Azure 信頼性ガイド: Azure 信頼性ハブには、多くの Azure サービスの信頼性特性に特に対処する詳細な記事があります。 これらの記事では、可用性ゾーンのサポートや、さまざまな種類の停止中の予想される動作など、最も重要な信頼性に関するトピックの一部について説明します。
別のクラウドから来ていますか?
別のクラウド プロバイダーでアプリケーションを設計する方法を理解している場合は、同じ基礎の多くが適用されます。 たとえば、アーキテクチャ スタイルとクラウド設計パターンは概念的にクラウドに依存しません。 詳細については、次のサービス マッピングとアーキテクチャ ガイドの記事を参照してください。