クラウドが削減しているコスト－その2

さて、前回、SaaS、PaaS、IaaSの「提供コスト」が安い理由の解釈をいくつか書きましたが、別のコスト削減の側面について書きたいと思います。それは「DIY」です。

Googleが、「安価な（不安定な）」「小さい（もしかしたら古い）」サーバーを大量にかき集めてシステムを構成していることは有名です。これには、GFS（Google File System）」、キーバリュー・データ、MapReduceなど、すこし変わった構造でできていることも有名です。（しかし、経験の長い人は「むかしも似たようなシステムはあったな」と思う人も少なくないはず）

これも、クラウドの「コスト削減」の一つのアプローチだと思います。これは、流通問題ではないので、前回とは回を分けてみました。

確かに、ベンダーが作るマシンは高価です。それは、以下のような性能を担保するようになったからです。

• 落ちない（できるだけ）
• 壊れない（できるだけ）
• 壊れても落ちない（ホットリペアなど）
• 壊れたらすぐ分かる（診断機能など）

こういった信頼性性能向上のアプローチは、多くの開発費用を使って作られ、その蓄積の上に成り立っていました。蓄積しちまったもんですから、当然高価です。「高かろう、良かろう」だったわけです。

ところが『「壊れちゃう」「壊れたら落ちる」があたりまえ』という大胆なアプローチをしているのが、最近の新しいアプローチです。「安かろう、悪かろう」を受け入れてしまえ、という感じです。これは、旧来「フォールトトレラント」という考え方で使われていたアプローチだと思いますが、それをシステム全体に適用したようなものです。Googleのアーキテクチャーはその代表格でしょう。

大量の安いコンピューター群とソフトウェアだけでこれを実現しているので、全体のコストは少ない「こと」になっています。このテクノロジーを採用することで、「安くても安全な」システムが構築できる、という神話のような話さえも浮き上がっています。

しかし、このようなシステムに欠点がない、という話ではありません。あくまでもコストを削減した一つの方法論、ということです。

Googleの真似をするには、この「大胆な」アプローチを失敗を恐れずに採用する勇気と、問題が起きたときのリスク管理をする必要があります。また、脱ベンダー依存を宣言するようなものですから、そのリスクを自分で負うこと、社内にそれを運用できるだけのベンダー以上のプロを準備する必要がある、ということです。この話題はまた次回にでも・・・・・。