白地図に墨汁を垂らすブログ

某木村氏にクソミソに言われてそうなSIerで、某木村氏にクソミソに言われてそうなユーザ企業のお守りをしているぐうたらSEが、気の赴くままに書くブログ。無責任な愚痴多め。

いかに技術が変化しようと本質を見誤ってはいけないということ

今週衝撃的な出来事があったので。

 

システム運用で一番大事なことは定められたサービスレベルを維持することですよね。

そして多くの場合それは「システムを止めないこと/止まっても影響を最小限に抑えること」が一番多くの比重を占めていることがほとんどだと思います。

(性能って観点も含めて)

 

そのために冗長構成だのなんだのというのを考え方があり、例えば「システムをなるべく止めないためには単一障害点をできるだけ作らないというのは」SEであれば知らない人はいないでしょう。

 

あるプロジェクトでのオンプレシステムのプロト構成を考える場があり、構成検討はあるエンジニアが1人で担当していました。

彼はインフラや運用担当ではありませんでしたが、システム構築全般の知識も問題なく、採用予定のミドルウェアの扱いに長けていたことから、ハードウェアも含めた全体の構成を考えてもらうことになっていました。

 

本論とは関係ない部分は省きますが、そのときの要件は次の通り。

・分散型の構成で複数ノードを用意する

・全体の1/3までの停止は許容し、縮退してサービスを継続できるようにする

 

 

そして彼から上がってきた構成案は

『1台の物理ホストの上にDockerを用いてN台の仮想サーバを動かす』

というものでした。

 

もう目が点です。

ってオイオイオーイ! 物理ホスト死んだらみんな死ぬんかーい!!

分散どこいったー!!!

という雑なバラエティノリのツッコミが頭の中で流れます。

 

 

検討資料にはあるサーバが停止した場合でも残りでサービスが継続できるという考え方がしっかり整理されています。

なので、彼は可用性について意識していないわけでは無く。ただ、「物理的なマシンは必ずどこかで壊れる」って考えがすっかり意識の外へいってました。

 

まあ初めて構成検討をするってなると、こういうことはよくあるのだと思いますが、物理サーバだけで構成する場合にはまず起こらないので、ある意味仮想化技術の弊害(?)かもしれません。

最初はこの背景には「今はクラウド(特にパブクラ)の時代だからかなぁ」なんて思っていたんですが、よくよく考えるとそうでも無いんですよね

パブリッククラウド使う場合でも、ユーザの目に見える原因がハード故障でないだけで、使っているインスタンスが停止することは可能性としてありますよね。

だからHA構成にするとかAZとかリージョンをまたいで構成するとかのノウハウがアルわけで。

 

たまーに技術の進歩で今のシステム運用分野の知識は不要になるっていう言説を目にしたりしますが、やっぱり根っこの部分はそう変わらないですよね。

 

今回の話は極端かもしれませんが、技術の幅が日々広がって言っている分、本質的に何が必要なのか、何のためにやっているのかを捉えることの重要性を再認識した1件でした。

(偉そうなタイトルの割に中身の無い記事ですね。。)