お問い合わせ
資料請求

実際にWebサイトをWebシナリオ監視する(4/4)

はじめに

前回の記事前々回の記事でWebシナリオ監視とスクレイピングによるWeb監視を実装しました。これらはECサイト「あーるわーくす商店」の商品購入機能を監視する目的で作りました。

今回の記事では両者を比較、考察していきます。

検知した障害に関する情報の見え方

まず障害として、何らかの原因で「あーるわーくす商店」の商品一覧ページに商品が存在しなくなってしまった、という状態を実際に発生させました。アプリケーションの動作の問題でこの状態が発生しているとき、従来のWeb監視では検知できない場合があり、ECサイトの運営者やサーバ運用者が障害を認識するまでに時間がかかります。「あーるわーくす商店」は2つの方法で監視しているため、この状態を障害として検知できます。従ってこの状態が気づかれず放置されることはありません。

ここからは障害発生時にそれぞれの監視ではどのような情報が得られ、それらが復旧作業にどのように役に立つか確認していきます。障害検知時にそれぞれの監視で得られた情報を以下の表にまとめました。

得られる情報 スクレイピングによるWeb監視 Webシナリオ監視
障害状態であること
障害によって失敗した操作
障害検知時のスクリーンショット ×
各操作の所要時間 ×

上表において、〇は監視コンソールで確認できるもの、△は監視コンソールでは確認出来ないが、他の手段で確認できるもの、×は確認できないものです。

障害検知時に監視サーバからそれぞれの監視の状態を実際に確認すると両者とも障害状態となっており、商品が存在していない状態を障害として検知することができています。下図は監視コンソールでそれを確認したものです。なお、これは今回の記事のため特別に作成したものであり、Webシナリオ監視の実際の画面とは異なります。

また、両者とも障害によってどの操作が失敗したかという情報が得られます。スクレイピングによるWeb監視ではこれを確認するために何らかのファイルにログとして出力する必要がありますが、Webシナリオ監視では失敗した操作がどの操作であるかを監視コンソール上から確認できます。このように障害検知したのはどのような操作ができなかったためなのか、ということが分かるため、障害箇所の特定や原因の切り分けに役に立ちます。今回の障害では商品一覧ページにディナーフォークが存在していることを確認する、という操作が出来なかったため障害検知したことが分かりました。

スクレイピングによるWeb監視で障害検知時に得られる情報はここまでですが、Webシナリオ監視ではこれらに加えて、障害検知時のスクリーンショットが得られます。スクリーンショットが得られることで、障害検知時にブラウザから見るとWebサイトがどのような状態であるかを確認することができるので、障害原因の容易な切り分けが可能です。今回の例では、以下のスクリーンショットを取得することができました。

これを見ると、商品一覧ページに商品が存在せず空の状態になっていることが分かります。このことから、商品情報を取得する部分の処理に原因であるのではないか、もしくは何らかの原因で商品データベースから商品が削除されてしまったのではないか、と推察することができて原因特定が早くなることが期待できます。

また、Webシナリオ監視では下図のように各操作の所要時間も得られます。それぞれのユーザ操作に対する応答がどれだけかかっているかが分かるので、特定動作に対する応答が遅くなっていた場合の原因切り分けの際に役に立ちます。

ここまで確認してきたように、Webシナリオ監視はスクレイピングによるWeb監視と比べて障害検知時に得られる情報が多いので、障害原因の切り分けが容易であり障害検知から復旧までの時間短縮が期待できます。

導入やメンテナンスにかかるコスト

監視対象のWebサイトが多い場合やメンテナンスが頻繁にあるWebサイトの監視をする場合、監視の導入やそのメンテナンスにかかるコストは出来る限り少ない方が望ましいと考えます。そこで、導入やメンテナンスにかかるコスト、という点で両者を比較します。

スクレイピングによるWeb監視は導入の際は前々回の記事で実装したように、まずHTMLの構造解析が必要であり、さらにフォームパラメータの解析が必要でした。例えば今回のECサイトの監視では、HTMLの要素を指定するために id や class を調べる必要がありました。また、テキストエリアやセレクトボックスで指定する値やフォームの隠れた要素として記述されていたランダム値がパラメータとして必要であり、この解析も必要でした。さらに今後「あーるわーくす商店」がメンテナンスや機能変更により構造やフォームの動作が変わった場合、その度に同様の解析が必要であり、時間と労力がかかってしまいます。このようにスクレイピングによるWeb監視の導入や調整にはある程度のまとまった時間や労力が必要です。

一方でWebシナリオ監視では、Firefox と SeleniumIDE を使ってユーザの操作を記録する方法で処理内容を作ることができるので、HTMLの構造解析は必要ありません。さらにフォームのパラメータはユーザの操作に応じてブラウザが生成してくれるので、これも解析する必要がありません。これはメンテナンスや機能変更の際も同様です。よって、スクレイピングによるWeb監視と比べて時間と労力がかからず、対象のWebサイトが多い場合やメンテナンスが多い場合の監視調整が容易であると言えます。

このように、Webシナリオ監視はスクレイピングによるWeb監視と比べて、低いコストで導入やメンテナンスができます。

監視内容の見やすさ

監視内容についてメンバや顧客と情報共有をする際に、作成物の読みやすさや理解のしやすさは重要です。そこで、スクレイピングによるWeb監視で用いたスクリプトとWebシナリオ監視で用いたステップセットを読みやすさという点で比較します。例として商品をカートに入れる処理を挙げ、スクリプトとステップセットを比較していきます。以下はスクレイピングによるWeb監視のスクリプトにおいて、ディナーフォークをカートに入れる処理を記述したものです。

$tree->parse($mech->content);
my $token = $tree->look_down('id', '_token')->attr('value');
$mech->submit_form(
    form_number => 2,
        fields => {
            classcategory_id1 => 3,
            classcategory_id2 => 6,
            quantity => 1,
            mode => 'add_cart',
            product_id => 1,
            product_class_id => 1,
            _token => $token,
        },
    );
);
&on_stepend($summary, $mech->uri, $mech->success());

このコードはユーザがディナーフォークの色や大きさを選択してショッピングカートに入れる処理に対応します。この処理では多くのパラメータを送信する必要があるため、コードが長く読みづらいものとなっています。プログラミング言語の読み書きに慣れている人であればある程度読めると考えられますが、そうでない人にとっては一見して処理とコードが対応しているか分かりません。このため、監視内容の情報共有に時間がかかってしまったり、スクリプトの処理内容を理解しているメンバが偏ったりする場合があります。

一方で、以下はWebシナリオ監視において、同様の処理を記述したものです。

コマンドは3行のみであり、スクレイピングによるWeb監視のスクリプトと比べてステップセットは簡潔な内容です。また内容を見ると、1行目は id が classcategory_id1 である要素を label が プラチナ になるように 選択する、と読むことができます。2行目も同様に id が classcategory_id2 である要素を label が 150cm になるように 選択する、と読むことができます。3行目は id が add-cart の要素をクリックして、ページ遷移が完了するまで待つ、と読むことができます。このように、ステップセットはユーザの操作により近い形で記述されているので、前提知識が無い人にとっても読みやすいと言えます。このためステップセットを作成者以外の人への情報共有が容易であり、監視に対して認識の相違が無くなることが期待できます。

必要な前提知識

監視設定や導入のために必要な知識が多い場合、時間と労力がかかります。そこで「必要な前提知識」という観点で比較をします。今回実装したそれぞれの監視では以下の前提知識が必要でした。

利用場面 スクレイピングによるWeb監視 Webシナリオ監視
監視内容を作成するとき プログラミング言語(Perl)の読み書き
WWW::Mechanize の利用方法
HTML::TreeBuilder の利用方法
HTTP::Cookies の利用方法
Cookieに関する知識
HTMLの知識
CSSの知識
Javascriptの知識
Xpathの知識
監視サーバ(Pandora FMS)の知識
ブラウザ(Firefox)の操作方法
SeleniumIDEの操作方法
監視サーバ(Pandora FMS)の知識
監視結果の読み取り 作成したスクリプトの読み方
HTMLの知識
CSSの知識
Xpathの知識
監視サーバ(Pandora FMS)の知識
ステップセットの読み方
HTMLの知識
CSSの知識
Xpathの知識
監視サーバ(Pandora FMS)の知識

今回実装したスクレイピングによるWeb監視では監視内容を作成する際に、ユーザによる機能の操作を再現するためプログラミング言語(今回の場合はPerl)の知識と関連ライブラリ(WWW::Mechanize)の知識が必要でした。また、Webページを構造解析するためにHTMLやCSS、Javascript、Xpathと関連ライブラリ(HTML::TreeBuilder)の知識も必要でした。さらに、機能によってはCookieの生成が必要な場合があり、これを生成するために関連ライブラリ(HTTP::Cookies)の知識が必要でした。このようにプログラミングやWebアプリケーションについての知識など多くの前提知識が必要であるため、スクレイピングによるWeb監視導入のハードルはある程度高いと考えられます。また、監視結果を読み取る際には、どの処理が失敗したため障害検知したかを知る必要があるので、復旧作業を行うにはスクリプトを読めることが必要です。以下の記述は、ディナーフォークが存在しない状態を意図通りに障害として判定した処理のソースコードを抜粋したものです。

$tree->parse($mech->content);
my $tag = $tree->look_down('id', 'result_list__item--1')->look_down('id', 'result_list__detail--1')->look_down('id', 'result_list__name--1');
$next_link = $tag->{_parent}->{_parent}->attr('href');
&on_stepend($summary, $mech->uri, $tag->as_text eq 'ディナーフォーク');

この処理を理解するためにはスクリプトの読み方やHTML、CSS、Xpathを知っている必要があります。これらの知識が無い場合、上記の処理が何をしている処理なのかを判断することができないため、障害原因の切り分けが困難です。

一方でWebシナリオ監視では機能の操作やHTMLの構造解析、Cookieの生成は全てブラウザ(Firefox)とSeleniumIDEが行ってくれるため、ブラウザ(Firefox)とSeleniumIDEの使い方をを知っていれば監視内容を作成できます。なお、SeleniumIDEではいくつかコマンドを覚える必要がありますが、基本的にブラウザの操作を記録するだけである程度ステップセットの作成が可能であり、さらに必要なコマンドの数は少ないため習得が容易だと言えます。また、監視結果を読み取る際にはステップセットについて理解する必要があります。例としてシナリオ監視のために作成したステップセットを見ていきます。以下の図は、上述のソースコードに相当するWebシナリオ監視のステップの実行結果です。

id が result_list__name–1 である要素に assertText コマンド(指定箇所に指定文字列があることをチェックするコマンド) でディナーフォークという文字列が存在していることをチェックして、その結果失敗しています。これを読み取るにはステップセットの読み方やHTML、CSS、Xpathを知っている必要がありますが、直感的に読める内容となっているのでこれらの知識が無くても読み取れると考えられます。また、前述のようにステップセットは覚えるべきコマンドの数は少ないので、スクリプトの知識と比べて習得が容易です。

このように、Webシナリオ監視はスクレイピングによる監視と比べて少ない知識で利用することができます。

まとめとおわりに

これまでの記事で、ECサイト あーるわーくす商店 を作成し、これにスクレイピングによるWeb監視とWebシナリオ監視を導入しました。これらによってWebサイトの機能の動作やページ遷移が正常に行えるかなどを監視できます。今回の記事では あーるわーくす商店 に障害を発生させて、両者を比較、考察しました。

スクレイピングによるWeb監視では、障害検知時に得られる情報が少なく原因の切り分けが困難です。また、メンテナンスや導入に多くのコストがかかります。対してWebシナリオ監視は、比較的少ない前提知識で手軽に導入ができ、障害検知時に障害箇所や原因の切り分けが容易です。これらのことから、ログイン処理や商品購入などの機能が多いWebサイトの監視やページ遷移の監視をしたい場合や、メンテナンスが頻繁に発生するWebサイトの監視をしたい場合にWebシナリオ監視は適していると言えます。

Rworks の Webシナリオ監視サービスの料金や導入フローにつきましては、
Webシナリオ監視サービス紹介ページに記載しています。どうぞお気軽にお問い合わせください。

ご相談・お問い合わせはこちらから

サービスについてのご相談、資料のご請求など、お気軽にお問い合わせください。

03-5946-8400 平日 10:00 - 18:00
page top