シンセティックモニタリング

シンセティックモニタリング（セマンティックモニタリングとも呼ばれる[1]）は、アプリケーションの自動テストのサブセットを、稼働中の本番システムに対して定期的に実行します。結果は監視サービスにプッシュされ、障害が発生した場合にアラートをトリガーします。この手法は、自動テストと監視を組み合わせることで、本番環境におけるビジネス要件の失敗を検出します。

小規模な独立したサービスと頻繁なデプロイメントの時代において、本番環境とまったく同じバージョンの組み合わせで本番前にテストすることは非常に困難です。この問題を軽減する1つの方法は、テスト可能性を本番前環境から本番環境に拡張することです。これが本番環境でのQAの背後にある考え方です。これを行うことで、平均故障間隔（MTBF）へのフォーカスから、平均復旧時間（MTTR）へのフォーカスへとマインドセットがシフトします。

ほとんどの種類のFについて、MTTR > MTBF

-- John Allspaw（ジョン・オールスポウ）

このための手法がシンセティックモニタリングです。私たちは、数十カ国に数百万件の広告を掲載しているデジタル自動車マーケットプレイスのクライアントでこの手法を使用しました。彼らは100近くのサービスを本番環境で運用しており、それぞれが1日に複数回デプロイされています。テストは、サービスが本番環境にデプロイされる前に、継続的デリバリーパイプラインで実行されます。統合テストの依存関係はテストダブルを使用せず、代わりに本番環境のコンポーネントに対してテストを実行します。

シンセティックモニタリングに適したテストの例を次に示します。ユーザーがお気に入りのリストに広告を追加する動作を模倣します。彼女が取る手順は次のとおりです。

ホームページにアクセスし、ログインして、お気に入りをすべて削除します（ある場合）。この時点で、お気に入りカウンターはゼロです。
いくつかのフィルタリング条件を選択して、検索を実行します。
星印をクリックして、結果から2つのエントリをお気に入りに追加します。星は灰色から黄色に変わります。
ホームページにアクセスします。この時点で、お気に入りカウンターは2である必要があります。

分析からテストリクエストを除外するために、URLにパラメータ（excluderequests=trueなど）を追加します。パラメータは、すべての下流サービスに推移的に渡され、それぞれが設定されている場合に分析とサードパーティスクリプトを抑制します trueに設定されます。

excluderequestsパラメータを使用して、バックエンドデータストアのデータを合成としてマークできます。私たちの場合、これは同じユーザーアカウントを再利用し、テストの開始時にその状態をクリーンアップするため、関連性がありません。欠点は、このテストを同時に実行できないことです。代わりに、テスト実行ごとに新しいユーザーアカウントを作成することもできます。テストユーザーを簡単に識別できるように、これらのアカウントのメールアドレスには特定のプレフィックスまたはポストフィックスが付きます。別のオプションは、すべての要求で送信されるカスタムHTTPヘッダーを使用してテストとして識別することですが、これはAPIの方が一般的です。

私たちのテストはSelenium webdriverで実行され、PhantomJSで5分ごとに本番環境のサービスに対して実行されます。テスト結果は監視システムに送られ、チームのダッシュボードに表示されます。テスト対象の機能の重要度によっては、障害が発生した場合にオンコール duty のアラートがトリガーされることもあります。

テストピラミッドの最上部にある広範なスタックテストは、シンセティックモニタリングに適しています。これらは、WebアプリケーションのUIテスト、ユーザー ジャーニー テスト、ユーザー受け入れテスト、またはエンドツーエンドテストです。または、APIのコンシューマー主導の契約テスト（CDC）です。一連のUIテストを実行する代わりに（たとえば、バッチ処理ジョブのコンテキストで）、システムに合成トランザクションを入力し、データベースエントリ、キューのメッセージ、またはディレクトリのファイルなど、必要な最終状態をアサートすることもできます。