Deploy

The presented Microsoft Azure Well-Architected Framework recommendations in this guidance include Reliability Stage “4 - Deploy (Automation and Deployment)” and associated resources and their settings.

At this stage, the system is launched into a production environment. Proper deployment strategies, like blue-green or canary deployments, are used to minimize risks associated with releasing new versions.

コードとしてのインフラストラクチャ (IaC) は、DevOps 手法と記述モデルによるバージョン管理を使用して、ネットワーク、仮想マシン、ロード バランサー、接続トポロジなどのインフラストラクチャを定義およびデプロイします。同じソース コードから常に同じバイナリが生成されるのと同じように、IaC モデルはデプロイするたびに同じ環境を生成します。

IaC は重要な DevOps プラクティスであり、継続的デリバリーのコンポーネントです。 IaC を使用すると、DevOps チームは統一されたプラクティスとツールのセットを使用して連携して、アプリケーションとそのサポート インフラストラクチャを迅速かつ確実に大規模に提供できます。

キーポイント：
- 一貫性を確保するために手動構成を避ける
- 安定したテスト環境を大規模かつ迅速に提供
- 宣言型定義ファイルを使用する

Ensures consistent, scalable deployments

価値を継続的に提供することは、組織にとって必須の要件となっています。エンドユーザーに価値を提供するには、エラーなく継続的にリリースする必要があります。

継続的デリバリー (CD) は、ビルド、テスト、構成、およびビルドから実稼働環境へのデプロイメントを自動化するプロセスです。

リリース パイプラインでは、複数のテスト環境またはステージング環境を作成して、インフラストラクチャの作成を自動化し、新しいビルドをデプロイできます。後続の環境では、統合、負荷、およびユーザー受け入れテストの長期実行アクティビティが徐々にサポートされます。

Ensures error-free releases

信頼性のもう 1 つの側面は、ワークロードの更新またはロールバックに使用されるデプロイメント方法です。使用する展開方法が信頼性戦略に適合しており、ワークロードの可用性とパフォーマンスの要件をサポートしていることを確認する必要があります。たとえば、軽減したいリスクと影響のレベルに応じて、Blue-Green デプロイ、カナリア デプロイ、またはローリング デプロイの使用を選択できます。また、変更をデプロイする際には速度と安全性の間のトレードオフを考慮し、適切なテストおよび検証方法を使用してコードと構成の品質を確保する必要があります。さらに、展開の失敗に対処するための明確で文書化されたプロセスを用意し、変更や問題があれば関係者や顧客に伝える必要があります。

Align deployment strategy to reliability requirements

導入のさまざまな段階でクラウド ソリューションをテストすると、ソリューションの品質と信頼性が向上し、本番環境でのコストが高く損害を与えるインシデントのリスクを軽減できます。 「シフトレフト」アプローチを採用することで、単体テスト、スモーク テスト、ロード テスト、カオス テストを実行して、ソリューションの機能、統合、パフォーマンス、スケーラビリティ、復元力、耐障害性を検証できます。これらのテストは、お客様やユーザーに影響を与える前に、問題やバグを特定して修正するのに役立ちます。

Code has been extensively tested during build process

障害シナリオとは、内部または外部の要因により、クラウド ソリューションが期待どおりに動作しない、またはサービス レベル目標 (SLO) を満たさない可能性がある状況です。たとえば、障害シナリオには、ハードウェア障害、ネットワーク停止、セキュリティ違反、構成エラー、需要の予期せぬ急増、サードパーティ サービスへの依存などが含まれる場合があります。これらのシナリオを定期的にテストすると、ソリューションに対する障害の影響を評価し、障害を軽減するための緊急時対応計画を準備するのに役立ちます。フォールト インジェクション、災害復旧訓練、ゲームデー、カオス エンジニアリングなどのツールや手法を使用して、制御された環境で障害シナリオをシミュレートおよびテストできます。

Gain confidence in handling failures

リージョン フェールオーバーは、クラウド ソリューションのプライマリ リージョンで大規模な中断または停止が発生した場合に、セカンダリ リージョンに切り替えるプロセスです。リージョン フェールオーバーは、さまざまな地理的領域にわたってソリューションの可用性とパフォーマンスを維持するのに役立ちます。ただし、リージョン フェイルオーバーは簡単ではなく、慎重な計画とテストが必要です。定期的にリージョン フェールオーバーをテストして、バックアップ リージョンがソリューションの負荷と機能を処理できること、データがリージョン間で一貫性があり安全であること、フェールオーバーとフェールバックの手順が期待どおりに機能していることを確認する必要があります。リージョン フェールオーバーをテストすることは、ユーザーや顧客に影響を与える前に、フェールオーバー戦略の潜在的な問題やギャップを特定して解決するのにも役立ちます。

Ensure app resilience with regional failover testing

信頼性の高いフェイルオーバー戦略の重要な側面の 1 つは自動化です。自動化により、停止中のセカンダリ リージョンへの切り替えに伴う人的エラー、遅延、複雑さを軽減できます。ただし、特に停止の影響を受けるコンポーネントやサービスに依存している場合、自動化自体が障害や中断に対して脆弱になる可能性があります。したがって、フェイルオーバー自動化が利用可能であり、停止時にも回復力があること、および手動介入なしでフェイルオーバー自動化をトリガーできることを確認する必要があります。また、フェイルオーバー自動化を定期的に監視およびテストして、さまざまなシナリオや条件下で期待どおりに機能することを確認する必要があります。たとえば、潜在的なリージョン停止の軽減策としてリージョン フェールオーバーを使用している場合、バックアップ リージョンへのフェールオーバーを調整するために使用される自動化は、停止が発生するリージョンでホストされるべきではありません。ワークロードの運用環境が含まれていないリージョンでオートメーションをホストすることを検討してください。

Gain confidence in your failover automation