タグ: Cloud

AWSがIoTデバイスのワンクリックでLambdaファンクションを実行するアプリを発表

Amazonが2015年にAWS Lambdaを導入したときには、サーバーレスコンピューティングという概念がまだよく知られていなかった。デベロッパーはそれによってソフトウェアを、それを実行するサーバーの管理等をせずに配布できる。サーバーはAmazonが管理し、そのインフラストラクチャは何かのイベントが要求をトリガしたときだけ動く。今日同社は、AWS IoT 1-Clickと呼ばれるアプリをiOS App Storeにリリースして、サーバーレスコンピューティングの概念をさらにまた一歩、前進させた。

その名前の“1-Click”の部分はちょっと大げさだが、とにかくこのアプリは、ラムダのイベントトリガーへのさらに素早いアクセスをデベロッパーに提供する。それらは、バッジを読むとか、ボタンを押すといった単純な目的のデバイスに向いている。たとえばそのボタンを押したらカスタマサービスやメンテナンスにつながるなど、そういった単純なシナリオだ。

そもそもAmazonにその好例といえるダッシュボタンがある。それは（Wi-Fiなどインターネットのある環境で）、ワンプッシュで特定のもの（洗剤、トイレットペーパーなど）を一定量注文できるボタンで、AWS IoT 1-Clickでデベロッパーは、自分のデバイス*にそんなシンプルな機能を持たせることができる。〔*: ローンチ直後の現状でサポートされているデバイスはボタン2種のみ、今後増える予定。〕

この機能を利用するためには、最初に自分のアカウント情報を入力する。利用するWi-Fiを指定し、デバイスとそのデバイスのLambdaファンクションを選ぶ。今サポートされているデバイスは、汎用ダッシュボタンとも言えるAWS IoT Enterprise Buttonと、AT&T LTE-M Buttonだ。

デバイスを選んだら、Lambdaファンクションをトリガーするプロジェクトを定義する。単純に、メールやSMSを送らせてもよい。イベントをトリガーするLambdaファンクションを選びNextをタッチすると、構成画面になるのでトリガーアクションを構成する。たとえば、会議室にいるときそのボタンを押したらIT部門を呼び出し、IT部門は送られてきたページから、どの会議室からヘルプの要請があったか分かる、など。

そして、適切なLambdaファンクションを選ぶ。それは、あなたの構成情報どおりに動くはずだ。

これらの指定、選択、構成などのプロセスはもちろんワンクリックでは済まないし、テストや構成変えも必要になるだろう。でも、シンプルなLambdaファンクションを作るアプリ、というものがあれば、プログラミングのできない人でもボタンを単純なファンクションで構成できるだろう。ちょっとした学習は必要だが。

このサービスはまだプレビューなので、アプリは今日ダウンロードできても、現時点では参加を申し込む必要がある。

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

AWSのデータベースサービスAuroraにアンドゥ機能が誕生、72時間の遡及可能

AWSの‘マネージドMySQL/PostgreSQL’データベースサービスに、アンドゥ機能がつく。今日の同社の発表によると、そのAurora Backtrack機能により、ユーザーは“時間を逆行できる”。今それはMySQLのみだが、この機能を有効にするとそれ以降新たに作られるデータベースクラスターとバックアップからリストアされたクラスターに対し、アンドゥができるようになる。それまであったデータベースは、ノーだ。

この機能を有効にすると、AWSは最大72時間ぶんのトランザクションのログを取る。本番のデータベースに不正なテーブルを入れた、などの間違いに気づいたら、アプリケーションをポーズして、どこまで戻りたいか、時間（時刻）を指定する。するとAuroraはデータベースもポーズして、開いているすべての接続を閉じ、まだコミットしてないものをすべて落としてから、指定された時点までロールバックする。

もちろん、トランザクションの逆行はAWSが初めてではない。MySQLも含め、多くのデータベースシステムが、すでに何らかの形で実装している。ただしそれらの多くは、今日AWSが発表したものに比べると範囲が狭い。

AWSのチーフエヴァンジェリスト(Chief Evangelist) Jeff Barrが今日の発表で言っているが、それは災害復旧だけが目的ではない。彼はこう書いている: “あなたも、このクールな新しい機能の、クリエイティブで奇抜な使い方を、きっと思いつくだろう。たとえば、本番データベースでいろんなテストをして、そのテストの痕跡をすべて掃除することもできる。復旧の指示は、APIまたはCLI（コマンドライン）からできるから、この機能を既存のテストフレームワークに統合するのも容易だ”。

Aurora Backtrackは今、すべてのデベロッパーが使える。料金は、アメリカリージョンではレコードの書き換え100万文字につき約0.012ドルだ。ヨーロッパとアジアでは、やや高くなる。

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

Kubernetesのための機械学習ツールKubeflowが発表から4か月で最初のバージョンをリリース

Googleが作ったオープンソースのコンテナオーケストレーションツールKubernetesは、おそらく同社が想像しなかったほど華々しく成長した。そしてその人気が増すとともに、多くの関連プログラムが生まれてきた。今日（米国時間5/4）はGoogleが、オープンソースのツールKubeflowのバージョン0.1のリリースを発表した。これは、Kubernetesのコンテナに機械学習をさせるためのツールだ。

Googleはかなり前にKubernetesをCloud Native Computing Foundationへ移したが、積極的な関与は継続し、今回のKubeflowもそのひとつだ。このプロジェクトは昨年末オースチンで行われたKubeconで発表されたばかりだが、早くもかなりの勢いがついている。

GoogleでKubeflowを運用しているDavid Aronchickは、その前の2年半、Kubernetesのチームを率いた。その彼の言うKubeflowの基本的な考え方とは、データサイエンティストたちが、Kubernetesのクラスターの上で機械学習のジョブを動かせるアドバンテージを享受できることだ。Kubeflowを使って機械学習のチームは、既存のジョブを簡単にクラスターに付けられる。

今日の発表でプロジェクトは前進を開始し、その節目を報告するブログ記事は、安定性のアップと、コミュニティの要望に応じて実装した多くの新機能を強調している。新機能には、機械学習のジョブをコラボレーションと対話により訓練するJupyter Hubや、Tensorflowの訓練とホスティングなどが含まれる。

Aronchickが強調するのは、このプロジェクトがオープンソースなので、いろんなツールを使えるということ。最初のバージョンがGoogleの機械学習ツールばかりサポートしていても、 Tensorflowに縛られることはない。今後のバージョンでは、そのほかのツールのサポートも期待できる。

最初の発表からわずか4か月あまりでコミュニティは急速に成長し、70名を超えるコントリビューターと20社あまりのコントリビューター企業がいて、15のレポジトリーに700以上のコミットが行われた。次のバージョン0.2は、夏になる。

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

DatadogのコンテナマップはKubernetesアプリケーションの内部〜各コンテナの可視性を提供

コンテナへ移行する企業が増えている中で、個々のコンテナと、それがアプリケーションに与えているインパクトをモニタすることが、課題になっている。それがとくに難しいのは、コンテナがきわめて短時間だけ存在する短命な実体だからだ。モニタリングとアナリティクスの専門企業Datadogは今日（米国時間5/3）、この問題を解決するための視覚化ツール、コンテナマップを発表した。

Datadogのプロマネ担当VP Ilan Rabinovitchはこう語る: “コンテナマップはユーザーのシステムにあるすべてのコンテナを見せる。顧客はすべてのコンテナを、どんなときでも見られて、それらをタグに基づいてグループ化し、その中で起きていることを詳しく知ることができる”。

同社はタグとメタデータを利用してコンテナの各部とそれらのお互いの関係、そしてそれらを支えるインフラストラクチャを識別する。そのツールはコンテナを、Datadogのそのほかのエンティティとまったく同じようにモニタする。

同社のブログ記事は、こう書いている:

“ホストマップが個々のインスタンスに対してするように、コンテナマップはメタデータを使ってコンテナを容易にグループ化し、フィルタし、点検できる。メタデータは、サービス、可利用性ゾーン、ロール、パーティション、そのほかのユーザーが望む特質など、何でもよい”。

問題が見つかったとき、Datadog自身が顧客企業のシステムにライト(write)アクセスして問題を修復することはしないが、その企業はWebhookや、あるいはAmazon Lambdaのファンクションのようなサーバーレスのトリガを使って、何らかのアクションを呼び出すことができる。

  1. container-inspect

  2. container-list

  3. dashboard

 View Slideshow
Exit

同社は、すべてのコンテナが正常に動作していることを監視するサードパーティにすぎない。“コンテナに対してやるべきことは、もっぱらKubernetesを信用している。でも異状が起きたら、何が起きたのかを知らなければならないが、それはKubernetesにできることではない”、とRabinovitchは語る。この新しいマップの機能は、コンテナシステムの内部に対する、その欠けていた可視性を提供し、ユーザーは個々のコンテナの内部を詳細に調べて、問題の原因を特定できる。

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

クラウドホスティングのDigitalOceanもついにコンテナプラットホームを提供

誰もが気軽に使えるクラウドホスティングサービスDigitalOceanが、そのメニューにコンテナサービスを載せた。同社は今でも、安価な仮想プライベートサーバーのホスティングサービスとしていちばんよく知られているが、同社自身はそのうち、クラウドコンピューティングの世界でメジャーになるつもりだ。ホスティングは、そのプランの最初の部分にすぎない。たとえば同社のストレージサービスSpacesは、同社の夢が本気であることを示す一例だ。

しかし今や、コンテナを避けて通れない世の中になっているので、同社が今日（米国時間5/2）、Kubernetesベースのコンテナサービスを立ち上げたのも、もはや意外ではないだろう。

このサービスはまだ初期のプレビュー段階で、ここからサインアップできるが、一般公開は今年の終わりごろだ。

DigitalOceanのプロダクト担当VP Shiven Ramjiはこう述べている: “私たちはいつも、デベロッパーのためのシンプルなソリューションに専心してきた。その最初のプロダクトが、クラウドサーバーDropletsだった。今度のプロダクトも、その例外ではない。デベロッパーは自分のアプリケーションを完成させることに専念でき、複数のアプリケーションにまたがるスケーラビリティの高い安全なクラスターを作って動かすことに伴う、複雑な作業は免除されるのだ”。

そのサービスはDigitalOcean Kubernetesと名付けられ、それによりデベロッパーは、自分のコンテナワークロードをDigitalOceanのプラットホームでデプロイし管理できる。大手のクラウドコンピューティングプロバイダーのほとんどすべてが提供している競合製品と同様に、DigitalOceanのプロダクトも、Kubernetesを動かすことに伴う複雑性の大部分を、抽象化してデベロッパーからは見えなくする。しかし必要ならユーザーは、KubernetesのAPIにフルアクセスして、独自の隔離されたKubernetesクラスターを作れる。

このサービスは同社の既存のサービス、ストレージやファイヤーウォールツールなどを統合している。デベロッパーは自分のコンテナを、DigitalOceanの標準のノードで動かすか、あるいはより強力で計算能力の高いノードで動かすかを、選択できる。また“teams”という機能で、アクセスコントロールができる。さらに、こういうサービスの通例として、通常のパフォーマンスアナリティクスやロギングの機能もある。

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

RedHatのCoreOSがKubernetesアプリケーションを管理するツールキットを発表

Red Hatが今年初めに2億5000万ドルで買収したLinuxディストリビューションとコンテナ管理のスタートアップCoreOSが今日（米国時間4/30）、Kubernetesのクラスターを管理するオープンソースのツールキットOperator Frameworkを発表した。

CoreOSがソフトウェア概念としてのOperatorについて最初に言及したのは、2016年だった。その考え方は、コンテナベースのアプリケーションをデプロイし管理するためのベストプラクティスをコードとして実装することだった。“まあOperatorとは、最良のオペレーター社員を絵に描いたようなものだ”、とRedHatのOpenShiftのプロダクトマネージャーRob Szumskiは語る。理想としては、Operator Frameworkはオペレーションのチームをあらゆる雑用や単純労働から解放して、高いレベルのタスクに集中させる。そして同時に、Operatorがつねに会社のルールブックに従うことによって、その過程からエラーしがちな人間を取り除く。

CoreOSのCTO Brandon Philipsは、今日の発表声明でこう説明している: “Kubernetesを最大限に有効利用するためには、Kubernetesの上で動くアプリケーションをサービスし管理するための一連の統一的なAPIを広げる必要がある。われわれはOperatorを、Kubernetes上のそういうアプリケーションを管理するランタイムだ、と見なしている”。

Szumskiによれば、CoreOSのチームは、同社独自のTechtonicコンテナプラットホームを作って管理するときに（そのユーザーコミュニティからのものも含めて）、これらのベストプラクティスを開発した。それらがコードとしてのOperatorとして動くようになると、Kubernetesのクラスターを監視し、アップデートを処理し、たとえば何かがおかしくなったら、数ミリ秒以内にその不具合に反応する。

全体としてのOperator Frameworkは、三つの部分から成る。1)実際のOperatorを作ってテストしてパッケージするためのSDK、2)OperatorをKubernetesのクラスターにデプロイしてそれらを管理するためのOperator Lifecycle Manager、そして、3)チャージバックや顧客への課金を必要とする企業のためにKubernetesのユーザーを（リソース使用量などを）計量することだ。

軽量ツールは全体の絵の中ではつけたり的だが、Szumskiによると多くの企業がそれを求めるのであり、CoreOSもKubernetesでそれをやるのはうちが初めて、と主張している。

今日のCoreOS/Red Hatによる発表は、今後各方面から、さまざまなKubernetes関連の発表が行われそうな週の、始まりにすぎない。数日後にはCloud Native Computing FoundationのデベロッパーカンファレンスKubeConが始まるし、そこではコンテナのエコシステムに帰属する企業のほとんどが、何かを発表すると思われるからだ。

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

より本格的な健康データデバイスを目指すFitbitがGoogle Cloud Health APIの利用へ

ヘルスデータ・ブレスレットのFitbitが今朝（米国時間4/30）、単なるエクササイズツールから本格的なヘルスケア製品へのステータス・アップをねらって、GoogleのCloud Healthcare APIを利用していく、と発表した。これはまるで、筋書き通りのようなパートナーシップだ。

アメリカの保健医療市場は2016年の支出額で3.3兆ドルと言われるが、GoogleはCloud Healthcareでこの巨大な市場へ食い込むことをねらっている。この市場の成長を止めるものは何もないから、数年後にはさらに額が肥大していると予想される。

Googleはこれまで、同社の既存のクラウド製品を利用して、ヘルスケアという巨大な世界のための情報共有基盤を提供してきた。その初期の段階では同社は、Stanford School of Medicine（スタンフォード大学医学部大学院）など医療専門機関とパートナーしてきたが、今回のFitbitとの契約は、さらにメジャーな路線への進出になる。

またFitbitにとっては逆に、より正統的なヘルスケアの世界への接近になる。最近のイベントでCEOのJames Parkは、ヘルスケアは消費者電子製品の企業がそこへ向かっていくべき大きな世界だ、と語った。それはもちろん、Jawboneのように消費者分野を切り捨てるという意味ではなく、正統的な医療保健データの収集を一般化大衆化することに大きな市場機会を見出している、ということだ。

正統的というのは、医師が患者の電子的医療データとまったく同格に、Fitbitによるモニタリングデータを利用する、できる、という意味だ。最近同社が買収したTwine Healthは、エクササイズデータに加えて糖尿病や高血圧などのデータを提供してくれるはずだ。

Google Cloud Healthcareからの新しいサービスについて、具体的な日程等の発表はまだない。

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

Google、NvidiaのTesla V100 GPUをクラウドで提供開始

Google は今日（米国時間4/30）、Nvidiaの高性能GPU Tesla V100がCompute EngineおよびKubernetes Engineで利用可能になったことを発表した。現在はまだ公開ベータだが、GPU作業でGoogleの完全サポートを必要とする利用者には、やや性能の低いNvidia P100 GPUがベータを終え一般公開された。

V100 GPUは、今もNvidiaの高性能コンピューティングのラインアップの中で最も強力なチップだ。登場からしばらく時間がたっており、Googleはやや遅れた参入となった。AWSとIBMはすでにV100を顧客に提供しており、Azureではプライベートプレビューを行っている。

GoogleはNvidiaのマルチGPUプロセッシングのための高速インターフェースであるNVLinkも使用していることを強調しているが、ライバル各社もすでにこれを使っていることは指摘しておくべきだろう。NVLinkはGPU-to-GPUのバンド幅を従来のPCIe接続より9倍速くすることで作業によっては40%性能が高くなるとGoogleは約束している。

もちろん性能のためにはお金が必要だ。V100の使用料は1時間につき2.48ドル、P100が1.46ドルだ（これは標準価格であり、Preemptible仮想マシンは半額で利用できる）。これ以外に通常の仮想マシンまたはコンテナを動かすための料金を払う必要がある。

現在V100マシンは、1 GPUまたは8 GPUの2種類の構成で利用可能で、将来は2または4 GPUの構成も加わる予定。P100には、1、2、または4GPUが用意されている。

[原文へ]

（翻訳：Nob Takahashi / facebook ）

Google Cloudのマネージドデータベースサービスがクラウドサービスとしての機能を充実

Googleがクラウドから提供しているデータベースが今日（米国時間4/25）、アップデートされた。画期的な新製品に生まれ変わったわけではないけど、それらのアップデートはすべて、企業がクラウドへ移行するときに経験するさまざまな痛点に対処している。

Googleのプロダクト管理のディレクターDominic Preussによると、Googleは長年、データベースの世界における思想のリーダーを自負している。思想のリーダーとは言ってもこれまでは、Bigtableに関するペーパーなどが主で、実際の製品で示す思想ではなかった。しかし最近では、グローバル分散データベースCloud Spannerが示すように、市場でもその姿が目立つようになった。

Preussによると、Googleのエンタープライズユーザーは彼らの既存のワークロードをクラウドへ移すことから始めるところが多い。しかしそれが一巡したら、新しいアプリケーションをクラウドに載せようとする。そしてそのとき求めるのが、クラウドのプロバイダーがアプリケーションやインフラの管理を肩代わりしてくれる、いわゆるマネージドサービスだ。

今日の発表も、エンタープライズに、彼らが求めるある種のマネージドデータベースサービスを提供していくことがメインのテーマだ。

まずそれは、ベータでローンチされるCloud Memorystore for Redisだ。これは完全に管理されるインメモリのデータストアで、大きなバッファリングをインメモリのキャッシュでやりたい、などのニーズに応える。

ビッグデータワークロード用のNoSQLデータベースサービスCloud Bigtableに、新しい機能が加わった。その、いずれregional replication（リージョナルレプリケーション）という正式名で呼ばれることになる機能は、オンプレミスのワークロードにApache Cassandraを使っていたエンタープライズに、Google Cloudにおけるその代替系を与える。そして、この、異なるゾーンにまたがるレプリケーションにより、Google Cloudに保存するデータの可用性と耐久性が高くなる。

今回のアップデートには、Cloud SQL for PostgreSQLのSLAにおける可用性を99.95%にすることも含まれる。またCloud Spannerには、コミットのタイムスタンプがつく。

Googleのクラウドデータベース周辺には、今後どんな新メンバーが登場するのか。Preussはその答を言わないが、今同社はエンタープライズができるだけ多くのワークロードをクラウドへ移行できるようにしたい、と考えているそうだ。つまり、マネージドサービスが今後も増える、ということだろう。

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

KubernetesをCloud Foundryが本格採用して両社の仲がより密接に

コンテナがソフトウェアの世界を食べている。そしてKubernetesがコンテナの王様だ。そこで、大きなソフトウェアプロジェクトに、とくに企業で関わる人は、いずれこの王様とお近づきになる。今ボストンで、半年に一度のデベロッパーカンファレンスをやっているCloud Foundryも、その興味深い例のひとつだ。

エンタープライズデベロッパーの世界の外にいる人にとっては、Cloud Foundryは馴染みのない名前だが、今ではFortune 500社の約半数がユーザーだ（スタートアップのユーザーはあまりいない）。Cloud Foundryをよく知らない人は、Herokuに似ている、と思ってもよい。ただしそれは商用ユーザーの大きなエコシステムのあるオープンソースのプロジェクトで、そのどんなクラウドやオンプレミス上のインストールでも、そしてどんなに大きなスケールでも、動かすことができる。デベロッパーは自分のコードを（Twelve-Factorの方法論–日本語–に従って）書き、実行に必要なものを定義すると、それが動くためのインフラや、必要なスケーリングについては、すべてCloud Foundryが面倒見てくれる。デベロッパーは自分のアプリケーションをどこで動かすか、どうやってもっと効率的に動かすかなどを、考えなくてよい。

それだけのことを可能にするためにCloud Foundryは、Dockerなどがまだ存在しない、きわめて初期のころからコンテナを導入した。そのころKubernetesはまだなかったので、Cloud Foundryに関わっているさまざまな企業が一緒になって、独自のコンテナオーケストレーションシステムを作った。それは今日のサービスでも利用されている。しかし、コンテナベースの開発が普及するに伴い、Cloud Foundryのエコシステムでも、Kubernetesをサポートせよ、という声が高くなった。昨年Foundationはその方向への第一歩を踏み出し、コンテナを管理するための、KubernetesベースのContainer Runtimeをローンチした。それが、これまでのApplication Runtimeの隣に座る。これによってデベロッパーは、Cloud Foundryを使って、彼らが開発する新しいサービスと並列に、彼らの新旧の一枚岩的なアプリケーションを動かし管理することもできる。

でも、Cloud FoundryではApplication Runtimeのための同団体独自のコンテナサービスをなぜ使い続けるのだろうか？　今ではKubernetesやそのほかの各種プロジェクトが出揃ってきて、それらがコンテナを扱うためのデフォルトになっているから、そんなことをする理由はないはずだ。そこで、当然とはいえ、今では、古いコンテナ管理システムをなくして、それらをKubernetesで置き換えていくCloud Foundryのプロジェクトがある。今やコンテナ管理の部分は、Cloud Foundryの差別化要因ではない。むしろ、Cloud Foundryの最大の差別化要因はデベロッパー体験であり、Cloud Foundryのそもそも中心的メリットは、デベロッパーがインフラストラクチャの内部構造をまったく気にする必要がない、という点にある。

Cloud FoundryのエコシステムがKubernetesに傾くことには、もうひとつの側面がある。Cloud Foundryも同じくソフトウェアだから、それをKubernetesの上で動かして悪い理由はない。だから、SUSEやIBMなど、Cloud Foundryの最大のベンダーたちの一部も、まさにそうしている。

Cloud Foundryの公認ディストリビューションであるSUSE Cloud Application Platformは、どのパブリッククラウドのKubernetesインフラストラクチャの上でも動く。それにはMicrosoftのAzure Container Serviceも含まれる。SUSEのチームによると、その方がデプロイが容易であるだけでなく、リソースの節約にもなる（アプリケーションがより少ないリソースで動く）。

同じくIBMも、今では顧客にKubernetesの上でCloud Foundryを提供している。ただしそれはまだ、実験段階だそうだ。IBMのCloud Developer ServicesのゼネラルマネージャーDon Bouliaが強調するのは、IBMの顧客の多くは自分たちのワークロードを、IBMのそのほかの顧客に共有されない隔離された環境で動かしたがることだ。

Bouliaによれば、多くの顧客に、KubernetesかCloud Foundryか、という視点はない。彼の顧客の多くにとっては、Kubernetesを使うことが即、自分たちの既存のアプリケーションをクラウドへ移すことだ。そして新しいアプリケーションに関しては、Cloud Foundryを動かすことを選ぶ。

SUSEのチームも、同じことを強調している。SUSEの顧客のひとつのパターンとして、彼らはコンテナ環境をセットアップしたくてSUSEにやってくるが、しかしその商談の過程で、Cloud Foundryを実装することを決心するのだ。

というわけで、今週のイベントのメッセージはまさに、KubernetesとCloud Foundryが互いに補完的な技術だ、ということだ。そのイベントのパネルディスカッションで、GoogleのContainer EngineとKubernetes担当技術部長Chen Goldbergも、その点を強調した。

Cloud Foundry Foundationと、KubernetesのホームCloud Native Computing Foundation(CNCF)は共に、Linux Foundationの傘下にある。しかしCloud FoundryはCNCFに比べて圧倒的にエンタープライズユーザーの比重が大きい。そこには何らかの政治が絡んでいるのかもしれないが、でも両団体は互いに十分に友好的で、メンバーも相当重複している。PivotalのCEO Rob Meeは、本誌のRon Millerの取材に対してこう述べた: “うちは半分CNCFで半分Cloud Foundryだ。二つのコミュニティはますますいろんな技術を共有し合っているし、共に進化している。完全に独立でもないし、競争関係もない。関係はもっといろいろ複雑で微妙だ。CNCFとCloud Foundryはどちらも、大きなエコシステムの部分であり、互いに補完し、収束している”。

つまりCNCFとCloud Foundryの技術共有と、もしかしてコラボレーションは、今後も増えるということだろう。CNCFはクラウドネイティブなアプリケーションを作るための、とてもおもしろいいろんなプロジェクトのホームであり、そしてそれらのユースケースの多くはCloud Foundryにもある。

関連記事: Cloud Foundry財団、Alibabaがゴールド会員に――中国のクラウドのオープンソース化加速へ

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

cloud.govの公式参加でアメリカ政府省庁のCloud Foundryの採用が容易になった

ボストンで行われたCloud Foundry Summitで、アメリカ政府のアプリケーションプラットホームcloud.govがCloud Foundryの公認プラットホームになり、そのほかの公認プロバイダー、IBM, Pivotal, SAP, そして今日からはSUSEなどとの互換性が保証される、と発表された。これによりcloud.govは、初めてのCloud Foundry公認政府機関になる。

この認定により、Cloud Foundryをサポートするさまざまなプラットホームのすべてが、お互いの互換性を確実に保証される。政府という文脈ではこれは、省庁が容易に彼らのワークロードを複数のクラウド間で移動できることを意味する（それらのクラウドがすべてに政府の証明があるとして）。しかしさらに重要と思われるのは、スキルのポータビリティが確実になることだ。それにより、コントラクター（政府下請）の起用や選択も容易になる。オープンソースのCloud Foundryは民間セクターでも広く採用され、Fortune 500社の半分は利用しているから、アプリケーションを構築するプラットホームを決めるときも、そのことが重要な要素になる場合が多い。

cloud.govは、General Services Administration（米国総務庁）の18階オフィス(18F)が、アメリカ政府の公開Webサイトやアプリケーションを改良するために立ち上げたサイトで、最初からCloud Foundryの上に構築されている。オーストラリアとイギリスの類似省庁も、同じ決定によりCloud Foundryプラットホームに標準化している。Cloud Foundryが認定事業を始めたのは数年前だが、昨年は個々のデベロッパーのスキルを認定するための事業を立ち上げた。

政府のワークロードを動かせるためには、そのクラウドプラットホームは一定のセキュリティ要件を満たす必要がある。Cloud Foundry FoundationのCTO Chip Childersによると、18Fがcloud.govのためにFedRAMPの認可でやった仕事が、アップストリームのプロジェクトのより良いコントロールに役立っている。そして彼は、このプラットホームを採用した政府のすべてが、そのすべてのプロジェクトに貢献してきた、と強調した。

〔参考: Cloud Foundry Wikipedia（日本語Wikipedia）〕

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

音声認識とAIで会議のノートを取るVoiceraがモバイルの同業Wrappupを買収

Voiceraは、会議などで人間がノートを取ることを今後永遠に不要にしたいと考えている。同社のビジョンはAIによる音声認識システムが、ノートを取るだけでなく話者を認識し、会議の要点や行動案件を要約できることだ。今日（米国時間4/18）同社は、類似のスタートアップWrappupを買収したことを発表した。ここもAIによるノート取りアプリで、Voiceraのビジョンにぴったり符合している。

Wrappupのチームは直ちにVoiceraに加わる。買収価額などの条件は、公表されていない。

VoiceraのCEO Omar Tawakolも、声明文の中で、相性は良い、と見ている: “問題解決への両社のアプローチには、互いにシナジー効果がある。Wrappupはモバイルファーストで目の前の人が相手だから、会議電話が主体のVoiceraを補完する”。

Wrappupの長所は、モバイルのコンテキストでミーティングの重要箇所を見つけることだ。そのために同社は、新しいモバイルアプリのローンチを発表した。これら二つの企業の協働関係は前からあって、それがやっと今日、オフィシャルになったものと思われる。

写真提供: Voicera

WrappupのCEO Rami Salmanによると、Voiceraとの合体によって顧客にとってより魅力的で強力なソリューションが作られた、という。“両社の技術とAIのアルゴリズムが合わさると、ミーティングの重要箇所をより正確に見つけてまとめることができる。それが、どんな場所であっても”、と彼は声明で述べている。

Voiceraの音声認識ツールはEvaと呼ばれるクラウドサービスだ。それは、ミーティングのノートを取る作業を、人間から取り上げるために設計されている。同社は先月、e.ventures, Battery Ventures, GGV Capital, Greycroftなどの著名VCから、シリーズAで1350万ドルを調達した。同社はまた、GoogleのGVやMicrosoft Ventures, Salesforce Ventures, Workday Venturesなどエンタープライズ系のVCからも注目されており、ミーティングの痛点（ノート取り）に対する同社のソリューションが本物であることを伺わせる。

Wrappupは、2015年にドバイで創業された。これまで80万ドルを調達している。同社の製品は、CitrixのGoToMeeting, CiscoのWebEx, UberConference, Zoomなど既存のミーティングツールと併用できる。

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

アプリケーションにチャット（会話）機能をつけるAPI、Dialogflow Enterprise EditionをGoogle Cloudが一般公開

会話ができるための入出力インタフェイスを作ることは、デベロッパーにとって新しい挑戦分野だ。チャットボットはWebサイトやアプリにおけるトラブルを減らし、会話ができるという構造の中では、企業はよく聞かれる質問に簡単迅速に答えることができる。そこで今日（米国時間4/17)Googleは、これまでベータだったDialogflow Enterprise Editionを一般公開した。

この技術は、2016年におけるAPI.AIの買収の成果だ。Googleは賢明にもツールの名前を変え、それが実際にすることにマッチした名前にした。同社によると、現在すでに、数十万のデベロッパーがこのツールを使って会話のためのインタフェイスを構築している。

これは必ずしもGoogleオンリーのツールではなく、Google AssistantやAmazon Alexa、Facebook Messengerなどの音声インタフェイスでも使えるから、デベロッパーが一度チャットアプリを作ったら、それらを、コードを大幅に変えなくてもさまざまなデバイスで使えるようになる。

さらに今日のリリースでは、機能を増やすとともに、エンタープライズエディションへの移行を容易にした。

GoogleのCloud AIのプロダクトマネージャーDan Aharonが、このツールを発表するブログ記事で、こう述べている: “今日からは、一つのAPI呼び出しで複数のAPI呼び出しが必要になるような、バッチ的な処理ができるようになり、コードの行数を減らして開発時間を短縮できる。Dialogflow API V2は今や、すべての新しいエージェントのデフォルトであり、Google Cloud Speech-to-Textを統合、APIからのエージェントの管理が可能になり、gRPCをサポート、そしてコードのマイグレーション不要でEnterprise Editionに容易に移行できる”。

同社は、Dialogflowを使って顧客のためのチャットインタフェイスを構築した企業の例として、KLM Royal Dutch AirlinesやDomino’s、Ticketmasterなどを挙げた。

この新しいツールは今日（米国時間4/17）から可利用になり、30以上の言語をサポートする。一般公開されたエンタープライズプロダクトには、サポートパッケージとサービスレベルアグリーメント（SLA）がつく。

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

Microsoftが新しいIoTサービスのために独自のLinuxカーネルを作った

今日（米国時間4/16）サンフランシスコで行われた小規模なプレスイベントでMicrosoft は、マイコンを使用するデバイスを対象とする、安全なエンドツーエンドIoTプロダクトのローンチを発表した。それらは、小型で消費電力の少ないマイコン(micro control unit, MCU)を使って最小限のコントロールやネットへの接続を行うデバイスだ。そのようなデバイスは、玩具や家庭用品、産業向けアプリケーションなど、さまざまなところで使われているが、頻繁なアップデートは行われず、セキュリティに不安のあるものが多い。

今回のAzure Sphereと呼ばれるプロダクトは、機能性能等が一定の基準を満たす一連の証明済みのMCUsを対象とする。そしてMicrosoftの法務部門のトップBrad Smithが今日の発表で強調しているのは、チップに対するAzure Sphereの認定ライセンスを無料にして、そのエコシステムの立ち上げに勢いをつける、という点だ。

アップデートや遠隔測定が困難なデバイスはセキュリティも困難だから、まずそれがインターネット接続機能を内蔵していることが重要だ。そしてその接続機能により、Azure Sphereのクラウド上のセキュリティサービスにもアクセスする。

ということは、それらのデバイスではWindowsが動くのだろうか？　いや、違う。Microsoftはこのプロダクトで初めて、独自のLinuxカーネルとディストリビューションを立ち上げる。そのAzure Sphere OSと呼ばれるオペレーティングシステムは、今日のMCUsの多くが使っているリアルタイムオペレーティングシステムの、Microsoft独自のアップデートだ。

Windowsのエンタープライズとセキュリティのためのパートナー担当部長Rob Leffertsは、今日の記者発表でこう述べた: “Azure SphereでMicrosoftはまったく新しい種類のIoTデバイス、すなわちMCUに対応する。Windows IoTはMCUの少なくとも100倍のパワーのあるマイクロプロセッサーユニット(microprocessor units, MPUs)〔通常のCPU〕の上で動くが、Azure Sphere IoT OSに使われているMicrosoftがセキュリティを強化したLinuxカーネルでは、OSSのライセンスのもとにチップレベルのパートナーたちが迅速に新しいイノベーションを実現できる”。

そしてそれらのパートナーたちも、オープンソースのリリースを自分たちの製品に組み込めるので、とても気が楽である。

このプロジェクトで最初にスタートを切るのが。MediaTekの一連のMCU新製品群だ。これらは、低電力消費シングルコアのARM-A7システムで、スピードは500MHz、Wi-Fi接続機能と、そのほかいくつかのI/Oオプションを備える。

オープンなエコシステム、という点では、Smithによると、それらのデバイスはAWSやAlibaba Cloudなど、そのほかのどんなクラウドの上で動くサービスからも使用できる。

実はAmazonのAWSも昨年のre:Inventデベロッパーカンファレンスで類似のプロジェクトを発表している。デバイスが特定のクラウドに縛られず、しかしクラウドサービスと組み合わさってこそ真価を発揮するのだから、これら大手のクラウドプロバイダーたちがMCUsに関心を寄せるのも当然だ。たとえば新しいデバイスの認証や、オペレーティングシステムのアップデート、それらデバイス上で動くソフトウェアの管理、などでAzure以外のクラウドが利用されることを、彼らは期待するだろう。

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

コードレビューサービスの繁盛でPullRequestはシードから数か月後に$8MのシリーズAを調達

オンデマンドのコードレビューをクラウドサービスとして提供しているPullRequestは最近忙しい。でもそれは、どんなスタートアップでも大歓迎するような忙しさだ。昨年8月にY Combinatorを卒業したばかりの同社はまだ、スタートアップの流儀を学んでいる最中だ。12月には230万ドルのシードラウンド を勝ち取り、資金面では安泰なはずだが、今日同社は同社のシードをリードしたシード投資家Google Gradient Venturesが率いるシリーズAによる、さらに800万ドルの資金調達を発表した。

今日発表された投資には、Y Combinator, Fika Ventures, Lynett Capital, Defy Partnersなど、そのほかのシード投資家も参加した。同社はわずか数か月で合計1030万ドルを調達したことになる。

なぜどうして、花の蜜にたかる蝶のように投資家は同社に殺到するのか？　PullRequestは、デベロッパーの大きな痛点を治療する。開発サイクルがはやくなると、真っ先に犠牲になるのが、コードの品質管理だ。同社のファウンダーでCEOのLyal Averyが昨年8月に本誌に語ったところによると、同社はオンデマンド方式でこの問題を解決している。彼は、こう語る:

“われわれは、コードレビューをSaaSとして提供している。デベロッパーがコードをプッシュすると、うちが抱えるオンデマンドのエキスパートたちがそれをレビューする。これによってデベロッパーたちは、負担増となる重いリソースを自分のところで抱えなくても、快調に前進できる。

12月のシードラウンドのときは、Averyはそのプラットホームにオートメーションとインテリジェンス(AI)を導入したい、と言ったが、最近では、今もその方向に向かって進んでいる、という。そこで早期の800万ドルの導入、となる。

今は、大規模なデータリークがあちこちで発生している。Averyも、今後のコードレビューではバグや問題を見つけるだけでなく、フィットネスのUnder Armourなどがやられたようなデータリークの防止にも力を入れなければならない、と言っている（Under Armourの名はたまたまごく最近の例だから挙げたにすぎない）。彼は自明の理由によりクライアントの名は明かさなかったが、最近同社は、コード中に脆弱性を見つけて、リークを未然に防ぐことができた、という。

投資をリードしたGradient Venturesの専務取締役Anna Pattersonは、オンデマンドとコードレビューは強力な組み合わせだ、と見ている。“PullRequestは、良質なコードと仕事の未来が交わるところにいる。AIを使ってコードレビューのアクセス性を良くし、大小を問わずあらゆる企業がコードレビューを気軽に発注できるようにしている”、と彼女は声明文の中で言っている。

コードレビューとバグ追跡は、スタートアップのホットな分野であり続ける。開発サイクルがどんどんはやくなっているから、企業もコードレビューを外注に頼らざるをえない。タイムフレームが長かった昔は、開発のワークフローの中でコードの品質管理をやる余裕があった。しかしタイムフレームはだんだん圧縮され、余裕がなくなり、PullRequestのようなところに頼まざるをえなくなっている。投資家たちは、そこに着目する。

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

FargateによってAWSはコンテナをもっとクラウドネイティブにしたい（Kubernetesなどのインフラを完全抽象化）

AWSのデベロッパーカンファレンスre:Inventは、たくさんの発表があるので、同社自身の重要な新製品の、影が薄くなってしまうこともある。同社の待望のElastic Container Service for Kubernetesはかなり大きく報道されたが、より斬新なコンテナサービスであるFargateのローンチは今もまだ、あまり知られていない。

今週たまたま会う機会があったAmazonのCTOでAWS担当VP（そしてEDMの熱心なファン） Werner Vogelsも、それを認める。彼曰く、“Fargateはそのほかの発表の下に埋もれてしまったようだ。しかしそれは、コンテナをもっとクラウドネイティブにするための重要なステップだと思うし、すでにかなりの数の顧客がFargateを採用している。”

Fargateは、AWSのコンテナサービス、Elastic Container Service(ECS)やElastic Kubernetes Service(EKS)のために、コンテナを動かすためのインフラストラクチャを抽象化する技術だ。ユーザーはコンテナオーケストレーションエンジンを指定するだけで、あとのことはこのサービスがやってくれる。個々のサーバーやクラスターをユーザーが管理する必要はない。むしろユーザーは単純に、ECSやEKSに、Fargateでコンテナをローンチすると告げ、そのアプリケーションのCPUとメモリの要求を定義し、あとはサービスにまかせる。

Fargateに関する長いブログ記事を今日（米国時間4/11）発表したVogelsにとってこのサービスは、デベロッパーが、インフラを気にせずに自分のアプリケーションだけに集中できるようにするというAWSのミッションの一環だ。彼曰く“クラウドの初期のころを、よく思い出す。AWSが登場するまでは、クラウドから仮想マシンを提供するサービスしかなかったんだ。多くの企業がそれを利用してビジネスを築き成功させてきたが、でも仮想マシンを動かすときには、依然としてハードウェアを管理しなければならない。[…] われわれがAWSのクラウドコンピューティングサービスの中核であるECSをかつて導入したときに起きたことの一つは、いろんなものをハードウェアから切り離してしまったことだ。[…]それによってデベロッパーの生産性は、ものすごく上がったと思うね”。

しかしAWSやECSの上でコンテナを動かそうとすると、初期のコンテナツールでは、コンテナを実際に動かすこととは無関係な多くのことを、やらなければならなかった。“それは、クラウドの初期と同じだ”、とVogelsは語る。“仮想マシンがコンテナにとってのハードウェアになってしまっている。デベロッパーはコンテナのオーケストレーションのために、VMを相手に大量の作業をしなければならない”。

しかしAmazonの顧客が求めるのは単純に自分のコンテナを動かすことだけだ。Vogelsの言う“ハードウェアに直接触（さわ）るような管理作業”なんか、やりたくない。“それはまるで、クラウド以前の時代に戻ったみたいだ”、とVogelsは述べ、そして今日のブログ記事では、“コンテナのオーケストレーションは、あまりクラウドネイティブではない、といつも感じていた”、と言っている。

Vogelsは、インフラストラクチャを気にしなければならないならそれはクラウドネイティブではない、と考えているようだ。彼によると、AWSの最初の約束は、インフラストラクチャに関してはAWSが面倒見るからデベロッパーはビジネスにとって重要なことだけに専念すればよい、というものだった。その哲学をさらに徹底したサービスがFargateであり、Lambdaだろう。

ECSやEKSのようなクラウドサービスがあっても、クラスターはまだ完全に自動的に動くわけではなくて、つねに必要とはしない能力や容量でも、ユーザー自身が確保（プロビジョニング）しなければならない。Fargateの約束は、そのようなスケーリングを自動化し、ユーザーは実際に必要とする能力と容量だけに支払えばよい、という状態にすることだ。

Vogelsはこう言う: “顧客は、ソフトウェアを作りたいだけだし、自分のアプリケーションを作りたいだけだ。このコンテナをどの仮想マシンに置くか、なんてことで悩みたくはない。でも今は、デベロッパーがそれをやっている。Fargateがあれば、ユーザーはタスクに対するCPUのタイプを指定するだけで、スケーリングは自動的に行われる。実際に使う能力容量に対してだけ、支払えばよいのだ”。

インフラの抽象化という点では、Fargateはコンテナのためにそれをやるのだが、AWS Lambdaのようなプロダクトはもっと徹底している。それは Vogelsにとってはひとつの連続体であり、顧客の要望が生んだものだ。今のAWSはコンテナをきわめて重視しているが、彼の現実的な見方によれば、近未来がコンテナ一色に塗りつぶされてしまうわけではなくて、VMを必要とする開発ニーズも残る、VMはなくならない、という。

Lambdaのようなサーバーレスのプロダクトでは、インフラストラクチャのことをまったく考える必要がない。コンテナのことすらも。ユーザーはただ単に、やりたい処理を指定するだけだ。そしてそのコードの実行に対して支払う。しかもVogelsの視界の中では、VMとコンテナとサーバーレスは一つの連続体の各部だ。顧客は、そのどれからどれへ移行してもよい。彼によると、今ではコンテナを完全に飛び越えて、何もかもサーバーレスで行くエンタープライズも見かけるようになった、という。

〔関連記事: 昨年のre:InventにおけるFargateの発表〕

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

中小企業の多様なApple製品の利用を自動化クラウドサービスで管理するFleetsmithが$7.7Mを調達

企業がAppleのデバイスを容易に管理できるようにするサービスFleetsmithが今日（米国時間4/10）、Upfront VenturesのリードによるシリーズA、770万ドルの資金調達を発表した。

シード投資家のIndex VenturesとHarrison Metalも、このラウンドに参加した。これで同社の調達総額は1100万ドルになる。同社はさらに、Puppetのファウンダーで元CEOのLuke Kaniesが同社の顧問団に加わったことを発表した。

Fleetsmithは、中小企業によるAppleデバイスのデプロイと管理を助ける。デバイスは、コンピューター、スマートフォン、iPad、Apple TVなど、さまざまだ。これらのデバイスを手作業で全社内的にデプロイすることは時間のかかる作業になり、大企業ではそれをとっくに、そのほかの商用オプションや内製のソリューションに任せている。Fleetsmithは、そのような効率的なデバイス管理をクラウドサービスとして提供することにより、中小企業でも利用できるようにした。

協同ファウンダーのZack BlumとJesse EndahlはそれぞれDropboxとFandomの出身だが、二人とも前の会社ではAppleデバイスの購買と社内デプロイを含む職務を担当していた。そして、そのための中小企業向けの良い方法が市場に存在しないことを、痛感していた。

“Macの編隊をデプロイしてそのセキュリティをインターネットから管理するには、どうしたらいいのか？　そのソリューションを、作るか買うかの検討から、やるべきことがまだ多く残されていることを知った。GoogleやFacebookにはすでに内製のMac管理ツールがあるが、それらのツールの民主化にわれわれは挑戦した”、とCEOのBlumは語る。

Fleetsmithのデバイス管理コンソール。写真提供: Fleetsmith

同社は、AppleがApple製品のプロビジョニングを容易にできるために提供しているデバイス管理サービスDevice Enrollment Program(DEP)を利用することにした。顧客企業のIT管理者がDEPの登録ユーザーなら、Fleetsmithを使って人力不使用のデプロイができる、とBlumは説明する。すると社員はラップトップなどどんなデバイスでもオーダーできるようになり、Wi-Fiに接続したらFleetsmithに接続し、デバイスの構成が自動的に行われる。

Blumは曰く、“EDPのいいところは、それをうちのサービスと統合すると、社員がWi-Fiに接続した途端に、デプロイのお世話をすることだ。アカウントが作られ、ソフトウェアがインストールされ、ドライブは暗号化される。新しい社員をインストールし登録する作業が、とても簡単だ”。そうやって必要なものすべてのセットアップが完了すると、アドミンは重要なアップデートを強制できるようになるが、ただしアップデートをする前にはシステムがいくつかの警告をくれる。

新たに同社の顧問になったKaniesは、声明でこう言っている: “Fleetsmithは、完全なオートメーションだ。細かい作業をすべてコンピューターにやらせて、人間はトラブル対策よりも本来の仕事に専念できるようになる。中小企業には人がいないし、冗長性のための余分のコンピューターもないから、このことがとくに重要だ”。

このクラウドサービスのアクセス料金はデバイス1台あたり年間99ドルだ。フリーミアムなので、デバイス10台までは無料で利用できる。同社は2016年に創業され、現在20名の社員がいる。顧客は、HackerOne, Robinhood, Nunaなどだ。

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

GitLabがGoogleのKubernetes Engineを統合、コンテナアプリケーションのデプロイが超簡単に

今や多くの人が使っているVCSのGitを、独自にホストしているサービスとして人気の高いGitLabが、最近とくに好調だ。わずか2週間前にはGitHubとの統合を発表したが、今日はGoogleのKubernetes Engine(GKE)を統合してクラスターの展開を自動化し、ユーザーであるデベロッパーが自分のアプリケーションをほんの数クリックでデプロイできるようにした。

この機能を作るために同社はGoogleと協働したが、しかしこの統合はGitLabに前からあるAuto DevOpsツールを大々的に使っている。それは、コンテナを扱うためのよく似た機能をすでに提供していた。Auto DevOpsは、CI/CDパイプラインのセットアップやコンテナへのデプロイなど、面倒な仕事をすべて引き受けることをねらっている。

しかし、“GKEを統合する前は、GitLabのユーザーは自分のクラスターを管理するためにKubernetesの深い理解を必要とした”、とGitLabのCEO Sid Sijbrandijは今日の発表で述べている。“Googleとの協働により、われわれのユーザーはGoogle Cloud Platform上に、管理サービスを伴うデプロイ環境をセットアップし、GitLabの堅牢なAuto DevOpsの能力を利用することが簡単になった”。

このGKEの統合を利用するためには、デベロッパーはGitLabから自分のGoogleアカウントに入るだけだ。GKEがクラスターを自動的に管理するので、デベロッパーは自分のアプリケーションを書くことに集中でき、デプロイと管理はGitLabとGoogleにまかせられる。

この新しい機能はGitLab 10.6 releaseの一部として、GitLabの全ユーザーが今すでに利用できる。

GitLab adds support for GitHub

〔この記事の日本語訳。〕

 

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

Google Cloudがユーザーのネットワークを最適化できるための詳細分析情報を提供

Google Cloudが今日（米国時間4/5）ローンチする新しい機能でユーザーは、Google Cloud上のユーザーのサーバー群とGoogleのそのほかのサービスやオンプレミスのデプロイメント、そしてそのほかのありとあらゆるインターネットのエンドポイントとの間のデータフローをモニタし、最適化できる。名前が示すように、そのVPC Flow Logsと呼ばれる機能は、GoogleのVirtual Private Cloud機能(仮想プライベートクラウド, VPC)を使って自分たちのリソースを他のユーザーから隔離している企業が利用する。

VPC Flow Logsは、VPC内の仮想マシンが送受するすべてのネットワークフロー（UDPとTCPの両方）をモニタしログする。それには、Google Cloudの複数のリージョン間のトラフィックも含まれる。そのデータをGoogle Cloudに保存したければ、すべてのデータをStackdriver LoggingやBigQueryへエクスポートできる。後述のように、そのほかのリアルタイムアナリティクスやセキュリティプラットホームにエクスポートするには、Cloud Pub/Subを使える。データは5秒おきにアップデートされるが、このサービスの利用がユーザーがデプロイしているアプリケーションのパフォーマンスに影響を与えないことを、Googleは約束している。

今日の発表におけるGoogleの注記によると、これによりネットワークの運用者はGoogleのネットワークのパフォーマンスを詳細に知ることができ、ネットワークのトラブルシューティングも可能になる。またユーザーのグローバルなトラフィックに関するさまざまな情報が得られるので、ネットワークの使い方や費用を最適化できるようになる。

そのデータはすべて、不審者がユーザーのネットワークに入り込んでいたときなどの捜査にも役に立つ。ただしそのためには、データを、SplunkやArcSightのようなセキュリティ情報とイベント管理(security information and event management, SIEM)の専門企業へエクスポートした方がよいだろう。

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

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）