2014/06/10

図面とともにあらんことを！：第二面

　NOC 図面担当、河口と申します。また長いおまえか！...そうおっしゃらずに、何卒お付き合い下さいませ。

　前回の末尾で「次回もお楽しみに！」なんてことを言っていましたが、あれから一年も経ってしまいました。実はあの時点で今回の分はほとんど書いてあったのですが、INTEROP が終わると関係者はみな燃え尽きます。私も社会生活を取り戻すのが毎回大変で、呆然としている内に次を迎えてしまいました。

　前回は、図面担当から見たゲンバの怒濤の雰囲気をお伝えしました。本日はその図面の話を掘り下げようと思います。関連する話も出てきますので、まだの方は 前回 から読んでいただければ幸いです。長いヨタ話はどうでもいい！という方は、ページ 3 へ飛んで下さい。

　さて、私が STM になりたての頃。素人同然の学生だった者にとって ShowNet で学んだ偉大な事と言えば、マネージメント・ネットワークでした。

　1994 年当時の米国 NOC チームはこれを〝Access Ether〟と呼んでいましたが、その後日本のメンバにシフトしてからは、いつの間にやら〝まなげ〟という愛称が使われるようになりました。箱とマナゲとの接続は運用にはほとんど影響しませんし、そもそも描き込める分量ではありませんので、それを構成する部分だけを欄外に描きます。

　安価なものは別として、箱には普通 MGMT などと刻印された管理専用のポートがあります。これはフォワーディングプレーンから隔離され、箱の CPU に直結している特別なポートです。箱をマウントして mgmt0 などにアドレスを付けると、マナゲ専用のスイッチで束ねる事からはじめます。その際、ぱっと見でそれがトラヒックを運ばないことを示すため、ShowNet では伝統的に黒いヒモを使います。

　このネットワークは L2 フラットです。NOC ラックのほうは事前に設計した通りに作りますが、NOC ブース前に仮設したパイプ机のほうは必要な人が自席にオンデマンドで引き伸ばすため、眠いながらやっていると時折〝グルグル〟つまりストームを作ってしまいます。ひとたびこれが発生するとマナゲが派手に融けてしまい、多くの人の仕事を止めてしまいます。そのため、ここで使うスイッチの仕様は最低限ストームコントロールがあるものや、去年の例ではファブリック等を使います。ここでは安定性が重要で、カッティングエッジは一旦忘れます。

　このセグメントに入るには、〝おもて〟つまり Internet 側と資源を共有しないというポリシーを持つため、その先にある箱の数がごく少ないなどの理由でもない限りオモテのタグと混ぜて運びませんし、資源の都合さえ付けばオモテを流している DWDM 箱などにも混ぜずに生芯を使ったりします。ルーティング障害に引きずり込まれないように広告もしません。

　こいつだけは天地がひっくり返っても動いてること、それが担保される程度にアイソレートします。

　そうやって孤立させたセグメントに入るには〝踏み台〟を使います。これは SSH ゲートウェイのことで、足を二本生やしただけの Unix 箱です。マナゲのセグメントには、シリアルサーバや KVM、計算機の IPMI などの管理系の多くをつなぎこむため、利便性のため squid や SSL-VPN 箱を置いたりもします。また、オモテ側を不安定にさせる可能性があるコマンドを叩く時は、あらかじめ自分の端末をマナゲに直収しておきます。去年の大魔神の話のようにオモテの無線が不安定なこともありますから、マナゲ用として USB イーサを持ち歩くエンジニアも珍しくありません。

　今となってはごく当たり前の手法ですが、当時は舞台裏の黒子のような地味な存在に何故ここまで拘るのか分かりませんでした。こうしたものは、経験値が伴わないうちは理解出来ないまでも、運用を通じてじわじわ来るものだからでしょう。普段はオモテ経由で箱に入れたものが、ひとたびネットワークが不安定で使いものにならなくなると箱へ確実に到達出来るマナゲの威力を実感します。リモートでこんなアブない事もできるんだということに気付いて頼りはじめ、そのうち有って当たり前だと思うようになります。

　オモテの世界で好きなだけ暴れまわるためにウラをガチにしておく...そうしておけば、いくら地上でド派手にワイプしても地下は平和です。何でもかんでもカッティングエッジ一辺倒ではないというメリハリのある ShowNet のネットワークデザインは、机上では学べないことを教えてくれました。それからというもの、逃げ出したくなるような修羅場で幾度も私を救ってくれました。

　私の職場はボックス型のルータ数十台、スイッチ数百台程度のものを私と相棒の二人で面倒を見るような中規模なエンプラですから、てんこ盛りの ShowNet とは比較にならないほど小さくシンプルなものです。実トラヒックを一切流さないような贅沢なものにコストをかけるような事はなかなか理解が得られませんので、はじめの頃は退役したスイッチを使ってこっそりベースで構築し、EoR で騙し騙し実績を積みました。そのうち IPMI な計算機が当たり前になってくると、ラック跨ぎの黒いヒモが大蛇に育って酷い有様となってきたため、ようやく ToR でデプロイできるようになりました。

　しかし、そうして作り上げた裏方の力を発揮させるためには、見やすく正確な図面が手元にあることが条件です。障害の切り分けをする時、臭そうな箱とその周囲の関係を検討したり、それらの箱のアドレスを確実に知るには、図面のようなローカルにある情報が突破口となるのです。

　さて、今時のネットワークエンジニアに図面を引くのに何を使っていますか？と問えば、決まってこう答えるでしょう。

　「ぱわぽや。」

と。

　PowerPoint は何かと便利なものです。設計するにもプレゼンするにも、メールにくっついた .pptx が目の前を飛び交います。いや、多くの人がそのような道具に対する疑問を持たず、先輩が使っているからだとか、今ある資料が全部 .pptx だからなどという理由で、長いものに巻かれるエンジニアが大半なだけなのかもしれません。

　プレゼンテーションと設計が同じツールで済んでしまうという教育的なコストメリット。PPT ファイルのまま送付しても失礼にあたらない程の普及度。誰もが必要に応じてアップデートできる手軽さ。空気のような存在となることがインフラとしての使命であるとすれば、今や PowerPoint はそれに最も近いポジションにあります。しかし、そんなデファクトが持つどこか気軽な空気への甘えでしょうか。人に伝える工夫というものを疎かにしていたり、折角内容的に頑張っているのにも関わらず結局何が言いたいのかわかりにくい図面に出会うたびに、残念な気分になります。

　誰かの端末の中で新規作成されたメモ書き程度の瑣末なファイルの一つが、いつの間にか設計の叩き台となり、様々な人の手を経ながら雪だるま式に膨れ上がって、気づけば詳細レベルまで書き込まれていく――そんな業務フローの中で一貫した見やすさを維持する事は確かに至難の業です。また、そのような空気の中では正しい箱に正しくヒモがつながっているという精度さえ担保されていれば、それが例え見難くても大した問題にはなりません。図面を使う側もこと見やすさに関しては寛容でそんなものだと目を瞑り、あまつさえ

　「あいつのアタマを sh tech したほうが早いわ」

などと言って片付けられてしまいます。

　しかし、平時に使えるものと、修羅場に耐えるものとでは話は別です。