インフラエンジニアへ期待すること

ブラックボックスな PaaS/SaaS のインフラが気になって仕方ない、元インフラエンジニア、現プラットフォームエンジニアのしょっさんです。立場上、Salesforce のことは色々知っていますが、他社のクラウドなどはもちろん知りもせず。想像をしてはニヤニヤする日々です。

さて。これからインフラエンジニアになる人も、すでにインフラエンジニアをやっていて、もっとスキルを磨いていこうと考えいる人にも、ハードウェアをおろそかにしないということを期待しています。

クラウド時代のインフラエンジニアのスキル

クラウドファーストな考え方も相まって、インフラエンジニアの求められるスキルも変わってきました。「いま、インフラエンジニアが必要なスキル」なんてものを見てみれば、TCP/IP すらなくL7のプロトコルだったりします。ミドルウェア中心の世界観ですね。ハードウェアエンジニアとして仕事を始めた私からは、びっくりの世界です。

ただ、私から言わせてみれば、それはインフラのエンジニアではないです。クラウドを使いこなすデザイナーであって、インフラ屋さんとは到底はなれているんですよね。むしろ、そういった最近のインフラは、アプリケーションエンジニアが入ってくる分野であると考えています。これまで、アプリ一辺倒だったけど、PaaS の出現によって、開発者だけでもサービスを提供できるようになりました。あまり複雑なことを知らずして、高品質なサービスを提供できるのです。

そうは言っても、オンプレのなくなっていく世界なんだから、インフラなんてどうなってても、いいじゃんとか思われるかもしれません。時代は変わったんだよ老害、と。たしかにクラウドによって、インフラの部分はブラックボックス化されています。しかし、その実、低レイヤーでのさまざまなデザインが、苦労に苦労を重ねて自動化されて運用されているわけです。急にクラウドのサービスができているわけではありません。

そんな苦労をはねのけて、クラウドもたまに大障害を起こします。その度に陰謀論とか、クラウドはやめよう論が噴出しますが、それはまだ中身を何もわかっていないから、そういう論調がさっと出てきてしまうのです。

インフラにおいて最も厄介な領域

インフラで最も厄介な障害はなにか、と問われて「ハードウェア」と答える老害はたくさんいるでしょう。現にそうですし。

ソフトウェアのバグやエラーに関しては、結構追えたりするもんです。どっかに記録されていることがほとんどです。記録さえもしていないようなソフトウェアを作ってしまわれていたら、一巻の終わりですが。ただ、それはコードを書いたやつが、またはアプリを設計したやつが悪い。はよ直せ。

そして、ハードウェアも進化に進化を遂げてきています。今では、事前に故障がわかったり、どのパーツに障害が発生しているかを明示してくれるものも増えました。素晴らしい。わたしがこの業界でエンジニアを始めた当初は、数千万、数億のマシンであっても二桁のエラーコードとマシンの状態から、想定される障害を導いていくことが一つの手段でした。今考えると、あのときに見ていた障害解析本は、ゲームブックそのものでは、とか考えたりもします。

それでもどうにもならんときは、ハードウェアまるっと交換したりね。PCとか小型のものだといいんですけど、汎用機やオフコンなどの巨大筐体に関しては、まるっと交換なんてできる代物じゃありませんから、障害解析がしんどかったことでしょう。それは今でもそうでしょうけど。

ハードウェアって故障が起きたことがわからないときが多いんですよね。汎用機のようにCPUが複数のっかっていて、マギシステムばりに答えを導いてくれるようなものであれば、どのCPUに異常があるとかは多数決の結果で分かりますが、PCなんてたいていCPUが正常に動作していることを前提に考えられてるので、ちょっと計算ミスったりしても、誰も気が付かないケースがあります。CPUとしては正確に答えを出していたとしても、小数点以下の丸め誤差によって、不正確な場合もありますけど、それはまた別の話。その他、メモリもケチってECC使ってなかったら終わりですし、HDD も壊れかけてるけど動いてるとか、コンデンサがもうヤバいとか、実はすでに破裂しているとか、キレイにどっかがショートしてるのに、地味に動いちゃってるとか。あんのかな。

まぁ「なんで動いてた...」みたいな症状が発生するのは、ほぼハードウェア起因です。しょうがないです、ここだけアナログなんだから。最近はHDDもなくなってきて、駆動系がないので、故障率も随分と下がったことでしょう。とはいえ、命あるものすべて壊れます。たまたま減価償却まで動き切るような場合もあるでしょうが、謎の死を遂げるようなケースも多々あります。

一番こわいのは、ゆっくりと死んでいくケース。徐々に何かがなくなっていく。2019年にもありましたね。冷却装置が死んで徐々にというか、どっかのAZの一部が死ぬ減少。あのときのハードウェアなんて、どう動作するかわからないわけです。熱暴走なんていいますけど、高熱になって暴走してCPU止まってくれれば御の字です。こわいのはCPU動いてるけど、メモリやストレージが死んでるとか。コンデンサ破裂して、そもそも動作が怪しくなってるとか。コンデンサ死んだら、急にしなないで、あとになって「あれ、俺おかしいわ」みたいになってOSが死んでくパターンありますけど、あれ一番困ります。確実に起こる死なのに、検出が難しい。

インフラエンジニアの闘争

インフラ屋さんは、こんな謎の死を遂げるものを前に日々戦ってきています。これはクラウドでも同様のパターンで死ぬケースがあるものの、ブラックボックスだから、「ぼくたちじゃ直せない...たすけて...」みたいにならざるを得ません。が、これは何が原因で起こっているかによっては、対処ができるケースもあります。データセンター単位でのなんらかの障害で、電圧降下・火災・水害などまるっと死にそうになりかけてる場合には、そこを切り離すことで対処可能かもしれません。このへんは、想像力がどこまで働くかにすぎませんが、想定される現象・状況を想像するには、その想像力の範囲が、自分の知識レベルを超えていくことは難しいでしょう。

だから「インフラエンジニアでーす」と名乗るのであれば、クラウドを操るだけのデザイナーではなくて、ちゃんとその下のレイヤーで動いている様々な仕組みを理解していることを期待しています。

ハードウェアと言っても、CPUとメモリだけじゃないです。電気や電子回路を組み合わせた論理回路の仕組みでできあがってます。わたしも電気までいくとよー知らんので、強く言えませんが、すくなくともアナログをどうやってデジタルにしているのか、どうやってCPUやバス・チャネルが他のデバイス・チャネルとともに動作しているのか、ネットワークはなんで通信できるのか。こういった低レイヤーの知識は、いざというときに確実に役に立ちます。

今は、その「いざ」の頻度が少なくなってきただけで、いらないわけじゃないのです。だけど、インフラエンジニアは知っていてほしいと願ってやまないのです。