前回までのおさらい
自動化の判断を「自動化しない」側に傾けているもののうち、コスト(➡️第4〜5回)と効果(➡️第6回)を見てきました。今回は3つ目の要素、リスクです。自動化に踏み出すには、安全に試せる場所が必要です。しかしNWではそれがなかなか作れません。
図1: 連載マップ
この回の要点
- 自動化は良い結果も悪い結果も増幅するので、事前に安全に試せる場所が必要です。
- しかし、NWは本番と完全に同じ環境は作れず、どこまで確かめれば十分かの基準もはっきりしません。
- 失敗したときの影響が広いNWでは、このリスクが自動化をためらわせます。
困る場面
ある作業を自動化するスクリプトができあがり、本番に適用する前に検証環境で試すことになりました。ところが、検証環境には本番と同じ機種がそろっていません。一部は別の機種で代用し、一部は仮想ルータで代用します。本番のコンフィグは、機材の違いによりそのままでは検証機器に入らないので、インタフェース名など変わる部分を書き換え、検証機器で使えない機能の設定を削ります。
検証環境では、スクリプトは問題なく動きました。しかし、本番に適用する段になっても「これで大丈夫だ」と確信をもって言い切れません。書き換えたコンフィグで試したことは、本番でも同じ結果になるのか? 本番環境の構成パターン・そのためのパラメータ設定に見落としはないのか? 代用した機器のふるまいは本番の機器と同じなのか? ……最終的に、本番作業は数人で状況を確認しながら、段階的にスクリプトを動かしました。進めてよいかどうかの判断は結局、担当者の経験に頼ることになりました。
難しいのは、検証環境を作ることだけではありません。そこで確認できたことと、本番ではまだ確かめられていないことの切り分けを考える必要があります。
なぜ砂場が要るのか
経験的に、NWに限らず、自動化は「安全に試せる環境」いわゆる砂場(sandbox)がないと導入が進みにくいものです。
自動化は増幅器です。正しい処理を自動化すれば正しい結果が速く大量に得られます。一方、間違った処理を自動化すれば、間違いが速く大量に広がります。人が1台ずつ作業していれば途中で気づけた間違いも、自動化すると、止める仕組みがなければ短時間で多くの機器に広がります。
自動化の仕組みが誤りを増幅した事例を(NWに限らず)いくつか挙げます。
| 事例 | 何が? | どこで? | いつ? | URL |
|---|---|---|---|---|
| 自動化ツールによる操作範囲の誤り | 担当者がメンテナンス用ツールに誤った入力を与えた結果、意図した以上のサーバが停止 | AWS | 2017 | 米国東部（バージニア北部、US-EAST-1）リージョンで発生した Amazon S3 サービス障害について |
| 自動配布による障害の高速伝播 | 問題のあるWAFルールが世界中に展開されたことで、CPU使用率が急上昇し、サービス障害が発生…自動配布の仕組みによって問題が短時間で世界中に拡大 | Cloudflare | 2019 | Details of the Cloudflare outage on July 2, 2019 | Cloudflare Blog |
| 誤ったコマンドと、それを止められなかった監査ツールによる大規模NW障害 | バックボーンネットワークのメンテナンスコマンドが、意図せずデータセンター間の接続を切断 + 本来そのようなコマンドを阻止するはずだった監査ツールにもバグが存在 | Facebook (Meta) | 2021 | More details about the October 4 outage - Engineering at Meta |
NWは多くのシステムが共有するインフラ(➡️第2回)なので、障害の影響範囲が広く、最悪の場合は現地での対応が必要になります。影響が大きいからこそ、本番に適用する前に確かめたいと思うはずです。ところがNWでは本番と同じ環境を作ること自体が困難です。なお➡️第3回では「NW全体の状態をデータとして取り出せない」問題を扱いました。今回扱うのは、その結果として「本番環境は完全には再現できない」問題です。
物理で作ると高い
本番環境と同じふるまいを確かめる最も確実な方法は、本番環境と同じ機材をそろえて同じ構成を作ることです。しかし、これには大きなコストがかかります。
同一性と規模のトレードオフ: NWのふるまいは系全体で決まるので、1台だけ本番と同じ機材を用意しても、複数の機器の連携で決まるふるまいは確かめられません。本番環境に近い状態を再現するには複数のノードが必要です。ところが、本番環境と同じ機材をそろえるほどノードを増やすコストは跳ね上がります。本番環境と同じ機材を少しそろえるか、別の(安い)機材でノード数を確保するか、というトレードオフになります。
固定で維持できない: 本番環境と同じ規模の検証環境を常に維持するのは、費用の面でも手間の面でも現実的ではありません。多くの場合、必要になるたびに限られた機材で「本番に近い」環境を組み立てることになります。組み立てるたびに本番とは違う部分が発生します。
本番のコンフィグがそのまま入らない: 機材や規模が違えば、本番のコンフィグはそのままでは使えません。インタフェース名を変え、使えない機能を削り、足りない機器の分を調整する。その調整のたびに、何かしら「本番とは違うもの」を試していることになります。
外部NWとのインタラクションは再現できない: 管理外の外部NWとの接続や実際に流れているトラフィックの影響は、そもそも正確に把握することも難しく、検証環境で再現するのは困難です。しかし実際には、本番NWの状況・状態はそうした外部とのやり取りにも左右されています(とくにISPなどで外部NWとBGPなどを使った情報交換をするようなケース)。
仮想で作ると別物になる
物理で作ると高いのであれば、仮想で作ればよいのではという話になります。仮想ルータやコンテナ版のNW OSを使えば、多数のノードを(物理機器よりは)安く用意できます。実際、仮想ノードベースの検証環境はNW検証の選択肢として広がっています。ただし、ここにも限界があります。
再現できるのはソフトウェアの部分
仮想ノードで確かめられるのは、主に設定や制御プレーン(ルーティングプロトコルなど)のふるまいです。ASIC での転送処理、物理ポート、性能やタイミングのように、ハードウェアに依存する部分は再現できません。検証用のイメージを用意している製品もありますが、それも「ソフトウェアの部分を確かめる」ためのものです。
さらに、➡️第4回で見たように、インタフェース名にはハードウェアの構成が反映されています。仮想ノードでは名前の体系が変わるので、本番のどの名前が検証環境のどの名前にあたるのかを読み替えて管理する必要があります。
物理の操作や構築手順は表しにくい
一般的な仮想化基盤上のシステムは、仮想ノードの構成を変更せずに作り直す(immutableな)使い方が基本です。そのため、稼働中のノードにインタフェースを付け外しするような、NW固有の操作を支える機能は弱いか、そもそも用意されていません。
リンク断や再起動はまだしも、仮想ノード稼働中にポートを増やす・減らすといった操作のようなNW製品固有の操作再現は厄介です。仮想ノードは通常、リソース定義から起動するので、NW増設作業を模擬するために(起動済みの)ノードにあとからポートを足してリンクをつなぎ変える…といった操作をそのままの形では実現できないことがあります。また他の例として、単体で起動してからクラスタの設定をして再起動するという手順が必要なファイアウォールの場合、環境起動を自動化したければこうした構成手順は個別に作り込む必要があります。
図2: 物理操作の再現が難しい例。仮想環境はトポロジの定義から起動するのが基本なので、途中で設定変更や再起動を挟む手順は表しにくい。
厳密なシミュレータは車輪の再発明になりかねない
仮想ノードではなく、計算機の上でNWのふるまいをシミュレーションする方法もあります。ただ、プロトコルの仕様や機器の動作を厳密に再現しようとすると、結局はルータやスイッチそのものを再実装することになります。それなら仮想ルータを使えばよい、という話に戻ってしまいかねません。そもそも、どこまで厳密なシミュレータが必要なのか、という問いも残ります。
どこまで確認できれば十分か
物理でも仮想でも本番と完全に同じ環境は作れません。そうなると「何をもって本番とほぼ同じことが確認できたと判断するか」が問題になります。ここには、かなり広いグレーゾーンがあります。
- 同じハードと OS を使えば大丈夫か: 1台の機器としては同じでも、隣接する機器との組み合わせで起きる問題は残ります。
- 仮想マシンに置き換えたものは信用できるか: ハードウェアやドライバに依存する部分は見えなくなります。性能の問題や、ハードウェアに依存する機能(機器固有のクラスタ機能など)は確認できません。
- 管理外の対向はどう作るか: 接続先が自分たちの管理外の機器であれば中身が見えません。対向を模した機材や仮のNWを、想定に基づいて用意することになります。対向のふるまいは推測で作るしかありません。
- 操作は同じか: 機器が違えば、コマンドやコマンドの実行結果として返ってくる値も同じとは限りません。自動化の処理が、検証環境と本番で同じように動く強い保証はありません。
図3: 検証の手段と、本番との近さ(模式図)。規模を取れば同一性が下がり、同一性を取れば規模が取れません。
確認したいことは機能だけではない
検証環境で確認したいことは、NW機器の機能やふるまいだけではありません。作業で使う操作コマンドや作業手順など、人の動き方も確認の対象です。
本番環境の作業では、コマンドを1つ間違えたり、操作の順序を取り違えたりするだけで障害につながる恐れがあります。たとえば、トラフィックを迂回させる前に対象のリンクを止めてしまうといった間違いです。そのため検証環境では、NWの機能やふるまいの確認とあわせて次のようなことも確かめます。
- 投入するコマンドやコンフィグに誤りがないか
- 作業の前後で、どのコマンド出力のどこを見れば正常と判断できるか
- 操作の順序や、問題が起きたときの切り戻し手順が正しいか(➡️第6回)
いわば本番作業の予行演習です。ところが、ここにも先ほどの「操作は同じか」のグレーゾーンが入り込みます。検証環境の機器が本番と違えば、インタフェース名もコマンドもその出力も変わります。検証環境で練習した作業手順は、本番で実行する手順そのものではなく、読み替えた「よく似た手順」です。手順を確かめたつもりでも、読み替えた部分で間違える余地は残ります。
自動化しても、確かめる対象がなくなるわけではありません。人の動き方がスクリプトの処理に置き換わるだけです。どのコマンドをどの順序で投入し、出力のどこを見て次に進むかを判断する。人が経験的に見ていた確認ポイントを、今度はスクリプトがコマンド出力を解析して判断します(➡️第4回)。検証環境で確かめる対象は、人の作業手順からスクリプトの処理に移ります。
検証そのものも人に頼っている
もうひとつ見落とされがちなのが、検証の作業そのものも人に大きく依存しているという点です。
ソフトウェア開発では、コードを変更のたびに自動でテストし、問題があればすぐにわかる仕組み(CI)が当たり前になっています。NWでも同じことができれば、自動化の処理を変更するたびに安心して確かめられそうです。
ところが、NWの検証環境はリソースの制約上、都度設計して組み立てるものが多く、いつでも同じ状態で使えるとは限りません。検証の手順も「この機器で経路表を見て、あの機器でセッションの状態を見て」という、人の確認を前提にしたものになりがちです。何をもって合格とするかの基準がはっきりしないので、確認の結果を判断するのも人になります。そうなると検証環境を組み立てるノウハウも、検証の手順も、合格の判断も、人に集まります。そうしたナレッジを持っている人が忙しければ検証は後回しになり、その人がいなくなれば検証の品質は下がります。自動化の処理を安全に変更し続けるための土台自体が人に依存してしまいます。
検証環境を仮想拡張していくと「同じものだから大丈夫」とは言えなくなる
何をもって検証内容を合格と判断するかにはグレーゾーンがあります。それでも、これまで本番作業を乗り切れてきたのはなぜでしょうか? 明確な合格基準がなくてもやれているのは、「同じ機材・OS を使っているから同じように動くはずだ」という前提に頼っているからです。だからこそ、本番と同じものをそろえた検証作業が残っています。
そして正直に言えば、その裏には「いまある環境でやれるだけのことはやったからOKとしよう」という暗黙の基準もあるのではないでしょうか。1
しかし、「同じものを使っているから大丈夫」と言えるのは、物理の検証環境で本番機器に近い機材・OS を使えるときだけです2。検証環境で本番の物理ノードを仮想ノードで再現(エミュレーション)したり、計算機の中で再現(シミュレーション)したりすると、「同じものを使っているからOK」という根拠は成立しなくなります。では、どこまで何ができていれば「ここで検証したことを本番で実施しても問題ない」と言えるのでしょうか?
検証の目標をどう置くか
検証環境は「本番と同じものを作る」ことを目標にすると永久に終わりません。物理でそろえるほどコストは上がり、仮想で代用すれば同じものではなくなります。
代わりに、「この用途ではどこまで再現できれば十分か」を作業ごとに決めてみてください。すべての作業に本番同等の検証が必要なわけではありません。論理的な設定の正しさを確かめたいのか、機器の性能を確かめたいのか、障害時の切り替わりを確かめたいのか、作業手順そのものを確かめたいのか……。目的によって必要な再現レベルは変わってきます。その設計があって初めて検証にどの程度のコストをかけるべきかが判断できるはずです。
コスト、効果、リスクのすべてが「自動化しない」側に傾いている理由を見てきました。最終回の次回は、全体を振り返り、この構造がどんな悪循環を生んでいるか、そしてどこでそれを断てるのかを考えます。