Microsoft Azure Well-Architected Framework

Azure Well-Architected Framework は、ワークロードの品質向上に使用できる一連の基本原則です。 フレームワークは、優れたアーキテクチャの 5 つの柱で構成されています。コストの最適化、オペレーショナル エクセレンス、パフォーマンス効率、信頼性、セキュリティです。 これらの柱を組み込むことで、高品質で安定した効率的なクラウド アーキテクチャを作成できます。

Microsoft Azure Well-Architected Framework に含まれている原則を使用してワークロードを評価するには、「Microsoft Azure Well-Architected のレビュー」を参照してください。

また、Azure Advisor と Advisor スコアを使用して、ワークロードの体制を改善する機会を特定し、優先順位を付けることをお勧めします。 どちらのサービスも、すべての Azure ユーザーが Well-Architected フレームワークの 5 つの柱に無料で配置できます。

  • Azure Advisor は、ベスト プラクティスに従って Azure デプロイメントを最適化できるようにする、個人用に設定されたクラウド コンサルタントです。 リソースの構成と利用統計情報が分析され、Azure リソースの費用対効果、パフォーマンス、信頼性、オペレーショナル エクセレンス、およびセキュリティを向上させるために役立つソリューションが推奨されます。 Azure Advisor の詳細については、こちらを参照してください。

  • Advisor スコア は、Advisor の推奨事項をシンプルで実用的なスコアにまとめる Azure Advisor の中核となる機能です。 これにより、信頼性が高く、セキュリティで保護された、コスト効率の高いソリューションを構築するために必要な手順を実行しているかどうかが一目で確認でき、ワークロードの体制に最大限の改善をもたらすアクションに優先順位を付けることができるようになります。 Advisor スコアは 1 つの総合スコアと、各 Well-Architected の柱に対応するよう更に分類された 5 つのカテゴリ スコアで構成されます。 Advisor スコアの詳細については、こちらを参照してください。

重要な要素 説明
コストの最適化 もたらされる価値を最大化するためのコスト管理
オペレーショナル エクセレンス 運用環境でシステムを継続的に動作させる運用プロセスです。
パフォーマンス効率 負荷の変化に対応するためのシステムの能力。
信頼性 障害から回復して動作を続行するシステムの能力です。
Security 脅威からアプリケーションとデータを保護することです。

コストの最適化

クラウド ソリューションの設計では、増分の価値の早期生成に集中します。 Build-Measure-Learn の原則を適用し、市場投入までの時間を短縮する一方で、資本集約型ソリューションを回避します。 アーキテクチャに従量課金制の戦略を使用し、最初のバージョンに多額投資するのではなく、スケールアウトに投資します。 アーキテクチャにおける機会コストと、先発者の優位性と "ファスト フォロー" とのバランスを考慮します。 コスト計算ツールを使って、初期コストと運用コストを見積もります。 最後に、ソリューションのコスト制限を設定するポリシー、予算、コントロールを確立します。

コスト ガイダンス

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

この要素は、運用環境においてアプリケーションの稼働を維持する運用とプロセスを対象とするものです。 デプロイは、信頼性が高く、予測可能である必要があります。 人的ミスの可能性を下げるために、自動化されている必要があります。 迅速かつ定期的なプロセスであるべきで、新機能やバグ修正のリリースを遅らせることはありません。 同じくらい重要なのは、 更新プログラムに問題がある場合に、ご自分で迅速にロールバックまたはロールフォワードできる必要があるということです。

監視と診断は非常に重要です。 クラウド アプリケーションは、リモートのデータセンターで実行されます。ご自分でそのインフラストラクチャを、または場合によってはオペレーティング システムを、完全に制御することはできません。 大規模なアプリケーションでは、VM にログインして問題をトラブルシューティングすることや、複数のログ ファイルを調べることは現実的ではありません。 PaaS サービスでは、ログインする専用の VM すら存在しない場合があります。 システムに関する分析情報が監視と診断によって提供されるため、いつどこで障害が発生したかがわかります。 すべてのシステムは監視できる必要があります。 すべてのシステムにわたりイベント同士を関連付けることができる、共通の、一貫性のあるログ スキーマを使用します。

監視と診断のプロセスには、次のいくつかの異なるフェーズがあります。

  • インストルメンテーション。 アプリケーション ログ、Web サーバー ログ、Azure プラットフォームに組み込まれている診断などのソースから生データを生成します。
  • 収集と保存。 データを 1 か所に統合します。
  • 分析と診断。 問題をトラブルシューティングし、全体の正常性を確認します。
  • 視覚化とアラート。 テレメトリ データを使用して、傾向をつかみ、運用チームに警告します。

Azure Policy を介してリソース レベルのルールを適用することで、ワークロードをサポートするすべての資産に対してオペレーショナル エクセレンスのベスト プラクティスを確実に導入できます。 たとえば、Azure Policy は、ワークロードをサポートするすべての VM が、事前承認された VM SKU の一覧に準拠していることを確認するのに役立ちます。 Azure Advisor では、Azure Policy のベスト プラクティスをワークロードに実装する機会をすばやく特定するのに役立つ一連の Azure Policy 推奨事項が提供されています。

DevOps チェックリストを使用して、管理性と DevOps の観点からご自分の設計を確認してください。

オペレーショナル エクセレンスに関するガイダンス

パフォーマンス効率

パフォーマンス効率とは、ユーザーによって行われた要求に合わせて効率的な方法でワークロードをスケーリングできることです。 これを実現するための主な方法は、スケーリングを適切に使用し、スケーリングが組み込まれている PaaS サービスを実装することです。

アプリケーションをスケーリングする方法は、主に 2 つあります。 垂直スケーリング (スケール アップ) は、VM のサイズを大きくするなど、リソースの容量を増やすことです。 水平スケーリング (スケール アウト) とは、VM やデータベース レプリカなど、リソースの新しいインスタンスを追加することです。

垂直スケーリングに比べて、水平スケーリングには、次のような大きな利点があります。

  • まさしく、クラウド規模です。 何百何千台ものノードで動作し、1 台のノードでは不可能なスケールを実現するように、アプリケーションを設計できます。
  • 水平スケールは柔軟です。 負荷が増加した場合にさらにインスタンスを追加することや、負荷が低い期間にそれらを削除することができます。
  • スケールアウトは、予定に合わせて、または負荷の変化に応じて、自動的にトリガーできます。
  • スケールアウトは、スケール アップよりも低コストになる場合があります。 複数の小さな VM を実行するほうが、1 つの大きな VM を実行するよりもコストを抑えられます。
  • 水平スケーリングでは、冗長性を追加して回復性を向上させることができます。 インスタンスが停止した場合も、アプリケーションは動作し続けます。

垂直スケーリングの利点は、アプリケーションに変更を加えずに行えるということです。 ただし、ある時点で上限に達し、それ以上は何もスケール アップできなくなります。 その時点で、さらにスケーリングする場合は、水平スケーリングにする必要があります。

水平スケールは、システムに対して設計する必要があります。 たとえば、VM をスケールアウトするには、それをロード バランサーより後ろに配置します。 ただし、プール内の各 VM が、どのようなクライアント要求でも処理できる必要があります。そのため、アプリケーションは、ステートレスであるか、状態を外部 (たとえば、分散キャッシュ内) に保存する必要があります。 マネージド PaaS サービスには、多くの場合、水平スケーリングと自動スケーリングが組み込まれています。 これらのサービスのスケーリングを簡単に行えることは、PaaS サービスを使用する大きな利点です。

ただし、インスタンスの数を増やすだけでは、アプリケーションをスケーリングすることにはなりません。 別の場所のボトルネックが増大するだけになる可能性があります。 たとえば、より多くのクライアント要求を処理するように Web フロントエンドをスケーリングすると、データベース内のロック競合が引き起こされる可能性があります。 その場合は、データベースのスループットを向上させるために、オプティミスティック コンカレンシーやデータのパーティション分割など、その他の対策を検討する必要があります。

パフォーマンスと負荷のテストを常に実行して、このような潜在的なボトルネックを検出するようにします。 データベースなど、システムのステートフルな部分は、ボトルネックの最も一般的な原因であり、慎重に設計して水平にスケーリングする必要があります。 あるボトルネックを解決すると、別の場所の別のボトルネックが明らかになる場合があります。

スケーラビリティの観点から設計を確認するには、パフォーマンス効率チェックリストを使用します。

パフォーマンス効率に関するガイダンス

[信頼性]

信頼性の高いワークロードは、回復性と可用性の両方を備えたものです。 回復性とは、障害から回復して動作を続行する、システムの能力です。 回復性の目的は、障害の発生後にアプリケーションを十分に機能する状態に戻すことです。 可用性とは、ユーザーが必要なときにワークロードにアクセスできるかどうかです。

従来のアプリケーション開発では、平均故障間隔 (MTBF) の延長に重点が置かれていました。 システムに障害が発生しないようにすることに労力が費やされていました。 クラウド コンピューティングでは、次のいくつかの要因により、異なる考え方が必要になります。

  • 分散システムは複雑であり、1 か所での障害がシステム全体に連鎖する可能性があります。
  • クラウド環境のコストは、コモディティ化したハードウェアの使用によって低く保たれています。そのため、ハードウェア障害が時折発生することは予想しておく必要があります。
  • アプリケーションは、多くの場合、外部のサービスに依存しています。外部のサービスは、一時的に使用できなくなることや、利用量の多いユーザーに対しては容量を制限することがあります。
  • 今日のユーザーは、アプリケーションはオフラインになることなく毎日 24 時間使用できることを期待しています。

これらの要因すべてが、障害が時折発生することを予期し、障害から回復するようにクラウド アプリケーションを設計する必要があることを示しています。 Azure では、多くの回復性機能があらかじめプラットフォームに組み込まれています。 次に例を示します。

  • Azure Storage、SQL Database、Cosmos DB はすべて、1 つのリージョン内とリージョン全体の両方で、組み込みのデータ レプリケーションを提供します。
  • Azure マネージド ディスクは、ハードウェア障害の影響を抑えるために、さまざまなストレージ スケール ユニットに自動的に配置されます。
  • 可用性セット内の VM は、複数の障害ドメイン間で分散されます。 障害ドメインは、共通の電源とネットワーク スイッチを使用する、VM のグループです。 VM を複数の障害ドメイン間で分散すると、物理的なハードウェア障害、ネットワークの停止、または停電の影響を抑えることができます。

ただし、それでもまだ、ご自分のアプリケーションに回復性を組み込む必要はあります。 回復性戦略は、アーキテクチャのすべてのレベルで適用できます。 一時的なネットワーク障害の後にリモート呼び出しを再試行するなど、一時的な対処としての性質が強い緩和策もあれば、 セカンダリ リージョンへのアプリケーション全体のフェールオーバーなど、より大局的な緩和策もあります。 一時的な対処による緩和策で状況を大きく改善できます。 1 つのリージョンの全体に障害が発生することはほとんどありませんが、ネットワークの輻輳などの一時的な問題は珍しくありません。そのため、まず一時的な問題をターゲットにします。 障害発生時に障害を検出し、根本原因を特定するために、監視と診断を適切に行うことも重要です。

回復性のあるアプリケーションを設計するときには、ご自分の可用性要件を理解する必要があります。 どの程度のダウンタイムを許容できるのでしょうか。 これは、ある程度はコストによって決まります。 起こり得るダウンタイムによって貴社のビジネスが被るコストはいくらになるでしょうか。 アプリケーションの可用性を高めることにいくら投資すべきでしょうか。

信頼性に関するガイダンス

セキュリティ

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

ここでは、いくつかの一般的なセキュリティ領域について考えてみましょう。

ID 管理

ユーザーの認証と承認に Azure Active Directory (Azure AD) を使用することについて考えてみます。 Azure AD は、フル マネージドの ID 管理およびアクセス管理のサービスです。 これを使用して Azure 上にだけ存在するドメインを作成することや、ご自分のオンプレミスの Active Directory ID と統合することができます。 Azure AD は、Office365、Dynamics CRM Online、および多くのサードパーティ製 SaaS アプリケーションとも統合できます。 コンシューマー向けアプリケーションの場合、Azure Active Directory B2C では、ユーザーは自身の既存のソーシャル アカウント (Facebook、Google、LinkedIn など) で認証することや、Azure AD によって管理される、新しいユーザー アカウントを作成することができます。

オンプレミスの Active Directory 環境を Azure ネットワークと統合する場合は、ご自分の要件に応じて、いくつかの手法を使用できます。 詳細については、ID 管理の参照アーキテクチャをご覧ください。

インフラストラクチャの保護

デプロイする Azure リソースへのアクセスを制御します。 すべての Azure サブスクリプションには、Azure AD テナントとの信頼関係があります。 Azure ロールベースのアクセス制御 (Azure RBAC) を使用して、ご自分の組織内のユーザーに Azure リソースに対する適切なアクセス許可を付与します。 特定のスコープでユーザーまたはグループに Azure のロールを割り当てて、アクセス権を付与します。 スコープには、サブスクリプション、リソース グループ、または 1 つのリソースを指定できます。 インフラストラクチャに対するすべての変更を監査します。

アプリケーションのセキュリティ

一般に、アプリケーション開発でのセキュリティのベスト プラクティスは、クラウドにも当てはまります。 これらには、あらゆる場所での SSL の使用、CSRF 攻撃と XSS 攻撃からの保護、SQL インジェクション攻撃の防止などがあります。

クラウド アプリケーションでは、多くの場合、アクセス キーを持つ管理されたサービスが使用されます。 これらがソース管理に含まれることはありません。 Azure Key Vault にアプリケーション シークレットを保存することについて考えてみます。

データの支配権と暗号化

Azure のデータ サービスを使用するときは、ご自分のデータが適切な地理的ゾーンに留まるようにしてください。 Azure の geo レプリケートされている ストレージでは、同じ地理的リージョン内のペアのリージョンの概念が使用されます。

暗号化キーおよびシークレットを保護するには、Key Vault を使用します。 Key Vault を使用すると、ハードウェア セキュリティ モジュール (HSM) によって保護されているキーを使用して、キーとシークレットを暗号化できます。 多くの Azure Storage サービスおよび DB サービスでは、Azure StorageAzure SQL DatabaseAzure Synapse AnalyticsCosmos DB などで、保存データの暗号化がサポートされています。

セキュリティ リソース