こんにちは。プロダクト開発部QAエンジニアの岡と申します。
弊社は「auブックパス （運営：KDDI株式会社）」と包括的なパートナーシップを結び、開発を行なっています。
こちらのサイトの監視に、Datadog Synthetics Tests（ブラウザーテスト）を導入して自動化したことについてお伝えします。
サイトの監視を自動化した結果、障害の検知と解決を迅速に行うことができるようになりました。
この記事で伝えたいこと
Datadog Synthetics Tests 導入理由
auブックパスは24時間365日営業しているため、ユーザーが本を購入できない、または読めないといった障害が発生することは許容できません。これまでサイトの監視を外部に委託していましたが、今後は障害の検知と解決を迅速に行うため、サイトの監視を内製化することにしました。また、内製化によるコスト削減も狙いのひとつです。システム構築コストも抑えるため、サイトの監視を簡単に実現できる有償ツールであるDatadog Synthetics Tests（ブラウザーテスト）を採用しました。
Datadog Synthetics Tests の概要
公式引用
Synthetic ブラウザテストを使用して、エンドツーエンドのテストで世界中の Web ページを顧客がどのように体験しているかを監視します。
Datadog Synthetics Testsには、公式サイトで紹介されている通り、ブラウザーテスト機能があります。レコーディング機能を使ってブラウザーの操作を記録し、ノーコードでブラウザーテストを作成できます。また、外形監視として障害の検知やサイトのレスポンスタイムの確認などを簡単に行うことができます。
ブラウザーテスト作成手順
まず、ブラウザーテスト作成手順について、「考慮したポイント」を交えて紹介します。
1. ブラウザーテストの作成開始
Datadogにアクセスし、ブラウザーテストを作成するためのダッシュボードに移動します。
Ux Monitoring > Synthetic Testsを選択し、画面右上の+New Testsをクリックして Browser Testをクリックします。
2. 設定
Set your test details
以下を設定します。
- Starting URL：テスト対象のURL
- Name：テスト名
- Envrionment：環境（任意）
- Additional Tags：タグ（任意）
- 分類に使用
- Advanced Options（任意）
- Cookie設定、Proxyの設定、Basic認証などの設定が可能
Browsers & Devices
実行クライアント環境は「Laptop Large」「Tablet」「Mobile Small」「Chrome」「Firefox」「Edge」の組み合わせが可能です。
Select locations
アクセス元の設定をします。
- 設定例：Tokyo (AWS)を選択
Define retry conditions
テスト失敗時の待機時間と再実行回数を設定します。
- 設定例：テスト失敗後10000ミリ秒待機し2回リトライ
Define scheduling and alert conditions
テスト実行間隔の設定をします。
- 設定例：テストを5分間隔で実行
- Advancedでは詳細な時間設定が可能
アラートの閾値の設定をします。
- 設定例：過去8分間に1か所でエラーが発生した場合、テストはアラートステータスになり通知が送信される
（ポイント） 実行コストとのバランスを考慮して、監視対象の重要度に応じて間隔を設定しました。参考：Datadog料金 （15ドル / 1,000テスト）
Configure the monitor for this test
障害検知時の通知方法を設定します。
通知方法としては、メール、Slack、PagerDuty、Webhookなど、豊富な選択肢があります。
※ここは通知作成方法で詳しく触れます。
設定が完了したらSave ＆ Edit Recordingをクリックしてレコーディングに進みます。
4. レコーディングの開始
レコーディング開始前にChrome拡張機能「Datadog test recorder」をインストールする必要があります。
レコーディング画面では、 ノーコードで簡単にブラウザーテストが作成できます。
Start Recordingでレコーディングを開始します。右側に表示されたブラウザーでの操作が、左側に記録されていきます。
（ポイント） テストの対象は、外部連携している箇所など障害が発生しやすい箇所に絞って監視しています。 監視対象が増えると誤検知が増え、不要なアラートが上がってしまい、テストの実行コストも増えてしまいます。
（ポイント） 障害の発生頻度が高い箇所を中心にしてテストシナリオのステップ数を最小限に抑えました。
テストシナリオのステップ数が多いと、本来検出したい障害ではない箇所でテストが失敗して原因の特定が困難になります。そのため、障害の発生頻度が高い箇所にアサーション（検証）を配置し、ステップ数を絞りました。
5. 自動記録された内容を確認して調整
以下を必要に応じて調整します。
- Step Name： シナリオのステップ名
- Target Element： 操作対象
- Click type： 操作対象のクリック方法
- Advanced Options > User Specified Locator： ユーザー指定のロケーターが使用可能
- 例えば、idやテキストを起点として要素を指定するためにXPathを使用するなど、柔軟な対応が可能
- Wait for 60s before declaring this step as failed： 検証実行前にwait（待機ステップ）を挿入
- Continue with test if this step fails： このステップが失敗したときにテストを続行するか選択
自動記録以外にも手動でアサーション（検証）ステップを追加できます。
（ポイント） テストステップ名を編集し、各ステップが何をテストしているのかを分かりやすくすることで、障害の発生箇所の特定が容易になります。
（ポイント） テストシナリオに分岐機能がないため、Continue with test if this step failsの設定を使用して分岐を実現しました。
例えば、特定の要素が表示された場合にのみアサーションを実施したい場合があります。シナリオステップのContinue with test if this step failsにチェックを入れることで、要素がある場合のみアサーションを実施するように設定することで分岐を実現しました。
（ポイント） 部分的にユーザー指定のロケーターを使用しました。
auブックパスのフロントエンドではReactを使用しています。Reactを使用する場合、デフォルトでは要素にIDが付与されないため、テキスト表示のない要素を特定したり、階層が変更された場合のテストメンテナンスが困難です。この課題に対処するため、開発者に対してテスト対象の要素にIDを付与するように依頼しました。付与されたIDを使用して、Advanced Options > User Specified Locatorでカスタムロケーターを指定しました。これにより、画面変更の際にもテストメンテナンスが容易になりました。
6. カスタムスクリプトの作成
✔︎Assertion > 下から2番目のTest custom JavaScript assertionを選択すると、JavaScriptの記述が可能になります。
クリックを繰り返す、サイト内に表示された値を変数に格納し後で検証に使用するなどの処理をJavaScriptで記述することにより、テストが拡張できます。
JavaScriptの記述以外にも、メールの受信テスト、DLファイルのテスト、サブテスト機能など機能が豊富です。
7. テストシナリオの実行
Run Test Nowで作成したシナリオを実行します。
テスト実行結果はダッシュボードで確認できます。結果をクリックして詳細を確認します。
- Faild（失敗）の場合は作成したテストシナリオに問題が無いか、内容を見直す
- 実行時の画面キャプチャーがあり、レスポンスタイムの確認が可能なため、テスト失敗の原因を特定できる
上記の場合、「モーダル画面が表示されてしまい要素のクリックができず、次の画面に遷移できなかった」がテスト失敗の原因です。そのためモーダル画面を閉じる処理を追加するとテストが成功します。
8. テストの修正
さきほど実行したテストが失敗しているので、「モーダル画面が表示された場合にクリック」というステップを追加します。
テストが成功したので、ブラウザーテストは完成です。
通知作成方法
つぎに、作成したブラウザーテストが障害を検知したときに通知する方法を紹介します。
電話通知設定と、Slack通知設定の2つを実施します。
電話通知設定
以前、弊社のテックブログ Amazon Connectを使った障害発生時の自動オンコール実現について でご紹介した方法を実施します。
使用する要素は以下の4つです。
- Datadog
- AWS SNS
- AWS Lambda
- Amazon Connect
1. 初期設定
電話番号を取得するための申請などを行います。 参照：初期設定について
2. 架電設定
参照：架電用のAmazon Connectの問い合わせフロー(SNS, Datadog設定, Lambda)について
3. Datadog側の設定
2の最後ではモニターに対して設定する例がありますが、シナリオに設定もできます。
今回は、シナリオテストの失敗(Faild)を検知して電話の着信で知らせるため、以下のように設定をします。
- ブラウザテストの設定 >
Configure the monitor for this test>Notify your team
4.調整
障害検知の条件を調整します。
Datadog Monitors機能とalert conditionsを設定し、リトライでテストが成功した場合は即時復旧したとみなし、障害とはみなさないように調整しました。
これにより、不要な電話通知を防ぎつつ、実際の障害を正確に検知できています。
Slack通知設定
1. Slack側の設定
2. Datadog側の設定
こちらも、シナリオテストの失敗（Faild）を検知してSlackに通知するため、以下のように設定をします。
- ブラウザテストの設定 >
Configure the monitor for this test>Notify your team
定期実行を開始
テストシナリオの「Resume Scheduling」で定期実行を開始します。 障害発生時にSlackと電話に通知されます。
運用手順
ブラウザーテストの作成と、障害の検知したときの通知方法の設定が完了したので、さいごに運用手順を紹介します。
1. 障害の発生
障害が発生すると、電話による通知があり、同時にSlackチャンネルにも通知が行われます。
2. 障害の特定
Slackのメッセージリンクからテスト失敗箇所へアクセスし、障害発生時のスクリーンショットやテストステップを確認できます。
テストシナリオ数とステップ数を厳選し、テストステップ名の編集により、各ステップが何をテストしているのかを分かりやすくすることにより、障害の発生箇所を迅速に特定できるようになりました。
3. 障害対応、復旧
障害の発生箇所が特定されたら、それに基づいて障害対応が行われます。 復旧した場合にも電話での通知とSlackへの通知が行われるように設定できます。（障害が発生している間もテストのスケジュール実行は継続されるため、復旧も即時検知されます）
4. 分析
電話通知やSlack通知により、障害発生から解消までの経過や復旧までの期間などをダッシュボードで確認できます。
これにより、障害の計測や原因分析が可能となり、障害の傾向やパフォーマンスの改善点を特定し、将来の問題を予防するための情報を得ることもできます。
さいごに
Datadog Synthetics Tests（ブラウザーテスト）を導入し、活用することで、障害の検知と解決を迅速に行うことができるようになりました。
弊社ではSynthetics Testに限らず、様々な方法でサイトの品質を担保しています。
お客様が快適にサイトをご利用いただけるよう、品質の向上を目指します。
