このブログは「風見鶏」が、日々気づいたこと、思ったこと、したことを気ままに綴る日記です。2008年9月に旧ブログから引っ越しました。バックアップをご覧ください。

ゲストログインがうまくできないので、コメントを承認制にしました。スパムでないことを確認の上、公開します。判断はあくまで「風見鶏」の主観で行いますので、文句は受け付けません。(笑)承認が遅れることもままあると思いますが、あしからず・・・

システムトラブルのため、2015年以降のブログ画像と2018年5月以降の記事が消失しました。画像は鋭意、新しい物から順次復旧中ですが記事については残念ながら戻せません。残念ですが、あきらめます。

なお、ここに書いていることは、あくまで個人的な思いであり、いかなる組織をも代表、代弁するものではありませんし、無関係ですので念のため。

雲をつかむ話(2章-8)

| コメント(0) | トラックバック(0)

さて、ここまでは雲の階層(レイヤ)の話だったが、今度は雲の大きさ、広がりを見てみよう。言うまでもなく、もっとも広がった雲は、GoogleやAmazonに代表される、いわゆる「パブリッククラウド」である。このカテゴリのサービスは、多くのユーザが必要とする一般的な機能、サービスもしくはインフラを必要とするすべてのユーザに提供する。このレベルでのサービスには、言うまでもなく高いスケーラビリティが必要になる。なぜなら、多くのユーザ、しかも、規模も使う頻度も違うユーザ(企業)をストレスなく収容しなければならないからだ。そのためには、ある程度の規模のインフラが必要になる。もちろん、スモールスタートはあるだろうが、ユーザに意識されない形で随時、増強が可能なインフラでなければならない。こうした、幅広い企業やコンシューマを相手にするサービスは、価格の面でも要求がきつい。はっきり言って、安くなければ誰も使わないからだ。だから、ある程度の初期投資をして、規模を稼ぎ、さらにはユーザの負荷をうまく平準化してインフラを最小化することが必要になる。そういう意味で、最も敷居の高いサービスだといえるのかもしれない。大手優位の構造が最もはっきりするタイプのカテゴリだろう。

 もう少し、絞り込んで、特定の業種やビジネス上の企業集団などのレベルで考えると、共通する業務はより多くなる。たとえば、EDIや、部品の取引市場、行政サービスなどを考えてみるとわかりやすいだろう。このレベルで共通な業務をサービス化してクラウドで動かそうというのが、いわゆる「コミュニティクラウド」だ。これは、どちらかといえば、システムの標準化とインフラの共用によるコストダウンを狙うものと考えられるだろう。もちろん、対象となるコミュニティの規模や広がりによって必要とされるインフラの規模はかわる。たとえば、グローバルな取引システムなどは、時差による負荷の平準化も可能だが、日本国内のようなタイムゾーンがひとつの地域内のサービスでは、その効果は薄い。むしろ、共同システム運用的な要素が強くなる。クラウドという意味合いを強調するのであれば、たとえば、複数の会社や自治体のような機関が、それぞれ得意な部分のシステムを運用し、相互に乗り入れたり、バックアップしたりするようなモデルがいいのではないかと私は考える。クラウドというなら一か所にまとめる必要はないだろうし、それによる地理的な意味でのリスクも大きくなるからだ。たとえば、きちんとしたIaaS/PaaS事業者がそういう大規模でスケーラブルな分散環境を用意してくれるのであれば、その上にまるごとのせてしまう手もあるだろう。いずれにせよ、クラウドコンピューティングというものが、ネットワーク上に分散された環境をうまく利用して効率のいいシステムを作るための技術だとすれば、そのような形で作るのでなければ、それは単なる共同計算センターにすぎなくなってしまう。ここがまた、「まやかしクラウド」の入りこむ隙間だろうと思う。

さて、では、ひとつの企業や団体、機関のレベルでの、「プライベートな」システムのクラウド化は可能なのだろうか。結論から言えば、可能だと私は思う。但し、それは、本来の意味でのクラウド基盤を提供できるIaaS/PaaS事業者の存在なくしては困難だ。自社でこうしたスケーラブルなクラウド基盤を構築できる会社は、世界中で見てもそれほど多くはないだろう。通常の、特に自国内中心の商売をしている企業などのクラウド化は、上のレイヤで考える必要があると私は思っている。このようなクラウド化は「アウトソーシング」の一種ではあるが、これまで、一般のデータセンタ事業者に対して行われてきたものとは根本的に考え方が異なる。最も異なる点は、コストに対する考え方だ。アウトソーシング自体は、企業が本来自分たちの本業ではないITリソースを保有せず、外部のリソースを利用して、こうした本業外のリソースを保有することのコストやリスクを下げようというものだ。ある程度規模のある事業者にシステムの運用管理やユーザサポートを委託することで、こうした目的はある程度達成できる。特に、人的リソースを保有しなくて済むことで、管理コストを含めた人件費とそれにかかわるリスク、たとえば、自社技術者のスキルへの依存やIT技術の変化による人材の再教育、入れ替えといったリスクを軽減できることは大きい。しかし、それ以上のメリットをどれくらい享受できているのだろうか。

多くの場合、システムのソフトウエア、ハードウエアはユーザ側の資産である。従って、この部分の調達費用はユーザ側の負担だ。また、運用やサポートのアウトソースに関する費用も決してバカにならない。意外と高くつくのが、必要なSLA(サービスレベル保持契約)の締結だ。SLAを結ぶことは、事業者にとってはリスクのを負うことにほかならず、当然、保険の意味で高い料金を要求することになる。実際、それは、自社要員で運用するよりも、高くつくことが少なくない。それが認められていたのは、それでもユーザは人的なものを含めたリスクを負いたくないからだと私は思う。ただ、事業者にしてても、ユーザごとにシステムが異なる以上、そうせざるを得ないだろうと私は思う。共通化できるのはファシリティとネットワーク基盤くらいである。ここを一歩打開しようとするのが、仮想化基盤を使ったハードウエアの共有化だ。平たくいえば、個々のユーザが持っているシステム性能の余裕部分を共有化することで、この部分のコストを下げようという考え方である。注意が必要なのは、仮想化でハードウエアを共有したとしても、SLAがある以上は、個々のユーザの処理性能は保証しなければならない点だ。したがって、事業者としては、それをカバーできるだけの規模のシステムは最低限必要になる。

ここは本来、事業者側の腕の見せ所だ。たとえば、個々のユーザの利用統計をもとに、同じ仮想基盤にのせるユーザのピークが重ならないようにするとか、異なる性格のシステムをうまく混在させるとかして、負荷をできるだけ平準化し、必要なハードウエアリソースとその運用、保有コストを減らすといったことだ。このために、システムを動的に仮想環境上で管理できるような基盤も必要になる。ただ、先にも述べたように、これは一事業者の範囲ではなかなか容易ではない。しかし、ここをクリアできなければコストダウンはできず、ユーザのコストダウン要求と自社の利益とのはざまで板挟みになることになる。何度も言うが、ユーザにとってのクラウドとは、コストダウン以外の何物でもない。つまり、クラウド化は事業者に対しても劇的なコストダウン努力を求めることになるのだ。

こうした前提で、個々の企業が、事業者のインフラを安価に借り受けて自社システムを動かすことができれば、はじめてそれは「プライベートクラウド」と呼ぶことができるのだろうと私は思っている。

 

(続く)

 

 

トラックバック(0)

トラックバックURL: https://www.kazamidori.jp/MT/mt-tb.cgi/242

コメントする

月別 アーカイブ

この記事について

このページは、風見鶏が2009年12月29日 20:13に書いた記事です。

ひとつ前の記事は「シーズン始動・・」です。

次の記事は「2009年、ひとつのしめくくり」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。