2013年09月22日

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

筆者の現在の研究の興味は電力系統に対して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)の両氏が応じてくれた。

acunu-pic1.jpg
Tim Moreton氏(左)と Dai Clegg氏

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

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

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

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


リアルタイムのアナリティックス

Acunuはリアルタイム・アナリティックスが差別化の1つであるとはいわなかった。しかし、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 (ビュー)を定義することができる。以下にこの様子を示す。

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

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

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-pic3.jpg
Acunuのアナリティクスのアーキテクチャ (出典: Tim Moretonの NoSQL Now 2013でのプリゼンより)

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

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

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

2013年09月17日

大規模、複雑、分散システムに必要な新たなパラダイムと考え方 – Netflixの場合

NoSQL Now 2013 での2つ目の基調講演はNetflix社の Adrian Cockcroft氏で、講演のタイトルは「Netflixでどの様に、スケールラビリティと複雑さに対応しているか」であった。最初に書いたブログでNathan Marz氏による講演について解説したが、Cockcroft氏の講演もテーマとしては、大規模、複雑、分散システムにいかに取り組むかを実例で示している。しかし、Marz氏とは異なった視点から述べているので面白い。この2つがすべてではないが、大規模、複雑、分散システムは我々が今までに知っていたシステムの設計や運用とはかなり異なっているので、実際に設計・構築・運用しなければ分からないが、この2つの講演でその輪郭が見えてきた。

大規模、複雑、分散システムに関しては想定外の故障はつきものだが、この講演ではそれにも関わらず、いかにしてスケーラビリティを維持しながら信頼性も維持するかについてだった。想定外の故障・不都合を回避するためには、システムを冗長性とフォールトトレランスを加味して、設計・構築・運用されなければならない。では、どうすれば良いのか。それは、しばしばシステムの運用を意図的に妨げ、システムがそれに耐え得るように変更を加えることだ。つまり、こういった種類のシステムは故障や不都合が起こるのは当たりまえでそれに備えるべきだということだ。この講演そのものはオンラインでは見ることができないが、同様のプリゼンは ここでみることができる。

netflix-nosql-1.jpg
Adrian Cockcroft氏

netflix-nosql-2.jpg
OODA loop

Adrianは現在、競争に勝つためには、新たな商品やサービスを素早く市場に出すことが肝要だと述べた。 今までの組織構造では「即市場へ」戦術を実行するには、問題が多い。戦闘機の空中戦で使われるOODA Loopを例に引いて、新たな組織の構造について述べた。上の図のループは「objective (目的)」、「orient(方向づけ)」、「decide(決定)」、と「act(実行)」から成り立っている。それぞれには、企業関係に適用するために、関連するキーワードが対応している。順番に「innovation(革新)」、「Big Data」、「culture(文化)」、そして「cloud」だ。

OODA loopを企業に応用

それぞれの項目に付けられている長方形のコメントは:

Objective: 顧客をモニター、チャンスを掴む、競争できる素早い動きと顧客のニーズの把握
Orient: リサーチと解析
Decide: 反応を計画、社内の同意取り付けと必要なリソースを割り当て
Act: 顧客を巻き込む、提供し実装


それぞれのポイントは説明を要しないだろう。

新しい市場に対応するために企業が必要なこと

企業は素早い市場の動きに対応してそれに見合った製品やサービスを迅速に提供しなければならない。

それに対して、4つのポイントが上げられた。 presentation):
1. ビジネス、開発とオペレーションを1つの組織に。BusDevOpsと言う名前。彼のプリゼンのページ14にNetflixに示されている。
2. NoSQLを使いデータをDenormalize (データーをまとめずに、データの全ての版を保存)
3. 素早い展開のためOps(運用)からDev(開発)に責任を移動
4. クラウドを利用して、素早い展開のためOps(運用)からDev(開発)に責任を移動


どのように、大規模、分散、複雑なシステムを設計し運用するのか
どのように分散・複雑なシステムを設計・運用しても、故障・不都合は避けられない。これを克服するには、時々運用を意図的に妨げて、それから学び、学んだことをシステムに反映させることだ。Netflixの ストリーミング・サービスはAmazonクラウドの上で実行される。Amazonクラウドは地理的に分散された複数の地域から成り立っている。自前のシステム問題満載の上に、クラウドも時々故障・不都合が起こる。そのために、NetflixはChaos Monkeyと Chaos Gorillaを開発した。

簡単に言えば
Chaos Monkey,はランダムに実際に実行中のインスタンスを停止して、それでもビジネスに影響しないようにするためのツール。
Chaos Gorilla はChaos Monkeyと似ているが、 Amazon のある地域全体の動作不能状態を作りだせる。


これらは、Simian Armyというツール群の1部だが、オープンソース化されている。

Netflix オープンソース・システム(OSS)
Netflix は多くのこういったシステムをオープンソース化した。Netflix Open Source System (OSS)はクラウド用に設計・構築されている。 ここから入手できる。なぜ、Netflixはオープンソース化に踏みきったのだろか。

それは、
自前の技術をベスト・プラクティスまたは標準とするため
最高のエンジニアを雇用、辞職を防ぎ、やる気を起こさせるため
Netflix の技術ブランドを世に知らしめす
エコシステムから恩恵受ける

ということだ。

この後、実際にどのようにシステムを意図的に実行不能にするのかについて述べた。しかし、ここでは、長くなるので述べない。興味のある人はこの プリゼンのページ23からto 27を参照のこと。

全インタネット・トラフィックに於けるNetflixのストリーミングの位置
インターネットのトラフィックは年々増加しているが、そのうち何が大きなウエイトを占めるのだろう。Adrian はSandvine 社によるトラフィックの情報を提供した。 (2012年11月時点2013年3月時点) トラフィックの増加はこの間に39%増加した。 Netflixのトラフィックはどちらの時点でも全体のトラフィックの約33%を占める。2013年3月にはNetflixとYuTube のトラフィックを合わせると50%を超える。ヴィデオのストリーミングが大きなパーセントを占めることは知っていたが、この規模だとは思わなかった。明らかにNetflixはインタネットのトラフィックに影響があることが分かる。

Netflixの参考情報
インラインのスライドでは、見つらいので、以下にまとめた。.
コード
技術ブログ
スライ


コメント
電力系統は大規模、分散、複雑システムだ。それを保守するシステムはNetflix のようなシステムが必要だ。どのように、それを適用するかは今後のチャレンジだ。
posted by infogreen at 22:58| Comment(0) | ICTとエネルギー

2013年09月14日

大規模、複雑、分散システムに必要な新たなパラダイムと考え方

NoSQL Now 2013のコンファレンスでは、チュートリアルの他2つの基調講演に参加した。2つとも似通ったテーマだが、少し異なった点を強調した。電力系統は電力だけではなく、電力搬送に関する莫大な量のデータや情報も伝達する。これは、電話のシステムに似ている。電話システムはコントロール・システム(シグナリング)と音声(データ)だ。電話システムも電力系統も国家の根幹をなす重要なインフラであり、予期できる故障や予期できない故障の際にもサービスを停止することはできない。電力の提供を絶やさないために、インフラやそれに付随するシステムは冗長性、回復性、自己回復性や,フォールトトレラント 性を備えて設計され構築されなければならない。

コンピュータのシステムも同様だ。大規模な分散コンピュータ・システムをモニターしコントロールするためには、突然であっても不可避な問題に対応できるように設計・構築されなければならない。電話システムや電力系統をモニター・制御するコンピュータ・システムには特に必要だ。

Nathan Marz氏による基調講演

Nathan Marz氏はBackType社で 分散システム処理システムのStormを開発した、その後BackTypeがTwitterに2011年中頃に買収された後はTwitterに移籍した。 買収の後Storm はオープン・ソースとして提供されている。コードはここからダウンロードできる。NathanのStormに関する講演は ここ (55 分程度)。現在はTwitterを辞めて、自分のスタートアップを経営している。事業内容はまだ未公開だ。基調講演のタイトルは「貴方が書いたコードは正しくない」。実際のプリゼンテーションのここからみることができる。

marz-1.jpg

Nathan Marz氏

講演の内容を簡単にまとめるなら、どのようなコンピュータ・システムも絶対に正しく構築されていることはないと言うものだ。彼の論点はどのソフトのコンポーネントも他の(ソフトであれハードであれ)、信頼性を100%保証できないコンポーネントに依存しており、更にそのコンポーネントもまた他の100%保証できないコンポーネントと言う風に。ずっと辿っていくと最後は量子力学に辿りつき、そして現在量子力学は完全には解明されていない。だから、どのコンピュータ・システム100%正しく設計・構築されている訳ではない。確かに、この議論は説得力がある。この状況を如実に表したのが次の図だ。

marz-2.jpg

その他にコードが正しくない理由には以下のものもある。

* 設計時と実際の入力領域のずれ
* コード内のロジックの間違い
* 急速に変化する要求・仕様への未対応

このため、実際の運用では予期できない故障・不都合を不可避である。そのため、それを想定して運用されるべきである。

NathanはStorm を例に引き、この問題の解決に関して次の5つの点を述べた。
1. 測定し、モニター
2. 不変性(immutability)を強調
3. 依存性を最小化
4. 入力領域を精査
5. 再処理(recomputation)

このうち、1, 3と4は説明が要らないくらい明らかだが、2 と5については頭を捻った。正直なところ、話について行けなかった。そのため、この講演の後少し調べてみた。最初の「コードは間違っている」が主体であるかのように思ってしまったので、本筋を見誤った。

彼が実際に話たかったのは、ラムダ・アーキテクチャー(Lambda Architecture)のことだ。Lambda Architectureの詳細は彼が今準備している本で語られる。本のタイトルは「 Big Data – Principles and best practices of scalable realtime data systems」だ。本はまだ出版されていないが、執筆中の本の一部を出版社のManning社の特別プログラムで読むことができる。それはManning Early Access Program (MEAP)だ。日本語版の出版は未定だが、これは必読に値する。

途中版を読んだJames Kinley 氏はこのように語っている。
私はこのimmutability(上の項目2)とrecomputation(上の項目5)をシステムに組み込むというアイディアが良いと思う。 Lambda Architectureはバッチとストリーム処理を同時に使い多くの問題を処理できる最初のシステムだと思う。 焦点がリアルタイムへ移行している現在、Big Data の開発者とアーキテクトにとっては必読の本だと思う。


その他にもChristian Gügi氏によるブログもある。 この2人の解説と解析はNathanのポイントを理解するのに非常に役立った。更に、Nathan には他のプリゼンもある。タイトルは「Runaway complexity in Big Data and a plan to stop it」だ。これも参考になる。

Lambda Architectureの詳細はかなり複雑で説明には時間を要する。これは筆者が完全に理解していると仮定してだが。であるから、かなり表層的ではあるが説明して見たい。完全に理解したいのであれば、上に上げたソースを参照されたい。非常に簡単に言うならば、Nathanのポイントはクエリは全てのデータの関数だということだ。この「全てのデータ」という点が重要だ。

marz-3.jpg

Nathan のプリゼンから、「Runaway complexity in Big Data and a plan to stop it」
データの値は時と共にを変える。言い換えれば。データは今までは、可変(mutable)だと考えれれてきた。データの値は時間と共に変化して、与えられた時点ではある特定の値がそのデータの値だ。これの問題は、もし間違った値がデータにアサインされていたり、データがシステムの問題で損なわれてしまうと、もうそのデータの正しい値は完全に消えてしまう。 これに反して、もしデータの全ての版(値)を捉えて格納できれば、この問題は解決される。これがNathanが言うところの不変性(immutability)だ。このコンファレンスでも、他の場所でも「データのdenormalization」ということを何回も聞いた。これは、以下と同じ概念だ。つまり、データは「生成、リード、アップデートと消去 (CRUD)」 されるものから、単に 「生成とリード」され、決して「アップデートや消去」されるものではないということだ。つまり、新しいNoSQLの世界ではやって来たデータはアップデートも消去もされず、単に格納されるのだ。

もし、全てのデータの全ての版(値)を格納してあれば、どの時点でもどの版を使っても再処理(上の5)が可能だ。しかし、全ての莫大な量のデータをもとに再処理すれば、 非常に時間が掛かり、不都合である。Lambda Architecture はこの問題を解決すべく、アプリは予め処理したヴュー(precomputed view)を通して アクセスすることで解決している。この点は具体例がないので、分かりにくいが将来のブログでこれを具体的に使っている会社の解について解説する。

marz-4.jpg

あまり詳細な説明ではないが、これが上でNathanが強調した第2項と第5 項である。この講演では触れなかったが他のプリゼンから抽出した図がバッチとリアルタイムの処理を利用してアナリティックスを実装する様子をを良く表している。

marz-5.jpg

Lambda Architecture: Nathanのプリゼンから、「Runaway complexity in Big Data and a plan to stop it」

この図で述べられている、ソフトのコンポーネントの説明をつけておく。
Kafka: Big Data用に構築されたメッセージングシステム
・ Storm: オープンソースで、分散型リアルタイムコンピューティングの用のシステム
Hadoop: オープンソースで 、高信頼性、スケーラブルな分散システム用
Cassandra: キー・バリューのNoSQLデータベース
Riak: a NoSQLデータベースでAmazonのDynamo ペーパーの概念を実装
HBase: Hadoopで使われるデータベース、分散型、スケーラブルなBig Data用
ElephantDB: Hadoopからキーや値をエクスポートするのに使用されるデータベース
Voldemort: 分散型のキー・バリュー型のストレッジ・システム

最終コメント
スマートグリッドから発生するデータは莫大な箇所から、また異なったスピードで発せられる。あるものは、電力の需要と供給量の変化のようにリアルタイムのものもあれば、電力系統内の装置や機器のコンフィギュレーションのように殆ど不変のものもある。最後に示したLambda Architectureであれば、全てのデータを捕捉して、的確なアナリティックスを適用できる。
posted by infogreen at 05:10| Comment(0) | ICTとエネルギー