【元記事をASCII.jpで読む】

 いま、企業のネットワークエンジニアは大忙しだ。

 社内ネットワークに接続される機器は年々多様化しており、さらにはIoTという大波も迫りつつある。社員はと言うと、世界のどこにいても社内にいるのと同じように業務アプリにアクセスできる環境を要求してくる。いつの間にかマルチクラウド利用も許容され、その変化にも速やかに対応できるITインフラ作りが必須となった。これらすべてがネットワークによって支えられており、だからこそ担当者の負担と責任は大きい。

 それどころか、これまでのように手作業でネットワーク機器の設定をしていては、拡大する要求への対応が間に合わないのが実態だろう。理想的には、ネットワークエンジニア自身がAPIを使いこなし、煩雑なネットワーク機器の設定や運用をコーディングで自動化することで運用付加を減らせればよい。実際、シスコシステムズも、開発者コミュニティのDevNetを通じて“ネットワークプログラマー”になるためのセミナーや、自動化のためのコードを共有するポータルなどを提供し始めている。

 しかし、本当にネットワークエンジニアは“ネットワークプログラマー”になれるのか。ネットワークの自動化は本当に簡単なのだろうか。

 「正直なところ、その道のりは長いし容易ではない。何を自動化したいのか明確にし、きちんとプロセスを策定、ドキュメント化して、小さな成功を地道に繰り返す。近道はない。それでも時代はその方向へと流れており、少しずつでも取り組むべき課題だ」。ネットワーク自動化のコンサルティングを提供するNetwork to Codeの創設者であるジェイソン・エデルマン氏は、米国で開催された「Cisco Live! 2018」のパネルディスカッションでそう断言した。

 このパネルディスカッションには、これからコーディングを学び、ネットワーク自動化に取り組む人たちの参考になればと、フランスの大手銀行であるソシエテ・ジェネラル、大手ヘッジファンドのブリッジウォーター・アソシエイツのネットワークエンジニアも登壇。両社におけるネットワーク自動化の取り組みを、生々しい経験談をまじえながら披露した。

ソシエテ・ジェネラル:インターンや外部の知見を真摯に学ぶ姿勢

 フランスのメガバンクであるソシエテ・ジェネラルのリチャード・オルソン氏は、2020年までにインフラの8割をプライベートクラウドおよびパブリッククラウドに移行することが目標と説明。それに伴い、API経由からインフラサービスを統合管理する際に自動化を取り入れようと取り組んでいると説明した。

 同社におけるネットワーク自動化の取り組みが始まったのは2016年のことだ。当時はまだbashやPerlで書かれたスクリプトをメインに使っていた。同社のネットワークアーキテクト、ビッシュ・リーシャンセム氏は、「社内のストレージ系エンジニアが『クラウド』やら『VM』『コンテナ』『API』といった謎の言葉を発していて、『一体何の話をしてるんだ?』と思っていた」と振り返る。

 自動化を本格化させるために、そんな“謎用語”だけでなくPythonやAnsibleといった言語やツールも学ばなければならなくなった。技術ブログやオンラインの学習サイトを通じて自学自習を始めてみたものの、まったくの手探り状態で悩みは尽きなかった。2016年秋に「AnsibleFest」参加、そこで自動化の先駆者であるエデルマン氏に出会い悩みを相談、支援を依頼したという。

 ソシエテ・ジェネラルでは2017年中旬にネットワークサービスのAPI開発を決定した。使用言語はPythonだ。しかし、どこからどう手をつければ良いのかわからない。そのときリーシャンセム氏は、前年の夏に来社したインターンのことを思い出した。「インターン生の彼はDjangoフレームワークを使ってWebアプリを開発していた。わたしが知らないツールで、彼から学んだことは大きかった」。

 それを切り口に、リーシャンセム氏はPythonの開発フレームワークを調査していった。自社に最適なものを検討した結果、軽量で覚えやすいFlaskを採用することに決めた。その選択は正解で、ロードバランサの「NetScaler」やセキュリティ製品の「FortiManager」用のAnsibleモジュールをカスタム開発することもできた。

 2017年の冬には、社内でITインフラの自動化に関する集中合宿を開催した。「ただうわべだけを学んでツールを導入し、自動化を理解した気になるのは危険だ」。そう感じたリーシャンセム氏は、サーバやクラウドなど他領域で自動化に取り組んできた社員と意見交換を実施、助言をもらいながら理解を深めていった。

 「詳しくない分野だからこそ、自分だけで頑張ろうとせず、知見のある人に頼ることをためらわないでほしい」。新しいことを素早く吸収し、自分のものにするためのポイントとして、リーシャンセム氏は会場の参加者にこう呼びかける。

 同社では現在、ロードバランサをサービスとして提供できる仕組みを構築、問題なく稼働しているという。今後はテストの効率化に向けて、CI/CD(継続的インテグレーション/継続的デリバリー)の導入検討を進めたいと展望を明かした。

ブリッジウォーター:DMZの再編で大失敗、手作業に限界を感じ自動化に着手

 「セキュリティ上の大失態」で自動化の必要性を痛感したと語ったのは、ブリッジウォーター・アソシエイツのシニアネットワークエンジニア、マイク・ケリー氏だ。

 世界最大手のヘッジファンドである同社では2016年秋、DMZインフラの刷新を決定した。ネットワーク機器のリプレースと追加購入などを通じて、最終的にはファイアウォール32台、Catalyst 3560スイッチ16台、Nexus 7000シリーズ24台など、OSバージョンの異なるデバイス100台以上で構成される環境を構築することとなった。

 「作業期間は6~9カ月。そこにエンジニア2名と運用スタッフ2名が割り当てられた」(ケリー氏)

 作業の流れはシンプルだった。まず、エンジニアが設定の標準化を行ってテンプレートに落とし込む。「『テンプレート』と言っても、実際は手順を箇条書きしたWikiページやメールのやりとりをまとめただけのものだったけどね」とケリー氏は笑う。

 続いて運用スタッフが、テンプレート情報を論理構成図と組み合わせて設定を記述し、これを該当デバイスにコピー&ペーストしていく。ポリシーに沿って記述されているかどうかは、ファイルやフォルダの内容を比較するツール「Beyond Compare」を使ってチェック。必要に応じてすべて手作業で追加/変更し、テンプレートに最新情報を反映させて管理した。

 作業は何の問題もなく進んでいた。プロジェクト期間が「3カ月」に短縮されるまでは。

 「作業期間が大幅に短縮され、金銭的に解決しようとしたが、予算はデバイスの購入などでかなり使ってしまっていた。会計担当に相談しようとしたら、休暇を取っていて連絡がつかなかった」

 ケリー氏たちはエンジニアを14人かき集めて、人海戦術で乗り切ろうとした。しかし、迫るタイムリミットに焦るあまり、当初は守られていた作業手順が次第に崩れていった。設定の変更や追加はネットワーク機器上で直接行われるようになり、テンプレートは更新されず、実施した作業内容はメールで事後報告。そのメールを見て、各人がそれぞれ独自の判断で設定を調整するようになった。

 その結果、ネットワーク機器には「理由のわからない設定」が数多く適用され、一応動きはするものの一元管理されていない、不安要素しかないようなDMZが出来上がってしまった。

 DMZの一部が稼働してから1週間ほど経ったある日、ケリー氏はセキュリティ部門の上長に呼び出され「一体何をしたんだ!」と問い詰められた。インターネットスイッチの一部で、承認されていないログインが大量発生しているのだという。

 あわてて調べてみると、該当するスイッチでACL(アクセス制御リスト)が設定されておらず、インターネット全体から総当たり攻撃(ブルートフォースアタック)が仕掛けられている状態であることが判明した。結局は、セキュリティ侵害が発生していないか、情報漏洩は起きていないかと、大がかりなインシデントレスポンスを行う事態にまで発展してしまった。

 「思い出すだけで辛い」と漏らすケリー氏は、管理しきれない手作業の欠点を痛感。新しい拠点のネットワーク構築を控えるなかで、絶対に同じ轍を踏むまいと自動化に乗り出した。

 自動化に関する調査を進めるなかで、同氏もNetwork to Codeに行き当たり、コミュニティの助言を仰ぎながら少しずつ自動化スキルを習得。現在はWikiページやメールをまとめた“テンプレート”を廃止し、Python用テンプレートエンジンのJinjaを使って、変更の頻度が低いものをテンプレート化している。そのほか、デバイスやホストごとに個別作成した設定もあるが、設定全体はAnsibleのPlaybookで管理し、設定変更を行う際には必ずソースコードリポジトリ経由で行うよう徹底している。さらに、設定変更を定期的に自動監視し、問題があればすぐにレポートが上がるようにしている。

 これからの目標についてケリー氏は、「今年はファイアウォールやロードバランサなど、変更が常時発生するデバイスで設定適用の自動化を実現したい」と語った。また、セルフサービス型フロントエンドの開発や、CI/CDの統合なども進めたいという。とても意欲的だ。

* * *

 最後に、Network to Codeのエデルマン氏はこうまとめた。

 「ネットワーク業界で起きている変化を受け入れず、自動化を検討しないまま何もしないエンジニアは、いずれ“自動化される”側になってしまうだろう。皆さんはぜひ自動化する側となって、変革によるメリットを十分に享受してほしい」(エデルマン氏)

「ネットワーク自動化」2つの事例、地味でつらいが見返りも