この記事は、ユーザー全体で合成アプリケーション監視を有効にしつつ、アプリケーションを健全に保つ方法を説明し、使う DEM アプリケーションプローブを計画している Netskope 管理者やアプリケーション所有者向けに書かれています。 バックグランドのような深いネットワーキングは不要です。 このガイドでは、何を決定すべきか、そしてどのような順序で決定すべきかに焦点を当てています。
アプリケーションプローブの機能
Netskope Digital Experience Management (DEM)は、重要なアプリケーションが実際のユーザーにとってどれだけうまく動作しているかを示します。 その最も便利な機能の一つが アプリケーションプローブです。これは各デバイス Netskope Client が選択したウェブアドレスに送信する小型の自動テストです。 アプリにアクセス可能かどうかを確認し、応答速度を測定します。
アプリケーションごとに最大3つのウェブアドレスを選び、各デバイスが5分ごとから1時間に1回までテストする頻度を選べます。プローブは、全員に対して有効にすることも、特定のグループや組織単位（OU）に対してのみ有効にすることもできます。ユーザーがレポートする前に問題を発見する簡単な方法です。
なぜ計画が重要なのか
それぞれのプローブは非常に小さい。でもプローブは、オンにする すべてのデバイス から動作します。1万台のノートパソコンがそれぞれ数分ごとに小さなテストを送信すると、それが積み重なって、あなたが見ているアプリに絶え間なくデータが送られてくることになる。それを、その用途向けに設計されていないアプリに向けてしまうと、意図せずアプリに過負荷をかけてしまう可能性があります。幸いなことに、探査機は自然に拡散していった。
各デバイスは Netskope Client が始まるとそれぞれ独自のプローブタイマーを始める。 試験はすべて同じ時間に行われるわけではありません。デバイスは異なるタイミングで始めるため、プローブは自然に広がり、負荷を軽く保ちます。 注目すべきは、会社全体のリブートや大規模なクライアントアップデートなど、多くのデバイスが同時に起こるイベントです。それらがプローブを一時的に合わせることができます。
下の画像は、同じ1万人のユーザーが同じ5分間隔の設定で利用している様子を示しています。通常、テストは分散して実施されるため、負荷はほとんど目立ちません（低い方の線）。多くのデバイスが同時に始めると、同じ設定でも大きく繰り返されるスパイクが発生することがあります。
注：グラフは、保守的な負荷モデルに基づいた計画策定の補助資料です。アプリケーションの実際の容量については、所有者に確認してください。Netskopeチームと共に準備を整えましょう。
通常、プローブは間隔をあけて優しく挿入されます（下線）。複数のデバイスが同時に始めると、同じ設定でもスパイク状に並びます。
単純なルール:デバイスが多ければ間隔が短くなるほど負荷も増えます
アプリに到達するトラフィック量を左右する要因は2つあります。探査しているデバイス数と頻度です。間隔を長くしたり、グループの人数を少なくしたりすることで、アプリの処理能力の範囲内に十分収まります。以下のグラフは、より小さく、より安定した目標値を想定した場合、1つのアプリが各時間間隔でサポートできるユーザー数を概算で示しています。
これはあくまで目安です。間隔を長くすることで、より多くのユーザーが安全に1つのターゲットを共有できるようになります。アプリの実際の性能は異なる場合があります。アプリの所有者に確認してください。
Shared Responsibility
Netskope はプローブを送ります。ターゲットや聴衆、頻度は自分で決めます。 最も安全な展開方法は、監視対象アプリの所有者と共同で計画されます。
安全な展開のための5つのステップ
1. Start small. まずは1つのグループまたは組織単位（数十人から数百人のユーザー）に対してプローブを有効にしてから、範囲を拡大してください。
2. Pick a comfortable interval. 開始は5分のデフォルトではなく15〜30分で始めます。 後で短くできますよ。
3. Choose targets that can take the traffic. 大手SaaSサービスは簡単に対応しています。小規模な内部アプリケーション、管理ページ、または単一サーバーサイトは、より注意が必要です。まずは所有者に確認してください。
4. Grow in stages. パイロット運用から段階的に大規模なグループへと移行し、アプリとネットワークが健全な状態を維持していることを確認しましょう。
5. Keep an easy way to dial back. プローブはグループ/OUごとに設定されているため、負荷がかかっていると思われる箇所があれば、一度に一時停止したり、数を減らしたりすることができます。
簡単な計画ガイド
使う、どこから始めるか決める出発点として。 これは意図的に控えめな措置だ。目標はスムーズな展開であり、プローブの数を最大化することではない。
| Situation | Suggested Starting Point |
|---|---|
| 大規模で有名なSaaSアプリ(主要な生産性やCRMスイート) | 間隔は問いません。ただし、グループごとに段階的に展開してください。 |
| ロードバランサーの背後にある中規模の内部ウェブアプリ | 開始は15〜30分で;1つのOUをパイロットしてから拡張します。 |
| 小規模または単一サーバーの内部アプリケーション/管理コンソール | 開始は30〜60分で;観客を少人数に保つこと;アプリの所有者に確認してください。 |
| ターゲットがどれだけの負荷に耐えられるかは不明です | 小規模なものとして扱ってください。所要時間は30～60分、試験的なグループのみで実施します。オーナーに確認してください。 |
注目すべき点
- Big start-up events. 全社的な再起動、パッチデイ、大規模なクライアントアップデートで、多くのデバイスが同時に起動し、プローブを揃えることができます。 可能であれば、これらを複数のグループに分散させてください。
- Three addresses, one destination. もしあなたの3つのドメインが実際には同じサービスにつながっているなら、そのサービスへのトラフィックは3倍になります。不明な点がある場合は、アプリの所有者に確認してください。
- Smaller targets feel it first. 社内のツールやアプライアンスは通常、大規模なクラウドサービスよりも少ない処理をし、より長い間隔と小規模なグループを扱います。
- Your own network. ファイアウォール、プロキシ、インターネット回線もプローブトラフィックを伝送する。ネットワークチームと協力して、非常に大規模な展開を実施してください。
支援を受ける
Netskopeの営業エンジニアや技術アカウントチームが、自社のアプリやユーザーのプローブサイズを手伝ってくれますし、展開計画をレビューしてから広範囲に進めることができます。迷ったら、小さく始めて育てましょう。プローブは健康状態が確認できれば簡単にスケールアップできます。