本番環境でのテストの概要

欠陥のリスク

本番環境でコードをテストする際の主な懸念は、ユーザーやサービスに影響を与える可能性のあるソフトウェアの欠陥を導入する可能性です。従来のソフトウェアテストパイプラインの背景にある考え方は、コードを本番環境の責任に昇格させる前に、徹底的に検証し、既知の弱点を確認することです。

この考え方には利点がありますが、実際には状況はそれほど明確ではありません。組織がステージング環境で実行するテストは、多くの場合、コードが本番環境で扱う内容を適切に近似していません。インフラストラクチャやワークロードを含む環境の複製は簡単な作業ではなく、実際の生産システムと同期がずれることがよくあります。

その結果、ステージング環境でテストした内容が、リリース後のコードのパフォーマンスに実際に適用できるとは限らないということです。さらに、その試みが成功するかどうかに関わらず、かなりの労力、時間、およびインフラストラクチャが必要です。

稼働中のシステムへの影響

密接に関連する懸念は、新しい変更とテストプロセス自体が本番環境に与える可能性のある影響です。システムの安定性は、サービスのユーザビリティや可用性に影響を与え、ユーザーの信頼を損なう可能性があるため、ほとんどの組織にとって優先事項です。

本番環境にデプロイされたコードが運用に影響を与える可能性があるのは事実ですが、潜在的な影響を最小限に抑える方法はあります。新しいコードが受けるトラフィックの量を制限する制御を実装すること、アクティブスタンバイインフラストラクチャを設定すること、監視ベースのスケーリングを実装することは、このプロセスをより安全にする方法の一部です。これらの種類の緩和策の素晴らしい点は、これらの投資が、あらゆる種類のシステム障害に対する本番システムの回復力を直接向上させることです。

フィーチャーフラグシステムを実装する

フィーチャーフラグは、機能を外部から簡単にアクティブ化または非アクティブ化できるようにするプログラミングおよびリリース手法です。基本的な考え方は、新しい機能を条件付きロジックで囲み、実行前に構成変数の値をチェックすることです。「フラグ」または「トグル」変数は、組織が必​​要に応じて値を簡単に変更できるRedisなどの外部ストアで設定されることがよくあります。

フィーチャーフラグは、本番システムの現在のロジックに影響を与えることなく、コードを安全にデプロイできるため、本番テストにおいて貴重なツールです。新しいコードパスは、最初に非アクティブ化され、新しいコードをテストする準備ができたときに後でアクティブ化できます。フィーチャーフラグの概念の多くの実装では、「有効」または「無効」よりもきめ細かな制御が含まれており、トラフィックの割合に対して有効にするオプション、異なるロジックをA/Bテストするオプション、または特定のケースでのみパスを選択するオプションがあります。

フィーチャーフラグを使用することで、コードを非アクティブな状態で本番環境にデプロイできます。本番トラフィックが古いロジックを使用し続ける間、新しいコードパスをテストスイートでテストできます。その後、新しいコードパスが受け取る本番トラフィックの量を徐々に増やしながら、カナリアリリースとしてコードをゆっくりとリリースし、その影響を監視できます。

CI/CD を使用して本番インフラストラクチャにデプロイし、テストする

本番環境でのテストに関する誤解の1つは、テストが本番環境で完了しなければならないという思い込みです。支持者は、コードが最終的に実行される環境でのテストの価値を認識していますが、すべてのテストがこの忠実度を必要とするわけではなく、多くの高速で集中的なテストは自動化され、コードのデプロイまでの準備の一部として実行できます。

これを実装する最も単純で効果的な方法は、適切に調整されたCI/CDパイプラインを使用することです。CI/CDは、継続的インテグレーション（Continuous Integration）と継続的デリバリー（Continuous Delivery）またはデプロイメント（Deployment）の略で、リポジトリに新しいコードが追加されると自動的にテストするシステムです。テストスイートが正常にパスすると、継続的デリバリーのパイプラインは開発者がボタンをクリックするだけで変更をデプロイできるようになり、継続的デプロイメントはテストが成功したすべてのコードを自動的にデプロイします。

CI/CD には、本番環境でのテストの文脈以外にも多くの利点があります。私たちが説明しているシステムでは、パイプラインはデプロイプロセスの一部を自動化し、本番環境でデプロイしてテストすることを目標とします。ユニットテストのような単純なテストは単独で行うことができますが、統合テストのようなより複雑な段階は、理想的にはコードを本番インフラストラクチャにデプロイしてそこでテストすることで行うべきです。これにより、コードは、最終的に実行されるインフラストラクチャ上で、同じ実行コンテキストで相互作用する実際のサービスに対してテストできます。

CI/CD パイプラインは、新しい変更への信頼を構築し、コードを本番環境にすばやくデプロイすることへの不安を軽減するのに役立ちます。フィーチャーフラグと組み合わせることで、開発チームはコードのいくつかの側面が検証済みであると信頼でき、より重いテストの実施方法を制御できます。

ダークローンチを許可するようにサービスを設定する

ダークローンチとは、ユーザーに影響を与えることなく、実際のトラフィックを使用してソフトウェアの変更をデプロイし、テストする方法です。その目的は、本番トラフィックをミラーリングし、新しくデプロイされたコードに重複するリクエストを送信することで、コードが正しく動作し、実際の運用負荷を処理できることを確認することです。

ダークローンチは、テストの正当性に影響を与えるような速度低下を招くことなく、アプリケーションの複数のインスタンスで既存のトラフィックをリプレイする必要があるため、非常に複雑になる可能性があります。リアルタイムでリクエストを複製する代替案は、イベントログやその他のソースから以前のリクエストを再生することです。この戦略では、最初のリクエストからすべての関連コンテキストをキャプチャする必要があります。

ダークローンチの利点は、コードがすでにユーザーにリリースされているかのように機能する様子を確認できることです。新しいコードを通じてトラフィックを実行した結果はユーザーには表示されませんが、コードがどのように動作し、どのような種類の条件を考慮する必要があるかについての洞察を提供できます。ダークローンチされたバージョンのアプリケーションをテストしたら、すでにそれらのプレッシャーに直面していることを考えると、本番環境でのパフォーマンスにかなり自信を持つことができます。

堅牢なモニタリングとメトリクス収集を実装する

デプロイおよびリリース中に実行されるコアテストに加えて、本番稼働後もその動作を継続的に監視できるシステムを導入することが重要です。新しいコードが動作の変更を引き起こした場合に異常をより迅速に発見できるように、サービスの健全性に関する長期的な洞察を得るために、さまざまな関連技術を実装できます。

モニタリングとメトリクス追跡は、サービスが時間とともに、また異なる条件下でどのように機能するかを理解するために使用できる基本的なツールです。新しい変更には、短期間では見つけにくい副作用があるかもしれませんが、時間とともに明らかになることがあります。モニタリングとメトリクスは、これらの行動の変化を特定のリリースと関連付けるのに役立ちます。