大規模、複雑、分散システムに必要な新たなパラダイムと考え方 － Twitter Storm
NoSQL Now 2013の コンファレンスでは、チュートリアルの他２つの基調講演に参加した。２つとも似通ったテーマだが、少し異なった点を強調した。電力系統は電力だけではな く、電力搬送に関する莫大な量のデータや情報も伝達する。これは、電話のシステムに似ている。電話システムはコントロール・システム(シグナリング)と音 声(データ)だ。電話システムも電力系統も国家の根幹をなす重要なインフラであり、予期できる故障や予期できない故障の際にもサービスを停止することはで きない。電力の提供を絶やさないために、インフラやそれに付随するシステムは冗長性、回復性、自己回復性や,フォールトトレラント 性を備えて設計され構築されなければならない。
コンピュータのシステムも同様だ。大規模な分散コンピュータ・システムをモニターしコント ロールするためには、突然であっても不可避な問題に対応できるように設計・構築されなければならない。電話システムや電力系統をモニター・制御するコン ピュータ・システムには特に必要だ。
Nathan Marz氏による基調講演
Nathan Marz氏はBackType社で 分散システム処理システムのStormを開発した、その後BackTypeがTwitterに2011年中頃に買収された後はTwitterに移籍した。 買収の後Storm はオープン・ソースとして提供されている。コードはここからダウンロードできる。NathanのStormに関する講演は ここ (55 分程度)。現在はTwitterを辞めて、自分のスタートアップを経営している。事業内容はまだ未公開だ。基調講演のタイトルは「貴方が書いたコードは正しくない」。実際のプリゼンテーションのここからみることができる。 
Nathan Marz氏
講 演の内容を簡単にまとめるなら、どのようなコンピュータ・システムも絶対に正しく構築されていることはないと言うものだ。彼の論点はどのソフトのコンポー ネントも他の(ソフトであれハードであれ)、信頼性を100%保証できないコンポーネントに依存しており、更にそのコンポーネントもまた他の100%保証 できないコンポーネントと言う風に。ずっと辿っていくと最後は量子力学に辿りつき、そして現在量子力学は完全には解明されていない。だから、どのコン ピュータ・システム100%正しく設計・構築されている訳ではない。確かに、この議論は説得力がある。この状況を如実に表したのが次の図だ。 
その他にコードが正しくない理由には以下のものもある。
* 設計時と実際の入力領域のずれ
* コード内のロジックの間違い
* 急速に変化する要求・仕様への未対応
このため、実際の運用では予期できない故障・不都合を不可避である。そのため、それを想定して運用されるべきである。
NathanはStorm を例に引き、この問題の解決に関して次の５つの点を述べた。
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氏によるブログもある。 この２人の解説と解析はNathanのポイントを理解するのに非常に役立った。更に、Nathan には他のプリゼンもある。タイトルは「Runaway complexity in Big Data and a plan to stop it」だ。これも参考になる。
Lambda Architectureの詳細はかなり複雑で説明には時間を要する。これは筆者が完全に理解していると仮定してだが。であるから、かなり表層的ではある が説明して見たい。完全に理解したいのであれば、上に上げたソースを参照されたい。非常に簡単に言うならば、Nathanのポイントはクエリは全てのデー タの関数だということだ。この「全てのデータ」という点が重要だ。
Nathan のプリゼンから、「Runaway complexity in Big Data and a plan to stop it」
デー タの値は時と共にを変える。言い換えれば。データは今までは、可変(mutable)だと考えれれてきた。データの値は時間と共に変化して、与えられた時 点ではある特定の値がそのデータの値だ。これの問題は、もし間違った値がデータにアサインされていたり、データがシステムの問題で損なわれてしまうと、も うそのデータの正しい値は完全に消えてしまう。 これに反して、もしデータの全ての版(値)を捉えて格納できれば、この問題は解決される。これがNathanが言うところの不変性 (immutability)だ。このコンファレンスでも、他の場所でも「データのdenormalization」ということを何回も聞いた。これは、 以下と同じ概念だ。つまり、データは「生成、リード、アップデートと消去 (CRUD)」 されるものから、単に 「生成とリード」され、決して「アップデートや消去」されるものではないということだ。つまり、新しいNoSQLの世界ではやって来たデータはアップデートも消去もされず、単に格納されるのだ。
も し、全てのデータの全ての版(値)を格納してあれば、どの時点でもどの版を使っても再処理(上の5)が可能だ。しかし、全ての莫大な量のデータをもとに再 処理すれば、 非常に時間が掛かり、不都合である。Lambda Architecture はこの問題を解決すべく、アプリは予め処理したヴュー(precomputed view)を通して アクセスすることで解決している。この点は具体例がないので、分かりにくいが将来のブログでこれを具体的に使っている会社の解について解説する。
あまり詳細な説明ではないが、これが上でNathanが強調した第2項と第5 項である。この講演では触れなかったが他のプリゼンから抽出した図がバッチとリアルタイムの処理を利用してアナリティックスを実装する様子をを良く表している。
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であれば、全てのデータを捕捉して、的確なアナリティックスを適用できる。