Webサイトの「リンク切れ」、どうやって発見する？ CloudWatch Syntheticsのリンク切れチェッカーを試してみた【AWSシリーズ】
みなさんこんにちは。あっきーです。
今回の投稿は、少し"技術寄り"のテーマでお送りできればと思います。
はじめに
リンク切れチェックの悩み
Webサイトを運営されている方だと、「リンク切れ」に1度は悩んだことがあるのではないでしょうか。
まだページの数が少なかったり、各ページの管理がうまくいっている頃だと把握できるのですが、どんどんページ数が増え、サイトオーナーも入れ替わっていき、各Webサイトのつながりが複雑になればなるほど発生してしまうものだったりします。
サイト利用者としても、「リンク切れ」に遭遇すると、少しテンションが下がるかと思います。
そういった、サイト内の「リンク切れ」をチェックしてくれるツールは世の中にありますが、今回はAWSにある「リンク切れチェッカー」に着目してみたいと思います。
CloudWatch Syntheticsとは
AWSで様々な「監視」ができるサービスとして「CloudWatch」がよく知られています。
その中の機能で、WebページやAPIエンドポイントに対する定常監視を行う「Synthetics」というものがあります。
この「Synthetics」では、「Canary」と呼ばれるリソースを用意し、その「Canary」内で定義した様々なチェックを自動実行して結果を得ることができるというサービスが提供されています。
チェックとしては、ユーザーからの動作をシミュレートし、正しく実行ができるかどうかを見てくれています。
(例. 「ブラウザから、Webページ『hogehoge』のURLにアクセス」をシミュレートする)
また、チェック項目としては、2022年10月時点で下記が提供されています。
・ハートビートモニター
・API Canary
・リンク切れチェッカー
・ビジュアルモニタリング
・Canary Recorder
・GUI ワークフロー
というわけで、今回はこの中の「リンク切れチェッカー」に着目し、実際にCloudWatch Syntheticsをさわってみました。
試してみた
今回の題材として、とあるWebサイトのリンク切れをチェックしてみることにしました。
※すぐに、使ってみた結論を知りたい方はこちらからどうぞ。
設定
AWSのコンソール画面では、まずCloudWatchの画面に入ります。
左メニューから、「Synthetics Canaries」のメニューに入り、「Canaryを作成」から設定を始めていきます。
Canaryの作成では、設計図が準備されているので、それを活用します。
今回は、「リンク切れチェッカー」の設計図を選択します。
Canary ビルダーの項目で、必要事項を記入していきます。
名前
Canaryリソースの名前です。管理しやすければなんでもOKです。テストするアプリケーションまたはエンドポイント URL
リンク切れチェックの対象サイトURLを入力します。フォローされるリンクの最大数
リンク切れチェックを行う数の指定です。上で指定したURLのページを1つ目とし、下の階層の何個目のページまでを見るかを記入します。
対象サイトの構成によって異なるかもしれませんが、子リンクすべて→孫リンクすべての順でチェックを行っていくようです。スクリーンショットを撮る
有効にすると、結果画面で、ページのどの部分のリンクが切れているか、視覚的に見ることができます。そのためのページのスクリーンショットを取得するかの項目です。
スクリプトエディタの画面では、これまで設定した内容がスクリプトとして記載されています。
ここを活用すれば細かい制御も可能にはなるようですが、今回は特に変更せずに進みます。
スケジュールでは、このCanaryを実施するタイミングを設定します。主に継続的・計画的なリンク切れチェック監視の場合で活用しますが、今回はお試しなので、「1回実行」とします。そのため、追加設定も特になしとします。
データの保持については、Canaryデータの保持期間を設定します。
1か月・3か月・6か月・12か月・カスタムの選択肢があるので、結果の保存に必要な期間を選びます。
データストレージでは、Canary実行結果を保存するS3バケットを指定します。デフォルトだと「s3://cw-syn-results-」から始まるバケットが作成されますが、既存のバケットを指定することも可能です。
アクセス許可では、このCanaryの実行権限を指定します。今回はデフォルトの「新しいロールを作成」から進みます。
オプションですが、アラームも設定してみます。
ここで設定したものが、自動的にCloudWatch アラーム(EventBridge)に登録されます。継続的・定期的・単発など、リンク切れの監視体系にもよると思いますが、それに合わせてメトリクスを設定します。
アラームは、SNSトピック経由でメール通知されるように、この画面からでも設定できます。
新しいトピックの作成から、トピック名および通知先メールアドレスを記入し、直下の「トピックの作成」ボタンを押すことで作成されます（この部分忘れがち注意！）。
この際、入力したメールアドレスに、AWSから確認メールが届くので、「Confirm subscription」をクリックして有効化しておきます。
もしメール以外を選ぶ場合は事前にSNSトピックを作っておくことをお勧めいたします。
今回、その他のオプション設定はデフォルトのままにします。
最後に、「Canary を作成」ボタンを押すことで、設定が完了します。あわせて、「1回実行」を今回選択したため、自動的にチェックが走ります。
これについては少々時間がかかります。
結果
Canary作成がうまくいくと、下のような画面となります。
ここで現在スキャンを実施してくれていますので、しばし待ちます。
しばらくするとスキャン結果が出ました。
今回は失敗しているようですので、どこかで「リンク切れ」が起きていたようです。
Canaryにある、「test-canary」をクリックして、詳細を見ていきます。
見てみると、10リンクのチェック中、2か所でリンク切れが検知されていました。
失敗したリンク先、その理由もここからみることができます。
また、今回は「スクリーンショットを撮る」機能を有効にしたため、黄色い枠の「スクリーンショット」にある1や2の数字をクリックすると、実際のページのどこがリンク切れしているのか、実際のページと同じような視覚で見ることができます。
もう少し下には、それらの結果が格納されたS3バケット情報も記載されています。
「アーティファクトをダウンロード」ボタンから、S3に格納された結果データ（Canaryアーティファクト）を落とすことができます。
落としてきたファイルの中身を見てみると、下記のような形でした。
中身には以下の5種類のファイルが入っていました。
スクリーンショットの画像
上記コンソール画面結果でも説明した、「スクリーンショットを撮る」機能でとられたスクリーンショットのPNGファイルで、こちらからでも確認できます。ここでわかる通り、この機能を有効にした場合は、S3の利用料金が多少増えるかと思います。実行ログ
今回のチェックの実施ログです。何か不具合があった場合はこれを確認します。BrokenLinkCheckerReport.json
リンク切れチェックの結果が書かれたJSONです。「どのリンクがどういった理由で失敗した」という情報が書いてあるので、これを解析するのもいいかと思います。results.har.html
ブラウザのデベロッパーツールで見るようなHARファイルも、HTML形式で出てきます。パフォーマンスなんかはこちらを参照してもいいかもです。SyntheticsReport-FAILED.json
Canaryを実行したこと自体（実施記録や設定内容など）の記録のJSONファイルです。
これらで一通り実行結果が確認できました。
料金
こちらご参照ください。
公開時点だと、Canaryの実行1回当たりの料金となっていますが、関連して動いているLambda, S3の格納料金なども追加でかかってきます。
感想・要望
試してみて思ったこととして、まずは「気軽に定期チェックできそう」という点です。
また、上記のように視覚的に結果がわかり、分析もしやすい形式でアウトプットできるので、その点も優秀だと思いました。
一方で、下記のような問題点もありました。
実際にはリンク切れしていない部分もエラー検知してしまうことがある（誤検知）
実際の画面上だとリンク切れしていないリンクが、なぜか誤検知されてしまう場面に遭遇しました。原因がわからなかったので、AWSサポートに問い合わせましたが、「『前段のエラー検知処理におけるDNS名前解決失敗』に引っ張られてのエラーで、サイト側に問題がある」という結論でした（実際おっしゃる通りでした）。
今回は「Webサイトのリンク切れチェック」にフォーカスしたかったのもあり、テンプレートでコードを書けばおそらくできるかなとは思ったのですが、可能であれば「特定のリンクは検知対象としない（除外）設定」が簡単にできたらいいなと感じました。
アラートの内容がパッとわかりづらい
こちらはしょうがない部分ではあるのですが、Canaryで検知して飛ばすアラート内容が、下記画像のように、「リンク切れ検知しました！」という内容だけなのが少々気になりました。
もちろん、CloudWatch アラーム(EventBridge)とSNSの仕様なので、しょうがない部分ではありますが、作りこまずも具体的な検知内容を文章に入れられるとわかりやすいかなと感じました。
現状感じた点としては以上となります。
そういった理由から、現状簡単に使えるユースケースとして、私は主に3つ思いついております。
リリースしたばかりで、「リンク切れがない」前提のサイトの監視
現時点でリンク切れがないサイトの監視は現状の仕様でも有効かと思われます。
そのサイトにおいて、「基本リンク切れがないこと（= チェック成功100%）」をベースラインとし、「チェック失敗（= チェック成功100%未満）」があったらアラートを上げる形です。
特定のリンク（群）の監視
上記のものに似ていますが、より範囲を狭めた形での監視になります。
可能な限りリンク切れを起こしたくないようなところを対象としておく形です。ただ、「URL外形監視」に近い気もするので、そちらで行ってもいいかもしれません。
小規模なサイトのリンク切れチェック
こちらは監視ではなく、チェックツールとして活用するイメージです。小規模なサイトであれば、多少の誤検知とかがあったとしても、簡単かつ安くチェックを実施できるかなと感じました。
ただ、「対象サイトの規模」や「その他のリンク切れチェックツールとの差別化」という点では何とも言えないかもしれません。
他にもユースケースはあるのかもしれませんが、まずはこういったところから試してもいいのではと感じております。
おわりに
いかがだったでしょうか。
検索してみて意外と情報が少なかったところでしたので、発信してみようと思いました。
私自身もまだ「試してみた」程度ではありますので、今後も本機能の情報を追いかけていきたいと思います。
そして、より使いやすいサービスになってくれるとありがたいなと感じております。
それではまた！