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