タグ: compute engine

Google Cloudでリソースの容量能力を予約でき確約利用割引の対象を拡大

Google Cloudが2つの重要な料金改定を行った。ただし残念ながらそれは、よくあるコンピュートとストレージの値下げではなくて、最初のは確約利用割引の拡大だ。GPUsや、Cloud TPU Pods、ローカルSSDなどを一定量、1〜3年契約で利用しているユーザーは、その長期的ロックインの代償として料金がオンデマンド料金の55%引きになる。

もうひとつはCompute Engineの（VMの）容量予約システムで、ユーザーが特定のゾーンにリソースを予約しておくと、あとで本当に必要になったときに確実にそれを使える。

一見すると、容量予約はクラウドらしくないコンセプトだ。なぜならリソースの縮小拡大はランタイムに必要に応じて自動的に為されるはずであり、その可用性をユーザーがいちいち気にするするべきものではない。

では一体、予約システムは何のためにあるのか？Googleの上級プロダクトマネージャーであるManish Dalwadi氏はこう語る。「想定ユースケースは災害復旧やそんなときのための安心感だが、ブラックフライデーやサイバーマンデーのような一時的で特殊な特売イベントのサポートも対象になる」。

つまり、その日には絶対的に必要なリソースが確実に利用できる、ということ。Googleのようなクラウドサービスの大手なら仮想マシンはいくらでもある、と思いがちだが、しかし一部のマシンタイプは特定の可用性ゾーンでないと使えないこともある。仮想マシンというリソースは、その点がその他のリソースとは異なる。

ユーザーは予約をいつでも作ったり取り消したりできるし、既存の割引が自動的に適用される（継続利用割引と確約利用割引）。

確約利用割引に関しては、かなりの柔軟性がある。たとえばユーザーは特定のマシンタイプを3年確約するのではなくて、CPUコアやメモリーなどの数量を確約すればいい。

GoogleのプロダクトディレクターPaul Nash氏は「顧客たちからよく聞くのは、他社の確約モデルには柔軟性がないことと、利用率が60%、70%ととても低いことだ。だからうちの確約割引の設計目標は、自分たちの容量計画を参考にして、ユーザーに十分なお得感があるような割引率にした。気楽に利用できて厳密な管理が要らないことも、目標とした」と説明する。

確約利用割引の拡大と、新たなCompute Engineの容量予約システムは、どちらもGoogle Cloud上ですでに利用できる。

[原文へ]

（翻訳：iwatani、a.k.a. hiwa）

GoogleがCompute Engineにオートスケーリングを提供

Googleのクラウドコンピューティングプラットホームはいつも増築工事が行われているが、今日発表されたのは、同社のIaaS Compute Engineのオートスケーリングサービスだ。今それは、ベータで提供されている。

この新しい機能によりCompute Engineでは、処理量の需要に応じて新しいマシンが自動的に動きだす。たとえば、ユーザのCPU利用が一定の値を超えたり、HTTPのロードバランサが入信トラフィックにスパイクを検出したら、新しいマシンをスタートさせてその負荷を分散できる。このオートスケーラをGoogleのCloud Monitoring APIからトリガさせて、アプリケーション固有の何らかの値をスケールアップの契機としてもよい。ユーザにとってのメリットは、万一の用意のために当面使わないマシンを手当しておかなくてもよい、ということ。必要時には自動的に動きだすから、無駄な経費が生じない。

同社は今月初めに行われたCloud Liveイベントでこの機能を予告していた。ただし、いつから供用開始か、が不明だった。しかしそのイベントの席でGoogleは、システムが毎秒150万リクエストぐらいになっても十分対応できることを示した。

オートスケーリングはAmazonのAWSには2009年からある（Amazonは”auto scaling”、Googleは”autoscaling”）。Microsoft AzureのWebサイトやクラウドサービスや仮想マシンのオートスケーリング（auto-scaling)は昨年6月からある。しかしこれまでGoogleはユーザに、App Engineのサービスを利用してCompute Engineのアプリケーションのスケーリングとオーケストレイションを自動化することを、推奨していた。そのやり方は有効だったが、今後は単純にオートスケーラの2〜3の設定をするだけのことに比べると、面倒でエラーになりがちだった。

Googleにしては、この機能の提供に手間取りすぎた、と言えるだろう。

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


クラスタ管理を抽象化して簡易にするMesosphereがGoogleのクラウドプラットホームにも対応、DockerツールKubernetesを統合

GoogleとMesosphereが今日（米国時間8/18）、両社のパートナーシップにより、GoogleのCompute EngineプラットホームにMesosクラスタのサポートを導入する、と発表した。MesosプロジェクトとMesosphereはまだよく見かける名前ではないが、アプリケーションのスケーリング（ニーズに応じての規模拡大）で余計な苦労をしたくないと考える企業にとって、このところ急速に、重要なツールになりつつある。それらのアプリケーションの所在は、完全に自社のみのデータセンターの場合もあれば、パブリックなクラウドサービスの場合、あるいはパブリック/プライベートのハイブリッドの場合など、さまざまである。〔*: Mesosphere関連日本語訳記事（１）、（２）。Mesosの’os’はOS(オペレーティングシステム)の意味…クラスタ群を一台のコンピュータへと抽象化する。〕

今度の提携によりGoogleのCloud Platformのユーザは、MesosphereのクラスタをGoogleのサーバ上に10分足らずでセットアップできるようになる。その基本的なインストールには二つの形があり、デベロッパはそのどちらかを選ぶ: 1)4インスタンスの開発用クラスタでアプリケーションのプロトタイピング用に8つの仮想CPUと30GBのメモリを提供、2)プロダクション用インストールで18インスタンス36仮想CPUメモリ136GB。この二つのオプションで不満な場合は独自のカスタムクラスタを作れる。

これらのクラスタにはデフォルトでMesosカーネル、Zookeeper、Marathon、およびOpenVPNが含まれる。クラスタの使用を開始するとMesosphereは、クラスタを管理するためのWeb上のわかりやすいダッシュボードを管理者に提供し、それにはGoogleのダッシュボードからアクセスできる。

MesosphereのCEO Florian Leibertによると、Mesosphereの中心的なねらいは、デベロッパがデータセンターをつねに一台のコンピュータのように扱えることだ。そのためにMesosなどのソフトウェアパッケージがDevOpsの主な仕事のほとんどを抽象化する。Leibertは以前TwitterやAirbnbの社員で今やそのTwitterもAirbnbもMesosのユーザだが、両社にオープンソースプロジェクトMesosを紹介したのはLeibert自身だ。

ユーザのハードウェアは実際には複数のハードウェアや仮想マシンやクラウドのインスタンスなどから成るが、Mesosphereという一枚の層がその上にかぶさるとアプリケーションは、多くのCPUやメモリをかかえた単一のリソースプールを使っている、という外見になる。デフォルトではMesosphereのサービスは、ユーザが使っているオペレーティングシステムやクラウドが何であるかを、まったく関知しない（どうでもよい）。ただし今回のGoogleとの提携にあたっては、Googleのクラウドに対しての最適化を図った。Mesosphereの詳細なドキュメンテーションは、ここにある。

Googleとのパートナーシップの中には、Dockerのコンテナを管理するGoogleのオープンソースのサービスKubernetesをMesopshereに統合することも含まれる。同社によるとこれによって、Dockerのワークロードの展開管理がより容易になる。ただしMesopshereのKubernetes統合は、対象がGoogleのCloud Platformに限定されない。Leibertは今日の発表声明の中で、“われわれが織り上げたコンピューティングの織物は、GoogleのCloud Platformだけでなく、そのほか、ユーザ自身のデータセンターやそのほかのクラウドプロバイダでも使用できる”、と言っている。〔Kubernetes関連日本語訳記事（１）、（２）。〕

GoogleでKubernetesなどの次世代クラウドコンピューティングプロダクトを担当しているリードプロダクトマネージャCraig McLuckieによると、GoogleがKubernetesでやりたいことは、Googleが自社のデータセンターを管理するために開発してきた重要なコンセプトの多くを、同社の外部でも利用できるようにすることだ。彼は今回のMesosphereとGoogleの協働関係を、“きわめて相補的である”*と呼び、それら重要コンセプトの一部はMesosにも持ち込まれるだろう、と考えている。〔*: complementary, お互いの足りないところに互いにピッタリとはまり込んで補う、完璧な結婚。〕

MesosphereのシニアVP Matt Trifiro（元HerokuのCMO）によると、KubernetesやMesosのようなプロジェクトは、これらの技術の背後にある非常に高尚な思想を、万人が共有するものにする。現状では、“Webをスケールしなければならないというニーズを抱える企業にとって、ツールが十分にアクセス可能でなかった”。しかし今では、GoogleやMesosの高度なコンセプトとツールを企業も利用できるようになり、デベロッパやDevOps たちは一段高い抽象性のレベルで仕事ができるようになり、アプリケーションを動かしているインフラの具体的な細部を、直接いじらなくてもよくなっている。

Leibertは今日、こう書いている: “Googleと協働することによってGoogleのCloud Platformを、従来からのMesosphereのワークロード、たとえばMarathon、Chronos、Hadoop、Spark、そして新たにKubernetesなどを使用するための最良の場所にしていきたい”。

この協働プロジェクトでは両社の関係がきわめて密だから、いずれGoogleがMesosphereを買収することもありえるかもしれない。現状ではそれは、あくまでも憶測だが、でも実際にそうなったら、その起源がこれだったことを、思い出そう。

 

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


Dartプログラミング言語をGoogleのApp Engineがサポート…ついにサーバ言語としても位置づけ

デベロッパカンファレンスGoogle I/Oが始まる数日前に実はGoogleは、同社のApp EngineがDartプログラミング言語をサポートする、と発表していた。

言語のこの実装は、同社が最近ローンチしたマネージドバーチャルマシン（管理を伴う仮想マシン）と、そのサービスがサポートするカスタムランタイムを使用する。ただしカスタムランタイムはまだ非公開ベータなので、Dartのサーバサポートもまだ一般公開はできない。でもGoogleはI/Oの席で、Dartデベロッパたちに、ささやかな プレビューを行った。

デベロッパたちの多くは、DartはJavaScriptと競合する言語だ、と見ている。たしかにGoogleがねらっていたユースケースはJavaScriptと同じWebスクリプティング言語だし、同社のChromeブラウザにはDartをサポートしているバージョンもある。GoogleはDartをJavaScriptに翻訳するコンパイラをはじめ、Dart関連の豊富なツールも提供している。でも、今度そのランタイムをApp Engineに持ち込んだということは、GoogleがDartに関して抱いている視野がもっと大きいことを、うかがわせる（単なるWebクライアント言語ではない）。

今回は、Dartを作った二人のデンマーク人Lars BakとKasper Lundに会って、Dartの現状と未来について、話を聞いた。なお、BakはGoogleのJavaScriptエンジンV8の作者でもある。

彼らによると、最初DartはJavaScriptの代替言語(better JavaScript)ではなく、あくまでも汎用のプログラミング言語を目指して開発に取り組んだ。目的は型付けが動的に行われる言語で、デベロッパがすぐに使い始められること、そしてデベロッパの生産性を高めるような言語だ。

そのため二人は、単に言語だけでなく、専用のエディタDart EditorやDart用IDE、大量のライブラリなど、デベロッパの生産性を支えるツールも並行して作っていった。最近ではDartのサポートを内蔵しているAndroid用のChromeブラウザまで作った。またDart Editorにも、デベロッパがプログラムをランタイムにモニタできるためのいろんなツールが伴っている。I/Oで二人は、Dartと、GoogleのWebコンポーネントプロジェクトPolymer、および新しいユーザインタフェイスデザイン言語Material Designを合わせた開発が容易にできることを、実例で示した。

GoogleはI/Oで、デベロッパがCompute Engineの上で、Dockerを使用してDartを展開できることと、Googleのクラウドモニタリング/キャッシングサービスData Storeにも容易にアクセスできることを発表した。

しかしデベロッパたちは、Dartをサポートした特殊なバージョンのChromeではなく、ふつうのChromeがふつうに最初からDartをサポートすることを望んでいる。Bakにこの点を尋ねると、彼は微笑みながら、それももうすぐ発表すると述べた。Chromeが標準的にサポートすれば、Dartはメジャーの位置に近づくだろう。もちろん、Dart-to-JavaScriptコンパイラを経由するよりはDart VM直接の方がコードの実行もずっと速い。いったんサポートしたら今後下ろされることはないだろうから、デベロッパにとってもDartを採用する大きなインセンティブになる。

今後の予定としてBakたちは、 JavaScriptのasyn/awaitのような非同期処理をDartに実装することを考えている。

二人はDart 1.0をリリースしたあと、DartのEcma標準規格の作成にも取り組んだ。JavaScriptも今では、EcmaScriptの規格に準拠している。Bakによると、良いプログラミング言語が委員会によって作られることはないので、Dartも完成した実装(v. 1.0)をまず自分たちで作ることが重要だった。そしてそのあとで、業界全体の標準言語として広めていきたい。そうすれば、ほかのブラウザもDartをデフォルトでサポートするようになるだろう、と二人は期待している。

Dartは汎用言語でもあるので、フロントエンドとバックエンドの両方を同じ言語で書ける。したがってより安定性の良いコードが書けるし、デベロッパチームによるコラボレーション的な開発もより容易にできる、と二人は信じている。

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


GoogleのApp EngineもDockerをサポート、オープンソースのコンテナ管理ツールを提供

Dockerは今や明らかにデベロッパコミュニティの大スターであり、Googleも当然、真剣に対応している。 今年はCompute EngineにDockerの基本的なサポートを加えたが、さらに今日（米国時間6/10）は、App EngineもDockerに対応する、と発表した。そしてそのためには、最近ローンチしたユーザ管理型仮想マシン(Managed VMs)を活用する。

またデベロッパによるDockerの利用を支援するために、Googleは今日、コンテナ管理ツールKubernetesをローンチする。さらにGoogleがDockerのコミュニティに本格的に参加するために、同社のインフラ担当VP Eric BrewerをDocker Governance Committeeにノミネートし、 “コミュニティと協力してコンテナのさらに良いオープンスタンダード構築に貢献していきたい”、との意思表示をした。

コンテナはGoogleにとって新しいものではない。同社はこれまで長年にわたって、大規模なデータセンターを管理するために内製のコンテナを使ってきた。今や同社は毎週、同社のデータセンター全体で20億あまりのコンテナをローンチしている。

GoogleのクラウドサービスプロダクトにおけるDockerの導入を推進してきた、プロダクトマネージャのCraig McLuckieは、Dockerのサポートは同社にとって当然なことだ、と言う。従来型のホスティングでは、新しいボックスを加えることが毎回、大仕事だった。しかし最近のアプリケーションは多くの小さなサービスの集合体であることが多いので、コンテナがうってつけの世界だ。だからMcLuckieは、“コンテナはうちにものすごく大量の価値をもたらす”、と言う。“多くのデベロッパにとってDockerは、大きな便宜を提供してくれるのだ”。

デベロッパがDockerをApp Engineで使うと、既存のDockerイメージの大きなライブラリにアクセスでき、またGoogleのストレージサービスを利用して自分のものを持ち込むこともできる。DockerイメージはManaged VMsに展開でき、するとデベロッパはGoogleのPaaSにない各種のサービスをApp Engineで動かせるので、多大な柔軟性 （自由度）が得られる。

またデベロッパが自分のApp Engineアプリケーションをパッケージして、それらからDockerイメージを作る作業を、ものすごく楽にしていきたい、と McLuckieは言っている。

App EngineにおけるDockerのサポートはまだベータだが、デベロッパはここでユーザ登録をして利用できる。

Dockerを使う場合、コンテナの管理やスケジューリングはユーザの責任だが、今ではそれらを支援するKubernetesのようなサードパーティツールがいろいろある。Kubernetesはギリシア語で“船の操舵手”という意味で、マシンの“艦隊”へのコンテナの展開を助けるオープンソースのコンテナマネージャだ。マシンを互いに連携させる機能のほかに、健康管理やレプリケーションの機能もある。なお、このコンテナマネージャはGoogleのサービスに縛られることなく、いろんなプラットホーム上のコンテナを一元管理できる。

Google自身はコンテナシステムとしてOmegaを使っており、Kubernetesも同社のデータセンターの運用にために作ったツールだが、今回はそれをDocker用にまったく新たに書き起こした。Googleが社内で使っているものよりもずっと、デベロッパフレンドリになっているそうだ。スタートアップ企業には、GoogleにあるようなDevOpsのチームがない場合が多いから、その点にも配慮している。

McLuckieによると、Kubernetesには多数のデベロッパが使えるという利点があり、ということは管理するコンテナ群が広範なデベロッパ集合にまたがっていてもよい、という意味だ。そのコードは、GitHubで入手できる。

〔関連記事（日本語訳）〕

 

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


Googleのクラウド・コンピューティングとクラウド・ストレージの新料金表

今日（米国時間3/25）サンフランシスコで開催されたGoogleのクラウドプラットフォーム・イベントで、ほとんどすべてのクラウド・サービスの料金の大幅値下げが発表された。また料金体系の簡素化や自動的に適用される長期利用割引などの新しいシステムも導入された。

Google Compute Engineは上の表のように、すべてのサイズ、リージョン、クラスで32%料金が引き下げられた。App Engineの料金も30%引き下げられ、料金体系の簡素化が図られた。

クラウド・ストレージの料金は68%値下げされて1GBあたり月額0.026ドル、DRAストレージの場合は1GBあたり0.02ドルとなった。Googleによれば、この料金は4500TBを専有するユーザーに適用されたいた大口割引よりもさらに安いという。

今日はクラウドSQLやクラウドDBなど、他のクラウド・ストレージの料金についての値下げ発表はなかったが、おそらく近日中にこれらも値下げされるか、あるいは今回値下げされたストレージに統一されるだろう。

長期利用割引を考慮に入れなくても新料金は多くのライバルより安い。予約インスタンスなど一部ではAmazonのEC2の料金をも下回るものとなった。

【中略】

これまでGoogle、Amazon、Microsoftは互いに相手の動向をうかがってクラウドサービスの料金を決めてきた。Googleの大幅値下げ攻勢で、これらライバルも値下げに動くことになるだろう。Amazonは今週サンフランシスコでAWS Summitカンファレンスを開催するが、どういう発表があるか注目だ。

[原文へ]

（翻訳：滑川海彦　Facebook Google+）


GoogleのCompute Engineが一般公開へ: インスタンス料金下げ, 16コアインスタンス登場, Dockerをサポート

Googleが今日（米国時間12/2）、2012年の夏にローンチしたクラウドコンピューティングプラットホームGoogle Compute Engineの一般公開を発表した。今日の一般公開とあわせて、1)新しいオペレーティングシステムのサポートと、2)標準インスタンスの10%値下げ、3)大量の計算力を必要とするアプリケーションのための16コアインスタンス、そして4)新しいロゴも発表された。

Googleには、検索エンジンをはじめとする各種自社サービスを動かすための巨大なインフラがあり、Compute Engineはその力を外部にも利用させるためのクラウドプラットホームである。これには同社の24/7のサポートが提供され、そのSLAでは99.95%のアップタイムが約束されている。

標準インスタンスの10%値下げに加えて、パーシステントディスクストレージの料金は60%値下げされ、それらのI/O課金も“あなたのブロックストレージデバイスが予定の範囲内の低料金に収まるように”値下げされる。同社の最大のパーシステントディスクボリュームは、そのI/Oの能力がこれまでの700%に向上した。

これまでCompute Engineは、DebianとCentOSを、Googleが独自にカスタマイズしビルドしたカーネルによりサポートしていたが、今日からデベロッパは、SELinuxやCoreOSをはじめ、任意のLinuxディストリビューションを使える。CoreOSはY Combinator出身のスタートアップが作った、Googleのクラウドインフラストラクチャの構造や振る舞いを真似るOSである。そのほか、SUSE、FreeBSD、Red Hat Enterprise Linuxなどの公式サポートも発表されている（Red Hat ELのサポートの現状は制限つきプレビューの段階だ）。

今回のアップデートの一貫として、好評な仮想アプリケーションコンテナDockerのサポートが提供される〔関連記事〕。Dockerがあると、デベロッパはアプリケーションのビルドやテストを自分のラップトップで行って、本格展開のためにはこのコンテナをサーバに載せるだけでよい。Dockerは先月より、オープンソースのプロジェクトとして提供されている。

Dockerは、CoreOSとの相性も良い。これは、Cloudkickを作ってその後Rackspaceに売ったAlex Polviが始めたプロジェクトで、CoreOSはDockerと一体的にパッケージされているから、アプリケーションをいろんなサービス間で移動するのも簡単だ。クラウドサービスを利用するデベロッパも、単一のベンダにロックインされずにすむのである。

Compute Engineが提供する最大のインスタンスタイプは、これまで8コアだったが、これからは三種類の16コアインスタンスタイプが提供される。Googleは、“大規模高密度LSIのシミュレーションや、大規模なNoSQLデータベースの運用などに利用していただきたい”、と言っている。

インスタンスタイプの多様性ではまだAmazonにはかなわないが、今日のローンチにより最大コアタイプでは並んだことになるので、そのほかの条件次第ではAmazonのEC2プラットホームからの移行も期待できるかもしれない。ただし、グラフィクス集約的なアプリケーションのためにAmazonがごく最近導入したGPUインスタンスは、まだGoogle Compute Engineにはない。

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


Google Compute Engineが月額400ドル24/7電話サポート付きの利用形態をローンチ

昨年のGoogleのデベロッパカンファレンスI/Oで、Compute Engineがローンチされた。それはクラウドコンピューティングのプラットホームで、デベロッパはGoogleの大規模なインフラストラクチャの上でホストされているLinuxの仮想マシン上で、自分のアプリケーションを稼働できる。しかしこれまでは制約のあるローンチで、デベロッパは招待されるかまたはGoogleの営業からアクセス許可をもらわないと、利用できなかった。

しかし今日からは、月額400ドル払ってGold Supportの会員になると24/7の電話サポートが利用でき、招待も営業へのコンタクトも不要でCompute Engineにアクセスできる。

新しい料金体系

この有料サポート付きパッケージは、Compute Engineを利用する権限を与えるだけだ。アプリケーションがGoogleのインフラを利用するときには、それなりの料金が発生する。ただし今日の発表とともにGoogleは、その料金を4%引き下げた（11月にはストレージの料金を20%下げた）。新しい料金体系では、最小の仮想マシンが1時間0.132ドル（13.2セント）で、現在の最高の料金は8コアのマシン、52GBのメモリ、1770GBのハードドライブ2基という構成で1時間1.211ドル（1ドル21.1セント）だ（ヨーロッパではこれよりやや高くなる）。

新しい機能

Compute Engineの機能とインスタンスタイプも増えた。たとえば、各インスタンスタイプにはディスクレスのバージョンがある。管理コンソールも改良され、これからはルートファイルシステムとしてマウントされた永続性のディスクからブートできる。ヨーロッパのゾーンが二つ増え、それにより“ヨーロッパの顧客に低レイテンシと高パフォーマンスを提供できる”という。新機能の詳細は、このページにある。

Googleのインフラは大きくて潤沢だから、そのCompute EngineはクラウドコンピューティングにおけるAmazonの強敵になるかもしれないが、しかし現状ではAmazonの幅広いサービス構成にGoogleは追いついていない。数週間後に迫っている今年のI/OでもCompute Engineについて何か発表があるかもしれないが、月額400ドルのサポートパッケージに続いて今度は無料の最小構成が出てくるのなら、まあ当然と思うだろうね。

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