デプロイ エラーの軽減戦略の設計に関する推奨事項
Azure Well-Architected フレームワークのオペレーショナル エクセレンスに関するチェックリストの次の推奨事項を対象とします。
| OE:12 | ロールアウト中の予期しない問題に迅速な復旧で対処する展開の失敗軽減戦略を実装します。 ロールバック、機能の無効化、展開パターンのネイティブ機能の使用などの、複数のアプローチを組み合わせます。 |
|---|
このガイドでは、展開の失敗を効果的に処理する標準化された戦略を設計するための推奨事項について説明します。 他のワークロードの問題と同様に、展開の失敗はワークロード ライフサイクルで避けられない部分です。 このように考えて、展開の失敗に対処するための適切に設計された意図的な戦略を用意することで、事前に対策を講じることができます。 このような戦略により、ワークロード チームは、エンド ユーザーへの影響をできるだけ少なくして、失敗を効率的に軽減できます。
このような計画がないと、問題に対して、雑然とした弊害をもたらす可能性がある対応が行われる場合があり、チームと組織のまとまり、顧客の信頼、および財務に大きな影響を与える可能性があります。
主要な設計戦略
開発方法が成熟しているにもかかわらず、展開の問題が発生する場合があります。 安全な展開方法を使用し、堅牢なワークロード サプライ チェーンを運用することで、展開の失敗頻度を最小限に抑えることができます。 ただし、展開の失敗が発生したときに処理する標準化された戦略を設計することも必要です。
標準的な方法として段階的公開展開モデルを使用するとき:
- 展開が失敗したときの顧客または内部ユーザーへの影響を最小限に抑えるための適切な基盤があります。
- 問題を効率的に軽減できます。
展開の失敗軽減戦略は、次の 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 は、クラウド環境とオンプレミス環境からの監視データを収集し、分析し、それに対応するための包括的な監視ソリューションです。 Monitor には、堅牢なアラート プラットフォームが含まれています。 そのシステムを、自動スケーリングやその他の self-healing メカニズムなどの、自動通知やその他のアクション用に構成できます。
Application Insights は、アプリケーション パフォーマンス監視 (APM) 機能を提供する Monitor の拡張機能です。
Azure Logic Apps は、アプリ、データ、サービス、およびシステムを統合する自動化されたワークフローを実行するためのクラウドベースのプラットフォームです。 Logic Apps を使用して、アプリケーションが更新されるたびに新しいバージョンを作成できます。 Azure はバージョンの履歴を維持するため、以前のバージョンに戻すことや、以前のバージョンを昇格することができます。
多くの Azure データベース サービスは、ロールバックが必要なときに役立つポイントインタイム リストア機能を提供します。
Azure Chaos Studio Preview は、カオス エンジニアリングを使って、クラウド アプリケーションとサービスの回復性を測定、把握、改善するのに役立つマネージド サービスです。
関連リンク
- 機能フラグを使用した段階的な実験
- 監視フレームワークの設計と作成に関する推奨事項
- 緊急時対応戦略の設計に関する推奨事項
- 信頼性テスト戦略を設計するための推奨事項
- ワークロード開発サプライ チェーンの設計に関する推奨事項
- 障害モード分析を実行するための推奨事項
- 安全なデプロイの実践に関する推奨事項
オペレーショナル エクセレンス チェックリスト
レコメンデーションの完全なセットを参照してください。