『監視は正常、しかし利用者側では起きている「シャドー障害」に気づいていますか？』というテーマのウェビナーを開催
マジセミ株式会社は「監視は正常、しかし利用者側では起きている「シャドー障害」に気づいていますか？」というテーマのウェビナーを開催します。
■ 監視対象と利用者の間には、監視できていない区間がある
本セミナーでは、監視システムには現れないが利用者側では実際に起きている障害を「シャドー障害」と呼びます。
サーバー、クラウド、アプリケーションの監視は多くの企業で整備されています。
しかし、それらの監視が見ているのは、データセンターやクラウドの内側です。
利用者は、スマートフォンからモバイル回線を経由し、DNS、CDN、TLSハンドシェイクを通ってサービスに到達します。
この区間で起きる遅延や接続失敗は、サーバー側の監視には現れません。
モバイル回線の品質は、地域、通信キャリア、時間帯によって変化します。
弊社の実測では、同一サイトでもキャリアによって表示完了時間に30秒以上の差が生じた例があります。
サーバーが正常でも、利用者は「遅い」「つながらない」と感じている状態、すなわちシャドー障害が日常的に起きています。
■ 監視はすべて正常、しかし問い合わせとSNS投稿は増えている
「監視ダッシュボードは全て緑だったが、カスタマーサポートに問い合わせが集まり、SNSで障害が指摘されていた」という経験を持つ運用担当者は少なくありません。
この状態では、障害の発生を利用者から教えられることになり、対応は常に後手に回ります。
どの地域、どのキャリアで、いつから起きているのかが分からないため、CDN、DNS、通信事業者への確認も手当たり次第になります。
自社に原因があるのか、通信事業者側の問題なのかを判断できないまま、サーバー増強などの見当違いの対策に時間を使うこともあります。
RUM（Real User Monitoring）を導入していても、利用者がサービスに到達できなければ記録が残らないため、「つながらない」の検知には向きません。
事業側からは「なぜ監視していて気づけなかったのか」と問われ、説明に苦慮します。
シャドー障害が続く間、把握できないまま積み上がる離脱や問い合わせは、いわば「シャドー機会損失」です。
1時間あたりの取引数に、遅延時の離脱率と、利用者から指摘されるまでの時間を掛けると、1回のシャドー障害で失っている売上の規模が見えてきます。
利用者側の環境から、平常時から継続的に計測する仕組みがなければ、この損失は計測されず、対策の予算も付きません。
■ 国内7都市・4キャリアの実回線から、利用者視点で監視し、発生箇所を切り分ける
本セミナーでは、データセンター側の監視でシャドー障害を捉えられない理由を、通信経路とモバイル回線が変動する仕組みから解説します。
RUMや、クラウド上の合成監視では捉えられない範囲を整理し、何が不足しているのかを明確にします。
解決の鍵は、利用者に近い場所から、定期的に実アクセスして計測する合成監視です。
国内7都市の物理拠点から、4キャリアの実SIM・実回線で計測し、地域・キャリアごとの品質を平常時から可視化することで、異常を利用者より先に捉える方法を紹介します。
BGP、DNS、TCP/TLS、CDN、HTTPS、ブラウザレンダリングまで含む18の監視メニューで、ネットワークからアプリまでを見渡し、どの区間で起きているかを切り分ける進め方も取り上げます。
既存のデータセンター側の監視を置き換えるのではなく、利用者側の計測を加えて、監視できていなかった区間を埋める位置付けです。
自社起因か通信事業者起因かを短時間で見極められれば、対策の優先順位を誤らず、事業側やカスタマーサポートへの説明も実測データに基づいて行えます。
平常時の計測データは、どのキャリア・地域の利用者が遅いのかを示すため、表示速度改善の優先順位付けや、CDN・DNSの選定にも使えます。
弊社の支援先では、実測に基づいて表示速度を改善した後、転換率が30%向上した例があります。
シャドー障害を可視化することは、シャドー機会損失を計測可能な損失に変え、監視への投資を売上の言葉で説明できるようにすることです。
セミナーでは、参加者が自社の数字を当てはめられる損失試算の考え方も提示します。
監視設計から分析・報告までを、非機能要求を専門とする弊社が担う体制もご説明しますので、ぜひご参加ください。
■主催・共催
株式会社Spelldata
■協力
マジセミ株式会社
マジセミは、今後も「参加者の役に立つ」ウェビナーを開催していきます。
過去セミナーの公開資料、他の募集中セミナーは▶こちらでご覧いただけます。
すべての画像
