シフト ライトで実稼働環境でテストする

右にシフトとは、DevOps プロセスの後半の一部のテストを運用環境でのテストに移動する実践です。 実稼働環境でのテストでは、実際のデプロイメントを使用して、実稼働環境でのアプリケーションの動作とパフォーマンスを検証および測定します。

DevOps チームが速度を向上させる 1 つの方法は、シフトレフト テスト戦略を使用することです。 シフトレフトを選択すると、ほとんどのテストが DevOps パイプラインの早い段階で実行され、新しいコードが運用環境に到達して確実に動作するまでの時間が短縮されます。

ただし、単体テストなどの多くの種類のテストは簡単に左にシフトできますが、一部のクラスのテストはソリューションの一部または全体をデプロイしないと実行できません。 QA またはステージング サービスにデプロイすると、同等の環境をシミュレートできますが、運用環境に完全に代わるものはありません。 チームは、特定の種類のテストを実稼働環境で実行する必要があることに気付きました。

本番環境でのテストでは次のことが可能になります。

• 生産環境の広さと多様性。
• 顧客トラフィックの実際のワークロード。
• 時間の経過とともに変化する生産需要に応じたプロファイルと行動。

生産環境は常に変化し続けています。 アプリが変化しなくても、アプリが依存するインフラストラクチャは常に変化します。 運用環境でのテストは、特定の運用環境と常に変化する運用環境の正常性と品質を検証します。

運用環境でのテストに移行することは、次のシナリオでは特に重要です。

マイクロサービスの導入

マイクロサービス ベースのソリューションには、個別に開発、デプロイ、管理される多数のマイクロサービスを含めることができます。 さまざまなバージョンや構成がさまざまな方法で運用環境に到達する可能性があるため、これらのプロジェクトではテストを適切に移行することが特に重要です。 実稼働前のテスト範囲に関係なく、実稼働環境での互換性をテストする必要があります。

導入後の品質の確保

運用環境へのリリースは、ソフトウェアの配信の半分にすぎません。 残りの半分は、本番環境で実際のワークロードを使用して大規模な品質を確保することです。 環境は変化し続けるため、チームは本番環境でのテストが完了することはありません。

本番環境からのテスト データは、文字通り、実際の顧客のワークロードからのテスト結果です。 実稼働環境でのテストには、モニタリング、フェイルオーバー テスト、障害挿入が含まれます。 このテストでは、障害、例外、パフォーマンス メトリック、およびセキュリティ イベントを追跡します。 テスト テレメトリは、異常の検出にも役立ちます。

展開リング

運用環境を保護するために、チームはリングベースの展開と機能フラグを使用して、段階的かつ制御された方法で変更をロールアウトできます。 たとえば、展開リングに参加している顧客が 1% 未満の場合に買い物客が購入を完了できないバグは、すべての顧客を一度に切り替えた後よりも捕らえやすいです。 検出された障害の特徴量は、特定のビジネスにとって有意義な方法で測定された、それらの障害による純損失を超える必要があります。

最初のリングは、標準統合スイートを実行するのに必要な最小サイズである必要があります。 テストは、他の環境に対してパイプラインですでに実行されているものと似ている可能性がありますが、テストにより、動作が運用環境でも同じであることが検証されます。 このリングは、構成ミスなどの明らかなエラーを、顧客に影響を与える前に識別します。

最初のリングが検証された後、次のリングを拡張して、テスト実行のために実際のユーザーのサブセットを含めることができます。 すべてが良好であれば、全員が使用できるようになるまで、さらにリングとテストを経て展開を進めることができます。 完全な展開はテストが終了したことを意味するものではありません。 テレメトリの追跡は、運用環境でのテストにとって非常に重要です。

フォールト挿入

チームは多くの場合、フォールト インジェクションとカオス エンジニアリングを使用して、障害状況下でシステムがどのように動作するかを確認します。 これらの実践は次のことに役立ちます。

• 実装された復元メカニズムが実際に機能することを検証します。
• 1 つのサブシステムの障害がそのサブシステム内に収まり、連鎖的に大規模な停止が発生しないことを検証します。
• 別のインシデントの発生を待つことなく、以前のインシデントの修復作業が望ましい効果をもたらしたことを証明します。
• 現場のエンジニア向けに、より現実的な訓練訓練を作成して、インシデントへの対処をより適切に準備できるようにします。

フォールト挿入実験は、常に変化するシステム上で実行する必要がある高価なテストであるため、自動化することをお勧めします。

カオス エンジニアリングは効果的なツールとなり得ますが、顧客への影響がほとんどまたはまったくないカナリア環境に限定する必要があります。

フェイルオーバーテスト

障害挿入の 1 つの形式は、事業継続性と災害復旧 (BCDR) をサポートするフェールオーバー テストです。 チームはすべてのサービスとサブシステムのフェイルオーバー計画を立てる必要があります。 計画には以下を含める必要があります。

• サービスの停止によるビジネスへの影響についての明確な説明。
• サービスの停止によるビジネスへの影響についての明確な説明。
• 災害復旧手順の正式な文書化。
• 定期的に災害復旧訓練を実施するリズム。

サーキットブレーカーの故障テスト

サーキット ブレーカー メカニズムは、通常、そのコンポーネントの障害が境界外に広がるのを防ぐために、特定のコンポーネントを大規模なシステムから切り離します。 意図的にサーキット ブレーカーをトリガーして、次のシナリオをテストできます。

• サーキットブレーカーが開いたときにフォールバックが機能するかどうか。 フォールバックは単体テストでは機能する可能性がありますが、実稼働環境で期待どおりに動作するかどうかを知る唯一の方法は、フォールバックをトリガーするフォールトを挿入することです。

• 回路ブレーカーが必要なときに開くための適切な感度しきい値を持っているかどうか。 フォールト挿入により、ブレーカーの応答性を観察するためにレイテンシーを強制したり、依存関係を切断したりすることができます。 正しい動作が行われるだけでなく、それが十分に迅速に行われることを検証することが重要です。

例: Redis キャッシュ サーキット ブレーカーのテスト

Redis キャッシュ は、一般的に使用されるデータへのアクセスを高速化することにより、製品のパフォーマンスを向上させます。 Redis への重要ではない依存関係を持つシナリオを考えてみましょう。 Redis がダウンした場合でも、システムはリクエストに対して元のデータ ソースの使用にフォールバックできるため、システムは動作し続けるはずです。 Redis の障害によってサーキット ブレーカーがトリガーされ、本番環境でフォールバックが機能することを確認するには、これらの動作に対するテストを定期的に実行します。

次の図は、Redis サーキット ブレーカーのフォールバック動作のテストを示しています。 目標は、ブレーカーが開いたときに呼び出しが最終的に SQL に送られるようにすることです。

上の図は 3 つの AT を示しており、Redis への呼び出しの前にブレーカーがあります。 1 つのテストでは、構成変更によってサーキット ブレーカーを強制的に開き、呼び出しが SQL に送られるかどうかを観察します。 次に別のテストで、サーキット ブレーカーを閉じて、呼び出しが Redis に戻ることを確認することで、逆の構成変更をチェックします。

このテストは、ブレーカーが開いたときにフォールバック動作が機能することを検証しますが、サーキット ブレーカーの構成が必要なときにブレーカーを開くかどうかは検証しません。 その動作をテストするには、実際の障害をシミュレートする必要があります。

障害エージェントは、Redis に送信される呼び出しに障害を引き起こす可能性があります。 次の図は、フォールト挿入を使用したテストを示しています。

1. フォールト インジェクターは Redis リクエストをブロックします。
2. サーキット ブレーカーが開き、フォールバックが機能するかどうかをテストで観察できます。
3. 障害が解消され、サーキット ブレーカーはテスト リクエストを Redis に送信します。
4. リクエストが成功すると、呼び出しは Redis に戻ります。

さらなる手順では、ブレーカーの感度、しきい値が高すぎるか低すぎるか、他のシステム タイムアウトがサーキット ブレーカーの動作を妨げるかどうかをテストできます。

この例では、ブレーカーが予想どおりに開閉しない場合、ライブ サイト インシデント (LSI)が発生する可能性があります。 フォールト挿入テストがなければ、この種のテストをラボ環境で行うのは難しいため、問題が検出されない可能性があります。

次のステップ

• [単体テストでテストを左にシフト]shift-left
• マイクロサービスとは
• Azure へのテスト フェールオーバー (ディザスター リカバリー訓練) を実行する
• 安全なデプロイ プラクティス
• 監視とは
• プラットフォーム エンジニアリングとは