ネットワークには多様性を…組み込めない事情がある
ネットワークは多様であるべき。それは理想的には…というか理屈で行けば正しい。自然環境を捉えたときに種の多様性が重要であったり、会社の強さを測るときに人材の多様性が重要であったりするのと同様に、自律分散系としてのネットワークを捉えたときにネットワークの構成要素が多様であるべきだ、というのはもっともな話だ。攻殻機動隊の漫画版を読んでる人なら、草薙と人形遣いとの会話、「あるネットが破局(カタストロフ)を避け安定した平衡状態を保つためにはどうする?」を思い出すんじゃないかな。
さて。リンク先にあるNTT東フレッツの障害についての話とかから派生している話題なんですが、ネットワーク屋さんがある "単一の" ネットワークシステムを構築するときに、意図してこういった多様性を組み込むかというと実はそうではないと思う。その理由を列挙してみよう。まあ一言で言ってしまえば、多様性(diversity)は複雑性(complexity)に繋がり、複雑なシステムの面倒を見るのは非常に困難ですよ、という話なんだが。
- 構築負荷
- 単一機種・単一ベンダで数そろえた方が、機器単価を下げられる。
- 単一機種・単一ベンダで数そろえた方が、操作方法を統一できるので構築するのが楽。
- 操作方法やそもそも使う用語からして違うような多ベンダ機器構成でやるのは、それだけのスキルと知識のあるエンジニアをそろえる必要があり、人件費的にも(エンジニア単価ね)高くなりがち。
- 組み合わせ問題
- 多機種・多ベンダ構成にすると、機器間の相性問題などの「避けられるはずのトラブル」に巻き込まれる可能性というのが出てくる。ベンダ側は他ベンダとの相性なんてなかなか見てくれないので、その辺の検証なり品質保証は誰がやるんだというがまた厄介。検証にはまたそれはそれでヒト(エンジニア)とモノ(検証機材)、時間とお金がかかるし。
- 使うものが増えると爆発的にその組み合わせも増えるため、全体としてちゃんと動くのかどうかを保障するのはとても困難になる。それで障害試験なんてやろうものなら……。
- ソフトウェアやOS/ファームウェアのバージョンにしたって、バージョン間の機能差、細かい操作の違いなんかは往々にしてバッドノウハウの温床になるし、バージョン間での脆弱性情報等を考慮することを鑑みるに、基本的にはこういったものもすべて統一する方向になる。
- 運用負荷
- 運用手順書の発散の防止
- 機種なりソフトウェアなりが複数種類にわたる場合、それぞれについて詳細な運用手順書が必要になり、手順書を書くエンジニアの負荷が高くなる。必然的に工数がかかり、金もかかる。
- オペレーションミスの防止
- 異なる機械、異なるソフトウェアを切り替えながら使いこなすのは高度な能力を要する。パッチやマイナーバージョン間の違いなんて誰がどうはっきり把握するんだ? 似ているけど異なる操作はオペミスの温床となり、さらなる障害の引き金でもある。こっちだと思って操作したら実は違ってましたなんて原因で発生した障害を顧客が納得してくれるだろうか。
- 障害切り分け時の検討パターン数の削減
- 機種・ベンダ・ソフトウェア等を複数導入するとなると、それぞれの特徴、アップデート情報(およびパッチ適用状況の管理)、サポート、バグ情報等を逐一把握しながら、実際に障害が起こったときに何が原因かの切り分けを行わなければならない。運用設計時に発生する可能性のある障害を想定して、それぞれどういうフローで切り分けし、対応を流すかというのを考えるけど、使うモノが揃っていないと、そのときのフローやサポート連絡先等がどんどん発散していってしまう。そのへんをフォローできる運用エンジニアを確保するのは非常に大変。
- 運用手順書の発散の防止
細かく考えればまだ色々でそうだけど、大まかなところだとこういう理由が挙げられるだろう。あ、拡張性とキャパシティの見積もりが難しくなる、とかもありそうだな。
そもそもL1からL7まで、多数の構成要素、多数のプロトコル、多数のソフトウェアの組み合わせ、それぞれの挙動および要素間の連携を把握しなければならないネットワークの設計・構築においては、その全体を把握して対応できるエンジニアなんてほんの一握り。運用まで回すことを考えると、たとえば特定のサーバならわかる人とか、特定のネットワーク機器ならわかる人とかに分割してフォローを任せることになる。冒頭で、自律分散系としてのネットワークといったけど、実際その上でさらに膨大な数の人(もっともcomplexで予測不可能な要素)がそれぞれ処理を走らせるわけで、いつだってある意味出たとこ勝負になるしかない。そんな状況で動かし続けるってことを考えると、使う構成要素はなるべく減らしてシンプルにしないととても回せないということになってしまう。今回障害のあったフレッツでどうだったのかは、中の情報が判らんのでなんとも言いにくいのだが、地域によっては新しいバージョンのルータが動いていて問題なかったというのから察するに、膨大な数あるルータを地域別にリプレースして「そろえていく」過程で発生した障害なんじゃないのかなと思っている*1。
リンク先で触れられている「多様性」がどのレベルでのものなのかによるよ、ということになりそうだけど、それがインターネットのかなりマクロなレベル、ASとか企業間とかのレベルになると実際それなりに多様にはなっているんじゃないかな。ただ、企業内のネットワークとか、フレッツみたいな「ひとつのネットワーク内」になると多様性をあえて組み込むというのはとても難しいだろう……否、あえて多様性は組み込まないだろうな、と思うのでした。だって、シンプルにしよう・統一しようとしていたってどうしても複雑化・肥大化してしまうのに、その中にあえて多様性を組み込むなんてよっぽどのスキルと能力がないとね…。
*1:もしそうだとするならという仮定の上での妄想だが、リプレースが予定より早く進行していたのであれば「運良く障害範囲が抑えられた」のだろうし、遅れていたのであれば「運悪く障害範囲を抑えられなかった｣のかもしれない。偶然ネットワーク内に多様性が発生していたために、一部障害の影響を免れたのかもしれないし、免れられなかったのかもしれない、ということ。
