テラバイトの恐怖：モノのインターネットを制御するには特別なデータベースが必要

データが降り注ぐ

非リレーショナルデータベースは、大量のセンサーデータをまとめる際の煩わしさを軽減するのに役立ちます。

Pixel Cの背面には冷蔵庫にくっつけられるだけの磁石が内蔵されている。写真：ロン・アマデオ

テクノロジー調査会社ガートナーの数字を信じるなら、2020年までにネットワークに接続されたデバイスは250億台に達するでしょう。「モノのインターネット（IoT）」は、冷蔵庫から照明、ガスメーターまで、私たちの身の回りのあらゆるものにネットワーク接続されたセンサーを埋め込みつつあります。これらのセンサーは「テレメトリ」を収集し、データを収集している人に送信します。例えば、「精密農業」では、凧やドローンに搭載されたセンサーが、作物から反射された近赤外線の分析に基づいて植物の健康状態に関するデータを収集します。センサーは土壌の水分や化学組成を測定したり、微気候条件を経時的に追跡したりすることで、農家が何を、どこに、いつ植えるかを決定するのに役立ちます。

用途を問わず、IoTセンサーは膨大な量のデータを生成します。その量と多様な形式は、標準的なリレーショナルデータベースでは到底収拾できません。そのため、企業が膨大な情報量に対処するために、非伝統的なNoSQLデータベースが数多く登場しています。

リレーショナルデータベースがセンサーデータの処理に利用されるのは、決して今回が初めてではありません。むしろ、多くの企業がこの使い慣れた構造化された世界に安住し、そこから抜け出せずにいます。一方、Temetra（公益事業会社にメーターデータの収集・管理手段を提供する企業）のように、センサーデータがピラニアの群れのように突然押し寄せてきたことで、リレーショナルデータベース管理システム（RDBMS）の世界から追い出されてしまった企業もあります。

IoTデータの小川から奔流へ

2002年、テメトラはアイルランドを拠点とする小さな会社でした。当時、従業員はわずか5人でしたが、すでに数十万台の水道メーターのデータを蓄積し、顧客の水道管を通る流量を分析していました。「より多くのデータがあれば、水道管の分析をより正確に行うことができます」と、テメトラのマネージングディレクター、ポール・バリー氏は言います。「ご想像のとおり、水道事業体の予算は無限ではありません。例えば、漏水修理に2500万ドルの予算があるとします。漏水箇所の追跡に多くの時間を費やすことになるかもしれません。それよりも、水道管の中で最も効率の悪い部分に取り組む方が、費用対効果が高く、はるかに効果的です。」

そのため、Temetraは顧客のメーターに関する詳細な情報を提供するだけでなく、そのデータを集約して「漏水しているメーターの場所をすべて表示」といった実用的な結果につなげています。10年間にわたり、Temetraはセンサーから膨大なデータを収集し、顧客にそのレベルの洞察を提供してきました。

2002年当時、同社は当時誰もが行っていたこと、つまりRDBMSへのデータ保存を行っていました。「2002年当時は誰もがSQLデータベースを使っていました」とバリー氏は言います。「Googleが型破りな動きを見せていましたが、一般的に誰もがモノリシックな方法でアプリを開発し、バックエンドにRDBMSを使用していました。」こうして、Temetraのメーターセンサーデータは、由緒あるリレーショナルデータベースであるPostgreSQLに大量に蓄積されるようになりました。

10年間は順調に進んでいましたが、2012年がやってきました。SaaS（サービスとしてのソフトウェア）を販売していた同社は英国市場に参入し、アイルランドよりもはるかに規模の大きい水道事業者との取引を開始しました。事業拡大に先立ち、Temetraはバリー氏が「爆発的な成長」と呼ぶものを経験し始めていました。英国進出に伴いデータ量が飛躍的に増加したため、同社はデータをより適切に保存し、分析できる別のデータベースを検討する必要がありました。

PostgreSQLが、予想されるデータ量の急増に対応できなかったわけではない、とバリー氏は述べた。RDBMSの問題は、データ量の増加に伴って管理負担が爆発的に増加することだった。「バックアップが非常に大きくなっていました」とバリー氏は述べた。「マスター/スレーブ型データベース（マスターデータベースを信頼できるソースとみなし、スレーブデータベースをそれに同期させるデータベースレプリケーション方式）では、データ量が増加するにつれてレプリケーションの処理に時間がかかるようになりました。データ量が増えれば増えるほど、負担は大きくなっていました。」

従業員わずか5名というTemetraにとって、管理コストを抑えつつデータベースの信頼性を高めるデータリポジトリを見つけることは大きな課題でした。チームは、非伝統的なデータストアであるMongoDBやCouchDB/Couchbaseなど、様々な選択肢を検討しました。最終的にBashoのRiakとCassandraのどちらかを選ぶことになりました。TemetraがRiakを選んだ最大の理由は、Riakが瞬く間に稼働を開始できたことです。「テスト環境はすぐに整いました。Riakを1時間ほど使って、すぐにデータを保存できました」とBarry氏は語ります。「Riakなら、管理負担を抑えつつ、高い信頼性を維持できると確信していました。」

バリー氏によると、Cassandraはそれ以来大きく進化したという。しかし、彼が小さなチームで使いやすいデータストアを探していた当時は、「高可用性を実現するためのセットアップと適切な設定が少し面倒だった」と感じていた。

IoTカーテクノロジー企業VCAROのCIO、ザック・アルトニュー氏は、「それは驚くべきことではありません」と述べています。彼はArs誌の取材に対し、既存のNoSQLデータベースを検討した結果、RiakではなくDataStax Enterprise Cassandraを選択したと語っています。VCAROのこの決定は、Cassandraのスキルを持つスタッフが既に存在していたことが大きな要因です。アルトニュー氏が述べたように、Cassandraを成功させるには、正しく実装する方法を知る必要があり、それはつまり、データスキーマを適切に設定する方法を知ることを意味します。

バリー氏によると、Temetraがデータストアを評価した際、「Cassandraが正しく設定されているか100%確信が持てなかった」とのことです。TemetraはRiakとCassandraの両方にデータを書き込み、それぞれのソリューションの性能を検証しました。バリー氏は、ノードを取り外してクラスターが正常に動作することを確認するなど、いくつかの標準的な手法を用いて2つのソリューションをテストしました。

RiakとCassandraのデータに違いはありませんでした。問題は、当時のCassandraのツールが少々限られていたことでした。Barry氏はクラスタの稼働状態に関する情報を見つけることができず、クラスタが健全な状態にあるかどうかを容易に確認できませんでした。一方、Riakではクラスタの健全性の確認は簡単でした。Riakには当初から「便利なツール」が付属していたとBarry氏は言います。「コマンドを1つ実行するだけで、クラスタが健全な状態にあることが確認できました。」

AltneuとVCAROにとって、重要なのはコストと、データベースの設定から運用に至るまで、あらゆる設定を厳密に管理することです。GoogleやAmazonのような企業がすべての作業を肩代わりしてくれるような、データベース・アズ・ア・サービス（DBaaS）は存在しません（本当にありがとうございます）。コストに関して言えば、Cassandraはオープンソースなので、かなりの費用を節約できます。VCAROは軽量Linuxサーバー用のクラウドホスティングを利用して、月額1,000ドル未満でクラスターを運用しています。

対照的に、Temetraはデータベースのコア部分に手が伸びるのを避け、パフォーマンスもそれほど重要ではありませんでした。PostgreSQL RDBMSには十分な余裕がありました。それよりも、膨大なセンサーデータをどこに保存するかという選択は、何よりも信頼性を重視していたとバリー氏は言います。

「理にかなっているように聞こえますが、一部のNoSQLデータベースでは、それほど強力な信頼性の保証はありません」とバリー氏は述べた。「パフォーマンスと引き換えに高速クエリを実行できますが、100万回に1回は失敗する可能性があります。そのような状況は許容できません。（高速に流れるセンサーデータの場合）データを保存し、正常に保存できたと報告できるのは一度きりです。保存が完了したら、（クライアントに）保存完了を伝えるのは私たちの責任です。」

矛盾したデータの何が一貫しているのか

ウォルグリーンは全米に8,000店舗を展開しており、Riptideは約半数の店舗にセンサーを埋め込み、空調、照明、灌漑制御、火災・安全管理などを監視しています。各ビルシステムにはプログラマブルコントローラーが搭載されており、センサーの監視やオン・オフ、調光、温度設定などを行います。Riptideはクラウドベースのビル管理ツールの開発を手掛けており、AT&T、Verizon、Ultaなど、大規模・小規模の小売店が入居する商業ビルの屋上に設置されたセンサーと接続しています。同社のウェブサイトでは、「施設を自動操縦にしましょう」と謳っています。

4,000のウォルグリーンには、約100万個のセンサーが設置されています。リップタイドのCEO、マイク・フランコ氏によると、そこから出力されるデータは多岐にわたります。センサーの中には、1分ごとにデータをサンプリングするものもあれば、5分ごとにサンプリングするもの、15分間隔でサンプリングするものもあり、値を変えるものもあります。タイムスタンプ、タイムゾーン、データポイント名も統一されていません。「非常に構造化されていない」とフランコ氏は言います。では、一貫性とは何でしょうか？それはすべて時系列データ、それも膨大な時系列データです。過去3年間、ウォルグリーンのセンサーデータ出力は約5テラバイトに相当します。

Riptideは、性能低下なく拡張可能なデータストレージシステムとアーキテクチャが必要だと認識していました。NoSQLを選択した最大の理由は、CassandraとDataStaxの分散型システムでした、とFranco氏は言います。「データが大量に蓄積され、ハードドライブが満杯になるようなユースケースが数多くありました。その場合は、ノードを追加し、ハードウェアをアップグレードするだけで済みました。私たちが使用しているNoSQLデータベースシステムの水平方向の弾力性こそが、私たちにとって最大の決め手です。」

RiptideはPostgreSQL、MySQL、Oracle、MongoDBなどを検討した結果、コミュニティのサポートとスケーラビリティを重視し、Cassandraを選択しました。同社のチームは、リアルタイム分析にはStorm、検索にはSolrを使用しています。このリアルタイム分析機能により、別のクライアントであるNordstromの各サイトを大きなバブルで表示するマップを作成できるようになりました。

ノードストロームは空調設備に非常にこだわっており、各店舗の温度が常に華氏72度（摂氏約22度）で、適切な湿度と快適な二酸化炭素濃度を保つよう専任チームを編成しています。「これはノードストロームでのショッピング体験にとって非常に重要です」とフランコ氏は語ります。ノードストロームは空調システムを常時監視しており、重要なパフォーマンス指標の一つが「クリティカルボックスカウント」、つまり過剰稼働しているエアコンユニットの数です。この数値が危険な閾値に達すると、リップタイドが設定したマップが赤色で点滅し始め、リップタイドは担当者を派遣して建物の制御システムにアクセスし、すぐに変更を加えます。

この72度ショッピング体験は、Stormのリアルタイム分析、検索管理のためのSolr、そしてデータを非常に迅速に利用できるマテリアライズドビューを提供するSparkによって実現されています。RiptideがDatastax Enterprise Cassandraを高く評価しているのは、これらのツールがすべて統合されている点です。

以前、ノードストロームはTableauからCSVファイルを取得していました。TableauはそれらのCSVファイルを読み込み、ビジネスインテリジェンスソフトウェアやスプレッドシートソフトウェアにロードし、そこからデータを細分化していました。見た目も悪く、処理速度も遅く、対応できるまでに1週間もかかっていました」とフランコ氏は言います。

センサーデータが少し不安定になる場合

これは、IoTセンサーデータを非伝統的なデータストアで処理することが簡単だという意味ではありません。特に時系列センサーデータは多くの課題を伴います。その一つが集計です。1,000個のセンサーからデータを集計する場合、デバイス1台あたり年間30,000個のデータポイントが発生する可能性があります。計算してみれば、これだけのデータポイントを収集するのは大変な作業であることがわかります。

理想的には、そのデータに対してどのような分析を実行するにしても、すべてのデータが適切な場所にあることが望まれます。クラスター内をくまなく調べて、さまざまな場所からデータを取得するのは避けたいものです。TemetraのBarry氏によると、時系列データの場合、クラスター内での局所性を維持するということは、1つのデバイスのすべてのデータがクラスター内の1か所にロードされることを意味します。

正しい方法を学ぶのは一夜にしてできたわけではなく、常に変化し続けています。Temetraはセンサーデータの保存方法を3度目のイテレーションに進めています。同社は、思考の転換が必要だと学びました。正規化されたデータの処理から非正規化されたデータの処理に切り替える方法を理解するには、しばらく時間がかかります。

「私たちは時々考えを変えることがあります」とバリー氏は述べた。「例えば、『構造上、あそこでは集計ができません』といったことです。中には私たちのミスではなく、新しい技術が原因となる場合もあります。『今こそこれに対応できなければなりません』といったものです。これは私たちのコントロール外です。あるいは、メーターからデータを収集する新しい方法や、新しいフォーマット、あるいは私たちが考えていなかった新しいデータポイントをシステムに導入する必要が生じることもあります。そのため、より良い方法で対応できるよう移行する時期が来たと考えています。」

IoTにおけるもう一つの課題は、あまり耳にしないものの、壁の向こう側、つまり機器レベルにあります。Riptide社のセンサーが建物のシステム機器の上に設置されている屋上に登ると、そこはバベルの塔のようです。収集される膨大なデータには命名規則が存在しません。「標準化されていない」のが当たり前です。フランコ氏によると、世界最大のHVAC企業であるダイキンは、実際にデータ管理サービスを行っており、データの標準化に取り組んでいるとのことです。ダイキンは、自社および他社の機器からあらゆるデータを収集し、標準化された命名規則を作成することでこれを実現しています。そうすることで、同社は多種多様な機器を制御できるのです。

フランコ氏によると、これは実はNoSQLデータベースのもう一つのユースケースです。データベースアプリケーション自体がこのような問題を明らかにし、ダイキンのような企業が介入して問題を解決することで、大規模な管理が可能になります。「ガベージイン、ガベージアウト」とフランコ氏は言います。「大規模であればあるほど、この言葉は真実味を帯びてきます。」

センサーデータは言うまでもなくビッグデータです。しかし、必ずしも高額なデータ処理サービスが大々的に提供されているわけではありません。Teradataは確かに巨大ですが、Temetraはデータストレージ界のAmazonとは全く違います。実際、スマートサーモスタットを導入している住宅所有者、水道インフラにおける水と費用の損失を把握しようとしている大手公益事業会社、あるいは堤防から指を抜くためにセンサーデータから逃れようとしている小規模貯水池など、私たちの多くがセンサーデータに溺れているのです。

昔ながらのリレーショナルデータベースを使う人もいます。HBaseやCassandraなどのNoSQLデータベース上に時系列データベースを構築する人もいます（OpenTSDBやKairosDBなどがその例です）。一方で、Baron Schwartz氏が「ネイティブに時系列対応」と表現するInfluxDBを使う人もいます。つまり、InfluxDBはSQLによく似た時系列クエリ言語を備えているため、SQLに精通した多くの人にとって非常に便利です。

フランコ氏が述べたように、あらゆるセンサーデータを集約する方法を見つけることのメリットは、小規模、中規模、大規模の組織に等しく当てはまります。センサーを集約できればできるほど、屋根に登る必要は減ります。また、IoTの故障した給水ポンプなどからデータをより効率的に取り込めるようになれば、IoTの故障をより迅速に修理できるようになります。

Lisa Vaas は、ボストンを拠点とするフリーランスの技術ジャーナリスト兼ブロガーで、データベース技術、情報セキュリティ、履歴書の科学、キャリア、糖尿病などについて執筆しています。

リスト画像: ロン・アマデオ

69件のコメント