Red Hat Summit 事例翻訳:6.Analog transformation: Scaling network automation culture with Ansible Tower at Microsoft

この記事は、以下のシリーズの6つ目の記事です。

Red Hat Summit 事例翻訳:Analog transformation: Scaling network automation culture with Ansible Tower at Microsoft

(前の記事はこちら)

最後に、これからの大きな賭けの話をしましょう。

f:id:canalroy:20190827205445p:plain

ネットワーク自動化の将来はどうなるでしょう。
私たちのチームが、どこに到達しようとしているのか。

Red Hatと提携していることで、エンタープライズの領域であろうがどこでも取り組むことができるようになりました。

また、我々が志向している、最大のものの1つがネットワークモデリングです。

f:id:canalroy:20190827205450p:plain

現在、我々は小規模にはネットワークモデリングを既に採用しており、いくつかのPoCを終えています。
これによって、私たちが本当にやりたいことは、デバイスのコンフィグレーションです。

ですが、私達はデバイスコンフィグレーションとデバイスモデリングからは少し離れようと思っています。
デバイス上の設定には、他のデバイスとリンクするための非常に多くの複雑なデータがあります。そのため、それらをネットワークモデル化しないということは不可能な規模に近づいているという見方をしています。

f:id:canalroy:20190827205454p:plain

2つ目については、Single source of truth(信頼できる唯一の情報源)についてです。

かつて、私がネットワークエンジニアから言われた言葉を教えましたが覚えていますか?『デバイスの正しい構成情報が知りたいなら、実際にログインしてチェックしたら?』でした。

多くの人々は、これをintent based networking(意図に基づくネットワーキング)と呼んでいます。デバイスへは、必要なインテントを定義します。
このアイディアに到達するには、メタデータでかつIDを持つようになるのではと思います。

そしてそれらはサービスとして実行するようになるでしょう。
サービスは、Single source of truthになりうるGit、SQL、またはCosmosDBに基づいて、デバイスのコンフィグレーションを定義し、これを使用して、Incident Management Platformなどの多くのアップストリームシステムにリンクすることができるでしょう。
同じように私たちはそれを私たちのチケット管理システムにリンクさせることができます。例えば私たちはそれを私たちのIPアドレス管理データベースにリンクさせることができ、実際にこれらすべての情報を引き出してNW機器の自身に対するクロスチェックを検証することができるようになります。

f:id:canalroy:20190827205501p:plain

そして、最後にEvent Based Automationです。
これは本当に大きなものです。

おそらく今後数年の間にやってきて、これにシフトしていくことになるでしょう。
私達は今日早くにRed Hatと会い、彼らがこの分野でAnsibleでしていることについて議論してきています。
彼らもまたこのEvent Based Automationでネットワーク自動化の文脈で”If This Then That”のような自動化をどのように始めるのか?にフォーカスしていています。

高度なテレメトリをトリガーするためのイベントをもつ必要があるという考えがあります。
出て行き、デバイスからより多くのテレメトリを収集し始めたり、さらにアドバンスなテレメトリを利用して送付を有効にしたり無効にしたりする。
実際、ネットワークモデリングについて話すときには、ネットワークモデリングはプッシュとプルの両方で行われるため、コンフィグレーションをデバイスから中央のコレクタにプル、プッシュすることができます。
高度なジオメトリを使ってシステムに常に過剰な電力を供給するのではなく、必要に応じてより高度なテレメトリをそのコレクタに送信できるようにすることができます。

もちろん自動化の文脈も登場します。現在も少しやってますが、システムで何かが起こった際に別のシステムで実際にアクションをトリガーするようなものです。
ハイブリッドクラウドのような考えでは、ネットワーク自動化システムの一部ではない別の自動化システムに対して通知したいような場合もあるでしょう。 Azure Automationかもしれませんし、他のタイプの自動化システムかもしれませんが、実際にそれをトリガーするか、ある時点で別のグループを別のTower環境を呼び出して何かを実行させたりするかもしれません。

最後は分析(Analytics)です。
どんなところでイベントが発生するのか、どのように対処するのか。イベントが発生した時にどのような影響があるオペレーションを決定するのか。
ああ、このイベントはみたことがあるぞ。このイベントが10分後に発生した時にはデバイスがクラッシュするのでいますぐ何かをやっておく必要がある。そんな感じです。

私のプレゼンテーションはこれで全ておしまいです。 少し早いかもしれませんが、最後にこのメモで終わりたいと思います。

f:id:canalroy:20190827205506p:plain

これは、昨日の基調講演

www.youtube.com

でも多く取り上げられていたものです。
私たちの会社の使命は、この地球上で多くの人たちがより多くの物事を達成できるようになることです。
昨日、ステージ上にいるサティアを私たちは一緒に見ました。
私はこのミッションステートメントを本当に信じています。

今、私はMicrosoftで働くことを本当に誇りに思っています。私たちは素晴らしいことをやっているんだ!と感じているのです。
Linuxカンファレンスで、まさかMicrosoftがステージに立つときがくるとは夢にも思っていませんでした。 でも、今私はここに立っています。

しばらく、ブースにいますので何か質問があればこちらに来てください。Swagと、ペンギンが書かれたクールなMicrosoft Tシャツを持って待ってます。 

f:id:canalroy:20190827205518p:plain

これで、私のプレゼンを終わります。   

今日はどうもありがとうございました。

* 各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。