Google Cloud Japan 公式ブログ: 1月 2015

[GCP] VMware が Google Cloud Platform の提供を開始します。

2015年1月30日金曜日

* この投稿は、米国時間 1月 29 日、Google for Work, Global Partner Strategy & Alliances の Managing Director, Murali Sitaram によって投稿されたものの抄訳です。

世界中の多くのビジネスが、VMware のデータセンター仮想化ソリューションを利用してインフラストラクチャーの仮想化とデータセンターの最適化を行っています。そして本日、VMware のハイブリッドクラウドプラットフォームである vCloud Air を通じて、VMware のお客様へ Google Cloud Platformサービスを提供開始することを発表しました。ビジネスにおいて、総合的なインフラストラクチャーを考える際、柔軟性は重要なポイントです。本日の発表で、VMware のデータセンター仮想化ソリューションをご利用の皆様が、Google Cloud Platform を簡単に統合できるようになります。

それにより、Google BigQuery や Google Cloud Storage といった Google Cloud Platform のツールやサービスを利用し、よりスケールし、生産性と機能性を向上することができます。VMware のお客様は、Google のパブリッククラウドが提供するセキュリティ機能、スケーラビリティ、そしてコストパフォーマンスといったメリットを受けていただけます。利用されるインフラストラクチャーは、10 億もの検索結果をミリ秒で返したり、60 億時間/月の YouTube ビデオをホストしたり、また 4 億 2500 万の Gmail ユーザーへのストレージを提供しているものと同じインフラストラクチャーです。

Google BigQuery, Google Cloud Datastore, Google Cloud Storage や Google Cloud DNS は VMware vCloud Air から直接利用可能となり、ひとつの購買およびサポート経路から vCloud Air と Google Cloud Platform の両方をご利用いただけます。

vCloud Air のお客様は、既存のサービス契約およびネットワークインターコネクトから Google Cloud Platform を利用でき、Google Cloud Platform サービスは利用した分だけの課金でご利用できます。
VMware vCloud Air の利用規約内で Google Cloud Platform を利用でき、VMware のグローバルサポートサービス (GSS) チームのサポートを受けることができます。
HIPAA への準拠が必要な米国の企業は、VMware’s Business Associate Agreement (BAA) で特定の Google Cloud Platform のサービスをカバーできます。

VMware からの Google Cloud Platform サービス提供は、今年中に開始の予定です。さらに、vRealize Cloud Management Suite （VMware のハイブリッドクラウドマネジメントツール）へ Google Cloud Platform を展開する可能性も検討しています。

本日のアナウンスは、Chromebook や Kubernetes オープンソースプロジェクトから続く我々の連携とお客様への価値提供を強化します。VMware のお客様に Google Cloud Platform サービスを提供できることを楽しみにしています。

-Posted by Murali Sitaram, Managing Director, Global Partner Strategy & Alliances, Google for Work

[GCP] コンテナ、Kubernetes、最新のクラウドコンピューティングの動向

2015年1月29日木曜日

* この投稿は、米国時間 1月 9 日、Google Cloud Platform’s Global Head of Solutions, Miles Ward によって投稿されたものの抄訳です。
これからの数週間はコンテナ技術に関する私たちの見解についてお伝えし、 10 年以上にわたって Google のサービスをコンテナで運用していく中で得た経験を共有する記事をお届けしていく予定です。 Google のプロダクトマネージャー、エンジニア、オペレーター、アーキテクトからなるチームとしての私たちのゴールは「コンテナレボリューション」が、効率的に目的を達成するアプリケーションを構築し、それを実行する上でどう役立つのかを皆さんに理解していただくことです。そこで、まずは Google Cloud Platform の Global Head of Solutions を務める Miles Ward を招きました。それでは始めましょう！ - 編集部

皆さん、こんにちは。そして、新しい連載へようこそ。この連載では、現代コンピューティングの最も重要なイノベーションの 1 つであるコンテナリゼーション（Containerization）についてお伝えしていきます。ところで、コンテナについてこんな疑問を持ってませんか？

コンテナとは何で、どう機能するの？

Docker、Kubernetes、Google Container Engine、Managed VM’s とはそれぞれ何なの？

これらはどう関連しているの？

コンテナを使って強力なアプリケーションを構築して、プラダクションスケールで展開するにはどうしたらいいの？。

この変化から、どうやってビジネス価値を見いだせるの？

と、質問はもういいですね。このポストは、コンテナテクノロジーを使うことにどんな意味があるのか、ということの入門編と考えてください。コンピューティングモデルが進化する中で、あきらかにアプローチが変わる瞬間、その後の軸が変わるような瞬間を、これまで何度か目にしてきました。この 10 年は、まるで過去を無視するかのように、仮想化という変化が起こりました。仮想化のムーブメントによって、広範囲でリソース利用が爆発的に拡大し、価値を生むまでの時間、そしてサービスを提供するまで続けられる繰り返し作業の削減にもなったのです。そして、マルチテナンシー、API を使ったシステム管理、パブリッククラウドの到来により、その利点はさらに拡大していきます。そして最も大きなブレイクスルーは、コンピューターの CPU の 1 つのコアほどのリソースが、オンデマンドで数分のうちに利用可能になったということです。しかし、考えてもみてください、マシン全体のごく一部しか必要としないときに、マシン全体を仮想化する必要があるでしょうか？ Google は早い段階で、この問題に直面することになります。ソフトウェアを短い時間で、安価に開発し、これまでにない規模でオペレーションする必要に迫られ、もっと細かいレベルでの制御を可能にする、より高い次元で抽象化できる仕組みにが必要になったのです。そこで Linux カーネルの追加機能として作成されたのが、cgroups です。cgroups は、隔離した実行コンテキストを作ることができるもので、その実行コンテキストがコンテナです。コンテナは、一種の仮想化であり、全ての Google のアプリケーションを動かすために使われる単純化された OS でもあるのです。それから数年が経った今、Docker の優れたスタッフが、このテクノロジーを活用し、コンテナ化されたアプリケーションの相互運用可能なフォーマットの開発を続けています。 なぜコンテナなのか？ VM にはない、コンテナの特徴とは何でしょう？

デプロイが簡単：独立して識別可能な値を使いレジストリに保存し、コマンド 1 行でデプロイ可能なコンポーネントとしてパッケージ化することで、アプリケーションのデプロイ先を考慮することもなくなり、デプロイは劇的に簡単になります。

すぐに使える：ハードの仮想化ではなく OS だけ仮想化することで、最新の VM ではブートに 1 分程かかるのに対し、上記のパッケージのブートは 20 分の 1 秒以下です。

マイクロサービスの活用：コンテナを使うことで、開発やオペレーションを行うにあたり、コンピューティングリソースをさらに細分化できます。マイクロ VM のインスタンスでもリソースが余るようなアプリケーション、あるいは、VM 全体を一気に大きくスケーリングするようなときは、コンテナはシステムにとって大きなプラス要因となります。

では、こういった特徴によって、何がもたらされるのでしょう？

明らかなことは、ラップトップの処理能力であっても、開発者が複数のコンテナを動かすには十分で、簡単迅速に開発を進められます。もちろんラップトップで複数の仮想マシンを実行することはできますよ。でも、速くもなければ、簡単でも、軽量でもないですよね。

同じように、リリース管理も簡単。新しいバージョンのコンテナをパブリッシュするには、1 回コマンドを叩く、それだけです。低料金でテストもできます。パブリッククラウドでは、VM が最低 10 分単位の処理時間（はっ！まさか 1 時間？！）で課金されるので、1 度テストするだけなら、たいしたコストはかかりません。でも、日毎に数千回のテストを自動化しているとしたら、当然コストは増えていきます。コンテナなら、コストはそのままで何千回ものテストを実施できるわけです。アプリケーションがプロダクションになるころには、かなりのコストが削減できるでしょう。

もうひとつ影響があるのは、このモデルを使ったアプリケーションシステムの構成力です。オープンソースソフトウェアを利用しているアプリケーションであるなら特にそうです。例えば、環境構築のために MySQL、memcached、MongoDB、Hadoop、GlusterFS、RabbitMQ、node.js、nginx… これらをインストールして設定するという、面倒なシステム構築作業を考えてみてください。それが、小さなスクリプトを使って、こういったアプリケーションをコンテナに格納しておけば、はるかに簡単で、リスクも大きく軽減されるわけです。ミスしやすい特殊な作業を、このモデルによってどれほど避けられるか想像できるでしょう。こうした基盤となるビルディングブロックの標準構成をパブリックに登録していくと、質の高いコンポーネントによるリアルなエコシステムが始まるのです。

長期的な視点で、この技術の最も重要な価値は、多くのホスト環境でアプリケーションを実行できる、ポータブルで統一したフォーマットだということです。今アプリケーションを作るとしたら、ベアメタルから、オンプレミスの仮想化インフラ、パブリックやプライベートのクラウド、種々の PaaS も選択肢です。つまりソフトウェアをパッケージしデプロイするには、6 つの異なるやり方があるということです！コンテナのフォーマットが標準化されれば、プロバイダーの差がなくなり、1 つのプラットフォームにロックインすることを避けて、ワークロードをもっとも安価で、もっとも速い環境へと簡単に移していけるようになります。
Docker コンテナや Docker コンテナの実装についての詳しい紹介、特にこことかここや、ここだとかあるので、ここではこのアプローチが「Good アイデア」である、と言っておけば十分でしょう。と言いつつも、課題がないわけではありません。コンテナによって細分化が進んできたことで、驚くほどのメリットがもたらされたものの、実行するワークロードの効率が大幅に向上するわけではなく、アプリケーションの実行に数千台のコンピューターが必要なワークロードもあるわけです。今のところ Docker は 1 つのコンピューターで動かせるように設計されています。では、どうすればコンテナとそこで動くワークロードを、インフラのリソース消費にあわせて連動させ、分散させ、それを管理していけるのでしょうか？どうしたらマルチテナントのネットワーク環境で運用できるのでしょうか？安全性は確保されるのでしょうか？この論点で話をしてもいいのか？と、システムデザインの観点からの問いとしては、あまりに基本的なところなのですが、私が話をする大半の開発者やそのスポンサーは、ここにあるコンピューター上のこのコンテナということには関心がないのです。求めてるのは彼らのサービス、つまり、アプリケーションが起動して、動いて、価値を生み出し、それを監視して運用していくことだけなのです。どのコンピューターでどのコンテナが何をしているかといった取るに足らない（希望的観測、というやつです）細かいことは気にしません。 Kubernetes Google はこの問題に対しイテレーティブに取り組み続け、Google 規模でコンテナ技術の運用を可能にするためのクラスタ管理、ネットワーキング、命名システムを構築してきました。その最初のバージョンを Borg、そしてその後継が Omega と呼ばれています。今現在 1 秒あたりおよそ 7,000、週間では 20 億個以上の新しいコンテナが起動しています。そして、これまでの Google のコンテナに関する運用経験と技術的な知見から、Kubernetes （パブリックフォーラムでは「K8s」と短縮されることもあります）を構築し、世界に向けて公開しました。 Kubernetes は、個々のコンポーネントやコンテナ、あるいはインフラのリソースといったことよりも、開発者と管理者とが、サービスの挙動の改善やパフォーマンスの改善に向けて連携して取り組める、抽象的なレイヤーを作り出します。 Kubernetes のクラスターは、1 つのコンテナでは実現できない何を提供してくれるのか？ Kubernetes は、コンテナというレベルではなく、サービスというレベルでコントロールする、そこににもう一度着目することで、サービス全体に対して知能的、自発的マネージメントを可能にします。サービスがスケールし、自己回復し、さらに更新も容易になるとしたら、それは「Good アイデア」の 1 つです。たとえば Google では、機械学習のテクノロジーを応用し、所定のサービスが最大効率で運用されるようにしています。コンテナを使うことが、デプロイの面倒な作業を減らし、開発者の能力をもっと有益なことに使えるのだとすれば、Kubernetes はコーディネーションの混沌を最小化し、チームの能力を高めるものだと言えるでしょう。 Kubernetes を使うことで、多数のコンテナからなるサービスを構成し、そのコンテナが適切にオペレーションされるようにデプロイのルールに従わせられます。サービスの一部が、他の部分を台無しにしてしまうことなんて、ザラですからね！ Kubernetes なら、こういったコンフリクトが系統的に回避されます。Google では、コーディネーションの改善によって、開発者の生産性とサービスのアベイラビリティが向上し、大規模環境でのアジリティを実現しています。まだ初期段階ですが、 Kubernetes はすでに多くのお客様や多様な企業のチームに採用されています。企業には、Red Hat、VMware、CoreOS、Mesosphere も含まれ、お客様が、Kubernetes で大規模に利用されるコンテナテクノロジーからビジネス的にも利益を生み出せるように積極的に支援しています。 Container Engine Google Container Engine は、 Google Cloud Platform 上の Containers as a service です。 Kubernetes を利用している GKE では、開発者がコンテナを使って、アプリケーションをすばやく起動させて実行できる手段、そして、デプロイして管理し、必要なときは指定された範囲までスケールできる手段を提供しています。GKE については、今後の連載でさらに詳しい情報をお届けします。 デプロイのオプション 私たちは、コンテナリゼーションをコンピューティングモデルの次の大きなシフトの始まりであると捉え、この革命の中で中心的な役割を担っていきます。コンテナについてわかったら、以下にリストしたデプロイの選択肢から、皆さんの要件に最も適合するものを探してください。

大量のコンテナを動作させるために、マネージドのクラスターを使いたいですか？それなら Google Container Engine でとりあえず動かしてみましょう。

パブリックなインフラ、または自社システムで、独自のクラスタを構築したいですか？ Kubernetes を試してみましょう。

完全にマネージドであるパブリックインフラでコンテナを動かしたいですか？ Google App Engine と Managed VM’s を使いましょう。

何にもまして、このイノベーションの中で、皆さんが何をしたか、どんなニーズがあるのか、そしてアイデア（プルリクエストも待ってます！）にとても関心があります。気軽に私まで連絡ください。また、出来る限りたくさんのカンファレンスやミートアップにも参加する予定です。皆さんの 2015 年から先の目標や抱負に、コンテナ技術がどうしたら大きな影響を与えられるか、お話しできることを楽しみにしています！ -Posted by Miles Ward, Global Head of Solutions, Google Cloud Platform

[GCP] Google Cloud Monitoring: Stackdriver で Google Cloud Platform をモニタリング

2015年1月28日水曜日

リクエストのトレースや、パフォーマンスの改善とは別に、他の作業やディスプレイから離れた業務時間外のときに発生する、アプリケーションの停止や性能の低下は、たとえオンプレミスからクラウドへ移行しても引き続き生じる問題です。この問題への対応に、Google Cloud Platform (GCP) を利用している皆さんなら、例えば、昨年 Google App Engine との統合を発表した Datadog や、GCP のテクノロジーパートナーである New Relic といったサービスを使いモニタリングする方法もあるでしょう。同じように AWS を利用している場合、多くのサービスと並んで、8 ヶ月前に、GCP に加わった Stackdriver も候補となるモニタリングサービスの 1 つではないでしょうか。様々な選択肢があるなかで、モニタリングサービスは何を使うべきなのか？回答はシステムに依りますが、まず DevOps の実現という観点から見ていきます。 DevOps による継続的改善によるビジネスゴールの達成、ビジネスの変更に対応するために小さな変更を頻繁に繰り返すオペレーションの中で、システムのガバナンス、オートメーション、CI、オートスケールなど、ツール、手法、プロセスも頻繁に改善し続ける必要があります。このような中でモニタリングサービスに求められるのは、単なるモニタリング機能以外にも、継続的デリバリーの中で事前に全ての変更をテストできるわけではないときに、とにかく速く広範囲に問題を検出できる QA（クオリティアシュアランス）の役割です。それには、より詳細なインサイト、リリースにあわせた迅速なセットアップ、リソースの予測、オートスケールへの対応、対象のクラウドサービスの機能にあわせたモニタリングや、検知に対してアクションを起こすオートメーション、このようなインテリジェンスを持つモニタリングサービスが要求されます。 Stackdriver が、AWS を利用する大規模なサービスで数多く利用されている要因の 1 つには、このインテリジェンスの実現によって、利用者のビジネスゴール達成への関与が挙げられます。

Google は、GCP でも AWS 、あるいは以前紹介した Wix のようにハイブリッドでも利用できる、統一モニタリングソリューションを提供することをゴールとして、まだ Google Cloud Monitoring に含まれていない Stackdriver のテクノロジの統合を進めています。この理由からも Stackdriver の AWS モニタリングの各製品は引き続き利用可能です。

Google Cloud Monitoring は、この Stackdriver を使い GCP のモニタリングを可能にするものです。機能は以下のようにシンプルでありながらも、強力なインサイトを得られます：

簡単なセットアップ：利用を開始すると直ぐに、チャートやアラート機能が使えます。そしてカスタマイズも可能なダッシュボード。

アラートの受信：メール、SMS、PagerDuty、HipChat、他にも多くの手段でアラートを受信できます。アラートは個々のメトリクスや閾値、あるいは、グループの中で集計した値に対して設定できます。

オープンソースソフトウェアの統合：少しの設定で、多くのオープンソースのサーバソフトウェアからのメトリクスを集計できます。例えば Cassandra クラスターや Nginx サーバ、それぞれに固有のトレンドを見つけることができます。

そして Google Cloud Trace に続きベータとなり、GCP を利用する全ての方が、Google App Engine、Google Compute Engine、Pub/Sub、Google Cloud SQL、各サービスのインサイトを得られるようになりました。
利用するには、Google Developers Console からプロジェクトを選択し、左側のナビゲーションから、Monitoring > Dashboards & alerts（監視 > ダッシュボードとアラート）を選択してください。最初に使うときは、Enable Monitoring（監視を有効にする）というラベルのボタンが表示されているので、ボタンを押して有効にします。有効にすると Stackdriver で動く Google Cloud Monitoring のコンソールに移動します（現時点では、app.google.stackdriver.com ドメインで動作します）。ここでは、Google Cloud Monitoring の概要がわかるように、そのコンセプトと主要な機能をスクリーンショットを交え掲載します。 Google Cloud Monitoring コンセプトリソースとグループリソース（Resource）は、GCP のサービスで使われている仮想オブジェクト、例えば GCE であるなら VM インスタンス、Cloud SQL ならデータベースインスタンス、Cloud Pub/Sub ならトピックを指します。グループ（Group）は、リソースの集合。「プロジェクトで Cassandra を実行している全ての VM インスタンス」という言うとき、これがグループとなります。Google Cloud Monitoring は、自動的に関連するリソースを集めてグループ化します。ただし、現在のところ App Engine だけのプロジェクトでは、グループは利用できません。メトリクスサービスメトリクス（Service Metric)、またはプラットフォームメトリクス（Platform Metric）は、特定のサービスやプラットフォーム（GAE など）を使うと計測できるメトリクスです。
カスタムメトリクス（Custom Metrics）は、何らかのシステムの状況を計測して独自に定義できるメトリクスです。例えば、カートのチェックアウトだったり、ユーザーのログイン、あるいはビジネスの KPI。利用するには、そのためのデータを Custom Metrics API を利用して Google Cloud Monitoring に送信する必要があります。
チャートとダッシュボードチャート（Chart）は、1 つ以上のメトリクスをビジュアルで表したものです。1 つ以上のメトリクス、あるいは複数のメトリクスを合計して、時系列のチャートを作成できます。例えば、「VM レイテンシー」という名前で、VM インスタンスのグループの平均 CPU 利用率を表示したチャートを作成するなどが可能です。ダッシュボード（Dashboard）は、複数のチャートからなり、加えてイベントログやインシデントのリストといった別の情報も含まれます。ダッシュボードは、1 ページのビューとして構成されています。システム全体の状況や、システムに悪影響を及ぼす特定要因の状況を表示するダッシュボードを作成することも可能です。ダッシュボードへのチャートの追加や削除はいつでも可能です。
エンドポイントヘルスチェックとイベントエンドポイント（Endpoint）とは、エンドユーザー、オペレーション担当、開発者がクラウドで構成されたシステムを使うときのエントリーポイントです。そのため、エンドポイントには、Web サーバーからストレージサービス、VM インスタンスも該当します。エンドポイントという名前は、Google Cloud Endpoints と混同しやすいですが、Google Cloud Monitoring のエンドポイントとは異なります。エンドポイントヘルスチェック（Endpoint Health Checks）は、Google Cloud Monitoring のサービスです。世界中の様々な場所からエンドポイントにリクエストを送ることで、システムの状態を調べるように設定でき、その結果はアラートポリシーの条件として使うことができます。そのため、結果が悪ければ通知する設定もできます。イベントログ（Event Log）は、アプリケーションや、利用している GCP プラットフォームやサービスに関連するシステムイベントの時系列リストです。イベントには、クラウドインフラストラクチャーのダウンタイム、アラートポリシーに関連した通知、コードのデプロイメントといったものが該当します。また、自分でログにイベントを追加することも可能です。イベントログも、Google Cloud Logging と混同しやすいですが、異なるものです。
アラートと通知とインシデントアラート（Alert）は、アラートポリシーの条件に合致する状況になったとき発生し、Cloud Monitoring Console の Incidents ページに表示されるインシデント（Incident）となります。インシデントは、条件を満たさなくなったら自動で消えますが、手動で取下げることもできます。アラートポリシーには、通知（Notification）を組み合わせことができます。アラートが発生したときに、メールや SMS で、担当者や何らかのサービスに対し通知することができます。

主な機能
Google Cloud Monitoring Console にアクセスすると、最初にシステムの全体状況と、キーメトリクスからなるページが表示されます。

Google Cloud Monitoring Console
アラートポリシーを設定し、設定した条件に合致するときチームに通知するためのアラートを設定できます。アラートは、メール、SMS、PagerDuty、Campfire、HipChat、AWS の Simple Notification Service そして gcp ja night や事例取材の中でも良く出てくる Slack にも通知可能です。また Webhook を利用して、何らかのサービスへ通知を定義することにも対応しています。

レスポンスレイテンシーをメトリクスとしたアラートポリシーの設定
エンドポイントヘルスチェックを設定しておくと、エンドユーザーが、ウェブサーバー、API、その他インターネットから接続可能なリソースが利用できない状況であると、通知を受けられます。

エンドポイントヘルスチェックの状況世界中のロケーションからチェックされています。 Google Cloud Monitoring の特徴として、MySQL や Nginx、Apache、MongoDB、RabbitMQ、その他にも数多くのオープンソースのサーバソフトウェアをネイティブに統合していることが挙げられます。一例として Cassandra プラグインを利用すると、分散 KVS のパフォーマンスを詳細に可視化して調べられます。

Cassandra のパフォーマンスダッシュボード Google Cloud Monitoring はカスタマイズすることもできます。API を使いカスタムメトリクスを送信することで、ダッシュボードにシステムやインフラストラクチャーのメトリクスと一緒に表示させられます。

ダッシュボードにカスタムメトリクスを表示今後の Google Cloud MonitoringGoogle Cloud Monitoring のページ Google Cloud Platform 日本チームでは、皆さんのフィードバックを聞きくのを楽しみにしています。利用した感想やおすすめの使い方、あるいは問題点や不足している機能も含めて、Blog や Qiita などに書いたときは、是非 Google+ や Twitter で教えてください。 #gcpja

[GCP] プライベート Docker リポジトリーを、高セキュリティ環境にホスティング - Google Container Registry

2015年1月27日火曜日

アプリケーションのデプロイや運用の方法を変革しようとしているコンテナのテクノロジーを紹介する連載がはじまりましたが、その中でも Docker は、アプリケーションのコンテナ化と、アプリケーションの構築、デプロイ、運用の革新的な方法として注目をあびています。 Google Cloud Platform (GCP) では、マネージド環境である Google Container Engine を Kubernetes や、コンテナに最適化された Google Compute Engine の VM、Google App Engine の Managed VMs を使い、Docker コンテナへ豊富なサポートを提供しています。
そして今回は、新しいサービスである Google Container Registry をベータとして紹介します。Google Container Registry は、高セキュリティのホスティング環境と共有機能を持ち、プライベートなコンテナリポジトリの運用を可能にします。 GCP にレジストリーサービスがあることで、3 つの利点が生まれます:

アクセス制御: GCP に作ったプロジェクトの中の、Google Cloud Storage の中にプライベートイメージが格納されます。つまり、デフォルトでは、プロジェクトのメンバーだけが、プライベートイメージにアクセスできるということです。プロジェクトのメンバーは、Google Cloud SDK のコマンドを使い、セキュリティが確保された状態でイメージのプッシュやプルができます。また、コンテナを格納している VM からも、安全にイメージにアクセスできます。

サーバサイド暗号化: プライベートイメージは、ディスクに書かれる前に自動的に暗号化されます。

高速で安定した環境からのデプロイ: プライベートイメージは、Google Clodu Storage に保存されると、Google のデータセンターでキャッシュされ、GKE のクラスターや、GCE のコンテナ最適化 VM へ、GCP の Andromeda を使いデプロイできる状態になります。

zulily は、数千にも及ぶ個性のある製品を扱い、日々新しい製品を販売するオンラインのリテーラーであり、今回のレジストリーサービスのアーリーアダプターでもあります。zulily の Core Engineering で Principal Engineer をしている Steve Reed 氏は、レジストリーサービスの利用について、次のように説明してくれます。 “Docker レジストリーを、常に高いパフォーマンス、高いセキュリティーで安定して使える、それは Docker でコンテナ化された GCE アプリケーションを使っている会社としてはとにかく重要なことです。そのためにプライベートレジストリーを使うことになるわけですが、実際に運用するには証明書に認証、ファイアーウォール、バックアップからモニタリングまでが必要になってきます。それが、Google からフル機能のコンテナレジストリーが提供されたことで、開発やデプロイのワークフローにプライベートレジストリーを容易に統合できたのです。” コンテナレジストリーのベータ期間中は、プライベートイメージで使う Google Cloud Storage のストレージ使用料とネットワーク使用料以外の料金はかかりません。始めるには、GCP のプロジェクトで、支払いを有効にしておく必要があります。まだプロジェクトを作っていないなら、今なら無料試用でも始められます。それと、Docker と Google Cloud SDK をインストールしておいてください。まずは試してみましょう。レジストリーを使い、プライベートの Docker イメージを運用しはじめる方法をドキュメントに掲載しています。是非レジストリーサービスのチームに、直接フィードバックをください、楽しみにしています。 -Posted by Pratul Dublish, Technical Program Manager

Google 主催、集中講座「クラウドを使うリスク、使わないリスク、Google のセキュリティ」を実施します。

2015年1月26日月曜日

クラウドサービスのセキュリティの考え方を理解する2月の情報セキュリティ月間六本木ヒルズ森タワーこちら

[GCP] モバイルアプリ事業者向けのビッグイベント「 Google for モバイルアプリ」を開催

2015年1月23日金曜日

イベント概要こちら

Google スケールで実現するグローバルなアプリ基盤

コンテナ技術と Google Compute Engine で実現するクラウド時代のアプリ実行環境

モバイルアプリ企業の Google Cloud Platform 活用事例

Maps API で、かしこく地図アプリを開発しよう

モバイル KPI 分析の新標準〜 Fluentd + Google BigQuery

こちら参加お申し込み方法イベントサイト

Google 社員の働き方紹介 vol.1

2015年1月20日火曜日

■ 普段どんなお仕事をされているのですか？■ Google Apps とは一言で表すと何ですか？■ Google Apps イチオシ機能ってありますか？■ Google 社員は普段どんな風に働いているのですか？

※ ひとつのファイルをチームで同時に共同編集

■ Google のオフィス環境で気に入っているところは？

[GCP] データサイエンティストが起こす、社会的なインパクト。Google Cloud Platform で 24 時間の Bayes Impact ハッカソン

2015年1月16日金曜日

Bayes ImpactGoogle Cloud Platform (GCP)Google Compute Engine (GCE)BigQueryチームの仕事

Google Maps for Work サイト「Maps going to Google」の第二章「資産や人員配置の把握と最適化」をアップしました。

2015年1月16日金曜日

「Maps going to Google」の第二章 Google インドアマップを利用し、目的地への移動をより迅速かつスムーズに

屋内の場所の表示・検索：Google インドアマップ機能は Google マップに組み込まれているため、Google マップの便利な機能を使って屋内の場所を閲覧したり、検索したりすることができます。

ズームインで表示：ズームインするだけで構内図を表示したり、構内の場所を検索することができます。

ワンタップでフロアを切り替え：画面右下で表示階を切り替えて館内のフロア間を移動できます。

モバイルアプリやウェブサイトへの組み込み：モバイルアプリやウェブサイトでも構内図が利用できるようになります。

顧客満足度やサービス品質の向上　～Google インドアマップ機能を利用して～ 「Google Atmosphere Tokyo 2014 」でも利用「Maps going to Google」の第二章

[GCP] Google Cloud Trace で、アプリケーションのパフォーマンスを診断する

2015年1月14日水曜日

発表プレゼンテーションとデモ英語の Google Cloud Platform Blog顧客満足とリテンション25% のユーザーはロード時間が 4 秒を上回るとそのウェブページから離脱する86% のユーザーはパフォーマンスの低いアプリケーションを削除する低いパフォーマンスがユーザー体験を損ねること、あるいはユーザーに見限られしまうこと重要視

db.get(), db.put(), db.query() のような Datastore の呼び出し

memcache.get(), memcache.get_multi() のような Memcache の呼び出し

urlfetch.fetch() のような URL Fetch の呼び出し

処理の中で必要のないサービスを呼び出している

同じデータを取得するために複数回のサービスを呼び出している

バッチ、または並列実行でも構わないはずが、順次実行でサービスを呼び出している

Developers Console

図 1 - リクエストの内訳

図 2 - リクエスト解析

図 3 - リクエストの比較Google Cloud Platform Live でのプレゼンテーションドキュメンテーションプロジェクトのページ

[GCP] MITx では、Google Compute Engine 上で Akselos を実行し工学シミュレーションに活用

2015年1月13日火曜日

Google Cloud PlatformAkselosGoogle Compute Engine目指しています

エデックスの構造解析コースコミュニティ

[GCP] Cloud Dataflow SDK for Java をオープンソース公開

2015年1月9日金曜日

Google Cloud DataflowGoogle Cloud DataflowFlumeJava

ストリーム処理とバッチ処理の統合によるイノベーション：Cloud Dataflow SDK では、バッチ処理とストリーム処理の両方を統合したモデルを導入します。この統合がもたらす再利用可能なプログラミングパターンが、開発効率の向上を実現するカギとなります。また、時間軸でのデータ集約のための豊富なウィンドウ関数を提供し、バッチとストリーム両方の種類のデータソースに対して同じ処理を適用できます。

さまざまなプログラミング言語による Dataflow プログラミングモデルのサポート：Dataflow がサポートするプログラミング言語とプログラミングパターンは、今後も増加していきます。Dataflow をより多くのアプリケーションから使えるように、現在 Python 3 版 SDK の開発が進められています。

サードパーティのサービス環境での Dataflow の実行：現在のIT開発、とりわけクラウド分野おいては、多種多様なサービスをいかにして組み合わせ構成するかが重要なポイントとなります。Cloud Dataflow は、大規模にスケール可能で、高い信頼性と一貫性を備えるマネージドサービスとして構築されていますが、一方で外部サービスへのポータビリティも重視されています。例えば Apache Storm や Spark、 Hadoop 製品ファミリーは引き続きは発展を続けているものの、それにともなうプログラミングモデルの分裂が開発者にとっての課題となります。大規模データ処理の実行環境やサービス環境のポータビリティを確保することで、そうした苦労をなるべくなくし、デプロイ先プラットフォームの選択肢を広げます。

Dataflow SDK for Java利用申し込みドキュメントgoogle-cloud-dataflow

[GCP] 12 月の Google Cloud Platform の動向を振り返る: 6 つの事例、3つは Windows ワークロードについて、2 つは Dataflow について、そして Year in Review ハイライトシリーズ

2015年1月8日木曜日

Google Cloud Platform

Windows サポートの拡充機能の詳細についてはこちら安心してお買い物準拠認定されたことをお伝え語られる、驚きのストーリー

Aerospike - Google Compute Engine (GCE)でどのように秒間 100 万書き込みを達成したか

Wix - マルチクラウドデプロイメントでどのように高可用性を実現したか

dotCloud - Google Cloud Platform でより高速で信頼性の高い PaaS を提供する方法

Akselos(英語)- どのように複雑な工学シミュレーションを伴う MITx の edX コースを GCE で支援したか

RealMassive(英語) - 強力なデータ技術を利用して商業不動産を変貌させる方法

Bayes Impact(英語) - Bayes Impact 自体が GCP を使ってという話ではありませんが、開催している 24 時間のハッカソンで、データサイエンティスト達が GCE や BigQuery といったツールを活用して何テラバイトもの情報を高速で分析し、人々の暮らしに有意義な影響を与える方法を追求

ゲーム攻略完全図鑑 - Google App Engine で MAU (Monthly Active User) 950 万に達するサイトを運営

エイチーム - リアルタイム RPG ゲームを GCE で開発

Cloud Developer Advocate チームから皆さんに「こんにちは」Twitter自己紹介のポストCloud Dataflow のあれこれCloud Dataflow SDKこちらをご覧ください別のポストYear in Review ハイライトシリーズで 2014 年を振り返る最近の開発者は楽をしすぎている物語GCP ポエムオープンソースを優先することの考察といったポスト

#77minLunch 株式会社 JTB 情報システム

2015年1月7日水曜日

同社では JTB グループ内の交流人事でインドから社員を迎えています。 ”シャッフルランチ” という、さまざまな社員が入れ替わり立ち代わりメンバーに入るランチ企画を開催することで、交流人事で来た社員と、お互いの国の文化や IT 事情に触れる機会を設けているそうです。

この日はオフィスに近い喫茶店でランチを実施。皆さんの和やかな雰囲気が伝わってきますね。

JTB グループの IT 戦略の推進や、グループ各社のシステム開発・運用業務を担っている同社では、Google グループを利用し、ユーザーからのお問い合わせをチームメンバー全員が共有し、迅速に対応が行えるような仕組みを利用されています。

また、日々のシステムに関するイベントについては Google カレンダー上に作成し、全員で共有・認識できるようにしているそうです。

さらに、ペーパーレスの推進のため、社員全員に iPad が配布され、ドキュメントの共有が Google ドライブ上で行われたり、最近では、離れたオフィスの社員が一つのプロジェクトに関わることも多いことから、Google+ やハングアウトも活用しています。

いつでもどこでもどんなデバイスでもコミュニケーションできるようになったことで、会議のためのオフィス間移動も減り、ゆったりしたランチタイムが実現できているそうです！

株式会社 JTB 情報システム

http://www.jss.co.jp/

《 #77minLunch フォト大募集！》

皆さんも業務を効率化し、いつもよりもゆったりしたランチを仲間と楽しく過ごしませんか？

77minLunch（セブンティセブンミニッツランチ）では、Google for Work をご利用いただいている企業、団体、チームの素敵なランチ風景を募集しています！

77minLunch 応募フォームはこちら

Japan 公式ブログ