データの高速化について現場最先端の6社が語る

このごろは、何ごとに関してもスピードが重視される。つまり、今でも、ネットワークからデータをかき集めるよりもFedExで送ってもらった方が速いことがある。データを飛行機で運んだ方が速いという、うそみたいな事実が、今でも実際にあるのだ。

数テラバイトのデータを転送するだけなら、丸一日とか一晩かかることはない。でもフィーチャーフィルムの収まった複数のハードディスクを単純に“大陸間移動”することと、正しいデータを取り出し、それを分析し、何かのアプリケーションでプレゼンすることは、状況や抱える問題がまるで違う。スマートフォンの爆発的普及や、言葉の違いなどの障壁、3Dプリンタ、データオブジェクトの限りない多様化と集積、などなど、現代は、データ移動と言っても後者のような複雑な処理ニーズを伴うものが、圧倒的に多くなっている。

このようなデータ移動の複雑性に対応するために多くのアプリケーションは、RAMやフラッシュメモリの有効利用に傾いている。ハードディスクは、もはや古いのだ。ハードディスクの機械的な部品は、現代の企業が分析するデータの量や速度に対応できない。データベースも、完全なメモリ常駐型など、新しいものが登場している。スタートアップだけでなくSAPのような伝統的なIT企業も、それらの開発に取り組んでいる。そしてNoSQLデータベースが、今ではデベロッパたちのコミュニティでは人気者になっている。

しかしアプリケーションのパフォーマンスやデータ分析のスピードを左右する要素は、非常に多面的だ。最近FirstMark Capitalの常勤パートナーになったMatt Turckは、先週ニューヨークの同社のオフィスで行ったインタビューで、物のインターネット(Internet of Things, IoT)がデータ転送の総量を爆発的に増大させる、と言った。彼はそのとき、その兆候としてMQTTの登場を挙げた。この、IoTのための通信プロトコルは、The New York Timesによると、“マシンツーマシン通信のための共通語であるだけでなく、データ交換のためのメッセンジャーでありキャリアだ”。

MQTTの作者は、ワイト島にある16世紀に作られた彼の藁葺き小屋をIoTで自動化しようとしているときに、メッセージングのプロトコルが必要だと気づいた。

物といえば、子どもが床に転がして遊ぶ、あのボールなどを連想するが、しかしTurckによれば、それはボールのような無表情なデータ片ではなく、それ自身の社会的な(かけがえのない、他と同じでない)自己同一性を持ち、いずれは何兆ものほかのオブジェクトと接続することになるデータオブジェクトだ。子どもが壁にぶつけてあそぶSpaldeen〔≒スーパーボール、ビックリボール〕のようなものではなく、それは何かのアバターにもなるデータオブジェクトだ。でも、このボールなどさまざまなオブジェクトから渡されるすべてのデータを、全世界規模で想像すると、それが簡単にゼタバイト級のディメンションになってしまうことが、理解できるだろう*。〔*: したがって通信方式はどうしてもメッセージング(==非同期)方式になる。〕

今では、何ものにも増して重要な話題かつ課題と思われる、IoTなどを契機とするデータ通信量の爆発的増大について、一部のエキスパートたちに話を聞いてみた。しかし彼らの視点は未来よりもむしろ、今まさに起きつつあることに向けられている。

MemSQL

4月の終わりにMemSQLは、同社のリアルタイム分析プラットホームを一般に公開した。このプラットホームは、インメモリデータベースと分散インフラストラクチャを使って大量のデータを分析する。そのデータベースは、スピード重視のアーキテクチャだ。

MemSQLのCEOで協同ファウンダのEric Frenkielは、最近の10年間で大規模なデータ保存技術に重要な改善が見られた、と言う。“企業は圧縮した列保存〔参考〕とHadoopを使って大量のデータを保存し、データの保存と分析を行っていない企業に対して競合上優位に立つようになった”、とFrenkielは言う。“しかしビッグデータは、データ量が十分に多くてしかもアクセス可能でないと無益だ。今企業が苦労しているのは、ビジネスの変化の速度にデータ処理のスピードを合わせること、後者を十分に速くすることだ”。

彼によると、企業がますますデータに依存するようになると、増大する一方のデータに正しいタイミングで対応するために、より高速なデータベースを必要とする。“大量データの保持(リテンション)と保存(ストレージ)という問題が解決されると、次の課題はスピードだ”、とFrenkielは言う。“ハードディスクをフラッシュストレージで置換するとある程度速くなるが、しかし本当に必要なイノベーションはデータを保存し分析するソフトウェアの進化だ”。

MemSQLは、データ分析のためのインテリジェンスとして機能するアグリゲータだ。データ分析は複数のノードにわたってオーケストレーションされ、それらがアグリゲータのコマンドを実行する。各データノード自身は何も知らない(処理インテリジェンスを持たない)、単なる歩兵である点がすばらしいのだ、とFrenkielは言う。

“企業が今インメモリコンピューティングに注目しているのは、それがビッグデータ問題を解決するための新しいアプローチだからだ。インメモリコンピューティングは速度という成分を解決するが、しかし、量という成分を満足させるためにはスケールアウトのためのアーキテクチャが同時に必要だ”。

彼によると、今企業は、既存のソリューションを利用しつつ、データウェアハウスを最新の高速化データベースで拡張して、高速なデータ分析により意思決定の高速化を支えようとしている。“これからは、データ分析が高速で、トレンドや異状を速く見つけられる企業が勝つ”、と彼は言う。“大量のデータを分析しなければならない、という状況は今後も変わらないが、今では速度を重視したアーキテクチャにより、重要な発見や洞察がリアルタイムで得られるようになっている”。

Enigma

Engima は、先週行われたDisrupt NY 2013で優勝した。協同ファウンダのHicham Oudghiriによると、スピードのニーズの背後には必ず、データ量の絶えざる増大というニーズがある。しかし彼によると、EnigmaやPalantirなどが抱えるスケールの問題は、多くのスタートアップが日々直面している問題とまったく異なる。

“ふつうスケールというと、ユーザ数が数千、数万、数百万と増えていくことへの対応だ。だから、問題の形は、どの段階でも同じだ”、とOudghiriは言う。“複数のサーバを並列で動かすとか、予備機を増やすといったワンパターンの対応になる。Webサーバの稼働のラウンドロビン化、CloudFlareのようなCDNの利用、Amazonのようなオートスケール方式でトラフィックのピークに対応する、などなどの方法がある。しかしユーザ数ではなくてデータ集約的なアプリケーションでは、問題がまるで逆になる。スケーラビリティの問題はユーザ数ではなくて、一つのクェリのために何十億もの行を調べるという問題になる。さらにしかも、集めてくるデータの形式や性質や内容がそれぞれバラバラで不統一、という問題に遭遇することも多い”。

彼曰く、これらの問題には、サーバの台数を増やすなどの単純な解はない。ただし、データの保存という点では、冗長性が何よりも重要である。

“唯一の正しいモデル、というものはない。SQLかNoSQLかグラフデータベースか、という選択の問題でもない”、とOudghiriは言う。“それらをすべて使うこと、それぞれに適した役所(やくどころ)を与えることが重要だ。そうやって、各方式の持つ利点を最大限に利用しなければならない。データベースを、一つの理想的なシステムと見なすのではなく、それぞれの声が互いを補い合うことによって生まれる“ハーモニー”だ、と考える。一つの問題を解くときに、頭の中にはつねに、効果的に使い分けられる複数の道具がある、という柔軟性がとても重要だ”。

“第二に、RAMが自分の親友だと考えること、パーシステンシ(persistency,データのオフメモリの持続的存続)はサーバのクラスタで実装することが重要だ(サーバはパーシステンシのための装備であり、実稼働はもっぱらオンメモリで行う)。うちでは、検索のスケール(規模拡大)をRAM内で行っている。今は、メモリがとても安いから、それが十分に可能だ。ただしそうなると、RAMに保存したデータのパーシステンシを確実にメンテできるソフトウェアの構築が、重要な課題になる”。

しかし、中には、RAMのコストを問題視する人びともいる。この点について、彼に聞いてみた。

“部分的にSSDも使っているが、非常に水平的な検索(列よりも行指向)では十分に速くない”、とOudghiriは言う。“しかも、SSDは、こっちが事前に予期できないタイミングでパフォーマンスが急に落ちる。それに比べるとRAMはまったくパーシステントではないけど、むしろノンパーシステントだからこそ頼りになる。リスクと、得られる利点との、トレードオフだね”。

10gen

10genの見方は違う。10genは、NoSQLデータベースMongoDBのスポンサー企業だ。10genの技術部長Jared Rosoffは、スピードには少なくとも二つの側面、アプリケーション開発とアプリケーションのパフォーマンスがある、と言う。

“MongoDBのアプリケーション開発が速いことには、異論がない”、とRosoffは言う。“データモデルに柔軟性があり、ドライバが定型化されていることにより、デベロッパの生産性が高く、機能の改良も速い”。

アプリケーションのパフォーマンスに関しては、MongoDBは余っているメモリのすべてを最近使ったデータのキャッシュに使うので、メモリが十分に大きければインメモリの高パフォーマンスが達成される。

しかしRosoffによると、ワークロードが大きくなるとDRAMはけっこう高いものになる。

“でもビッグデータの仕事を完全にインメモリのデータベースでやろうとすると、十分な量のDRAMを使わざるを得ない。問題は、一台のサーバに載せられるRAMの量に限界があることと、RAMの費用そのものだ。MongoDBは、ディスクやフラッシュストレージを使って、一台のサーバの上で相当大きなデータ集合を処理できる。MongoDBの顧客の多くが、SSDやFlashストレージデバイスを使って、比較的安く、インメモリに近いパフォーマンスを達成している。

また、MongoDBの(NoSQLの)ドキュメント型データモデルではデータのローカリティ…局所性…を維持できるので、複雑なデータモデルと違ってディスクI/Oの回数が少ない。これも、ハイパフォーマンスの重要な鍵だ。

SlashDB

SlashDBは、関係データベースのAPIを作る。ファウンダのVictor Olexの説では、ユーザが求めるスピードはデータベースそのもののスピードに帰結する。

“データアクセスの速度は距離(ネットワークのレイテンシ)だけでなく、ファイルシステムやデータベースからデータを取り出すのに要する時間と、その間のデータ変換の量(フォーマットの変換、エンコード、デコード、圧縮など)にもよる。また、データの取り出しの効率は、データ構造の実装にもよるし、間接参照の少なさも重要だ*。とくに今のデータベース上のエンタプライズデータは(そのデータ構造が)、Webを利用する情報システムにとってボトルネックになっている。関係データベースは宣言型(not手続き型)のクェリができるので便利だが、そのためにインメモリでもディスクからでも、必要なレコードを取り出す計算費用が高くなる。逆にNoSQLのようなドキュメント型のデータベースは、一般的に数値キーでデータを取り出す。データを保存するときに数値を割り当てて、数値とデータを対照するルックアップテーブルを作っておくのだ”。〔*: 直接参照は「n番地にあるデータを読め」、間接参照は「n番地にあるデータに書かれている番地にあるデータを読め」。〕

“さまざまなキャッシング技術がデータアクセスのスピード向上に貢献しているが、そこには精度の低下という費用が発生する(目的データがキャッシュにないこともある)。たとえばWebページでは、キャッシュには古い日付のものしかないことが、よくある。でもそれは、実際にデータベースにアクセスして最新データを取り出す処理費用との、トレードオフという問題だ。我慢できるトレードオフ、と言うべきか。キャッシングとWebアプリケーションのレイヤはスケールアウト(out)して同時に複数のサーバを動かせるから、複数のリクエストを並列に処理できるが、しかしデータベースサーバの方は、一台のサーバの容量やプロセッサを増強するというスケールアップ(up)しかできない。SlashDBは企業のシステムにWeb型のサービスを提供している。つまりURLの中にクェリがあり、結果をHTTPのレスポンスで返す、という形のサービスだ。それは複数のノードでも動かせるし、通常のHTTPプロキシにも対応して、頻用されるリクエストをキャッシュしている”。

“データ集約的な処理は主に、サーバサイドのシステムの領分だった。モバイルデバイスの普及で状況はやや変わってきたが、しかしそれでも、人間の情報処理能力は昔と変わらない。一説ではそれは、毎秒60ビットと言われる。だから、それ以上速いスピードでデータを配布しても意味がない、無駄である、という説もあるのだ。Twitterやメールだけは、別かもしれないがね”。

AlchemyAPI

“AlchemAPIはスピードにこだわっている”、とCEOでファウンダのElliot Turnerは言う。“うちの顧客はみんな、情報の時間価値を知っている。だからデータをできるだけ速く処理することとうちの業績は直接結びついている。しかしデータ処理アプリケーションをもっと速く動かすための簡単な秘訣はない。ボトルネックはいろんなところで発生する。データの保存、取り出し、分析など、いろんな局面で”。

“データの分析の効率化にはさまざまな方法があり、GPUによるハードウェアアクセラレーションや、分散コンピューティング、アルゴリズムのイノベーションなどいろいろだ。AlchemyAPIはこれらすべてを組み合わせて利用するとともに、RAMやSSDを多用することによってデータの保存、取り出し、そして処理を高速化している”。

“RAMは着実に価格が下がりつつあるが(http://www.jcmit.com/mem2013.htm)まだSSDよりも一桁高いし、ハードディスクよりは二桁高い。ペタバイト規模のビッグデータを完全にRAM上で処理するのは、ちょっと費用的に無理かもしれないから、うちも含めてRAMとSSDを併用するハイブリッド方式のところが今は多い。でも、テラバイト規模の小さな展開では、徐々にRAMオンリーに変わりつつある。今後さらにRAMが安くなれば、展開規模も大きくできるだろう”。

まとめ

データ処理の高速化の話は、SSDやRAMや最新のデータベース技術だけで終わるものではない。しかし、一つだけ確かなのは、世界が高度に分散したデータメッシュになり、そしてその負荷が日に日に増大するとともに、新しい高速化の方法が必ず必要になることだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


全世界のWordPressサイトに大規模攻撃; デフォルトのアドミンユーザ名’admin’がねらわれている

本誌TechCrunchのように、WordPressを使ってサイトを構成しているところは、管理/編集ページにアクセスする人たちのパスワードが“強いパスワード”であることを、あらためて確認しよう。そしてユーザ名が、”admin”であってはいけないHostGatorCloudFlareからの報告によると、今、WordPressを使っているブログに対する大規模無差別攻撃が行われている。その大半は辞書を使用する力ずくの攻撃で、とくにWordPressがデフォルトで設定する”admin”アカウントのパスワードを見つけようとする。

HostGatorの分析によると、これは高度に組織化された、そして広範囲に分散した攻撃だ。同社の見積もりでは、今のところ約9万のIPアドレスが使われている。CloudFlareのファウンダでCEOのMatthew Princeが今朝語ったところによると、ハッカーたちは約10万のボットをコントロールしている。CloudFlareが実際に見たところによると、攻撃は相手を選ばずで、特定の種類のサイトに偏ってはいない。

知らない人に自分のパスワードを当てられるのも迷惑だが、犯人たちの最終目的はサーバを乗っ取ることだ。CloudFlareの説によると、犯人は現在、比較的ローパワーなホームPCのネットワークを使っているが、そのねらいは“強力なサーバによる大きなボットネットを作って次の攻撃に備える”ことだ、という。ホームPCは、大規模なDoS攻撃の舞台にもなる。しかしサーバを乗っ取って利用すれば、さらに強力な攻撃が可能だ。

今行われている攻撃は、同じくWordPressのサイトをねらった2012年の攻撃に似ている。でもそのときの攻撃は、古いバージョンのTimThumbを探した。これはWordPressのテンプレートの多くがデフォルトで使っている、PHPによる画像のサイズ変更ソフトだ。

CloudFlareとHostGator、およびそのほかのホスティングプロバイダの多くが、顧客を保護するための適切な措置をすでに講じている。強力なパスワードを選ぶことはつねに重要だが、いろいろWordPressプラグインをインストールして、同じIPアドレスや同じネットワークからのログイン回数を制限し、こういう力づくの攻撃を防ぐこともできる。ただしWordPressのファウンダMatt Mullenwegは彼の今日の午後のブログ記事で、ユーザ名を’admin’から別の…ありふれてない…ものに変えることが最良の防御だ、と言っている。犯人は9万ものIPを使っているのだから、特定は困難である、と。あなたのサイトがもしもWordPressを使っていたら、二段階認証をonにして、セキュリティの層を厚くすることもできる。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))