罪深きエンジニアたち

昨日書いた内容よりももっと大きな問題。それは何となく不安に思う人の心理が積み増すオーバーヘッドです。

開発をしたことのある人なら多分経験あると思いますが、「何かあるとヤバいからとりあえずこの見積もりは1.5倍しておこう」、という"あれ"です。これの罪は大きく、自分は1.5倍しただけでも他人も同じように積んでいることがあります。

例えばモデリング担当(広い世界なのでデータモデリングと言ったほうがいいかもしれません)は自分のレイヤーを考えるのでよくある役割分担としてはテーブル設計までを考えます。その時、テーブルの件数は多少多めにしますよね。1.5倍にしておこうなんて話はよくあります。

次に、インフラ担当は自分のレイヤーで多目に積みます。下手をするとオラクルでいう表領域で1.5倍しているのにOSの領域でも1.5倍するなんてこともあります。というかよく見ます。表領域の算出をテーブルサイズなどから積み上げで出すプロジェクトは見たことがありません。最も、積み上げが難しいのには理由があって、インフラのサイズを検討している時にはアプリケーションの仕様が決まっていなくて求められないってこともよくあります。そうなると1.5倍が散見されます。

さらに、ストレージ担当は当然ながら自分のレイヤーで多目に積みます。「このLUNが不足すると嫌だから1.5倍しておくか」、と考えます。「まあ、大きくなってもディスク一本なんて安いからいいよね」、というノリでやってしまう訳です。ディスク単価はストレージ筐体の価格やデータベースのライセンス価格に比べると比較にならないくらい小さいので感覚が麻痺して多く積みがちです。

これだけで多目に積まれた容量は
1.5×1.5×1.5×1.5=5.06
です。必要な数の5倍を見積もっているのです。1.5倍ならまだいいですが、うちのシステムは重要だからという、変な親心?(笑)が働くと2倍になったりします。そうなるとあっという間に10倍を超えます。そんな罪を犯した記憶はありませんか?私はあります(笑)

また、これらの罪深き現実はわからないからみんな幸せ?に生きていられるのです(笑) というのは実効容量の裏、つまり実際に使っている容量は極めてわかりにくいのです。例えば、DBである容量を確保してしまうと、OSから見ると使っているのか使っていないのかがわかりません。オラクルを例にするならば表領域としては使っていなくてもOSから見るとファイルがあるので使っているように見えます。dfコマンド叩くとそうなりますよね?OSも同じでフォーマットしてしまうとストレージからはわからなくなります。当然監視の仕組みを入れる時には自分のレイヤーを担当する訳で、全体の監視など設計しません。自分が積んだ容量が溢れなければいいわけですから。。。結果、全体が見えない監視(各レイヤーでの監視)となり、大きな問題には気づきにくくみんながハッピー?なのです。

こういう罪はまだまだあります。一番大きな罪はバックアップです。たまにありますよね?10世代保管とか。あれも必要な場合は皆無だと思います。ごく稀に法定要件でありますが、バックアップは本質的には一世代でいいのです。「いやー何かあった時のためにせめて二世代は取っておこうよー」なんて会話もよく耳にしますが、そんなの根拠ないでしょ?と思います。よくあるバックアップ設計は週末にフルバックアップを取りますが、一週間前に戻るだけでも大変なのに二週間も前に戻ったらとんでもないことになります。というか、現実的な運用を考えると戻せないでしょう。論理的には二週間の仕事をやり直す訳ですから。。。

ただバックアップの設計の難しいところは取るまでの時間とリストアの時間とコストのバランスが取りにくいところです。瞬間的に大量のデータをコピーするなど不可能な訳ですから、いろいろと工夫をします。ストレージの機能で二重コピーしてからの一方の切り離しや、スナップショットなどがそうです。ただしこれらの工夫はどれも容量が増えるものなのでそのトレードオフはきちんと理解しておく必要があります。また、仮に普通(単純な全体コピー)にやったとしてもバックアップ中に失敗することもありえるので、バックアップが完了する前にはその前のバックアップは消せません。そうすると二倍の容量が必要になってしまいます。その二倍の容量が必要になるのはバックアップ中だけなのですが、容量としては常に二倍必要です。

そういう観点で考えると無駄は本当に多いです。
1.5×1.5×1.5=3.375
1.5×1.5×1.5×1.5=5.0625
2×2×2=8
2×2×2×2=16
となります。数値にしてみるとちょっとした余剰の積み重ねがいかに大きいかわかると思います。では、こうした難しさにどう立ち向かっていけばいいのか、次回はその内容について書いてみようと思います。