最終更新日
3月20日

インフラ稼働率と経営的リスクマネジメント

 

posted by
石橋秀仁

TechCrunch Japanese アーカイブ » 「Amazon Webサービス」ダウン、スタートアップのサイト多数が巻き添えに

こういう事故があると、「Amazon Webサービス信頼性ひくすぎて使えない」なんて思うかもしれません。

ですが、「信頼性の高い低いは、使う人(の要求基準)による」という点を言いたい。

以下、稼働率をリスク管理的(つまり経営の問題として)に考えることの提案です。すごく単純化してますが考え方として。

障害コスト 10万円/障害時間(1時間あたり)

「障害コスト」というのは、それによるお客さま対応とか、ブランドの損失とか、そういった広義の「コスト」をすべてひっくるめて一つの数字にしたものです。あなたが何の商売をしているかによって桁が大きく違ってくる数字です。理論的に厳密な数字なんか出ないわけですが、ある程度「桁(オーダー)レベル」の試算はできますよね。

そして、こういう選択肢があったとしましょう。

インフラA コスト100万円/月 稼働率99.999%
インフラB コスト20万円/月 稼働率99.99%
インフラC コスト5万円/月 稼働率99.9%
インフラD コスト1万円/月 稼働率99%

1ヶ月=720時間で確率的「障害コスト(ひと月あたり)」を出すと、

インフラA 720円
インフラB 7200円
インフラC 7万2円
インフラD 72万円

となります。

ぱっと見てインフラコスト自体より障害発生によるコストが上回ってしまうCやDはどうなんだという感じですね。でもそれは関係ない。

問題は、インフラ自体のコストと障害コストの合計です。一番低いのはCです。数字だけで考えれば合理的です。(※なぜ「合計」するかというと、結局は障害コストを「払っている」のと同じなので)

リスク込みコスト=インフラコスト+障害コスト
インフラA 100万円+720円=100万720円
インフラB 20万円+7200円=20万7200円
インフラC 5万円+7万2円=12万2千円
インフラD 1万円+72万円=73万円

こうしてみるとインフラDはさしずめ「安物買いの銭失い」を地で行ってる感じ。

また、「信頼性」といったファクターもありますよね。いくらCが安くても、ほぼ毎週のように障害発生しているとなると、数字の印象以上に「不安定」という負のイメージで営業上不利になったり。

といったわけで、上記の数字だけでは、判断できません。

結局は「経営判断」ですね。

もちろんAmazon WebサービスについてはAmazon社自身がこういう「経営判断」のもとに稼働率の目標値を設定しているでしょう。

「アマゾンと他の各社がクラウド・コンピューティングの普及を広めたいのなら、平常運転の稼働率を99.999%まで持っていかなくては」とTechCrunchの記者は書いていますが、それはAmazonに多大な労力を要しますし、我々利用者に価格転嫁されます。

2年で2時間のダウンタイムというのは99.9886%であす。「あと少しで99.999%は達成できそうだな」とも思えそうです。しかし「0.0114%」を「0.0010%」にすることになるわけで、11.4分の1にする努力、あるいは91.24%の削減努力と考えるべき。とても大変、控えめに言って。

Amazon社が「Webサービスの稼働率は99.99%でいいから、低価格を追求しよう」と考えるかもしれません。ならば、それを選ぶ利用者もそのことを理解したほうがいいですね。品質と価格はトレードオフなんですから。

世の中のインフラが「5つのコンピュータに集約される」といった議論も、現時点では疑問符がつきます。インフラに求められる品質とコストのトレードオフは無視できません。インフラに求める品質というのは、上の「障害コスト」、つまりどんな商売をしているかによります。銀行と零細企業では桁が6つは違う気がします。

長期的にはインフラの品質が劇的に向上し、コストが劇的に下がり、いわゆるコモディティとしてコストが問題視されないレベルになるのかもしれませんけど。ほとんどの企業は水道代の節約に熱心になったりしませんよね、そういうレベルにWebのインフラがなるのかもですね。

コメント

ZEROFACESではコメントは認証制です。
コメントは投稿審査してから、エントリのページに反映されます。 少々お時間を頂きますが、どうかご了承ください。

トラックバック

トラックバックURL:

http://zerobase.jp/mt/mt-tb.cgi/57

イニジオの「ぴぽぱ」なんかよさげ

ほとんどテキストエディタ