はじめまして。事業開発部の中條です。
私の主な業務の一つで、企業様向けのネットワーク環境構築+運用サポートがあり、
複数の拠点間をつなぐWANや、各拠点内のLAN/無線環境の提供、IaaSとの接続などなど、
企業内ネットワーク全般を担当しているのですが、
完成後の環境を運用していると、ユーザーから以下のような問い合わせを受けることがあります。
・△△拠点との接続が時々切れる。どうすれば安定する？
・〇〇システムの動作が重いことがあるんだけど、ネットワークの調子が悪いのでは？
・特定のPCだけ業務システムへのアクセスに時間がかかる。ネットワーク環境に問題がある可能性は？
ユーザ目線でのシステムの快適性(≒ユーザーエクスペリエンス)は、
個人の感覚で決められるため、システム目線で評価するのはなかなか難しい部分です。
そんなときに役に立つのがThousandEyes。
この名前の持つ意味については今後連載を読んで頂ければわかるかもしれません。
基本機能については多くのWebページで紹介されているかと思いますので、
今回は少しだけ尖った機能である「トランザクションテスト」について触れてみます。
ThousandEyesにおけるトランザクションテストとは、ざっくり言うと
ユーザーが日常行う一連のアクションをソフトウェアで実行し、完了までの時間を計測するもの。
これを定期的に自動実行することによって、ユーザーと同等の目線でシステムの快適性を監視することが出来ます。
※ThousandEyesはあくまでネットワークに重点を置いたプロダクトであるため、
業務アプリの動作やサーバー負荷が原因の問題を特定するためには別の製品が必要となる可能性があります。
例えば、エンドユーザーである社員から以下のような問い合わせがあったとします。
【エンドユーザの声】
最近、仮想デスクトップにログインするのにやたら時間がかかってストレス溜まるんだよね。
特に朝が酷い。
なんとかならない？
実際にユーザーが行っている操作イメージは以下の通りです。
ユーザーの指摘内容から、上記⑤のログイン完了までに非常に時間がかかる時間帯がある、
ということのようです。
この問題の原因を特定し解決するには被疑箇所を絞り込んでいく必要がありますが、
詳細調査の前に知っておきたいことが何点かあります。
①影響範囲：他のユーザーも同様の影響を受けているか？
→別の端末からでも同様の状況であれば、影響範囲が大きいことが想定され早急な対策が必要。
逆に、他のユーザーが同様の経験をしていないのであれば
個人の端末周辺の問題である可能性が高く、最小限の対応で済むかもしれない。
②深刻度：指摘のあった時間帯と通常時で、ログイン時間にどの程度の差があるのか
→何倍もかかっているようであれば、他のユーザーも同様のストレスを抱えている可能性が高い
120%程度であれば、指摘してくれた人以外は気にしてないかも...(温度感が下げられる)など
ここがUXの難しいところで、人によっては20%の時間も許容できない、といったこともあるかもしれない。
③発生時間帯の特定
→時間帯が絞り込めれば、その時間帯で実行されているタスク/処理など、
思い当たる原因にぶつかり、迅速な対応が出来るかもしれない。
これらの確認には、ThousandEyesのトランザクションテストが役立つかもしれません。
＊かもしれないって何回言ったでしょう
いきなりですが、トランザクションテストの実行結果から見てみます。
以下は、ユーザーと同じ拠点に設置されたThousandEyesエージェントで実行するトランザクションテストの結果です。
テストの内容としては、エージェントのインストールされた端末から、
前述のログイン手順と同様のステップで仮想デスクトップにログイン完了するまで
(※正確にはWebブラウザの画面遷移が完了するまで)
の時間を5分おきに計測し、その結果をグラフで表示しています。
グラフを見ると、一部通常時の2倍程度時間がかかっている部分があります。
平均9秒前後で完了していたテストが、9:00～9:50のテストでは18秒ほどかかっていたようです。
その他の時間帯ではログイン時間の大きな変化は見られません。
また、過去のデータも確認したところ、以下の事実が判明しました。
※ThousandEyesでは、過去2週間分のテスト結果を保持しています。
・発生時間帯は平日の9:00～10:00頃までの間に限られる
・出社人数が少ない土日は、ログイン時間に変化なし
・同様の事象が発生したのは7日間前から。それ以前は平日であってもログイン時間に変化なし。
このような結果であれば、以下のような状況と推測できます。
①影響範囲
ThousandEyesエージェントからのアクセスでも同様の事象が確認できるので、
特定のユーザor端末に限られた問題ではない。
他のユーザーにも同様の影響が出ていると考えられる
※特定拠点に限定された問題かどうかは、ThousandEyesエージェントを複数拠点に配置し、
同様のテストを実行すれば判明する。
②深刻度
事象発生時は通常の2倍程度ログインに時間がかかる模様。
7日前から突然発生しているため、他のユーザから同様の指摘が来るのも時間の問題。
早急な報告と対処が必要。
③発生時間帯の特定
確認した範囲では、9:00～10:00に絞られました。
当該時間帯で何か処理が行われていないか確認します。
ここからは、確認できた状況を各所へ共有しつつ、原因を探っていきます。
ThousandEyesでは、対象端末から任意のシステムまでの経路情報をLAN、WAN含め洗い出し、
特定の時間帯にネットワーク的な不具合があったかどうか確認する機能が備えられています。
(というかそちらが本来のメイン機能です)
ネットワークの被疑箇所を特定する方法については、今後の連載の中で書いていく予定です。
さて、トランザクションテストでどのような結果が得られるかわかったところで、
(え、、分かりました？実はもっと細かい情報まで掘り下げられたりします。詳しく知りたい方はお気軽にお問い合わせ下さい。)
トランザクションテストの作成方法について、ざっくり紹介します。
テストの設定はとても簡単です。
専門的な知識が少ない方でも構えなくて大丈夫です。
ThousnadEyesの左ペイン、「Cloud & Enterprise Agents」から「Test Settings」を展開。
「Add New Test」をクリックし新しいテストを作成します。
テストの名前や、実行間隔(デフォルト5分)、テストを実行するエージェントを選択(詳細は今回は割愛)します。
そして設定のメインとなるのがキャプチャ下部の「Transaction Script」です。
検証したい一連の動作(トランザクション)をスクリプト形式で記述していきます。
このスクリプトを見た瞬間に拒否反応を示したのは私だけではないでしょう。
安心して下さい。
いいものあります。
画面下部の"ThousandEyes Recoder"をクリックすると魔法のソフトがダウンロードできます。
インストールは数クリックで終わります。
インストールしたThousandEyes Recoderを起動すると以下のコンソールが表示されます。
●ボタンを押しましょう。
Enter Base URLに、テストの起点となるサイトのURLを記述します。
※今回であれば仮想デスクトップのログインページのURLです。
入力出来たら「Start Recording」をクリックです。
すると、自動的にWebブラウザが起動し上記Base URLに接続されます。
あとはテスト化したい一連の動作をブラウザ上で実行していくだけです。
一連の操作が実行できたら、Recorderに戻って停止ボタンを押します。
すると、Recording中にブラウザで実行された操作がスクリプトとして記述されます。
後はこれをコピぺして先程のTransaction Scriptに貼り付けるだけ！
貼り付けたら「Save Changes」で保存。
これで基本的なトランザクションテストの完成です！
以降は指定間隔ごとに自動的にテストが実行されます。
これ以上は長くなってしまうので今回はここまでにしますが、
エンタープライズ向けのネットワーク運用などされている方には特にThousandEyes、おすすめです。
今まで評価が難しかったユーザエクスペリエンスの可視化にも使えますし、
今回紹介しきれていませんが、ネットワークが不調な時の原因特定に大いに役立ちます。
今後の連載で詳しく書きますね。
お疲れ様でした！
▼あとがき
なお、今回の仮想デスクトップの事象については、結論を言うと原因はネットワーク起因ではなく、
1週間前に実施したシステム設定変更の影響でした。
仮想デスクトップ上のGoogleChromeのアップデートが朝9:00以降で実行されるよう、
お客様側で設定変更をしていたようです。
※社員の始業時刻が8:00のため、ログインストームが落ち着いてからアップデートされるようにしたようです。
これまで各々の出社のタイミングで分散実行されていたChromeのアップデートが、
一斉に9:00から実行されるようになってしまい、
結果的に仮想デスクトップが稼働する仮想環境全体に負荷を掛けていたようです。
GoogleChromeの自動アップデート機能をオフにすることで事象の再発は無くなりました。
トランザクションテストによって得られた、
・いつから発生？
・発生時間帯
の情報から原因特定に至りました。
