Azure Well-Architected Framework の柱

  • 10 分

クラウドにより、組織がビジネスの課題を解決する方法や、アプリケーションとシステムの設計方法が変わりました。 ソリューション アーキテクトの役割は、アプリケーションの機能要件を通じてビジネス価値を提供することだけではありません。 スケーラブルで回復性と効率に優れた安全な方法でソリューションが設計されるように保証する必要もあります。

ソリューション アーキテクチャはテクノロジ システムの計画、設計、実装、および継続的な改善に関係しています。 システムのアーキテクチャは、ビジネスの要件と、それらの要件を満たすために必要な技術的能力のバランスを取り、調整する必要があります。 完成したアーキテクチャは、システムとそのコンポーネントの全体にわたるリスク、コスト、および機能のバランスです。

Azure Well-Architected Framework

Azure Well-Architected Framework は、Azure で高品質のソリューションを構築するための一連のテナントです。 アーキテクチャの設計に万能のアプローチはありませんが、アーキテクチャ、テクノロジ、またはクラウド プロバイダーにかかわらず当てはまる普遍的な概念がいくつかあります。

これらの概念は包括的なものではありませんが、これらに重点を置けば、信頼性が高く、安全で、柔軟性のあるアプリケーション基盤を構築しやすくなります。

Azure Well-Architected Framework は次の 5 本の柱で構成されています。

  • コスト最適化
  • オペレーショナル エクセレンス
  • パフォーマンス効率
  • [信頼性]
  • セキュリティ

An illustration that shows the pillars of the Azure Well-Architected Framework.

コスト最適化

運用と開発のコスト効率に優れたクラウド環境を設計する必要があります。 最も効果が大きい部分に予算を投入できるよう、非効率的で無駄なクラウド支出を明らかにします。

An illustration that shows increasing quality, speed, and efficiency while maintaining decreasing costs.

オペレーショナル エクセレンス

DevOps などの最新の開発方法を利用することで、開発とデプロイのサイクルを高速化できます。 障害や問題が発生する前に、または遅くとも顧客が気づく前に検出できるよう、優れた監視アーキテクチャを整備する必要があります。 自動化はこの柱の重要な側面で、運用の機敏性を高めながら差異やエラーを除去します。

パフォーマンス効率

パフォーマンスが良くスケーラブルなアーキテクチャにするため、リソースの容量を適切に需要と一致させる必要があります。 従来のクラウド アーキテクチャでは、アプリケーションのアクティビティに基づいてアプリケーションを動的にスケーリングすることによって、このバランスが実現されます。 サービスの需要は変動するため、需要に応じた調整能力がアーキテクチャ側に備わっていることが重要です。 パフォーマンスとスケーラビリティを念頭に置いてアーキテクチャを設計することで、コスト効率を維持しつつ、優れたエクスペリエンスを顧客に提供します。

An illustration that shows how resources in the cloud scale dynamically based on demand, resulting in highly efficient usage. When resources are implemented at a fixed level, it results in inefficient usage during low demand and shortage during high demand.

信頼性

すべてのアーキテクトが最も恐れる事態は、復旧手段がない状態でアーキテクチャがダウンすることです。 成功するクラウド環境は、すべてのレベルで障害を予測するように設計されています。 利害関係者や顧客が要求する時間内に、障害から復旧できるシステムを設計することも、これらの障害予測に含まれます。

An illustration that shows two virtual machines in a virtual network. One of the machines is shown as failed, while the other is working to service customer requests.

セキュリティ

データは、組織の技術的フットプリントで最も価値のある部分です。 この柱では、認証によってアーキテクチャへのアクセスをセキュリティで保護し、アプリケーションやデータをネットワークの脆弱性から保護することに重点が置かれます。 暗号化などのツールを使用して、データの整合性を保護する必要もあります。

設計と実装から、デプロイと運用まで、アプリケーションのライフ サイクル全体を通してセキュリティを考える必要があります。 クラウドでは、ネットワークへの侵入や DDoS 攻撃などのさまざまな脅威に対する保護が提供されます。 しかし、それでもアプリケーション、プロセス、組織の文化にセキュリティを組み込む必要があります。

An illustration that shows the types of security threats and attacks that might affect your data in the cloud.

一般的な設計原則

これらそれぞれの柱に加えて、アーキテクチャ全体で考慮する必要がある一貫した設計原則があります。

  • アーキテクチャの進化を実現:静的なアーキテクチャというものは存在しません。 新しいサービス、ツール、テクノロジを利用できる場合は、それらを活用してアーキテクチャが進化できるようにします。

  • データを使用した意思決定:データを収集して分析し、アーキテクチャに関する意思決定を行うために使用します。 コスト データからパフォーマンス、ユーザー負荷まで、データを使用することにより、お使いの環境で適切な選択を行うことができます。

  • 教育と有効化:クラウド テクノロジは急速に進化します。 開発、運用、およびビジネス チームに対して、ビジネス上の問題を解決するための適切な意思決定とソリューションの構築を支援する教育を行います。 組織内の構成、決定、およびベスト プラクティスを文書化し、共有します。

  • 自動化: 手作業による活動を自動化することにより、運用コストが削減され、手動のステップによって発生するエラーが最小限に抑えられ、環境間の一貫性が確保されます。

共同責任

クラウドに移行すると、共同責任のモデルが導入されます。 このモデルでは、クラウド プロバイダーがアプリケーションの特定の側面を管理し、残りの部分についてはお客様が責任を負います。

オンプレミス環境では、すべてがお客様の責任です。 サービスとしてのインフラストラクチャ (IaaS)、さらにサービスとしてのプラットフォーム (PaaS) やサービスとしてのソフトウェア (SaaS) に移行すると、クラウド プロバイダーが責任を負う範囲が増えます。

この共同責任はアーキテクチャの決定で役割を果たします。これらの意思決定が、コスト、セキュリティ、アプリケーションの技術的な機能や運用上の機能に影響を及ぼす可能性があるからです。 これらの責任をプロバイダーに移すことによって、組織はビジネスに価値をもたらすことに専念し、コア ビジネス機能以外の活動から脱却することができます。

An illustration that shows the level of shared responsibilities in each type of cloud-service model.

設計の選択肢

理想的なアーキテクチャでは、できる限り安全で、パフォーマンスと可用性が高く、効率的な環境が構築されます。 ただし、何事もそうですが、トレードオフがあります。

以上の柱のすべてを最高水準で達成した環境を構築するには、コストがかかります。 そのコストは、費用を指す場合もあれば、構築の所要時間、あるいは運用の俊敏性を指す場合もあります。 それぞれの柱で行われる設計上の選択に影響を及ぼす優先順位は、すべての組織で異なります。 アーキテクチャを設計する際は、どのようなトレードオフが許容され、どのようなトレードオフが許容されないかを確認する必要があります。

Azure アーキテクチャの構築にあたって、留意すべき考慮事項は多々あります。 アーキテクチャに望まれるのは、安全で、スケーラブルで、可用性が高く、回復可能であることです。 それを可能にするには、コスト、組織の優先事項、リスクに基づいて決定を下す必要があります。