はじめに
クラウドコンピューティングに至るまでの歴史
ユーザ側がブラウザ上で雲の上にあるコンピュータですべての処理を行うという方法はインターネット初期のメインフレーム時代に似ている。メインフレーム時代では、すべての機能はメインフレームに集中していて、低速通信回線を使用しているために、コンソール画面から文字や数字でメインフレームに対して指示を送っていた。当時はメインフレーム自体が大変高価なものであったために、中央のコンピュータを複数のユーザが共同で利用するということが理にかなっていた。
1980年台に移ると、PCが誕生し、コンピュータ自体の価格が下がったために企業が多数のコンピュータを使用できるようになり、コンピュータシステムはメインフレーム時代から多数のコンピュータ通しの「分散」の方向へ向かった。
1990年台からは、コンピュータの価格が更に下がり、ADSLの登場で通信速度が上がりコストも下がっていった。そのためにネットワークに接続されるPCの数が増え、その結果インターネットを利用して分散したクライアントを接続しながら、サーバ側で主要な処理を行う「集中」の時代へと変化していった。しかし「集中」の時代から、サーバが乱立することになり、「いかにサーバを統合し、管理するか」が問題となった。この文章はコピペです。
その課題を解決するためにクラウドコンピューティングが推進されることになった。データ等の管理コストが問題となりつつありそのため、アプリケーションとデータ共にサーバ側が集中して管理すること、又、仮想化技術などの活用によってサーバを統合しつつ様々なクライアントからのアクセスを可能とすることができることが、最も効率がいい解決策である。さらに、クラウドコンピューティング環境の設定のために、膨大な数のサーバやストレージ機器を収容し、稼働させるためのデータセンターが必要となる。その際に機器を一括購入することで安く調達が可能になり、調達した機器を一括で運用することで、物理的な位置がバラバラのサーバと違いコストを抑えることができ、ユーザの数が増えたとしても増設は容易となり、また利用効率を高めることができる。この文章はコピペです。
クラウドコンピューティングを支える技術
クラウドコンピューティングを構成しているのは、スーパーコンピュータ1台ではなく、安価で汎用的なとりわけ能力が高くないコンピュータが大量に使われている。従来のデータセンターを構成するコンピュータと異なり、ハードウェア単体ではディスクアレイや無電源装置などの信頼化を目的とした専用ハードウェアを持っていない。そのため個々のハードウェアの障害の発生は当然とみなされているが、ソフトウェアにより迅速なエラー検出、障害の自動復旧機能などを備えており、システム全体としての高い信頼性を実現している。
汎用コンピュータを使う理由としては、価格が安くインフラ構築のコストを下げることができることと、ハードウェアの費用対性能が上がった時に汎用コンピュータなら新しいコンピュータに簡単に入れ替えることができ、拡張することも容易であることのメリットがある。さらにこうしたコンピュータでは発熱量を増やす原因となる冗長化機構が組み込まれていないために、数千台以上の膨大なコンピュータを運用する際に機器の発熱量を抑え、空調を効率化してデータセンター全体としての消費電力を抑える狙いがある。
コストを抑えるためにOSや仮想化ソフトウェアは無償で手に入るオープンソースソフトウェアを採用している。これによってコストを下げユーザに対しての料金設定を下げることが出来るだけでなく、開発者がオープンソースソフトウェアに慣れ親しんでいるために開発するのが楽になるメリットがある。
また、限られたハードウェアを最大限有効に活用するための技術として「仮想化技術」と「分散処理技術」がある。
n 仮想化技術
仮想化技術を利用することで1台のサーバをあたかも複数のサーバで利用しているように機能させることができ、1台のサーバで複数のユーザ処理に対応する事ができる。これまでより少ない台数でサーバの構築・運用ができるため、電力や冷却コスト、さらに機器の設置スペースが確保できる。
n 分散処理技術
グーグルが自社技術をクラウドコンピューティング用の標準として広めるために一分の情報は開示されているMapReduceと、その情報をもとに開発がされているオープンソースソフトウェアのHadoopが有名。Hadoopを使うことでプロセス同士の対応処理を全て任せることができ、大量のデータを複数マシンに分散して処理することができる。1台で数日かかっていた処理を複数のマシンに分散させることでより短時間で処理を終わらせることが可能となる。
この2つの根底にあるのは「エラー忘却型コンピューティング」という考えで、通常のプログラムと異なりメモリに何かしらのエラーが発生してもエラー忘却型コンピューティングではプログラムに無効な値を返し、処理を継続する点にある。大量のユーザのアクセスに備え、クラウドコンピューティングでは高可用性を維持するためにCAP定理では一貫性を犠牲にして高可用性を優先している。
ユーザ企業が利用する際のメリット・デメリット、課題
企業がシステムを導入する際に「開発するアプリケーションはどこで稼働させるのか」。またSaaSから自社調達まで「何をどこまでクラウドに任せるのか」を決めなければいけない。そこでここでは自社調達からSaaSまでの利用のメリット・デメリット、また導入する際の課題をまとめる。
まずクラウドコンピューティングのメリット・デメリットをまとめると以下のようになる。
n 自社調達を利用する場合
インフラから実行環境、さらにアプリケーションの全てを自前で調達するため、セキュリティや可用性のすべてを自分でコントロールすることができる。反面、設定に時間がかかり、スケーラビリティ[1](システムの拡張性)を得たりすることは難しい。
n HaaSを利用する場合
サービスプロパイダ側があらかじめサーバやストレージの設定を行なっており、インフラの調達や設定に時間を奪われることが無く、自前で運用するよりも可用性が高く、スケーラビリティを得ることも容易になる。反面、プロパイダがどのようにインフラを運用しているかを把握することができず、セキュリティや可用性をコントロールすることができない。
n PaaSを利用する場合
インフラから実行プラットフォームまでを利用するために、開発者はアプリケーション開発に特化することができる。スケーラビリティなども自動で行なってくれるために、開発者は一度アプリケーションコードを書いてアップロードさえすれば自動運用が可能になる。反面、独自のインフラ,言語で記述する際にはほかのプラットフォームへの移植が困難になる。
n SaaSを利用する場合
インフラからアプリケーション全てをサービスとして利用するために、ごく一部しかサービスをカスタマイズすることができない。システムの条件がこちらの要求を満たしてさえいれば利便性が高いし自分たちで調達するのと比べかなりの短期間で済む。ユーザはシステムを利用するだけでいいので、セキュリティの心配などはいらなくなる。
現状の課題として。セキュリティ、データ保管の場所、パフォーマンス、移植性の4つがあげられる。
セキュリティはサービスのほとんどが不透明であることから起こり、自社のデータに第三者が勝手にアクセスしている可能性がある。アクセスログが取れるものもあるが、大切なデータを企業の外に置くことへの不安は残る。データ保管の場所では、個人情報や金融などのデータの保管場所を制限している国が多い。データの物理的なロケーションを指定できるサービスもあるが、できない場合はサービスを利用することができなくなる。
時間サーバが停止することになる。またサービスが突然停止した時に、プロパイダ側がログを公開していれば原因がわかるが、公開していない際には自社のサービスが原因でエラーが出たのかプロパイダ側が原因なのかがわからなくなる。
移植率では、PaaS利用の際に言語などが指定されてしまうために他のサービスに切り替えることが実質不可能になってしまうことがある。最近では改良されつつあるが、一度サービスを利用し始めたらそれを使い続けなくてはならない欠点がある。
まとめ
クラウドコンピューティングのサービスを提供できる企業は資金を多量にもち、データやインフラの効率的運用が可能な企業に限られる。そのため新規参入が大変難しく、少数の大企業(Amazon.comやGoogle)がしのぎを削る事になる。データが集中的に管理され効率的に運用されるのはいいことだが、そのシステムに致命的な欠陥があり、データが大量に紛失された場合には大変な問題となる[2]。
しかし企業がコア業務に集中するためにインフラの設定などの、自分たちの専門以外のものは、コスト削減や基幹業務に専念するためにクラウドコンピューティングにアウトソーシングするだろう。サービスプロパイダ側もユーザが増えるたびに業務を効率化できるために価格設定をより魅力的なものにできる。
さらに、資金の乏しいベンチャー企業などが格安で利用できるメリットがあり、日本型インテグレータビジネスはシステムの運営保守を得意としているが、これからは変化を必要とされるだろう。クラウドコンピューティングはこれから大きく社会を変化させる可能性を秘めている。
参考文献
城田 真琴（2009) 『クラウドの衝撃――IT史上最大の創造的破壊が始まった』 東洋経済新報社 252pp. ISBN-10: 4492580824
[1] IT用語辞典「スケーラビリティ」http://e-words.jp/w/E382B9E382B1E383BCE383A9E38393E383AAE38386E382A3.html
[2] http://www.nikkei.com/article/DGXNASFK2600L_W2A620C1000000/
追記:Machine to Machine センサークラウド (2012/12/14)
M2Mクラウドは、インターネットに接続された各ノード(機器)通しが大抵の場合は無線を用いて相互に通信し、クラウド上で各ノードを制御することや、稼働状況をチェックすることができるサービスである。各ノードからのデータを中央に集め、集めたビッグデータを分析、可視化し実社会の状態をより詳しく把握することができ、インフラや資源を効率よく運用することが可能となる。ネットワーク環境が整ってきたことと、通信機器が小型化かつ安価したために近年になって注目されている。
M2Mクラウドとはいっても単にM2Mをクラウドへ拡張しているだけなので、ここからはM2Mのネットワークと、技術的な課題に目を向ける。
M2Mはセンサネットワーク(図1参照)を用いる。それに加え、センサネットワークではアドホックネットワーク(図2参照)で提案されてきた経路制御プロトコルを利用することが可能である。アドホックネットワークはノードの立場が全て等しいが、センサネットワークは観察者とセンサという異なる立場のノードが存在する。センサネットワークではセンサ間での情報の中継はあるが、互いが終端ノードとなって情報交換することはめったにないために、観察者からセンサ、センサから観察者の1対1の通信に注目することができ効率化することができる。
 |
| 図1 |
図 2
そのためアドホックネットワークを加えたセンサネットワークのネットワーク層の設定には2つの特徴的な話題がある。
1つ目はネットワークの内部処理(図3参照)である。ネットワークの内部処理では、ネットワーク化された複数のセンサを、仮想的な1個のセンサとして観察者に見せることができる。仮想的な1個のセンサに見せることで、観察者は複数のセンサからくるデータを処理する必要がなくなり、観察者が求めている情報だけを得ることができる。センサネットワークではセンサ同士が協調し合い、ネットワーク内部でデータの内容を解析し冗長性を省き融合することができる。ネットワークの内部処理はデータの種類によって不可能であることがある。センサの位置情報や時間情報などを融合することはできないので当初はオプション的な技術と考えられていたが、最近では必須の技術として、アプリケーション本体から独立な部分を考慮した仕組みが作られている。
図 3
2つ目はデータセントリックの概念(図4参照)である。ネットワークがノードのIPアドレスではなくデータの名前を直接扱うものである。従来のネットワークではアドレスセントリックと呼ばれ、個別のノードを識別することが重要視されていた。その場合データを取得する際にはノードアドレスを指定してデータを問い合わせる必要があったが、センサネットワークではデータに位置や時間といった情報が埋め込まれているため、どこから送信されたかはそれほど重要ではない。また、数多くあるセンサの中から特定のセンサを指定して通信することも稀であるために、ノードアドレスを調べて指定するよりもデータを直接扱った方が効率が良いために、データセントリックが注目されている。
図 4
課題
M2Mネットワークにはセンサの電源問題とローカライゼーション技術の2つの実用上の課題がある。
電源問題は、各センサにどのように電源を供給するかが課題である。大量に配置されたセンサのバッテリーはやがて切れてしまうので、屋外であれば太陽光発電や風力発電、屋内であればワイヤレスで充電できるような持続可能かつ強力な電源供給方法が求められる。
ローカライゼーション技術は、センサネットワークからの単なる情報だけでなく地理的にそのセンサがどこにあるのかを把握することが課題である。例として工場内に設置されたセンサネットワークから「工場内で温度以上が発生した」というデータを得た場合、そのデータがどの位置にあるセンサから来たものであるかが分からなければ情報として役に立たないものとなってしまう。GPSは電源問題があり全てのセンサに搭載することは難しいし、化学プラントなどの入り組んだ大規模なパイプラインなどに設置しても期待した精度が常にでるとは限らない。また、GPSは屋内では使用できない。
参考文献
安藤繁，田村陽介，戸辺義人，南正輝編著（2005)
『センサネットワーク技術―ユビキタス情報環境の構築に向けて』東京電機大学出版局 244pp. ISBN-10: 4501324708
No comments:
Post a Comment