Google Cloud Platform Japan 公式ブログ: 8月 2015

UDF を新たにサポートした Google BigQuery で、より “ディープ” なクラウドアナリティクスを！

2015年8月28日金曜日

* この投稿は、米国時間 8 月 25 日、Technical Program Manageである Tino Tereshko によって投稿されたものの抄訳です。 8 月 14 日付の投稿Google Cloud DataflowGoogle Cloud Pub/SubGoogle BigQueryBigQueryBigQuery 新しい BigQuery は、UDF などの新機能と、改良されたユーザーインターフェース（UI）を備え、今まで以上に使いやすくなっています。

ユーザー定義関数（UDF）: UDF は JavaScript で表現され、SQL を拡張します。UDF を使えば、BigQuery の中で自由にコードを実行できるようになります。たとえば複雑な条件をクエリに記述できるようになり、正規表現よりもはるかに柔軟なマッチングを指定できます。詳細はドキュメントを参照してください。

BigQuery から Google Cloud Storage ファイルへのクエリ: BigQuery に最初にファイルをロードしなくても、クエリを実行できるようになりました。この機能により、BigQuery へのデータのインポートも単純化されています。既存のストレートな“インポート”メカニズムに加え、Cloud Storage ファイルを読み込んで結果を BigQuery テーブルに書き込むクエリを書けるようになりました。詳細は統合クエリのドキュメントを参照してください。

クエリ上限の拡張: 新しい BigQuery では同時に 50 のクエリを実行できます（従来は 20）。1 日あたりのクエリ数も 100,000 に増えています（従来は 20,000）。さらに、“同時処理されるバイト数の上限”と“同時実行される大規模クエリの上限”が廃止されました。これらの変更により、BigQuery エコシステムにおける自由度が広がりました。

UI の改良: 新設の“ Format Query ”ボタン、日付によってシャーディングされたテーブルの自動構成、クエリ結果の JSON へのダウンロードなど、いくつかの新機能が追加されています。

BigQuery はさらに強力で、かつパフォーマンスの高い製品へと進化し、お客様の作業時間短縮と生産性向上を支援します。

ダイナミックなクエリの最適化: 大規模な JOIN や GROUP BY などの複雑なクエリの信頼性とパフォーマンスを高めます。あと数週間のうちに、お客様のプロジェクトは動き始めるはずです。もう EACH キーワードを指定する必要はなくなります。これにより、クエリは大幅に単純化されます。特に、ビジュアライゼーションツールやダッシュボードのようにプログラム内で SQL を生成するアプリケーションでは大きな効果があります。

クエリ実行エンジンの拡張: これにより、大規模な JOIN、アナリティクス機能、カーディナリティの高い列による集計など、大量の資源を使用するクエリのパフォーマンスとスケールが向上します。

最後に、BigQuery をよりオープンにするための新機能を紹介します。

BigQuery Slots: BigQuery には、広大な共有リソースのプールから 1 つのクエリのために数千のコアを投入できるというユニークな機能があります。BigQuery Slots は、システムの負荷にかかわらず、使えるリソースを拡大する機能を提供します。ユースケースには、レイテンシーに敏感に対応する SaaS、ETL（抽出、変換、ロード）、ビジネスレポート作成などがあります。

High-Compute 料金レベル: UDF、ダイナミックなクエリの最適化、クエリ実行エンジンの拡張に伴い、BigQuery は“バイトスキャン”と比べて大量の計算リソースを使用するクエリをサポートします。こうした大量リソースの使用を可能にするため、High-Compute 料金レベルが導入されます。詳細は価格ページを参照してください。

BigQueryBigQueryドキュメント試してみる- Posted by Tino Tereshko, Technical Program Manager

Google Cloud Platform パートナー、リセリングオプションの利用が可能に

2015年8月27日木曜日

ワールドカップに人を集結させること (過去の記事はこちら; 英語のみ) から、従業員同士のコミュニケーション向上 (参考資料はこちら; 英語のみ) まで、Google Cloud Platform Services Partners は顧客が Google の製品を最大限に活用できるようサポートしています。

パートナーの皆さまがより一層、カスタマーエクスペリエンスの向上にフォーカスできるように、この度 Google Cloud Platform の現サービスパートナーを対象にしたリセリング (パートナー経由での販売) オプションの申請受付開始を発表いたします。初秋には新規のパートナープログラム申請者も対象となる予定です。

Google Cloud Platform のリセラー (販売パートナー) の方々は、新しい Google Cloud Platform のリセラーコンソールを介し、顧客管理や対策を行うことができます。例えば以下のようなことが可能になります。

顧客の Google Cloud Platform 利用体験を研修から実践まで完全管理
最良のサポートを提供し、顧客の問題解決に責任を持つこと
顧客の具体的な要求に対応した請求サービスを現地通貨で提供

リセリングを行えるようになることは、複数のGoogle Cloud Platform サービスを一つに束ねたり、顧客へ一括請求の提案を考えているパートナーにとって特に有益なものとなっています。

現サービスパートナーの方々でリセリングの資格についてさらに詳しく知りたい方は、申請ページ Google for Work Connect をご覧ください。サービスパートナーに関心があり、Google Cloud Platform にあまり馴染みがない場合は cloud.google.com/partners をご覧ください。

- Posted by Adam Massey - Director, Global Partner Business

Google Container Engine が GA に

2015年8月27日木曜日

本日、 Google Container Engine が GAとなり、99.95% の SLA (サービスレベル契約)が適用される実用レベルとなりました。 Container Engine を利用することにより、インフラストラクチャの柔軟性を犠牲にすることなく、コンテナクラスタの設定とアプリケーションの管理が簡単になります。早速、お試しください。数クリックでマネージドコンテナクラスターを設定Container EngineContainer EngineContainer Engine

「私たちは、自分たちのアプリケーションインフラストラクチャを最大限有効に生かすために Kubernetes を選び、また Kubernetes を最大限有効に生かすために、別のクラウドプロバイダから Google Container Engine への乗り換えを選びました。 Container Engine での私たちのインフラストラクチャは、もう一つのクラウドプロバイダの当初のデプロイのおよそ 40 %で実行しており、 Google の継続使用割引と分単位での課金が更なるコスト削減へと繋がっています」

- Jay Allen 、Porch CTO

宣言的なコンテナスケジュールと管理

多くのアプリケーションが複数のコンテナを利用しています。例えば、ウェブアプリケーションでは、ウェブサーバー、キャッシュ、データベースで別々のコンテナを持っているかもしれません。オープンソースのオーケストレーションシステムである Kubernetes を利用している Container Engine なら、複数のコンテナを1つのシステムとして一緒に実行することも簡単にできます。

Container Engine は、あなたの宣言による要件に基づき、コンテナをクラスタにスケジュールし、自動的に管理します。蓄えておく CPU ／メモリの量、レプリカの数、キープアライブポリシーなど、ただコンテナのニーズを定義するだけで、 Container Engine が能動的に確実に要件を満たします。

「 Kubernetes の宣言的な性質は、Django 、 Geoserver 、 ELK stack 、 Redis 、 PostGIS 、そしてGoogle Cloud Bigtable のインスタンスと統合する GeoMesa を含む、アプリケーション構成の起動を効率化し、簡素化するために大きな力を発揮していると分かりました」
- Tim Kelton,共同創設者, Descartes Labs.

Kubernetes による柔軟性

多くのユーザーは、マルチクラウドの世界に住み、オンプレミスとパブリッククラウドのインフラストラクチャの両方を用いてアプリケーションをホストしています。 Kubernetes を自社のプラットフォームに組み込んでいる Red Hat 、 Microsoft 、 IBM 、 Mirantis OpenStack 、 VMware などと共に、ユーザーももっと簡単にワークロードを移行したり、複数のクラウドプロバイダを利用したりできるようになります。 Container Engine と Kubernetes は、ユーザーの利用しているのが、オンプレミス、ハイブリッド、あるいはパブリッククラウドのいずれであっても、柔軟性を提供します。

「私たちが新しいマイクロサービスベースのコンテナ構造を実施したとき、 Kubernetes を選択しました。複数の環境で簡単に素早くデプロイできる単体でシンプル、標準ランタイムのプラットフォームを必要としていたからです。私たちは、 Container Engine を自分たち自身のインフラストラクチャ（ Mirantis OpenStack を利用）および他のパブリッククラウドと連動させて使用し、インフラリスクを分散させています。」
- Lachlan Evenson 、 Lithium Cloud Platform Engineering

実用レベル

検索から Gmail まで、 Google ではすべてを Linux コンテナでパッケージし実行しています。毎週、世界中にある私たちのデータセンターで 20 億以上のコンテナインスタンスが起動しています。 Container Engine は、私たちの最高のコンテナ経験を象徴するものであり、皆さまにお届けできることを大変嬉しく思います。さあ、 Container Engine を始めましょう。

皆様のサポートに感謝をこめて、特製 Container Engine T シャツを 1,000 名にプレゼント！

Twitter から @googlecloud と #imakubernaut で、なぜ Container Engine か Kubernetes が好きかをつぶやいてください。(先着順、応募概要、規約はこちらから)

- Craig Mcluckie, Product Manager

簡単スタートアップガイドのお知らせ

2015年8月27日木曜日

Posted by 福田潔 (Google Cloud Platform セールスエンジニア) 本日は、Google Cloud Platform 簡単スタートアップガイドのお知らせです。 Google Cloud Platform セミナーに参加したことがある方はすでにご覧になったこともあるかと思いますが、日本チームでは、主に初めて Google Cloud Platform を使う方向けに、簡単スタートアップガイドを公開しています。 Google Cloud Platform 簡単スタートアップガイド:　http://goo.gl/ua5fQw

このガイドでは、初めて Google Cloud Platform を利用する際のセットアップから、Google Compute Engine, Google App Engine, Google BigQuery などの主なサービスの使い方をステップバイステップで、スクリーンショットと共に説明しています。主な内容:

サービス共通編

プロジェクトを作成する
課金を有効にする
コマンドツールをインストールする

Compute Engine 編

VMインスタンスを作成する
Web ページを提供する
VMインスタンスを削除する

BigQuery 編

クエリを実行する
テーブルを作成する
Google Spreadsheetと連携する（オプション）

これから Google Cloud Platform を使ってみようという方、ぜひご活用ください。また、Google では、ハンズオンセミナーも定期的に開催しています。この資料にそって、実際に私達と一緒に製品を触ってみるチャンスです。詳細はこちらをご覧ください。

放置されているバックアップデータを今すぐクラウドへ

2015年8月26日水曜日

*この投稿は、米国時間 8 月 26 日、Product Manager の Ben Chong によって投稿されたものの抄訳です。ローカルやサードパーティのストレージでバックアップテープを使用している方々に朗報です。こうしたデータを放置しておく必要はなくなりました。競争力を維持しながら古いバックアップデータをクラウドへ簡単にインポートできるよう、Google は Offline Media Import/Export の提供を開始しました。Google Cloud StorageStandardDRANearlineGoogle Cloud Storage Nearline

自社で実行するよりも高速：シンプルな手順：データの保護：はじめてみようOffline Media Import / Export のウェブページ-Posted by Ben Chong, Product Manager

株式会社ブロードリーフの導入事例 - Google BigQuery で 100 万規模のデータを統合、最短数秒で結果を返すシステムを構築。

2015年8月24日月曜日

およそ 10 年に渡って自動車のアフターマーケットの業務効率化を推進してきた株式会社ブロードリーフが、新たな時代の取り組みとして手がけるのがデータベースのクラウド化。部品商と整備業者、そしてエンドユーザーをつなげる新たな仕組みを Google Cloud Platform を使って生み出しました。

株式会社ブロードリーフ ■ 写真左から開発本部開発部部長樋口直亨さん開発本部開発部マネージャー鈴木基之さん ■ 利用中の Google Cloud Platform サービス Google Compute Engine, Google Cloud Storage, Google BigQuery 自動車に乗っている人であれば、誰もが定期的に利用する自動車整備工場。車検や修理など、快適かつ安全にカーライフを過ごしていくためにはなくてはならない存在です。株式会社ブロードリーフはそんな自動車のアフターマーケットにおける IT ソリューションを提供する企業（2005 年創業）。自動車の販売業、整備業から部品商などまでを包括的にカバーする業務アプリケーションやサービスを開発・販売してきました。

これまでの自動車業界は、一定の IT 化が進んだとはいえ、まだまだ古い体制が根強く、お世辞にも先進的とは言えない状況が続いています。例えば車検の際、必要となる部品の在庫や納期について、カーオーナーをお待たせたした状態で都度確認するといった業務が当たり前のように行なわれているのです。ブロードリーフはそれらを改善すべく、整備事業者様（フロントマン）と部品商様（バックヤード）をネットワークで結ぶサービスを提供しているのですが、そこにもまだ課題があったと、同社開発本部開発部部長の樋口さんは言います。「電話で確認するよりははるかに速く、効率的だったのですが検索処理を部品商様のサーバーで行なう関係上、短いとは言えない時間がかかってしまっていました。たとえそれが 10 秒だとしても、お客様を目の前にした 10 秒は数倍の長さに感じられますからね。業界のためにも、お客様のためにも、新しい仕組みが必要だと考えました」（樋口さん）そこでブロードリーフが取り組み始めたのが、それらデータベースのクラウド化。Google Cloud Platform を活用し、部品の在庫情報などを高速かつ一元的に管理できることを目指しました。こうすることで客前などでタブレットを使った検索・提案が可能に。ただし、この仕組みを実現するためには、部品商各社から部品の在庫・価格情報などのデータを収集する作業、そしてそれを 1 つのデータベースとして統合・格納する作業が必要となります。

「いろいろなビッグデータ解析サービスを検討しましたが、Google BigQuery が抜きんでて簡単でした。何よりありがたかったのが、慣れ親しんだ SQL に近い使い勝手で利用できること。当初は開発期間を 3 か月程度見込んでいたのですが、これが何とわずか 1 週間で済んでしまったんですよ」（鈴木さん）「IT というものに対する考え方ががらりと変わる瞬間でした（笑）」（樋口さん）もちろん BigQuery を使うことで、検索にかかる時間も劇的に短縮。「100 万件の価格データと 70 万件の部品データを統合して、そこから必要な情報を引き出すなど、普通にやっていたら数時間かかる処理が BigQuery なら数秒～数分で終わってしまいます」（鈴木さん）また、複数の部品商のデータベースを統合することで、これまでは実現できなかった、複数事業者間での検索も可能に。より安く、より早く納入可能なパーツを1度の問い合わせで確認できるなど、カーオーナーにとってもメリットの大きな取り組みとなりました。ちなみに本サービスは Google Cloud Platform を利用した、株式会社グルーヴノーツのプラットフォーム「MAGELLAN（マゼラン）」を使って構築。そのことも大きな効率化に繋がっているそうです(株式会社グルーヴノーツのインタビューはこちら: 前編 | 後編)。

「各部品商様の情報を統合する際、当初は一旦、Google Cloud Storage にアップしてから BigQuery に流し込むという方法を採っていたのですが、小さなファイルが大量にできてしまい、効率が低下してしまっていました。これについて悩んでいたところ、グルーヴノーツさんにストリーミングインサートというやり方を提案していただいて、一気に効率アップ。実はこういう使い方は BigQuery 本来の使い方ではないのですが、グルーヴノーツさんも Google さんも、絶対にそういうことを言わないんです。むしろサービスの制限を外す検討をしてくださるなど、実に親身になってくださいました。やり取りもスピーディで本当に助けられましたね」（鈴木さん）「自分たちのやろうとしていることに関心をもってくれるのがうれしかった」と言う樋口さん。今回の経験を経て、今後、さらにクラウドを積極的に活用していこうと決心されたそうです。ちなみに今、特に気になっているのが「ディープラーニング」。これを上手に活用していくことで次世代のサービスを生み出せるのではないかと考えているのだとか。

「いままでの技術、やり方だとできなかったようなことを、Google Cloud Platform を使って可能にしていくというのはエンジニアとしても興味深いチャレンジ。コンソールを眺めていると日々新しいサービスが増えていくのが面白いですね。今気になっている新サービスが Google Container Engine。上手に使うとサービスをフレキシブルな構造にできそうですよね。今やっている作業が落ち着いたら少し触ってみようと思っています」（鈴木さん）導入事例はこちら

目で見る Google のグローバルネットワークインフラストラクチャにおけるイノベーション

2015年8月21日金曜日

Adam Hall によって投稿されたものネットワーキングについて考えたのはまだネットワーキングがないときだった！100 倍以上1 ペタビット/秒

Firehose (2005-2006) シャシーベース（ただしバックプレーンなし）バルキー CX4 銅線ケーブル、規模に制限


WatchTower (2008) バックプレーン付きシャシー全ステージでファイバー（10G）ファブリックは 82 Tbps にグローバルにデプロイ
Saturn (2009) 288 の 10G ポートシャシー 10G イーサネットによるホスト接続を実現ファブリックは 207 Tbps に WAN における再利用


Jupiter (2012) 40G イーサネットによるホスト接続を実現外部制御サーバー OpenFlow

クラウドネットワーキング

Cloud Interconnect - 暗号化された VPN、ダイレクトピアリング、お客様のキャリアのいずれかを介してお客様のデータセンターと私たちのデータセンターを接続します。

Load Balancing - HTTP/P を使ってアプリケーションの間で、あるいは TCP/UDP を使ってマシンの間で、負荷を分散します。

Cloud DNS - Google の世界規模の Anycast DNS サーバーネットワークから信頼性が高くレイテンシの低い DNS サービスを提供します。

cloud.google.com/networkingドキュメントホワイトペーパー- Posted by Adam Hall, Head of Technical Product Marketing, Cloud Platform

Magento と CloudMaestro と Google Compute Engine を使ったパフォーマンステスト

2015年8月20日木曜日

* この投稿は、米国時間 8 月 18 日、Lagrange Systems の Senior Sales Engineer である Jason Walp と Corporate Development の VP である Emily Friedberg によって投稿されたもの (US投稿はこちら) の抄訳です。e コマースで重要視されるのは、ウェブサイトの速度と効率です。すべての顧客に対して常にLagrange SystemsCloudMaestroGoogle Compute Engine

最近、同僚によってMagento で開発された、オープンソースのパフォーマンスツールキットを活用してごくシンプルな e コマースストアを構築。

成功事例ガイドを使用して、2 台、4 台、6 台のアプリケーションサーバーをCloudMaestro に統合し、れぞれに対して 3 つのアーキテクチャを定義。

それぞれのクラウドプロバイダーで、同じ仕様を持つコンピューティングリソースを選択し、リソースあたりのコストを算出。

6 台のアプリケーションサーバーを使ったアーキテクチャの例

目標：ページの読み込み時間の 90% を 2 秒未満にすること Compute Engine は、テスト済みの他の主要なクラウドプロバイダーの平均値よりも、優れたパフォーマンスと低いコストを達成

スループットの比較（高いほうがよい）

コストの比較（低い方がよい）

可用性に対するコンピューティングリソースの時間の比較（短いほうがよい）

ウェビナーウェブサイトinfo@lagrangesystems.com- Posted by Jason Walp, Senior Sales Engineer, and Emily Friedberg, VP of Corporate Development, both at Lagrange Systems

Cloudera が Google Cloud Platform で動作保証の対象に

2015年8月19日水曜日

* この投稿は、米国時間 8 月 17 日、Cloudera の Engineering Manager である Vinithra Varadharajan と、Google の Product Manager である Misha Brukman、同じく Google の Partnerships Manager である Hemant Mohapatra によって投稿（USの投稿はこちら）されたものの抄訳です。IDCGoogle Cloud PlatformHadoopGoogle File SystemMapReduceCloudera EnterpriseCloudera DirectorCloudera DirectorCloudera Enterpriseムーアの法則に基づく経済的な料金設定の維持継続使用割引（長時間にわたるワークロードに対する割引料金の自動適用）TCO 計算ツールCloudera DirectorReference Architecture の資料** 2013 年から 2018 年までのデータウェアハウス：データベース解析と Hadoop 市場規模と市場予想：分析家、Matt Aslett のレポートより

- Posted by Vinithra Varadharajan, Engineering Manager at Cloudera and Matt Duftler, Software Engineer at Google

Google Cloud Platform の Media Solutions

2015年8月18日火曜日

* この投稿は、米国時間 8 月 12 日、Google Cloud Platform の Product Marketing Manager である Andy Tzou によって投稿されたものの抄訳です。Google Cloud Platform によるMedia Solutions
Rodeo FXFramestoreAtomic FictionCompute Engine価格設定Cloud Platform でのMedia Solutions Zyncユーザーの皆さんを対象に Zync の最初のユーザーとしてのサインアップを募集していますメディアウェブサイトGoogle Cloud Storage NearlineCloud Networking 製品 iStreamPlanetWowza Streaming Engine ZencoderPandaStreamCompute Engine 上の click to deploy ソリューションお問い合わせ-Posted by Andy Tzou, Product Marketing Manager, Google Cloud Platform

8月19日(水) ハンズオンセミナー: Google Cloud Workshop: はじめてみよう Firebase

2015年8月17日月曜日

Google Cloud PlatformFirebasehttp://eventdots.jp/event/567833

Google Cloud Dataflow と Cloud Pub/Sub が正式リリース

2015年8月14日金曜日

* この投稿は、米国時間 8 月 12 日、Cloud Dataflow の PM である Eric Schmidt (not that Eric) と Cloud Pub/Sub の PM である Rohit Khare によって投稿されたものの抄訳です。Google Cloud PlatformCloud DataflowCloud Pub/SubBigQueryゲノミクス解析MapReduceFlumeJavaMillwheel

バッチおよびストリーム処理の統合コンピュテーションモデルを提供する Cloud Dataflow Cloud Dataflow の正式リリースにより、以下のメリットが得られます

1. 完全に管理され、耐障害性と可用性が高く、SLA が適用されるバッチおよびストリーム処理サービス。

「私たちは Cloud Dataflow を利用して、私たちの現在の Hadoop クラスタが抱える弾力性の課題を克服しようと取り組んでいます。BigQuery にデータを取り込むための基本的な ETL ワークフローに適用するという形で使い始め、その後、本格的なクリックストリーム処理・分析に移行しました。そのおかげで、私たちのシステム全体のパフォーマンスが大幅に向上し、コストも削減できました」

Sudhir Hasbe, Zulily.com ソフトウェアエンジニアリングディレクター

「Qubit のリアルタイムデータサプライチェーンの現行バージョンは、Google の MillWheel の論文で説明されていた画期的なストリーム処理の考え方に大いに触発されたものです。その原点に立ち返り、Cloud Dataflow 上でストリーミングパイプラインを構築できることをうれしく思います。Cloud Dataflow は約束されていたように、耐障害性と可用性が高いデータ処理システムとなっており、多様な機能を実現できる素晴らしく強力な API も用意されています」

Jibran Saithi, Qubit リードアーキテクト

2. 無秩序なデータを大量に処理する際に正確さ、レイテンシー、コストのバランスを取る包括的なモデル。これらの考え方が Cloud Dataflow のプログラミングモデルの主要要素を支えています。

「ストリーミングに対応する Google Cloud Dataflow は、Wix.com の時系列アナリティクスプラットフォームの要件に完全に適合しています。特に、Cloud Dataflow のスケーラビリティ、低レイテンシーデータ処理、耐障害性の高いコンピューティングはぴったりです。Cloud Dataflow では、幅広いデータ群の変換およびグルーピング操作により、複雑なストリームデータ処理アルゴリズムを実装できます」

Gregory Bondar 博士, Wix.com データサービスプラットフォーム担当シニアディレクター

動的なワークリバランシング技術パートナーを増やしTamrSalesforceClearstoryspringMLClouderadata ArtisansApache Flink

「Google Cloud Platform との Salesforce Wave に関するコラボレーションは、私たちにとってエキサイティングな取り組みです。Google Cloud Dataflow との統合により、ビジネスユーザーに洞察を提供する Wave の機能がさらなる進化を遂げます。企業はマシン生成データのような多様で膨大なデータセットから、顧客に関する洞察をほぼリアルタイムで引き出せるようになります」

Olivier Pin, Salesforce.com Wave Analytics プロダクト管理担当 VP

「Tamr と Google Cloud Dataflow は、人々がより簡単に社内の重要データや分散コンピューティング資産にアクセスして利用できるようにしてくれました。Google Cloud Platform 上での Cloud Dataflow と Tamr の組み合わせによって、企業は自社データをインターネットスケールで接続し、充実させることができます」

Andy Palmer, Tamr 共同創設者兼 CEO

Cloud Dataflow は、Google Cloud Platform やサードパーティーのサービスおよびデータストアとシームレスに統合されます

「Cloud Dataflow と Cloud Pub/Sub によって得られる生産性のメリットに非常に期待しています。これまで使ったところでは、例えば、以前に Spark を使って構築するのに 6 カ月以上かかったものを、半日で書き換えることができました」

Paul Clarke, Ocado 技術ディレクター

Google Cloud Pub/Sub も、Google におけるこの 10 年のイノベーションに支えられています。アルファ版とベータ版を試用したお客様のために 1 兆件のメッセージを送信したことが、Cloud Pub/Sub のパフォーマンスのチューニング、v1 API の改良、各種機能の基盤としての安定稼働の確保に役立ちました。Cloud Pub/Sub は、Cloud Dataflow のストリーミング取り込み、Cloud Logging のストリーミングエクスポート、Gmail のプッシュ API、Cloud Platform のお客様が行う本番ワークロードのストリーミングの基盤として機能し、このワークロードストリーミングのメッセージオペレーションは 1 秒当たり最大 100 万回に上ります。

こうした多様なシナリオは、Cloud Pub/Sub が、よりシンプルかつ堅牢で柔軟なアプリケーションの作成を支援する 1 つのグローバルなマネージドサービスであり、信頼性の高いリアルタイムメッセージングを実現するように設計されていることを示します。

Cloud Pub/Sub は、開発者が作成したサービスを相互に、また Google API やサードパーティーのサービスと接続します

Cloud Pub/Sub はアプリケーションやサービスの信頼性の高い統合に加え、ビッグデータストリームのリアルタイム分析に役立ちます。従来のアプローチでは、キューイング、通知、ロギングの各システムが必要で、それぞれに固有の API があり、耐久性、可用性、スケーラビリティがトレードオフの関係にありました。Cloud Pub/Sub は 1 つの API で広範なシナリオに対応しており、前述のようなトレードオフがないマネージドサービスであり、ビジネス規模に応じて経済的に利用できます。料金は、所定の使い方で 100 万メッセージオペレーションにつき 5 セントです。

正式リリースは重要なマイルストーンですが、ゴールに到達したというわけでは決してありません。私たちは引き続きイノベーションに取り組んでおり、gcloud pubsub ツールのアルファ版や、新しい Identity and Access Management (IAM) API、Google Developers Console の Permissions Editor の各ベータ版をこのほどリリースしたばかりです。これらにおける改良により、ユーザーは特定のトピックやサブスクリプションに対して特定の操作のレベルでアクセスを制御できます。IAM ACL は、複数の Cloud Platform プロジェクトを社内で、あるいはサードパーティーサービスと接続しやすくします。

始めましょう

私たちは、開発者や企業がビッグデータに関する Google の技術上および運用上の専門知識やノウハウを活用できるように支援を続けており、Google Cloud Platform の今後の展開を楽しみにしています。Cloud Dataflow サイトや Cloud Pub/Sub サイトをご覧いただいて、ぜひ知識を深めてください。そしてフィードバックや、新しいコネクタのアイデア、あるいは私たちに広めてほしい新しいパブリックデータフィードもお知らせください。

- Posted by Eric Schmidt (not that Eric), PM Cloud Dataflow & Rohit Khare, PM Cloud Pub/Sub

アーティストやプロの創作家たちを支えるメディアソリューション

2015年8月13日木曜日

* この投稿は、米国時間 8 月 10 日、Google Cloud Platform の Product Marketing Manager である Andy Tzou によって投稿されたものの抄訳です。JW Marriott LA LiveAvereChaos GroupThe FoundryPixarThinkbox Software世界有数のセキュリティ最も重要と考える部分Zyncユーザーの皆さんにサインアップして頂くGoogle のメディアウェブサイトGoogle クラウドプラットフォームに関するメディアソリューションAtomic FictionFramestoreRodeoFXライブビデオストリーミング SaaS一般向け提供を発表メディアソリューションサイト#RenderMore-Posted by Andy Tzou, Product Marketing Manager, Google Cloud Platfor

Deployment Manager の GA リリースでデプロイが容易になります

2015年8月12日水曜日

* この投稿は、米国時間 8 月 6 日、Technical Program Manager の Chris Crall によって投稿されたものの抄訳です。Google Cloud Deployment Manager

「Wix Media Group では、Google Cloud Platform でのデプロイメントと管理に Deployment Manager を活用しています。さまざまな場所でシステムを簡単にデプロイしたり、新しいサービスの展開に必要な管理ができるようになっているほか、複数のバージョンのコードを同時にデプロイする場合に必要な、柔軟性も確保されています」- Golan Parashi, Wix Media Group Deployment Manager の機能

インフラストラクチャのデプロイをテンプレートに定義し、コマンドラインまたは RESTful API を経由してデプロイします。
テンプレートは jinja や python をサポートしているので、デプロイメントが要求するロジックに、ループ、条件、パラメータ化された入力などのプログラミング構造を有効活用できます。
デプロイメントの表示や削除を行う UI は、 Google Developers Console でサポートされます。
ストレージへのコンピュートからネットワーキングまで、Google Cloud Platform のリソースとの緊密な統合により、デプロイメントのプロビジョニングおよび可視化を迅速に実行します。

アジアでのステージング環境の例

Deployment Manager は何が違うのか

Puppet、Chef、SaltStack、Ansible などの既存のオープンソースの構成管理システムと、Deployment Manager の違いについて、たびたび質問が寄せられます。既存のシステムは優れた構成管理のフレームワークではあるものの、Google Cloud Platform とネイティブに統合されるものは 1 つもありません。

宣言型のシステムである Deployment Manager では、実行したい対象を定義するだけで、Google の内部システムが実行に関連する困難な作業を引き受けてくれます。他の構成管理システムとは異なり、UI が Google Developers Console で直接サポートされるため、デプロイメントのアーキテクチャも確認できます。また、ソフトウェアの管理にあたってリソースを提供できることや、既存のツールを使用できるというメリットもあります。さらに、コンテナに移行して、ビルドの段階で事前にソフトウェア構成を作成し、リソースを管理したり、実行するコンテナを構成することもできます。ぜひ最適な使い方を探してみてください。

開始する

Deployment Manager は Google Cloud Platform にサポートされているため、他の構成管理ソフトウェアのデプロイや管理は必要ない上、利用に追加料金がかかることもありません。こちらから Deployment Manager をお試しの上、Google Cloud Platform でのアプリケーションのデプロイメントが簡単であることをご確認ください。皆さまのフィードバックをお待ちしています。ぜひ、dep-mgr-feedback@google.com までお寄せください。

- Posted by Chris Crall, Technical Program Manager

App Engine アプリケーションのレイテンシーに関するトラブルシューティング

2015年8月10日月曜日

John Lowry によって投稿されたものGoogle Cloud Platform のサポートサービスには、App Engine アプリケーションのレイテンシーを解決するためのお問い合わせが寄せられることがあります。今回の投稿では、この問題の根本的な原因を特定する主な方法についてご紹介します。curlcurl -s -o /dev/null -w "@curl-format.txt" curl \n time_namelookup: %{time_namelookup}\n time_connect: %{time_connect}\n time_appconnect: %{time_appconnect}\n time_pretransfer: %{time_pretransfer}\n time_redirect: %{time_redirect}\n time_starttransfer: %{time_starttransfer}\n --------\n time_total: %{time_total}\n \n time_namelookup: 0.060 time_connect: 0.098 time_appconnect: 0.000 time_pretransfer: 0.099 time_redirect: 0.000 time_starttransfer: 0.144 ---------- time_total: 0.144time_connecttracerouteデベロッパーコンソールcurlリクエストの実時間

アプリケーションの新しいインスタンスの起動によって待ち時間が発生している場合、こうした起動は読み込み要求として、ログでフラグが立てられます。ここではデフォルトのスケジューラ設定で、テストを実行してください。たいていの場合、この設定ではコストと待ち時間の最適なトレードオフが提供されます。設定を変更する場合は、負荷テストを行った上で、その影響について判断してください。また、常駐インスタンスの追加も検討してください。

インスタンスが使用できるようになるまでリクエストがキューで待機していた時間は、時間のかかるリクエストに対する長い保留時間としてログに記録されます。通常、この状態はデフォルトのスケジューラ設定に戻すことで回避できますが、常駐インスタンスの追加が必要になる場合もあります。

静的ファイルを配信したり、リクエストの処理に Blobstore API を使用している場合、これらの配信パスではアプリケーションのコードが一切実行されません。そのため、待ち時間を対象とする個別のテストを行う必要があります。ここでは Google の高性能な画像配信のインフラストラクチャを使用し、待ち時間を改善できます。

時間のかかるリクエストの応答サイズが大きいことがログで確認できる場合、クライアントと Google の間に帯域制限がないかを特定します。

リクエストをキャッシュさせないことで、テスト中の一貫性を確保します。本番の実行時には、HTTP ヘッダー「Cache-Control」を応答に追加し、待ち時間を改善できます。

リクエストで API 呼び出しが行われる場合は、Appstats を使用して呼び出しにかかった時間を特定します。

ログの CPU（ミリ秒）のフィールドの値が高い場合は、リクエストが CPU バウンドとなっている可能性があります。ここでは上位のインスタンスクラスを使用することで、待ち時間を低減できる場合があります。

HTTPS やカスタムドメインを使用している場合は、appspot.com ドメインに対する HTTP リクエストと待ち時間を比較し、これらの要因によって待ち時間が発生していないかを特定します。

減速がコードで発生していると考えられる場合は、アプリケーションのロギングをコードの記録タイミングに追加します。

サポートパッケージGoogle サポートチームへのお問い合わせのページ

お客様の IP アドレス。App Engine に送信されたリクエストに対する、デベロッパーコンソールのログから入手できます。

お客様の App Engine アプリケーションの URL

上記の URL が指定する、ドメイン名の IP アドレス

クライアントから上記 IP アドレスへの、「ping」と「traceroute」の実行結果

先にご紹介した「curl」コマンドの実行結果。このコマンドは数回実行し、標準となる結果を入手してください。

上記リクエストに対するデベロッパーコンソールのログ

ウェビナー開催のお知らせ「新興企業でのリーンオペレーション：4 人のリーダーがその秘密を明かします」

2015年8月7日金曜日

* この投稿は、米国時間 8 月 5 日、Google Cloud Platform Marketing の Ori Weinroth によって投稿されたものの抄訳です。
*創業初期段階に製品化などの目的で行われる資金調達

賢明な技術的選択を行い、バーンレート（月々の支出額）を抑える

重要だが有限なリソース、すなわち社内の開発チームに最大限の力を発揮させる

コスト効率を最大化するために、特定のベンダーへの集中を回避する

ヨリック・フェニックス氏 CTO Issio Solutions

エーリヒ・エス氏 CTO Simple Relevance

グレッグ・ルード氏 CTO AirHelp

ラファエル・ウーザン氏 CTO BillGuard

南北アメリカ申し込みはこちらからヨーロッパ、中東、アフリカ申し込みはこちらからアジア太平洋申し込みはこちらから

- Posted by Ori Weinroth, Google Cloud Platform Marketing

Google Cloud Datastoreでのデータ整理の考え方

2015年8月6日木曜日

* この投稿は、米国時間 8 月 5 日、Google Cloud Platform Developer Programs Engineer の Jon Wayne Parrott によって投稿されたものの抄訳です。Google Cloud Datastore

マルチユーザーブログ

Wiki

Google Cloud Storage マルチユーザーブログ User

Id	Username	Name
1	tonystark	Tony Stark
2	dianaprince	Diana Prince

Post

id	user_id	content
1	1	Hello, world!
2	2	Another post

SELECT * FROM Posts WHERE user_id = {user_id}

エンティティカインド

Key	Data
(Post, 1)	{"user": Key(User, tonystark), "content": "Hello, World!"}
(Post, 2)	{"user": Key(User, dianaprince), "content": "Another post"}
(User, tonystark)	{"name": "Tony Stark"}
(User, dianaprince)	{"name": "Diana Prince"}

datastore.Query(kind='Post', filters=[('user', '=', Key('User', username))])

強い整合性と結果整合性のどちらかを選択できます祖先/1.post
/2.post
/tonystark.user
/dianaprince.user/tonystark.user
/1.post
/dianaprince.user
/2.post/tonystark.user/1.post

Key	Data
(User, tonystark)	{"name": "Tony Stark"}
(User, tonystark, Post, 1)	{"content": "Hello, World!"}
(User, dianaprince)	{"name": "Diana Prince"}
(User, dianaprince, Post, 2)	{"content": "Another post"}

datastore.Query(kind='Post', ancestor=Key('User', username))注： datastore.Query(kind='Post') Wiki /home.page
/ current.revision
/ 05-29-2015-10-30-27.revision
/ 05-20-2015-06-33-11.revision
/another.page
/ current.revision
/ 04-10-2015-11-23-10.revision注： def save_page(ds, page, content):
   with ds.transaction():
       now = datetime.datetime.utcnow()
       current_key = path_to_key(ds, '{}.page/current.revision'.format(page))
       revision_key = path_to_key(ds, '{}.page/{}.revision'.format(page, now))

       if ds.get(revision_key):
           raise AssertionError("Revision %s already exists" % revision_key)

       current = ds.get(current_key)

       if current:
           revision = datastore.Entity(key=revision_key)
           revision.update(current)
           ds.put(revision)
       else:
           current = datastore.Entity(key=current_key)

       current['content'] = content

       ds.put(current)
datastore.Query(kind='revision', ancestor=Key('page', home))def restore_revision(ds, page, revision):
   save_page(ds, page, revision['content'])

ページは 1 秒間に 1 回まで更新できる。

ページ上のクエリとそのリビジョンは強い整合性を持つ。

保存操作では、強い整合性を持つクエリが使用されるため、ページの保存やリビジョンのリストアは、トランザクションとして実行できる。

ページ数が膨大でも、ページの読み書きは高速。

まとめ

本ブログポストで用いたサンプルコードはこちら

Datastore のエンティティ、プロパティとキーについて

強い整合性とデータの構成について

Datastore のトランザクション

- Posted by Jon Wayne Parrott, Developer Programs Engineer, Google Cloud Platform

Google Cloud Platform Japan Blog

UDF を新たにサポートした Google BigQuery で、より “ディープ” なクラウドアナリティクスを！

Google Cloud Platform パートナー、リセリングオプションの利用が可能に

Google Container Engine が GA に

簡単スタートアップガイドのお知らせ

放置されているバックアップデータを今すぐクラウドへ

株式会社ブロードリーフの導入事例 - Google BigQuery で 100 万規模のデータを統合、最短数秒で結果を返すシステムを構築。

目で見る Google のグローバルネットワークインフラストラクチャにおけるイノベーション

Magento と CloudMaestro と Google Compute Engine を使ったパフォーマンステスト

Cloudera が Google Cloud Platform で動作保証の対象に

Google Cloud Platform の Media Solutions

8月19日(水) ハンズオンセミナー: Google Cloud Workshop: はじめてみよう Firebase

Google Cloud Dataflow と Cloud Pub/Sub が正式リリース

アーティストやプロの創作家たちを支えるメディアソリューション

Deployment Manager の GA リリースでデプロイが容易になります

App Engine アプリケーションのレイテンシーに関するトラブルシューティング

ウェビナー開催のお知らせ「新興企業でのリーンオペレーション：4 人のリーダーがその秘密を明かします」

Google Cloud Datastoreでのデータ整理の考え方

12 か月間のトライアル

Labels

Archive

Feed

Company-wide

製品・サービス

デベロッパー