データは新しい石油ではない

(日本語版注:本稿は、Jocelyn GoldfeinとIvy Nguyenにより執筆された記事。Jocelyn GoldfeinはZetta Venture Partnersの業務執行取締役。 Ivy Nguyenは、Zetta Venture Partnersの共同経営者。)

ソフトウエアの開発が以前に比べて簡単になったことで、ソフトウエア・ビジネスにおいて身を守ることは、以前よりも難しくなっている。そのため、投資家や企業家が、データに新しい競争力の可能性があると楽観視するのは不思議ではない。データは「新しい石油だ」と称賛する人間もいる。私たちは、ビジネスに関する問題を解決してくれるデータやAIを活用するスタートアップへの投資に力を入れているため、たしかに、そうした声を聞くわけだが、石油に例えるのは少し違うと思う。

ビッグデータへの関心は非常に高いが、すべてのデータが同等に作られているわけではないという事実は見落とされがちだ。スタートアップも大手企業も、口を揃えて、テラバイト級だとか、米国議会図書館に収められている情報より多くのデータを保有しているとか、自分たちが集積したデータの量を自慢するが、量だけで「データモート」(Data Moat:データの堀)を築くことはできない。

データ戦略の変遷  左から「ワークフロー・ツール(データなし)」「データ集約」「データ駆動型好循環(AI / ML)」「データモート」

 

その理由のひとつには、生のデータは、問題解決に利用できるデータと比べて価値が遙かに劣るということがある。それは、公開市場を見るとわかる。ニールセンアクシオムなどのデータの収拾や提供を業務としている企業は、ネットフリックスやフェイスブックのようにデータをアルゴリズムや機械学習(ML)と組み合わせることで製品を生み出している企業と比較すると、企業評価は数分の一をなんとか維持している程度だ。新しい世代のAI系スタートアップは、その違いをよく心得ていて、収拾したデータから価値を抽出するためのMLモデルを採用している。

MLベースのソリューションにデータが利用できたとしても、そのデータセットのサイズはまた別の話だ。データセットの価値、つまりデータモートの強さは、文脈による。アプリケーションによっては、顧客に何らかの価値を提供するために、非常な高精度にトレーニングしたモデルを必要とするものがあるかと思えば、ほんの僅かなデータ、あるいはまったくデータを必要としない場合もある。独占的に所持できるデータもあれば、すでに複製されているデータもある。時間とともに価値が失われるデータもあれば、永久に価値を保ち続けるデータセットもある。アプリケーションがデータの価値を決定するのだ。

「データ欲」の範囲を規定する

エンドユーザーに価値ある機能を提供するためには、MLアプリケーションは、幅広く大量のデータを必要とする。

MAP閾値

クラウドの分野には、実用最小限の製品(MVP)という考え方が根付いている。初期顧客を探し出すのに必要な機能だけを備えたソフトウエア郡だ。インテリジェンスの分野では、私たちはデータやモデルから見られるアナログの部分に注目している。採用を正当とするに足る最小限の精度を持つ情報だ。これを私たちは最低限のアルゴリズム性能(MAP)と呼んでいる。

ほとんどの場合、アプリケーションで価値を生みだすのに必要な精度は、100パーセントでなくてもよい。たとえば、医師のための生産性向上ツールがあったとしよう。最初は、健康状態を電子的に記録するシステムのデータ入力を補助する役割を果たすが、時が経つにつれて、どの医師がシステムに入っているかを学習して、データ入力を自動化するようになる。ここではMAPはゼロだ。使い始めた最初の日から、そのソフトウエアの機能が価値を発揮するからだ。インテリジェンスは後から付加される。しかし、AIが中心になっている製品(たとえば、CTスキャナーから脳卒中を特定するツール)の場合は、生身の人間が行うときと同等精度のソリューションが求められる。MAPは人間の放射線科医の能力と同等になり、製品として成立させるまでには、恐ろしいほど大量のデータが必要とされる。

成績の閾値

100パーセントに近い精度があっても、すべての問題が解決できるわけではない。あまりにも複雑すぎるため、最先端の技術を駆使したモデルを必要とする問題もある。その場合は、データは特効薬とはならない。データを増やすことで、モデルの成績は徐々に向上するだろうが、すぐに限界利益の減少に直面してしまう。

反対に、追跡すべき次元が少なく、結果の幅も小さく、比較的単純にモデリングできる問題の場合は、ほんのわずかのトレーングされたデータセットで解決できてしまう。

早い話が、問題を効率的に解決するために必要なデータの量は、状況によって変わるということだ。実用的なレベルの精度に達するために必要なトレーニングされたデータの量を、私たちは「成績の閾値」(Performance Threshold)と呼んでいる。

書類処理におけるMAPと成績の閾値の関係 縦軸は精度、横軸はトレーニング用の実例(ドキュメントの数)。 左「成績の閾値=ドキュメント数200」、右「MAP=93%(人間による処理の精度)」

AIを使った契約処理は、成績の閾値が低いアプリケーションのよい例だ。契約書のタイプは何千とあるが、そのほとんどには、契約に関わる人たち、価値を交換するアイテム、期限など、共通する要点がある。住宅ローンやレンタル契約などの書類は、規制に準拠しなければならないため、ほとんど定型化されている。わずか数百種類の例を使ってトレーニングするだけで、実用的な精度に高められる自動文書処理のアルゴリズムを開発したスタートアップを、私たちは数多く見てきた。

起業家にはバランス感覚が必要だ。成績の閾値が高ければ、顧客に使ってもらい、より多くのデータを集めるために、十分なデータを集めなければならないという「ニワトリが先か卵が先か」のような問題に行き当たる。低すぎれば、データモートは築けない。

安定性の閾値

MLモデルは、それが利用されることになる現実の環境から例を集めてトレーニングされる。その環境が少しずつ、または突然に変化したとき、それに伴って変化できなければモデルは陳腐化する。つまり、そのモデルの予測は、もう信頼できないということだ。

たとえば、スタートアップのConstructor.ioは、MLを使って電子商取引サイトの検索結果をランク付けしている。そのシステムは、顧客が検索結果をクリックするかどうかを観察し、そのデータを使って、よりよい検索結果を得るための順番を予測するというものだ。しかし、電子商取引の製品カタログは常に変化している。もしそのモデルが、すべてのクリックのウェイトを同じと考えていたら、または一定の時間のデータセットだけでトレーニングされていたとしたら、古い製品の価値を過大に評価したり、新製品や現在人気の製品をそこから除外してしまったりする恐れが出てくる。

モデルの安定性を保ちたいなら、環境の変化の速度に合わせて最新のトレーニングデータを取り込む必要がある。私たちは、このデータ取得の速度を「安定性の閾値」と呼んでいる。

短命なデータでは強固なデータモートは作れない。一方、安定性の閾値が低い場合、豊富で新鮮なデータへの継続的なアクセスは、大きな参入障壁になってしまう。

長期的な防御力で好機を見極める

MAP、成績の閾値、安定性の閾値は、強固なデータモートを築く際に中核となる要素だ。

新しいカテゴリーに飛び込む先行者には、MAPが低い企業があるが、ひとたびカテゴリーを確立して、そこを牽引するようになれば、後から参入する者たちの敷居は、先行者のときと同じか、それよりも高くなる。

成績の閾値に達するまでに必要なデータと、成績を維持するため(安定性の閾値)に必要なデータの量が少なくて済む分野では、防御が難しい。新規参入者はすでに十分なデータを持っているので、先行者のソリューションに簡単に追いついたり、追い越したりできてしまう。その一方で、成績の閾値(大量のデータを必要としない)と低い安定性の閾値(データが急速に古くなる)と戦っている企業でも、他の企業よりも早く新しいデータを取得できれば、データモートを築ける可能性がある。

強固なデータモートのその他の要素

AI系の投資家は、データセットは「公開データ」と「独自データ」に分けられると熱弁するが、データモートには、それとは別に次の要素がある。

  • アクセスのしやすさ
  • 時間 — どれだけ早くデータを収集してモデルに活かせるか。データには即座にアクセスできるか、または取得や処理に長い時間がかからないか。
  • コスト — そのデータを入手するのに、いくらかかるのか。データを使用するユーザーがライセンス権のために金を払う必要があるのか。または、データのラベリングのために人件費を払う必要があるのか。
  • 独自性 — 同じ結果を導き出すモデルが構築できる同等のデータが広く公開されていないか。そのような、いわゆる独自データは、「日用データ」(Commodity Data)と呼ぶべきだろう。たとえば、求人情報や、広く普及している形式の書類(機密保持契約書やローンの申請書など)や、人の顔の画像のようなものがそれにあたる。
  • 次元性 — データセットの中に、種類の異なる属性がどれほど含まれているか。その多くが、問題解決に役立つものであるか。
  • 幅 ― 属性の価値がどれほど多岐に渡っているか。そのデータセットに、極端な事例や稀な例外的事例が含まれているか。データまたは学習が、たった一人の顧客から得たものではなく、幅広い顧客層から収拾され蓄えられているか。
  • 寿命 ― そのデータは、長期にわたって幅広く利用できるものであるか。そのデータでトレーニングされたモデルは、長期間使えるか。または、定期的な更新が必要か。
  • 好循環 ― 性能のフィードバックや予測の精度といった結果を、アルゴリズムの改良のためのインプットとして使えるか。時を経るごとに性能が磨かれてゆくか。

今やソフトウェアは日用品だ。長期間にわたって競争での優位性を保ちたいと考える企業にとって、データモートの構築はますます重要になる。技術系の巨大企業がクラウド・コンピューティングの顧客を獲得するためにAIツールキットを無料公開する世の中では、データセットは、差別化のための非常に重要な決め手となる。本当に防衛力の高いデータモートは、データを大量に集めるだけでは実現しない。最良のデータモートは、特定の問題分野と強く結びついている。そこでは、顧客の問題を解決するごとに、他所にはない新鮮なデータが価値を生み出すようになる。

画像:Artem_Egorov / Getty Images

[原文へ]

(翻訳: Tetsuo Kanai)

AWSのDynamoDBが継続的自動バックアップと事故時の即時リカバリを提供

クラウドコンピューティングはいろいろ便利だが、データの扱いもクラウドのベンダーがやってくれるのがありがたい。でもそれは、ソフトウェアをアップデートしてくれるとか、ハードウェアのスケールアップ/ダウンを勝手にやってくれる、ぐらいのことだった。しかし今日(米国時間4/4)AWSはそれを一歩進めて、Amazon DynamoDB Continuous BackupsおよびPoint-In-Time Recovery(PITR)〔継続的自動化バックアップと即時リカバリ〕なるものを発表した

この新しいサービスでは、ユーザーがバックアップツールを有効にしておくと、バックアップが自動的に行われる。あとのことはすべてAmazonが面倒を見て、ユーザーのDynamoDBデータベースにあるすべてのデータを継続的にバックアップする。

しかもそれだけではなく、バックアップシステムは記録もつける。つまり、そのおかげで、過去35日以内ならデータの“巻き戻し”ができて、その粒度は秒単位だ。しかもそのツールにはユーザーがAWS Management Consoleからアクセスでき、AWS Command Line Interface(CLI)でAPIを呼び出せる。

スクリーンショット提供: Amazon

この新しい機能を発表するブログ記事でAmazonのRandall Huntが書いている: “この機能を作ったのは、事故的な上書きや削除からユーザーとデータを守るためだ。デベロッパーがステージングではなくプロダクションに対してスクリプトを動かしたとか、どこかのファットフィンガー(fat-finger, 指が太すぎるやつ)が間違ってDeleteItemボタンを押してしまったときには、PITRが助ける。また、ユーザーにとって予想外の事態にも対応できる”。

35日のリミットが気になる人は、通常の定期的なオンデマンドのバックアップならいくらでも長期保存できることを、おぼえておこう。

AmazonのCTO Werner Vogelsが、今日サンフランシスコで行われたAWS Summitでこの新しいサービスを紹介した。そして、どれだけ大量のデータがあっても平気だ、と言った。つまりこれらの新しいサービスは、データ量がテラバイト級でも使える。“これはAWSの本当に強力な仕組みなんだ”、とVogelsは自画自賛した。

この新しいサービスは今日からいくつかのリージョンで可利用になる。それらがどことどこか知りたい人は、このページを見てみよう。

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

MySQL代替系MariaDBがビッグデータ分析スタートアップMammothDBを買収してBIアナリティクスを強化

MariaDBは、人気の高いMySQLデータベースの簡易な代替系としていちばんよく知られている。しかしMariaDB Corporationを創ったのはMySQLのファウンダーMonty Wideniusであり、そこがそのソフトウェアのすべてをオープンソースのライセンスで提供している。それは明らかに、もっと大きな市場をねらっているからであり、大きくなってOracleなどともより有利に競合したいからだ。という同社が今日(米国時間3/27)、ブルガリアの企業向けビッグデータ分析サービスMammothDBを買収したことを発表した。

MariaDBはすでに、MariaDB AXという名で企業向けアナリティクスとデータウェアハウジングのシステムを提供している。そのサービスは2017年にローンチしたが、これにMammothDBの専門的能力を注いで、力をつけたいのだ。

MariaDBのCEO Michael Howardはこう説明する: “MammothDBのチームは、MariaDBの成長にとってきわめて重要な時期に来てくれた。彼らは、ビッグデータのソリューションでめざましい実績を有している。昨年はMariaDB AXの需要が急増したが、それは、Oracle やTeradataのようなプロプライエタリな提供物と違ってオープンソースの世界では従来、アナリティクスの部分に欠落があり、企業ユーザーはその欠落を埋めたかったからだ。MariaDBがこの成長中のニーズに対応し、そのアナリティクスのプロダクト(MariaDB AX)を継続的にイノベーションしていくためには、MammothDBの専門的なアナリティクスの能力が欠かせない”。

買収の価額は公表されていない。MammothDBは2015年に3TS Capital PartnersとEmpower Capitalがリードするラウンドで180万ドルのシード資金を調達したが、その後の資金獲得の話は聞かない。一方MariaDBは、2017年の後半にAlibaba GroupとEuropean Investment Bankが率いるシリーズCのラウンドで5400万ドルを調達した。その資金が、今回の買収を支えたものと思われる。

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

MongoDBがマルチドキュメントのACIDトランザクションをサポート、三年がかりの大工事で

MongoDBがついに、マルチドキュメントのACID日本語)トランザクションをサポートすることになった。MongoDBのコミュニティは長年これを求めていたが、このプロジェクトを支えている企業(製品と同名のMongoDB, Inc.)がやっとその実装に取り組んだのだ。

発表は今日(米国時間2/15)の午後になるようだが、ACIDのサポートはこのNoSQLデータベースが夏にリリースするバージョン4.0でローンチする。しかしデベロッパーはそれまでベータを利用できるから、その使い方などを勉強できる。

基本的にMongoDBはドキュメントデータベースであり、デフォルトでは、この種のデータベースはACIDではない。マルチドキュメントのトランザクションなら、なおさらだ(ドキュメントのレベルではMongoDBはすでにACIDトランザクションをサポートしている)。しかし、マルチドキュメントに同時にライトするようなMongoDBの使い方をする企業はそう多くないから、それはこれまで、重要な案件ではなかった。

しかしそのために、MongoDBのユーザーの多くは今だに、リレーショナル・データベースをドキュメントデータベースと併用している。

むしろ、MongoDBの協同ファウンダーでCTOのEliot Horowitzによると、それこそがこのプロジェクトのメインの動機のひとつだった。“われわれがこれを必要としなかったのは、ドキュメントモデルはACIDトランザクションの必要性をなくすからだ。すべてではないが、ほとんどのね”、と彼は語る。しかしそれと同時に、ミッションクリティカルなユースケースのためのトランザクションが必要な場合も、明らかにある。またHorowitzによれば、MongoDBのユーザーの中にも、“いずれそれが必要になるのではないか”という不安をずっと抱えているデベロッパーがいる。今日のローンチは言うまでもなく、そんな不安を取り去る。

RedMonkの主席アナリストStephen O’Gradyはこう言う: “トランザクションのACIDが保証されることは何十年にもわたってリレーショナル・データベースの重要な特長だった。しかしそのためにユーザーは、トランザクションの確実性か、ノンリレーショナル・データベースが提供する柔軟性と多機能性か、という選択を強いられてきた。今回、マルチドキュメントのACIDトランザクションがサポートされたことにより、MongoDBは、ケーキを作るだけでなくそれを食べたいという顧客にも、奉仕できるようになった”。

Horowitzが強調するのは、単純にこの機能をデフォルトにするデベロッパーはいないだろう、ということ。むしろ多くのデベロッパーは、非常に特殊なユースケースの場合のみ、それを有効にするだろう。“これがMongoDBにライトするときのふつうの方法になるとは、思わないね”、と彼は言う。

この新しい機能の構築は複数年にわたる努力であり、三年前に、データベースのストレージエンジンの技術を持つWiredTigerを買収したことから始まった。しかしそれを有効にするためには、データベースシステムのほとんどあらゆる部位に手を加える必要があった。

試してみたい人は、ここでベータに参加しよう。

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

時系列データベースで次々とエンタープライズ顧客を獲得しているInfluxDataがシリーズCで$35Mを調達

センサー群がどんどん増える一方のデータを絶えず捉(とら)まえているような世界では、その大量のデータを収集して時間軸の上でそれを測る技術がますます重要になる。オープンソースの時系列データベースInfluxDBの実装や管理サービスを提供するInfluxDataが今日、Sapphire VenturesがリードするシリーズCのラウンドで3500万ドルを調達したことを発表した。Sapphireは、エンタープライズソフトウェアの大手SAPの投資部門だ。

前からの投資家Battery Ventures, Mayfield Fund, およびTrinity Ventures, そして新たな投資家としてHarmony Partnersもこのラウンドに参加した。これでInfluxDataの資金調達総額は6000万ドル近くになる。

時系列データベースはその名の通り、データを素早く捕捉計測して、その時間上のトレンドを見るためのデータベースだ。InfluxDataのCTO Paul Dixは時系列ツールのニーズがあることを知って、2014年にオープンソースのツールキットの開発を始めた。それはGitHub上でたちまち評判になった、とCEOのEvan Kaplanは言っている。今では12万のサイトがInfluxをオープンソースで利用し、400のエンタープライズ顧客が同社のプラットホームを使っている。

デベロッパーがInfluxのツールを使って時系列アプリケーションを作ることもできるが、エンタープライズのスケールやセキュリティや可用性が必要なら、商用バージョンのプロダクトを買う必要があるだろう。“Influxを大きなプロダクションで本格的に動かしたいなら、クローズドソースのバージョン(商用バージョン)を買うべきだ”、とKaplanは語る。

その商用バージョンは立ち上げてからまだ18か月だが、早くからIBM, SAP, Cisco, PayPal, Tesla, Siemensなど代表的なエンタープライズブランドが顧客になっている。

SapphireのパートナーAnders Ranumによると、同VCはこれからの新しい市場機会に目をつけていて、それを先取りしたいから投資をした。“機械学習や物のインターネット、人工知能などの新しい能力を企業が使いこなさなくてはならなくなると、その企業で日々得られるすべてのデータを捕捉分析してスマートな意思決定に結びつけていくことが、彼らにとって急峻な障壁になる”、とRanumは声明の中で言っている。彼が信じているのは、時系列ツールがそんな企業を助ける、ということだ。

同社には今80名の社員がいるが、本日得られた資金により、これを年内に倍にして、プロダクトの成長を促進したい。今日の投資の一環として、SapphireのRanumがInfluxの取締役会に加わる。

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

分散データベースNomsを抱えるAttic LabsをSalesforceが買収、Quipとの統合を目指す

オープンソースの分散データベースNomsを作っているAttic Labsが今日(米国時間1/8)、Salesforceに買収されたことを発表した。これはSalesforceの2018年初の買収だが、その契約条件は公表されていない。Crunchbaseによると、昨年の同社の買収はデジタルクリエイティブエージェンシーSequence一社のみで、10社あまりを買収した2016年に比べ、一休みという形になった。

Nomsがローンチしたのは2016年の8月で、そのとき同時にAttic Labsは、Greylockが率いるシリーズAで810万ドルを調達した。ファウンダーのAaron BoodmanとRafael Weinsteinをはじめ、Attic Labsのチームのメンバーの多くが、それまでGoogle Chromeを手がけていた。Boodmanは、Greasemonkeyの作者でもある。

Gitと同じように、Nomsでもユーザーは複数のマシンのオフライン上でデータを複製し、それをシンクしたり編集できる。バージョニングの機能があるので、編集してもデータの前のバージョンは壊れないから、必要なら復活できる。Gitと違うのは、Nomsはテキストファイルよりも定型データの保存に適していて、とても大きなデータ集合もサポートする。Attic Labsは今日の発表声明の中で、Nomsは今後もオープンソースであり続ける、と言っている。NomsのフォーラムでBoodmanは、そのデータベースに対して、“今すぐやらなければならないことはない”、と述べている。

買収が完了したらAttic Labsのチームは、Salesforceが2016年に7億5000万ドルで買収したドキュメントコラボレーションプラットホーム〔“コラボレーション型ワープロ”〕Quipに加わる。Attic Labsによると、Nomsの技術が“Quipの能力を拡張して、ライブのデータソースに接続できるようにし、人びとが容易に迅速で効果的なコラボレーションをできるようになる”、という。

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

オープンソースの分散グラフデータベースDgraphが$3Mを調達しv.1.0にやっと到達

【抄訳】
このところ人気が盛り上がっているDgraphは、オープンソースの分散グラフデータベースで、デフォルトのクェリ言語としてFacebookのGraphQLをベースとする同社独自のGraphQL+-を使用する。今日(米国時間12/19)同社は、Bain Capital Venturesらから300万ドルの資金を調達したことを発表した。そのほかの投資家として、Atlassianの協同ファウンダーMike Cannon-Brookes, Blackbird Ventures, AirTreeなどの名が挙げられている。同社はこれを機に、その主製品であるデータベースがバージョン1.0に達したことを発表した。なお、300万ドルという額面には、昨年のシード資金110万ドルも含まれている。

DgraphのファウンダーManish JainはこれまでGoogleでWeb検索と知識グラフ(ナレッジグラフ)プロジェクトを担当していた。【中略】〔資金調達の経緯〕

Jainによると、グラフデータベースは長年、既存のリレーショナル・データベースを補完する二次的なデータベースとみなされていた。しかし最近では、アプリケーションがますます複雑になるにつれて、いろんなものともののあいだの、大量の関係を表現し追跡する必要性が生じてきた。となると当然、グラフデータベースの出番だ。Jainの予想では、今後ますます、多くの企業がDgraphのようなプロダクトをメインのデータ格納庫として使用するようになるだろう。グラフデータベースは、速さでリレーショナル・データベースに負けないだけでなく、いろんな形の関係性を表現できる柔軟性があるからだ。

DgraphがNeo4などの競合製品より優れているとJainが信ずるのは、それが最初から分散データベースとして構築されているからだ。投資家も同意見で、Bain Capital Venturesの専務取締役Salil Deshpandeは、昨年同社のシードラウンドに参加したとき、こう述べた: “今あるグラフデータベースは本物の分散ではない。それらはノードが一つなら立派に動くが、ノードが複数になると、いろんなアーキテクチャ的ハックに頼らなければならないから、スケールしない”。

Dgraphのプロジェクトは2015年にスタートし、これまでバージョン1.0に達していなかったが、それでもかなりの数のデベロッパーがプロダクションで(本番で)使ってきた。現在のユーザーは、ゲームサービス、広告、フィンテック企業などで、ユースケースは不正ユーザーの検出などだ。このほか、検索エンジンやIoT、医学研究、機械学習、AIなどのユースケースも多い。

Jainによると、プロジェクトをオープンソースにしたのは熟考を重ねた結果だ。Apacheライセンスにしたのは、エンタープライズユーザーに受けが良いからだ。彼によると、このようなプロジェクトが十分な採用数に達するためには、オープンソース以外の道はない。“Uberが使い始めたら、新しいユーザーがどっと増えるだろうね”、と彼は言う。

収益源としては、近くリリースするDgraphのエンタープライズバージョンが軸だ。それはクローズドソースで、同社がホストするバージョンだ。Jainは冗談半分で、それぞれの顧客のそれぞれ独特な環境の面倒をいちいち見てあげるよりも、サービスをこっちでホストした方が楽だ、と言う。

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

成約率が高い見込み客を自動でリスト化、DBスタートアップのBaseconnectが1億円調達

企業情報データベースの「BaseconnectLIST(以下、LIST)」を開発するBaseconnectは12月20日、ジェネシア・ベンチャーズみずほキャピタル、京都市スタートアップ支援ファンド、ユーザーローカル代表取締役の伊藤将雄氏、YJキャピタルEastVenturesなどから総額1億円を調達したと発表した。この調達金額には地銀からの融資も含まれる。

テレアポや飛び込み営業というのは、今も昔も変わらない営業の現場の姿。営業員たちはいわゆる「見込み客リスト」を片手に営業をかけていくわけだが、そのリストの作成には膨大なコストと手間がかかる。Web上の情報や電話帳から得たデータをもとに人力でリストを作成し、片っ端から営業をかけていくという企業も少なくないだろう。

そのような企業に対し、営業先となる企業に関する各種情報を集めた企業データベースを安価で提供するのがBaseconnectだ。LISTでは、同社が保有する企業データを約20項目の検索条件(従業員数、売上規模など)で絞り込み、それを見込み客リストとして出力することが可能だ。LISTは12月20日よりベータ版を公開。正式リリースは2018年4月を予定している。

SaaS型で低価格、レコメンドも

企業情報をデータベースとして提供する企業は多くある。大企業まで網羅する企業としては帝国データバンクランドスケイプなどがあるし、スタートアップを中心としたデータベースにはCrunchBaseもある。しかし、Baseconnect代表取締役の國重侑輝氏は、それでも「データベース業界は旧態依然とした業界であり、企業情報を安価で入手できるSaaSがない」と話す。

Baseconnect Listの料金は従量課金制で、企業情報1件にかかる料金は25〜30円。最も安いプランでは月額9000円で利用できるという。この値段であれば、スタートアップや中小企業でも手を出しやすい。企業規模が大きくなり、営業活動が本格化すれば見込み客リストを無制限に作成できるプラン(月額50万円)を選ぶこともできる。

Baseconnect Listにはレコメンド機能があることも特徴だ。これは、ユーザーが既存顧客のデータをアップロードすると、その企業に似た企業をデータベースから抽出してリスト化するというもの。既存顧客と見込み客との間の類似点をスコア化し、その点数が高い見込み客が成約率が高いと判断する。“既存顧客と似ている見込み客の成約率は高い”というロジックがアルゴリズム化されているというわけだ。

一方で、データベース企業の勝敗を分ける要因の1つが”情報の網羅性”であることも確かだ。今のところ、LISTに格納された企業データは約10万社。國重氏によれば、本社ベースで数えた企業数は全国で400万社ということだから、カバー率はまだ低い。Baseconnectの当面の目標は、その400万社のうち企業活動が活発な150万社をデータ化することだ。

データはデジタルなものだが、その入力作業は人間の手によるアナログなタスク。今ある10万社分のデータを作成するのには約1年の時間を要している。「今では2ヶ月で10万件のペースでデータ化できるようになった」と國重氏は話すが、Baseconnectは今回の資金調達によって現在200名(アルバイトなど含む)体制のデータ作成チームの増強をさらに進める。また、1社分のデータを作成するコストは今のところ約300円だということだが、このコストもデータ作成の自動化を進めることで圧縮していくという。

AWSがサーバーレスのデータベースサービスAurora Serverlessをプレビューで立ち上げ

Amazonのクラウドコンピューティング部門AWSが今日(米国時間11/29)、連続的なデータ処理を必要としないようなリレーショナル・データベースを、容易に、安く、そして手早く立ち上げるサービスを発表した。そのAurora Serverlessと名付けられたサービスは、その名のとおりAWSの既存のデータベースシステムAuroraを利用しており、いわばサーバーレスでイベントドリブンなコンピュートプラットホームのデータベース版だ。

そのもっとも巧妙な仕組みは、データのストレージと処理が分離していることだ。Aurora Serverlessのユーザーは処理に対してのみ支払うが、もちろんそのときはストレージも仕事をしている。ただしその費用は比較的安い。

このサービスは、計画では来年のどこかの時点でプレビューを脱し、そのときにより詳しい情報を共有する、という。

目下Aurora Serverlessはプレビューのみだが、一般公開されたらデベロッパーはサーバーレスのリレーショナル・データベースにオンデマンドでアクセスでき、データベースのプロビジョニングを自分でやる必要がない。しかもスケールアップ/ダウンが、必要に応じて簡単にできる。ユーザーは、データベースを実際に使用した秒数に対してのみ支払う。これまでは、データベースを使おうと思ったら、データベースサーバーと称するマシンを動かす必要があった。Aurora Serverlessでは、そこらのことをすべて、AWS自身が楽屋裏でやってしまう。



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

AWSのAppSyncでアプリケーションのオフライン利用が可能に

【抄訳】
Webホスティングサービスの王者の勝利を誇示するような大集会が、今年もラスベガスで行われている。そのAmazon Web Servicesのデベロッパーカンファレンスre:Inventでは今日(米国時間11/28)、このサービスがホストしているアプリケーションをオフラインでも使える新しい機能、AppSyncが発表された。

今朝発表された同社のブログ記事が、この新しいサービスの概要を説明している。

その記事によると、AWS AppSyncは、完全に管理されたサーバーレスのGraphQLサービスで、デバイスがオフラインでもリアルタイムのデータクェリを可能にする。そして接続が可利用になればローカルデータをシンクする。

Amazon技術のエヴァンジェリストのようなTara Walkerの、少々分かりづらいブログ記事によると、GraphQLはデータクェリ言語で、リアルタイムのデータ取り出しとクェリの動的実行を行うサーバーサイドのランタイムだ。

クライアントアプリケーションを作るときにはGraphQLはアプリケーションレイヤで動き、スキーマを定義するためのタイプシステムを提供する、と上記のWalkerは言っている。

そしてこれらのスキーマが、データに対する操作の仕方とデータの構造をコントロールするスペックになる。GraphQLはまた、多くのプログラミング言語やライブラリがサポートしている宣言的プログラミングモデルで動作する(これもWalkerより)。

以上でよく理解できた方は、ぼくよりも優秀だ。でもなにしろ、Walkerは、AppSyncについてこのように書いているのだ。

デベロッパーはスキーマを作って、GraphQLで開発するAPIのタイプと能力を定義し、“Resolver”ファンクションに結びつける。スキーマは既存のデータソースに基づいていてもよいし、あるいはAppSyncがスキーマの定義に基づいて自動的にテーブルを作ることもできる。

デベロッパーは、バックエンドのデータソースに関する知識がなくても、GraphQLの機能を利用してデータの発見(データディスカバリ)ができる(これは便利だ)。

Walkerは、さらにこう説明している:

【後略】

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

MicrosoftがMariaDB Foundationに参加してAzure Database for MariaDBをローンチ

Microsoftが今日(米国時間11/15)、同社がMariaDB Foundationに参加することを発表した。この非営利団体は、MySQLを作ったデベロッパーたちによる人気の高いリレーショナルデータベースMariaDBの非商用化バージョンを支えている。そのプラチナスポンサーになったMicrosoftは、Booking.comやAlibaba Cloud、Tencent Cloudなどと横並びすることになる。

さらに今日Microsoftは、Azure Database for MariaDBというサービスを立ち上げた。これは、Azureの一員としてのマネージドデータベースサービスという意味で、ほかにもAzure Database for MySQL, 〜〜〜PostgreSQLなどの類似サービスがある。

MySQLは最初Sun Microsysytemsが買収し、今ではOracleがそのオーナーであるため、その私企業臭を嫌う多くのデベロッパーのためにMariaDBが開発された。いわばそれは、MySQLの身代わりリプレースだ。

MariaDB(とMySQL)のファウンダーMonty Wideniusが、今日の発表声明でこう書いている: “MariaDB Foundationの理事会は、MicrosoftをFoundationのプラチナメンバーとして歓迎する。私がMariaDBを作ったのは、MySQLをオープンソースのコミュニティに戻すためであり、その強力でオープンな未来を確実なものとするためだった。私はMicrosoftがそのビジネスをオープンなやり方で変えていく様相を間近で見てきたし、Microsoft Azureも確かにオープンであり、フレキシブルである。今のMicrosoftはGitHubの主要なコントリビューターの一員であるが、私たちは、Microsoftの技術者たちとそのデベロッパーのエコシステムが、それと同じようにMariaDBを支えていくことを、期待している”。

Wideniusのオープンソース観は、つねにきわめて実践的だ。数年前に彼はMariaDB Foundationを始めるためにSkySQLを去ったが、今ではそれはMariaDB Corpとなり、MariaDBデータベースの商用化をビジネスとしている。そしてその後彼は、MariaDB Corp.にCTOとして戻った

一方Microsoftは、このところ確実にオープンソース擁護派だ。今や同社は、Linux Foundationとその一部プロジェクトのスポンサーであり、またOpen Source InitiativeやCloud Foundry Foundationなどにも加盟している。

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

GoogleのCloud Spannerデータベースがマルチリージョンをサポート、年間ダウンタイム累計5分未満を約束

Googleのグローバルな分散データベースCloud Spannerが今日(米国時間11/14)アップデートされ、マルチリージョン(複数リージョン)がサポートされた。データベースを複数のリージョンにまたがって複製しても、レイテンシーは増えず、良好なパフォーマンスが保証されるという。また、サービス水準合意(Service Level Agreement, SLA, サービス品質保証)も、顧客が満足すると思われる方向へ改定された。

上記後者(新SLA)によると、Cloud Spannerデータベースは99.999%(five nines)の可用性が保証される。Cloud SpannerのプロダクトマネージャーDeepti Srivastavaによると、これは年間のダウンタイムに換算すると5分未満となる。

“システムの可用性と効率を高める改造を行ったので、サービスにそのことが反映されると期待される”、と彼女は述べる。なお、Cloud Spannerは、このようにサービスとして提供される前には、AdWordsなどGoogle内部のプロダクトで使われていた。今でもそうだから、GoogleにとってAdWordsがダウンしたら直接、売上に響く。だからまずGoogleにとって、それはダウンタイムがあってはならない。今では同社の人気サービスの多くが、Cloud Spannerを使っている。

“それは、Googleが動かしているミッションクリティカルなアプリケーションの最前線でテストされている”、とSrivastavaは説明する。

しかしこれまでは、複数リージョンにまたがるサポートが欠けていたので、Cloud Spannerを一箇所に置くことしかできなかった。それが、今日のマルチリージョンサポートの発表で変わった。ユーザー企業は、データベースをエンドユーザーに近いところに置けるようになる。それにより当然、レイテンシーが減り、応答性が良くなるだろう。

Cloud Spannerは今年の初めにベータで提供されたが、それはまるでマジックのように思えた。それは、SQLデータベースのようなトランザクションの一貫性と、NoSQLデータベースのスケーラビリティを兼備している。この両者が揃うことは稀であり、今日ではEvernoteやMarketoなどもCloud Spannerを利用している。

Googleは、Cloud Spannerの導入はわずか4クリックで完了、と謳っているが、既存のデータベースを移行する場合はそう簡単ではないだろう。Srivastavaによると、それはシステムのタイプ次第だ、という。まったく新しいアプリケーションのために新たに導入するのは簡単だが、Cloud Spannerを使うために既存のデータベースシステムのアーキテクチャを変えなければならない場合は、それなりの時間がかかるだろう、と彼女は語る。

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

MongoDBのNasdaq上場、初終値は34%アップ

ニューヨークのデータベース企業、MongoDBは今日(米国時間10/19)Nasdaqに上場し、初終値は32.07ドル、24ドルの売り出し価格から34%のアップとなった。当初、上場の目標株価は18ドルから20ドルとされていたものが20ドルから22ドルとアップされ、さらに直前になって24ドルに決定されたものだ。

MongoDBはこの株価24ドルの売り出しで11.8億ドルの評価額で1億9200万ドルを得た。上場初日の終値はさらにアップし同社の時価総額16億ドルとなった。これは2年前の資金調達ラウンドの際の会社評価額と同額だ。

MongoDBは2008年以降、3億ドル以上を株式売却で調達し、Sequoia Capital、Flybridge Capital、Union Square Venturesが大株主となった。

MongoDBを利用してデータベースを運用するクライアント企業にはAdobe、eBay、Citigroupなどが含まれる。MongoDBは同名のオープンソース・データベース、MongoDBやデータベース・アズ・ア・サービスのAtlasなどのプロダクトを提供している。

共同ファウンダーでCTOのEliot HorowitzがTechCrunchに語ったところでは、MongoDBは「次世代アプリケーションのための優れたデータベース」だという。Horowitzは「デベロッパーの生産性を一気に向上させるようなプロダクトを開発する」としている。

2017年1月に終わる会計年度の売上は1億140万ドルだった。前年同期の数字は6530万ドルで2倍近くの成長を遂げたことになる。最近の年間損失は8670万ドルと発表されている。その前年、2016年1月に終わる年度では7350万ドルの赤字を計上している。

画像: Nasdaq, Inc

[原文へ]

(翻訳:滑川海彦@Facebook Google+

MongoDBのIPO価格は一株あたり24ドルで当初予想を上回る、赤字企業に市場の期待大

MongoDBが上場に向かう最後のステップを終了し、そのIPOに24ドルの値をつけ、それにより1億9200万ドルを調達した。

公開市場にデビューするのは明日(米国時間10/19)だが、そこでもまた、同社のオープンソースソフトウェアをベースとするビジネスの真価を問われることになる。MongoDBが提供するオープンソースのデータベースソフトウェアは、これから離陸を目指す初期段階のスタートアップたちにとくに人気があり、同社は高度なツールを提供することによって彼ら(および大企業の顧客)を有料顧客に変換する努力を重ねてきた。それは、この前上場したClouderaとは異なる状況だ。

同社は今、800万株を売っているが、引受人にはさらに120万株を買えるオプションがある。その追加分を含めると、MongoDBは2億2080万ドルを調達するかもしれない。一株あたり24ドルでは、同社の時価総額は約12億ドルになる。

同社は成長しているように見えて、その損失も着実に増えており、確かに同社は大量のキャッシュを燃やしている。約12億ドルの時価総額になるのも、おそらくそのせいだ。MongoDBは、ある時点では16億ドルの時価総額まで行けそうだったが、MongoDBのようなマーケットの問題児はウォール街にとって明らかに売りづらい。しかしそれでも、同社のIPO価格は当初予想された20-22ドルより高い。つまり、市場の関心が高い、ということ。

このところの、同社の財務状況はこうだ:

最終的にはこれは、スタートアップのさらなる大型IPOを期待していたニューヨークのテクノロジー界隈にとって、快挙になるかもしれない。時価総額は安めになったが、MongoDBはいわゆる“IPOの狭き窓”に疑問符がつきかけていたこの時期に、ドアの外へ出ることに成功した。このIPOはSequoia CapitalやFlybridge Capital、それにもちろんニューヨークのKevin Ryanにとって、たぶん大勝利となるだろう。

どのIPOでも資金調達が目標だが、でもできるだけ多くの資金を確実に得ることと、初日の“ポップ”(急騰)を許容することとのあいだには、微妙なバランスがある。投資家や社員たちのために流動化イベントを立ち上げて、これから強力な上場企業になるぞ、という姿勢を示すのは一種のショーでもある。MongoDBが公式に上場を申請したのは、9月だった

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

水は身近すぎて忘れられている問題、研究者たちは将来に備えてネット上の情報共有化を提案

蛇口から出る水は、どこから来ているのだろう? どのようにろ過され、浄化されているのだろう? 1ガロン(約4リットル)の水を利用者に送るために要する市や州の費用はどれぐらいだろう? それはもっと安くできないのか? きれいな水がますます貴重な資源になってくるにつれて、あれやこれやの疑問が自然に湧いてくる。それらの疑問に答えるためには、オープンに共有される‘水のインターネット’(internet of water, IoW)が必要だ、デューク大学とアスペン研究所(Aspen Institute)の研究者たちはそう考えている

干ばつや洪水のような自然災害や、過密都市や工場廃液のような人災、これらの被害者である水系は酷使され無理解にさらされている。各地の行政や公共事業体は、水の使用に関するデータを大量に作っているが、国レベルのデータベースはほとんどなく、国や世界の標準に合ったオープンなデータベースとなると、なおさらない。

“人間と水に関しては、データは多いけど情報は乏しい”、デュークのニコラス研究所のMartin Doyleが説明する。“水のデータがオープンに共有され、みんながよく使うデジタルのプラットホーム〔Google検索など?〕に統合されたら、一般市民が地元の水質を測れるようになり、行政は水に起因する健康危機を早めに警報できるようになるなど、水をめぐる社会状況が一変するだろう”。

それは、ミネアポリスの水道局の人がフェニックスの1ガロンあたりの水道料金を知りたい、というレベルの問題ではない。むしろそれは、有意義なビッグデータがみすみす捨てられていた、という問題だ。視野を広げればより多くのデータが得られ、システムの一部を最適化するための意思決定の質も向上する。マクロとミクロの両方のレベルで。

しかしデータの収集と分析にはお金がかかり、国レベルの情報共有システムともなるとさらにお金が要る。そこで研究者たちの結論は、それをすることのメリットを分かりやすい言葉で説得していくことだ。結局のところ、お金の余裕のない州当局が、既存の実際に役に立っているサービスではなく新奇なデータプロジェクトに数百万ドルを投じるとしたら、そこまでする動機やメリットはなんだろうか?

研究者たちは、水と水のデータが極端に軽視されている、と断言する。カリフォルニアで最近の大規模な干ばつのとき行われたような、既存のデータ収集努力を検分することによって、オープンなデータにアクセスできることの具体的な利点を示せるのではないか、とも期待している。

それでも、こんな状況は、きれいな水の入手にはまったく問題がなく簡単でやさしい、ということを意味しているのではない。水不足や季節変動は、自然資源が今後さらに枯渇し、人口が増加するに伴って、ますます深刻になる。

“有限な水資源に対して需要は成長している。適正なトレードオフを見つけるためには、オープンで誰もがアクセスできるデータが必要だ”、カリフォルニア州水管理委員会のGreg Gearheartはそう語った。

デュークのチームが好んでそう呼ぶ“水のインターネット”は、すべての自治体からの、水に関するあらゆる種類のデータが集まるクリアリングハウスだ。関心を持つ一般市民や、行政府のデータサイエンティスト、それにアプリケーションのデベロッパーなど、誰もがそれにアクセスできる。

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

Google Compute EngineがCPU 96コア、メモリ624GBの巨大インスタンスを提供、プロセッサーもグレードアップ

どんなにリソース大食漢のアプリケーションでも、Google Compute Engine(GCE)なら満足するだろう。今度新たに、CPU 96基、メモリ624GBという怪物インスタンスが生まれたのだ。Bill Gatesは昔、誰が一体640KB以上ものメモリを必要とするんだい?と言ったらしい。彼には、今日のような日が来るとは想像もできなかったのだ。

これは、本当の話ですよ。しかも、ちょっと前の3月にはGCEは64コアのCPU + 416GBのメモリというインスタンスを発表している。今回は、それを上回る。

使用するチップは、たぶんご想像どおり、IntelのXeon Scalableプロセッサー(コードネームSkylake)だ。Googleによるとこの子は、前の世代のXeon系列に比べて計算性能が20%速く、high performance computing(HCP)では82%より高速、メモリ帯域はほぼ2倍だ。もちろん、これで十分という性能は永遠にないけどね。

それほどのパワーは要らない、というユーザーは、ご自分のワークロードに合わせてCPUとメモリの構成をカスタマイズできる。

Googleによると、今回の巨大インスタンスは、その性能をすでにSAP HANAで実証している。SAP HANAは、ドイツのソフトウェア大手によるインメモリデータベースで、ユーザーの必要に応じてメモリをいくらでも使える。

624GBでも足りない、というユーザーに対応するためGoogleは今、最大4TBまでメモリを搭載できる製品を開発中だ。お金をしっかり用意して、待っていよう。本日(米国時間10/5)紹介されたインスタンスは、一時間約4ドル95セントからだ。

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

Googleがアプリデベロッパーのための新しいデータベースCloud Firestoreを立ち上げ

Googleが今日、アプリデベロッパーのためのプラットホームFirebase用に、新しいデータベースサービスを立ち上げた。そのCloud Firestoreと呼ばれるデータベースは既存のFirebase Realtime Databaseを補完するもので、両者の重複部分も多い。

Firebaseの協同ファウンダーJames Tamplinによると、Realtime Database(RTDB)はつねに、Firebaseプラットホームの旗艦的プロダクトであった。そのサービスは今や、数十万ものデベロッパーに利用されている。そしてTamplinの説では、デベロッパーにそれほど人気があるのは、データベースアクセスがリアルタイムであり、しかも管理やスケールアップ/ダウンはGoogleがやってくれるからだ。

彼によると、しかしそうやってサービスの規模が大きくなると、デベロッパーが不満を感じる部分も出てきたので、それを解決するためにCloud Firestoreを立ち上げた。不満はたとえば、RTDBでは複雑なクエリを扱いにくい。プラットホームのアーキテクチャのせいで、同時接続デバイス数が10万を超えるとシャーディングでデータベースを分割しなければならない。それでは、RTDBの本来の利点がなくなってしまう。

既存のデータベースサービスの改築工事はきわめて困難なので、チームは新築を選んだ。Cloud Firestoreはまったく新たに設計され、さまざまなユースケースをサポートする。たとえば、ローカルなデータベースを併用してオフラインのアプリを作るとか、複数のアプリやユーザー間でデータのリアルタイムのシンクができる、など。

すべてのデータが複数のリージョンにまたがって自動的に複製され、整合性も完璧だ。また、前と同様、スケーリングは自動的に行う。

さらに、Cloud Firestoreのクライアント側SDKにはアプリの認証やネットワーキングのコードもあり、またそのバックエンドは、いくつかのセキュリティルールによりデータへのアクセスを制御し、ユーザーの正当性を検証する。したがってアプリは、ユーザー確認のためのプロキシなどを使わずに、直接データベースにアクセスできる。

そしてもちろん、これらがすべてFirebaseのプラットホームに深く統合されている。したがってGoogleのサーバーレスプラットホームCloud Functionsも使える。

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

AWSがOracle Larry EllisonのRedshift批判に反論、“例によってLarry節だ”と

Oracle OpenWorlカンファレンスのキーノートでOracleのLarry Ellison会長が同社の新製品、全自動データベース(autonomous database, 自律的データベース)を発表したとき、彼は数分間にわたり、クラウド市場における同社の強敵AWSをけなした。マーケットリーダーであるAmazonをEllisonが標的にするのは当然だが、しかしAWSは今回、彼のコメントに公開の場で反論した。

AWSがとくにひっかかったのは、同社のビッグデータウェアハウスAmazon Redshiftがエラスティックでない、というEllisonの主張だ。Ellisonはこう語った: “Amazon Elastic Cloudと呼ばれているのは知っていますが、でもそれはエラスティックではありません。すなわちAmazonのデータベースRedshiftは、ワークロードが大きくなったとき自動的にプロセッサーの数を増やせません。逆にそれを、減らすこともできません。そんな能力が、そもそもないのです”。彼はさらに、Redshiftでは手作業でシステムを停止し、新しいインスタンスを立ち上げ、データベースを新しいストレージにコピーし、その後の稼働結果を古いデータベースへコピーバックしなければならない、と主張した。

これに対しAmazonのスポークスパーソンは応じた: ばかばかしい(もっと多くの言葉で)。

“まず、それは事実ではない。Amazon Redshiftでは、顧客は必要に応じてクラスターをリサイズできるし、コンピュートをストレージとは別にスケールできる。Amazon Simple Storage Serviceのデータに対してRedshift Spectrumを使えるし、顧客はストレージとは無関係に単純にクェリに対して支払うだけでよい”。

さらに彼らは、Ellison自身についても非難した: “でも多くの人は、Larryという人物をすでによく知っている。事実に基づかない乱暴な主張、そして、大量のこけ脅かしが、彼の常套手段だ”。

エラスティック(elastic, 伸縮自在)というのは、ジョブのサイズに応じて計算機資源が自動的に拡大縮小することだ。Ellisonの場合ジョブとは、データベースの運用、クェリの処理だ。

エラスティックであること、リソースの伸縮が自動的に行われることは、クラウドコンピューティングサービスの主な魅力のひとつだ。まるで、音量ボリュームのつまみを回すときのように簡単に、使用するリソースの増減ができる。自前のデータセンターだと、誰も自動的にリソースを増減してくれない。必要なキャパシティは新たに買わなければならないし、しかも今後の余裕を見て、今の必要量よりも多い買い方をしなければならない。資金の無駄遣いである。

それでもなお、ホリデーギフトシーズンのショッピングでデータ量が予想を超えてスパイクしたら、万事休すだ。リソースを、その日のうちに、しかもその日一日だけのために、買い増すことはできない。しかしクラウドなら、リソースの必要な伸縮が自動的に行われ、‘一日’という短期的なニーズにも対応できるから、リソースの無駄なアロケーションも発生しない。

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

Oracleのイベントでラリー・エリソンが自律DB発表――AWSをからかう

Oracleはクラウド化の波に大きく取り残されており、ラリー・エリソン会長はそのことをよく知っている。そこでエリソンはあらゆる機会をとらえて最大のライバル、AWSに嫌味を言うことにしている。昨夜のOracle OpenWorldイベントのキーノートに登場したときも例外ではなかった。エリソンは自律的にチューニングを行う新しいデータベース・システムを紹介したが、同時にAWSを批判するという誘惑に勝てなかった。

今回発表されたスマート・データベースはテクノロジー的にみてクールなプロダクトに思える。エリソンとしては数分も割いてライバルについて論ずるより、自分たちの新しいデータベースの説明に集中したほうが効果的だったのではないか? このデータベースは、完全に自律的に作動するという。つまりチューニング、プロビジョニングを自ら実行できる。エリソンはこれを自分の自家用ジェット機の自動パイロットにたとえた(イベントの聴衆に自家用ジェットの所有者がどのくらいいたか知らないが)。つまり「今後はパイロットのエラーという事態は起きない。パイロットは乗っていないからだ。このデータベースではアドミニストレーションは完全に自動化されている」とエリソンはキーノートで述べた。

それに加えて、このデータベースには自己修復能力がある。なんらかの理由でデータベースの一部が壊れた場合、データベースは自らその部分を修復して運用を続ける。この能力があるため、Oracleは稼働率として99.995%を保証するという。エリソンはこれを「1年の作動あたり、計画的、突発的合わせて30分のダウンタイム」にすぎないと大胆に宣言した。

またエリソンは契約書にうたわれる4ナイン(99.99%)、5ナイン(99.999%)といった数字は「実質的にウソだ」と述べた。なぜならこの数字は通例ソフトウェアのバグ、セキュリティー・パッチのインストール、構成の変更などにともなうダウンタイムを除外してしているからだという。しかしOracleの新しいデータベースがいかにしてこうしたダウンタイムを一切排除できるのかについてエリソンは詳しく述べなかった。大規模なDDoS攻撃、最近アメリカを襲ったような猛烈なハリケーン、雷、それどころか単なるヒューマン・エラーも大規模なシステム障害を起こすことが知られている(昨年AWSに起きた障害がよい例だ)。

ともあれ、エリソンは何分か使ってAmazonのRedShiftを批判した。クラウドコンピューティングは非常に複雑なビジネスだが、赤丸付き急上昇でチャートのトップに立ったのはもちろAWSだ。一部の推定によればAWSのシェアはクラウドコンピューティング市場の40%を占めているという。2位のMicrosoft Azureは10%で、他はOracleも含めてこのトップ2社に遠く及ばない。

新しい自律的データベース・サービスは(18cというおよそ想像力を欠いた名称だが)、現在のOracleの強みを生かしながらクラウドでAmazonと戦おうとする試みだ。AWSはクラウド・ビジネスで何年も早くスタートを切り、巨大なシェアを誇っている。しかしOracleはデータベースを隅々まで知っており、これはクラウドに移行してもAWSより優位に立てる点のはずだ。

今回のイベントでのエリソンの発表は注目すべきものだったが、「プディングの良し悪しは食べてみるまでわからない」ということわざもある。このデータベースの能力も実際に運用されてみて初めて判明するだろう。Oracleによれば、新データベースは今年中に利用可能となるという。

画像:: Bloomberg/Getty Images

[原文へ]

(翻訳:滑川海彦@Facebook Google+

AlibabaがMySQL代替系MariaDBへの2700万ドルの投資をリード、クラウド事業に本腰

【抄訳】
Alibabaは2017年をクラウドコンピューティング事業への注力に費やし、そして今度はその分野の西側のスタートアップに、初めての大きな投資をしようとしている。

この中国のeコマース巨人は、MariaDBへの2290万ユーロ(2700万ドル)の投資をリードすることに合意した。西側すなわちヨーロッパの企業であるMariaDBは、Webでいちばん多く使われているオープンソースのデータベース(社名と同じMariaDB)を作っている。今回の投資案件に詳しい情報筋によると。投資はまだ完了していないが、MariaDBの株主たちが今週OKを出したので、完了も至近だそうだ。

AlibabaとMariaDBの両社は、本誌からのコメントのリクエストに応じていない。

TechCrunchが聞いた話によると、Alibabaが2000万ユーロを出し、残りは既存の投資家 たちが出すらしい。投資に際してのMariaDBの評価額は約3億ユーロ(3億5400万ドル)で、Alibabaのクラウド事業の主席技術者Feng Yuが、MariaDBの取締役会に加わるようだ。

5月にEuropean Investment Bankから2500万ユーロ(当時で2700万ドル)を調達したときは2億から2億500万ドルの評価額だったから、かなりの増加だ。情報筋によると、今後のAlibabaとの事業関係への期待がMariaDBの評価額を押し上げた、といわれる。

MariaDBは、もっとも人気のあるMySQL代替DBMSでよく知られている。MySQLもオープンソースだが、Sun Microsystems次いでOracleと、企業がオーナーだったために、最初の頃と違って完全なフリーではない。そこで、MariaDBのような代替系が求められるのだ。

そしてAlibabaのクラウドコンピューティング事業は、同社の最速成長部門だ。ここ数年、毎年、3桁の売上増加額を記録している。

【後略】

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