Meraki クラウドのサイジングとスケーリングに関する考慮事項およびベストプラクティス

ネットワークとデバイス管理

数百のネットワークやデバイス、多数の管理者を抱える柔軟環境では、比較的簡単なスクリプトであっても、複数のネットワークやオーガナイゼーションにわたる構成管理のプロセスを 1 回のコマンドに大幅に簡略化できます。例えば、SSID 名を更新するスクリプトは、API ユーザがアクセス可能なネットワークとオーガナイゼーションのリストを取得し、すべてのオーガナイゼーションとネットワークに同じ SSID コマンドを実行することや、実行対象を指定することが可能です。

 

Meraki Developer Hub には、複数のオーガナイゼーション間で管理者を管理する Python スクリプトのデモプロジェクトがあり、スクリプトのインストール方法と使用方法の詳細、ならびに参考となるソースコードが提供されています。

 

また、MX ファイアウォールルールを大規模に管理する Python スクリプトのプロジェクトもあり、ソースコードや自組織での利用方法も提供されています。

ネットワーク自動化

定期的な監査やネットワークの一括展開、構成変更、その他の反復的な定期タスクが必要な柔軟かつ大規模な環境では、API を使用してネットワークやデバイス管理を自動化することができます。単一のレコードをスケジュールに従って変更するなどの簡単な処理から、他の自動プロセスによってトリガーされ、外部プログラムへデータを出力するような複雑なスクリプトまで利用可能です。

 

Meraki Developer Hub のラボでは、Python と API を使用してタスクを自動化する方法をステップごとに解説しており、自動化ツールを作成するための良い出発点となります。

 

さらに高度な例として、他サービスとの統合を伴うものがあり、ServiceNow を使って Meraki ネットワークをプロビジョニングするデモプロジェクトがあります。これにより在庫管理と結び付けたり、より高度な制御のためのアプリケーション構築の概念に触れることができます。

アクションバッチ

アクションバッチは、ダッシュボード API の機能であり、複数の操作を 1 回の API コマンドで実行できるようにします。これにより、関連する複数のコマンドを一度にまたは順番に実行でき、スクリプトや統合ソリューションから発行するコール数や種類を簡略化できます。また、ダッシュボード API エンドポイントで課される 1 秒あたり 10 回の API コールの制限を回避する目的でも利用できます。

 

例えば、スイッチをネットワークに追加し、48 ポート全てを構成して、スイッチの管理インターフェースを設定する処理を 1 回の POST 内の単一アクションバッチで行えます。各アクションバッチは、この 10 コール/秒の制限に対して 1 コールとしてカウントされます。アクションバッチの詳細は、Cisco DevNet のアクションバッチに関する記事をご参照ください。

Webhook によるプロアクティブなアラート

アラートはネットワークのパフォーマンス監視において非常に重要であり、ネットワークや組織の拡大には、柔軟性とスケーラビリティの両方を備えた受信・対応方法が必要です。ダッシュボードは、重要なネットワークイベントに対するアラートをすべてのネットワークで設定可能にします。Webhook は、これらのアラートをアクション可能な項目や高度な監視データに変換する手段を提供します。Webhook は、JSON オブジェクト形式で設定済みの HTTPS URL にアラートを送信するため、JSON を解釈できるあらゆるサービスで利用可能となり、幅広い統合が可能です。

 

統合は必ずしも複雑である必要はありません。例えば、このデモプロジェクトでは、ダッシュボードアラートを Google スプレッドシートに記録して、データを即座に追跡したり、レポートを作成したりできます。

 

Webhook を活用する別の簡単な方法は、特定のインシデント発生時に Cisco WebEx Teams や Slack のようなコラボレーションアプリにメッセージを送信することです。この例では、Zapier のような自動化サービスを使って、ネットワークアラートを WebEx Teams に中継することで、重要なチームに新しいインシデントを通知します。一般的に自動化サービスは、Webhook を受信した際にさまざまなアクションを実行でき、ネットワークアラートの機能を拡張します。

オーガナイゼーション管理者

数百人の管理者を抱えるオーガナイゼーションでは、複数の IdP（アイデンティティプロバイダ）と共に SAML 認証を活用します。オーガナイゼーション内で複数の SAML ロールを作成し、誰が特定のネットワークセットにアクセスできるか、および各ロールにどの管理権限が付与されるかを指定します。手動管理者もオーガナイゼーション内で引き続き使用されますが、その役割はより制限されます。主な理由は、SAML 管理者はダッシュボード API を利用できないため、API を使用するユーザは API を利用するオーガナイゼーションで標準管理者である必要があるためです。

 

これらのオーガナイゼーションやアカウントは、標準管理者と SAML ロールの両方を管理するためにダッシュボード API も活用します。Admins エンドポイントを使用すると、1 つ以上のオーガナイゼーションで標準管理者を追加、変更、または削除できます。また、SAML Roles エンドポイントを使用すると、1 つ以上のオーガナイゼーション内のロールリストを取得したり、SAML ロールを追加、変更、または削除したりできます。

 

SAML SSO ログインの設定方法については、「ダッシュボード用 SAML シングルサインオンの設定」の記事をご参照ください。

デバイス上限

推奨最大スケーリングガイドライン:

項目	上限
合計デバイス展開規模	無制限
1 オーガナイゼーションあたりのデバイス数	35,000
1 ネットワークあたりのデバイス数（スタンドアロンおよび統合ネットワーク）	5,000

 

ネットワークあたりのデバイス上限

製品タイプ	上限
MR	5000
MS	5000
MT	1700
MV	1000
MX	2
MG	4
CG	2
WLC	2

ダッシュボード UI とやり取りする際の最適なパフォーマンスを維持するためには、1 つのオーガナイゼーション内のネットワーク全体での Meraki デバイス総数がこれらの上限内に収まるようにすべきです。オーガナイゼーションが標準業務運用の中でこれらの上限に近づいている場合、次のいくつかのステップを講じることで、引き続きデバイスを最適に管理できます。

• Meraki アカウントチームに相談し、オーガナイゼーション分割を検討してください。これにより、オーガナイゼーション内のネットワーク、デバイス、ライセンスの一部を別のダッシュボードオーガナイゼーションに分離できます。この方法は、将来的にオーガナイゼーション分割を迅速に行うためのガイドライン確立にも役立ちます。

• ネットワークが推奨デバイス数上限に近づく、または超えそうな場合は、オーガナイゼーション内でネットワークを複製し、デバイスを移動させることを検討してください。こうすることで、ネットワーク構成を維持しながら、多数のデバイスによるパフォーマンス低下を回避できます。

• 1 度に複数のデバイス構成変更を行う場合は、ダッシュボード API を活用してください。これにより、2 つのネットワークやオーガナイゼーション間での構成同期の維持が大幅に簡略化されます。

• 管理対象のオーガナイゼーション数が 700 を超える、または超える見込みがある場合は、拡張への対応方法について Meraki アカウントチームに相談してください。

SNMP および Syslog

標準規模および拡大規模の両方の組織において、Syslog や SNMP といった従来の監視プロトコルは、システムログやネットワークログの取得、デバイス・ネットワーク・オーガナイゼーションレベルの統計レポート用途で活用されます。大規模環境でこれらの技術を導入する場合は、次の点に留意する必要があります。

• SNMP については、Meraki デバイスに直接ポーリングして情報を取得できますが、最も有用な情報は Meraki 固有の MIB を使ってダッシュボードからポーリングすることで取得できます。これによりデバイス使用状況やネットワーク利用状況のより詳細な情報が得られます。設定方法についてはSNMP 概要と設定ガイドをご参照ください。

• Syslog は、ダッシュボードのイベントログからイベントを保存して分析するためにも利用できます。これにより、ダッシュボードイベントログに一定期間しか保持されない制限を回避し、長期保存が可能です。詳細はSyslog サーバ概要と設定ガイドをご覧ください。

複数オーガナイゼーション間での Auto VPN 展開

大規模組織では、複数のオーガナイゼーション間で安全なサイト間通信を行う必要がある場合があります。Meraki の Auto VPN は、異なる MX 間で VPN トンネルを構築するための低負荷なソリューションですが、同一ダッシュボードオーガナイゼーション内の MX 間でしか VPN トンネルを構築できません。そのため、複数のオーガナイゼーション間に VPN を構築する場合には、追加の設定手順や設計上の考慮が必要です。

• それぞれのオーガナイゼーションでハブ＆スポーク型トポロジーを構築し、1 台以上のハブ MX が多数のトンネルをスポークに張る構成が推奨されます。これにより、小型 MX のトンネルおよびトラフィック負荷を軽減し、定格トンネル数を超えずに運用できます。

• Auto VPN 対応のハブ MX は、OSPF や iBGP といったルーティングプロトコルに参加できます。iBGP は NAT モードおよびパススルーモードの MX で動作し、柔軟なルーティングと VPN 構成が可能です。

• 異なるオーガナイゼーションのハブ MX 間で安全なトンネルを構築するには、それぞれのオーガナイゼーションで「非 Meraki」IPSec VPN 設定を作成します。フェーズ 1 とフェーズ 2 設定が一致すれば、通常の非 Meraki IPSec VPN と同様にトンネルが張られます。

電波法域（Regulatory Domains）

複数の国で Meraki アクセスポイントを運用する場合、各 MR ネットワークでの電波法域（ワイヤレス信号送信に関する法的制限）の設定と管理が必要です。国ごとに異なるため、ネットワーク単位で明示的に設定する必要があります。異なる電波法域に属する AP は同一ダッシュボードネットワークに所属できません。以下は大規模環境での管理方法です。

• 電波法域ごとに AP を分けてネットワークを構成し、競合を回避します。

• 新規購入 AP の電波法域は、発送先住所とクラウド初回接続時のパブリック IP の位置情報で決定されます。別ロケーションでテストを行う場合は注意してください。

• 運用中に電波法域の異動や競合が発生する可能性もあります。詳細はMR 電波法域の記事をご参照ください。

MV ネットワークのストリーミングと使用に関する考慮事項

動画ストリーミング（通常利用）

• 各カメラは、構成データやメタデータ（動き検出など）の送信に常時約 50kbps のアップストリーム帯域幅を使用します。
• さらに、カメラ映像を視聴している際は、ビットレート（0.5Mbps 〜 8Mbps）が必要となります。
• クラウドストリーミング時は、このビットレートがアップストリーム帯域要求となります。
• クラウドストリーミングでは、実質的に視聴上限はありません。
• ローカルストリーミング時は、アップストリーム帯域消費は発生しません。

MV ビデオウォール

• ビデオウォールの作成時、各タイルのビットレートの合計が必要な帯域幅になります（UI 上で見積りを表示します）。
• タイルサイズが小さすぎる場合、アダプティブビットレートストリーミングを有効化します。
• ビデオ閲覧専用のハードウェアワークステーションには、ハードウェア要件があります。

以下の図は、動画ストリーミング時に発生する可能性のある障害ポイントを示しています。

 

動画エクスポート（通常利用）

• エクスポート 1 件につき 1Mbps 以上のアップストリーム帯域を推奨します。これは、カメラがエクスポート前に動画をクラウドへ送信するためです。

MV クラウドアーカイブ有効時（オプションアドオンライセンス）

• クラウドアーカイブ利用時には、カメラ 1 台あたり少なくとも 1Mbps のアップストリーム帯域が必要です。

外部 RTSP 有効時

• 外部 RTSP を使用すると、カメラのローカルネットワークに接続している場合に直接映像へアクセスできます。ストリームはダッシュボード上で設定されたビットレートに従います。外部 RTSP 有効化時はローカルネットワークがトラフィックに耐えられるか確認してください。

動画ストリーミングの制限事項

Meraki MV カメラはすべて、映像をカメラ本体の SSD ローカルストレージに記録するため、通常は低帯域幅のデバイスです。ただし、ダッシュボードから動画をストリーミングする場合は、ローカルストレージからクライアントに送信するためネットワーク帯域使用量が増加します。ビデオウォールを表示する場合は、各カメラが映像をストリーミングするため、ネットワークの帯域容量やカメラ数によって負荷が高まる可能性があります。以下に考慮事項を挙げます。

• MV 動画を閲覧するブラウザがカメラと同一ローカルネットワーク上にある場合、カメラは WAN 帯域を消費せずに直接クライアントにストリームします。大規模なローカルカメラ設置では特に、監視用マシンを配置する際に留意してください。詳細は、カメラの直接ストリーミングとクラウドプロキシに関するドキュメントをご参照ください。

• クラウドアーカイブを使用する場合、録画中は映像アップロードに帯域を使用します。特に大量のカメラ展開では、WAN 帯域の計画を適切に行ってください。詳細はクラウドアーカイブ機能の記事をご覧ください。

カメラ API

第 2 世代（MVx2）カメラは、カメラ内で高度な解析を実行し、そのメタデータを Meraki クラウドへ送信する能力を持ちます。このアーキテクチャにより、詳細な分析を行う際のコストと複雑さが大幅に軽減されます。Meraki カメラは、これらの分析や重要な動作イベントへのアクセスのための API 群も備え、オーガナイゼーション規模で MV カメラを動作データのセンサー兼解析エンジンとして活用できます。