リアルタイム・アナリティックスを電力系統へを適用する

筆者の現在の研究の興味は電力系統に対してITと通信(ICT)技術を応用することだ。 ICTの進歩・進展は早い。しかし、ICTだけ独立して動くわけではない。ニーズのないところに投資もついてこない。その恩恵は他の分野にも適用されその 分野の発展や進歩に貢献されるべきである。

センサー技術の発達で、スマートグリッドに付随する装置や機器に安価だが高機能のセンサーが装 着され始めている。それに従って、多くのデータ源から莫大な量のデータがリアルタイムやそうでないペースで生成され、生成されたデータは収集されて解析さ れる。この様な新たなBig Dataの特徴はスピード(velocity)、多種性(variety)、量(volume) (これを3 Vと呼ぶ)で表されるが、今までの relational databases (RDB)では処理出来ない。これが、NoSQLの誕生を招いた。最近参加した NoSQL Now 2013 コンファレンスに関して幾つかブログを書いた。

ここ
ここ
ここ

このコンファレンスでアナリティックスを売りにしている展示会社 を探したが、運よくAcunuという会社を見つけた。 Infochimps 社のJim Kascade 社長をインタビューして以来、アナリティックスの基本を研究し始めた。少しづつ研究するにつれて理解したことはアナリティクスの領域は広く、深く、所謂ア ナリティクスと一言では言えないことを理解した。今まではデータサイエンス屋さんの話が抽象的で詳細を語らないのを訝っていた。でも、今はなぜ専門家が素 人の私に詳細を語りたがらないのかよく分かった。

アナリティックス市場の変遷
Hadoop のアナリティックスはバッチ処理だ。それはそれで結構なことだ。それが向く場所もある。しかし、リアルタイムまたはストリーミング・アナリティックス　は どうだろう。この分野は今大きな注目を浴びている。電力業界では、電気の供給を絶やさないため多くのデータ源からのデータをモニターしている。責任の範囲 によるが、広い地域または狭い地域の電力の需要と供給のバランスを見る必要がある。どちらにしても、異なった生成頻度、スピードや形式のデータが非同期で 飛んでくる。一般的にデータ量が多ければ、多いほどアナリティックスの質が改善される。もちろん、アナリティックスを適用する前に、どのデータが必要か精 査するべきだ。最近のCSCによるInfochimpsによる買収がこのことを如実に語っている。

Acunuのアナリティックス
インタビューの前に数分調査をして、インタビューには45分程度費やした。インタビューにはTim Moreton (CTO) と Dai Clegg (VP marketing)の両氏が応じてくれた。


Tim Moreton氏(左)と Dai Clegg氏

インタビューの後、ブログを書くにはもっと調査　研究の必要を感じた。そのため、インタビューそのものの他、Acunuのドキュメントやその他を参考にしてかなりの時間を費やした。

差別化
全ての会社はその解はユニークであり、競合よりも良いと主張する。では、Acunuの差別化はなんだろう。

全てのアナリティックスはそれぞれユニークだ。リアルタイムの定義同様、ストリーム・　アナリティックスも人によって微妙に定義が異なる。多くの人はこの言葉で多くのことを十把一絡げにしてストリーミング・アナリティックスと使う傾向がある。　Grok Solutions社のようにストリーミング・アナリティックスを提供する会社が数社ある。差別化を精査する情報源としてAcunuのブログが役にたった。もちろん、１つのブログは１つの題目にフォーカスするため、全体を見通せる１つにまとまったホワイトペーパーが望ましい。Timと Dai によればそのうちにそのようなものを用意するとのことだ。

4つの差別化のポイントは:

1. リアルタイムのアナリティックス
2. Cube
3. Cassandra との統合と使い勝手の改善
4. ダッシュ・ボードとアーキテクチャー

リアルタイムのアナリティックス
Acunuはリアルタイム・アナリティックスが差別化の１つであるとはいわなかった。しかし、Acunuがリアルタイムをどのように定義しているのか知るのは有意義だ。Timのブログが良い情報源だ。もちろんハードリアルタイム とは異なる。Timのブログの中でDoug Cutting (Hadoop開発者で、Clouderaのchief architect)の言を引いている:

「コマンドを発して終わるまで、十分座って待てる時間で、終わるまでコーヒーを飲みに行くとか、一晩待たなければならないというものではない。それがリアルタイムだ。」

Acunuのリアルタイムは「API real time」」と呼ばれ、Timの説明では：

Acunu の「API real time」　は運用インテリジェンスとモニタリングのためのものだ。結果はインターアクティブに戻ってくる。大体WebページへのリフレッシュやAPI コールに掛かる通常の遅延程度だ。ストリーミング・アナリティックスは 増加し続け、また持続する。その時点の結果は最新のものだ。それだけではなく、最新のデータは現在までのデータと共にクエリ・解析することができる。 そのため、傾向(trend)、エクセプション、比較などがすぐに検出することができる。

Cube
Acunuの Cube はTimのブログに記述されており、online analytical processing (OLAP) cubeに似通っている。しかし、差異はこのように説明されている。

Acunuのcubeは非常に似通っているが、以下が異なる。新たなデータが到着するたびにインクリメンタルに コンピュートされているので、全てを全部初めからコンピュートしなくても、一度に処理する量は少なくて済む。

Lambda アーキテクチャーでは、 Nathan Marz はアプリとそれがアクセスするデータの間にプリ・コンピュートされたビューを配置した。プリ・コンピュートされたビューがあれば、その時点までに収集され て解析されたデータと共に新たに到着したデータを解析できる。cubeはある時点まで収集されたマルティ次元のデータにある数式を適用した結果を格納して いる。例えば、単に地域毎や時間毎(週、月、年)で売れた商品の個数の合計などだ。ある時点までの結果は既に存在しているので、新たに到着したデータ(最 近の商品の売り上げ個数) は単に加算され、情報が更新される。必要なクエリに応じて、複数のcubes (ビュー)を定義することができる。以下にこの様子を示す。


処理前のデータがいかにリアルタイムで処理されるか。(出典: Tim MoretonのNoSQL Now 2013コンファレンスでのプリゼンより)

注意
これは、Lambda アーキテクチャを実装する１つの方法で、他にも実装の方法はある。しかし、これはこのアーキテクチャーを理解する上で、具体的な例なので理解に役立つ。

Cassandra のインテグレーション
TimはCassandraをデータベースを選んだ理由を以下のように述べた:

Cassandra はスケーらビリティ、性能、複数のデータセンター間サポート、マルティ・マスターアーキテクチャー(no single point of failure)に秀でている。

しかし、彼は続けた:

例外なく殆どのカスタマーはこのシステムを学ぶ際一番困難なのは、Cassandra のデータ・モデリングだ。
…
も ともとのAPIは, Cassandra クエリ言語(CQL)を使ったとしても、非常に簡単過ぎて、本当に非常に簡単なビルディング・ブロックを提供するだけだ。開発者はデータを読み込むスキー マを作成することが必要だ。もし、新らたな機能のために新らたなデータの読み込みが必要となると、それを変更するのは非常に困難だ。

筆 者はCassandra のユーザーでも開発者でもないので、専門的なコメントはできない。しかし、筆者の理解は以下のようだ。一般的にオープンソースの解はオープンであり、柔軟 に対応でき、無料(ライセンスの条件に従う限り)で素晴らしい。問題は使い勝手とサポートの欠如だ。確かに、役に立つコミュニティがあって色々と質問する ことが可能だ。しかし、これを企業のビジネス用に使用するのは、必ずしも容易ではない。そのため、オープンソースの解にはビジネス版が必要なのだ。 Cassandraの場合は, Datastax社がビジネス版をサポートともに提供している。

筆 者の理解では、AcunuはCassandra の上にAcunu クエリ言語 (AQL)を含む層を乗せて、使い勝手をあげている。オープンソースのため、Cassandraには複数の版が存在するが、Acunu は主なものはサポートしている。更に、Apache コミュニティとも密接に連携をしており、アップデートやアップグレードをCassandraのプロジェクトに提供している。

ダッシュボードとアーキテクチャ
可視化(visualization)はBig Data を処理・理解するのには必須だ。また、Cassandra のデータベースとインタフェースするのにも役立つ。Acunuのアーキテクチャを以下に示す。


Acunuのアナリティクスのアーキテクチャ (出典: Tim Moretonの NoSQL Now 2013でのプリゼンより)

Acunu のアナリティクスは複数のデータ・ストリームを同時に受け取ることができる。ストリームはHTTP の他、Flume または Stormで処理できる。

Acunuの今後
Tim とDai によると、現在のアナリティクスの機能は基本的なもので、境界を越えた値の検知とかあるデータの加算値を入手することはできる。もっと、複雑なアナリティ クスの機能が望まれる。例えば、予測。その様な予測機能があれば、電力系統を安定させて信頼性高く運営できる。

最終コメント
Acunu 社のようなベンダーがストリーミング・リアルタイム　アナリティクスの製品を提供していることは頼もしい。それぞれのアナリティクスはたくさんの異なった コンポーネントがそれぞれ特異な方法で結合されている。今後この市場はどうなるのだろうか。今のように多くの会社がばらばらに製品を提供するのだろうか。 それとも、多くの会社が統廃合されていくのだろうか。現在のアナリティクスの会社はSNSやエンタープライズの市場への適用からスマートグリッドのように 新らたな分野へと進出しようとしている。

データセンターに於けるソフトウエア定義の電力とは--その１

この題目はITと電力との接点にあたり、とても興味深い。ITは完全に電力に依存してお り、IT屋であっても電力を意識することが必要となってきた。 しかし、逆にITが電力をコントロールできるようになれば、非常に興味深く素晴らしい。この２回のブログの１回目はデーターセンタにおける電力の問題につ いて述べる。それには電力の価格についての議論も含む。またこれは、２回目のソフトウエア定義の電力の実装に対する準備も兼ねている。ソフトウエア定義の 電力を用いれば、データセンターに於ける諸問題を解決できるのだろうか。

電力不足の問題
データセンターでは電力問題が増加している。典型的な問題は電力不足だ。電力不足が起こるのは以下のような場合だ。

1. 電力会社に十分な電力供給能力がない。
2. 自分の電力システムのコンフィギュレーションが規定されており、容易に改善して電力容量を増加できない。

１ の場合に関しては、更に２つの場合が考えられる。まず自分の立地地域で電力需要が増加して電力会社が十分な電力供給が出来ない場合だ。この場合、電力会社 は送電システム、変電所を含む配電網を改善して整備しなければならない。これには、多額の費用と時間が必要である。更に、電力会社は大抵の場合は十分な電 力供給能力があるが、一時的に需要が増大するとき、例えばピーク時間帯などだ。

２の場合に関しては、自分のデータセンターに与えられてい る電力は制限されおり、それを越えた電力を消費は出来ない。データセンターの電力容量やコンフィギュレーションは固定されており、実際にこれを変更しなけ ればならない。この変更は自分のデータセンターに限らないことが通常だ。データセンターに電力を提供する電力会社はそれに属する変電所やトランスなどを含 めた配電網を整備する必要がある。場合によっては、送電網も改善する必要がある。この改善のの費用は当然データセンター側にも跳ね返る。

更 に言うと、自分のデータセンターの電力コンフィギュレーションはデータセンター全体だけではなく、そのそれぞれのセクションでも同じだ。あるセクションに もっとIT装置をを追加したいとする。しかし、そのセクションに十分な電力が割り当てられていないと、そのPDUのブレーカーが飛んで電気が落ちてしま う。 ラックに十分なスペースがあっても、IT装置の追加はできない。つまり、使用不可能なスペースが生じることになる。この場合、装置場所を考慮する必要があ る。そして、装置を移動する場合それぞれの装置をシャットダウン、 電源を落とし、電源やネットワークの回線を外し、移動して、再び電源とネットワークの回線を接続し、電源を入れて、ブートしなければならない。これは面倒 なプロセスであり、ダウンタイムが生じて、ビジネスにも影響する。 もちろん、複数の装置を移動させる にはデータセンター全体の電力状況を把握して最良のICT装置のレイアウトを考えなければならない。これはなかなか困難なプロセスだ。

以上のそれぞれの場合について言えることは、電力需要の増加が恒常的ウであれば、変更することは正当化されるが、それが稀にしか起こらないのであれば、正当化するのは困難だ。

データセンターでの電力料金
現 在は電力料金はデータセンターでは大きな問題となっている。IT屋だからと言って電力の問題を無視することはできなくなった。 データセンターでの電力料金は複雑で地域毎に異なる。更に、電力料金は様々な要素があり、それぞれの契約は独自なもので一般的な議論は困難だ。しかし、こ のブログのために詳細な議論は簡略化する。実際にはそれぞれのデータセンターの状況や、地域、電力会社によってかなり異なる。

大手のビジネスと産業の消費者用の料金体系には、大抵の電力料金は以下を含む:

*接続費 – 配電網に接続するため
*エネルギー費 –　消費されたエネルギーに対して (単位kWh)
*デマンド費または最大需要電力 – 最大の需要電力に対する料金 (単位kW)

接続費
一般的に多くの電力を必要とすると、電力会社は変電所を含む配電網を整備する必要がある。例えば50MWの電力が必要な場合は20MWの場合に比較して高い接続費を課せられる。

エネルギー費
エ ネルギー費はどれだけの電力を消費したかによって科せられる料金のことだ。これは消費者としてはよく知っている料金だ。使えば使うだけ料金が高くなる。北 と中央カリフォルニア州に電力を提供しているPG&E社の地域では、データセンターのように大量の電力を消費する消費者には、時間によって変化す る料金体系が科せられている。kWあたりの値段は一日のうち時間によって変化する。一般的に午後に一番高くなる。その上、一年のうち何日かはピーク日とい うものが決められており、その日は更に高い料金が上乗せされる。

デマンド費
PG&E社によるとデマンド値は:

住 宅用でない多くの料金はデマンド費を含む。デマンドは１ヶ月の料金サイクルの間で１５分（または短い場合は５分）の間に消費れた最大の電力の計測値であ り、kWで表される。大きなデマンドは通常装置の立ち上がり時に見られる。全ての装置を一度に立ち上げずに分けて立ち上げることで、デマンド費を小さく抑 えることができる。

負荷が変動し、時々突出すると高いデマンド値が科せられる。 出来るだけ、負荷による需要を平坦にすることが肝要だ。

データセンターで電力料金を削減するにはどうすれば良いのだろうか。例えば、以下のような方策を採用することだ。

*適切な電力容量を設計し計画する。
*高騰するデマンド費を避けるため出来るだけ負荷の変動を防ぎ一律の負荷分布にする。
*ピーク時やピーク日の料金に注意を払う。

上 は当然のことの様だが、適正な電力容量を決定するのは容易なことではない。一般に将来の拡張を考慮して余裕を持たして設定し、大きく設定しがちである。ま た、多くのデータセンターはミッション・クリティカルであるため、ピーク時でも停止せず運転する必要がある。また、負荷をできるだけ上下なしに配分するこ とは容易ではない。

いつ電力をコントロールするのか
電力は一旦発電されると大量に貯蔵でき ず、すぐに消費されなければならない。言い換えれば、電力は供給を制御できないので、需要を制御するしかない。これはデータセンターでも同じことだ。制御 とは負荷による需要を軽減することである。ではいつ負荷を軽減すれば良いのだろうか。それは、電力料金が高くなったとき、または電力が不足している時だ。 それに使われるのがデマンド・リスポンスだ。PG&E社はデマンド・リスポンスを次のように説明している:

PG&E 社のデマンド・リスポンスは消費者が需要のピーク時にエネルギー負荷を軽減することができるようにしたプログラムである。 大抵のPG&E社の デマンド・リスポンスは需要のピーク時に負荷軽減のための経済的な誘因を与えるという側面も持っている。

デマ ンド・リスポンスはデータセンターにはあまりなじみのないものだった。と言うのは、データセンターはミッション・クリティカルと考えられて何があっても停 止されないと思われて来たからだ。しかしながら、研究用やテスト用のデータセンターの負荷は軽減することが可能であろう。

その２で実際にどのようにしてソフトウエア定義の電力を実装できるのか、その１つを示そう。

このブログの電力料金に関しては、Power Assure社のPeter Maltbaek氏に色々と助言を頂いた。

NoSQL Now 2013で学んだこと

最近San Joseで開催されたNoSQL conferenceに 参加した。チュートリアル１つと基調講演２つに参加して、更にアナリティックスの会社１社をインタビューした。 筆者の現在のNoSQLへの興味は、スマートグリッドに搭載された多くのセンサーから発せられたBig Dataを解析して電力系統の信頼性を高め、安定度を増加するためのアナリティックスの技術だ。



チュートリアル
このブログではチュートリアルの部分のみを取り上げる。去年のコンファレンスでは「 NoSQL 101」というチュートリアルに参加した。今年は「 Introduction to the Hadoop Ecosystem」というチュートリアルに参加した。このチュートリアルではSciSpike社のVladimir Bacvanski氏がHadoopの仕組みとそのecosystemについて述べた。





Hadoop はBig Data と同義語としてよく使われ、様々なところで述べられている。しかし、簡単な説明ではなかなかその本質に迫ることはできない。筆者はそれぞれの新分野をかな り理解できるまでには、片っ端から簡単であろうが詳細であろうが情報を乱読することにしている。どの分野でも同じことだが、技術的な言葉とその本質には大 きなギャップがある。筆者のブログは簡単な説明と詳細な説明との間に位置するようにしている。

チュートリアルで提示されたものの大部分は 既知であったが、知識の反復や所々にあいた穴を補充するには非常に役にたった。これで、Hadoop がなにでどういう立ち位置かを理解した気がする。このチュートリアルはお薦めだ。チュートリアルの中身をすべて網羅するわけにはいかないので、筆者がラン ダムに選択した項目を取り上げる。

* Big Data のソースはトランスアクション (ビジネス・システム), ドキュメント (テキスト、イメージ、音声、ビデオ), ソーシャル・メディア (Twitter, Facebook, ブログ)と 装置や機器に取り付けられたセンサーなどだ。センサーは特に興味深い。センサーの技術進歩により、以前は出来なかったデータ収集がスマートグリッドから入 手できるようになった。多くの異なった形式のデータが生成されしかも非同期で異なったスピードでどんどん飛んでくる。筆者の興味はこういったデータをいか に集め、集合し、統合解析し、有益な情報を引き出し、電力系統を最適化に利用することだ。
* Big Dataの３つのVはvolume(量), variety(種類)とvelocity(スピード)だ。他のVは veracity (真実性)とviability(実行可能性)だ。
* HadoopはMapReduce と Hadoop distributed file system (HDFS)から成り立っている。
* MapReduce はHDFSのファイルシステムの上で実行される。
* MapReduce では入力データは細か分割され(map)、それぞれクラスターの多くのノードに分散される。それぞれのノードでデータは処理され、集合・併合されて全体と してはデータのサイズは縮小される(reduce)。こういった処理は自動化されており、ユーザーが手動でなにかしなければならないということではない。
* 新しい考え方は「プロセスをデータに持って行く」であり、現在までの「データをプロセスに持って行く」からの大きなパラダイムの変化である。
* Hadoopに関するその他のコンポーネントに関しても簡単に触れる。Hive はデータ・ウエアハウスのインフラだ。HiveQL (クエリ言語)も含む。



* Pig は大きなデータセットを解析するプラットフォームだ。データアナリシスを行うプログラムを表現するハイ・レベル言語から成り立ち、そういったプログラムを 評価するインフラも含む。Pigの顕著な特徴はその構造が並列化に適しており、そのため非常に大きなデータセットを扱えることだ。



* HBase はHDFSの上のコラム・ベースのデータベースだ。



* Zookeeper は分散をコーディネートするサービスを提供する。


* その他に HCatalogはHive の一部でPig, Hiveと MapReduceの整合性を提供する。 SqoopはHadoopの自動インポート・エクスポートを提供し、 Flumeは大量のログ・データを収集、集合し移動させる。



* Hadoopを使用したアナリティックスは原則としてリアル・タイムではなくてバッチ・モードだ。 スマートグリッドでは収集され送信されるデータはリアル・タイム及びリアル・タイムでないものを同時に含む。リアルタイムで到着するデータを処理すること は最近は注目が集まっている。ストリーミング処理でデーターを取得して、アナリティクスを適用することが必要となる。以下のストリーミング処理プログラム が主なものだ。

- Apache S4 (オープン・ソース)
- Esper (オープン・ソース)
- IBM InfoSphere Streams
- Twitter Storm
- Walmart Labs MUPD8



チュー トリアルに出たからって終わったわけではなく、もっと学ぶことが多い。良いことは、NoSQLやアナリティクスの技術を提供する会社はSNSやビジネス・ トランスアクション以外にも適用範囲を広げようとしている。スマート・グリッドは電力、通信とITを融合するものだ。こういった新たに出現するICT の技術はもっとスマートグリッドに適用されるだろうし、そのおかげでＩＣＴの市場も増大する。

データセンターの冷却はソフトウエア定義できるのか

最近ソフトウエア定義されるデータセンターが注目を浴びている。データセンターは周知のようにICTとファシリティの装置で成り立っている。しかし、現在のソフトウエア定義されるデータセンターにはファシリティの装置は含まれない。しかし、幾らICTの装置やそのレイアウトをソフトウエアで定義しても、その装置を問題なく動作させるためには、適度な冷却と電力が必要である。つまり、冷却と電力もソフトウエア定義されないと本当の意味ではデータセンターをソフトウエアで定義したことにはならない。このブログでは、冷却のソフトウエア定義に関して述べる。


冷却のソフトウエア定義を謳っているベンダーはあまり多くない。と言うか、筆者は一社しか知らない。それは、Vigilent社だ。早速知り合いのVigilent社のAlex Fielding氏に話を聞いた。

Alex Fielding氏


Vigilent社
非常に簡単に言うと、Vigilent社はデータセンター・インフラ管理(DCIM)のツールを提供するベンダーである。市場調査会社のGartnerはDCIMツールをを以下の様に定義している。　


データセンターの効率やエネルギー消費をモニター、計測、管理または制御する全てのIT関係の装置（サーバー、ストレッジ、ネットワークなど）やファシリティのインフラの要素（PDUやCRACなど）を含む。


Vigilent社の業務内容
Vigilent はDCIM のベンダーでデータセンターの冷却を管理する。非常に分かり易い。周知のようにデータセンターの運用は大部分はファシリティの人々によってなされる。IT関係の人たちはお客さんとして見られることが多い。しかも、なかなか要求の多い客だと思われがちだ。過去には何回もITとファシリティを統合し、データセンターを効率良く運用しようとする試みがなされた。幾分かの成功例はあるものの、統合管理というのはITとファシリティのどちらにも受け入れにくい提案の様だ。Fielding氏 によれば Vigilentの業績が良いのは２つの理由がある。１つはデータセンターの運用に大きな影響を与える部分を改善するからだ、つまり効率の高い冷却方法だ。40% から50% の冷却に必要な電力消費に影響を与えることができる。つまり、必要な所に必要な量の冷却を提供するのだ。だから、非常に恩恵が見えやすい。何かしなかればならないのはファシリティ側だけで、IT側のサーバーなどのIT機器にはタッチしない。しかし、そのおかげでIT側の人を巻き込む必要もなく、サーバーなどの装置に触れることもないが、IT装置を安定して問題なく運転することができる。ファシリティの人たちは簡単に理解でき、すぐに恩恵が見られるものであれば、非常に受け入れやすいという分けだ。その上、実際のインストレーションから数日でエネルギー効率の改善が見られるとFielding氏は続けた。


実装
Vigilentの技術を説明するのは容易だ。常にデータセンター内の冷却の必要性をモニターして計測し、本当に必要なところに動的に最少必要限の冷却を提供するということだ。サーバーやその他のIT 装置は負荷によって発熱量が異なる。データセンターの負荷は動的に時間毎や日ごとでも変化する。通常将来の拡張を見込んで、電力も冷却も過剰に準備しがちだ。IT装置は必要以上に冷却しすぎる必要はなく、冷却の必要性が軽減されれば冷却もそれに伴って調整されるべきだ。

Vigilentは正にその機能を提供する。一般的にデータセンターの冷却は冷却装置に戻ってくる熱くなった空気の温度を感知して温度調整を行う。しかし、本当に必要なのはサーバーの取り入れ口での空気の温度をモニターし温度調節をすることだ。これが行われなかったのは、以前は容易にサーバーの取り入れ口での空気の温度を測定できなかったからだ。ここ数年、サーバーやラックレベルでの温度や湿度などの環境情況をモニターし計測されるようになった。これを使用すれば、実際にモニター・計測しなければならない箇所で環境情況の情報を入手できるようになり、もっと効率の良い冷却を提供できるようになる。Vigilentは無線センサーを利用してDust Networks のメッシュ・ネットワークを利用して環境情報を収集する。常に温度などの環境情報を収集してモニターして、冷却装置を電源を入れたり、止めたり、またそのファンのスピードを調整することで、冷却量を調整することが出来る。以下の図はこの様子を示している。

Vigilentのシステムの仕組み (出典: Vigilent)


冷却の仮想化
Vigilentが最初に冷却の仮想化を言い出した。冷却の仮想化とは何だろう。あるものが仮想化されるのであれば、それを簡単さらに動的に生成、増量、除去、減量　および移動させることができる。これはサーバーの仮想化に当てはめてみると良く分かる。


冷却は:

• 生成される (冷却装置の電源をオンにする)
  
• 増量される(更に他の冷却装置の電源をオンにするまたは、ファンのスピードを増加する、チラーの温度を下げる)
  
• 除去される(冷却装置を停止を停止したり、スリープ・モードにする)
  
• 減量される(冷却装置の一部を停止したり、ファンのスピードを下げたり、チラーの温度を上げる)
  

移動はどうだろう。冷却って動的に移動できるのだろうか。実際のところ、仮想化されたサーバーも物理的に移動されるわけではない。vMotionの様にバーチャル・マシン(VM)の移動は生成、コピーと除去で実装されている。その仕組みは、新しいVM のインスタンスが移動先のサーバーに生成される、実行状態を元のVMのインスタンスからこのインスタンスにコピーする、そして最後にもとのインスタンスを除去する。この手法は冷却にも適用できる。サーバーのVMが１つのサーバーから他のサーバーに移動されると、当然移動元と移動先のサーバーに対する冷却の要求は変化する。移動元用のサーバーに対する冷却は停止されるか、冷却量を削減できる。これに反して、移動先のサーバーは冷却要求が増加して、移動先用のために新たな冷却のインスタンスを生成することで対応できる。


当然サーバーと冷却ではインスタンスの移動は全く同じではない。冷却のインスタンスはサーバーのVMの様に、移動元と移動先では全く同じコピーではない。物理的なレイアウトなどの幾つかのファクターにより、移動元と移動先では冷却量でさえ異なるかも知れない。しかし、これは移動元から移動先に動的に冷却が移動したと言えるだろう。ということで、冷却はIT機器の様に仮想化されると言う事にする。


以前に述べた電力の仮想化と共に、ソフトウエア定義されるデータセンターが新しく定義される。これによって、データセンターのコンフィギュレーションや要求をソフトウエアで定義すれば自動的にデータセンターを設計したり、最適な運用形態を自動的に生成することができる。これを敷衍すれば、ビルのエネルギー管理にも適用できるだろう。

FERC HQ Closed Due to Power Failure

Earthquake in Japan

If you watch TV, you hear a lot of damages caused by the earthquake in Japan.
Let me give you some info which may be hard to get from the US media.

The hardest hit areas are in the northern part of Japan where I do
not have any relatives or friends. Thus, I have not heard any casuality
or property damages among my circle.

My wife is in Tokyo for an extended period time to take care of her parents and told me
that the jolt in Tokyo was pretty bad. But she did not lose any utility services or anything.
The train services are back to normal.  People do not travel by car like in the US.
Two of my friends were in high rise buildings at the time and one could not go home
because of no train service. The other one walked for 4 hours to get home.

Nuclear power plants to service the Tokyo metropolitan area suffered from the quake.
They do not have enough power and they may need to do rolling blackouts.
As you know, nuclear is used to provide baseline power in Japan as in many other countries.
When I interviewed Tepco AND Kepco, they both were proud of their infrastructures and
reliable services.  I was skeptical about their readiness for acquiring other sources of energy.
This implies the real needs of energy sources other than the legacy ones in Japan and
US.

I will be in Japan in two weeks and  be in the Tokyo area where aftershocks are expected.
I came from the western part of Japan where earthquakes were rare and am
not used to it. The one here in 1989 scared me to death. The one in Kobe
in 1995 was news to me.........I was in the US then and did not experience it.

Zen
P.S> Tepco http://www.tepco.co.jp/en/index-e.html
kepco http://www.kepco.co.jp/english/index.html

データセンター市場としての日本、東京Equinix訪問記

最近完全にサボってます。この記事はここを参照してください。

Equinix東京の大槻氏

サンクスギビングの前のＳＦ，クリスマスの予感

最近のシリコンバレーの家の値段

家の値段も暴落という報道がありますが、シリコンバレーでは相変わらず結構な値段を保ってます。これは相変わらず中国人やインド人の流入が多いことによるのでしょう。目安は購買力から言えば１ドル１００円、１フィート四方は１１分の１にすれば大体１平米。１０月以降は実際の売値はつけた値段を下回ってますね。

NECによる次世代サーバー

時として、ブログのネタを探すのは難しいです。また逆に書くことが多すぎて追いつかないこともあります。 その「逆の状況」が今です。１０月２８日に日本データセンター協会の依頼で米国データセンターの現状について話をしました。そのミーティングで６社のサーバーベンダーの発表もありました。その中でNECが一番「売らんかな」のメッセージが少なく次世代サーバーに関しての話をしていたのでここで取り上げたいと思います。

筆者が見るところ、データセンターの電力不足の問題は我々は本当の問題を解決しようとせず、症状を和らげようとしているだけの様です。つまり冷却の問題です。誰のデータを信ずるかによって変わりますが、冷却に必要な電力はデータセンターの総電力消費の30–60% に達します。冷却の効率化を計れば、電力消費は大きく減少します。そして、PUEが限りなく１．０に近づくでしょう。この方向で、筆者はサーバのようなIT機器の稼動可能の範囲を拡大できるのか興味があります。はっきり言えば、もしサーバーに冷却が必要ないのであれば、全く冷却する必要がありません。本永実氏（NECのプラットフォーム・グループマネージャ）がExpress 5800シリーズに関する発表をしました。製品の詳細には触れませんがその設計哲学に触れます。このシリーズのなかでEco Center series.に関して話されました。

NECの本永実氏

氏はサーバーの設計哲学を発表された。そのハイライトをここに示します。

1. Atom プロセッサと電源の共有:

• この２つを組み合わせることで電力消費を７０％も節減。電源を複数のサーバーで共有すうることで電源の使用率を５０％程度に保つことができます。５０％の使用率が一番交流―直流変換のロスが一番小さいとか。   
• 40 40°Cで問題なく動作。IntelはCPUは３5 °Cまでの動作を保障しています。

2. スペースの削減

• Can accommodate up to 240 servers under 6kVAで２４０サーバーまでサポート.
• 240サーバーで630kg/m2を達成.

3. 設計のノウハウ

·         気流制御

• HDDは高熱に弱いです。高熱を発するCPUはチャシーの後ろ側に置かれHDDは前方に置かれていて、熱の影響を受けません。
• ケーブルのキットも開発されておりチャシーのなかで気流の流れが妨げられるのを防ぎます。

他のサーバベンダーもAtomプロセッサを使用しています。しかし、全体としえサーバーのエネルギー効率化を図るにはいくつもの解を集めて適用しなければならない様です。解のあるものは新しく画期的なものですがその他のものはサーバーを長年開発販売することで培われたものです。筆者はNECを始め多くのサーバーベンダーがサーバーを高温での動作を可能にすることを望みます。日本は夏は高温多湿で冬は温度が低く湿度も低いです。本永氏に外気による冷却に関する湿度の問題を聞きました。この問題は結露が一番大きい問題とのことでした。なかなか困難な問題ですが、今後ともこの問題に取り組んで行くそうです。小さくて軽くエネルギー効率く広範囲の温度と湿度で作動できる高いサーバーが将来のデータセンターのサーバーでしょう。

スマートグリッドの記事を日経ＢＰのＩＴＰＲＯに発表しました。

スマートグリッドという前に、ＩＴ屋さんに電力の仕組みどうなっているのか、どこにＩＣＴが使用されるのかを書いてくださいということで、３回の連載になります。第一回は１１月１２日、２回目は１９日で３回目は２６日です。記事への反応にもよるのでしょうが、来年初頭から更に詳しい記事を書くかも知れません。記事はここから。電力の仕組みはこうなっている 。

test

A BrightTALK Channel

クラウドはエネルギー効率が良いか

これは最近開かれたシリコンバレー・リーダーシップグループ主催のデータセンターエネルギー効率化コンファレンスでのクラウドのパネルの報告です。

モデレータはAccenture のTeresa Tung 氏、パネリストはスタンフォード大学のJon Koomey先生とForrester のJames Staten氏でした。

左から James Staten, Jon Koomey, Teresa Tungの各氏

報告をする前に前提を議論しましょう。クラウドにはパブリックとプライベートがあります。　

更に、どこにクラウドが設置されるかによって外部と内部という分け方もあります。そうすると組み合わせは３つになります。つまり、 (1) 外部でパブリック, (2) オンプレミスでプライベートそして(3) ホストされたプライベートです。パブリックで内部というのはありません。このパネルの議論はパブリック・クラウドとエンタープライズのデータセンターを比較したものです。ですから、ここでの議論はパブリック・クラウドを利用した場合と自前のデータセンターを利用した場合ユーザーに取ってどちらがエネルギー効率が良いかということです。

結論から言うと、コスト比較は割合と容易で多くの例が報告されていますが、エネルギレベルでの比較に関するデータはほとんどないと言う事です。これは、計測が困難なこととクラウド・プロバイダーがデータを発表しがらないからです。以下はこのパネルの要約です。

クラウドの基本 

•  一般にクラウドでは同質のタスクが大量に存在する。
•   規模の経済のおかげでコストは広範に分けられる（エネルギー消費も同様）
• 物理的サーバーからバーチャル・サーバーへの移行はコストとエネルギー消費を削減できる
• クラウドを利用すると企業内のめんどくさいプロセスを回避できる

SaaSとIaaS は規模の経済を利用:

•  SaaSでは同質性はmultitenancyで実装されている。それぞれのクラインとを１つのプロセスやスレッドでサポートするのではなく、１つのインスタンスで全てをするため効率が良い。
• IaaSでは同質性は１つのハイパーバイザーのレベルで実現される

トランザクションのコストの研究が必要:

• クラウドを使用する場合、タスクは自前のデータセンターとクラウド間を信号を送受信することでタスクを遂行する。どちらがよりエネルギー効率が高いかはこのトランザクションのコストも加味する必要がある。

クラウドコンピューティングによる具体的な経費節減とエネルギー削減の例

• 経費節減の例は豊富にあるが、エネルギーに関してはほとんど報告されていない。しかし、Accenture はクラウドコンピューティングのプロバイダーに関する情報を１１月に発表の予定。
• マサチューセッツ州立大学ではDNA 解析に自前のデータセンターでは１０億円程度掛かり数年の年月を要するので、Amazonのサービスを利用したところ、わずか２万程度でしかも数時間で結果を入手できた。

クラウド・プロバイダーにはオーバー・プロビジョニングの問題はないのか

• 一般的にクラウド・プロバイダーはサービスやインフラのプロビジョニングに優れている

• 会社の構成が簡単でフラットであり多くの部門との調整のオーバヘッドが少ない。
• リソースの使用率が６０％以上だと利益が上がると言われている。１つの物理的サーバーにできるだけ多くのVMを配置しようとする。また、一般的にＶＭは長く同じサーバーにとどまらないので、規模の経済をうまく利用できる。

15年後まだ自前のデータは存在するのか

• 大部分のコモディティのアプリはクラウドに移行する。しかし、クラウドは特別な機能や性能を求める人には向かない。そのため、データセンターがなくなることはない。

日本の電力事情とスマートグリッド

最近ときどき日本の方から米国のスマートグリッドについて聞かれることがあります。先日関西電力の河田氏（部長、グループ経営推進本部、ITソリューションサービスグループ）と小橋氏（グループ経営推進本部、ITソリューションサービスグループ）にお目にかかる機会があり、日米のスマートグリッドについて意見交換しました。お二人に関心のあった話題を中心に以下まとめました。

左から小橋氏、岸本、河田氏（クリックで拡大）

米国におけるスマートグリッドの位置づけ、電力会社のねらいについて

米国のスマートグリッドは、インフラの老朽化、電力不足、クリーン エネルギーの取り込みなどがモチベーションです。年間の停電時間が日本では3分なのに対してカリフォルニアでは120分、ニューヨーク エリアでは210分と比較にならない程劣悪な状態で、停電による経済損失は15兆円規模と推定されています。長年にわたり電力戦略をないがしろにして発電所や送電設備を十分に建設してこなかったことが電力不足の大きな原因です。変電所や配電網で使用される機器の耐用年数は40年程度ですが、平均使用年数は約42年で、もう限界という現実があります。スマートグリッド化では、その費用を政府補助や電気代への上乗せにより賄い、電力会社は大きな負担無しに電力網を近代化させることができます（スマートメータ1個当たりの設置費用約2万2千円は電気代に上乗せされる）。また自動検針により各消費者の電力消費量を実時間で捉えられるようになるため、消費者の電力消費パターンの誘導や必要に応じた消費抑制といった方法で、コストの高い発電システムの稼動を抑えることができます。

関電ではインフラの整備は万全で電力不足は無いとのこと。これは東電と同じです。となると、日本のスマートグリッドは何のためにやるのかという疑問が生じます。東電や関電では、ソーラー パネルからの電力をスムーズに配電網に取り入れることと電気自動車のサポート等を計画されておられます。関電はそれに加え、自動検針と電力供給の自動オン・オフも考えておられます。

米国ではスマートグリッドやスマートメータをどう見ているのか

スマートグリッドやスマートメータを知っている人はせいぜい国民の10%程度だと市場調査会社は言っています。電力会社や連邦・州政府の広報不足のため、消費者にとってはある日突然電力会社の作業員が現れてメータを交換して行く、という状況です。60～120日経つと、時間ごと消費電力の情報を見ることができます。しかし、GUIは非常に簡単なもので、単に棒グラフと線グラフで電気使用量とそれによって発生した電気代が示される程度なので、IT技術者には物足りません。筆者のようにこの分野に関心があれば興味を持って消費データを見るでしょうが、それでもまず3日と続きません。何と言っても電気はあって当たり前、電気代の詳細を見る人は稀です。

スマートメータが一般消費者の注目を集めたのは電気代の高騰です。PG&Eがサービスを提供するカリフォルニア州中部地域で、昨年の夏、スマートメータ導入後電気代が2～3倍になった消費者が続出。PG&Eは異常高温によるエアコンの使用増加とメータ交換直前の料金値上げによるものと説明しました。しかし消費者は納得せず、監督官庁へ訴えたり、訴訟を起こしたり、という騒動になりました。その結果、PG&Eはスマートメータ プロジェクトの詳細を発表せざるを得なくなり、また第三者のコンサルタントがメータの正確性などをテストしました。最終的にはPG&Eの言い分が認められましたが、いかにPG&Eとカリフォルニア州政府による広報活動が不足していたか分かります。

日本でスマートメータを導入するのならば、やはりその目的をはっきりさせるべきでしょう。米国でもそのメリットはいろいろと議論されますが、もうひとつしっくりきません。電力会社主導による電力会社のためのスマートグリッド、という感じがするせいでしょうか。ある実験によれば、スマートメータとダイナミック プライシングにより家庭の電気使用量が減り、電気代が10%程度削減できたとのことです。またスマートメータの導入により、国として電力を確保できる、ということもあるでしょう。しかし消費者は普通、電気、ガス、水道代などの細かいことにはあまり興味がありません。しかも電力が余っている日本の場合、消費者のメリットがどの程度あるのか疑問です。

標準や技術

商務省内の国立標準研究所（NIST）がスマートグリッドに使用される技術の標準を定める役割を与えられています。スマートグリッドには電力、通信、ITの技術が駆使されるため、幅広い分野の技術が対象となります。NISTは22の分科会からなるスマートグリッド整合パネル（SGIP）を作って、それぞれの分野での議論を重ねて標準を設定しています。筆者もそのうちの研究・開発の分野に参加しています。SGIPはオープンで、海外からの参加も自由です。現在は標準を一軍と二軍の技術に分けています。一軍の技術はNISTのお墨付きでスマートグリッドの標準と認められたもの、二軍はまだ精査が必要なものです。もちろん、二軍に上がらないと一軍には入れません。例えば、通信のプロトコルではIPだけが一軍で、WiFi、ZigBee、WiMaxは二軍です。ちなみに、メータの大部分にはZigBeeチップが搭載されており、実際にはZigBeeが市場を制覇したと言ってもよいでしょう。余談ですが、最近SprintがWiMax専門のClearwireから人を引き上げたことで、どうやら米国ではWiMaxはお終いのようです。

日本もこの動きに参加しているようです。しかしこれは米国主導のプロジェクトなので、日本の主張が通るのは実際なかなか難しいかもしれません。こちらには、日本が自分たちの標準を押し付けようとしていると言う人もいます。

電気自動車に関して

時々日本に行った折に報道を見ると、電気自動車で日本回復を図っているような印象を受けます。米国でも電気自動車に対する関心は高く、例えばバークレーでは結構電気自動車が走っています。しかし、全体的に電力が足りない上に、1回の充電で一般家庭が1日に使うのと同じくらいの電力（20kWh）を消費するということで、皆が一斉に充電する夜に新たなピークが生じるのではないかと危惧されています。更に1回の充電で走行できる距離が100～110kmということで、一般に移動距離の長い米国西部では、現在のままでは少しきついかと思います。これがボストンとかマンハッタンの中だけとかいうのであれば、ありでしょう。

日本の場合、都市部に住む限りそれほど自動車を必要とはしませんが、郊外ではそうでないようです。いずれにしろ、関電と東電の方たちが言うように、電力不足が無く、走行距離も一般的に短いわけですから、電気自動車の導入は問題ないでしょう。

米国のスマートグリッドから学べることは

インフラがしっかりしており電力不足のない日本にとっては、一見学ぶところが無いかのように見えます。米国のスマートグリッドは、元々電力不足に陥った現状を打開し、かつ今後増加するであろう電力需要を、温室効果ガスを削減しながらサポートするという大前提があります。つまり米国は、国家のエネルギー戦略の一環としてスマートグリッドの導入を図っているのです。日本は戦略の結果であるスマートグリッドを見るだけではなく、国家として今後のエネルギー源の確保と温室効果ガス削減という問題をどう解決するのか、しっかり見据えてエネルギー戦略を構築すべきです。スマートグリッドは戦術であり戦略ではありません。戦略が決まらないのに戦術だけを真似してみてもどうにもなりません。筆者はオイルショックを知っている年代です。外国に頼るエネルギー政策からの脱却を図らないと、必ずどこかの段階で国家として存続の危機を迎えると思います。米国のぼろぼろのインフラを笑っていないで、今こそエネルギー戦略を。米国は恥を忍んでぼろぼろのインフラを認めたわけですから。

最新データセンターワールド（ラスベガス）の報告ー１

その１です。しばらく、書いていないので、読む人もいなくなったかと。。。。。。
先週ラスベガスで開催された データセンターワールドに行って来ました。

 会場のミラージュホテル

CEOのJill Eckhaus氏が今回の主要な題目を発表

３大題目は

1. クラウド
2. セキュリティ
3. エネルギー効率と将来に向けてDCがサポートできるか（電力とか冷却とか）

１と３は今まであったのですが、突然２が出て来ました。基調講演もセキュリティねたでした。これは別の報告します。セキュリティで変わったところでは、電磁妨害なんかが取り上げられてましたね。
それぞれのセッションに関しては今後報告します。

原文ここ。

急速充電の話

東京電力の技術開発研究所を訪問して、東電のサービス地域での電力事情と電気自動車の急速充電の話を伺いました。前回の電力事情の話に続き、今回は急速充電に関して報告します。以下は質疑応答を質問とその回答という形で編集してあります。

お話は電動推進グループの主任研究員の丸田理氏と同じく国際関係担当シニアマネージャーの青木浩行氏です。（写真はクリックで拡大）

丸田氏（左）と青木氏（右）

東京電力は、急速充電コンソーシアムのCHAdeMO協会に参加しています。この協会の幹事会員は東電の他、トヨタ、日産、三菱自動車、富士重工です。

Q：CHAdeMOを設立する際に東電が中心的役割を果たしたのか。
A：急速充電器と電気自動車のインターフェイスを設定した。具体的には、プロトコルとコネクタを指定した。実装は自動車会社が行った。インターフェイスの設定だけなので、内容は各社がそれぞれ実装できる。

Q：CHAdeMOのメンバーはどのような会社か。
A：自動車会社の他、電源、バッテリ、他の電力会社など、200社を超えている。
http://chademo.com/soshiki/kaiinnichiran.pdf

Q：急速充電には特殊なバッテリが必要なのか。ウェブサイトにあったECUとは何か。
A：バッテリは走行中ずっとモニターされている。これを電気自動車で行うのがECUだ。ガソリン エンジンの自動車でもさまざまな電子制御にECUは広く使われている。ECUは小型のコンピュータと考えて差し支えない。ECUは，バッテリの性能・特性に応じて最適に管理する。例えば、バッテリの温度が上がりすぎた時は、流れる電流を抑えて温度を調節する。

Q：CHAdeMOは「茶でも」というのにも引っ掛けていると聞いているが、30分でも長いと感じる人がいると思うが。
A：自動車会社は30分で「満タン」にできると宣伝している。しかし考えてみれば、ガス車と同様、普通バッテリが完全に空になるまで待って充電するのは稀だ。そのため、通常の充電は10分程度で済むはずだ。急いでいる場合、5分もあれば更に40km程度は移動できるようになる。
Q：急速充電対応の車は常に急速充電する必要があるのか。
A：普通の電気自動車は通常充電（100-200V）と急速充電（300-350V）の接続口があるので、どちらでも選択できる。

Q：急速充電するとバッテリの寿命が短くならないか。
A：ECUで常にバッテリの状態をモニターしているので、バッテリに問題が生じそうになれば適切な処置を講じる。例えば、温度が高くなりすぎると電流を下げて調節する。現在までの実験では、急速充電はバッテリの寿命に関係ないという結果が出ている。

Q：日本全国に数多くの充電ステーションがあるが、あれは実証実験のためか。
A：現在200箇所ほどあるが、実用として使用されている。また政府の助成金も出る。

Q：米国での電気自動車の実現についてはどう見ているか。
A：米国の標準電圧の120Vで10時間充電すれば110kmから120km走ることができる。それより速く充電したければ、急速充電のインフラを建設する必要がある。インフラを戦略的に設置すれば、新たな電力需要による電力網への影響はわずかだ。

Q：電気自動車は今後どう発展していくか。
A：日本に続き、ヨーロッパの自動車会社も電気自動車の開発を計画している。米国ではエネルギー省からの助成金でオレゴン州ポートランド市を始め５箇所で電気自動車を展開する予定だ。こういうことで、電気自動車の市場に火が点くかもしれない。

日本では電気自動車が熱い。電気自動車の時代はもうすぐだろうか。

東京電力の電力事情

東京電力の技術開発研究所を訪問して、東電のサービス地域での電力事情と電気自動車の急速充電の話を伺いました。今回は電力事情の話を報告して、次回では急速充電に関して報告します。以下は質疑応答を質問とその回答という形で編集してあります。

Q：一般に、東電のサービス地域で電力不足はあるか。

A：原発の停止時とか新潟地震などの特殊な場合を除き、電力不足はない。

Q：外国からの石油に大量に依存するなど、日本のエネルギー事情は不安定なように見えるが。

A：東電の地域に限らず、日本のエネルギー源は石炭、石油、原子力と十分確保されており、石油の輸入が困難となっても昭和の時代のような問題はない。日本の場合、水力発電を行える場所が限られており、新規発電所の建設はない。あるとすれば、夜間、電力料金の安いときに水を汲み上げておき、電力需要が大きくなる昼間に水力発電で発電する揚水型だけ。

Q：電力需要は、正確に予想できるか。

A：大体前日には1%の誤差で予想できる。

Q：電力のピーク時は何時頃か。

A：年間最大は，真夏の午後２時前後に発生する。冬と春秋は，夕方。この傾向は以前から同じ。

Q：日本ではスマートグリッドはどのように利用されるか。太陽光発電と電気自動車というイメージが強いが。また、スマートメータはどうか。

A：スマートグリッドは太陽光発電をスムーズに配電網に取り入れるのに利用する。電気自動車に関してはあまりメリットがないかと思う。日本の場合、かなり前から3つの時間帯ごとに異なった料金メニューを選択できるようにしており、所謂スマートメータがなくても欧米で言われているスマートメータの一部機能は実装している。ただし、スマートメータが実装されると、自動検針などが可能になる。

Q：電気自動車が実用化されると、充電のために新たな電力需要が発生するのではないか。

A：我々の試算では、10年後に100万から200万台が使用されたとしても、必要とされる電力は総電力消費量のコンマ以下のオーダーで、問題とならない。

Q：DR（需要・供給バランス）はどうか。

A：DRが有効なのは、電力が根本的に不足する状況下。電力不足がない日本ではあまり意味がない。一般的に、エアコンその他の電気製品もエネルギー効率を非常に考慮して作られている。

Q：それでは、東電側から見ると、日本のスマートグリッドは太陽光発電を取り込むためだけのものか。

A：（唯一目的ではないが）それが最優先課題だ。

この取材で分ったことは、

1.     電力供給は、インフラがしっかりしていることもあり非常に安定している。（ちなみに、東電の地域では年間の停電時間は3分程度だが、米国ではカリフォルニアを含む西部で約120分、NYCを含む地域では210分だ。）そのため、安定性を増加させるというスマートグリッドの役割はあまり意味を持たない。

2.     スマートメータを設置する前から、日本ではTOUを実施している（スマートメータ設置後も筆者の住む北カリフォルニアの地域では、未だにTOUが適用されていない）。

3.     日本では電気自動車が実用化されても、電力網に与える影響は微々たるものだ。

以上を総合すると、日本でのスマートグリッドやスマートメータの意義は小さいように思えますが、本当にそうでしょうか。時間帯によって異なる料金がセットされているので、スマートメータ導入でも課金は変化しないでしょう。しかし、スマートグリッドやスマートメータは電力会社だけのものではなく、消費者も巻き込んだ大きな流れだと考えるのであれば、スマートグリッドに対する認識も変化するのではないでしょうか。

まず、各家庭と電力会社がネットワークで結ばれることで電力消費データが共有され、消費者が電力をより賢く使用する一助となると予想されます。更にそのデータを信頼できる第三者に供給することで、データの表示をより分かりやすくしたり、ダッシュボードでデータを提供するなど、新たなサービスの提供が可能となることも考えられます。当初のアプリケーションは、消費電力の表示と電力網のモニターという、電力会社主体のものとなるのはやむを得ないことだと思います。しかし、現在想像もできないようなアプリケーションやサービスが将来消費者や第三者から提案・開発されることは想像に難くありません。インターネットの進化を振り返ると、これは確信できます。こうした点で、スマートグリッドを再生エネルギー源の取り込みに限るのではなく、もう少し広く長い目で見てはどうでしょうか。

最近のシリコンバレーの家の値段ー第二段

Greenpeaceがfacebookの新しいデータセンターを批判

Facebookはこの１月に４億人のユーザからｌこの７月のわずか７ヶ月で１億人増やして５億人としました。この急成長をサポートするためオレゴン州の中央部にデータセンターを建設しています。第一段階(13700平米）の建設が完了しないうちに、第二次の建設(14900平米）を表明しました。この場所が再生可能エネルギを使わない石炭による発電のため、Greenpeaceが噛み付きました。これに対してはFacebookはこれに対して、オレゴン州は気候も良く、温度が上がらないため、チラーを使わないいわゆるwater side economizerを使用しているので、エネルギ効率が良いと反論しています。

しかし、その当のGreenpeaceのデータセンターがクリーンエネルギを使用していないことが判明しています。再生可能エネルギだけでデータセンターの要求を賄うことは不可能です。そうなると排出権を買っていればという事になるのでしょうが、筆者には免罪符を買っているようで、排出権を買っていればそれで良いというのは納得できません。

アメリカの新幹線

今日のＣＮＮにアメリカでの新幹線の導入の記事が出てました。交通省が８０００億円の資金を提供して３１州に新幹線を引くというものです。場所はここ。（地図はクリックで拡大）

カリフォルニアではＳＦからＬＡですが、今のアムトラックに乗るとＳＪからＬＡで約１０時間かかります。車で走れば５－６時間。東京ー大阪より少し長い感じです。飛行機だと５０分程度です。何時ものことですが、全体として車に使うガソリンよりも少ない量のオイルで 電車を走らせることができるということです。但し、全工程を３００ＫＭ以上で走れるわけでもなく、１９０ＫＭ程度の区間も結構あるみたいです。それに、８０００億は最初の工事費で全工事費をカバーできるわけでもないとか。カリフォルニア州は殆ど破産しているので、そんな工事費が出せないような感じです。

なんせ、国が広すぎる。それとやっぱり国民の大部分が自分の好きなときに自分の馬で出かけるというメンタリティですから、これってうまくいかないのか。リニアのことも書いてありましたが、日本の場合ＪＲ東海は最初は名古屋までしか引かないんですね。東京ー大阪を結構行き来する身としては、残念ですが。。。。。