はじめに

この記事はシスコの有志による Cisco Systems Japan Advent Calendar 2022 の１つとして投稿しています。昨年の記事や関連する投稿記事は以下リンクよりご覧いただけます。

2017年版: https://qiita.com/advent-calendar/2017/cisco
2018年版: https://qiita.com/advent-calendar/2018/cisco
2019年版: https://qiita.com/advent-calendar/2019/cisco
2020年版: https://qiita.com/advent-calendar/2020/cisco
2020年版(2枚目): https://qiita.com/advent-calendar/2020/cisco2
2021年版: https://qiita.com/advent-calendar/2021/cisco
2021年版(2枚目): https://qiita.com/advent-calendar/2021/cisco2
2022年版: https://qiita.com/advent-calendar/2022/cisco

概要

UX2.0、特にUX2.0設定の特徴についてCisco SD-WAN学園のUX2.0先生と好奇くんの会話を通してお届けいたします。

本題

好奇くん：UX先生、最近のCisco SD-WANのvManage GUIでデバイスの設定をしようと思ったらいつものデバイステンプレート（Device Template）のほかに、設定グループ（Configuration Group）というものが出てきたようですが、それは何ですか？

UX2.0先生：・・・・・・（怒る様子）

好奇くん：（なんか機嫌が悪そう、、）UX先生？？

UX2.0先生：私はUX2.0先生だ！名前を間違えるな！

好奇くん：あっ、ごめんなさい。

UX2.0先生：そのUX2.0の2.0はとても大事だぞ。次世代のUIで次元の違うユーザ体験の良さを提供できるU Iという素晴らしい意味を込めているぞ。

好奇くん：（やばい、なんか変人先生みたいだ）

UX2.0先生：UX2.0になると、まずは見ての通り、見た目も操作感も抜群に向上する、他の製品群との統一感も強化されるぞ。

UX2.0先生：しかもそれだけではなく、新しい監視ツール、設定方法、可視化ツール、トラブルシューティングツール、レポーティングなど、さまざまな新しいツールや仕組みが追加され、より直感的でより便利にかつ柔軟にやりたい運用をやりたい放題になるのだぞ！

好奇くん：（あっ熱い！教育熱心というか、製品への情熱がすごいというか、とにかく熱い）
UX2.0は本当にすごいですね。いっぱい勉強したくなりました。UX2.0の全てを教えてください。

UX2.0先生：おお、UX2.0の凄さが伝わったようでよかった！では、まずは先ほど質問された「設定グループ」からUX2.0の新しいデバイス設定方法を教えよう。

好奇くん：（意外と最初の質問内容をちゃんと覚えてくれたのね、気分屋さんだけど実はよい先生かも？）はい、ぜひよろしくお願いいたします。

UX2.0先生：UX2.0では従来のデバイステンプレートに加えて、設定グループという斬新な、というより次世代の設定方法を導入している。

UX2.0先生：デバイステンプレートは機能テンプレート（Feature Template）から構成されるが、設定グループは機能プロファイル（Feature Profile）から構成される。
デバイステンプレートにデバイスをアタッチ（Attach）することで、設定をデバイスに反映するが、設定グループにデバイスを関連付け（Associate）することで、設定をデバイスに反映する。
両者の比較を以下の図にまとめた。

好奇くん：うん（なんか言葉の置き換えだけで、何がどう違うかがわからない。。言葉の遊びってやつか？）

UX2.0先生：「うん」と言いながらも実は全然わかっていなくて、ひょっとすると心の中では「言葉の遊びってやつか？」とでも言っているのかな？

好奇くん：（わぁ、読心術！？）

UX2.0先生：でもご心配なく、これからこの両者の違いを猿でもわかるように解説する。現時点では多分みてもわからないと思うが、主な違いをまとめてみると以下の通りだ。

UX2.0先生：これらの違いを順次に説明したいところだが、その前に一旦デバイステンプレートの復習をしよう。簡単にいうと、ほぼ同じ物理特性や必要な機能を持つデバイスを対象に一つのデバイステンプレートを用意する。そのデバイステンプレートは複数の機能テンプレートから構成される。さらに機能テンプレートの中にはデバイスに依存しない設定値（固定設定）やデバイス依存の設定値（変数）が存在する。図示すると、以下の通りだ。

UX2.0先生：デバイステンプレートをファミレスのセットメニュに置き換えれば、よりわかりやすいと思う。例えば、以下の通り。

好奇くん：確かにわかりやすい！（それはわかっているけどね）

UX2.0先生：でも、デバイステンプレートを実際に運用してみると、いくつかの課題が見えてくると思う。まとめてみると、課題は以下の通り。

・再利用性が低い
・更新と適用は同時に行われる
・設定は煩雑になりがち

UX2.0先生：一つ目の課題は再利用性が低いという点だ。

好奇くん：機能テンプレートをなるべく共通化して、さらに変数を少なめにするなどの工夫をすれば、同じ機能テンプレートをさまざまなデバイステンプレートに使用させることができると思いますし、デバイステンプレートも設計次第で数を抑えられると思いますが、それでも再利用性が低いのでしょうか？

UX2.0先生：それでも再利用性が低いのだ。なぜかというと、デバイステンプレートも、機能テンプレートも全部デバイスモデルごとに用意しないといけないからだ。

例えば、同じ役割＆機能を持つ1000の拠点のデバイステンプレートは本来一つで済むのだが、拠点によって使用されているデバイスのモデルが異なると、モデルごとにデバイステンプレートを用意しないといけなくなる。例えばスループットやポート数や調達関係の事情により、デバイスモデルは10種類があれば、同じ役割＆機能でもデバイステンプレートは１０個用意しなければならない。さらに各々のデバイステンプレートが使用する機能テンプレートもデバイスモデルごとに用意しないといけないため、掛け算でテンプレートの総数があっという間に膨大な数になる。

例のファミレスのセットメニュで例えると、同じセットメニュAを
10代眼鏡なし金髪女性用セットメニュA、10代眼鏡なし黒髪女性用セットメニュA、10代眼鏡あり金髪女性用セットメニュA、10代眼鏡あり黒髪女性用セットメニュA、20代眼鏡なし金髪女性用セットメニュA・・・といった感じで別メニュとしてデザイン、印刷、管理するみたいな感じ。

好奇くん：確かに。。なんか非常に無意味で非効率のような、、

UX2.0先生：実は、仮にデバイスモデルは同じでも、現場ではある理由により、大量な拠点のデバイスを全て同じテンプレートにアタッチしたがらない傾向が強い。

好奇くん：それはなぜですか？せっかくテンプレートの数を減らし、再利用性を高められるのに。

UX2.0先生：それはこれから紹介するテンプレートの二つ目の課題が（ついでに）もたらしてくれた問題だ。

好奇くん：おお、二つ目の課題！

UX2.0先生：二つ目の課題はずばり、更新と適用は必ず同時に行われるという点だ。

好奇くん：確かにそうですが、普通はテンプレートに何らかの変更を加えたらすぐそのテンプレートにアタッチされているデバイスへ反映したくなりますね。別に課題ではないようですが？

UX2.0先生：チーズバーガーを美味しく食べている最中に、突然誰かに咀嚼中のバーガーを吐かせられ、さらに吐かせられたものからチーズだけを生クリームに変えられた後、そのまま口に戻されたら、好奇くんはどんな気分になるのかな？

好奇くん：（なんでいきなり？）えっ？最悪な気分になりますね。その人を殴りたいのです。

UX2.0先生：はい、そうなるよね。例えば、世界各地のミッションクリティカルのシステムを稼働させている数十台のルータには、いきなり一斉に想定外の新しいルーティングの設定を入れられたら、どうなるか想像できるか？

好奇くん：大惨事レベルの障害が発生し、管理者がクビになる、ひょっとすると、会社が潰れるかもですね。でも、そんな無茶な運用は絶対しませんよね。あっ、そうか、もし単純に同じ機能ということで全てのルータを共通のテンプレートにアタッチしたら、そのうちの一つの機能テンプレートの微修正を行ったとしても即時に全てのルータに反映されてしまうから、このような予想外のことが発生してしまうかもしれないということだったのですね！
あっ、先程のチーズバーガーの話も、こういうシチュエーションの例え話だったのですね！

UX2.0先生：お見事！さらに、仮にテンプレートの変更内容自体は問題がなくても、各拠点ルータの運用状況やメンテナンス時間が違うから、一斉に変更を適用させるのは、負荷の観点も運用の観点でも避けたいね。テンプレートの「更新と適用は必ず同時に行われる」という仕様はこういったリスクや理由から基本的に好ましくない。これはさらにテンプレートの共通化を阻害する要因の一つにもなっているね。

好奇くん：おお、理解できました！

UX2.0先生：よし。では次は三つ目の課題だ。それは、テンプレートの作成はそもそも煩雑という点だ。

好奇くん：まぁ、簡単とまでは言えませんが、マニュアルを読みながら私もできたし、一度作成すると複数のデバイスに使えるし、煩雑とまでは言えないのではないのかなと思います。そんなに煩雑ですか？

UX2.0先生：じゃ、好奇くんにファミレスのセットメニュの作成を任されたら、簡単に作成できますか？もちろん、きちんと食材等の調達、管理、調理などのファミレスの運営を踏まえて作成するという意味で。現実的にルータのテンプレートを作成する人も、ルータを含めたシステムの設計、運用を踏まえて作成しているからね。

好奇くん：えーと。まずは客層から人気メニューを考えて、そこから細かい料理や食材を決めて、

UX2.0先生：そんな方法論は良いかもしれないけど、そもそもその後決めた食材を調達できないことになったり、調理できる人がいなかったりするようなことになったら？

好奇くん：そうか。じゃ、まずは雇える料理人の得意料理や近所で調達できる食材から検討した方がよいのですかね。

UX2.0先生：雇える料理人の得意料理は客層に合わないかもよ。近所で簡単に調達できる食材なら競合の店もやっているから簡単に勝てないかもよ。

好奇くん：（意地悪い！）えーと。じゃ、

UX2.0先生：それに、そもそもメニュのデザインはどうしたらお客様にとって見やすいか、印刷はどうしたら料理がより一層美味しく見えるのか、こういった考慮も必要だね。

好奇くん：もう、無理です。それぞれのベストプラクティスを教えてくれるコンサルタントを雇いたくなります。。

UX2.0先生：はい、そうなるよね。残念ながら、百戦錬磨の経験者は別として、ほとんどの初心者はテンプレートを作成しようとする際に、先程のファレミスメニュー作成の好奇くんと同じ気持ちになると思うよ。

好奇くん：（あっ、確かにそうかも）私は事前にCisco SD-WAN Black Beltのハンズオントレーニングを受けたから、マニュアルを読みながらなんとか社内検証環境のテンプレートを作成できたのですが、初心者にとってはテンプレートの作成は意外と難しいかもですね。

UX2.0先生：その通り。機能テンプレートだけでも膨大な数が存在する。それぞれ従来のどのコンフィグのどの部分に対応しているかは最初わからないはずだし、どのように共通化を考慮した上でそれぞれの必要な機能テンプレートを作成し、さらに組み合わせて一つのデバイステンプレートを作成することは初心者にとってはなかなかの難題になるはずだ。

慣れた経験者にとっても作業の手数が多い点と、微妙に重複しているタスクを繰り返しながらも設定ミスを避けなければならない点を踏まえて考えると、テンプレートの作成は決して楽な作業ではないはずだ。

好奇くん：（別にテンプレートをそんなにディスらなくてもよいと思うが）確かにそう感じますね。。
ところで、設定グループを使う場合は、それらの課題は改善されますか？

UX2.0先生：無論だ。むしろこれらの課題を改善するために、設定グループという次世代の設定方法が開発されたのだ。順次に説明しよう。

好奇くん：はい！よろしくお願いいたします。

UX2.0先生：まずは再利用性についてだ。設定グループは役割的にはデバイステンプレートに似ているが、デバイステンプレートよりずっと自由奔放な存在だ。

好奇くん：自由奔放？

UX2.0先生：要は、設定グループはただ設定を行うための容器みたいなもので、その中に自由に好きなルールでどんなルータを入れてもよい。デバイスモデルの制限はもちろんなく、役割、地理的な場所、部署などの任意の基準でルータを分類してそれぞれの設定グループに入れればよい。無論、同じ設定グループに入ったルータは、同じ機能プロファイルを使用することになるので、機能面の共通点が多ければ多いほど望ましいけどね。

好奇くん：なるほど、デバイスモデルを無視して完全に機能の観点でルータを設定用グループに分類・運用できるようになっただけでもかなり嬉しいのですね！

UX2.0先生：さらに、設定グループは、更新と適用が同時に行われなくてもよいのだ。むしろ、基本的に別々のタイミングで行った方がよいのだろう。そして、更新と適用のタイミングは別々にすることができるだけでなく、同じ設定グループに属するルータを任意に選択して、部分的に適用することもできるし、各ルータの適用状態も管理できる。

好奇くん：おお！これでさらに再利用性が高くなるのですね。チーズバーガーの例で言うと、食べている最中に、チーズをクリームに変える指示を無理やり受けさせられなくて済むので、美味しいチーズバーガーも安心して食べるようになりますね。

UX2.0先生：そう、その通りだな。チーズバーガーの例が出たから、その勢いで先程のファミレス運営とメニュ作成の例で第三の改善点を紹介しよう。それはずばり、業界専門のコンサルタントからコンサルティングを受けられるようになることだ。客層や料理人や食材などの要素を総合的に考慮し、料理の選定からメニュのデザイン・印刷までベストプラクティスや手順を全部教えてもらえるコンサルティングだ。

好奇くん：おお！それはありがたいが、コンサル料は高そうですね。

UX2.0先生：コンサル料？無料コンサルティングだよ。設定グループの話に戻すと、このコンサルティングはワークフローライブラリとスマートデフォルトと呼ばれる機能で、設定グループや機能プロファイルに内包されている機能なので、ただで使える。こんな感じだ。

好奇くん：いきなり拠点の設定が完了状態になっているみたいですね？

UX2.0先生：その通りだ。コンサルが最初からベストプラクティスに基づき設定グループに必要な機能プロファイルを変数等も含めて設定してあるから、いきなり適用できる状態になっている。無論、以下の通り、必要に応じて各機能プロファイルの微調整を行うことも可能だ。

UX2.0先生：まぁ、初心者ならまずデフォルトの設定でそのまま適用するのも悪くない。そもそもベストプラクティスなので基本的にそのまま動く。もし何か更新したいのであれば焦らずにその後ゆっくりやればよい。前に紹介した設定グループの「更新と適用は同時行われない」と言うメリットを思い出したか？テンプレートと違い、デバイスを設定グループに関連付けしても、すぐ設定が一気にデバイスに適用されることもないので、試しながら色々微修正できるよ。

好奇くん：おお！完璧じゃないですか！

UX2.0先生：そう、設定グループは。。ほぼ完璧だ。

好奇くん：（お？珍しく謙遜になってきた？）ほぼですか？

UX2.0先生：そう、設定グループはかなり優れているし、これからのCisco SD-WANの新機能は基本的に全部設定グループでのUIを提供する方針も決まっているが、とある理由でまだすぐ本番環境で使用することを推奨していない。

好奇くん：とある理由？

UX2.0先生：それは対応している機能はまだ不十分だから。2022年12月17日現在のCisco SD-WANの最新バージョンである20.9/17.9では、機能プロファイルはまだ機能テンプレートのすべての機能をカバーできていない。具体的に言うと、現時点サポートしている機能は以下のマッピングが示した通りだ。