Ansibleクックブックの著者が語る「ネットワーク自動化を成功させる最大の鍵」

今年3月に発売された「Ansibleクックブック」。この書籍の執筆に参加した弊社エンジニア3名に、Ansibleによるネットワーク自動化の難しさや導入のコツ、そしてネットワーク自動化を成功させる上での「最大の鍵」について語ってもらいました。

参加者
三枝浩太
プロフェッショナル職エンジニア
官公庁向けネットワークの設計、構築業務を経験。2017年に株式会社エーピーコミュニケーションズへ入社。入社後Pythonを利用したネットワーク運用自動化に興味を持ち学習をしていた際にAnsibleと出会う。趣味はNikeのスニーカー蒐集。

宮﨑啓史
シニアプロフェッショナル職エンジニア
メールやwebのインフラ構築やバックエンド開発、組み込みアプリ開発などの経験を経て、2020年に株式会社エーピーコミュニケーションズへ入社。現在はAnsibleを使ったネットワーク自動化を推進する部署に所属。朝晩の散歩が日課。

横地晃
テクニカルエバンジェリスト
インフラ構築からシステム開発まで行う、ITなんでも屋的なポジションでエンジニアキャリアをスタート。ネットワーク運用自動化の支援業務や自動化トレーニングの講師を担当している。他、Ansibleユーザー会などのコミュニティへの参加や運営、技術ブログの投稿がライフワーク。

ネットワークはノードの集合体、１機器で完結しないが故の難しさがある
ネットワーク自動化には、高いハードルを超えるだけの価値がある
まずは定型作業から。自動化を前提とした作業の組み換えも効果的
自動化成功の鍵は「中の人たちの"自律性"」

ネットワークはノードの集合体、１機器で完結しないが故の難しさがある

-ネットワーク自動化の「便利さ」は色々なところで語られているので、今回はあえて「難しさ」からお聞きしたいと思います

宮﨑：そうですね……　Ansibleを用いて自動化すると、Playbookを書き、そのPlaybookが正しく処理を行うかテストしてから本番投入となります。これまでは手順書を作って構築をしていたところから、コード（Playbook）を書いたりテストをしたりと構築プロセスがガラッと変わるので、それは自動化導入の最初のハードルになりますよね。

横地：Playbookに加えて、IPアドレスやインターフェースの番号みたいな作業ごとに異なるパラメーターを、Ansibleが読み取れる形式で用意しておく必要があるので、そこで難色を示されることはありますね。スペース1個多いとか、カンマ1個少ないとかだけでAnsibleは読み取れないので。

三枝：ネットワークっていう観点でいうと、作業前後の確認がすごく多いので、設定変更の部分は自動化ですぐ終わるのに、前後の確認に手間がかかって、全体フローとして結構時間がかかっちゃうっていう場合があるのも特徴な気がします。

宮﨑：サーバ側では初期状態チェックした記憶があまりないですね。Playbookで書いた状態にするっていう動きが基本なので。作業前の状態がどうであれ最終的にはPlaybookに書いたとおりになれば良しだし、既にPlaybookに書いた状態でPlaybookを実行しても結局そのまんまだから、あんまり初期状態にはこだわらなかったですね。

横地：ネットワークの場合、設定をAからBに変えるときに「あらかじめAになっていること」っていう確認をしてから次の作業に進むんですよね。ルーティングがないこと、ネクストホップがどっちであること、インターフェースの状態が何であることって。そこで違っていたら作業は中断して、設定を元に戻して作業をリスケするので、このスタイルの手順はAnsibleの特徴である冪等性（ある操作を何度実行しても常に結果が同じになる性質）と相性が悪いんです。

三枝：ネットワークは色々なノードの集合体だからなんですかね。ある機器に設定を入れた後に別の機器が想定外の状態になっていることに気づいたとして、それぞれの作業前の状態を知らないと、それがこの作業の影響なのかが分からない。こういうケースも実際にあるので。
あとは、切り戻しを考えるとかなり難しくなるなっていうのは感じていますね。切り戻しは対象機器の状態とかネットワーク全体の状態とかいろいろな観点があって、作業フローがすごく複雑になってしまうのでここまでを含めて自動化するのはかなり難しい。

ｰ手順書の場合は切り戻し手順も一緒に作りますが、自動化する場合はどうするんですか？

横地：切り戻しをすべて自動化するのはなかなか難しいので、切り戻し用のConfig生成まで自動化しておいて実行自体は人力でやるよう運用方法に落とし込んだりします。

三枝：「こういう状態からこうなったらこのコマンドを入れて、この状態だったら戻す」みたいな手順が完璧にできているのであれば、切り戻しも含めた自動化はできるかも知れないけど、「作業者が"いい感じ"に判断して戻す」っていうものは厳しいですよね。いい感じって何？ってなっちゃうから。
切り戻しが自動化できないと、その部分だけ手順書が残り続けてしまうので、そこは悩ましいところです。

ネットワーク自動化には、高いハードルを超えるだけの価値がある

宮﨑：確かに導入ハードルが高かったり一部手順書が残ったりはしますが、それでも従来のように二人でダブルチェックしながら手順書に従ってコマンドを1つずつ入れていくなんていう作業が、コマンド1つでシュッとできるっていう魅力は大きいですよね。

横地：そうですね。今まで手動で一行一行慎重にやっていたところを、コマンド一発でバーンと処理が走ってくれるというのは単純に面白いですね。気持ちがいい。

三枝：これまでお話したような理由もあって、「ネットワークは自動化できない、しにくい」っていうイメージが強いので、それが自動化できたときは感動しますよね。

まずは定型作業から。自動化を前提とした作業の組み換えも効果的

ｰこの辺も踏まえて、ネットワーク自動化のコツってありますか？

宮﨑：定型作業から自動化するとか。Ansibleに限らないですけど、作業を効率化するときはやっぱり定型作業が手を付けやすいですよね。

三枝：showコマンドで情報を取るとか、Configのバックアップを取るとか、そういう低リスクでできる作業から始めるのがいいんじゃないですかね。切り戻し作業のような「機器の状態がAだったらこうする、Bだったらこうする」っていう複雑なフロー（条件分岐）になると、Playbookの造りが難しくなって誰も改修できない塩漬けPlaybookになりがちなので、まずは単純な作業から始めるのがいいと思いますね。

横地：今ある作業を自動化する前提で組み替える、というのもありますね。自動化したらいらなくなるコマンドを削除したり、順番を入れ替えたり。あとは、どうしても人の判断を挟まなきゃいけない場合、「自動化→人の確認→自動化→人の確認」みたいに、人と機械の間を行ったり来たりするのは結構ストレスフルだと思うので、人の確認が1回で済むようにするとか、なるべく往復が少なくなるように手順を組み替えるのがいいと思います。

自動化成功の鍵は「中の人たちの"自律性"」

ｰここまでのお話を聞いていると、NW自動化を始めるならやっぱりプロに任せるのがいいのかな、って思うのですが……

三枝：プロに頼むのもいいと思うんですけど、丸投げではなく、実際にそれを使う人たちが積極的に関わって行ったほうがいいと思います。チームの中にある暗黙知というか、隠れた手順って少なくなくて、そういうのって外の人から見えないんですよね。なので、委託先が作ったPlaybookをテストする段階で「あれ？このコマンドないの？」ってなったり。

横地：自動化による恩恵を受けるには、設定変更（コマンド投入）だけではなく、むしろそれ以外の部分、それこそ作業前後の確認とか、作業にあたっての承認とか、似て非なるような手順の標準化・パターン化とか、そういうことに向き合わないとうまくいかないんです。そして、それを知っているのって中の人だけなんですよね。暗黙の前提になっていて外からヒアリングしても中々顕在化しなかったりするので、中の人たちが自律性というか、自動化するぞ！っていう強力な勢いみたいなものを持ち続けることは必要だと思います。

ｰこれまでに見た良い事例はありますか？

三枝：以前参入していたお客様先でネットワーク自動化の導入をお手伝いさせて頂いたんですけど、そちらでは自動化に興味を持っているメンバーを募って取り組みを始められていました。自動化やAnsibleに関しては初学者が多く最初は苦労されてましたが、「こんなふうに動くんだ、こんなに早く作業が終わるんだ、自分たちでできるんだ」っていうのを実感したことで、自動化の範囲を自分たちで広げられていました。

横地：あるお客様からは、Playbookレビューのときに「中身の説明をしてほしい」というリクエストが有りました。あまりないことだったので、「理解したいという欲が出てきたんだな」と印象に残りました。その後、追加のPlaybook作成をご依頼いただいたのですが、契約上お受けできなかったんですよね。ですが、最終的には「自分たちで作ってみるのでアドバイスやレビューをして欲しい」という方向になったので、「理解したい」という欲が「自分たちでもやれるかも」という自信に変わっていったのかなって思いました。

宮﨑：すべてを一緒に作るところまで行かなくても、Playbookを読めるくらいのトレーニングを受けるとか、一部のPlaybookだけ一緒に作るとか、そういう関わり方から始めるのでも良いと思います。