Cloud | SEO-LPO.net

Digital OceanがオブジェクトストレージサービスSpacesを立ち上げ、スケールアップ無制限

人気のクラウドホスティングサービスDigital Oceanが今日、オブジェクトストレージサービスSpacesを発表した。同社の既存のブロックストレージサービスを補完するサービスだが、16TBという上限のあるブロックストレージサービスと違ってSpacesにはスケールアップの制限がなく、その物理的な量やストレージの仮想マシンへの接続は問題にされない。

Digital Oceanにとってこれは、同社の核となるクラウドコンピューティングサービスを拡張する試みのひとつであり、AmazonやGoogle、Microsoftなどの大手と同格に戦おうとする意欲の表れでもある。もちろん大手はすでに、Digital Oceanの現状よりもずっと幅広いサービスを提供している。

同社のクラウドストレージのプロダクトマネージャーJohn Gannonが、発表声明でこう述べている: “オブジェクトストレージはもっとも要望の多いプロダクトだった。コンピューターのリソースを抽象化したスケーラブルなストレージプロダクトの開発に着手したとき、ここには今日（こんにち）のデベロッパーが行っている問題解決のやり方をリファクターし改良する機会があることに気づいた”。

同社によるとこのサービスはAWS S3の既存のツールの多くと互換性があり、またすべてのデータは256ビットAES-XTSで暗号化されてディスクに書き込まれる。デベロッパーが独自の暗号化方式で暗号化することも、もちろん可能だ。

料金体系は単純明快だ。250GBのストレージが月額5ドル、アウトバウンドの帯域1TBが含まれる。それを超えると、1GBあたり0.02ドル、転送量1GBあたり0.01ドルとなる。試用希望者のための2か月の無料プランもある。

Spacesは現在、同社のNYC3リージョンで可利用であり、年内にAMS3リージョンでも提供される。そのほかのリージョンは2018年以降だ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

デベロッパーでなくても誰でも通信機能のあるアプリケーションを容易に作れるTwilio Studio

Twilioはデベロッパーが自分のアプリケーションに通信機能（オーディオ、ビデオ、テキストなど）を容易に組み込めるためのAPIサービスとして長年有名だが、しかし今日（米国時間9/19）同社が非公開プレビューで立ち上げたTwilio Studioは、デベロッパーでない人びとを対象にしている。

あくまでも通信APIのプロバイダーという同社の本来の土俵にしっかりと立ってはいるのだが、しかし今回のプロダクトは、デベロッパーではなく“だれもが”、音声応答システムやメッセージングボット、通知ワークショップなど顧客のエンゲージメントのあるアプリケーションを、Web上のドラッグ＆ドロップ方式で作れる。今のところ、ビデオはまだ使えない。なお、Twilioのマーケティング戦略としては、通信〜コミュニケーションを中心とするユースケースにフォーカスしているけれども、作れるアプリケーションの種類はそれだけではない（もっといろんなアプリケーションを作れる）。

Twilio Studioは特定の種類のアプリケーションを作るための、コーディング不要のサービスだが、実はプロのデベロッパーも対象にしている。Twilioのプロダクト担当VP Pat Malatackはこう語る: “これによって、こういうユーザー体験〔==アプリケーション〕を作れる人の数が大幅に増えるけれども、しかしこんなワークフローを今実際に作っている多くの企業の既存の技術者にとっても、すごく便利なんだ”。

というかTwilio Studioには、同社のサーバーレスプラットホームTwilio Functionsが組み込まれている。StudioでTwilioの既存のAPIのほとんどにGUIでアクセスできるけれども、ドラッグ＆ドロップのインタフェイスでは、コードを直接書くことに比べると柔軟性が失われがちだ。しかし機能の呼び出し形式が単純なサーバーレス方式のおかげで、デベロッパーが仕事をした後でも、誰もが容易にアプリケーションに変更を加えることができる*。〔*: サーバーレスでは、アプリケーション側が‘呼び出す’というより、むしろアプリケーションはAPI側がイベント（ここでは主に通信イベント）発生時に呼び出すべき機能を‘指定して’おくだけ。なので、ノンデベロッパープログラミングでも柔軟性が維持される。〕

Twilio Studioの料金は、アプリケーションの利用量がベースだ。やや制限のある無料プランでも、作れるフローの数に制限はないが、プロダクション向けに機能の完備した“Plus”では、月額99ドル＋顧客のエンゲージメント一回につき0.5セントだ。今後登場するエンタープライズプランでは、もっと大規模な実装が可能になる。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

Kubernetes展開お助けサービスで起業したHeptioが創立1年足らずでシリーズB $25Mを調達

オープンソースのコンテナオーケストレーションツールKubernetesの協同ファウンダーCraig McLuckieとJoe Beda〔共に元Google〕が創業したHeptioが今日（米国時間9/13）、Madrona Venture Partnersが率いるシリーズBのラウンドで、2500万ドルを調達したことを発表した。Lightspeed Venture PartnersとAccel Partnersもこのラウンドに参加したが、同社はシリーズAで850万ドルを調達してからまだ1年経っていない。ただしこのシアトルのスタートアップは、シード資金を獲得していない。なお、Kubernetesのもう一人の協同ファウンダーBrendan Burnsは、今Microsoftにいる…MicrosoftからGoogleに来たBedaとは逆だ。

HeptioのCEO McLuckieは、“短い8か月だったが、すばらしい体験をした”、と語る。“シリーズAのときは、次の資金調達がこれほどすぐだとは、想像もしなかった”。Kubernetesやそのほかのクラウドネイティブ技術のエンタープライズへの導入を支援する彼らのビジネス機会が、これほど急速に大きくなるとは、彼らも予想しなかった。そして今彼が強調するのは、その機会が単にKubernetesの機会ではないことだ。

McLuckieは語る: “Kubernetesは核であり、それを取り巻くようにしてこの会社を作った”。そしてさらにそのまわりには、クラウドネイティブコンピューティングをエンタープライズが容易に採用できるようにするためにやるべき仕事が、山のようにある。また、さらにそれに伴って、デベロッパーの新しいワークフローも生まれる。Kubernetesはコンテナオーケストレーションツールだが、McLuckieによると、ほかに大量の関連ツールも作らなければならない。

“Kubernetesの人気が盛り上がるのを見て、われわれにはこれをビジネス機会として捉える資格がある、と感じた”、そうMcLuckieは述べる。

では、Heptioは実際に何をやっているのか？　企業向けの、Kubernetesお助けサービスがビジネスになる、と確信していたが、最初はプロダクトの具体的なイメージはなかった。でもその後の数か月で、徐々にビジネスモデルがはっきりしてきた。要するにHeptioは、Kubernetesを採用したがっている企業にプロフェッショナルなサービスを提供し、教育訓練やサポートも提供する。McLuckieが強調するのは、それが企業のKubernetes利用を助けるだけでなく、彼らをオープンソースのコミュニティに接近させる意味合いもあること。そのためにチームは、Kubernetesのいくつかの具体的な特性と、それがオーケストレーションするコンテナクラスターを管理するための、独自のオープンソースプロジェクトも作っている。

新たな資金はヨーロッパとアジアへの進出に充てる予定だが、さらにチームを拡大するとともに、新市場開拓に役に立ちそうな買収を検討するかもしれない、という。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

営業の最終過程を管理するサービスApttusが$55Mを調達、次はIPOか

Salesforce上の見積請求管理サービスApttus（日本）は今やユニコーン企業だが、このほど5500万ドルの資金調達ラウンドを発表した。これは同社の、IPO前の最後のプライベート投資になるものと思われる。

CEOのKirk Krappeは上場についてまだ明言しないが、今日（米国時間9/13）のラウンドは今後の投資家の信任を獲得するだろう、と述べた。“バランスシート上に一定量の流動性が必要である、と判断した。企業が上場や買収に臨むときは、投資家たちがその企業の確実な流動性を求める。流動性は、企業を良い位置につける”、と彼は説明する。“弊社の成長は今でも大きいが、最後の手早いプライベートラウンドをやるのが賢明かつ慎重と言えるだろう”。

5500万ドルのラウンドをリードしたのは、インドのシステムインテグレーターWiproのプライベート投資部門Premjiだ。これまでの投資家Salesforce, K1, Iconiqも参加した。

今や13億ドル(2016/9現在)というユニコーン評価額の同社は、これで累計調達額が3億2900万ドルになる。最近では、投資家を国際的に求めることにも果敢だ。たとえばシリーズCの1億800万ドルには、Kuwait Investment Authorityが投資家として参加した。シリーズDの8800万ドルには、サウジアラビアからの投資も含まれる。

バックにSalesforceがいることは大きい。2015年の終わりには、SalesforceがApttusのライバルSteelBrickを買収して割りを食った形になったが、Apttusはその後Microsoft Dynamics用のバージョンを作るなどして独立を模索した。しかし今ではその傷もすべて癒え、今度のラウンドではSalesforceが投資家として戻ってきた。

Krappeによると、Steelbrickの買収によってSalesforceとの仲がこじれたわけではない、という。“彼らは小さなコンペティターを買ったけれども、弊社の同社との関係は一貫して良好であり、今でもうちの仕事の大半はSalesforceの上でやっている”、と彼は語る。

見積〜請求〜回収の全過程を管理するApttusのサービスは、営業過程の重要な部分を担う。営業が顧客企業との関係を築くと、その対話過程をSalesforceに記録するが、実際に最終的な売買契約の過程（本番の見積提出以降）に入ると、企業はApttusなどのソフトウェアを利用して、見積書の作成や、契約書の生成、そして最後の代金回収までの流れを管理していくことになる。〔quote-to-cash, 見積から現金までのサービス、と言う。〕

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

Microsoft Azureにバースト的なワークロードのための新しいVMタイプが登場

Microsoftが今日（米国時間9/11）、同社のクラウドコンピューティングプラットホームAzureの、新しいタイプの仮想マシンをプレビューで発表した。この、バースト的なワークロードに適しているとされる、その名もBシリーズマシンは、今のところもっともローコストなAzureマシンで、CPUの利用度を目的に応じ選べる（下表）。Webサーバーや小規模なデータベース、開発/試験環境などのワークロードに向いているだろう。

このBシリーズのマシンは、バーストできるパフォーマンスを提供するという意味でAWSのT2インスタンスに似ており、仮想CPUのフルパワーを必要としないときは使わないぶんをクレジットとして築ける点でも同じだ。Googleのf1-microとg1-smallのインスタンスも、ほぼ同じだ。マシンがアイドルのときクレジットを蓄えられるから、通常のVMよりも費用を節約できる可能性があり、しかも必要なときには十分なパワーを利用できる。

Microsoftが提供するこのBシリーズマシンには6つのバージョンがあり、いちばん安いのはシングルコアのVMと1GBのメモリで1時間1.2セント、そして最高は8コア32GBのマシンで1時間37.6セントだ。これらはLinuxマシンの場合の料金だが、Windowsマシンの場合は例によってやや高くなる。プレビューの間は、料金はこれらの半額である。

これらの新しいマシンタイプが提供されるのは、最初はアメリカ(West 2, East)、ヨーロッパ(West)、アジア太平洋(Southeast)のゾーンのみだ。プレビュー期間に利用してみたいデベロッパーは、クォータをリクエストする必要がある。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

Nginx Application Platform、Nginxが考える今の時代に合ったアプリケーションプラットホームとは？

Nginxは、その商用バージョンとオープンソースバージョンの両方で、今日のインターネット上のとても人気の高いロードバランサーであり、プロキシであり、Webサーバー/アプリケーションサーバーだが、その提供企業であるNginx, Inc.は、顧客を獲得するための網をもっと大きくしたい、と考えている。とくに重要視しているのが、アプリケーションの開発とデプロイ方式の、近年における急速な変化だ。ポートランドで行われたデベロッパーカンファレンスで今日（米国時間9/6）同社は、デベロッパーがアプリケーションを開発するため、あるいは、DevOpsやクラウド、コンテナ、マイクロサービスといった新しい枠組みに基づいてアプリケーションを現代化するためのワンストッププラットホームとして、Nginx Application Platformの立ち上げを発表した。

当然ながらこのプラットホームの核は、オープンソースバージョンにさまざまなエンタープライズ機能を加えた商用バージョンのNginxだ。さらにその上に、Nginx ControllerおよびNginx Unitというものが加わる。Controllerはその名のとおり、アプリケーションの集中的な管理と制御を行う（アプリケーションはどこへデプロイされていてもよい）。そしてUnitは、PHP, Python, およびGoで書かれた、動的可変的な環境で動くアプリケーションのための、現代的なアプリケーションサーバーだ（今後node.js, Java, Ruby, Perlなどもサポートされる）。年内にUnitはControllerに完全に統合されるので、opsのチームがUnitのアプリケーションをControllerのダッシュボードから管理できる。

Nginxのプロダクト担当Owen Garrettはこう言う: “Unitの基本的な考え方は、今日のアプリケーションサーバーがマイクロサービス方式のアプリケーションアーキテクチャに十分に対応していない、という点にある。たとえば一つのアプリケーションを構成する複数のマイクロサービスが、いろんな言語で書かれていたりするからね”。

Controllerは、Nginx Plusおよびその上で動く従来的なアプリケーションと、今多くの企業が投資している現代的なグリーンフィールドデプロイメント（green-field deployments, レガシー残存物のない処女地デプロイ）の両者を橋渡しする。

Controllerは10月に一部の顧客に非公開ベータで提供され、Unitはすでに可利用である。

今あるNginx Web Application Firewallも、このプラットホームに加わる。Controllerがまだ非公開ベータだから、料金等は未定だ。

なお、Unitはオープンソースだが、Controllerはクローズドソースだ。一部の商用製品をクローズドにするのは、Nginxの従来からのやり方だ。協同ファウンダーでCTOのIgor Sysoevはこう述べる: “Unitは多くの人に使ってほしいから、オープンソースにする。でもControllerは商用製品にしたい”。Unitを早くリリースしたのは、コミュニティからのフィードバックをなるべく早く得て、ツールの今後の方向性の参考にしたいから、だそうだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

VMware CloudがAWSから提供される、ITのプロたちは喜びのダンスを踊る

VMwareは昨年の秋にAWSとのパートナーシップ発表して、エンタープライズ界隈を驚かせた。一方はオンプレミスの仮想マシンを支配している企業だし、他方はパブリッククラウドの雄だ。それは、強力な組み合わせになるだろう、と思われた。そしてVMwareは今日（米国時間8/28）のVMworldで、その組み合わせの正体、AWS上のVMware Cloudを公式に明らかにした。

AWSは同社独自のVMsを動かしているが、それはデータセンターでVMwareが動かしているものと同じではないので、両方を使おうとしている企業にとっては管理が頭痛の種だ。でも、AWS一本に絞って、その上でVMwareのVMsを引き続いて動かせるなら、管理の問題がなくて両者の良いとこ取りができる。

それはどちらにとっても都合が良くて、VMWareのCEO Pat GelsingerとAWSのCEO Andy Jassyの両方とも、失うものがない。Gelsingerは声明文で述べている: “AWS上のVMware Cloudは、顧客にシームレスに統合されたハイブリッドクラウドを与え、それはvSphereベースのオンプレミス環境とAWS両者にまたがる同じアーキテクチャと能力とオペレーション体験をもたらす”。

Jassyはこう付言する: “世界のエンタープライズの大多数が、データセンターをVMwareで仮想化している。そしてこれからは、これらの顧客が容易に、アプリケーションを彼らのオンプレミス環境とAWSのあいだで移動でき、しかもそのために新たなハードウェアを購入したり、アプリケーションを書き換えたり、オペレーションを変更したりする必要がない”。

これは、それまで二つのシステムを苦労しながら一緒に動かしていたITの連中にとって朗報だ。その苦労とは、新しいアプリケーションはクラウドに置けるけれども、一緒に使うレガシーのアプリケーションをVMwareからAWSのVMに移すのがたいへん、という点だ。その障害が、今回の提携で取り除かれる。

このパートナーシップは、企業としてのVMwareにも大きな揚力を与える。オンプレミスのデータセンターでは100%の浸透を誇っている同社も、顧客の多くがワークロードをクラウドへ移し始めた近年では居場所を失い始めていた。今回はパブリッククラウドの巨人AWSと統合し、二つの環境を横断してスムーズに仕事ができるようになったのだから、息苦しさもやっとなくなる。

AWSにとっては、これはお金持ちになれるのはお金持ちだけの好例だ。パブリッククラウドのビジネスで失うものは何もないだけでなく、VMwareという大きなユーザーがそのクラウドにやってくる。どこからどう見てもこれは、ウィン、ウィン、そしてウィンだ。二社が大きな得をして、VMwareのVMsとAWSのクラウドを容易に統合できるようになる顧客も得をする。全員がトロフィーを獲得する。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

Googleのモニタリング/ロギングサービスStackdriverがアップデートされカスタマイズと視覚化が充実

Google Cloud PlatformやAWSの上で動くアプリケーションの、モニタリングやロギング（ログ取り）、診断などのサービスを提供するGoogleのツールStackdriverが今日（米国時間8/31）アップデートされ、ロギングの機能が増えるとともに、無料のログサービスの大きさが拡張された。すなわち12月1日からは、Stackdriverのロギング機能は1プロジェクトあたり1か月に50GBまでのログを無料で提供する。50GBを超えるぶんは、1Gバイトにつき月額50セントが課金される。

このアップデートのスローガンは、ログの分析を早くし、管理を容易にし、そしてより強力にすることだ。そのためにGoogleのチームは、ログに何かが書き込まれたときと、それがStackdriverの分析結果に反映されるまでの時間を短縮した。これまでは、ログのアップデートがStackdriverのユーザーにとって可視になるまで5分以上を要していた。それが今や1分未満になったそうだ。

これまでも、5分では困るというユーザーはあまりいなかったと思うが、でも早くなって怒るユーザーはいないだろうね。

またこれからは、ログのどんな項目でもそれらの各欄をラベルにして、ログのデータを視覚化できる。しかしもっとおもしろいのは、ユーザーが排除フィルターをセットアップして、必要なデータだけをログに出力させられることだ。GoogleのプロダクトマネージャMary KoesとDeepak Tiwariが、今日の発表声明で書いている: “排除フィルターを利用してコストを下げ、無駄なログを減らしてS/N比を上げられる。特定のソースをブロックしたり、逆に特定のパターンにマッチする項目を拾うことによって、コンプライアンスにも貢献する”。

もうひとつの新機能一括エクスポートは、複数のプロジェクトのログをGCS, PubSub, BigQueryなどにエクスポートできる。これまではデベロッパーが、一つ々々手作業でエクスポートしていた。

[↓排除フィルターと排除を指定するエディター]

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

Facebookが世界各地に分散したデータセンターのログを保存するツールLogDeviceをオープンソース化

Facebookは、複数箇所に分散しているデータセンターのログを保存するための自家製のソリューションLogDeviceを、オープンソースにすることを計画している。その発表は、同社のScaleカンファレンスで行われた。

それらのログは、データベースのイベントを調べるために利用されている。何かの理由でサーバーがダウンしたときには、デバッグする方法が必要だし、セキュリティのための監査を行って、サーバー間の整合性を確保しなければならない。大量のユーザーデータが世界中の大きなデータセンターに分散しているFacebookでは、このことがとくに重要だ。

LogDeviceは、ハードウェアやネットワークに問題があってもデータを記録できる。何かの不具合が生じたらログ収集のタスクを他のデータセンターにお願いする。そして回復したら、問題のあったデータセンターのレコードを毎秒5〜10ギガバイトのスピードでリストアする。

Facebookのデータセンターはもうすぐ10箇所になるが、各センターのレコードは確実に同じページに載ってほしい。しかしそこには、バックアップという複雑な問題があるので、データの扱いは一層難しくなる。LogDeviceは、これらの、各所に分散したデータセンターのデータを複製する作業を支援する〔上記のような場合も含め〕。

高価なサーバーをどうしても故障引退させなければならないときでも、LogDeviceは失われたレコードを正しく教えてくれる。レコードのシーケンスとサーバーのストレージを最初から分離し、レコードをさまざまな場所のストレージにランダムに割り当てるので、データセンター全体の自己回復力が強化される。

LogDeviceをいつからオープンソースにするのか、そのスケジュールは公表されていないが、今年のおそい時期に、とは言っている。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

PivotalとVMwareとGoogleがコンテナでパートナー、すでに提供プロダクトも具体化

PivotalとVMwareとGoogleがチームを作って、コンテナプロジェクトの開発とデプロイと管理を、十分なスケーラビリティを維持しつつ単純化する総合的サービスを提供していくことになった。

三社はオープンソースのプロダクトをベースとする商用サービスにより、このパートナーシップを構成するさまざまなパーティーと共にそのプロダクトを市場化していく。GoogleはそれをGoogle Cloud Platformの一環として売ることになり、PivotalとVMwareでは彼らの標準の営業品目として売り、両社の親会社であるDell-EMCはハードウェアを含めたパッケージとして売っていく。

彼らの役割分担を整理するとこうなる: GoogleはオープンソースのコンテナオーケストレーションツールKubernetesを提供する。PivotalはCloud FoundryによりPaaSの要素を提供、そしてVMwareは全体をまとめる管理層を加える。

プロダクトの名前にはPivotalが使われ、Pivotal Container Serviceとなる。省略形はPCSではなくPKSだが、たぶん彼らは頭字語という言葉の意味をよくわかっていないのだろう。いずれにしても、三社が肩を組んでやることは、VMwareのvSphereとGoogleのCloud Platform(GCP)をベースとする“プロダクションに即対応する(production-readyな)Kubernetes”を提供していくことだ。そしてそれは継続的に、Google Container Engineとの互換性が確約される。後者はご想像どおり、GCEではなくてGKEなのだ。¯_(ツ)_/¯

以上は説明だが、このプロダクトが実際にベースとするものはGoogleとPivotalが作ったコンテナ管理プロダクトKuboだ。そしてPKSは、PivotalのCloud Foundryによる、デベロッパーにとっておなじみのコンテナ開発環境を提供する。デベロッパーはKubernetesの経験者であることが前提だ。

VMwareは縁の下の力持ちのように管理層を提供し、その上でDevOpsのOpsの連中がコンテナをデプロイし、コンテナのライフサイクルの全体を管理する。以上を総合すると、エンタープライズ級のコンテナ開発〜デプロイ〜管理のシステムの、一丁あがり、となる。

Google Cloudのプロダクトマーケティング担当VP Sam Ramjiによると、昨年Googleに来る前、Cloud Foundry Foundationにいたときすでに、コンテナをプロダクションに持ち込むためのいちばん容易な方法がCloud Foundryだ、と直観していた。そして当時の彼らは、Kubernetesを統合するやり方を研究していた。

一方、PivotalのJames Watersはこれまで、PivotalのツールとともにGoogle Cloudのツールを使っている大企業顧客が多いことに気づいていて、そのツールキットに、人気急上昇中のKubernetesを含める必要性を痛感していた。

VMwareはどうか、というと、Sanjay PoonenらVMwareの連中はこれまで、コンテナの開発環境としてCloud Foundryを使う大企業顧客が多いことと、Kubernetesがコンテナオーケストレーションエンジンとしての勢いを増していること、この二つの支配的な状況を日々、目にしていた。

そして今回、そのような三者が交わったところに出現したコンテナ統合環境（開発/デプロイ/管理サービス）が、今回の三社パートナーシップの成果だ。その供用開始は、今年の第四四半期を予定している。

〔関連記事:
●三社パートナーシップに導いた7つの動向（未訳）
●VMware CloudがAWSからも提供（未訳）
〕

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

インフラストラクチャのマーケットプレースInflectがサービスプロバイダー30社データセンターとピアリングロケーション2200を新たに加える

サンフランシスコのInflectは、企業が適切なコロケーションファシリティやネットワークサービス、エクスチェンジプロバイダーなどを見つけようとしているとき、それをより容易にしてくれるスタートアップだ。2か月前にローンチしたばかりの同社は今日（米国時間8/24）、そのデータベースに新たに30あまりのサービスプロバイダーと約2200のデータセンター、およびネットワーキングのピアリングロケーションを加えたことを発表した。新しいサービスプロバイダーには、CenturyLink, Cogent, Comcast, Equinix, Level 3, T5, Telstraなどこの業界のヘビー級のプレーヤーたちも含まれる。

ネットワーキングやコロケーションのプロバイダーの詳細情報や課金情報は、あまり簡単には得られない。データや通信の企業は、非常に古いタイプの営業過程を経て契約が決まることが多く、その過程は透明性が乏しい。シードで200万ドルを調達したInflectは、そういった過程を21世紀にふさわしいものにしたい、と考えている。同社はデータをプロバイダーやPeeringDBのデータベースから自分で集める。後者は、ネットワークのピアリング情報を得るためのデファクトスタンダードだ。InflectはPeeringDBのデータをもらい、それを同社独自の検証処理にかける。そして情報のどこをどう変えたかを、PeeringDBと共有する。

協同ファウンダーでCEOのMike Nguyenはこう語る: “ここまで数週間のローンチ直後の反応は、嬉しいものであると同時に、反省を迫られるものでもあった。ユーザーは私たちに、正確で特定ベンダーに傾かないデータを低コストで提供するInflectのようなプラットホームをずっと求めていた、と言う。しかし同時に、サービスプロバイダーたちは、実際にこれから買おうとしている買い手の目の前に、自分たちのサービスを置いてくれるようなプラットホームを探していた、と言うのだ”。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

GoogleのApp Engineがファイヤーウォールを提供、デベロッパーパラダイムの変化で人気を盛り返すか

Googleの最長寿命のクラウドコンピューティングプラットホームのひとつであるApp Engineにやっと、完全な機能を持つファイヤーウォールが備わる。

これまでデベロッパーは、このサービスの上で、自分のアプリケーションへのアクセスを簡単に制限することができなかった。たとえばテストのために一定の範囲のIPアドレスだけにアクセスを許すとか、そんなことが。そこでデベロッパーは制限をアプリケーションのコードとして書いていたが、そうするとどんなリクエストも一応はアプリケーションにやってくるわけだから、拒否するアドレスでもリクエスト処理のコストが生じる。

しかしこれからは、App EngineのAdmin APIやGoogle Cloud Console、さらにコマンドラインツールのgcloudなどを使って、特定のIPアドレスをブロック、または受け入れるアクセス制限をセットアップできる。ファイヤーウォールはアプリケーションの前へ陣取るから、拒否されたリクエストはアプリケーションにやってこないし、そんなリクエストのためにApp Engineのリソースが使われることもない。

App Engineのファイヤーウォールは、その機能や使い方に特殊なところはない。ユーザーはルールをセットアップし、それらのプライオリティ順を決めれば、それだけでOKだ。

App Engineにはすでに、DoS攻撃保護サービスがある。デベロッパーはそれを利用して、良からぬIPアドレスやサブネットを指定できるが、今日（米国時間8/24）のGoogleの発表では、保護のためには今日ベータでローンチしたファイヤーウォールの方をなるべく使ってくれ、ということだ。

App Engineは登場時には最先端のサービスだった。でもそれはデベロッパーを完全に新しいモデルに強制するから、AWSのEC2のような従来的な仮想マシンベースのサービスにはかなわなかった。しかし今では、コンテナやマイクロサービスやサーバーレスプラットホームなどの人気に伴い、App Engineモデルもそれほど珍奇とは感じられなくなり、このファイヤーウォールの例に見られるように、Googleとしても本格的な投資をこれから行っていこうとしているのだろう。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

GoogleのCloud Platformが自社の高速ネットワークを使わない低能力な廉価版ネットワーキングを提供

Googleのクラウドプラットホーム(Cloud Platform)に、廉価版が加わる。これまでの高級版(Premium Tier)は、できるかぎりGoogle自身の高速ネットワークへユーザーのトラフィックをルートして、中継と距離を最小化する。そして今度の安価な標準版(Standard Tier)では、トラフィックを一般の公共的なインターネットにルートし、起こりうる速度低下や中継の増加を我慢していただく。これからのデベロッパーは、そのどちらかを選べる。

Googleのインフラ担当SVP Urs Hölzleは曰く: “これまでの18年間で、Googleは世界最大のネットワークを築き、今ではそれがインターネットの全トラフィックの25-30%を配達していると推定される。Premium Tierではその同じインフラを享受できるが、しかしユースケースによっては、安価で低能力なネットワーキングを選んでもよい。両者を合わせたサービスをNetwork Service Tiersと呼んでいるが、アプリケーションごとに、もっとも適したネットワークをお選びいただける”。

北米およびヨーロッパでは、標準版は高級版より24-33%安い。また課金方式は、高級版ではトラフィックの起点から終点までの距離で計算されるが、標準版は距離は関係なく、起点がどこにあるかによって、料金が異なる。

今現在は、Google Cloudの全ユーザーがいわゆるPremium Tierを使っている。トラフィックはできるかぎりGoogle自身のネットワークを通り、そして同社のエッジネットワーク上に存在する100あまりのグローバルポイントのどれかで、よりワイドなインターネットへ渡される。ちなみに、このように、できるかぎり長く起点ネットワークがトラフィックを保持する方式をcold-potato routing（コールドポテトルーティング）と呼ぶ。この方式では遅延が最小化され、トラフィックはGoogle自身のケーブルを通るから、パケットロスも少ない。このことは、アプリケーションからユーザーへの往路だけでなく、ユーザーからアプリケーションへの帰路についても、同様に言える。帰路ではトラフィックはできるだけ早くGoogleのエッジネットワークに渡され、そして企業のデータセンターへと旅をする。

新たにできたStandard Tierでは、トラフィックはGoogleのネットワークではなく一般的な（公共的な）インターネットへ渡される。そしてトラフィックは、ネットワークからネットワークへ、ISPからISPへと中継されるから、当然、単一のネットワーク上より遅くなる。クラウドサービスでも、Googleのような大きな自前ネットワークを持ってないところを使うと、このStandard Tierと同じ結果になる、とGoogleは宣伝っぽく言っている。

この二種類のネットワーキングのパフォーマンスの測定と公共的なモニタリングを、GoogleはCedexisと協働して行っている。当然ながらStandard Tierではスループットが遅く、遅延（レイテンシー）は高い。より顕著なのは、レイテンシーの違いよりもむしろ、スループットの違いである。

なお、Standard TierではGoogleのグローバルロードバランサーとCloud CDNが使えない。代わりに、リージョン内のロードバランサーを使わなければならない。

アプリケーションの特性やニーズによって、どちらのネットワーキングを使うべきか迷ったときは、Googleが作った下図のフローチャートを使ってみよう:

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

Googleは企業のChrome OS機採用を促進するためエンタープライズサービスのワンセットChrome Enterpriseをローンチ

Googleは、Chrome OS機の採用を考えている大企業のための新たなエンタープライズサービスをローンチする。そのChrome Enterpriseと呼ばれるサブスクリプション（会員制サービス）は、一機につき年間50ドルで、基本的にはChromebooks for Workの別名のようなものだが、サービスの内容は増えている。名前にChromeがあってもそれはChromeブラウザーのことではなく、あくまでもChrome OSである。エンタープライズのChromeユーザー向けにはすでに、Chrome Enterprise Bundle for ITというものが用意されている。

Chrome OS機のユーザーのためのChrome Enterprise会費制サービスの呼び物は、既存のオンプレミスのMicrosoft Active Directoryのインフラストラクチャと完全互換であることだ。担当ディレクターのRajen Shethによると、この件はChrome OS機を採用しようとする企業にとって長年の障害だった。しかしChrome Enterpriseでは、ユーザーはそれまでの認証情報を使ってChrome OS機にログインでき、自分たちのGoogle Cloudサービスにアクセスできる。そしてITアドミンは、彼らのデバイスとサービスへの、彼らのアクセスを管理できる。

なおChrome OSのアドミンは前からすでに、SAMLスタンダードを使ってChrome OS機へのシングルサインオンを有効にできるサービスなら、有効にできていた。

それに加えて企業はこれからは、彼らがすでに使っている同じエンタープライズモバイル管理ソリューションから、自分たちのChrome OS機を管理できる。まず最初は、VMwareのAirWatchからだ。そのほかの同様のサービスも、今後追い追いサポートされる。

このChrome Enterpriseのライセンスでは、ITアドミンが自分たちのユーザーのための、管理サービス付きのエンタープライズアプリストアをセットアップできる。この機能は目下ベータで、Chrome OSのAndroidアプリを動かせる能力にフォーカスしている。この能力は、多くのエンタープライズが使っているChrome OS機のほとんどで利用できる。

さらに好都合なのは、Chrome Enterpriseの会員になると24/7のエンタープライズサポートや、OSの管理つきアップデート、プリンターの管理などが提供される。プリンターのところで笑った読者もおられるかと思うが、プリンターはいまだに、多くの会社で重要なのだ〔文書やコミュニケーションがデジタル化/ネット化されていない〕。

周知のように今のGoogleは、なりふり構わず多くの企業を自社のクラウドサービスの顧客にしようと努力している。Chromebookはすでに、リテールや教育の分野で、稼げるニッチを見つけている。それをさらに一般的な企業分野に拡大していくためには、たとえば今回のAirWatchとの統合のような機能が、ものすごく必要とされていたのだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

Microsoftが完全な管理を伴うイベントルーティングサービスAzure Event Gridを立ち上げ

Microsoftが今日（米国時間8/16）、Azure系列の新製品をプレビューとして発表した。それは、イベントベースのアプリケーションを作りやすくするためのツールだ。

そのAzure Event Gridは、画像やビデオがアップロードされた、ボタンがクリックされた、データベースがアップデートされた、などなどのイベントをAzureの正式のオブジェクトとして扱う。Event GridはMicrosoftの既存のサーバーレス製品Azure FunctionsやAzure Logic Apps（の足りない機能）を補完して、完全に管理されたイベントルーティングサービスへのアクセスを与える。この新しいサービスにより、どんなイベントに対しても、それを受け入れて反応する柔軟性が与えられる。それらは、Azure内部で起きるイベントでも、あるいはサードパーティのサービスや既存のアプリケーションで起きるイベントでもよい。

Event Gridを使うと、イベントを特定のエンドポイント（あるいは複数のエンドポイント）へルートしたりフィルタできる。

“サーバーレス”という言葉は、最初から一貫して誤称だ。たしかにアプリケーションはサーバーを呼び出さないけど、イベントに応じて何かをやるのは依然としてサーバー、というかサーバー上のコードだ。サーバーレスプラットホームの基本的なコンセプトは、このモデルではイベント駆動のアプリケーションを、それを支える低レベルのインフラストラクチャ（サーバーなど）をまったく気にせずに作れる、という点にある。

たとえば、MicrosoftのAzure ComputeのディレクターCorey Sandersによると、Event Gridは、マイクロサービスを作るためのMicrosoftのプラットホームService Fabricの上にあるが、デベロッパーはそのサービスについて何も知る必要がなく、プラットホームがすべての面倒を見る。

Event Gridはwebhookのエンドポイントとして、どんなアプリケーションからでも入力を取れるから、Azure FunctionsやLogic Appsなどよりもやや進んでいる。“目標は、顧客が管理でき操作できる正式のオブジェクトとしてのイベントを提供することだ”、と、Sandersは語る。基本仕様としてEvent Gridは、Azure Blog StorageやResource Manager, Application Topics, Event Hubs, Azure Functions, Azure Automation, そしてLogic Appsをサポートしている。またCosmosDBデータベースサービスやIoT Hubなどの新しいサービスも、年内にはサポートされる。IoTアプリケーションはイベント駆動が定石だから、IoT Hubのリリース時点でイベントのサポートがなかったのが、むしろ意外だ。

標準的なサーバーレスアプリケーションとインテグレーションはLogic Appsがあれば十分かもしれないが、Event Gridを使えばオペレーションのワークフローの一部を自動化でき、たとえば新しい仮想マシンやデータベースの立ち上げなどにも、自動的に対応できるようになる。

Event Gridの料金は処理するオペレーションの数による。最初の10万オペレーションは無料、そしてその後、100万オペレーションごとに60セントだ。現在のプレビューの時点では、30セントとなる。ひとつのオペレーションは、入力処理、高度な数値演算、デリバリの試み、管理タスクの呼び出しなどだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

NoSQLデータベースのMongoDBが非公開でIPOを申請

情報筋によると、MongoDBが秘かにIPOしていた。同社がSECにS-1ファイルを提出したのは数週間前で、今年中の上場をねらっている。

ニューヨークのMongoDBは、そのデータベースプロダクトとデータベース管理サービスをAdobe, eBay, Citigroupなども利用している。主要なプロダクトは、社名と同じオープンソースのデータベースMongoDBと、Atlas DBaaS(Database as a Service, クラウド上から提供されるデータベース)だ。

同社は2008年以降3億ドルあまりの、非公開段階の資金を調達しており、Sequoia Capital, Intel Capital, NEAなど著名な投資家が投資に参加している。最近の資金調達ラウンドは2年あまり前で、そのときの評価額は16億ドルといわれる。

MongoDBは、2012年に制定された雇用創出法*が定めている“非公開申請”を利用している。それによると、申請をしてから15日間は財務条件などを公開せずに投資家めぐりができる。これによりスタートアップは、上場前の数週間、余計な審査や手続きに悩まされずに市場デビューの準備ができる。〔*: 参考記事〕

MongoDBのIPOは、数年前から噂されていた。今年の5月には、Wall Street Journalが、同社がIPOに向けて投資銀行の連中を雇った、と報じている。

本誌TechCrunchも最近、Stitch Fixがやはり非公開でIPOを申請したことを報じた。そのほかにも数社が、労働者の日（9月第一月曜日）と感謝祭（11月第四木曜日）までの間に上場を目論んでいる、と噂されている。

IPOは社員や初期の投資家たちに流動性（会社の所有権…株…が一般的に売買できること）を提供するための優れた方法だが、GoogleやAmazonが大成功を収めた反面、最近の人気IPOだったSnapやBlue Apronなどは、その後苦戦した。ビッグデータ企業のClouderaは、IPO価格よりも上の株価を維持している。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

GoogleのCloud Speech APIが大幅アップデート、対応言語が増え、言葉にタイムスタンプを付着

2016年にローンチしたGoogleのCloud Speech APIは、話された言葉をテキストに書き起こす。このAPIが今日（米国時間8/14）、大幅にアップデートされた。

中でもいちばんおもしろいのは、これまでの89言語に加えて新たに30の言語が加わったことだろう。ただしこれらの数字には、英語とスペイン語とアラビア語の地域的な変種が複数含まれている。今回新たに加わったのは、ベンガル語、ラトビ（ヴィ）ア語、スワヒリ語などで、Googleによると、それらを話す人は約10億人いる。

重要な新しい機能もいくつか加わった。たとえば、言葉にタイムスタンプが付くこと。これにより元の音声と書き起こしテキストに同じタイムスタンプが付くので、前者から後者、あるいはその逆の、対照ができる。書き起こされたテキストを見た人が、それらの実際の発音を知ることができる。また、このAPIを使って人間が介助する書き起こしや翻訳サービスをしているところは、仕事のスピードアップができる。このAPIを使って1分10セントでインタビューの書き起こしサービスを提供しているHappy Scribeの協同ファウンダーAndré Bastieはこう述べる: “タイムスタンプでオーディオをテキストにマップできるので、書き起こしの校正に要する時間が大幅に短縮できる”。

アップロードできるファイルの大きさは、これまでの80分から3時間になった。もっと長いクォーターも要求できる。

最初の60分は無料、そしてその後は、15秒ごとに0.6セント課金される。

〔関連記事（未訳）〕

〔新たに加わった言語:

Amharic (Ethiopia)
Armenian (Armenia)
Azerbaijani (Azerbaijani)
Bengali (Bangladesh, India)
English (Ghana, Kenya, Nigeria, Tanzania)
Georgian (Georgia)
Gujarati (India)
Javanese (Indonesia)
Kannada (India)
Khmer (Cambodian)
Lao (Laos)
Latvian (Latvia)
Malayalam (India)
Marathi (India)
Nepali (Nepal)
Sinhala (Sri Lanka)
Sundanese (Indonesia)
Swahili (Tanzania, Kenya)
Tamil (India, Singapore, Sri Lanka, Malaysia)
Telugu (India)
Urdu (Pakistan, India)

〕

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

Amazon MacieはAWSのユーザー企業のクラウド上のデータ保護を機械学習で強化する

AmazonのクラウドコンピューティングサービスAWSが、今日（米国時間8/14）行われた今年のNY Summitの場で、Amazon Macieという新しいサービスを立ち上げた。Macieは、機械学習を利用してクラウド上の機密データをより強力に保護する。当面は、Macieを使って、AmazonのS3ストレージサービスにある個人を特定できる情報や知財を保護でき、年内にはAWSのそのほかのデータストアもサポートされる（たぶん11月のre:Inventカンファレンスで発表されるだろう）。

このサービスは完全に管理され、機械学習を使ってデータのアクセスをモニタし、異状を検出する。疑わしいアクションがあればユーザーに警告し、ユーザーがデータリークやその原因を（ヒトによる犯行以外のものも含め）見つけられるようにする。そのためにこのサービスは、S3に入ってくる新しいデータを継続的にモニタする。そして、通常のアクセスパターンを学習して理解し、またストレージバケット内のデータの正規の形を理解している機械学習を利用する。

このサービスはまた（アメリカの場合）、ヒトのフルネームや、住所、クレジットカード番号、IPアドレス、免許証番号、社会保障番号、誕生日などを自動的に検出するが、指定によりさらに、メールアドレスやSECのフォーム、データログ、データベースのバックアップ、ソースコードなども自動的に検出できる。

これらの高リスクデータはすべてダッシュボード上で高輝度表示され、またそれらにユーザーやそのほかのアプリケーションがどのようにアクセスしているかも示される。

AWSのサービスはどれも料金が複雑だが、このMacieサービスでは各月のイベントの数とデータ量が料金計算のベースになる。最初は、ユーザーのデータの特性や分類を機械学習におぼえさせるため、最初の月の料金は高くなる。

今Macieを利用できるのは、AWSのU.S. East(Northern Virginia)とU.S. West (Oregon)リージョンだけだが、今後徐々に拡張されるだろう。

このほかAmazonは今日、さまざまなデータベースやストレージサービスにロードするデータを準備するサービスGlueを発表した。それはすでに、すべての顧客が利用できる。

さらに同社は今日のイベントを機に、ワークロードの一部をクラウドへ移したい企業のためのマイグレーションハブをローンチし、、またElastic File Systemのアップデートにより暗号化された状態での保存がサポートされ、それと並んでキー管理のためのAWS ConfigとAWS CloudHSMもアップデートされた。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））