2023-04-12 04:47 PM 2023-04-17 12:16 PM 更新
既存のオンプレミス型の電話システムからWebex Callingへの移行を検討されている方々の中には、通話の品質や可用性は自分たちの顧客へのサービス品質や顧客体験の観点から非常に重要なことであり、状況を積極的にモニタリング(監視)をし、問題の早期発見や迅速な対処を行いたいとお考えになられておられる方々がいらっしゃいます。そういった方々の中からその具体的な方法についてご相談を受けることがあります。
ご利用されているWebex Callingサービスにおいてそのような状況がお客様のテナント (Organization/組織) において発生した場合にはWebex Control Hubを通じて管理者にアラートが送られる仕組みがまもなく提供回されますので、一般的な企業においてはそれで十分だというケースが多いのではないでしょうか。(なお、Webex MeetingsサービスやWebex Roomデバイスなどではすでに同様の機能が提供されています。)
今回は、問題の状況や原因をかなり詳細かつ迅速に把握できるようになる方法をご紹介いたします。
Webex Callingサービスとは別に、ThousandEyesのWebexモニタリングを利用します。
ThousandEyesは世界中の各Webexデータセンター内に監視ポイント (クラウドエージェント) を展開しており、ThousandEyesのクライアントエージェントまたはエンタープライズエージェントからWebexのサービスとのネットワーク接続に関して通信経路の状況をエンドツーエンドで可視化することができます。
ネットワークの状況を積極的にモニタリングする理由なのですが、実際にお客様から弊社へ電話システムやWeb会議の通話品質の問題についてサポート窓口に寄せられるもののほとんどの原因がネットワークに起因するものだからです。これはオンプレミス型の電話システムやビデオ会議システムでも同様なのですが、クラウド型のサービスの場合にはお客様の社内のネットワークに加えて、インターネットが経路の大部分を占めるためにネットワークの状況を従来の方法でモニタリングすることが困難となっています。実際に対策が完了している企業の割合はまだ相対的に低くなっています。さらに、COVID-19への対策として各種SaaSの導入と適応のためにセキュリティ関連のサービスが導入されたものの、最適化がまだ完了しておらず、音声やビデオの品質に影響が出て解決に苦慮されているケースも散見されます。(これはオンプレミス型の場合でも同様なのですが、クラウドサービスの場合はより問題が複雑です。)
そんな中、最近、ThousandEyesとWebexのサービス間の連携が進み、Webex Callingの呼制御プロトコル (SIP-TLS) や音声メディア (sRTP) の通信についても積極的なテストを実施して通話品質の観点からネットワークの状況を評価および可視化することができるようになりました! 例えば、電話やアプリが数百台から数千台も展開されているような大規模拠点からWebex Callingのデータセンター (日本リージョンは東京および大阪) へのネットワーク経路の状況を2分おきに評価し、輻輳などによって通話品質が下がるような問題があれば管理者に即時に通知するようなことができるようになりました。
ThousandEyesがWebex Callingサービスについて評価可能な項目の例:
上記の状況が悪化していきますと、音声が途切れたり、いくつかの特定の機能が不全になったりします。
上記の他にもクライアントエージェントがインストールされたユーザがWebex会議への接続に時間がかかり過ぎてしまったなどの情報が収集および統計的に分析され、ThousandEyes Internet Insightというサービスを通じて管理者がどの程度の範囲のユーザで問題が起きているのかなども知ることができます。
ThousandEyesもモニタリングのさまざまな方式をご提供しておりますが、今回はその中でも、大規模拠点にエンタープライズエージェントを配置し、拠点のインターネット接続回線の接続ポイントからWebex Callingのデンターセンターへ積極的に上記のような状況をテスト(試験)によって評価し、ネットワーク由来の品質の問題が顕在化し始めた瞬間を検知して管理者へ通知する仕組みを実装する例をご紹介します。
下記のように、ThousandEyesで検知したWebex Callingデータセンターへの経路上に通話品質などに影響をアラートとして管理者へのメールだけではなく、Webhookを通じ、各種システムとの連携を実装します。以下のようなユースケースはさほど難しくないのではないでしょうか。
構成図だけですとデベロッパーとしてはイメージが掴みづらいと思いますので、いくつかのサンプルコードを例示していきます。
品質低下などのアラートを外部システムへのWebhookとして送信することをThousandEyesで設定できます。
Webhookのボディに含めるJSON形式のデータは自由にカスタマイズできます。(今回はデフォルトのまま利用してみます。)
これを受信するのは以下のようなPythonコードで実装したAWS Lamda (とAPI Gateway) です。
import json
import base64
BASIC_AUTH_USER = 'thousandeyeuser1'
BASIC_AUTH_PASSWD = 'D3buG0waRaNa!'
ALERT_RULE_NAMES = ['Alert-NW-WxC-Tokyo', 'Alert-NW-WxC-Osaka']
def process_webhook(event, context):
auth_header = event['headers']['authorization']
encoded_value = base64.b64encode("{}:{}".format(BASIC_AUTH_USER, BASIC_AUTH_PASSWD).encode('utf-8'))
if auth_header and auth_header == "Basic {}".format(encoded_value.decode(encoding='utf-8')):
body = event['body']
if 'type' in body and body['type'] == 1:
# TriggeredタイプのWebhook
if 'alert' in body:
# Alert
if 'rule' in body['alert'] and body['alert']['rule']['name'] in ALERT_RULE_NAMES:
# ThousandEyesで設定したアラートルールに関連したアラートであるかどうかを名前で判定
# 東京または大阪のDCのTEエージェントとのRTP通信で遅延やパケットロスが閾値を越えたなど
# ここで管理者への通知や管理システムとの連携の処理などを実行します
print('{} Webex Calling DCへの経路に深刻な異常が発生しています'.format(body['id']))
else:
print('{} 関係のないアラートでした'.format(body['id']))
else:
print('{} アラートが閾値を下回ったためにクリアされました'.format(body['id']))
return {
'statusCode': 200,
'headers': {'Content-Type': 'application/json'},
'body': json.dumps({'id': body['id']})
}
else:
# ThousandEyesのWebhook設定でBasic認証が正しく設定されていない
return {
'headers': {
'www-authenticate': [
{
'key': 'WWW-Authenticate',
'value':'Basic'
}
]
},
'status': 401,
'body': 'Unauthorized'
}
LambdaやAPI Gateway、およびその他のファンクションをどのように組み合わせるのかはHTTPリクエストの数や接続する外部システムとの関わりによってケースバイケースですので今回はその部分の議論は割愛しまして、ThousandEyesのWebex Callingに関するアラートを受信するためのポイントを解説いたします。
Webhookのボディ内のデータ (JSON形式) はThousandEyesの管理者が設定した構造になっていますので、Webhookを受信するコードは構造については管理者との間で合意しておく必要があります。
Webhookの受信側として最小限のBasic認証だけ実装しています。(パスワード等は本来はシークレットマネージャーに格納したいところですが、今回はあえてプレーンテキストでコードに埋め込んでいます。)他システムへの通知もこのコードの中で行う前提にしておりますが、プロダクションではメッセージバスやキュー (AWSであればEventBridgeやSQSなど) に格納だけして終了という実装になるかもしれません。
処理すべきアラートであると判定したらログにメッセージを残す処理だけを今回は実装しています。
ご参考になるかどうかわかりませんが(もしご参考になれば幸いです)、今回はAWSのサービスはServerless Frameworkを利用してデプロイしています。必要最小限しか設定しておりませんが、もしご興味のある方はご覧ください。(Webhookを受信するAPI GatewayとLambdaを一つずつ組み合わせているだけです。実際のプロダクション環境では、他のファンクションも必要になるかとは思います。)
service: aws-sf-te-webhook-example
frameworkVersion: '3'
provider:
name: aws
stage: ${opt:stage,self:custom.defaultStage}
runtime: python3.8
region: ${opt:region,self:custom.defaultRegion}
plugins:
- serverless-python-requirements
custom:
pythonRequirements:
usePipenv: false
defaultStage: dev
defaultRegion: us-west-1
functions:
webhookhandler:
handler: webhookhandler.process_webhook
events:
- httpApi:
path: /webhooks
method: post
ThousandEyesで設定したWebhookで送信されてくるHTTPリクエストを以下のようにcurl形式で例示しておきます。(webhook.siteで取得、エクスポートしています。)
curl -X 'POST' 'https://webhook.site/556fadcf-6c8d-4dd9-a7e1-bdb862e69e7c' -H 'connection: close' -H 'content-length: 1166' -H 'content-type: application/json' -H 'authorization: Basic dGhvdXNhbmRleWV1c2VyMTpEM2J1RzB3YVJhTmEhJw==' -H 'accept: */*' -H 'host: webhook.site' -H 'user-agent: ReactorNetty/1.0.12' -d $'
{
"id": 750737261,
"type": 1,
"alert": {
"id": "b640577f-fb75-49b1-bce8-7e992005e8ca",
"type": "OneWayNetwork",
"severity": "CRITICAL",
"test": {
"name": "NW-WxC-Japan-Tokyo",
"labels": [
]
},
"targets": [
"Tokyo, Japan (Webex Calling)"
],
"rule": {
"id": 5834535,
"name": "Alert-NW-WxC-Tokyo",
"expression": "Latency \u2265 15 ms",
"notes": ""
},
"triggered": 1681227240000,
"cleared": 1681227572000,
"details": [
{
"metricsAtStart" : "Latency: 20.6 ms",
"metricsAtEnd" : "N\/A (rule modified or removed from test)",
"source" : {
"id": "935316",
"name": "turatake-teea1"
}
}
]
}
}
'
このようなサンプルからテスト用のデータを生成しておくと良いでしょう。
今回の例では単純にアラートの名前だけで処理するべきアラートかどうかを判定していますが、遅延やジッター、パケットロスやMOS値などのメトリックの値の大小でもう少しインテリジェントなハンドリングをしても良いかもしれません。
ご覧になってお分かりになると思いますが、JSONの構造がThousandEyesの管理者によって変更される可能性があることをのぞけば、特殊な考慮事項などはありません。イベントの送信回数など受信側のサイジングを決定する要素はテストの頻度やアラートの発生回数などに依存しますので、実際には運用しながら調整していくことになるのではないでしょうか。
ThousandEyesがどんなものか初めてご覧になられる方もいらっしゃるかと思いますが、現実的に役立ちそうなテストを実施し、問題があった場合は結果を即時に知ることができることを具体的に理解していただくことにお役に立てましたら幸いです。
最後にThousandEyesのエンタープライズエージェントの要件やインストール方法などについて簡単にご紹介いたします。
詳細な日本語のドキュメントはこちらがわかりやすいです。
エンタープライズエージェントはインターネット接続ルーターとして利用するCisco IOS-XEルーター上で仮想マシンとして配置することがテストの精度、監理のしやすさなどいろんな意味でメリットがあろうかと思いますが、ラボでちょっと試してみたいという方はWindowsやmacOSの上にUbuntu Linuxの仮想マシンを準備し、Linuxパッケージ版のエージェントをインストールするのも良いかもしれません。
ちなみに私はmacOSの上にMultipassでUbuntu Server 20.4 LTSの仮想マシンを作成してインストールしています。以下のようなcloud-initの設定ファイルを利用して使いたい時に3分ぐらいでインストールして実行できてとても便利です。
#cloud-config
timezone: Asia/Tokyo
locale: en_US.UTF-8
system_info:
default_user:
name: ubuntu
lock_passwd: False
plain_text_passwd: <YOUR_PASSWORD>
groups: [adm, lxd, sudo]
sudo: ALL=(ALL) NOPASSWD:ALL
shell: /bin/bash
runcmd:
- sudo apt-get update
- cd "/home/ubuntu"
- sudo curl -Os https://downloads.thousandeyes.com/agent/install_thousandeyes.sh
- chmod +x install_thousandeyes.sh
- sudo ./install_thousandeyes.sh -b <YOUR_ACCOUNT_GROUP_TOKEN>
- ./install_thousandeyes.sh -f
- sudo apt install -y net-tools
- sudo apt-get install -y ntp
- service ntp start
- sudo apt-get install -y te-agent-utils
- sudo ifconfig enp0s1 mtu 1454
上記のYAML形式のファイルを読み込ませてUbuntuのインストールと初期設定、ThousandEyesのLinux Package版のインストールなどを行なっています。
multipass launch --name ea1 --cpus 2 --memory 1G --disk 20G --cloud-init cloud-config-te-ea.yml 20.04
ただ、小規模なラボネットワーク内のラップトップで動かす前提ですので、必要最低限の設定のみとなっております。皆様がご利用される場合は環境に合わせて適切なセキュリティ対策の適用、より生産性を高めるツールなどをご利用ください。
検索バーにキーワード、フレーズ、または質問を入力し、お探しのものを見つけましょう
シスコ コミュニティをいち早く使いこなしていただけるよう役立つリンクをまとめました。みなさんのジャーニーがより良いものとなるようお手伝いします
下記より関連するコンテンツにアクセスできます