Azure でのミッション クリティカルなワークロードの横断的な懸念事項

主要な設計領域を横断する複数の横断的な懸念があります。 この記事では、各設計領域内での後続の考慮事項に関するこれらの横断的な懸念をコンテキスト化します。

重要

この記事は、 Azure Well-Architected ミッション クリティカルなワークロード シリーズの 一部です。 このシリーズに慣れていない場合は、ミッション クリティカルなワークロードとは何かから始めてお勧めします。

スケールの上限

Azure では、すべての顧客に対して一貫したサービス レベルを確保するために、さまざまな 制限 または クォータ が適用されます。 これらの制限の例としては、1 つのサブスクリプション内のデプロイ可能なリソースの数に関する制限や、ネットワークとクエリのスループットに対する制限があります。

サービスの制限は、ミッション クリティカルな大規模なワークロードに大きな影響を与える可能性があります。 持続可能な規模を確保するために、ターゲット アーキテクチャで使用されるサービスの制限を慎重に検討してください。 そうしないと、ワークロードの増加に合わせて、これらの制限の 1 つ以上に達する可能性があります。

重要

制限とクォータは、プラットフォームの進化に応じて変更される可能性があります。 Azure サブスクリプションとサービスの制限、クォータ、制約の現在の制限を必ずチェックしてください。

推奨事項

• リソースの構成、デプロイ、および管理に スケール ユニット アプローチ を採用します。
• サブスクリプションをスケール ユニットとして使用し、必要に応じてリソースとサブスクリプションをスケールアウトします。
• スケール制限が容量計画の一部として考慮されていることを確認します。
• 使用可能な場合は、既存のアプリケーション環境に関するデータを使用して、発生する可能性のある制限を調べることができます。

Automation

デプロイと管理アクティビティの自動化に対する包括的なアプローチにより、ワークロードの信頼性と操作性を最大化できます。

推奨事項

• すべてのアプリケーション コンポーネントの継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインを自動化します。
• パッチ適用や監視などのアプリケーション管理アクティビティを自動化します。
• 命令型アプローチではなく、コードとしてのインフラストラクチャ (IaC) などの宣言型管理セマンティクスを使用します。
• スクリプトよりもテンプレートの優先順位を付けます。 テンプレートを使用する場合にのみスクリプトを延期することはできません。

Azure ロードマップの配置

Azure は、サービス、機能、リージョンの可用性に対する頻繁な更新によって絶えず進化しています。 ターゲット アーキテクチャを Azure プラットフォーム ロードマップに合わせて調整し、最適なアプリケーション軌道を通知することが重要です。 たとえば、選択したデプロイ リージョン内で必要なサービスと機能を使用できることを確認します。

新しいサービスと機能に関する最新情報については、「 Azure の更新プログラム 」を参照してください。

推奨事項

• Azure エンジニアリング ロードマップとリージョン ロールアウト 計画に合わせます。
• プレビュー サービスを使用するか、Azure プラットフォーム ロードマップに依存してブロックを解除します。
• コミットされたサービスと機能にのみ依存します。Microsoft エンジニアリング製品グループとのロードマップの依存関係を検証します。

次のステップ

ミッション クリティカルなワークロードを構築するための重要な考慮事項と推奨事項を提供する設計領域について説明します。

アーキテクチャ パターン