Googleが多様なツールを用意してクラウド上のデータ操作/データ処理を助ける

今日(米国時間3/9)のCloud NextカンファレンスのステージでGoogleは、データの準備や統合化を助ける一連のツールを発表した。いずれも、Google Cloudの企業利用をより強力かつ敏速にするためのアップデートだ。

まず紹介されたのがGoogle Cloud Dataprepの非公開ベータ。その名のとおり、データ(data)を視覚化のために準備(preparation)する。このツールには、異状検出機能があり、機械学習を利用して通常と異なる形のデータをユーザーに告げてデータのクォリティーを改善する。

誰にも使いやすいツールにするために、すっきりとしたインタフェイスに留意している。多くのコントロールが、ドラッグ&ドロップでできる。DataprepはGCP(Google Cloud Platform)への統合化に向けて最適化されており、Google Cloud Dataflow中のパイプラインを作ることによって、容易にBigQueryへデータをフィードできるようにしている。

今日は、BigQueryも強調された。新たにBigQuery Data Transfer Serviceというサービスを立ち上げて、複数のデータソースからのデータのマージを単純化する。既存の商用データセット、Xignite, HouseCanary, Remind, AccuWeather, Dow Jonesなどを最初からサポートしている。

ユーザーがTableauのような視覚化サービスを利用するときは、データをシームレスに準備して分析結果を表示できる。BigQueryは大規模プロジェクトのためにCloud Bigtableを今後サポートするから、データをいちいちコピーして移送する手間もなくなる。

Googleのクラウドプラットホーム担当VC Brian Stevensはこう語る: “マーケティングのチームがマーケティングに関するデータ分析をGCP上できわめて容易にできるようにした”。

Cloud Dataflowには、PythonによるSDKが広く提供される。これまでのJavaを超えて、コミュニティがさらに拡大するだろう。

ワークフローツールCloud Datalabも、今度から一般提供される。デベロッパーは、ノートブック環境Jupyterと標準のSQLを使って、データ分析ができる。TensorFlowとScikit-learnもサポートされる。バッチとストリーム処理はCloud DataflowやApache Spark + Cloud Dataprocでできる。またCloud DataflowのためのStackdriver Monitoringはベータへ移行し、GCPやAWSがホストするアプリケーションのモニタリングや診断を行う。

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

新しいGoogle App Engineは、お好みの言語で開発が可能

Googleは、完全にオーバーホールを施したApp Engineが本日(米国時間3月9日)から利用可能になったことを公表した。この発表は、サンフランシスコで今週開催されているGoogle Cloud Nextで行われた。

App Engineとは、複雑なインフラの保守の心配をすることなしに、アプリケーションのバックエンド構築を可能にする、GoogleのPaaS(platform-as-a-service)だ。

ビッグニュースは、App Engineが任意のプログラミング言語をサポートするようになったということだ。これにより開発者は、自身が快適に使いこなせる任意の言語を用いてアプリケーションを開発することができる。Googleはこれをゲームチェンジャー(流れを大幅に変えるもの)と見做している。企業ユーザーたちをGoogle Cloud Platformへと強く誘いたい同社にとって、プラットフォームをよりオープンなものにすることは重要なテーマだ。

Googleの製品管理担当副社長であるSam Ramjiは、当初のApp Engineが完全に閉じた環境であったことを指摘した。「私たちがこれからやろうとしているのは、オープン世代のApp Engineです」とRamjiは言う。

従来のバーションでは、ランタイムに使えるライブラリに制限があり、1度アプリケーションを構築してしまうと、Googleから取り出すことは極めて困難だった。今回同社は、そのオープンであることの哲学の一環として、移動することやロックインを避けることを容易にするという姿勢を示したということだ。たとえそれがGoogle Cloud Platformからの離脱を容易にするということを意味しているとしても。

新しいApp Engineを使えば、もしGoogle Cloud Platformを離れたくなった場合には、アプリケーションのDockerイメージを取得して、必要に応じてそれをどこにでも移動することができる、とRamjiは指摘した。

まず手始めに、Java 8、Ruby、Go、Python 2/3、C#、PHP 5/7、そしてNode.jsの7種の言語をサポートするが、それ以外にも、プログラマが独自のランタイム、フレームワーク、そしてサードパーティのライブラリを持ち込むことも可能にしている。そして開発者たちが使いたいと思うツールを、面倒な管理なしに使える柔軟性をApp Engineが与えてくれる。そもそもこれこそがクラウドサービスが提供できる最大の利点だ。

そして開発者はDockerイメージとして、(バイナリの)プログラミングパッケージをApp Engineに持ち込めるようにもなる。

App Engineは、クラウドツールとしては管理が簡単なことで知られているが、Googleは、それでも全ての制御をあきらめる必要はないと指摘している。開発者たちは、カスタムデバッギングやカスタムインテグレーションを行う必要がある際には、使い慣れたツールを用いて、必要なレベルまで内部に手を入れることができるのだ。

[ 原文へ ]
(翻訳:Sako)

GoogleのCompute Engineの最大仮想マシンが64コアRAM 417GBとなる…AWSの優位動かず

GoogleのCompute Engineが提供する仮想マシン‘一台’の最大コア数が32から64へ倍増した。このハイパワーマシンは今ベータだが、Googleの標準構成とユーザー指定のマシンタイプ(コア数とメモリ)で利用できる。

64コアを指定した場合は、最大メモリサイズがRAM 416GBになる。単一仮想マシンのメモリとしてはこちらも倍増になり、ハイエンドのインメモリデータベースのようなメモリ集約的なアプリケーションを十分に動かせるだろう。

料金は1時間3.7888ドルだが、長期ユーザーの値引きはもちろん適用される。

“ここが終点ではない”、とGoogleのUrs Hoelzleが今日のCloud Nextのキーノートで述べた。“今年後半にはコア数がさらに増え、メモリサイズはTB級になるだろう”、と彼は言った。

なお、AWSのEC2はすでに、コア数128、最大メモリ2095.944GB(2TB+)のマシンを提供している。これらの特注規格を選んだ場合は、料金は1時間13.388ドルになる。Microsoft Azureの仮想マシンは、現在の最大が32コアだ。

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

GoogleのCloud Platformが常時無料プランと無料トライアルの両方を拡大してクラウド新人たちがAWSへ傾くのを防ぐ

Googleが今日(米国時間3/9)ひそかに、常時無料プランと、同社のCloud Platformのトライアル(試用)プログラムの改良バージョンをローンチした。

常時無料プランは今や小さなアプリケーションをGoogleのクラウドで動かすに十分なパワーを持ち、拡張された無料トライアルプログラムとは別に提供される(このへんがちょっとややこしいが)。拡張された無料トライアルの方は、ユーザーに12か月300ドルのクレジットを与えるが、拡張される前は300ドルを60日以内に使うことになっていた。

一方無料プランの方は、Googleの広告の中にはなく、小さなインスタンス(f1-microインスタンス)をCompute Engine, Cloud Pub/Sub, Google Cloud Storage, およびCloud Functionsで使える。合計で常時無料プランに含まれるサービスは15となる。

中でもいちばん重要なアップデートは、Compute Engineのインスタンスと、無料のCloud Storage 5GBだろう。両者は、多くのクラウドアプリケーションの中核だから。この常時無料プランの詳細仕様はここにある

ただしこの無料プランが提供されるのは、us-east1, us-west1, us-central1の3リージョンのみだ。

これはもちろん、GoogleのAWS対抗策の強化だ。AWSの12か月トライアル以外の常時無料プランには仮想マシンが含まれない(仮想マシンは12か月のみ)。でもAWSも近いうちに、無料版に関してGoogleと横並びするだろう。

無料使用の拡大は、多くの人にGoogleのプラットホームに慣れ親しんでもらうためだが、とりわけデベロッパーは、自分のホビープロジェクトを動かしていたプラットホームを仕事用・会社用にも使いがち(あるいは推薦しがち)だ。また新人のデベロッパーは、クラウド初体験としてAWSを選びがちだ。Googleのこれまでの60日300ドルのクレジットは、彼らに十分な初体験期間を与えなかっただろう。

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

クラウドで出遅れたRackspaceがクラウドにやる気を見せてきたGoogleのCloud Platformに管理サービスを提供

AWSを筆頭とする三強に押されてこのところ管理サービスに転身しつつあるRackspaceが今日(米国時間3/8)、その管理サービスのポートフォリオにGoogle Cloud Platformを加える、と発表した。これまで同社がサービスを提供してきたのは、Amazon Web Services, Microsoft Azure, およびOpenStackのクラウドを使おうとするクライアントたちだ。これからはGoogleとRackspaceの協働により、管理を伴うクラウドサービスが提供される。その立ち上げは今年後半とされているが、具体的な日程は不明だ。

この二社共同提供物のクライアントには、クラウドの構成、実装、データのマイグレーション、その後のオペレーションのサポートなど、通常の管理サービスが提供される。こうやってパブリッククラウドの(その利用の)管理をRackSpaceのようなサービスに頼むと、ユーザー企業にとっては、自社でクラウド管理専任スタッフを雇うよりも、往々にして安上がりなのだ。

RackSpaceがこれまでGoogle Cloud Platform(GCP)をサポートしなかった理由は、それを求めるクライアントが少ないから、とされていた。しかし最近のGoogleはクラウドに本気で注力してきているから、状況は変わってきた。Rackspaceが挙げている 451 Researchの調査報告によると、最近の1年間でGCPのユーザーは倍増している。

RackSpaceでGCPサービスを担当するゼネラルマネージャーPatrick Leeが、今日の発表声明でこう述べている: “GCPはこのところ、日増しに勢いを増しており、ワークロードをこのプラットホームへ移行する企業も増えている。そして彼らは、その新しい旅路を支える専門的技術とサポートパートナーを求めている。そのGoogle Cloudに弊社のFanatical Supportを提供することにより、顧客企業のビジネスニーズの進化を支えることができる”。

たしかにGoogleのクラウド事業はこのところ、前向きの評価に変わりつつあるが、サポート、とくにエンタープライズ級のサポートに関してはまだ高評価とは言えない。これまでの煮え切らない数年間でAWSやAzureに許してしまったリードを挽回するためにGoogleは、これからは顧客にRackspaceの管理サービスを紹介することができる。

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

Google、データサイエンス、機械学習のKaggle買収を確認

今日(米国時間3/8)、Googleはデータサイエンスと機械学習をオンラインでホスティングするKaggleを買収したことを発表した。TechCrunchでは昨日、GoogleがKaggleを買収するという情報があることを伝えたが、これは事実であると確認された。

この発表は現在サンフランシスコで開催中のGoogle Cloud Nextカンファレンスで行われた。ただし買収金額などの詳細は明かされていない。そうではあってもGoogleがKaggleを傘下に収めたこと自体は驚きではない。Kaggleのプラットフォームを利用するデータサイエンティストが10万人単位で存在するため、同社の買収はGoogleのAIコミュティーでの地位を大きく高めるだろう。Googleはクラウド事業でAmazonと正面から競争を挑む展開になってきたため、可能な限り有利な条件を整備する必要があるはずだ。

Kaggleの買収によってデータサイエンティストの間でもGoogleブランドはいっそう権威を高めそうだ。もちろん同社はTensorFlowプロジェクトなどで機械学習のコミュティーの有力なメンバーだが、自動運転やディープ・ラーニングなどで人工知能が現実に応用される例が増えるにつれて競争は激化している。こうした新分野では大小を問わず多くの企業にチャンスがある。人間の最強棋士を破ったアルファ碁が劇的に示したような進歩が他社に起きれば、少なくとも可能性としては、AI分野におけるトップクラスの地位からGoogleが押しのけられることになる。

Kaggleの買収は、同社のAIコミュニティーにおける影響力を考えるなら、人材獲得の面でもGoogleにメリットをもたらすだろう。GoogleはPinterest(画像検索テクノロジーに力を入れている)などと競争していくために、今後ますますディープ・ラーニング分野でトップクラスの人材を必要とする。Kaggle買収は同社の高度なテクノロジーを取得できたことはもちろんだが、GoogleがAI分野全般での地位を高めるという目的もあったに違いない。

[原文へ]

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

Google、ビデオ中の対象を認識する機械学習API公開―Cloud Next 2017

SAPとの提携に引き続きGoogle Cloud Nextからのニュースだ。今日(米国時間3/8)、サンフランシスコでスタートしたカンファレンスでGoogleは新しい機械学習APIを発表した。このAPIはビデオ中の対象を自動的に認識し、検索可能にする。

新しいVideo Intelligence APIを利用するとデベロッパーは ビデオから対象物を自動的に抽出する能力を備えたアプリを開発できる。これまで画像認識APIはクラウド・サービスでのみ利用でき、しかも多くは静止画だけを対象にしていた。しかしGoogleのAPIを使えばデベロッパーはユーザーがビデオを検索して情報を引き出すようなアプリを開発できる。つまりflowerやdogなどのキーワードでビデオを検索できるようになる。

ビデオ中のエンティティの抽出に加えて、このAPIはシーンの転換を認識し自動的なタグづけを可能にする。

ただしビデオそのものはGoogleクラウドに保管されている必要がある。こちらでデモを見ることができる。

Google CloudのAIおよび機械学習担当チーフ・サイエンティストのFei-Fei Liのキーノート講演によれば、画像処理は静止画の先へ進みつつあるという。ビデオは機械学習の開発者にとって長らく困難なターゲットだった。新しいAPIは静止画の画像認識同様んび簡単にビデオから情報を引き出すことを可能にする。

さらにGoogleのクラウド機械学習エンジンはTensorFlowフレームワークを用いてデベロッパーが独自のカスタム機械学習モデルを構築できるようにする。Gogleによればこのエンジンは今日、一般に公開された。

キーノートでLiは、Googleは「社内で開発した機械学習テクノロジーの一般への普及を図っている。 今回もVision APIの公開もその例だ」と述べた。

〔日本版〕Googleが用意した説明ページのデモでは動物園、Google本社の自転車などを撮影したサンプルビデオにAPIを適用して処理した結果を見ることができる。APIの利用例のサンプルコードも掲載されている。

[原文へ]

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

GoogleクラウドにHANA DBがやってくる―Google、SAPとの提携を発表

今日(米国時間3/8)、GoogleはGoogle Cloud NextカンファレンスでSAPとの提携を発表した。これによりGoogle Cloud Platformに SAPのインメモリ・データベース、 HANAがやってくる。

いくつかの理由からこの提携には大きな意味がある。まず第一にGoogleはHANAが利用できることでクラウド・プラットフォームに有力エンタープライズを引き入れることができるだろう。また大企業で広く利用されているSAPとの提携はGoogleがクラウド事業を拡大する上でさまざなエンタープライズ・ビジネスの可能性を広げる。

SAPはERP〔Enterprise Resource Planning 統合基幹業務システム〕における世界的なリーダーの1社だ。SAPは各種の大企業においてテクノロジー、人事、財務などのシステムを運用するバックエンドを提供している。伝統的にこうしたシステムはオンプレミスで運用されてきたが、最近数年、クラウド上でサービスを提供する例が増えている。これはユーザー企業がこうした大規模システムのオンプレミス運用に伴うハード、ソフトのメンテナンスのわずらわしさを嫌うようになったためだ。

SAPは巨大企業なので独自のクラウド・サービスのためのデータセンターを持っているということは注意する必要がある。しかしGoogleとの提携はユーザーにメリットをもたらす新しいオプションを与える。またSAPがサードパーティーのクラウドとしてGoogle Cloud Platformを選んだことはGoogleにとって大きな成功だ。GoogleはIaaS( Infrastructure-as-a-Service)分野でAmazonのAWSはもちろん、Microsoft Azureからも大きく引き離されていた。

興味ある点は、この提携ではSAPが引き続きユーザーのクラウド・データの管理者の地位を保つということだ。つまり作動するのがGoogleのクラウド上であっても依然としてSAPがデータベースの運用に関して責任を持つ。このことは企業統治や法令遵守に関連する問題からクラウドに移行することをためらっていたユーザーにとってハードルを大きく引き下げる効果があるはずだ。いずれにせきわめて異例な取り決めだろう。

[原文へ]

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

MongoDBのクラウド上のデータベースサービスAtlasに無料プランが登場してフリーミアムに

MongoDBは今でも主力製品のNoSQLデータベースで有名だが、しかし昨年同社は、Atlasという、管理サービスつきのデータベースサービスを立ち上げた。そのクラウドサーバーは、AWS上で動いている。立ち上げ時点では有料サービスのみだったが…AWSの使用料も払わなければならないから当然か…、今日からはMongoDBを勉強したいデベロッパーや、これから新しいアプリケーションのプロトタイプを作る、といった人たちのために、無料サービスの提供を開始する。

無料プランには当然ながら制約もあり、たとえばストレージは512MBしか使えない。でも、可用性の高いAtlasのクラスターにアクセスできる点では有料プランと同じで、しかも、保存されている、あるいは転送時の、データは暗号化される。だからストレージが小さい点をのぞけば、サービスの内容は有料プランと変わらない。MongoDBをこれから勉強しよう、というユーザーにとっては、ストレージのサイズもこれぐらいで十分だろう。

無料プランがなぜこんなに遅れたのか、という問いに対してMongoDBのクラウドプロダクト担当VP Sahir Azamはこう答える: “無料プラン(Free Tier)のユーザー体験を、最初から本格的なものにしたかった。最初に立ち上げた有料プランも、販促のための無料利用の部分がかなりあり、デベロッパーはかなり気軽に完全なプロダクトを体験できた。そして彼らからのフィードバックが、無料プランでも高可用性とモニタリングと主要なセキュリティ機能をを提供すべき、という確信をわれわれに与えた。そのほかの機能やツールについても、それらをすべて提供すべき、という確信が得られた。つまりこれまでの有料ユーザーからのフィードバックを見るかぎり、ユーザー体験のクォリティーという点から、有料バージョンと完全に同じものを提供すべき、という結論にならざるを得なかった”。

また、今日同時にローンチしたデータマイグレーションツールmongomirrorにより、既存のMongoDBのデプロイメントをAtlasへ移せる。このツールは、将来的にはクラウド上のツールとしてAtlasから提供される予定だ。

Atlasの利用状況についてMongoDBは詳しい数字を明かさないが、“全世界の数千の企業で使われている”、とだけ言った。その中には、オンラインデートサービスeHarmonyや、バイオテックのThermo Fisherなどが含まれる。

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

AWS、S3の大惨事の原因を公開―ヒューマンエラーが発端だった

Mixed race person watching light column in cloud of blocks

AWSのS3クラウドストレージが4時間にわたってダウンした件は、当然ながら、強い批判を浴びた。AWSは検証レポートを発表し、この事件について原因と経過を詳しく説明した。技術的情報と将来に向けての防止策も含まれている。

直接の原因は、やや平凡な理由だが、ヒューマンエラーだった。あるエンジニア―ここではジョー(仮名)と呼んでおく―が間違ったコマンドを入力してしまったということだ。ジョーはあるサブシステムをシャットダウンするつもりだった。それ自体は日常行われるオペレーションだった。しかし月曜日、バージニア州北部データセンターではルーチンワークが大変な問題を引き起こした。

ジョーは正規の特権ユーザーであるため、システムをシャットダウンするコマンドを入力する資格があった。ただしこの作業はAmazonが「確立された手順書(established playbook)」に従ったもので、ここではS3サブシステムの少数のサーバーを停止することが意図されていた。ところがジョーは誤って多数のサーバーを停止するコマンドを入力してしまった。

素人の表現でいえば、地獄のような騒ぎが持ち上がった。

Amazonはもっと技術的な表現をしているが、問題のエラーはカスケードしてバージニア州北部データセンター全体に影響を与えることになった。ジョーのエラーは決定的に重要なサブシステムを停止してしまい、センターのデータ保存能力の大きな部分を失わせた。システムは再起動を余儀なくされたが、この間S3はリクエストを処理することができなくなった。AWS自身のダッシュボードも機能を失い(これはかなり恥ずかしい事態だ)、S3の稼働状態を確認できなくなった。

そして外部の世界も影響を感じ始めた。一般ユーザーはお気に入りのサイトが開かなかったり、アプリが異常な動作をしたりするのに気づいた。

昼頃、AWSはサービスの復旧に全力を上げていたが、なにぶんシステムの規模が大きすぎた。AWSは何年にもわたってダウンしたことがなく、従って全システムの再起動を行ったこともなかった。S3はいわば自分自身の成功の犠牲になった。再起動をかけるとシステムは安全性のチェックとメタデータの整合性の確認を始めた。ところがこれは予想外に時間を必要とした。

こうしたヒューマンエラーによる事故の再発を防ぐためにAWSでは運営手順に変更を加えるという。レポートによれば「この〔事故の原因となった〕ツールに修正を加え、作動速度を遅くし安全策を追加した。〔停止要求に対し〕配下の最小限のレベルにおけるサブシステムのみを停止させるようにした」という。これでジョーのような慌て者が同様のミスをするのは防げるだろう。

しかしAWSでは、もっと根本的にS3のサブシステムの構成の見直しも行っている。サブシステムをセル(cell)と呼ばれるさらに多数の区画に分割し、一挙に大量のサーバーが停止されないようにするという。これは過去にも試みられたことがあったはずだ。ともかくS3のサブシステムは許容可能な時間で再起動するには大きすぎた。

AWSのレポートは謝罪と改善の約束で締めくくられている。単純なヒューマンエラーで始まったものの、影響が連鎖反応で急速にデータセンター全体に拡大して大事故となった。AWSのシステムがこの種の深刻なエラーを想定せず、したがってそのカスケードを防ぐ機能が組み込まれていなかったのが惨事の根本的な原因だったようだ。

画像: Colin Anderson/Getty Images

[原文へ]

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

Amazon S3が停止した日―アナリストは冗長性の重要性を指摘

NEW YORK, NY - DECEMBER 14: Jeff Bezos, chief executive officer of Amazon, listens during a meeting of technology executives and President-elect Donald Trump at Trump Tower, December 14, 2016 in New York City. This is the first major meeting between President-elect Trump and technology industry leaders. (Photo by Drew Angerer/Getty Images)

昨日(米国時間2/28)、Amazonのバージニア州北部データセンターに障害が発生し、 AWS S3クラウド・ストレージ・サービスが4時間近くダウンしたというニュースはご存知のことと思う。その結果、有名なウェブサイトやサービスが停止し、大きな混乱が起きた。

念のため断っておけば、今朝、Amazonのダッシュボードはすべて正常に動作中であることを示している。

影響を被ったサイトやサービスにとっては大事件だったものの、Amazon S3は長年にわたって信頼性が高いサービスだったことは指摘しておくべきだろう。またバージニア州北部データセンターがダウンしても他の13のリージョンではS3は正常に作動した。

今回のS3のダウンのようなクラウド・サービスのダウンをモニターしているCloudHarmonyによれば、S3の動作記録はサービスレベル合意書((SLA)が保証する基準を上回っていたということだ。SLAによればS3は99.9%の稼働を約束しており、下回った場合については返金に応じるとしている。CloudHarmonyの調査では、同社が2014年にクラウド・サービスのモニターを開始して以來、AWS S3は年間でほぼ100%の稼働率を達成している。S3の目立った障害は2015年8月のダウンだった。

CloudHarmonyはMicrosoft Azureの仮想マシンとオブジェクト保管も2月19日に5時間にわたってダウンしたが昨日のS3の場合のような注目は集めていないと指摘する。

クラウド・コンピューティングの専門家、ジャーナリストのBen Kepesは「シアトルのAWS本社では夕べは誰も眠れなかっただろう。しかしこの種のダウンはときおりどうしても起きてしまう」と述べた。Kepesによれば、「AWSは他の同種のサービスと比較して隔絶して大きいパブリック・クラウド・サービスだ。そのためダウンすると各方面に非常に大きな影響を与える。昨日のダウンはいかに多くのサードパーティーがAWSのインフラに依存していたかを印象づけた。残念ながら、こうしたサービスはときおりダウンすることがある。ユーザーはこうした場合に対処する方法を準備しておく必要がある」という。

Kepesは「どんな場所であろうとダウンが起きることはITのプロなら誰でも知っている」 と付け加えた。しかしクラウドは通常地味なサービスでありダウンしても関係者以外には注目を引かない。「世間では大騒ぎしているが、事実はどんな公共サービスであろうと落ちるときは落ちる」という。

Forresterのアナリスト、Dave Bartolettiも同意見だ。彼は今回の事件はクラウド・サービスのユーザーに警鐘を鳴らすものだという。「ストレージに冗長性を持たせることが必要だ。ユーザーはクラウドにデータを保管してサイトやサービスを構築する場合、複数のレイヤーを利用する必要がある。ストレージはS3の特定のリージョンのみに依存してはならない」という。

ただしこれらのアナリストも今回のダウンで被害を受けたユーザーを非難しているわけではない。しかし冗長性というのはIT専門家がシステムに組み込むことを必須としてきた要素で、クラウドの場合でもなんら事情は変わらないという指摘だ。

しかしMoor Insight & Strategyのアナリスト、Patrick Moorheadは今回のダウンについてもっと厳しい意見を持っている。今回のダウンタイムはけっきょくのところ数百万ドルの損害をもたらしたはずで、Amazonは顧客の貴重なデータを保管するサービスを提供するからにはもっと高い冗長性をシステムに組み込んでいる必要があったという。

「パブリック・クラウドだからといってこうしたダウンが起きていい理由にはならない。銀行オンラインでダウンがほとんど起きないのは障害耐性が高いアーキテクチャを組み込んだシステムが構築されているからだ」という。

こうした批判の当否はともあれ、インハウスであろうとAWSのようなクラウドであろうとデータセンターの事故はサイトやサービスにとって死活問題だということは明らかになった。どんなアプローチであれ「これで絶対安全」とはならない。だからといってAWSの責任が否定されるわけではないが、少なくとも過去の運用記録からみればS3はきわめて信頼性の高いサービスの一つであったことは間違いない。

t画像: Drew Angerer/Getty Images

[原文へ]

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

OpenStackの第15リリースOcataはコンテナのサポートをさらに充実、プライベートクラウドの第二の夜明けを目指す

Fibre-optic cables feed into a server inside a comms room at an office in London, U.K., on Friday, Oct. 16, 2015. A group of Russian hackers infiltrated the servers of Dow Jones & Co., owner of the Wall Street Journal and several other news publications, and stole information to trade on before it became public, according to four people familiar with the matter. Photographer: Chris Ratcliffe/Bloomberg via Getty Images

今日(米国時間2/22)OpenStack Foundationが、同プラットホームの最新バージョンをローンチする。企業はOpenStackを使って、AWSのようなクラウドコンピューティングプラットホームを自己のデータセンターでプライベートに運用できる。Ocataと呼ばれる今日の15回目のリリースは、前回のリリースからわずか4か月後と早いが、今後は通常の6か月サイクルに戻る。今回とくに早かったのは、Foundationが近くデベロッパーのためのイベントを開催するからだ。短いサイクルなので新しい機能よりも安定性が重視されているが、しかしそれでも、いくつかの新機能を見ることができる。

今やOpenStackは巨大なプロジェクトで、20近いサブプロジェクトで構成されている。もちろんどれもコンスタントにアップデートされているが、今回の新機能で目立つのは、OpenStackにおけるソフトウェアコンテナのサポートがさらに充実したことだ。OpenStackのCOO Mark Collierによると、コンテナプロジェクトは他のプロジェクトよりも進捗が早い。彼によるとOpenStackとGoogle生まれのコンテナオーケストレーションシステムKubernetesの組み合わせは“クラウドのLAMP”みたいなものであり、Kubernetesの人気が高いのはGoogleや特定一社がそれをコントロールしようとせずに、オープンソースのコミュニティにその成長を委ねたからだ、とCollierは語る。

今回のOctaリリースにおけるコンテナサポートの改良は、OpenStackのコンテナによるデプロイをサポートするプロジェクトKollaにKubernetesをより完璧に統合したことだ。それによってOpenStackのデプロイの管理が容易になるだけでなく、アップグレードもよりシンプルな工程になる。そのほかのアップデートとしては、コンテナのオーケストレーションサービスを支えるOpenStackのメインプロジェクトMagnumがMesosphereをより本格的にサポートするようになったことが挙げられる。またOpenStackのコンテナネットワーキングサービスKuryrが、Docker Swarmをサポートする。

OpenStackは明らかに、コンテナエンジンに関してえこひいきはしていない。わずか1年前ですら、コンテナがOpenStackの死を招くか云々という議論がまだあった。しかしそんな不安はいかにも大げさであり、今やコンテナはこのプロジェクトの中核的部分のひとつだ。

2017-02-21_1746

OpenStackの今後に関連してCollierの説では、このところ、企業のプライベートクラウドの見方が変わってきている。OpenStackにかぎらず、最初の世代のプライベートクラウドサービスは、あまり使いやすくはなかった。“今よりもずっと大きなチームを必要としたし、採用もPayPalやWalmartなど超大企業に限られていた。つまりクラウドをプライベートで立ち上げるのは、ふつうの企業には無理だった”。でもCollier説によると、今はプライベートクラウドの第二世代だ。プライベートクラウドを立ち上げるのに、もはや巨大なチームは要らない。それに今では、セットアップを手伝ってくれる企業のしっかりとしたエコシステムがある。

初期には、OpenStackのクラウドをセットアップするために必要なマンパワーの量が大きすぎて、小さなチームでは難しかった。しかしCollierによると、今では費用の面でもプライベートクラウドがAWSなどのパブリッククラウドサービスと十分に競合できる。パブリッククラウドサービスはいろんなオプションなどで費用がかさむことが多いが、OpenStackなどを自前で使えば、持続可能なワークロードを低費用で維持できる。つまり彼の主張では、これからはプライベートクラウドの方がAWSなどを使うより費用効率が良い、というのだ。

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

GoogleのCloud PlatformがGPUをサポート

tesla-m40-header

3か月前にGoogleは、2017年の早い時期に、機械学習などの特殊なワークロードためにハイエンドのグラフィクスプロセシングユニット(graphics processing unit, GPU)のサポートを開始する、と発表した。2017年の早い時期とは今のことだから、Googleは言葉に違(たが)わず今日から、Google Cloud Platform上でGPUを使えるようにした。予想通りそれはNvidiaのTesla K80で、ユーザー(デベロッパー)はひとつのCompute Engineマシンで最大8つを動かすことができる。

GPUベースの仮想マシンを使えるのは当面、三つのデータセンター、us-east1, asia-east1, そしてeurope-west1だけだ。ひとつのK80コアに2496のストリームプロセッサーと12GBのGDDR5メモリがある(K80ボードには2つのコアと24GBのRAMがある)。

image02

複雑なシミュレーションを動かしたり、TensorFlow, Torch, MXNet, Caffeeなどのディープラーニングフレームワークを使っているときには、計算力はどれだけあっても過剰ではない。GoogleがこれらのGPUインスタンスでねらっているのも、ハイエンドマシンのクラスタを常時動かして機械学習のフレームワークを駆動しているようなデベロッパーだ。このGoogle Cloud GPUは、GoogleのCloud Machine Learningサービスおよび同社のさまざまなデータベースとストレージのプラットホームに統合される。

GPUの利用料金単価はアメリカでは1時間70セント、ヨーロッパとアジアのデータセンターでは77セントだ。時間単価としてはお安くないが、Tesla K80の2コア/24GB RAMのアクセラレータは、たちまち数千ドルの節約を稼ぎだしてくれるだろう。

この発表から数週間後にGoogleはサンフランシスコで、Cloud NEXTカンファレンスを開催する。そこではおそらく、同社の機械学習をもっと多くのデベロッパーに使ってもらうための企画が、発表されるだろう。

image00-1

〔参考記事: AWSのGPUインスタンス

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

企業のクラウド環境をモニタしてリソース等の最適化を行うYotaScaleが$3.6Mを調達

Vector high tech internet data center. Network equipment that is used to organize the server room

エンタープライズ指向のアクセラレータAlchemistを卒業したYotaScaleが、360万ドルのベンチャー資金の調達を発表した。そのラウンドに参加した投資家は、Engineering Capital, Pelion Ventures, およびエンジェルのJocelyn Goldfein, Timothy Chou, そしてRobert Dykesだ。同社は機械学習を利用して、企業のクラウドコンピューティングの実行性能(パフォーマンス)や可用性、費用などの最適化を図る。同社と競合するCloudHealth TechnologiesCloudabilityも、この今や熱い市場で、合わせて8000万ドルの資金を獲得している。

クラウドコンピューティングは、今やどの産業でも事業の不可欠な要素になりつつあるが、しかしイノベーションが急速なので、インフラの進化に適切に付き合っていくのが難しい。その責任を人間に丸投げするのではなく、YotaScaleはクラウドインフラの実行性能管理そのものを自動化する。

同社は、きわめて多面的で複雑なクラウドデータを絶えず精査して、顧客企業のインフラストラクチャがその重要な事業的プライオリティに向けて確実に最適化されている状態を保つ。プライオリティは、費用の最小化などシンプルなものもあれば、目標の異なる複数のプロジェクトが関与する複雑な動的構造のこともある。

“機械の稼働率が低い、などの単純なことなら人間にも分かるし、一部の機械を止めればすむことだ”、とYotaScaleのCEO Asim Razzaqは語る。

Razzaqのシステムは、クラウドの利用データに課金とログのデータを結びつける。その複合データが、ベースラインと対照して異状を検出するための基盤になる。大量のデータではない、と思われるかもしれないが、リソースの消費やCPUの利用状態などの稼働状況を外挿するには十分なのだ。

むしろ、異状検出で難しいのは‘正常’の定義だ。何が正常かは、状況によって千差万別だからだ。分かりやすい例としては、CPUの利用がスパイクしても、それがブラックフライデーのeコマースなら全然異常ではない。そこでYotaScaleは履歴データにだけこだわるのではなく、今後の見通しも重視する。それによって、状況によるデータの浮動も理解できるようになる。変化が見られたら、それらにいちいちフラグをつけるのではなく、パフォーマンスの見通しと実態を突き合わせる。

クラウドインフラストラクチャのデータは、さまざまなタイプのデータがさまざまな時間間隔で生成される。毎時というものもあれば、毎日、というものもある。それらの違いを正確に見極めながら最適化を図る作業が、非常に難しい。アンサンブル学習という機械学習のテクニックを利用して分析の精度を上げ、捕捉したデータの多面的な特徴を管理している。基本は回帰分析だが、用途によってはそのほかの半教師ありモデルも使っている。

YotaScaleのユーザーであるApigeeやZenefitsなどは、機械学習に頼ってクラウドコンピューティングのニーズの理想的な管理ができている。その負担が、クラウドからもDevOpsからも消えている。また言うまでもなく、機械学習はリアルタイムの分析がとても得意だ。

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

Linodeが新たに月額5ドルのインスタンスでDigitalOceanに挑戦

shutterstock_141093727

2003年に生まれたLinodeは仮想プライベートサーバー(virtual private server, VPS)のホストプロバイダとして古顔だが、最近ではDigitalOceanやVultrなどの新顔たちにマインドシェアを食われている。しかし、盛り返す意欲は十分にあるようだ。

同社は今日(米国時間2/14)、新たに月額5ドルのプランを発表したが、それはDigitalOceanAWS Lightsailの5ドルプランに比べるとメモリが倍の1GBある。しかしまた同時にLinodeは、高性能化のためにはストレージやCPUパワーよりもメモリが重要、というアプリケーションのためにハイメモリインスタンスをいくつか発表した。

今日の発表はバレンタインデーのお祝いでもあるが、同じ日の朝DigitalOceanはロードバランサーをローンチしたから、対抗の意味もあろう。ロードバランサー機能はLinodeにすでにあるが、何もしないバレンタインデーであることは許されない。

pricing-1g-2

通常のインスタンスでもLinodeは、DigitalOceanの倍のメモリを提供している。そのほかの機能は似たりよったりだ。今日発表したハイメモリプランでは、RAMの料金がDigitalOceanの半額になる。ただしCPUのコア数は少ない。

Linodeでは、インスタンスのサイズのアップ/ダウンが容易にできるから、メモリ1GBと単一CPUで十分なアプリケーションにハイエンドなインスタンスを使っているなら、これを機に節約ができるだろう。その新しいローエンドのインスタンスは、いくつかのホビー・プロジェクトや、大きなアプリケーションの小さい特殊な機能部品を動かすには、十分なパワーがあるはずだ。

Linodeはまだ専用のストレージサービスを提供していないが、DigitalOceanは昨年から提供している。Linodeは、ロードマップには載っている、と言っているから、来月あたりベータでローンチするかもしれない。RESTful APIのサポートやダッシュボードに関しても、同じことが言える。

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

DigitalOceanがロードバランサーを現料金内で提供開始、徐々に本格的なクラウドコンピューティングサービスへ成長中

hero-6c0992e2

DigitalOceanが今日から、このプラットホーム上でアプリケーションを運用しているデベロッパーのために、ロードバランスサービスの提供を開始する。ロードバランサーは比較的単純明快なプロダクトで、DigitalOceanの場合も、サイトへの接続を複数のサーバーに分散することによって、アプリケーションの良好なアップタイムを保証する。言い換えると、トラフィックにスパイクがあっても、ロードバランサーがあれば一箇所のエラーですべてがだめになることはないから、顧客へのサービス性が向上する。ただし、一つしかない(バックアップのない)データベースがダウンしたら、上記の‘一箇所のエラーで云々’という説は通用しなくなる。

これまでDigitalOceanのユーザーは、ロードバランサーを自前でセットアップしていた。しかしこれからは各月20ドルの料金にロードバランサーの利用も含まれ、同社のダッシュボードやAPIからアクセスできる、プロトコルはHTTP, HTTPS, およびTCPをサポートしている。またロードバランサーのアルゴリズムをラウンドロビン最小接続の二つから選べる。

2017-02-13_1612

ロードバランサーのセットアップは、数クリックで終わる。時間にして1分足らずだ。利用できる圏域は、DigitalOceanの全世界の全リージョンだ。

DigitalOceanによると、同社の登録ユーザー数は100万に近く、現在のアクティブユーザーはデベロッパーのチーム数で言って4万あまりだ。同社は今日までずっと基本サービスの規模拡大で忙しくて、関連サービスの提供が遅かったが、そろそろその悪癖も、改まりつつある。これまでは単純に安く使える仮想プライベートサーバーが売りだった同社も、今では本格的なクラウドコンピューティングプラットホームを目指している。たとえば昨年はストレージサービスを開始したし、また複雑なアプリケーションを高い可利用性で提供できるフローティングIPを導入した。そしてさらに最近は、改良されたモニタリングサービスの提供も開始した。

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

Googleがグローバルな分散データベースCloud Spannerをローンチ、SQLとNoSQLの‘良いとこ取り’を実装

google-cloud-spanner

Googleが今日、Cloud Spannerのベータローンチを発表した。それは、ミッションクリティカルなアプリケーションのための、グローバルな分散データベースだ。Cloud SpannerはGoogleの一連の、クラウドベースのデータベースサービスの仲間に加わる…それらは、Bigtable, Cloud SQL, そしてCloud Datastoreなどだが、しかしその重要な特徴は、従来的な関係データベースとNoSQLデータベースの両方の長所を取り入れて、トランザクションの一貫性(整合性)とスケーラビリティの容易さの両方を実現していることだ。現実的に分かりやすい言い方をすると、MySQLやPostgreSQLなどのデータベースでスケールの限界にぶつかっているデベロッパーが、クェリなどの現状を維持しつつ、その限界を乗り越えるために採用する代替的データベースだ。

Cloud Spannerという名前に見覚えのある方は、それはたぶんGoogleがこのデータベースの過去のバージョンを社内的に使っていて、2012年にはそれに関するペーパーを公開しているからだ。GoogleのDeepti Srivastavaによると、Googleは2007年に、MySQLに代わるデータベースとしてSpannerの開発に着手した。それまでは同社のさまざまなプロダクトで、MySQLが使われていた。しかし今日では、Google Photosや、Googleのそのほかの多くのミッションクリティカルなアプリケーションがSpannerを使っている。その同じデータベースを今回、外部デベロッパーにも公開したものが、Cloud Spannerなのだ。

デベロッパーは、SQLベースのアプリケーションを書くときに集積した知識をそのまま新しいデータベースに持ち込んで、SQLのシンタックスを用い、顧客にはACIDなトランザクションを提供できる(しかもそれを自分たちのセールスポイントにもできる)が、しかしそれと同時に、Google自身がそのプロダクトの運用のために必要としている、スケーラビリティとグローバルなネットワークの組み合わせなど、今日的なNoSQLデータベースの利点も提供できる。

2017-02-14_0903

“データ保存データベースではなく、日々のトランザクションのためのデータベースでスケールの限界にぶつかっていたら、共有データベースやNoSQLが次の選択肢だ”、とSrivastavaは語る。“しかし、それでもなおSQLは使い続けたい、という二股的トレードオフを抱えているなら、Spannerを選ぶべきだ。デベロッパーは、今使っているシステムを捨てたくない。だったら私たちが、そのトレードオフをできるかぎりシンプルにして差し上げたい”。

彼女によると、Cloud Spannerのデータベースには理論的には大きさの制約はないし、もちろん小さなプロジェクトでも十分に利用できるが、メインのアドバンテージは必ずしもスケーラビリティではなくて、グローバルなトランザクションの能力にある。そういう意味でCloud Spannerは、Cloud Datastoreの拡張と考えた方がよい。Cloud DatastoreはGoogleの、スケーラビリティの高いNoSQLデータベースだが、ACIDトランザクションやSQLふうのクェリもサポートしている。

cloud-spanner-4

パフォーマンスについては、まだ体験的に語れる段階ではないが、Googleの約束ではCloud Spannerの性能はそのほかのクラウドデータベースとほぼ互角である。

GoogleはCloud Spannerに関して99.9999%のアップタイムを約束しており、また提供するクライアントライブラリはJava, Go, Python, Node.jsなど複数の言語に対応している。ベータテストの間に複数の企業が、そのほかの言語のためのドライバーを作ったから、それらの言語のサポートも遠くないだろう。

料金は1ノード1時間あたり90セント(レプリケーションを含む)から始まり、ストレージは1GB1か月30セントだ。ネットワークのingressは無料、egressはGoogleの通常のクロスリージョン(複数リージョン間)とインターネットegressの料金に従う。

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

AWSがひとり勝ちである理由

クラウド市場を眺めてみると、AWSが異論のないリーダーであり、近い将来もその地位に揺るぎがないであろうことに驚く。しかもGoogle、Microsoft、IBM、そしてOracleといった強豪が競争相手であることを考えると、AWSの大きなリードは更に驚異的だ。ここで疑問なのは、AWSはどのようにそうした優位性を手に入れたのか?ということだ。

先行者だったからというのが簡単な答だが、AWSのCEOであるAndy Jassyは、それは幾つかの点で市場転換力学の古典的なケースだったと、先週ワシントン大学で行われたインタビューで語った。競争相手たちは単純に、心配する必要が生じるほどの十分な市場が生まれるとは思っていなかったのだ。

手遅れになるまで、ちょっとした不快感を無視し続けることは簡単だ。実際、ハーバード大学教授の、クレイトン・クリステンセンは、彼の先駆的な著書「イノベーションのジレンマ」でこの問題を概説している。市場の支配的なプレイヤーたちは、市場の最下層への攻撃を心配する理由がない。そしてそれこそがAWSが初期の頃にやっていたことだ。

ライバルたちについてJassyは、彼らは長く激しくクラウドと戦って来たために、戦いに敗れ去る会社を見ることで、彼らの市場の優位性を脅かすものは存在しないと思いこむ傾向が強まったと語った。

「彼らがクラウドに対して言ったことは、まず、誰もそれを使わない、次に、おそらく使うのはスタートアップだけだ、その場合でも本番には使わないだろう、ということでした。その次には、企業は使わない、そしてその次に言ったのは企業はミッションクリティカルな用途には使わない、というものでした。企業や開発者たちはその労力を注ぐ場所で意見を表明していました。そしていまや(競争相手たちは)この領域で何かを始めようとしています。おわかりでしょうけれど、それは6、7年遅れた動きなのです」とJassyは語った。

screenshot-2017-02-13-14-44-34

AWSのCEOであるAndy Jassy

OracleやIBM、そしてMicrosoftのような企業さえもが、こんなにも力を注いでこなかった理由の1つは、クラウドが彼らのコアバリューを損なうものだったからだ。

「私は、そこに到達するために、ただとても長い時間のかかる企業のカテゴリーがあると思っています。それはOracleやIBMのような企業で、彼らの立場からすれば、私たちが推し進めていたビジネスモデルは、彼らのビジネスに対してとても破壊的なものだったのでしょう」。彼は、根本的に異なるマージンや、価格体系、展開モデルについて発言を続け、そしてそうした企業たちに対して根本的な疑問を提起した。

「多くの大企業が抱えるジレンマだと思います。既存のビジネスを食い潰す動きを本当に加速したいのかどうか。だからこそ彼らは可能な限り長く激しく戦って来たのだと思います」。

Jassyは、他のプレイヤーたち、特にMicrosoftが、参入のためにこれほど長い時間がかかったことに驚いたと告白した。もっとも彼は実社名は挙げずに「湖の向こう岸の会社」と呼んだだけだったが。「私たちが立てた、もっとも甘い予想の中でも、私たちに6、7年の先行が可能になるとは考えていませんでした。特に私たちは、あの大企業とは湖を挟んで向かい側ですし、お互いに相手の会社の沢山の人を知ってたのですから」。

しかし、ライバルたちはいまや方向を定めた。そしてJassyもAWSの1人勝ちの幻想に浸ってはいない。彼は数兆ドルの価値がある市場に向けての厳しい競争があることを認識している。「1人勝ちのプレイヤーが現れることにはならないでしょう。かといって30にもならないと思います。コスト構造を考えると規模が本当に大切なのです。しかし複数の成功したプレイヤーが現れることでしょう、まだ登場していない企業かも知れません。しかし従来の手堅いプレイヤーたちも無視できません。既に膨大な企業顧客基盤を持っていますし、強力な販売チームやその手の何かを有しているからです」と彼は語った。

JassyはAWSが提供している機能の量を考えると、ライバルたちが追いつくためには相当量の仕事をこなさなければならないと述べた。もちろんAWSも定期的に機能を追加している。

こうした全てが市場におけるAWSの優位性につながってきた、そして現時点では追いかけるプレイヤーたちにとっては、本当に困難が予想される。市場は成長を続け、主要クラウドプレイヤーたちは派手な成長を見せ続けるだろうが、先行したAWSは大きなリードを確保し、その地位を近い将来譲り渡す気配はない。

[ 原文へ ]
(翻訳:Sako)

DropboxやG Suiteなど複数のクラウドサービスを一括サーチ ― Swiftypeが新プロダクトを発表

swiftype-mobile-client-1

今日紹介するSwiftypeは元々、TechCrunchなどのニュースサイトで利用するサーチシステムを開発していたスタートアップだ。しかしその後、同社はカスタマーサポートやEコマースの分野の企業にもシステムを提供するようになった。そして今日、Swiftypeはこれまで以上に大きな飛躍をすることとなった。同社が新しいエンタープライズ向けのサーチプロダクトを発表したのだ。

中小規模向けに開発されたSwiftypeの新プロダクトを利用すれば、さまざまなクラウドサービスからお目当てのファイルを見つけ出すことが可能だ(先日にはGoogleもCloud Searchの提供を開始しているが、その検索対象となるのはGoogle製のサービスに限られる)。

「ソースがバラバラに存在しているせいで、企業の中に存在するナレッジもバラバラに保管されてしまっています」と共同創業者のMatt Riley氏は語る。

Swiftypeの検索対象は、Dropbox、Office 365、GoogleのG Suite、Zendeskなどのサービスだ(同社はAPIも提供していて、それを利用すればカスタマイズされたデータソースにも対応することができる)。またRiley氏は、単一のインターフェイスで様々なサービスに保管されたファイルを検索できるようにすることは、ビジネスの現場には欠かせない機能だという。

面白いのは、このサービスには人工知能も搭載されている点だ。その人工知能がクラウドサービスに保管されたデータを解析して、共同創業者兼CTOのQuin Hoxie氏が呼ぶところの「エンタープライズ・ナレッジグラフ」を作成する。そして、そのグラフがSwiftypeのサーチ体験を向上させている。

その1つとして、Swiftypeは単なるキーワード型のサーチシステムではなく、ユーザーから与えられた複雑なクエリを理解することもできる点が挙げられる ― 例えば、ユーザーが「連絡先ファイル」や「最近のドキュメント」を探している場合、探しているドキュメントにその言葉が含まれていなくても目当てのものを見つけ出すことが可能なのだ。

また、Swifttypeはデータを利用しやすいかたちに構造化することもできる ― ユーザーがある企業について検索すると、その企業についてのあらゆる情報をまとめた要約カードを見ることができる。加えて、あるドキュメントを検索すると、それぞれのドキュメントに関連する情報も一緒に確認することができるので、複数のドキュメントを1つ1つ開いて確認する必要がなくなる。

これは特に重要な機能の1つである。なぜなら、Swiftypeが提供しているのはデスクトップPCで利用できるサーチシステムだけではないからだ。同社はSlackと統合して利用できるモバイルアプリも開発している。私たちは、たくさんのフィルターを設定したり、複数のページをブラウズする時間がないこともある。そういう状況下では、サーチシステムは複雑なクエリを理解し、ドキュメントから最も重要な情報を抽出する必要がある。

また、Swiftypeはブラウザ用のプラグインも提供している。先ほど紹介した関連情報を一覧表示する機能は、ここで生きてくる ― 例えば、営業やカスタマーサービス部門に所属する社員のプロフィールを開くと、それと同時に、その社員に関連するさまざまなドキュメントがポップアップ表示されるのだ。Swiftypeを一度も開かずに情報を取得できるのが理想的だ、とRiley氏は語る。

swiftype-sources-management

加えて彼は、Swiftypeを導入するまでにかかる時間は従来のエンタープライズ向けサーチシステムに比べて大幅に少ないと語る。Swiftypeを導入するためには、まずはアドミニストレーターが企業で利用中のクラウドサービスとSwiftypeを連携し、あとは個々の従業員が自分のアカウントを登録するだけだ。

もちろん、企業内に存在するあらゆるドキュメントを1つの場所から検索できるようにするとセキュリティに関する懸念が生まれる。Hoxie氏によれば、Swifttypeでは社員ごとのアクセス権限を細かく設定することが可能だという ― オフィスネットワーク内からのアクセスに限定することも、社員の個人デバイスからアクセスできるようにすることも可能だ。

ここで明確にしておくべきなのは、SwiftypeはWebサイトで利用するサーチシステムの提供を停止したわけではないということだ。Hoxie氏によれば、開発チームはすべてのSwiftypeプロダクトで「同じコアテクノロジー」を利用するという目標を達成するために大変な苦労をしたという。しかし、そうすることで、あらゆるユーザーがすべてのSwiftypeプロダクトの恩恵を受けることができるという考えだ。

同社は、エンタープライズ向けサーチシステムによって、これまでのSwiftypeプロダクトよりも大きな市場を狙うことができると考えている。Hoxie氏は、「(エンタープライズ向けサーチシステム市場は)これまでよりも大きな市場です。ただ、どの点を考えてもこのプロダクトがもつ市場の方が大きいというわけではありません。マーケットにはサイトサーチの方が適している企業がたくさんあり、だからこそ、これまで私たちは成長してきました。しかし、エンゲージメントという面を考えると世界はがらりと変わります。TechCrunchで利用されているようなサイトサーチでは、検索するときにSwiftypeと向き合っているユーザーはおそらく1人でしょう。しかし、このプロダクトでは、すべてのユーザーが私たちのプロダクトと交流することになるのです」。

[原文]

(翻訳: 木村  拓哉 /Website /Facebook /Twitter

DreamHostの新しい簡易WebサイトビルダーRemixerはOpenStackとKubernetesの上で 動くコンテナアプリケーションだ

remixer-customize-content

Webサイト作りとWordPressホスティングの老舗DreamHostが今日、新しい、より簡略なWebサイトビルダーRemixerを立ち上げた。ユーザーは、単純でメンテナンスの楽なWebサイトを、HTMLのコードすら1行も書かずに作れる。この新しいプラットホームは、DreamHostの従来のホスティングプランのどれにも含まれることになる。

こういうGUI方式のWebサイトビルダーを使ったことのある人は、Remixerに親しみをおぼえるだろう。まず、提供されているテーマの中からどれかを選ぶ(現在は13、今後はもっと増える)。画像をアップロードしたり、あるいはInstagramやFacebookなどなどからインポートできる。オーディオやビデオをSoundCloud, YouTube, Vimeoなどからインポートすることもできる。そのほか、類似のサービスと同様に、地図、コメント欄、フォームなどを数クリックで加えられる。こういったいろんな部品は、70種用意されている。

remixer_customize_text

また、60万種類の自由に利用できる画像やグラフィクスを提供しているから、そこから選んでもよい。

DreamHostは長年、ホスティングサービスとして知られているが、近年ではOpenStackのエコシステムにおける重要なプレーヤーだ。OpenStackは、大企業や通信企業、ホスティング企業などがAWSのようなクラウドコンピューティングサービスを自前で(自分とこのデータセンターで)運用できる、オープンソースのプロジェクトだ。実はRemixerは、OpenStack + コンテナ管理サービスKubernetesの上で動いている。つまりこのアプリケーション、というかサービスは、マイクロサービスの集合としてKubernetesが管理するクラスターの上で動いている。そしてそれらがさらに、OpenStackが動かすDreamComputeクラウドプラットホームの上で動くのだ。

remixer-themes

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