2013年1月12日土曜日

[#Cloud #クラウド ] 2013年のクラウド予測:第三弾:2013年を迎えるにあたり、クラウドに対する4つの新しい心がけ

記事=www.infoworld.com

投稿者=David Linthicum, CTO and founder of Blue Mountain Labs

投稿日=1/3/2013

クラウド業界に身を投じている人間として、今まで学んだレッスンを元に2013年のクラウド業界をどのように生きぬくべきか、4つの提案を推奨したい。

1. 「クラウド洗脳」をやめる

2012年は、引き続き何でもクラウドの一年であった。IT業界の殆すべての製品/サービスはクラウドと何らかの関係を持っていたし、物によっては頭をかしげたくなる様なケースも数多くあった。本来なら、クラウドはある特定の目的(オンデマンド、ユーザ主導、拡張性、従量課金、等)を達成する技術であるべきで、市場も今では理解しつつある、と言える。相も変わらず何でも「クラウド」に絡ませる手法は、むしろベンダーの品位が問われる要因にもなり、むしろ市場の混乱を起こす懸念として位置づけられる、と見るべきである。

2. 何でもクラウドコンピューティングで解決しようとしない事

ITプロフェッショナルの多くは、未だにクラウドコンピューティングをエンタプライズに無理矢理突っ込もうとしている傾向がある。クラウドコンピューティングはアプリケションの条件によっては、かえって混乱や複雑な要件を起こす可能性がある。常に、クラウドに移行する事によるビジネス面での価値を顧客と十分に議論の上、進める必要がある。

3. クラウド化しても、性能/運用/サービス品質の管理は怠らない

クラウドコンピューティングを導入した際につい忘れてしまいがちなのは、実際にクラウドの運用を行わなければいけない、という事である。性能や運用の管理は、常にクラウド上にあるシステムを監視し、問題の未然防止や対策のためにも常に行う必要がある。特に、サービス品質についてはSOA管理の事を指しており、クラウド上では、各クラウドコンポーネントの提供するAPIを管理する事に相当する。

4. クラウドプラットホームを提供する技術を十分理解してから、クラウドのセキュリティを評価する。

エンタプライズ業界では、クラウド上への移行を嫌う最大の要因として、セキュリティが無い事があげられている。本質的には、企業のデータをどこに置こうが、そのプラットホーム上でどのように管理するかによって決まる訳で、そこに着目すべきである。クラウドは通常、必要なセキュリティ上の要件を対策すれば、On Premiseのプラットホーム以上のセキュリティを確保する事も可能である。クラウドに限らず、ターゲットプラットホームを十分知らずして、そのセキュリティの是非を語るのは誤ったアプローチである。

 

以上、クラウドというものは、従来のITプラットホームと何ら変わる物ではない、という事が浸透していくものと思われるが、今までのクラウドが持っていた、「目新しい技術」と言う見方ではなく、従来のITインフラと同じフェアな観点で評価を行う必要があると思われる。

[#Cloud #クラウド ] 2013年のクラウド予測:第三弾:2013年を迎えるにあたり、クラウドに対する4つの新しい心がけ

記事=www.infoworld.com

投稿者=David Linthicum, CTO and founder of Blue Mountain Labs

投稿日=1/3/2013

クラウド業界に身を投じている人間として、今まで学んだレッスンを元に2013年のクラウド業界をどのように生きぬくべきか、4つの提案を推奨したい。

1. 「クラウド洗脳」をやめる

2012年は、引き続き何でもクラウドの一年であった。IT業界の殆すべての製品/サービスはクラウドと何らかの関係を持っていたし、物によっては頭をかしげたくなる様なケースも数多くあった。本来なら、クラウドはある特定の目的(オンデマンド、ユーザ主導、拡張性、従量課金、等)を達成する技術であるべきで、市場も今では理解しつつある、と言える。相も変わらず何でも「クラウド」に絡ませる手法は、むしろベンダーの品位が問われる要因にもなり、むしろ市場の混乱を起こす懸念として位置づけられる、と見るべきである。

2. 何でもクラウドコンピューティングで解決しようとしない事

ITプロフェッショナルの多くは、未だにクラウドコンピューティングをエンタプライズに無理矢理突っ込もうとしている傾向がある。クラウドコンピューティングはアプリケションの条件によっては、かえって混乱や複雑な要件を起こす可能性がある。常に、クラウドに移行する事によるビジネス面での価値を顧客と十分に議論の上、進める必要がある。

3. クラウド化しても、性能/運用/サービス品質の管理は怠らない

クラウドコンピューティングを導入した際につい忘れてしまいがちなのは、実際にクラウドの運用を行わなければいけない、という事である。性能や運用の管理は、常にクラウド上にあるシステムを監視し、問題の未然防止や対策のためにも常に行う必要がある。特に、サービス品質についてはSOA管理の事を指しており、クラウド上では、各クラウドコンポーネントの提供するAPIを管理する事に相当する。

4. クラウドプラットホームを提供する技術を十分理解してから、クラウドのセキュリティを評価する。

エンタプライズ業界では、クラウド上への移行を嫌う最大の要因として、セキュリティが無い事があげられている。本質的には、企業のデータをどこに置こうが、そのプラットホーム上でどのように管理するかによって決まる訳で、そこに着目すべきである。クラウドは通常、必要なセキュリティ上の要件を対策すれば、On Premiseのプラットホーム以上のセキュリティを確保する事も可能である。クラウドに限らず、ターゲットプラットホームを十分知らずして、そのセキュリティの是非を語るのは誤ったアプローチである。

 

以上、クラウドというものは、従来のITプラットホームと何ら変わる物ではない、という事が浸透していくものと思われるが、今までのクラウドが持っていた、「目新しい技術」と言う見方ではなく、従来のITインフラと同じフェアな観点で評価を行う必要があると思われる。

2013年1月11日金曜日

[#Cloud #クラウド ] 2013年のクラウド予測:第二弾:テレコム業界の2013年の動向

記事=www.gigaom.com

投稿者=David Meyer, senior writer for GigaOM

投稿日=1/3/2013

Ovum社の行った市場分析によると、テレコム業界に於ける今後の成長路線はかなり限定される、と予測している。

まず、市場全体の状況を見ると、テレコム業界は2012年の総売上$2兆ドルを達すると見ており、2011年の$1.96兆ドルと比較して、さほどの成長は見込めない、と見ている。

一方では、いくつか成長著しいセグメントがある、とも述べている。その筆頭はモバイルブロードバンド市場であり、年間平均成長率で2016年までに平均して19.2%の成長を維持する、と予測している。

テレコム業界の取り組んでいる事業セグメントを整理したのが下記の図である。モバイルブロードバンドが突出している状況が見える。

2013年1月10日木曜日

[#Cloud #クラウド ] 2013年のクラウド予測:第一弾:DCIM(Data Center Infrastructure Management)にとっての2013年

記事=http://www.datacenterknowledge.com/

投稿者=Jason Verge, Editor/Industry Analyst on the Data Center Knowledge

投稿日=1/3/2013

1.  DCIMのカバーする範囲がエネルギー管理より上のビジネス面での管理に広がる。

DCIMの従来の役割は、主としてデータセンターの電力消費等、インフラの運用コストの最適化のためのソリューションとして位置づけられていた。今後この機能がよりエンハンスされ、データセンター全体の運用効率を監視/管理し、向上させるためのツールとして活用される方向に成長していく事が予想される。電力消費に特に着目していたのは、データセンタ運転コストの最大要因である、電気料金の値上げに伴い、如何にそれを安くするか、という事に最大の関心が寄せられていた事に要因がある。他のコストも同様に上昇の傾向にあり、それを同様に管理するニーズが高まっている。

2.  顧客の知識がますます高まり、その対応が必要になる。

2011年の後半は、まだDCIMの価値についてはあまり市場に浸透していなかったせいか、受注は一部の非常に先進的な顧客に絞られていたのが現状。

今や、DCIMのもたらす価値を理解するユーザ(データセンタ運用者)も多くなってきており、Nlyte社の様に2012年の後半から急激に売り上げを延ばし始めているベンダーが目立つようになってきた。具体的には、RFPの数も多くなってきているの現状のようだ。

3.  市場はかなり混み合っていて、買収、合併等の動きはかなり活発になる。

現在、DCIMソリューションを出しているベンダーハ80~100社に登るが、提供しようとしているソリューションはあまり統一感が無く、ユーザに取っては選択が非常に難しい状況である。恐らく2013年の後半には、10社程度の大手ベンダーが買収を通して広い機能セットを提供する市場構成が期待されている。これらの統合によって、DCIMの市場に於けるメッセージもある程度統一される、と予測される。

4.   新しいタイプの競合の登場

今まで市場にいなかった会社でDCIM事業に参入するベンダーも登場する傾向もある。最も成長する可能性が高いのは、BMCHPIBMCA Technologies4社になる、と予測する。

5.   価格体系が明確になる。

先日登場したGartner Groupのレポートによると、DCIM業界の価格帯をもっとわかりやすくする必要があり、この複雑な価格体系が市場への浸透を妨げている、と述べている。

最も受け入れられているのは、ラック単位の価格体系の様であり、この体系の基づいたソリューションが多く登場するものと予想される。価格帯としては、現在$500~5,000、と非常に幅広いが、最終的には$1,000/ラック程度の価格帯に落ち着くもの、と思われる。

6.   オープン化

業界は、DCIMのオープン化を強く要望している。DCIM間、もしくはDCIMとつながるデータセンタの他のコンポーネントとのインタフェースの同期が必要になっている。

7.  DCIMエコシステムの形成

DCIM業界内でのエコシステムが形成され始める、と予測される。特に開発者同士の連携を通して、DCIMシステム間のデータ互換性の確保が大きなメリットとして出てくる。所詮、DCIMはデータセンタ内の様々なデータを集めて分析をするツールである故、より多くのコンポーネントと接点を持つ事が重要になる。

8. 視覚的な機能より分析機能を重視

DCIM市場の当初は、様々なレポートやコンソール表示等を通して、視覚的に訴えるソリューションが多く、マーケティング重視のビジネスモデルであった、と言われている。これが、より機能重視の市場に移っていき、今後は異なるシステム間を統括する機能、広い範囲のデータを収集して高度な分析を行う機能、等の面でベンダー間の競争が激化するもの、と想像する。

9.  リアルタイムデータ

リアルタイムに情報を収集する事の重要性はあるが、市場は、それよりもDCIM内の様々なコンポーネントが統合的に動く事とシステム間の互換性がより重要な要件となる。

10.  25%の市場シェア

Nylite社のMark Harris氏の予測によると、2013年の6月までには25%の市場シェアが確立する、考えられている。

2013年1月9日水曜日

[#Cloud #クラウド ] クリスマスのAWS障害で学んだ事:Netflixの受けた影響をそれを防止する方法 #RightScale #AWS

by  @ RightScale
クリスマスイブ、さらに翌日のクリスマス当日にかけて、AWSはUS東海岸地域でのELB(Elastic Load Balancing)サービスの一時的な中断が事象として起きました。ELBオペレーションのほんの一部が影響を受けただけに留まっていたが、この地域全体でELBがらみの操作に遅れが生じる、等の影響が出ていた事が報告されている。AWS本体がこの障害に関して出した報告はここにあります。

この報告によると、AWSのユーザのかなりの数が影響を受けた事が示唆されます。実際には、各ユーザの受けた影響はELBの利用依存度によってまちまちであった様です。影響を受けた会社の中で、Netflix社が含まれていたようで、彼らの事後報告、さらにこの障害に関する所見がここで記載されています。


クラウドプラットホームベンダー固有のソリューションに頼るな

毎度の事であるが、この障害に関する業界内での議論において、マルチリージョン(複数のリージョンでシステムを分散/多重化させる)ソリューションを採用する事の重要性が、Netflixを含めた、ベンダー間で議論されている。RightScaleでは、こういった障害対応のためにマルチリージョンでシステム構築を行う事を推奨してますが、現実的にマルチリージョン対応するのはコストや管理工数面で難しい、という現実も理解してます。以前にこの課題に対してWhite Paperを書いており、是非その内容を参考ににしてもらいたい。リンクはここ

RightScaleの顧客の多くは単一のリージョンで稼働しており、ベンダー特定のツールを使う事を避けるようにアドバイスするように心がけています。よく見えない、ベンダーへの依存状態が発生しないようにするためです。

ところで、今回起きたAWS障害はUS東海岸全体に影響を及ぼしたが、結果的にはELBという単一のサービスで起きた問題に過ぎないのです。もしウェブサイトが別のロードバランシング技術(HAProxy、Nginx、等)を使用していたら、今回の障害では全く影響を受けなかったはずです。このような対策手法は別のブログ記事で説明してます。


特に、項目#9の、"クラウドロックインに注意"という項目がポイントです。

ベンダー特定の運用ツールやアプライアンスは、一時的にアプリケーションの運用効率を向上する事が可能になりますが、同じベンダーの提供する他のツールとの連携も強いケースが多いために、障害発生時にも想定以上の問題が発生する可能性が高くなります。クラウドベンダーに依存しないツールを利用する事により、特定のクラウドプラットホームに縛られない、クラウド依存度の無いアプリケーション運用が可能になり、結果的に障害対応に強いシステム運用が可能になるはずです。マルチクラウドもメリットは特定のクラウドの障害に対応するソリューションになるだけではなく、コストの最適化にも寄与します(より安いクラウドへの移行が可能になります)。

ELBというのは、正にベンダー固有のツールそのものです。もちろん、システムのセットアップ時にELBの存在は非常に便利ですが、問題はこのツールが他のクラウドから利用出来ない、という制限のみならず、障害が起きた時にシステム全体にその影響が及ぶ、という事であります。今回の障害は、ELBに対するマニュアル操作が原因による障害、という事で報告されているが、ELB運用全体のかなり局所化された部分での障害であったにも関わらず、ELB運用全体に影響を及ぼした、という事がやはり問題なのです。

疎結合によるコンポーネント構成の良さ

我々がクラウドアーキテクチャを提唱する時の強調するのは、クラウドシステム構成を疎結合されたコンポーネントで構成する事です。今回のAWSのELBでの障害は、独立した単独サービスコンポーネントが起こした問題のように見えるが、実際にはELBはAWSのインフラと深く関係を持ったものであり、ここでの障害は、他のコンポーネントにも影響を与える可能性は非常に高い、と評価しています。Netflix社は、クラウド自動化に関して非常に多岐に渡る工夫をしており、特にオープンソフトウェアの利用に関してはAsgard等、画期的なものもある。しかしながら、AWS固有のコンポーネントの利用に関しては以前から疑問を持ってはいました。

今回の障害の根本的な原因を分析するにあたり、GigaOmは非常に興味深い分析を行っており、また、Netflix社のこの障害に対する対応についても詳しく記述している。注目すべきは、問題は元々自動化されていた操作をエンジニアがマニュアル操作をしたために起きた、という事に起因しており、これはRightScaleでも強く提唱している、管理操作の徹底的な自動化の推奨にも同期する要件であります。

どんな自動化プロセスも、その立ち上げ時に人為的な操作によってスタートさせられる訳であるが、この操作も、アクセス権管理、ログ記録/監査、の機能によって管理されるべきであります。マニュアル操作は、(基本的に不完全である)人間が行う以上、必ずエラーが伴うものであり、自動化されたシステムによる修正、トラブル防止の機能に依存する事が重要です。

高可用性、耐久性の高いシステムがゴールであるべき

今回のAWS障害は、クラウドの"ベストプラクティス"、がどうあるべきか、という事を改めて認識するよい機会である、と考えるようにしている。システムの運用設計を行う際に、様々なショートカットが講じられるが、最初は小さく、局所化された障害であると思われる事が、その機能に依存する他のサービスコンポーネントに順次影響を及ぼし、最終的に大きな障害につながる、という事が見えた事例である、と言える。

システムの可用性、耐久性を確保、強化出来るコンポーネントは市場に数多く存在します。それらをどのように組み合わせるか、という事に関しては、様々な事例、そして実際に組み合わせる実証試験を行う事によって最善の選択を行う事が出来る、と考えます。特に、クラウドプラットホームと独立した、アクセス管理ツール、ログ管理ツール、システム監査ツール、等はRightScaleでサーバテンプレートとして数多く準備しており、様々な組み合わせを非常に安く、簡単に行う事ができる事が可能です。

特に、RightScaleのフリーエディション(無償版)を利用する事によって、コストをかけずにクラウドアーキテクチャの設計を行う事が出来ますので是非利用してみてください。

2013年1月8日火曜日

[#Cloud #クラウド ] 2012年のスマートグリッド市場を振り返って(よくまとまってます)

2012年のスマートグリッド市場を振り返って
Jeff St. John:  December 19th, 2012

2012年は、スマートグリッド業界にとっては幼少期を終わり、いよいよ社会人として世の中に飛び出ている状態をイメージしている人も多いのでは、と思われる。スマートグリッド業界には、何十年も電力業界で身を立てている人もいれば、本の数年前にVCの資金を元手に最新技術を持って市場に参入している人もいて、人によってかなりその印象も異なってくる、という意見もある。

新しいフェーズに移行しつつある、と思われる要因は一つある。ここ数年の間は、政府の助成金、それも数十億ドルにも及ぶ資金が政府から市場に投入され、今や、そのほとんどが使い終わった状態にある。また、この資金の流入に伴って膨大な金額のベンチャーキャピタル資金もだんだんとその意義について疑問視されるようになってきており、動きが基本的に遅く、厳しい規制に縛られた電力業界に果たしVC投資に見合うROIがあるのかどうか、という意見も登場している。

いろいろと反論も多く登場する中、技術的にはかなりの進歩が見られているのも事実である。ユーティリティ事業者のレガシーのシステムに先進的なデマンドレスポンスシステムを統合したり、エネルギー節約の技術も多く登場している。さらに、障害に対する高度な対応技術や、電力の配信技術の高度化等、ユーティリティのユーザへのサービス向上の面で寄与している技術が多く登場している。

一方では、新しい技術を自社のグリッドに導入する事に多くの混乱も生まれているケースが目立つ。特に、電力業界は何十年も殆ど変化が見られなかった業界であるが故に、高度な技術革新に対してはあまり準備ができている、という事は言えない、と思われる。特に新しいスマートメータ技術を導入する事によって生まれる膨大な量のデータをどのように活用するか、についてはまだまだ動きが遅い、という事が言える。

次の5つの項目が、2012に起きたスマートグリッド業界でのトレンドです。

1)買収
スマートグリッドのスタートアップにとって、資金の調達はかなり厳しいものになってきている。2009年の後半に発表されたエネルギー省による$40億ドルに及ぶ助成金の可決は市場の活性化に大きく寄与しており、その資金のおかげで、何十万台ものスマートメータやエネルギー管理ソリューションの導入が実現している。ただし、この大きな波の後に続くものが無く、特にスマートメータの導入に関しては導入スピードが極端に落ち込んでいる、という事実が判明している。2012年は、2011年よりもスマートメータの導入数が少なくなる、と見込まれており2013年も同様に成長の殆ど見られない事が想定されている。

これは、スマートグリッド業界に膨大な資金を投入したベンチャーキャピタル業界にとっては非常に厳しい問題を投げかけており、特にAMI(Advanced Metering Infrastructure)技術や、ホームエネルギー管理技術等の業界に大きな影響を与えている。既に2012年の最初の3つの四半期はVC投資の金額が今まででも最低を記録しており、いくつか大きな投資が失敗している状況が投資家をこの業界から遠ざける事に拍車をかけている。

お金の流れの変化は、業界全体の動きに顕著に現れている。2012年はIPOした企業が一社もいない上、以前からIPOすると宣言していたSilver Sptings Network社等の様な会社も、延々とIPOを実行出来ずに躊躇している状況の中、買収の噂が立ち始めている。

一方では、スマートグリッド業界での買収攻勢は非常に活発化している。ただし、VCが期待しているレベルでのリターンが実現していない、というのも事実である。代表的な買収案件としては、Eaton社が$118億ドルで買収した、Cooper Industries社や、プライベートエクイティのMelrose社が$23億ドルで買収したドイツのスマートメータ大手、Elster社の買収Blackstone Groupが$20億ドルで買収したVivint社、等、数十億ドルクラスの買収が登場している。



2)スマートグリッド投資の行方
数千万台を超えるスマートメータが北米全国に導入され、電力供給の効率向上と新しい機能が電力料金の値上げを十分に見合う価値を生む、という事が約束されている中で、もっとその効果を早く、そして明確にしてほしい、という市場からの要望が強くなってきている。このメリットが明確に説明出来ていないがために、延期/中止になったプロジェクトもあり、必ずしもスマートメータの市場は順風満帆という訳ではないようである。

一方、電力供給グリッドの監視等のシステム化、自動化については、今後スマートメータの導入よりも早いペースで動くもの、と予測されており、特にバイヤーである電力会社にとってもメリットが明確で、尚かつ自分でコントロールが出来る、という面がスマートメータと事情が異なる。昨年アメリカ東海岸で起きた台風サンディーの被害に対する対策等も含めて、今後この辺の技術が大きく伸びていくもの、と期待されている。


3)HAN (Home Area Network)
2012年においては、HANに関連した技術や新製品が数多く登場した。市場が十分に立ち上がっていないにも関わらず、ZigBee、Z-Wave、Wifi等の無線技術を採用した室内ディスプレイや、ウェブインタフェース等が数多く登場している。Oklahoma Gas & Electric、Arizona Public Service等の電力事業社は、HANの重要性を認識し、実際にスマートメータの導入とともにHAN技術の導入を行ってる。しかしながらこれらの案件は、ユーティリティが独自に進めているプロジェクトで、顧客へのシステム提供をすべて一社で行っているケースである。消費者が近所の店に出かけて自分の欲しいデバイスを購入出来る様なユーザ主体のプロジェクトからはほど遠いものである。

これが最近になって少し変わりつつある。既に4200万台のスマートメータ(Itron社製)を導入したSouthern California Edison社は昨年Rainforest Automation社とホームセキュリティ大手のADT社とパートナーシップを結び、自社のスマートメータと、民間のHANソリューションと接続を可能にするプロジェクトをスタートさせている。また、Nest社と呼ばれるサーモスタットのメーカは、iPhoneとのコミュニケーションが出来る$250もする製品を発表し、販売が堅調に伸びている。サーモスタットの大手、Honeywell社は、自社の製品とOpower社の提供するHEM製品との接続をモバイルデバイスを通して行う様な開発を行っている。


4)ビッグデータ関連
スマートグリッド業界にとって、ビッグデータはいよいよ本格的に必要な技術になってきている、と言える。以前は、ひと月に一回程度しか収集されていなかったメータの情報は、スマートメータの導入によって毎時間できるようになっている。これは、月に720回データを収集する事であるが、計測が15分に一回になるとその回数は一挙に2,880回にもなる。毎回のデータ収集で、電力使用量に加え、様々な他の情報も一緒に送信している上、スマータメータは今後家庭内の他のデバイスともコミュニケーションを行う事にもなるので、電力供給事業者にとっては、今までに経験した事の無い、大量のデータを処理、分析する必要性が出てきている、という事である。

GTMリサーチ社によると、このトレンドが、2012年に$3.2億だったスメートグリッド分析技術市場を一挙に$140億ドル規模の市場までに急成長させる牽引力になる、と予測している。ITベンダーの大手である、Oracle、IBM、EMC、Microsoft社等の動きは当然ながらも、今後スタートアップ関連のベンダーも多く登場し、成功を収める事が期待されている市場である。代表的な企業として、Versant社、Autogrid社の様な非構造型のデータベース上にアプリケーションを開発するベンダーや、Hadoopを採用しているOpower社、Tendril社、EcoFactor社等がある。



5)システム統合
スマートグリッドのこれからの重要な要件は、如何に設置した大量のスマートメータを統合して新しい価値を生むシステムに変えていくか、という課題である。新しいシステムというのは、単に電力の消費状況を詳細に収集する機能だけではなく、その大量のデータを利用して新しいビジネスを生む事が問われている。例えば新しい課金のシステム、顧客サービス、停電時の対応サービス、グリッドの監視、等、議論されているアプリケーションの数は非常に多い。

これらのシステムはMDM(Meter Data Management)と呼ばれ、Oracle社が行った実態調査によると、スマートメータを導入した電力事業社の約半数がMDMの導入に手が回っていない、という状況が明らかになっている。

これらの新しいスマートグリッド技術は、電力業界に実際に導入され民間に展開されるようになるまで非常に長い時間がかかる、という業界固有の特性についてはあまり考慮されていないケースが目立つ。スマートグリッドソリューションとしてInfosys社、SAP社、Silver Springs Networks社、Echelon社等、多数の会社が様々なアプリケーションを開発し、導入に向けてかなり積極的な営業活動を行ってきた。話題になったアプリケーションの種類としては、変換機のステータスを分析する機能、停電時、停電の影響を受けているデバイスから通信を行うシステム(Last Gasp Notification)、等があり、電力業界に取って、こういったシステム化の付加価値を非常にわかりやすい様にデザインしたものが多いようである。

分散グリッドの自動化に対しても同様の動きがあった。従来、この世界は、大手企業がフルターンキーで提供する独自仕様によるシステム設計、構築が常識的であった世界で、Schneider Electric、ABB、Seimens、GE、東芝、日立、Alstom、Esaston Cooper社等がその代表である。これが最近になってシステム間の互換性の重要性と価値が見いだされるようになり、尚かつ、コストを下げる大きな要因になる事も理解し始めている。小規模なスマートグリッドインフラの実装、他社の大規模でマンドレスポンスシステムとの相互接続等が大きなトレンドになりつつある。

電力事業社間のシステム相互接続に関しては、IBM、Infosys、Wipro、Capgemini、Accenture等の大手IT企業が名を連ねている。これらの会社の戦略として、電力事業社を対象に、クロスプラットホームでのスマートグリッドシステムの統合をソリューション提供する事である。特に積極的な動きを見せているのは、Cisco社であり、自社のネットワーク技術を駆使して、Itron社、Elster社、等のスマートメータ大手ベンダーとの協業、Distribution Automation業界ではAlston社、Cooper Power社(現在Eaton社)等との協業や数多くのスタートアップベンダーとのパートナーシップも発表している。



2012年は、総合的に分析すると、電力事業社がスマートメータの導入を終了し、一通り落ち着いたところで、これらのメータインフラを如何に有効活用するか、という事を考え始めた一年であった、という事が言えよう。2013年は、今度このスマートメータを有効活用する数々の実証試験を見る事が出来る一年になりそうであるが、ますますもってIT業界との接点の強化、クラウドコンピューティングや、ビッグデータ等の特定技術やインフラの活用が見いだされる事になりそうである。非常に数の多い顧客層と大量のユーザが存在する市場だけでにこの業界に於ける勝ち組と負け組との明暗はかなりはっきりしてくるもの、と思われる。

2012年12月20日木曜日

[#Cloud #クラウド ] 2013に向けて、クラウドアーキテクチャに留意すべきポイント (RightScaleのソリューション)

2013に向けて、クラウドアーキテクチャに留意すべきポイント
by Brian Adler @ RightScale

2012の終わりを迎えるにあたり、今一度クラウドコンピューティングを運用する上で重要な要件を整理していきたい。
次の9つのポイントは、来年2013年に向けてクラウドの運用をより効率よく行うためのアドバイスです。

1)インスタンスサイズと数についてはよくテストを行ってから決める事
  • どのクラウドもCPU、メモリ、ディスクがそれぞれ異なる複数のサーバサイズを提供する。まず、各社どのようなレンジのサーバ規模を持っているのかをしっかり調べましょう。
  • 各サイズに対して、負荷テストを行い、自分のアプリケーションにとって最も的確なサイズのものを選ぶようにしましょう。アプリがCPUを多く必要とするがメモリはあまり使わない、という事であればマルチコアCPUのサーバインスタンスを選ぶようにしましょう。
  • データベースに関しては、一般的にデータベース全体がメモリ上に乗るようにする事が勧められます。データベースサーバに関してはいろいろとハイメモリ型のサーバの種類があるはずです。
  • RightScaleは、PlanForCloudと呼ばれるツールを提供しており、アプリケーションのクラウド上での運用に関してコストを最適化するためのサービスを提供しています。例えば、On-Demand型か、Reserved Instance型等の価格体系の比較もしてくれます。

2)サーバ障害は起こるもの、と想定してシステム設計する
  • 自動スケーリング機能を設定して、トラフィックの急増等のシステム負荷やシステム障害に対して動的に対応出来るようにしましょう。例えば、まずは再手減のサーバアレイの規模(台数)を設定し、どんな状態でも必ず必要最低限の数のサーバが稼働している様、保証しましょう。RightScaleの機能を利用して、サーバアレイの自動的なプロビジョニング/デプロビジョニングをかなり詳細までカスタマイズする事が出来ます。カスタマイズはスクリプトを通してプログラミングする事が出来、サーバの動的な操作に加えて、サーバの動的な監視、アラートの発信、バッチ処理のキュー管理、等の機能がサポートされています。機能の詳細は、RightScaleのクラウド管理自動化機能を参照ください。
  • データベースは、複数のゾーン(AZ)やクラウド事業者間で複製を作り、単一のゾーンやクラウドでの障害の影響を受けないように設計します。システム性能への影響も懸念として出てきますが、クラウド上での運用は、ユーザが冗長性設計をする事が必須事項となってきてます。
  • データベース等、IPが時と共に変更を要する内部コンポーネントについては、動的なDNSを採用しましょう。逆にユーザが直接アクセスするアプリケーションの入り口部分については固定IPを設定しましょう。

3)ゾーン障害に備える
  • アプリケーションの各Tier毎に、2つ以上のゾーンにサーバを分散させましょう。クラウド障害時の被害を最小限に抑えるための配慮です。
  • すべてのデータ(データベースに加え、共有ファイルシステムも含めて)を複数ゾーン間で多重化しましょう。

4)クラウド障害に備える
  • 同じクラウド事業者の異なるソーンのみならず、異なるリージョン間でもデータのバックアップや同期を取りましょう。リージョン全体が障害を起こすケースも起きており、そういう事態に対して、別のリージョンで待機させているデータをデータ回復に活用する事が出来ます。

5)とにかく自動化
  • データベース/データストアの別リージョン/クラウドへの定期的なバックアップを自動化しましょう。特定のリージョンで障害が起きた時でも、アプリケーション回復が非常に楽になります。
  • 常にシステムの状態を監視し、自動的にアラートを発信、問題が小さい内に対策が打てるようにしましょう。RightScaleはこの監視を自動化するためのツールを多く備えています。

6)とにかくキャッシュする事
  • まず殆どのアプリケーションは、キャッシングを活用する事で性能を向上させる事が出来ます。また、Webフロントアプリの部分にしろ、バックエンドのデータベースシステムにしろ、同様です。
  • アプリケーションサーバに内蔵されているキャッシュは使わない事。内蔵型のキャッシュは、データベースの一部をアプリケーション上で管理する形で行われますが、アプリケーションサーバを複数使用する際、またアプリケーションサーバを動的に増減させる場合も、結果的にデータベースサーバに対するこのアプリケーションサーバからのキャッシュ関連のアクセスが急増し、システム性能の大幅な低下に直結します。
  • 独立したマルチノード型のキャッシュシステムを採用しましょう。大量メモリのサーバを一台を用意し、キャッシュ専用マシンに設定する事も可能ですが、このマシンが障害に会った時、すべてのキャッシュが落ちない様にするための配慮が必要ですので、そのための多重化対応です。
  • もう一つ、アプリケーションサーバに内蔵されたキャッシュのソリューションの問題は、アプリケーションサーバにオートスケーリングが適用出来なくなるからです。新規のアプリサーバを立ち上げる度に、キャッシュ全体の設定が変わり、キャッシュ間で大量のデータが移動する結果になります。これはシステム性能を大幅に下げる要因になり、勧められません。独立したキャッシングシステムを容易に構築する技術を持っているベンダーが数社存在します。特にキャッシュの動的なオートスケーリングは、CouchBase等のベンダーがソリューションを提供してます。

7)同期を取る事
  • データは、他のゾーンに同期を確保しておきましょう。特定のゾーンでの障害時、そこにマスター、スレーブのいずれかがあったとしてもシステムのダウンタイムは最小限に抑える事が出来ます。
  • 合わせて、他のクラウド/リージョンにもデータの同期を取っておきましょう。大規模な障害が起きた際に、影響を受ける心配の無い場所にデータのバックアップを確保する安心感は大です。
  • 可能であれば、さらにスレーブとして、Ephermalディスク(EC2等でついてくるメモリ)上に一つ設定する事を勧めます。AWSの障害の内、EBSが原因によるものも多く、EBSへの依存度を少しでも下げるためにもこの対策は必要である、と言えます。

8)意外なところで起きる障害要因を早期発見する
  • もしアプリケーションコードがGitやSVNレポジトリで管理されている場合、このレポジトリの稼働状態がアプリケーション全体の稼働状態に影響を及ぼします。RightScaleを通して自動化やインフラストレクチャのデザインはしっかり設計し、障害への対応もしっかりしていても、アプリケーションサーバが動的にコードを入手する事が出来なければ、そこが重要な障害要因になります。

9)クラウドロックインに注意
  • ベンダー特定の運用ツールやアプライアンスは、一時的にアプリケーションの運用効率を向上する事が可能になりますが、同じベンダーの提供する他のツールとの連携も強いケースが多いために、障害発生時にも想定以上の問題が発生する可能性が高くなります。クラウドベンダーに依存しないツールを利用する事により、特定のクラウドプラットホームに縛られない、クラウド依存度の無いアプリケーション運用が可能になり、結果的に障害対応に強いシステム運用が可能になるはずです。マルチクラウドもメリットは特定のクラウドの障害に対応するソリューションになるだけではなく、コストの最適化にも寄与します(より安いクラウドへの移行が可能になります)。

上記のソリューションをより詳しく記載したWhite Paperは次のリンクからダウンロード出来ます。