ここGranifyでは 、膨大な量のユーザー生成データを処理しますが、私たちのビジネスはそれに基づいています。 データが正しく収集および処理されることを確認する必要があります。
ユーザーから送られてくるデータがどれほど奇妙であるか想像することさえできません。 ソースには、プロキシサーバー、聞いたことがないブラウザー、クライアント側のエラーなどがあります。
テストやフィクスチャがいくつあっても、すべてのケースをカバーすることはできません。 本番からのトラフィックは常に予想とは異なります。
さらに、すべてのテストに合格した場合でも、バージョンを更新するときにすべてを単純に壊すことができます。 私の練習では、これは常に起こります。
自動および手動のテストでは見つけるのが非常に難しいエラーのクラスがあります。同時実行性、サーバーの構成エラー、コマンドが特定の順序でのみ呼び出されたときに発生するエラーなどです。
ただし、このようなバグの検索を簡素化し、システムの安定性を向上させるために、いくつかのことができます。
常にステージングでテストします
ステージング環境が必要であり、本番環境と同一である必要があります。 PuppetやChefなどのツールを使用すると、タスクが大幅に簡素化されます。
開発者は、ステージング時にコードを常に手動でテストする必要があります。 これは最も明白なエラーを見つけるのに役立ちますが、実稼働トラフィックで発生する可能性からはまだ非常に遠いです。
実データのテスト
実際のデータでコードをテストできるようにする方法はいくつかあります（両方を使用することをお勧めします）。
1.本番サーバーの1つのみを更新します。そのため、ユーザーの一部は新しいコードで処理されます。 この手法にはいくつかの欠点があります。一部のユーザーにはエラーが表示される可能性があり、 スティッキーセッションを使用する必要がある場合があります。 これは、A / Bテストによく似ています。
2.本番トラフィックの複製（ログの再生）
Ilya Grigorikは、ログ再生技術を使用した負荷テストに関する素晴らしい記事を書きました。
このトピックで私が読んだすべての記事では、実際のデータを使用した負荷テストの手段としてログの再生について言及しています。 毎日のテストとバグの発見にこの手法を使用する方法を示したいと思います。
jMeter、httperf、またはTsungのようなプログラムはログ再生をサポートしていますが、実際のユーザーをエミュレートするのではなく、初期段階にあるか、ストレステストに焦点を当てています。 違いを感じますか？ 実際のユーザーは、一連のリクエストだけでなく、リクエスト間の正しい順序と時間、さまざまなHTTPヘッダーなどが非常に重要です。 負荷テストでは、これは重要ではない場合がありますが、バグを見つけるために重要です。 さらに、これらのツールは構成と自動化が困難です。
開発者はとても怠け者です。 開発者に何らかのプログラム/サービスを使用させたい場合は、可能な限り自動化する必要があり、誰も気付かないように機能する場合はさらに良いはずです。
生産トラフィックを自動モードで再現します
簡単なGorプログラムを書きました
Gor-最小限のコストで、1日24時間、実稼働の実稼働トラフィックをリアルタイムで自動的に再現できます。 したがって、ステージング環境は常に実際のトラフィックの一部を受け取ります。
Gorは、リスナーと再生サーバーの2つの部分で構成されています。 リスナーは実稼働Webサーバーにインストールされ、すべてのトラフィックを別のマシンのReplayサーバーに複製します。これにより、既に目的のアドレスにリダイレクトされます。 動作の原理を次の図に示します。
Gorは、リクエスト数の制限をサポートしています。 これは非常に重要な設定です。ステージングでは運用環境よりも少ないマシンが適切に使用され、ステージング環境が耐えられる1秒あたりの最大リクエスト数を設定できます。
詳細なドキュメントはプロジェクトページにあります 。
GorはGoで記述されているため、起動には、コンパイル済みのディストリビューションディストリビューションを使用するだけです。
Granifyでは、Gorを本番環境でしばらく使用しており、結果に非常に満足しています。
いいテストをしてください！