ビジネス ニーズに合わせて構築する
設計の決定はすべてビジネス要件によって正当化される必要があります。 この設計方針は当たり前のこととも言えますが、Azure アプリケーションを設計する際には、このことに留意することがきわめて重要です。
アプリケーションで数百万人、または数千人のユーザーをサポートする必要がありますか。 大量のトラフィック バーストが生じていますか。またはワークロードは安定していますか。 どのレベルのアプリケーション停止を許容できますか。 最終的には、ビジネス要件によってこれらの設計上の考慮事項が方向付けされます。
次のレコメンデーションは、ビジネス要件を満たすソリューションの設計と構築に役立ちます。
ビジネス目標を定義する (目標復旧時間 (RTO)、目標復旧時点 (RPO)、最大許容停止時間 (MTO) など)。 これらの数値を、アーキテクチャ関連の意思決定に反映させる必要があります。
たとえば、ビジネスで非常に低い RTO と非常に低い RPO が要求されているとします。 これらの要件を満たすために、ゾーン冗長アーキテクチャの使用を選択することもできます。 ビジネスがより高い RTO と RPO を許容できる場合、冗長性を追加してもビジネス上のメリットがなく、余分なコストが追加される可能性があります。
軽減する必要がある障害のリスクを考慮してください。 自己修復の設計ガイダンスに従って、多くの種類の一般的な障害モードに対して回復力を持つソリューションを設計します。 領域内のすべての可用性ゾーンに影響を与える可能性のある大規模な自然災害が発生した地理的領域など、可能性の低い状況を考慮する必要があるかどうかを検討してください。 これらのまれなリスクを軽減するには、通常、より費用がかかり、大きなトレードオフが伴うため、企業のリスク許容度を明確に理解する必要があります。
サービス レベル アグリーメント (SLA) とサービス レベル目標 (SLO) を文書化する (可用性とパフォーマンスのメトリックを含む)。 たとえば、提案されるソリューションでは、99.95% の可用性が提供される場合があります。 その SLO が SLA を満たしているかどうかは、ビジネス意思決定によって決まります。
ビジネス ドメインのアプリケーションをモデル化する。 ビジネス要件を分析し、これらの要件を使用してソリューションをモデル化します。 ドメイン駆動設計 (DDD) のアプローチを使用して、ビジネス プロセスとユース ケースを反映したドメイン モデルを作成することを検討してください。
機能要件と非機能要件を定義する。 機能要件では、アプリケーションがそのタスクを実行するかどうかを判断します。 非機能要件では、アプリケーションが良好に動作するかどうかを判断します。 スケーラビリティ、可用性、待機時間などの非機能要件を確認するようにしてください。 これらの要件は、設計に関する意思決定とテクノロジの選択に影響します。
ワークロードを個別の機能に分解する。 ワークロードとは、定義されたビジネス成果を達成するために連携して機能するアプリケーション リソース、データ、およびサポート インフラストラクチャの集合です。 ワークロードを構成する要素には、コンポーネントだけでなく、開発および運用の手順も含まれます。 ワークロードは、多くの場合、ユーザー、データ、またはシステム フローに一致する個別の機能に分解でき、このようなフローに価値や非機能要件を割り当てることができます。
ユーザー、データ、システム フローが違えば、可用性、スケーラビリティ、データ整合性、およびディザスター リカバリーの要件も異なることが少なくありません。 適切に設計されたシステムでは、フローごとに設計を最適化できます。 これを実現するには、ワークロードを調整可能なコンポーネントに分割する必要があります。 一般的な戦略では、コンポーネントをその価値に基づいて分類します。 たとえば、レベル 1 コンポーネントは重要であり、費用に関係なく最適化する必要があります。 レベル 2 コンポーネントは重要ですが、影響を最小限に抑えて一時的に削減できます。 レベル 3 コンポーネントは省略可能であり、コスト効率と管理性に優れたものにする必要があります。 フローの価値についての共通理解を確立しておくと、ワークロードの設計および改善に関わる全員で、コストとその他の非機能要件のバランスを保つために役立ちます。
成長に対応可能な計画を立てる。 ソリューションでは、ユーザー数、トランザクションの量、およびデータ ストレージの現在のニーズがサポートされているとしても、主要なアーキテクチャを変更することなく、成長に対応できるようにする必要もあります。 また、ビジネス モデルやビジネス要件は時間の経過と共に変化していくということも考慮するようにしてください。 アプリケーションのサービス モデルやデータ モデルが柔軟性に乏しいと、新たなユース ケースやシナリオに合わせてアプリケーションを改良することが困難になります。
ビジネス モデルとコストを合致させる。 システムの寿命は、コストがビジネス モデルとどれだけ効果的に合致しているかによって左右されます。 アーキテクトは、価値の推進要因を考慮し、その分析情報に基づいて意思決定を行う必要があります。 ソリューションが価値を提供するディメンション (収益性など) を特定し、アーキテクチャがバリュー ストリームに沿っていることを確認します。 こうすることで、アーキテクチャは投資に対する価値を最大化し、ビジネス要件に沿った投資収益率 (ROI) を実現できます。
コストを管理する。 従来型のオンプレミス アプリケーションでは、ハードウェアのための初期費用を資本支出として支払う必要がありました。 クラウド アプリケーションでは、使用するリソースごとに費用を支払うことになります。 サービスの価格設定モデルを把握するようにしましょう。 全体のコストは、ネットワーク帯域幅の使用量、ストレージ、IP アドレス、サービス消費量によって決まってきます。
また、運用コストについても検討してください。 クラウドでは、ハードウェアやインフラストラクチャを管理する必要はありませんが、アプリケーションの DevOps、インシデント応答、ディザスター リカバリーを管理する必要があります。