{{Azure IaaS の回復性: 大規模環境での標準可用性}}

{{## はじめに ビジネスクリティカルなアプリケーションにとって、回復性はもはや任意ではありません。Microsoft は最新のガイダンスで、Azure IaaS がコンピュート、ストレージ、ネットワーク全体にわたる組み込み機能を活用し、最初から障害を見据えた設計を可能にし、ワークロードの可用性と復旧性を大規模に維持できることを示しています。

IT 管理者にとっての重要なメッセージは明確です。Azure はプラットフォーム機能を提供しますが、顧客側でも事業継続、復旧目標、障害シナリオに合わせてワークロードを設計する必要があります。

Azure IaaS 回復性ガイダンスの新しいポイント

Microsoft は、Infrastructure as a Service ワークロードにおける回復性について、より実践的でエンドツーエンドな視点を強調しています。

コンピュートの回復性

• Virtual Machine Scale Sets は、インスタンスを Availability Zones とフォールト ドメインに分散できます。
• Availability Zones は、リージョン内でデータセンター レベルの分離を提供します。
• これらの機能により、単一障害点を減らし、局所的な障害、計画メンテナンス、ゾーン障害の発生時でも正常なアプリケーション インスタンスを維持しやすくなります。

ストレージの継続性と復旧

• LRS, ZRS, GRS, and RA-GRS により、組織は複数のストレージ冗長化オプションを利用できます。
• Snapshots, Azure Backup, and Azure Site Recovery は、復元およびフェールオーバー計画を支援します。
• Microsoft は、特にステートフルなワークロードにおいて、ストレージの選択が recovery point objectives (RPO) と recovery time objectives (RTO) に直接影響すると強調しています。

ネットワークの回復性

• Azure Load Balancer は、正常なリソース間でトラフィックを分散します。
• Application Gateway は、Web アプリ向けの Layer 7 ルーティングをサポートします。
• Traffic Manager と Azure Front Door は、トラフィックのリダイレクトを支援し、エンドポイント間およびリージョン間のフェールオーバーをサポートします。
• 目的は、個々のインスタンス、ゾーン、またはエンドポイントに障害が発生しても、サービスへの到達性を維持することです。

IT 管理者にとって重要な理由

このガイダンスは、ミッションクリティカルなアプリケーションを運用しているチームや、クラウド移行を計画しているチームに特に relevant です。Microsoft は、あらゆる移行を、引き継いだ弱点を取り除き、冗長性を前提に再設計し、アーキテクチャを実際のビジネス影響に合わせる好機として捉えるよう組織に促しています。

この記事はまた、回復性が万能のアプローチではないことも改めて示しています。ステートレス アプリはオートスケーリングやインスタンス置き換えを重視できる一方で、ステートフル ワークロードでは、より強固なレプリケーション、バックアップ、フェールオーバー戦略が必要です。

推奨される次のステップ

• コンピュート、ストレージ、ネットワーク全体でアプリケーションの依存関係を確認する。
• ワークロード要件を目標 RPO および RTO の値にマッピングする。
• 適切な場合は、Availability Zones、冗長化オプション、フェールオーバー サービスを活用する。
• 隠れた単一障害点がないか、従来の lift-and-shift 設計を再評価する。
• チュートリアルとベスト プラクティスを得るために Azure IaaS Resource Center を確認する。

Azure IaaS の設計に早い段階で回復性を組み込む組織は、ダウンタイムを抑え、障害の影響を封じ込め、インシデント発生時により迅速にサービスを復旧できるようになります。}}