ビジネス ニーズに合わせて構築する

設計の決定はすべてビジネス要件によって正当化される必要があります。 この設計方針は当たり前のこととも言えますが、Azure アプリケーションを設計する際には、このことに留意することがきわめて重要です。

アプリケーションで数百万人、または数千人のユーザーをサポートする必要がありますか。 大量のトラフィック バーストが生じていますか。またはワークロードは安定していますか。 どのレベルのアプリケーション停止を許容できますか。 最終的には、ビジネス要件によってこれらの設計上の考慮事項が方向付けされます。

次のレコメンデーションは、ビジネス要件を満たすソリューションの設計と構築に役立ちます。

  • ビジネス目標を定義する (目標復旧時間 (RTO)、目標復旧時点 (RPO)、最大許容停止時間 (MTO) など)。 これらの数値を、アーキテクチャ関連の意思決定に反映させる必要があります。

    たとえば、ビジネスで非常に低い RTO と非常に低い RPO が要求されているとします。 これらの要件を満たすために、ゾーン冗長アーキテクチャの使用を選択することもできます。 ビジネスがより高い RTO と RPO を許容できる場合、冗長性を追加してもビジネス上のメリットがなく、余分なコストが追加される可能性があります。

  • 軽減する必要がある障害のリスクを考慮してください自己修復の設計ガイダンスに従って、多くの種類の一般的な障害モードに対して回復力を持つソリューションを設計します。 領域内のすべての可用性ゾーンに影響を与える可能性のある大規模な自然災害が発生した地理的領域など、可能性の低い状況を考慮する必要があるかどうかを検討してください。 これらのまれなリスクを軽減するには、通常、より費用がかかり、大きなトレードオフが伴うため、企業のリスク許容度を明確に理解する必要があります。

  • サービス レベル アグリーメント (SLA) とサービス レベル目標 (SLO) を文書化する (可用性とパフォーマンスのメトリックを含む)。 たとえば、提案されるソリューションでは、99.95% の可用性が提供される場合があります。 その SLO が SLA を満たしているかどうかは、ビジネス意思決定によって決まります。

  • ビジネス ドメインのアプリケーションをモデル化する。 ビジネス要件を分析し、これらの要件を使用してソリューションをモデル化します。 ドメイン駆動設計 (DDD) のアプローチを使用して、ビジネス プロセスとユース ケースを反映したドメイン モデルを作成することを検討してください。

  • 機能要件と非機能要件を定義する。 機能要件では、アプリケーションがそのタスクを実行するかどうかを判断します。 非機能要件では、アプリケーションが良好に動作するかどうかを判断します。 スケーラビリティ、可用性、待機時間などの非機能要件を確認するようにしてください。 これらの要件は、設計に関する意思決定とテクノロジの選択に影響します。

  • ワークロードを分解する。 この文脈で言うワークロードとは、他のタスクから論理的に分離することができる、個別の機能またはコンピューティング タスクのこと指します。 ワークロードが違えば、可用性、スケーラビリティ、データ整合性、およびディザスター リカバリーの要件も違ってくる可能性があります。

  • 成長に対応可能な計画を立てる。 ソリューションでは、ユーザー数、トランザクションの量、およびデータ ストレージの現在のニーズがサポートされているとしても、主要なアーキテクチャを変更することなく、成長に対応できるようにする必要もあります。 また、ビジネス モデルやビジネス要件は時間の経過と共に変化していくということも考慮するようにしてください。 アプリケーションのサービス モデルやデータ モデルが柔軟性に乏しいと、新たなユース ケースやシナリオに合わせてアプリケーションを改良することが困難になります。

  • コストを管理する。 従来型のオンプレミス アプリケーションでは、ハードウェアのための初期費用を資本支出として支払う必要がありました。 クラウド アプリケーションでは、使用するリソースごとに費用を支払うことになります。 サービスの価格設定モデルを把握するようにしましょう。 全体のコストは、ネットワーク帯域幅の使用量、ストレージ、IP アドレス、サービス消費量によって決まってきます。

    また、運用コストについても検討してください。 クラウドでは、ハードウェアやインフラストラクチャを管理する必要はありませんが、アプリケーションの DevOps、インシデント応答、ディザスター リカバリーを管理する必要があります。

次のステップ