「“サーバーは止まるもの”を前提とするCassandraの実装はIoTと相性がいい」説：Database Watch（2015年4月版）
今月は「Cassandra Summit Tokyo 2015」から、IoT（Internet of Things：モノのインターネット）を支えるデータベースとして活躍する「Cassandra」のいまを取材してきました。
自動車と「Cassandra」の関係
2015年4月21日、「日本Cassandraコミュニティ」が主催する「Cassandra Summit Tokyo 2015」が開催されました。今回はその中から自動車のIoT分野におけるCassandraとの関係について見てみましょう。Cassandraは分散型NoSQLデータベースの一つです。
IoTの潮流の一つとして、自動車などの車両に搭載したセンサーのデータを収集し、そのデータをあらゆるサービスやビジネスにつなげようとする動きが始まりつつあります。この“自動車のIoT”とCassandraは相性がいいようです。
ここからはCassandra Summit Tokyo 2015で聞いた、CassandraとIoTの相性、Cassandraの弱点を補った実装例の一つを紹介していきます。この例は、IoTに限らず、Cassandraを使ったシステムを考える際のヒントになるでしょう。
IoT部品を載せやすい自動車、「無停止」「拡張性」が強みのCassandra
そもそも自動車などの車両は高額な「耐久消費財」といえます。IoTを実現するには、センサーや通信用の部品を搭載する必要がありますが、自動車自体の価格が高いこともあるので、自動車全体の原価に占めるIoT機器のコストは比較的小さくて済みます。
環境省の資料によると*、日本国内の温室効果ガス（CO2）排出量の約17％が自動車など運輸・輸送業に関わるものであるとのことです。社会的責任としても経済的な意味でも、こうした企業・組織では、CO2削減や効率向上のためのシステム投資の意義を見いだしやすく、輸送の効率化などを目指す意味でも、IoT投資のモチベーションは低くはないでしょう。
*環境省「2013年度（平成25 年度）の温室効果ガス排出量（確報値）について」（PDF）「表3 二酸化炭素（CO2）の排出量」より
昨年（2014年）は自動車ビッグデータビジネスの動きが加速しました。自動車のセンサーデータを商品開発に役立てたり、自動車保険の保険料に反映するなどの動きも次々と実現しています（関連記事）。こうした動きを皮切りに、今後はインフラ設備のモニタリングや個人向けのマーケティングなどの領域でのデータ活用が見込まれています。
自動車でいうと、データ取得の容易さも見逃せません。自己診断システムで用いる「OBD2（On Board Diagnosis second generation）」、あるいは車載ナビゲーションシステムから出力されるものを用いることが多いようです（関連記事）。データ送信は通信モジュールだけでなく、スマートフォンの通信機能を用いるものもあります。いずれにしても実装自体はさほど難しくありません。
一方、こうした車両から送られるデータを処理する側システム要件はどうでしょうか？
ほとんどの場合、センサーデータは絶え間なく生成され、データベースに送信されます（実装によってはセンサー端末側で一定の処理を施した上でまとめて送信することもあります）。ですから、データを格納するデータベースサーバーには無停止が求められます。また、日本国内では一般乗用車の保有台数だけでも6000万台といわれていますから、スモールスタートで考えたとしても、きちんとサービスを展開するならば当初から相当なスケーラビリティ（拡張性）を考えておく必要があります。
このとき必要になる、「無停止」と「拡張性」という要件は、Cassandraの特性にぴったり合致しています。
「無停止」「拡張性」にCassandraはどう応えているのか
講演で登壇したウルシステムズの岸本康二氏は、Cassandra開発プロジェクトの初期段階から「（実装の）センスがいいな」と目を付けていたそうです。というのも、多くのデータベースは「止まらないように」さまざまな工夫をしていますが、Cassandraでは「サーバーは止まるもの」という前提に立ち、分散と協調によって、サーバーが増えても減っても「動作し続ける」ことを重視しているからです。
「サーバーは必要な分だけ足せばいい。不要になったら減らせばいい」という考え方は、サーバー台数の最適化にもつながります。こうした思想は、インフラコストの面で有利であるだけではなく、運用時の人的コスト削減にもつながります。
Cassandraの運用保守を経験したことがある、あるITエンジニアは「夜中に運用担当者全員にシステム障害のアラートが一斉通知されても、Cassandraそのものは正常稼働していたので出動する必要がなかった。（体力的にも心理的にも）楽だったよ」と話していました。「動作し続けること」の恩恵として、トラブル対応で疲弊することがなくなり、エンジニアの士気維持にもつながったということです。もちろん、深夜の緊急対応に工数を掛けずに済む可能性がある、という点も見逃せません。
Cassandraの弱点と対応策
しかし、Cassandraにも弱点はあります。岸本氏が所属するウルシステムズではCassandraを用いつつ、弱点を補うように機能拡張したIoTソリューション「BlueRabbit」を提供しています。このプロダクトの機能は、皆さんがCassandraを運用するときの良いヒントとなりそうです。
どんどん書き込めるCassandraにはACID性に弱点がある
岸本氏の講演をベースに、まずは、Cassandraのトランザクション機能について見ていきましょう。
Cassandraは、データの書き込みには強いのですが、基本的にはコミットログを持たず、ロールバックの仕組みもありません。つまり、データの一貫性を保つための機能は持ち合わせていません。ですから、いくつもの書き込みが行われたとき、そのデータがきちんと書き込まれていることや、書き込まれた結果が次のデータにきちんと反映されているか、といった情報は、100％信用できないかもしれません。
一般的なリレーショナルデータベース管理システム（RDBMS）であれば、データの一貫性を維持するための仕組みとして、コミットログやトランザクションログなどを持っています。
ここが、Cassandraが一般的なRDBMSとの決定的に違う点です。
独自実装と、「テッパン」な組み合わせ「Cassandra＋Apache Spark」
そこで、BlueRabbitではCassandraに対して、排他制御やトランザクション機能を追加しています。こうすることで、Cassandraの長所を生かしつつも、在庫管理のように、数値の誤りが許されないシステムでも使用できるようにしています。
また、Cassandraは分散型であるため、データを集約して分析するのが得意ではありません。その点を補う際に使えるのが、分散環境で並列処理を実行する「Apache Spark」です。最近ではビッグデータ分析に、このCassandraとApache Sparkを組み合わせたパターンを採用するケースが少なくないようです。
BlueRabbitでは、さらに必要に応じて「PostgreSQL」や「MySQL」などのRDBMS、あるいは「Apache Hadoop」と組み合わせることも可能だそうです。
岸本氏によると、この仕組みはすでにテレビ放送受信機からのデータを収集する放送システムや、スマートフォンのGPS機能を利用したヘルスケアアプリ、さらに本来ならRDBMSを用いるようなECサイトでの実績も出てきているそうです。
IoTの時代要請に応えられる構成が見えてきたことから、Cassandraは今後この領域で強みを発揮できそうです。
Copyright © ITmedia, Inc. All Rights Reserved.