達人が語る,インフラエンジニアの心得

第9回 金勘定とエンジニア

この記事を読むのに必要な時間:およそ 3 分

イノベーションをにらんだコスト把握

筆者が今まで手掛けた中でも,かなり効果の高かったケースをひとつ紹介しましょう。

某ISPにおいて,それまでメールサーバは普通のサーバにRAIDボックスを接続したものをたくさん使うという使い方をしていました。物理的に場所をとる構成だったために,1ラックで収容できるユーザ数があまり多くなく,メールサーバだけでラックを数十本使っているような状況でした。また,サーバ台数が100台超と非常に多かったため,故障はしょっちゅう出るし,OSパッチがあるときなどももう大変な状況でした。まだその当時は,業務系はともかくフロント系では巨大サーバや巨大ストレージにconsolidateするような使いかたはなかったのです。

そこで,主に業務系をターゲットにした新機種がHPから出たため,その機種とSUNのE4500の2つを性能比較し,またストレージも当時としては巨大ストレージ(SANではなくDASですが)を選定して,まったく新しいシステムを構築しました。

性能比較したところ,最初はE4500のほうがパフォーマンスが出ていたのですが,本来のCPU性能を考えるとあきらかにおかしい結果でした(ストレージの条件は同じ⁠⁠。なんでだろうと思っていたのですが,当時Solarisはnscdというキャッシュデーモンをとっくに実装していたのに対して,HP-UX 10.xはまだそういう実装がなかったのです。

ところが,ちょうどその比較をしているときにHP-UX 11.xが登場し,11.xからはpwgrdというキャッシュデーモンが搭載され,この条件で比較したところ圧倒的にHPのほうが高速な性能を出すことができたため,結局HPにしました。このときも,HPの機種は戦略的な新機種であったため,導入事例が出ることがHPにメリットが多かったためにかなりのディスカウントを得ることができました。

今となってはというか,2000年くらいでは,メールサーバにおいてvirtual domainが作成できたり,認証にRDBやdbm系のバイナリDBを使えるのは普通のことですが,なにせ当時はsendmailやqpopperあたりにもまったくそのような機能もなかった時代です。POP before SMTPも,qpopper用で出回っていたパッチは外部processをforkするようなオソマツなものだったので,自分でqpopper自体を改造していました。また,virtual domainはchroot環境を使用して作成し,管理ツールなどもすべて自作でした。もっともこの数年後,sendmail社が商用の商品などを出してきたので,そのあとは商用の製品に切り替えたようですが…(そのときすでに筆者は転職していました⁠⁠。

そしてその結果,数十本あったラックをわずか3本にすることができたのです。年間あたり数億円の削減をすることができました。ここで筆者が言いたいのは,この削減プランは業務指示が出たわけでもなく,筆者が自分からやりたいと思ってやったということです。まあ100台超のサーバをお守りするのは嫌だというのももちろんありましたが。

求められるのは「利益を生むエンジニア」

エンジニアというのは,より限られた条件で同じことを達成できるほうが優秀です。そしてその条件にはもちろん,予算という条件が入ってきます。

世の中のほとんどのエンジニアは企業で働いているでしょうから,何らかの収益のために活動していることになります。ということは,エンジニアの活動の目的の1つには,より利益を出すということが必然的に含まれているはずなのです。

そこをキリキリ追求しすぎても,またお金のことを気にしなさすぎでも駄目な気がしますが,いずれにしても金勘定ができ,かつそこまで考慮した行動を取ることができ,より厳しい条件でも目的を達成できるエンジニアのほうがいいに決まっています。

予算をじゃぶじゃぶ使って贅沢な環境を用意してシステム組むほうが楽なのは当然です。ただここで注意しないといけないのは,お金をたくさん使えば誰でもできるかといえば,それもまた違います。お金を山ほど使ってすら目的が達成できないのは論外です。ただ,同じ達成するのであれば,より費用を抑えてシステムが組めるエンジニアのほうが優秀だと言えるでしょう。

その実現方法は,前述した値引きや相手の意図を読むという営業的交渉術もあれば,これもまた前述したシステムを根本から見直してみる(サーバ費用でなくラック費用に着眼するなど)という方法もありますし,またなんでもかんでもDBではなくKVSを使ったり,SQSを活用して必要なサーバ台数を抑えるというのも重要です。

ほとんどのエンジニアは,値引き交渉で実現するよりは,技術力で実現するほうが良いと思う気がしますが,これらは別に排反背反するものではないので,両方やれば良いというのが正解だと思います。私見ですが。

また,もちろん技術力によって費用を抑えるときも,目的をちゃんと定めてやることが重要です。単に速くなっただけではなく(それも重要な視点ですが⁠⁠,それによってどのくらい利益が増えるのかまで考えられれば最高でしょう。

またこれまでは,調達額を抑える側の話ばかりしましたが,もちろん粗利というのは売上から原価を引いたものですから,より売り上げが上がるという発想ももちろん有効です。それはパフォーマンス向上によるユーザロイヤリティの向上であったり,正しい冗長化によるシステムの信頼性であったり,クラウドなどをうまく活用したピークトラフィックの処理であったりするかもしれません。こういった点についても,単に技術的興味からだけ取り組むのではなく,それによってどういう効果があり,自身が関わるビジネスでプラスになるのか,というところまで考えられれば,これはとても素晴しいことだと思います。

今回は技術の話というよりお金の話になってしまいましたが,エンジニアとして必要な部分だと筆者が思っている重要な部分の1つの話でした。

著者プロフィール

山崎徳之(やまざきのりゆき)

青山学院大学卒業後,アスキー,So-netなどでネットワーク,サーバエンジニアを経験。オン・ザ・エッヂ(現ライブドア)のデータセンターである「データホテル」を構築,運営。2003年にベイエリアにおいてVoIPベンチャーであるRedSIP Inc.を創業。2006年6月に株式会社ゼロスタートコミュニケーションズ(現 ZETA株式会社)を設立,代表取締役就任(現任)。ECソリューションの「ZETA CX」シリーズとして検索エンジンやレコメンドエンジンを開発,販売している。

blog:http://blog.zaki.jp/
社長コラム:https://zetacx.com/column