前回のおさらい
NWの自動化が、ノード単位の設定投入より先に進まないのは、コスト・効果・リスクが「自動化しない」側に傾いているからでした。今回からは、その傾きを生んでいる前提を見ていきます。最初は、NWという対象そのものの性質です。
図1: 連載マップ
この回の要点
- NWは機器同士が連携して系全体で状態を持ち、いくつもの層が重なっています。機器を1台ずつ見るだけでは全体の動きがわかりません。
- これは技術の選び方や努力では消えない性質です。
- この性質が、後の回で扱う「機械には難しい判断」「足りない情報」「検証の難しさ」の出発点になっています。
困る場面
冗長構成を組んだ2台のルータのうち、片方をメンテナンスのために止める作業を考えてみます。手順書にすると、「トラフィックをもう片方に寄せる → 寄ったことを確認する → 止める」という単純な流れに見えます。では、実際に自動化することを考えましょう。いまどちらのノードが active? トラフィックを寄せるにはVRRPの設定を変える? それともルーティングのメトリックを変える必要がある? 対向側からはどう見えている? ……人は構成図と経験で判断しますが、自動化するには、こうした判断の材料と条件を機械が扱える形にする必要があります。
この難しさの根っこには、NWという対象の性質があります。
系全体が状態を持つ
機器が勝手に状態を変える
NW機器は、ルーティングプロトコルや冗長化プロトコルを通じて互いに連携し、隣接するノードの状態変化に合わせて自律的に自分の状態を変えていきます。これはNWの強みでもあります。リンクが切れれば勝手に別の経路に切り替わり、機器が落ちれば待機系が引き継ぎます。人の指示を待たずに系全体として通信を維持してくれます。
一方で、自動化の立場から見ると、これは「操作する前の状態が決まっていない」ことを意味します。
- どちらの機器が active になるかは、起動のタイミングや優先度の設定、直前の障害履歴によって決まります。
- 変更を入れてから、系全体が落ち着く(状態が収束する)までには時間がかかります。その間の状態は、タイミング次第で変わります。
- 自分たちが管理していない外部のNW(上位のISPや接続先の組織のNW)の変化によって、自分たちのNWの状態が変わることもあります。
その結果、同じ目的の作業でも、手順は「いまどうなっているか」によって変わります。障害対応はその典型で、何が起きているかを把握してから、何をするか決める必要があります。
「正しく終わった」の判定も難しい
状態が系全体で決まることは、作業の前だけでなく作業の後にも影響してきます。
単体サーバの限定的な設定変更であれば、「設定ファイルが意図どおりに書き換わったか」「サービスが起動しているか」を確かめれば、作業が正しく終わったかをおおむね判定できます。NWでは、個々の機器の設定が意図どおりに入っても、それだけで作業が正しく終わったとは言えません。変更を受けて経路が再計算され、冗長のペアが状態を合わせ、系全体の状態変化が落ち着いた後に、狙った通信が狙った経路を通っているかまで見て、初めて「正しく終わった」と言えます。
人が作業する場合、作業後にルーティングテーブルやインタフェースの状態などを確認し、知識・経験をもとにいつもの状況に落ち着いたと判断しています。この「いつもどおり」を機械に判定させるには、落ち着くまでどれくらい待てばよいのか、どの状態になっていれば正常なのかを、あらかじめ定義しておく必要がありますが、その定義は機器の組み合わせや構成によって変わります。
マイクロサービスとの違い
「状態を持つ分散システムなら、マイクロサービスだって同じでは?」と思うかもしれません。多数のコンポーネントが連携して動く点は同じです。大きな違いは、全体をまとめて管理する共通の仕組みがあるかどうかです。
Kubernetes には、Pod などの共通の管理対象と、それを扱う API があります。配置や再起動、あるべき状態への収束はオーケストレータに任せられます。NWにも SDN コントローラのように一定の範囲をまとめて管理する仕組みはありますが、ベンダや層をまたいで広く使われている共通の仕組みはなく、機器ごとに扱える設定・状態・操作の範囲も違います。しかもNWはITシステムの土台そのものなので、その下に頼れる仕組みもありません。系全体の状態をとらえて収束させたければ、その仕組みはNWの外に別途用意することになります。
層が重なり、入れ子になり、横断する
構成図を重ね合わせないと全体が見えない
NWの構造をひとつの図で表すのは困難です。物理的な接続、L2 のセグメント、L3 のルーティング、その上の overlay…。さらに、拠点やエリアといった地理的な単位でも分割されます。運用をしている人は、レイヤ別・地域別に分かれた何枚もの構成図を頭の中で重ね合わせて「この通信は全体としてどう流れるか」を組み立てているはずです。
層の中にも、さらに層があります。たとえば物理層(L1)でも、1本のポートを複数に分けるブレイクアウトケーブルや、1本のファイバに複数の波長を載せる波長多重があり、「目に見えるケーブル」と「機器が認識するリンク」は必ずしも一致しません。overlay の中にさらに overlay が作られることもありますし、複数のシグナリングプロトコルが連携してひとつの通信を成り立たせていることもあります。
図2: 層の重ね合わせ。人は複数の構成図を頭の中で重ねて全体の動きを組み立てている
「1台に見える」と「2台に見える」を使い分けている
層が重なると、同じものが観点によって違って見えるようになります。代表例がクラスタリングされたファイアウォールなどの冗長構成です。2台のノードが協調して、コントロールプレーンとしては1台に見えますが物理的な実体としては2台あり、どちらかのデバイスに問題が起きたときはもう片方が処理を引き継ぎます。
人は、この見え方を状況に応じて自然に使い分けています。通常時は1ノードとして扱い、障害の切り分けや片系のメンテナンスでは2ノードとして扱う。L2より上のレイヤとしては1ノードとして扱い、L1では2ノードとして扱う。こうした見え方のバリエーションは製品ごとに増えていきます。自動化する(機械で扱う)ために、どんな状況で、どんな製品を、どういう見方でとらえればよいでしょうか? その情報はどのように管理すべきでしょうか?
層をまたがないと成り立たない機能
層が重なっているだけでなく、層をきれいに分けられない機能もあります。
- パケットフィルタや NAT は、L3〜L4 の情報を扱う機能ですが、L3 の情報(どの経路を通りどのインタフェースで受けるか)がわからないと、どこにどんな設定を入れればよいかが決まりません。
- ロードバランサやプロキシは、そこで通信のセッションを終端します。クライアントからサーバまでの E2E の通信は、そこで2つに分断されます。
- 高いレイヤの機能を持つ機器ほど、複数のレイヤにまたがる処理を一度に実行しています。その処理の順序は機器ごとに異なります(➡️第4回)。
性質の重なり合い
ここまで「系全体が状態を持つ」ことと「層が重なっている」ことを別々に見てきました。実際には、この2つは重なり合って効いてきます。
たとえば、overlay のNWで通信が途切れたとします。原因は overlay の設定かもしれませんし、その下の underlay の経路が切り替わったことかもしれませんし、さらに下の物理リンクの障害かもしれません。underlay の経路の切り替わりは、その層の中で機器が自律的に行うので、overlay 側から直接は見えません。ある層で起きた状態の変化が別の層のふるまいとして現れます。
人は構成図を重ね合わせながら「この層の変化が、あの層にこう効いているはずだ」と推理して原因にたどり着きます。この推理には、層の重なり方(構造)と、各層のいまの状態の両方が必要です。そのどちらも機械が使える形ではそろっていません(➡️第3回)。
個々の機器は、自分の担当する層の自分の周りのことしか知りません。NW全体としていまどう動いているかを知っているのは、構成図を重ね合わせ、状態を読み取っている人だけです。そのためNW運用では人の判断が残ってしまいます(➡️第6回)。
後の回で効いてくる性質
ここまでの2つが自動化の難しさに影響する主要なNWの性質です。ほかにも、後の回で関係してくる性質があります。ここでは簡単に紹介し、詳しくはそれぞれが絡んでくる回で扱います。
- 組み合わせが多い: NWが提供するのは「どこからどこへの通信」なので、E2E の組み合わせは(単純に考えれば)端点の数の2乗のオーダーで増えます。1件1件は人が見れば判断できる簡単な作業でも、数が増えるとそれだけで手に負えなくなります(➡️第6回)。
- 共有インフラなので影響範囲が広い: NWは多くのシステムが共有する土台です。障害が起きると影響は複数のシステムに広がります。最悪の場合、リモートからは手が出せなくなり現地での対応が必要になります。しかも、NWの運用者はNWの上を流れている通信そのものを管理しているわけではないので、実際の利用者にどんな影響が出ているかを直接観測できないことがあります。そのため、NWの作業には高い確度が求められます(➡️第7回)。
- ライフサイクルが長い: NW機器はファシリティに近い性格を持っています。一度導入すると数年は使い続けますし、止められない共有部分は部分的・段階的にしか更新できません。全体を一度に作り直すことが難しいので、時間経過とともに世代の違う機器や設計が混在していくことになります(➡️第4回)。
自動化の対象を選ぶときに
NW運用における自動化の計画は、NWの性質を「前提」として立てる必要があります。どの作業ならこの性質の影響を受けにくいのか。どの作業はこの性質のせいで人の判断が残り続けるのか。そうした見極めが、自動化の対象と優先順位を決めます。
NWの性質は変えられません。一方で、次回扱う「足りない情報」は、自分たちで埋められる余地があります。NW全体の構造や状態、設定の経緯は、なぜ機械の使える形で残っていないのでしょうか。