本日、株式会社トップゲート（本社:東京都文京区本郷3-40-11、代表取締役:加藤 昌樹、以下トップゲート）が、日本国内にて Google のトレーニングパートナーとして認定されました。

これを機に、トップゲートは、日本国内のサードパーティー ベンダーとしてはじめて、Google Cloud Platform 認定トレーニングを開始します。本認定トレーニングは、クラウドエンジニアの方々を対象としたもので、Google の「Qualified Developer （認定エンジニア）」の資格を得るための公式の資格試験「CP300」受験の際に受講必須とされるものです。

Google Cloud Platform（GCP） は Google が提供するクラウド プラットフォームの製品群で、導入企業数の増加に伴い、多くの技術者の育成が求められていました。本トレーニングは Google ハングアウトにも対応予定で、自宅や事務所、さらには、遠方からも受講する事が可能です。

公式トレーニングと試験が、サードパーティーにより実施されることにより、クラウドエンジニアの受講機会が増えるため、GCP のさらなる普及が期待出来ます。

【Google Cloud Platform 認定トレーニング】のコース概要

コース種別
・CP301： Google App Engine  (2日コース、税別12万円)
・CP302： Google Cloud Storage (1日コース、税別6万円)
・CP303： Google Cloud SQL (1日コース、税別6万円)
・CP304： Google BigQuery (1日コース、税別6万円)
・CP305： Google Compute Engine (1日コース、税別6万円)

受講特典
受講者には、GCP 利用料500ドル分が無料になるクーポンコードが配布されます。（既に他のクーポンを利用しているアカウントでは利用不可）

【Google Cloud Platform 認定試験】の概要

受験資格：Google Cloud Platform 認定トレーニングを受講している事
受験費用：各US$100、但しトレーニング受講により初回受験無料

試験種別
・CP301： Google App Engine (90分)
・CP302： Google Cloud Storage (90分)
・CP303： Google Cloud SQL (60分)
・CP304： Google BigQuery (90分)
・CP305： Google Compute Engine (90分)
【Google Cloud Platform認定トレーニングの詳細な情報】
http://google-training.jp/cloud-platform/


【本件に関するお問い合わせ先】
株式会社トップゲート　CP300 担当
e-mail： cp300@topgate.co.jp


ラベル:



2013年11月23日、ワン・ダイレクション（英語: One Direction ／略称で 1D）のグローバルイベント「1D Day」が開催されました。このバンドによる7時間におよぶライブストリームで、ライブストリームが流れている間、視聴者がクイズに答えて遊ぶことができるセカンドスクリーンアプリケーションも提供されました。

1D Day は、YouTube 上で開催されたミュージック ライブストリームのうち、過去最大のもので、ライブ中継の視聴者は、772,000人に及び、1070万人がプレイバックしています。セカンドスクリーンアプリケーションは完璧に動作、10 時間の間に 63 万人のユニークユーザーを獲得、ピークトラフィックは、1秒間に9000 クエリでした。

Sony Music のデジタルマーケティングチームの責任者 Genevieve Amphaduh 氏は、 「このアプリケーションがこんなにもはやく現実化するとは、Google App Engine 以外を使っていたらありえない。」と語っています。詳細については、こちらをご覧下さい。

この投稿は、米国時間2014年9月2日に Developer Advocate の Mandy Waite によって投稿されたものの抄訳です。



■ Google Cloud Platform のその他の導入事例はこちらから
ラベル:



Google for Work、 Cloud Platform GBU ソリューションアーキテクト 佐藤一憲

本記事は Google Cloud Platform サイト向けのソリューション ペーパーとして筆者が執筆し先日公開された「Fast and Reliable Ranking in Datastore」を要約したものです。ジョブ アグリゲーションやタスク キューのシャーディングなどの設計パターンを適用して、Google App Engine におけるランキング処理時間を大幅に短縮する方法を紹介しています。

ランキング処理の難しさ
株式会社アプリボットでリード エンジニアを務める鈴木智明氏は、多くの大規模なゲームサービスで直面する問題であるランキング処理に取り組んでいました。

株式会社アプリボットで App Engine リード エンジニアを務める鈴木氏

アプリボット制作の Legend of Cryptids は、2012 年 10 月にアップル社の北米
App Store ゲーム部門ランキング#1を記録
このケースでのランキング処理の要件は、以下の通りシンプルです。

  • ゲームには数 10 万のプレイヤーが参加している
  • プレイヤーが敵を倒すたびにスコアが増える。ピークで毎秒 300 件程度の更新が発生する
  • トップページ上に常に最新のプレイヤーランキングを表示したい

スケーラビリティやレスポンスの速さが求められないのであれば、ランキングの取得は難しくはありません。たとえば Cloud Datastore 上で以下のようなクエリを実行します。

SELECT count(*) FROM Players WHERE Score > プレイヤーのスコア

このクエリは、特定のプレイヤーよりスコアの高いプレイヤーをすべてカウントします。しかし、プレイヤーが数 10 万人を超える規模のゲームで、プレイヤーがトップページにアクセスするたびにこのようなクエリを毎回実行するのは現実的でしょうか？　鈴木氏はまずこの方法を試しましたが、レスポンスを得るのに数秒かかってしまいました。これでは遅すぎる上、実行コストも高く、プレイヤー数が増えるほど性能が落ちてしまいます。
もっとも簡単な方法は、全プレイヤーをスキャンすること


鈴木氏は Google App Engine の Memcache サービス（メモリ キャッシュ）でランキングデータを保持する方法も検討しました。しかし Memcache サービスはレスポンスはきわめて速いものの、あくまでキャッシュである以上データの永続性がなく、万が一の障害時やメンテナンス時にはデータが失われる可能性がつきまといます。

結局、鈴木氏はすべてのプレイヤーのスコアをスキャンしてランキングを算出するバッチ処理を 1 時間に 1 回実行する方法を選択しました。この方法では、表示されるランキングは最大で 1 時間前の内容となってしまいます。

O(log n) アルゴリズムを探す
上述のような単純なクエリを使う方法では、プレイヤーより高いスコアを持つすべてのプレイヤーをスキャンしなければなりません。このアルゴリズムの計算量は O(n) です。すなわち、クエリの実行時間はプレイヤー数の増加に比例して増加するため、スケーラビリティの高い方法とは言えません。今回の要件を満たすには、計算量が O(log n) になるような、プレイヤー数の増加が処理時間にあまり影響を及ぼさないアルゴリズムを探す必要があります。

コンピュータサイエンスの授業を受けたことがある方なら、二分木、赤黒木、B 木などのツリー アルゴリズムを用いることでデータの探索を O(log n) 時間で実行できること覚えているでしょう。ツリー アルゴリズムは、集約した値を個々のブランチ ノードに置くことにより、ノードの数や最大値／最小値、平均値などの様々な集計にも応用できます。

この特性を利用して Google のエンジニアが Cloud Datastore 向けに実装したオープンソースのランキング処理ライブラリが、Google Code Jam Ranking Library です。Google Cloud Platform が提供する プラチナサポートプログラム に基づいて鈴木氏からの相談を受けた筆者は、鈴木氏のランキング問題を解決する手段としてこのライブラリの評価を行いました。

Google Code Jam Ranking Library を活用し、探索木でスコアランキングを取得

整合性確保と更新スループットのトレードオフ
しかし負荷テストを行う中で、筆者は Google Code Jam Ranking Library の問題点を発見しました。同ライブラリは、ツリーからランキング情報を取得する処理のレスポンスはたいへん速いものの、ツリーに対する更新処理のスループットがかなり低いことがわかったのです。負荷テストによる更新処理を毎秒 3 件より上げると、ライブラリはリトライ エラーを返すようになりました。この状況では、アプリボットの要件である毎秒 300 件の更新をこのライブラリで実現できないことは明らかでした。

なぜ毎秒 3 件程度の更新でリトライ エラーが発生するのでしょうか？ その理由は、ツリーの整合性を維持するためにあります。Datastore では、複数行を更新するトランザクションにおいて強整合性（Strong Consistency）を確保する仕組みとして、エンティティ グループとよばれるメカニズムを提供しています（エンティティ グループについて詳しくはドキュメント「Balancing Strong and Eventual Consistency with Google Cloud Datastore」を参照してください）。Code Jam Ranking Library ではツリー全体を 1 つのエンティティ グループに収めることで、ツリーの整合性を確保する設計になっています。

しかし、エンティティ グループには性能に限界があります。Datastore ではすべてのデータを必ず 3 台以上のサーバーに同期書き込みして高い可用性と永続性を提供するため、加えて強整合性も保証するエンティティ グループについては、1 つにつき毎秒 1 件のトランザクションしか処理できません。もしこの 1 秒の間に同じエンティティ グループに対して他のトランザクションによる書き込みの競合が発生すると、後者の処理はキャンセルされてリトライエラーが発生します。この楽観的排他制御（optimistic concurrency）により、整合性を確保する仕組みです。

つまり Code Jam Ranking Library は、Datastore 上でツリーアルゴリズムを実装することで優れたレスポンスと高い整合性、可用性、永続性を提供するものの、更新処理のスループットはあまり高くないライブラリであることがわかりました。

Datastore チームの解決法：ジョブ アグリゲーション
こうした課題を背景に筆者が米国本社の Datastore チームに問題の解決方法についてアドバイスを求めたところ、同 チームからは「ジョブ アグリゲーション」パターン利用の提案がありました。

ジョブ アグリゲーションでは、多数の更新処理をひとつのトランザクションに集約し、単一のバッチ処理スレッドで実行します。エンティティ グループに同時アクセスするスレッドが 1 つしかないため、トランザクションの同時実行にともなうリトライ エラーやロック待ちは発生しません。そのため、データ構造の整合性を確保しながら高い更新スループットが得られます。ただしトレードオフとしてスレッド数が 1 つに制限されるため、スケーラビリティを際限なく高めることはできません。これと同様のアイデアは VoltDb や Redis のような他のストレージ製品にも見られます。

Datastore チームからのアドバイスに基づき、筆者はジョブ アグリゲーション パターンと Code Jam Ranking Library を組み合わせたサンプル コードを作成しました。App Engine の分散キューサービスである Task Queue を使用して複数の更新処理をタスクとしてキューに保存します。一方、バックエンドでは単一のスレッドで一回あたり最大 1000 件までのタスクをキューから取り出すバッチ処理を実行します。この複数の更新内容を Code Jam Ranking Library にまとめて渡し、全体を 1 つのトランザクションとして実行します。この仕組みにより、上述のようなリトライエラーは一切発生せずに、毎秒 1 件をケタ違いに上回る更新処理が可能になります。

下記のグラフは、サンプルコードを用いた負荷テストの結果です。今回はキューのスループットの変動を最小限に抑えるため、キューのシャーディング（分散化）も組み込みました。最終的にアプリボットに提案したソリューションでは、数時間にわたり毎秒 300 件の更新を処理できることを確認しました。個々の更新内容は、リクエストを受けてから 5 秒程度で Datastore に反映されます。


サンプルコードの性能グラフ

結果的にこのソリューションでは、数 10 万人のプレイヤーを有するゲームサイト上で、毎秒 300 件ほどのスコア更新処理を扱いながら、高い整合性と可用性、永続性を備えたランキング処理を 5 秒ほどの遅延で実行するという要件に応える実装を提案できました。またここで紹介したジョブ アグリゲーション パターン以外にも、線形補間等のアプローチによるいくつかのソリューションも合わせて提案しています。その詳細については「Fast and Reliable Ranking in Datastore」をご覧ください。

注記
本記事で公開されている性能数値は参考用のサンプル値であり、App Engine、Datastore、または他のサービスの絶対性能を保証するものではありません。

ラベル:


今年の6月、米国、ジョージタウン大学の Kalev Leetaru は 2.5 億レコードの完全な GDELT イベントデータベースが BigQuery で利用可能になったことを発表しました。このデータセットは、100 以上の言語に渡る世界中の放送、印刷、およびWebニュースメディアから配信された内容を監視するものです。これは世界で何が起こってるかを知ることができるデータベースです。

GDELT データベースは、BigQuery を通じてアクセスすることができます。2.5 億におよぶデータをリアルタイムでクエリ、さらに、掘り下げて調べることが可能です。BigQuery の使い方についてですが、GDELT では、相関を計算するために使っています。相関を計算すると、例えば、2011 年のエジプト革命の前のタイムラインを追いかけ、他の国々で 35 年間に同様のパターンがなかったかを探すことが可能になります。

BigQuery を使うと、単一の SQL クエリで（GDELT チームはまさにそうやっているのですが）、わずか数分で 250 万以上の相関関係を走査することができるのです。データの一部でははく、GDELTの生データ全体を使うことによって、偉大なる発見をする場合があります。

GDELT チームは、次のようなクエリを走らせています。

SELECT
  STRFTIME_UTC_USEC(a.ending_at, "%Y-%m-%d") ending_at1,
  STRFTIME_UTC_USEC(b.ending_at-60*86400000000, "%Y-%m-%d") starting_at2,
  STRFTIME_UTC_USEC(b.ending_at, "%Y-%m-%d") ending_at2,
  a.country, b.country, CORR(a.c, b.c) corr, COUNT(*) c
FROM (
  SELECT country, date+i*86400000000 ending_at, c, i
  FROM [gdelt-bq:sample_views.country_date_matconf_numarts] a 
  CROSS JOIN (SELECT i FROM [fh-bigquery:public_dump.numbers_255] WHERE i < 60) b
) b
JOIN (
  SELECT country, date+i*86400000000 ending_at, c, i
  FROM [gdelt-bq:sample_views.country_date_matconf_numarts] a 
  CROSS JOIN (SELECT i FROM [fh-bigquery:public_dump.numbers_255] WHERE i < 60) b
  WHERE country='Egypt'
  AND date+i*86400000000 = PARSE_UTC_USEC('2011-01-27')
) a
ON a.i=b.i
WHERE a.ending_at != b.ending_at
GROUP EACH BY ending_at1, ending_at2, starting_at2, a.country, b.country
HAVING (c = 60 AND ABS(corr) > 0.254)
ORDER BY corr DESC

このクエリには、２つのサブクエリがあります。小さいほうは、2011年1月27日のエジプトの革命から30 日さかのぼったエジプトでの出来事について確認しています。左側のデータは、GDELT を通じて確認したエジプト革命の 30 日前の各国の状況です。最初のセットと、左側のセットを組み合わせることにより、BigQuery が100万を超える組み合わせがリアルタイムで計算されます。表示については、以下 IPython notebook をご確認ください。

BigQuery を実行させ、GDELT は、この 35 年間で、2011 年のエジプト革命に最も近い出来事を探し出しました。数学的あるいは統計的見地からそれらの出来事が最も近いと判断された後、GDELT チームが、それらがなぜ近いと判断されるかについて、深い研究をすすめます。GDELT のKalev による投稿をご覧下さい。

月に１テラバイトまでのデータ処理は無料ですので、GDELT データベースあるいは、公のデータセットを Google BigQuery を使って処理してみてください。

本件は、 Developer Advocate の Felipe Hoffa により8月13日に投稿されたものの抄訳です。

ラベル: , ,


最近のお客様事例によると、Coca Cola はじめ、Google Compute Engine が成功の鍵となっている事例を多くみかけますが、私達は、Google Compute Engine上でアプリケーションがさらに容易に開発できるよう、日々、新たな仕様とツールの開発に努めています。以下、最近のアップデートをご紹介します。

米国およびアジアでの新ゾーンについて
us-central1 と asia-east1 リージョンに対して3番目のゾーン (Available Zones) を追加しました。 これにより、MongoDB のような、高可用性のためにクォーラムベースのアーキテクチャを利用するシステムを、Compute Engine を使って動かすのがより容易になりました。新しく追加された us-central1-f  および asia-east1-c 両ゾーンについては、透過的なメンテナンス（Google の定期メンテナンスがアプリケーションに影響を与えない）が即時に利用できるようになっています。

SSDによる永続ディスクが利用可能に！
Google Compute engine を提供している全てのゾーンで、SSD による永続ディスクの利用が可能になりました。お客様の環境にどれが最適なのかを含め、ブロックストレージオプションについての詳細については、こちらのビデオをご覧下さい。また、こちらに使用法その他について詳細を記載しています。また、永続ディスクの詳細については、こちらのホワイトペーパーをご確認ください。

永続ディスクからのイメージ作成が容易に！
永続ディスクに関していうと、ルート永続ディスクから簡単にカスタムイメージを作成できるようになりました。開発者は、既存の永続ディスクを Images:insert API または、gcutil addimage CLI コマンドのソースとして指定することができます。詳細については、こちらをご覧ください。Windows インスタンスについても同様にイメージを作成することができます。

本件は、8月5日にProduct Manager の Scott Van Woudenbergによって投稿されたものの抄訳です。
ラベル:


7月17日（米国時間）より、Google Cloud Monitoring Read API が、一般の方々にお使いいただけるようになりました。これにより、CPUや、diskIO などの実行中のサービスのメットリックにプログラムでアクセス できるようになりました。たとえば、Cloud Monitoring Read API  と Nagios を組み合わせると、既存の監視/イベントフレームワークに対しプラグインすることができます。あるいは、 Graphite と合わせて使い、既存のグラフにデータを統合することができるようになります。サード パーティーのプロバイダーは、APIを使って、 Google Cloud Platform メトリックを自社の監視サービスに統合することができます。  


Cloud Monitoring Read API は、現在、そして過去のメトリックデータを 30 日間にわたって遡り、クエリ することが可能です。また、ラベルを使ってデータをより特定のメトリック（例えばゾーン毎）にフィルタすることができます。現在、Cloud Monitoring Read API は、以下の Cloud Platform servicesから、メトリックタイムシリーズデータを読むことを可能にしています。 
Google Compute Engine - 13 メトリック
Google Cloud SQL - 12 メトリック
Google Cloud Pub/Sub - 14 メトリック

Google は、利用できるメトリックスすべてのリストを提供しています。今後、利用可能な Cloud Platform サービスメトリックスを増やすとともに、既存のサービスに対するメトリックスを強化していきます。以下、スタートページに掲載されているサンプルです。これらメトリックスを試してみてください。サンプルとライブラリーについてはこちらをご覧ください。


例： CPU の使用時間に関するシリーズデータ

GET \
https://www.googleapis.com/cloudmonitoring/v2beta1/ \ # Access API
projects/YOUR_PROJECT_NAME/ \ # For YOUR_PROJECT_NAME
timeseries/ \ # get time series of points
compute.googleapis.com%2Finstance%2Fcpu%2Fusage_time?\ # of CPU usage
youngest=2014-07-11T10%3A29%3A53.108Z& \ # with this latest timestamp
key={YOUR_API_KEY} # using this API key

本内容は2014年7月17日に配信されたものの抄訳です。
ラベル:



今後、IT業界において、クラウドとモバイルは、ビジネスの中心になるでしょう。そのことが牽引材料となってか、ガートナーの調査では、企業のセキュリティに対する投資が増大しており、本年のコンピューターのセキュリティ業界の売り上げは、2013年に比較し、7.9％ 増の 710 億ドルに達しています。企業がより効果的に投資を行えるよう、クラウド ベンダーが、インフラのセキュリティについて可視化することが重要だと考えています。Google のクラウドソリューションを採用するお客様は、以下に代表されるレポート結果に従い、Google のシステムが各企業のセキュリティ基準を満たしているか否かの判断をすることができます。

現在、Google のクラウドは、 ISO 27001 認証、 また、 SOC 2 and SOC 3 Type II レポートを取得しています。これらは、最も広く認識され、国際的に認められた独立したセキュリティ コンプライアンス レポートです。 適用範囲は、Google Apps for Business そして Education、Google Cloud Platform、さらには、Google+ やハングアウトまで、拡大されています。必要に応じてどなたでも弊社のセキュリティをご確認いただけるよう ISO 27001 認証、そして、新たな  SOC3 レポート について Google Enterprise のセキュリティ ページに掲載しました。
Google は、お客様のデータを安全な環境下で保つことができるよう、現在、セキュリティに関するフルタイムのエンジニア450名を雇用しています。Google Apps for Government 用の FISMA （米国連邦情報セキュリティ マネージメント法）、Google Apps for Education　用のFERPA （家庭教育の権利とプライバシーに関する法） や COPPA （児童オンライン・プライバシー保護法）、保護された健康情報を扱う組織のための HIPAA （医療保険の相互運用性と説明責任に関する法律）ビジネスアソシエート契約、など、既に適用されているものも含め、今後も、コンプライアンスの遵守、安全性の強化に努めて行きたいと参ります。

本内容は、2014年8月27日にGoogle Apps  Director of SecurityPosted の Eran Feigenbaum によって投稿された内容の抄訳です。
ラベル: