デプロイエラー軽減戦略を設計するための推奨事項

  • [アーティクル]

この Azure Well-Architected Framework のオペレーショナル エクセレンス チェックリストの推奨事項に適用されます。

OE:12 迅速な復旧に関するロールアウト途中の予期しない問題に対処するデプロイ エラー軽減戦略を実装します。 ロールバック、機能の無効化、デプロイ パターンのネイティブ機能の使用など、複数のアプローチを組み合わせます。

このガイドでは、デプロイエラーを効果的に処理するための標準化された戦略を設計するための推奨事項について説明します。 他のワークロードの問題と同様に、デプロイエラーはワークロードライフサイクルの避けられない部分です。 この考え方を使用すると、デプロイの失敗に対処するための適切に設計された意図的な戦略を用意することで、プロアクティブにすることができます。 このような戦略により、ワークロード チームは、エンド ユーザーに与える影響をできるだけ少なくして、障害を効率的に軽減できます。

このような計画が存在しない場合、問題に対する混同的で有害な対応につながる可能性があり、チームと組織のまとまり、顧客の信頼、財務に大きな影響を与える可能性があります。

主要な設計戦略

開発プラクティスが成熟しているにもかかわらず、デプロイの問題が発生することがあります。 安全なデプロイ プラクティスを使用し、堅牢なワークロード サプライ チェーンを運用すると、デプロイの失敗頻度を最小限に抑えることができます。 ただし、失敗したデプロイが発生したときに処理する標準化された戦略を設計する必要もあります。

プログレッシブ 露出デプロイ モデルを標準プラクティスとして使用する場合:

  • デプロイが失敗した場合の顧客または内部ユーザーへの影響を最小限に抑えるための適切な基盤があります。
  • 問題を効率的に軽減できます。

デプロイ エラー軽減戦略は、次の 5 つの広範なフェーズで構成されます。

  1. 検出: 失敗したデプロイに応答するには、まず障害を検出する必要があります。 検出には、スモーク テストの失敗、ユーザーから報告された問題、監視プラットフォームによって生成されるアラートなど、いくつかの形式が使用される場合があります。

  2. 決定: 特定の障害の種類に最適な軽減策を決定する必要があります。

  3. 軽減策: 特定された軽減策アクションを実行します。 この軽減策は、フォールバック、ロールバック、ロールフォワード、またはランタイム構成を使用して問題のある関数をバイパスする形式をとることができます。

  4. コミュニケーション: 関係者と影響を受けるエンド ユーザーは、 緊急対応計画で必要に応じて問題を検出して処理する際に、状態を認識する必要があります。

  5. 事後分析: 責任のない事後分析は、ワークロード チームが改善の領域を特定し、学習を適用する計画を作成する機会を提供します。

次のセクションでは、これらのフェーズの詳細な推奨事項について説明します。 これらのセクションでは、1 つ以上のユーザーまたはシステムグループに変更を展開した後、ロールアウト計画のすべてのグループを更新する前に問題を検出することを前提としています。

検出

デプロイに関する問題をすばやく特定するには、デプロイに関連する堅牢なテストと 監視のプラクティス が必要です。 異常をすばやく検出するために、次の手順を実行して、ワークロードの監視とアラートを補完できます。

スモーク テストやその他の品質テストは、ロールアウトの各フェーズで行う必要があります。 1 つのデプロイ グループで成功したテストは、後続のグループでテストする決定に影響を与えるべきではありません。

ユーザーの問題とデプロイ フェーズを関連付けるテレメトリを実装できます。 その後、特定のユーザーが関連付けられているロールアウト グループをすばやく特定できます。 この方法は、段階的な露出のデプロイでは特に重要です。これは、デプロイの特定の時点でユーザー ベース全体で複数の構成が実行されている可能性があるためです。

ユーザーから報告された問題にすぐに対応する準備ができているはずです。 実用的な場合は常に、完全なサポート チームが利用可能な時間帯にロールアウト フェーズをデプロイします。 適切なルーティングのためにデプロイの問題をエスカレートする方法について、サポート スタッフがトレーニングされていることを確認します。 エスカレーションは、ワークロード の緊急対応計画に合わせる必要があります。

決定

特定のデプロイの問題に対する適切な軽減戦略を決定するには、次のような多くの要因を考慮する必要があります。

  • 使用するプログレッシブ 露出モデルの種類。 たとえば、青緑色のモデルやカナリア モデルを使用できます。

    青緑色のモデルを使用する場合は、ロールバックよりもフォールバックの方が実用的です。 更新されていない構成を実行するスタックにトラフィックを簡単に戻すことができます。 その後、問題のある環境で問題を解決し、適切なタイミングでデプロイを再試行できます。

  • 問題を回避するために自由に使用できるメソッド。 たとえば、機能フラグ、環境変数、またはその他の種類のランタイム構成プロパティを使用してオンとオフを切り替えることができます。

    機能フラグをオフにしたり、設定を切り替えたりすることで、問題を簡単に回避できる場合があります。 この場合、次のことが可能な場合があります。

    • ロールアウトに進みます。
    • フォールバックは避けてください。
    • 問題のあるコードを修正しながらロールバックします。

  • コードに修正プログラムを実装するために必要な作業レベル。

    コードを修正する作業のレベルが低い場合は、ホットフィックスを実装してロールフォワードすることが、特定のシナリオに適した選択肢です。

  • 影響を受けるワークロードの重要度のレベル。

    ダウンタイムなしのデプロイを実現するには、ブルーグリーン モデルのように、ビジネスクリティカルなワークロードを常に並べてデプロイする必要があります。 その結果、フォールバックは、これらの種類のワークロードに適した軽減策です。

  • ワークロードが使用するインフラストラクチャの種類 (変更可能または不変)。

    ワークロードが変更可能なインフラストラクチャを使用するように設計されている場合は、インフラストラクチャの更新が必要になるため、ロールフォワードが理にかなっている可能性があります。 逆に、変更できないインフラストラクチャを使用する場合は、ロールバックまたはフォールバックが理にかなっている可能性があります。

どの選択を行っても、意思決定プロセスに適切な承認を含め、デシジョン ツリーに体系化する必要があります。

対応策

  • ロールバック: ロールバック シナリオでは、更新されたシステムを最新の正常な構成状態に戻します。

    ワークロード チーム全体が 、最後に既知の良い点の意味について同意することが重要です。 この式は、デプロイが開始される前に正常だったワークロードの最後の状態を指します。これは、必ずしも以前のアプリケーション バージョンではありません。

    ロールバックは、特にデータの変更に関連するため、複雑になる可能性があります。 スキーマを変更すると、ロールバックが危険になる可能性があります。 安全に実装するには、かなりの計画が必要な場合があります。 一般的な推奨事項として、スキーマの更新は付加的である必要があります。 置き換えの変更にしないでください。レコードを新しいレコードに置き換えてはいけません。 代わりに、古いレコードは非推奨とされ、非推奨のレコードを削除しても安全になるまで、新しいレコードと共存する必要があります。

  • フォールバック: フォールバック シナリオでは、更新されたシステムが運用トラフィック ルーティングから削除されます。 すべてのトラフィックは、更新されていないスタックに送信されます。 このリスクの低い戦略では、さらに中断を導入することなく、コード内の問題に対処する方法が提供されます。

    カナリアデプロイでは、インフラストラクチャとアプリの設計によっては、フォールバックが簡単ではないか、不可能な場合もあります。 更新されていないシステムの負荷を処理するためにスケーリングを実行する必要がある場合は、フォールバックする前にそのスケーリングを実行してください。

  • 問題のある関数をバイパスする: 機能フラグまたは別の種類のランタイム構成プロパティを使用して問題をバイパスできる場合は、ロールアウトを続行することが特定の問題に対する適切な戦略であると判断できます。

    関数をバイパスすることのトレードオフを明確に理解し、そのトレードオフを利害関係者に伝えることができるはずです。 利害関係者は、先送り計画を承認する必要があります。 利害関係者は、低下した状態で動作するために許容できる時間の長さを決定する必要があります。 また、問題のあるコードを修正してデプロイするために必要な時間の見積もりと比較して、その決定を比較検討する必要があります。

  • 緊急展開 (ホットフィックス): ロールアウトの途中で問題に対処できる場合は、最も実用的な軽減策がホットフィックスである可能性があります。

    他のコードと同様に、ホットフィックスは安全なデプロイプラクティスを実行する必要があります。 しかし、ホットフィックスを使用すると、タイムラインはかなり加速されます。 環境全体でコードプロモーション戦略を使用する必要があります。 また、すべての品質ゲートでホット フィックス コードをチェックする必要があります。 ただし、ベイク時間を大幅に短縮する必要があり、テストを高速化するためにテストを変更する必要がある場合があります。 デプロイ後に、更新されたコードでできるだけ早く完全なテストを実行できることを確認します。 品質保証テストを高度に自動化することで、これらのシナリオでテストを効率的に行うことができます。

トレードオフ:

  • フォールバックできるということは、通常、2 つのバージョンのワークロード構成を同時に処理するのに十分なインフラストラクチャ容量が必要であることを意味します。 ワークロード チームは、運用環境で 2 つのバージョンを同時にサポートできる必要もあります。
  • 効果的にロールバックするには、ワークロードの要素のリファクタリングが必要になる場合があります。 たとえば、関数を分離したり、データ モデルを変更したりする必要がある場合があります。

通信

インシデント時の混乱を最小限に抑えるために、コミュニケーションの責任を明確に定義することが重要です。 これらの責任は、ワークロード チームが、緊急対応マネージャーなどのサポート チーム、利害関係者、緊急対応チームの担当者と連携する方法を確立する必要があります。

状態の更新を提供するために、ワークロード チームが従う頻度を標準化します。 利害関係者がこの標準を認識していることを確認して、更新プログラムを期待するタイミングを把握します。

ワークロード チームがエンド ユーザーと直接通信する必要がある場合は、ユーザーとの共有に適した情報の種類と詳細レベルを明確にします。 また、これらのケースに適用されるその他の要件についてもワークロード チームに伝えます。

事後評価

事後分析は、例外なく、失敗したすべてのデプロイに従う必要があります。 失敗したデプロイはすべて学習の機会です。 事後分析は、デプロイと開発プロセスの弱点を特定するのに役立ちます。 また、他の多くの可能性の中でも、インフラストラクチャ内の構成の誤りを特定する可能性があります。

事後分析は、インシデントに関与している個人が、改善できる点に関する視点を共有するときに安全に感じることができるように、常に責任を負う必要があります。 事後分析のリーダーは、特定された機能強化を実装し、これらの計画をワークロード バックログに追加するための計画をフォローアップする必要があります。

考慮事項と一般的な推奨事項

最新の既知の適切な構成を簡単にデプロイできるように、デプロイ パイプラインで個別のバージョンをパラメーターとして受け入れることを確認します。

ロールバックまたはロールフォワードを行う際に、管理プレーンとデータ プレーンとの一貫性を維持します。 リソースとポリシーに固有のキー、シークレット、データベース状態データ、および構成はすべて、スコープ内に存在し、考慮する必要があります。 たとえば、前回の既知の適切なデプロイでのインフラストラクチャ スケーリングの設計に注意してください。 コードを再デプロイするときに、その構成を調整する必要があるかどうかを判断します。

新しいデプロイと最後に既知の適切なデプロイの間の差分が小さかるように、頻度の低い大きな変更よりも小さく、頻繁な変更を優先します。

継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインで 障害モード分析 (FMA ) を実行して、軽減策を複雑にする可能性がある問題を特定します。 ワークロード全体と同様に、パイプラインを分析して、特定の軽減策の種類を試みたときに問題になる可能性のある領域を特定できます。

自動ロールバック機能を慎重に使用します。

  • Azure DevOps などの一部の CI/CD ツールには、組み込みの自動ロールバック機能があります。 この機能が具体的な価値を提供する場合は、この機能の使用を検討してください。
  • 自動ロールバック機能は、パイプラインを徹底的かつ定期的にテストした後にのみ採用する必要があります。 自動ロールバックがトリガーされた場合は、パイプラインが十分に成熟し、追加の問題が発生していることを確認します。
  • 自動化によって必要な変更のみがデプロイされ、必要な場合にのみトリガーされることを信頼する必要があります。 これらの要件を満たすように、トリガーを慎重に設計します。

ロールバック中にプラットフォームによって提供される機能を使用します。 たとえば、バックアップとポイントインタイム リストアは、ストレージとデータのロールバックに役立ちます。 または、仮想マシン (VM) を使用してアプリケーションをホストする場合は、インシデントの直前にあるチェックポイントに環境を復元すると役立ちます。

デプロイエラー軽減戦略全体を頻繁にテストします。 緊急対応計画やディザスター リカバリー計画と同様に、デプロイエラー計画は、チームがトレーニングを受け、定期的に実施している場合にのみ成功します。 カオス エンジニアリングと フォールト インジェクション テスト は、デプロイ軽減戦略をテストするための効果的な手法です。

トレードオフ: サポート チーム メンバーは、通常の業務を遂行し、緊急時にもサポートできる必要があります。 サポート チームが適切にスタッフを配置し、必要なすべての職務を遂行できるように、人員を増やす必要がある場合があります。 低い開発環境にデプロイする場合は、デプロイを十分にテストします。 この方法は、運用環境に到達する前にバグや構成の誤りを検出するのに役立ちます。

Azure ファシリテーション

  • Azure Pipelines には、 アプリケーションの CI/CD をサポートするためのビルド サービスとリリース サービスが用意されています。

  • Azure Test Plansは、使いやすいブラウザーベースのテスト管理ソリューションです。 このソリューションは、計画的な手動テスト、ユーザー受け入れテスト、探索的テストに必要な機能を提供します。 Azure Test Plansでは、利害関係者からのフィードバックを収集する方法も提供されます。

  • Azure Monitor は、クラウドおよびオンプレミス環境から監視データを収集、分析、対応するための包括的な監視ソリューションです。 監視には、堅牢なアラート プラットフォームが含まれています。 自動通知やその他のアクション (自動スケーリングやその他の自己復旧メカニズムなど) に対して、そのシステムを構成できます。

  • Application Insights は、アプリケーション パフォーマンス監視 (APM) 機能を提供する Monitor の拡張機能です。

  • Azure Logic Apps は、アプリ、データ、サービス、システムを統合する自動化されたワークフローを実行するためのクラウドベースのプラットフォームです。 Logic Apps を使用すると、更新が行われるたびに新しいバージョンのアプリケーションを作成できます。 Azure はバージョンの履歴を保持し、以前のバージョンを元に戻したり昇格させたりすることができます。

  • 多くの Azure データベース サービスには、ロールバックが必要な場合に役立つポイントインタイム リストア機能が用意されています。

  • Azure Chaos Studio Preview は、カオス エンジニアリングを使って、クラウド アプリケーションとサービスの回復性を測定、把握、改善するのに役立つマネージド サービスです。

オペレーショナル エクセレンスチェックリスト

推奨事項の完全なセットを参照してください。

オペレーショナル エクセレンスチェックリスト