GraphQLサービスを提供するHasuraが約26.5億円を調達、MySQLを新たにサポート

米国時間9月8日、データベースにアクセスするためのGraphQL APIを生成するオープンソースエンジンを提供しているHasuraが、シリーズBで2500万ドル(約26億5500万円)を調達したと発表した。このラウンドを主導したのはLightspeed Venture Partnersで、以前に投資していたVertex Ventures US、Nexus Venture Partners、Strive VC、SAP.iO Fundも参加した。

今回のラウンドは新型コロナウイルス(COVID-19)の感染が拡大してから開始されたもので、同社がシリーズAで990万ドル(約10億円)を調達したと発表してから半年しか経っていない。Hasuraはこれで合計3560万ドル(約38億7500万円)を調達した。

Hasuraの共同創業者でCEOのTanmai Gopal(タンマイ・ゴパル)氏は筆者に対し「2020年に企業からの引き合いが急速に増えた。企業の顧客の成功のために、Hasuraのコミュニティと最近公開したクラウド製品への投資を加速しようと考えた。VCのインバウンドの関心を考えると、アクセルを踏み余裕をもって成長するための資金調達は理にかなっていた」と述べた。

Hasuraは同日、新たな資金調達に加え、MySQLデータベースに対応したことも発表した。これまで同社のサービスは、PostgreSQLデータベースにのみ対応していた。

左:共同創業者でCOOのRajoshi Ghosh(ラジョシ・ゴーシュ)氏、右:共同創業者でCEOのTanmai Gopal(タンマイ・ゴパル)氏(画像クレジット:Hasura)

ゴパル氏が筆者に対して述べた通り、MySQLのサポートはユーザーからのリクエストが最も多い機能だった。医療分野や金融サービス業など多くのユーザーがレガシーなシステムを使い、モダンなアプリケーションと接続しようとしている。そのためには、長く使われてきたMySQLが重要な役割を果たす。

MySQLに加えSQL Serverも新たにサポートするが、こちらはまだ早期アクセスの段階だ。

ゴパル氏は「MySQLとSQL Serverに関しては、医療や金融サービス、フィンテックのユーザーから多くのリクエストがあった。こうしたユーザーはオンラインのデータ、特にこの2種類のデータベースのデータをすでに大量に持っていて、アプリケーションをモダナイズしつつ新しい機能を構築して有効活用したいと考えている」と述べた。

Hasuraは今回の発表のわずか数カ月前に、企業向けにすでに提供していた有料のProサービスを補完するものとしてフルマネージドのクラウドサービスを公開したばかりだった(未訳記事)。

Lightspeed Venture PartnersのパートナーでHasura取締役のGaurav Gupta(ガウラブ・グプタ)氏は次のように述べている。「開発者がHasuraを採用し、GraphQLのアプローチでアプリケーションを構築していることに、たいへん感銘を受けている。特にReactのようなテクノロジーを使うフロントエンドの開発者にとっては、Hasuraを使えばアプリケーションをすべてのデータが保管されている既存のデータベースに簡単に接続でき、セキュリティやパフォーマンスの問題もない。Hasuraはクラウドネイティブのアプローチでアプリケーションを再プラットフォーム化する素晴らしい橋渡しとなるため、企業の開発者にとってもフロントエンドの開発者にとってもますます魅力的なものになるだろう」。

Hasuraは新たに調達した資金でさらに多くのデータベースをサポートし、さまざまなデータベースが加わることによる難しい技術的な課題やアプリケーションレベルのデータキャッシュシステムに取り組む計画だ。ゴパル氏は「市場獲得戦略とエンジニアリングを両輪として成長できるように企業づくりにもしっかりと投資し、こうした分野の上級職の社員を雇用している」と述べた。

画像クレジット:Fernando Trabanco Fotografía / Getty Images

[原文へ]

(翻訳:Kaori Koyama)

YouTubeで開発されたDBaaSにアンドリーセン・ホロウィッツなどが24億円超を投資

PlanetScaleの共同ファウンダーは元YouTubeのエンジニアで、このサービスの巨大化を助けたVitessデータベースシステムの開発者だ。現在2人が創業したスタートアップは大規模なデータに迅速にアクセスすると同時にセキュリティーも確保したい企業にVitessを販売している。

Vitessは稼働中に簡単にデータベースのレプリケーションができるのが大きな特徴だ。 この機能はEUのGDPR(一般データ保護規則)の遵守を容易にする。GDPRではユーザーデータをそのユーザーが居住する国に保存しなければならないことが要求され、これが企業にとって大きな負担となっている。

PlanetSacaleはAmazonのAWSのライバルであり、同時に補完関係にある。またコンピューティング全般のインフラとなる可能性があることを考えれば、シリーズAで2200万ドル(約24億円)という巨額の資金調達に成功したことも不思議ではない。ラウンドをリードしたのはAndreessen Horowitz(アンドリーセン・ホロウィッツ)で、長年Googleのスパム対策のトップを務めたことで知られるマット・カッツ(先月、大統領直属のUSデジタル・サービス責任者に就任)や以前からの投資家であるSignalFireが加わっている。1年前にPlanetScaleが調達したシード資金は300万ドルに過ぎなかったことを考えれば一大飛躍だ。

今回の投資を機会にAndreessen Horowitzのジェネラル・パートナーであるPeter Levine氏がPlanetScaleの取締役に就任し、エンタープライズ向け事業に関するノウハウによってスタートアップを助ける。

PlanetScaleの共同ファウンダー、左から Jitendra Vaidya氏、Sugu Sougoumarane氏

CEOのJitendra Vaidya氏は次のように述べている。

以前我々はAWSやRDBをホスティングするサービスをライバルと考えていたが、むしろパートナーだということに気づいた。われわれのサービスはAWSなどのデータベースホスティングサービスのフロントエンドとして大きな需要がある。PlanetScaleは順調に成長中だ。

ライバルのデータベーススタートアップも巨額の資金調達を行っているのでPlanetScaleも対抗する必要があった。Andreessen Horowitzと関係を作れたことは大きな成果だ。テクノロジーとして見ると、VitessはGoogleが開発したKubernetesの先行者にあたり、MySQのミドルウェアとなってデータベースの水平的規模拡張を助けるプロダクトだ。Vitessは信頼性とパフォーマンスを損なうことなく大規模データベースのメモリー効率を高めるプロダクトとしてまずYouTubeのバックボーンに採用された。2014年にSugu Sougoumarane氏自身が下のビデオでVitessの仕組みを説明している。

PlanetScaleのVitessの販売は4つのチャンネルに分かれている。一つは自社サーバーを利用したデータベース・アズ・ア・サービス(DBaaS)、 次はクライアントがオンプレミスないし他のクラウドで利用するためのテクノロジーのライセンス、 3番目はデータベース専門家に対するVitess利用の教育、4番目がオープンソース版Vitessを利用するユーザーに対するオンデマンド・サポートだ。PlanetScaleには現在18社と契約して有料サービスを提供しているが、近くサビスを一般公開する計画だ。【略】

PlanetScaleは充分な資金を得たため人員を現在の20人から倍増させ、サポート、セールス、マーケティング部門を強化する計画だという。CEOのJitendra Vaidya氏は「我々共同ファウンダーは2人ともエンジニアなので、技術面に関しては心配していない。しかしエンタープライズ向け市場に参入するための戦略が必要だ」と説明する。

Andreessen Horowitzのような有力ベンチャーキャピタルがリードするシリーズAで2200万ドルを調達できたのはどんなスタートアップであれビッグニュースだが、PlanetScaleの場合はテクノロジーエコシステム全体に対する影響が大きい。EUのGDPRは巨大テクノロジー企業の行動を抑制することを目的としているが、実態としては大小あらゆる企業にコンプライアンス・コストを強いるものとなっている。皮肉なことに、このコスト負担はリソースに余裕のある大企業より中小のビジネスに重くのしかかるものとなっている。

「データの保存場所をユーザーの居住国にローカライズせよ」というGDPRの要求はスタートアップにとって耐え難い負担となる。PlanetScaleのVitessは単にデータベースの運用を省力化、効率化するだけでなく、GDPRを遵守することを可能にする。PlanetSclaleのサービスを利用することで、スタートアップは新しいサービスを提供するという本来の目的に専念できるようになるだろう。

原文へ

(翻訳:滑川海彦@Facebook

VMwareがその顧客元実装上にAWSのRelational Database Serviceを導入

ちょっと意外なニュースだ。Amazonのクラウドコンピューティング部門であるAWSが、今日(米国時間8/27)の発表によると、同社のRelational Database Service(RDS)をVMwareに持ち込む。それはAWS上のVMware Cloudと、企業が自分のデータセンターでプライベートに動かすVMwareの両方だ。

AWSのコンペティターの一部は、かなり前から、こういうハイブリッドなクラウドのデプロイにも力を入れてきたが、AWSはそれほどでもなかった。でも今や、それが変わろうとしている。それはたぶん、Microsoftなどの競合他社がこの分野で好調だからだろう。

AWSのCEO Andy Jassyはこう述べている: “データベースは、その管理にも運用にも、泥沼のように面倒で厄介な側面がある。だからこそ何十万もの顧客がAmazon RDSを信頼して、大規模なデータベースの管理を任せているのだ。この、オペレーションの現場で鍛えられた同じサービスを、オンプレミスやハイブリッド環境の顧客にご提供していけるのは、とてもすばらしいことだ。それによって、エンタープライズのデータベース管理が容易になるだけでなく、データベースをクラウドに移行する作業も、より単純になる”。

Amazon RDSがVMwareに来たことによって、エンタープライズは、AWSの技術を利用してMicrosoft SQL ServerやOracle, PostgreSQL, MySQL, MariaDBなどのデータベースを利用できる。たとえば、どこでデータをホストするにしてもデータベースのセットアップと管理が楽になる。…そして将来的には、AWSへの移行も容易になるだろう。

この新しいサービスは目下非公開プレビューなので、その詳細や料金などはまだ分からないが、ユーザー体験はクラウドの場合とほぼ同じだろうし、VMware上のRDSもアップデートやパッチを自動的に行なうことになるのだろう。

今日の発表は、AWS上のVMware Cloudのローンチから約2年後になる。それは今日の発表の真逆で、VMwareがAWSに来る、というものだった。VMwareのデプロイを動かしているエンタープライズは、それをそのまま、AWSへ移せるのだ。

関連記事: VMwareがついにクラウドサービスを提供、しかもAWSとのパートナーシップのもとで

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

Facebook、圧縮アルゴリズムのZstandardとストレージエンジンのMyRocksをオープンソース化

Illustration and Painting

今日(米国時間8/31)Facebookは、圧縮アルゴリズムのZstandardをオープンソース化する。時代遅れとなったDeflate圧縮アルゴリズムを使用しているzlibライブラリーを置き換えることが、このロスレス技術の目的だ。さらにFacebookは、zStandardに加え、ストレージエンジンのMyRocksもオープンソース化する。MyRocksは、Facebook社内でMySQLデータベースのストレージ効率を高めるために使われている。

いずれも、カリフォルニア州サンノゼで行われたFacebookの@Scaleカンファレンスで発表された。このカンファレンスは、大規模な技術的課題を抱えるエンジニアたちを集め、オープンソース技術の発展に力を入れている業界各社と共に解決するのを支援することを目的としている。ZstandardやMyRocksを使うと、デベロッパーは大規模で多様なユーザー基盤に効率よくスケーリングできるプラットフォームを作ることができる。

重要なインフラストラクチャーの更新や置き換えを考えているエンジニアにとって、最大の恐怖は新しいライブラリーがシステム全体をダウンさせてしまうことだ。Facebookのインフラストラクチャー技術担当VP、Jay Parikhは、ZstandardもMyRocksも、デベロッパーに公開する前にFacebookで全社規模でテストされていることを誇らしげに語った。

「ここにいる全員が両製品を使っている」とParikhは言った。

Zstandardをテストした6ヵ月間に、Facebookはすばらしい結果を残した。zlibと同じ圧縮比ならZstandardの方が5倍も速かった。圧縮時間が同じなら、ファイルサイズは10%小さかった。

MyRocksもまた、ストレージ効率を著しく改善した。InnoDBとの比較で、MyRocksは同じ量のデータを半分のサーバースペースに保存することかできた。

「オープンソースにすることは、コミュニティー全体の利益になる。単独の企業が所有しているよりも、オープンソースにした方が早く普及する」とParikhは話した。

Facebookは、同社のオープンソースソリューションが新たな業界標準になることを期待している。

[原文へ]

(翻訳:Nob Takahashi / facebook

MySQLの創始者たちが提唱するビジネスソースライセンス(BSL)とは

Software licenses GPL LGPL Flat 3d isometric concept vector. Wordplay propane fuel LPG become acronym of software license. Open source code it not means gratis. How to refuel your own software.

オープンソースライセンスについて言えば、開発者たちは十分な選択肢をもっている(GPL、BSD、MIT、Apacheなど)。それぞれのライセンスには長所と短所がある。同じことは、商用ライセンスにも適用される。しかしMySQLの創始者Michael “Monty” Wideniusと共同創始者David Axmarkは数年前に、別のモデルを思い付いた: ビジネスソースライセンス (BSL)である。

この新しいライセンスは、多くのスタートアップがそのソフトウェアに対して選択しているクローズドソースかつオープンコアのライセンスへの代替策を提供するものだ。そしてWideniusの新会社MariaDBは、初めてそのライセンスをプロダクトの1つに適用した

いくつかの点で、BSLは(オープンソースのひねりを加えた)ソフトウェアライセンスのフリーミアムのモデルに似ている。Wideniusが私に説明したように、BSLは本番運用時にどれくらいの規模のサーバ/CPUその他の利用を許諾できるかの指定を、開発者に認めるものだ(利用制限は本番利用にのみ適用され、テスト環境には適用されない)。指定規模以上での利用には、ライセンス料が発生するという仕組みだ。

これはきわめて標準的な商業用ライセンスのように聞こえるが、工夫が加えられている点は、ソースコードのすべてが常に参照可能であることと、BSLライセンスには有効期限があることだ。一定期間後(例えば3年とか)にライセンスが期限切れとなり、その後は開発者が選択したGPLその他の任意のライセンスに戻る。

「これは全く新しいエコシステムを生み出すことができます」とWideniusは私に語った。「そしてオープンソースが一度に手に入らなくても、将来的にはより多くのオープンソース・アプリケーションが生み出されます」。これらは力強い言葉だ。オープンソースの世界での彼の経験を踏まえるならば、彼とAxmarkがBSLを思い付いた経緯と理由を詳しく見てみる価値はある。

これは全く新しいエコシステムを生み出すことができます。そしてオープンソースが一度に手に入らなくても、将来的にはより多くのオープンソース・アプリケーションが生み出されます。

— Monty Widenius

Wideniusはライセンスについて多大な経験を持っており、MySQLのために作ったライセンスのおかげでかなりの財を成すことができた。「MySQLのようなプロダクトにとってGPLは本当によく出来たライセンスです、なぜならMySQLは企業がそのプロダクの中に統合したいようなものだからです」と彼は説明する。GPLライセンスのプロダクトを自社のプロダクトに統合するには、自社のソフトウェアもまたオープンソースにする必要がある。そうしたくないユーザーに対しては、WideniusとAxmarkが設立したMySQL AB社は、商用ライセンスを提供していた。

彼らが2008年に、MySQL ABをSunに売却時したときには、同社の収入の70%がライセンスから来ていた。「それがMySQLが巨大な価値を持っていた理由です」とWideniusは語る。「私たちはプロダクトの会社であり、人々は特定の状況下ではそれに対して支払いを行わなければなりませんでした」。

Wideniusは、実際にはBSLのバリエーションをもっと早くから使用したいと考えていた「…のですが、当時の経営陣は現在に比べて先を見通して居なかったため、クローズドソースで行くことになったのです」。そして数年前のこと、彼は自身のベンチャーキャピタル会社Open Oceanに多くのスタートアップがやってきて、彼らのエンドユーザープロダクトをオープンソースにしたがっていることに気が付いた。そうした企業のためには、MySQLのためには上手く行ったデュアルライセンスモデルは上手く働かなかった。なぜなら彼らは他のソフトウェアを自身のプロダクトの中に埋め込まなかったので、ライセンスに対して支払いをする理由がなかったのだ。

オープンソースにしたいと考えているほとんどの企業が、そうしたケースでやろうとしていることは、オープンソースツールの周りにサービスを提供するビジネスの構築だ。Wideniusはこのビジネスモデルがうまく行くとは思っていない(彼はそれがいくつかの会社では上手く行っていることを認めてはいるが)。「これは、プロジェクトをサポートする企業のためには上手くいきます – 人々はUbuntuのためのサポートを与え、そこからお金を稼ぐということです」と彼は言う。「しかし、ライセンスを持っていない企業は、プロダクトを作ることはほぼできません」。それは何故か?もしあなたが良いサポート担当から10パーセントのマージンをとるとすれば、1人の開発者を雇うためには10人のサポート担当が必要となる。彼の見方では、このモデルはスケールしない。

そこでMariaDBでは、チームはそのMaxScaleデータベースプロキシの最新バージョンをBSLで提供することにしたのだ(MariaDB自身はMySQLの変種なので、MySQLが従っているGPLにこの先もずっと従う)。

Wideniusが認識している限り、2つまたは3他の企業もすでにこのライセンスを利用しているが、彼は今は多くの企業が大企業が動くのを待っているのだと見ている。チームはまた、開発者が自身のソフトウェアをBSLに移行する際のフレームワークを与えるドキュメント作りを行っている。

新しいプロジェクトのためにBSLを採用したい開発者は、わずか4行を記入するだけだ:製品の名前、それ以上はユーザーが対価を払わなければならない制約条件、いつライセンスがオープンソースライセンスに変更されるかの情報、そしてどのライセンスになるのかの記述。

プロダクトの更新をするたびに、BSLライセンス期限も延長することになるので、開発者は自身のソフトウェアを最新に保つためのインセンティブが得られることになる。しかし彼らが最新版を提供しない場合 – またはユーザーが古いプロダクトで満足の場合 – にはBSLライセンス期限の訪れとともに新しいライセンスが適用されることになる。これはまた、開発者が廃業したときには、BSLライセンス期限以降にソフトウェアはオープンソースとなり、コミュニティが仕事を継続できることを意味している。

「多くの人が、間違った理由でこのライセンスを批判しています」とWideniusは私に言った。「しかし私は、これはより多くのオープンソースを生み出すことによって、オープンソースの将来をより良くするチャンスだと思っているのです – たとえ少々時間の遅れがあるとしても」。

[ 原文へ ]
(翻訳:Sako)

Webサーバを攻撃するLinux上のランサムウェアが出没、身代金は1ビットコイン

encoder-1

新種のランサムウェアがLinuxマシンを攻撃している。とくに、サーバがサーブするWebページ関連のフォルダが被害者だ。そのLinux.Encoder.1と呼ばれるランサムウェアは、MySQL、Apache、およびhomeやrootのフォルダを暗号化する。そしてファイルを解読するために1bitcoinを要求する。

以下、Dr.Web Antivirusより:

管理者権限で侵入したこのLinux.Encoder.1と呼ばれるトロイの木馬は、犯人が求めるファイルと、RSAの公開鍵のパッチのあるファイルをダウンロードする。そのあと、その悪質なプログラムはデーモンを始動し、元のファイルを削除する。その後RSAキーを使ってAESキーを保存し、トロイの木馬はそれを利用して、感染したコンピュータの上のファイルを暗号化する。

最初にLinux.Encoder.1はhomeディレクトリと、Webサイトの管理に関連したディレクトリ内のすべてのファイルを暗号化する。それからトロイの木馬は、自分が侵入したディレクトリとその下のファイルシステムのすべてを再帰的にトラバースする。さらにその次は、rootディレクトリ(“/”)とその下を襲う。そのときトロイの木馬は、犯人が指示した文字列のどれかで始まる名前のディレクトリのみを訪ね、指定した拡張子のあるファイルだけを暗号化する。

 

被害者がランサム(ransom, 身代金)を払うとシステムは信号を受け取り、再びディレクトリをトラバースしてファイルの暗号を解く。このマルウェアは自分が動くために管理者権限を必要とし、またおそらく、そのようなプログラムにうかつに実行許可を与えるようなシスアドミンを必要とする。Dr.Webのチームは、すべてのデータをバックアップすることと、攻撃された場合には、研究者たちが脱暗号化システムを作るまで被害の現状を保全することを、勧めている。

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

これからのアプリケーションはデータセンタースタックを必要とする

grid-platform-data

[筆者:Derrick Harris ]
編集者注記: Derrick HarrisはMesosphereのシニアリサーチアナリスト。Harrisは最近GigaOMに、クラウドとビッグデータについて書いた。

インターネットはこれまでの20年間で生活を大きく変えた。Webとモバイルのアプリケーションで、どこからでも、情報の検索と買い物とスムーズなコミュニケーションができ、しかもそのスピードは、これまでありえなかったほどに速い。車のダッシュボードでおすすめの映画を知り、携帯電話でビデオの制作と掲載ができる。温度計を買えば、仕事に出かける時間に暖房を消してくれる。

テクノロジ業界の外にいる人には、これらの技術進歩がマジックのように見えるかもしれないが、実際にこれらのアプリケーションを作っている人たちは、そこにどれだけ多くのものが込められているかを理解している。でも最近ではビジネスの世界にいる人たちみんなが、それを理解していることが重要になりつつある。

その理由は簡単だ: 優秀な企業は、次の10年の企業競争で落伍しないためにはITについてまったく新しい考え方をしなければならないことを理解している。モバイルアプリから冷蔵庫に至るまでのあらゆるものが、さらに一層個人化され、一層インテリジェントになり、より機敏に反応しなければならない。企業は機械学習を行い、センサのデータを取り入れ、ユーザのトラフィックの予期せざる急騰に無事に対応しなければならない。

後戻りはできない。アプリケーションが、ユーザが期待する体験を提供できなければ、彼らは、それを提供できるほかのアプリケーションを見つけるだろう。

アプリケーションのアーキテクチャの革命

アプリケーションとWebサイトのユーザは、過去数年間で百万のオーダーに達し、アプリケーションのそれまでのアーキテクチャは、その膨大な量のトラフィックとユーザデータに対応できなくなっている。さらに最近では、その大量のデジタルデータを有効利用しようという欲求が生まれ、その目的だけに奉仕するまったく新しい種類の技術への関心が芽生えてきた。

それらの技術には多くの場合、サーバの複数のクラスタにまたがって容易にスケールできるように設計された新しいストレージや処理能力、およびデータベースのフレームワークを作ることが含まれている。またさらに、これら各部位間の情報の移動を単純化し、高速化することも求められる。GoogleやLinkedIn、Facebook、Yahoo、Twitterなどの大きなインターネット企業では、この同じ一般的パターンが、何度も何度も繰り返し実装されている。

たとえばデータベースのレイヤでは、ほとんど誰もが関係データベースからスタートし、今になって新しいプランを考えなければならなくなっている。一部の企業は、MySQLデータベースをその自然な限界を超えて酷使するために、秘かに何百万ドルもの費用と人時間を投入し続けている。逆に新しいデータベース技術を作ったところもあるし、新旧の二股をかけているところもある。

またビッグデータの処理でも、新しいパターンが生まれている。具体的な技術はさまざまでも、今の大型Web企業に共通している新しいアーキテクチャは、データ処理のリアルタイム部分と、準リアルタイム部分と、バッチ部分という三層構造だ(下図)。必要に応じて、個人化されたWeb体験やコンテンツ体験をリアルタイムで高速に提供しなければならない。しかしまた同時に、社内のデータアナリストやデータサイエンティストたちが、データの集合に対して彼らの能力を十二分に発揮できなければならない。

MachineLearningArchitecture-v3

アプリケーションの構成部位としてのデータセンター

今ITに起きているイノベーションは、ものすごいスケールだ。GoogleやFacebook、Amazonなどは日々数十億のユーザに奉仕し、数百万件のユーザ対応処理が並列で行われている。それと同時に、大量のデータが保存される。しかしそれでも、彼らはめったにクラッシュしない。Twitterも、インフラストラクチャに思い切った投資をしてからは、あのfail whale(クジラさん)が現れなくなった。

これらの企業はこれまで、MapReduce、Hadoop、Cassandra、Kafkaなどなど、数々の技術を生み出してきた。また無名のスタートアップやデベロッパたちも、主にオープンソースの世界で、アプリケーションのパフォーマンスをとスケーラビリティを高め、ときにはまったく新しい機能を実現するための新しいツールを作ってきた。それらの中では、Spark、Storm、Elasticsearchなどがとくに有名だ。

また、そのような極端に巨大なスケールでも安定して動くアプリケーションを開発するための、アプリケーションの新しいアーキテクチャも生まれてきた。

たとえば、今いちばんもてはやされているのがマイクロサービスだ。これはアプリケーションを個々のサービスの集合として構成するアーキテクチャで、部品であるサービスは複数のアプリケーションから使われてもよい。これまでの、一枚岩的なアプリケーションアーキテクチャでは、各部位がそのアプリケーションの専用の部品として閉じ込められている。しかし、自立した個々のサービスの集まり、という新しいアーキテクチャでは、各部位間や、部位と特定のアプリケーションとのあいだの依存性がなくなり、サービスのスケールアップをアプリケーションの再構築を必要とせずに実現できる。

また、マイクロサービスと並んでビッグなトレンドになっているのが、コンテナ化だ。コンテナは、Dockerのようなデベロッパフレンドリなフレームワークを利用して作ってもよいし、もっと低レベルにLinux control groupsを使ってもよい。コンテナに収めたアプリケーションは分散サービスに容易にプラグインでき、いつ何をどこで動かすか、などをいちいち気にする必要がなくなる。コンテナがあることによってデベロッパは、自分のアプリケーションの機能や構造の磨き上げに集中できる。

以上のような、分散サービスの集合体とコンテナ化という新しいアーキテクチャ技術を一つの全体として見た場合には、それを“data center application stack”(データセンターアプリケーションスタック==アプリケーションの基本構成要素としてのデータセンター)と呼べる。奉仕すべきユーザが複数のプラットホーム上に何百万もいるようなアプリケーションを作り、それらのアプリケーションが多量かつ多様なデータをハイスピードで利用していくときには、どうしてもそういう、サービスの集合体的なものを使うことになる。したがって高性能なデータセンターが、いわば、アプリケーションの心臓部になる。

これらは、将来そうなるという説ではなくて、今急速に進展しているトレンドだ。巨大な消費者アプリや、Salesforc.comのような巨大なビジネスアプリケーションを志向するスタートアップたちのあいだでは、これらの技術がすでに常備品になっている。

またデベロッパやスタートアップだけでなく、企業も変わりつつある。Fortune 500社だけでなく、ITのイノベーションとは無縁と思われていた中規模の企業ですら、インターネットの時代に対応しようとすると変わらざるをえない。したがって彼らも、今ではデータセンターが提供するサービスに関心を持ち始めている。データセンターのアプリケーションスタック化は、企業の内部にも浸透していく。

“ビッグデータ”と“リアルタイム”と“物のインターネット(IoT)”は、今や単なるバズワードではなく、21世紀の経済において企業の成功を左右する必修科目だ。

そしてデータセンターアプリケーションのためのオペレーティングシステムが

しかしこれらはいずれも、実装が難しい。Hadoopをデプロイして管理してスケールする。Cassandraを〜〜〜〜。Kubernetesを〜〜〜〜。等々。使用するフレームワークやサービスごとに、あなたは手を洗って同じことを繰り返す。実装の困難さは、口にしてもしょうがないから、誰も口にしない。だから、世に氾濫する‘かっこいい話’には出てこない。

でもある時点で企業は、それまでのアプリケーションの書き方を反省し、データのパイプラインを築くことで、より強靭なアーキテクチャを確保したくなるだろう。

GoogleやMicrosoftのような、大きくてエンジニアをたくさん抱えている企業は、この問題をBorgAutopilotなどのシステムを自分で作って解決してきた。こういうシステムがあると、リソースの適正な割り当てを自動的にやってくれるから、何百万台ものサーバにまたがって動くサービスやアプリケーションの高い可用性が確保される。デベロッパやソフトウェアアーキテクトが頑張らなくても、アルゴリズムが、どこで、何を、どれだけのマシンの上で動かすかを決める。

しかし、BorgもAutopilotもすばらしいシステムだが、どちらもプロプライエタリだ。Googleが某論文の中で、Borgというものの存在を認めたのも、ごく最近のことだ。MicrosoftはAutopilotについて、ほとんど何も明らかにしていない。そしてBもAも、一般的なサービスとしては提供されていない。

そこで、Mesosphereだ、というお話になるのだが、それは次の機会のお楽しみに。

periodic-table-721x411-ea2b3e75968fbb5dd814f2a2cdc926ec

〔原文のコメントに、Microsoftの元社員からの反論があります。〕

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

Google Cloud SQLがMySQLのネイティブ接続をサポート…オンプレミスも連携へ

Google Cloud SQLが今度から、MySQLのネイティブ接続をサポートする。それは、サードパーティのアプリケーションとの統合を、より容易にするためだ。今回のサポートにより、ネイティブのMySQLアプリケーションをCloud SQLにはめ込めるので、DBに関するGoogleサイドのシステム管理が不要になる。

CloudSQLはMySQLデータベースの標準的接続プロトコルであるMySQL Wire Protocolを使ってネイティブMySQLにアクセスするので、Google Compute EngineGoogle App Engine上のアプリケーションからの接続が高速になる、とGoogleは主張している。顧客はCloudSQLのインスタンスを管理するために、従来からあるMySQL WorkbenchToad、それにMySQL用コマンドラインツールを使用できる。また、Connector/J、Connector/ODBC、Connector/NETといった標準ドライバがサポートされる。

ネイティブへの接続によって、クラウドデータベースの管理および展開というレベルでデータのレプリケーションをコントロールできる。Googleが挙げている例としては、Cloud SQLとオンプレミスのデータベース(Oracle、SQL Server、DB2など)とのあいだでのデータレプリケーションもできる。

今回のサポートは、MySQL Wire Protocolのようなコネクターがあれば、クラウドサービスとオンプレミスアプリケーションとの間に透明性が担保される、ということの好例だ。ユーザにとっては、Googleが自社のサービスで提供している高度な管理を通してオンプレミスを使えることも魅力だ。

Googleは今、Amazon Web Services(AWS)が何年も前から提供している機能を急いで揃え始めている。CloudSQLサービスのコア部分のローンチは今年の6月だったが、AWSがMySQLサービスをローンチしたのは2009年、そして2012年にはOracle Databaseのサポートも開始した。

問題は料金だ。InfoQのブログ記事によると、AWSのRDSは“時間料金ではGoogleのCloud SQLよりも安いが、データのストレージや転送の料金など、ほかの費用も検討する必要がある”、ということだ。

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