こうした声に応じ、Google ではゲーム業界に特化した Google Cloud Platform 入門セミナーを開催しています。定員 15 名までの小規模なセミナーなので質問やディスカッションがしやすく、また実際の導入事例をもとに説明する実践的なセミナーです。

例えば前回 11 月に行ったセミナーでは、以下のコンテンツでお話ししました。

  • Google Cloud Platform 概要: Google Cloud Platform チームの福田が、Google Cloud Platform 概要を分かりやすくご説明。
  • ゲストスピーカー登壇:  ゲームインフラ構築で豊富な実績を持つgrasys 長谷川さんが、Google Cloud Platform ユーザーとして生の声を。具体的なゲームインフラアーキテクチャーやソリューションまで突っ込んでお話いただきました。
    1
  • 導入事例詳細: 海外でのゲームログ分析の最新動向:
    Google Cloud Platform チームの Oyvind と八木橋が、
    1. バッチ処理プロセスの高速化
    2. データ分析ソリューション構築の高速化
    3. バッチ処理からリアルタイム処理への変換による高速化
    など、ゲームにおける Google Cloud Platform とデータ分析のトレンドを解説しました。
    2
    (US DeNA での BigQuery と App Engine 導入事例)


同様のコンテンツで、12 月にもセミナーを開催します。ゲームのバックエンドおよび分析基盤に関わる方ならどなたでも参加可能です。(参加無料、先着順)


ぜひご参加ください。

Nomanini のカスタマイズされた高耐久性の POS ターミナルは、速度と信頼性に定評がありますが、財務処理のバックエンドも信頼できるものでなければいけません。

Nomanini のプラットフォームを使う販売員は、販売手数料を得ることで生計を立てているので、たった一度の販売ミスやほんの数分のダウンタイムでさえ、顧客と売上を失うことにつながるのです。



数百を超えるサーバーに自動でスケーリングを行う Google App Engine は多くのユーザーを獲得し続けています。

私たちは当社のサービス拡大に対応できる敏捷性と、ダウンタイムによって販売員の生活が脅かされないような強固な信頼性が必要でした。

これらを理由に App Engine を選択しましたが、あらゆる処理で Task Queue が、そして財務のトランザクション ストアとして、高可用の NoSQL データベースである Datastore がフル活用されています。

また、すべてのデータがリアルタイムで BigQuery にストリームされ、顧客分析やレポートの作成が行われています。さらに、夜間の調整ジョブでは Datastore から Google Cloud Storage にデータがエクスポートされ、長期的なバックアップに対応しています。



競争の激しい財務テクノロジーの領域では、製品を絶えず改善しない限り取り残されてしまいます。Nomanini はこの 4 年間で、製品のバグを（ほぼ）ゼロにしながら、継続的な革新を可能にするエンジニアリング プロセスを構築しました。

これにより、チームの開発者が 3 人から 6 人に倍増したほか、本番環境でのデプロイ数も 1 か月に 1 件から、 1 日 6 件以上に拡大しています。つまり、開発速度は 120 倍になっているのです。

この変化に対応するために、Nomanini ではトヨタが開発した生産管理方式の「かんばん」を活用していますが、この方式はアジリティを確保する方法として、ソフトウェア業界でも採用されるようになっています。

2011年以降の1 か月単位でのチームの人数と、本番環境でのデプロイ数

開発プロセスを絶えず改善すれば、よりよい製品を作ることが可能になります。さらに、ファームウェアを備えるクライアント向けの新製品の展開やバッテリー寿命の延長など、お客様の利益拡大につながる最新機能も提供できるのです。


組み込まれるシステムにコミットされたコードは、クラウドでホストされる Mercurial ソース コードのレポジトリにプッシュされます。継続的インテグレーション サーバーはこのコードをチェックし、POS ターミナルを対象とする実行可能なバイナリなど、すべてのアーティファクトを構築し Google Cloud Storage にアップロードします。サービスはビルド パイプラインを管理する App Engine で実行され、CI 、テスト、アルファ、ベータ、ステーブルの各フェーズでそれぞれのコミットが追跡されます。

実際に運用されるターミナルは、ベータかステーブルのいずれかのチャネルにサブスクライブされます。アプリケーションの新しいバージョンが利用可能になると、GSM のネットワーク上で Cloud Storage からバイナリが直接ダウンロードされ、インストールとアップグレードが自動で実行されます。

Cloud Storage を利用することで自社のFTP/HTTP ファイル サーバーを管理する必要がなくなるため、運用の簡易化とコストの削減が実現するほか、アップグレード サービスの信頼性も向上します。

リリース パイプライン：新しい CI 版（上 2 つ）と本番のステーブル版（一番下）
ターミナルで収集された診断情報は BigQuery にストリームされます。ここではバージョンごとのコードで測定基準を比較する統計的なテストを実行し、ベータ版のコードがステーブル版から大きくかけ離れたときに自動アラートを生成することで、新たなバージョンの潜在的な問題を把握できます（詳細については、BigQuery と Rを活用する分散システムの監視に関する私のブログをご覧ください）。

また、オフィス周辺のテレビのパフォーマンスやビジネスの測定基準を確認するために Google Cloud Monitoring をフル活用し、問題が特定された場合に SMS とメールでアラートを受信しています。すべてのサーバー ログは BigQuery にストリームされ、問題の調査や監査に必要なログの保存のほか、パフォーマンスの改善点を明らかにすることなどを目的とした分析が行われています。

Cloud Platform で提供されるサービスプラットフォームを Nomanini の小規模なチームで構築したり、あるいは安全で確実にホストすることはほぼ不可能でしょう。

しかし Cloud Platform をベースにすることで、新機能を数時間で開発し、リリースできます。これによってNomanini はお客様の満足度を高めながら、大きな競争優位性を確保できます。

最後に忘れてはいけないのは、当社の製品を革新させる真の原動力は、「より良い製品があれば、地方の村で暮らす人々が明かりをつけたり、遠くにいる大切な人と連絡を取ることが簡単になる」という事実なのです。
Nomanini による GCP の活用についての詳細は、Google の導入事例をご覧ください。


-Posted by Dale Humby, CTO, Nomanini 


Google Cloud Logging は、Google Cloud Platform 上の様々なサービスやアプリケーションのログを収集・保管・閲覧することが可能です。また、Cloud Logging 内に保管するだけでなく BigQuery などに直接エクスポートすることにより、ログの加工や分析を柔軟に行えます。

Google Cloud Logging とは？

主に下記の３つの機能を提供します。
  • ログの閲覧：Logs Viewer により様々なサービスのログを閲覧・検索などができます。
  • アプリケーション・ログの連携：Google Compute Engine の仮想マシンに Logging Agent である google-fluentd をインストールし、アプリケーションのログを Cloud Logging に格納することができます。
    また、Logging API によりアプリケーションから直接 Cloud Logging にログを出力することもできます。この場合、ファイルベースでのログ転送は必要ありません。
  • ログのエクスポート：Cloud Logging 内のログを Cloud Storage のバケット、BigQuery のデータセット、Cloud Pub/Sub のトピックへエクスポートすることが可能です。


Logs Viewer

コンソールのメニューから Logging を選択すると Logs Viewer にアクセスができます。対象のサービスからコンポーネントやリソースを選択していくと、ログを閲覧することができます。下記に、Logs Viewer の特徴的な点を２つ挙げます。
  • ストリーム：新しく追記されたログをリアルタイムに Log Viewer に反映します。
  • ログベースのメトリック：ログから抽出した値をもとに、Cloud Monitoring のメトリックとして取込むことができます。

1

アプリケーション・ログの連携

Google Cloud Platform 上のアプリケーションやミドルウェアのログ連携として、下記２つの方法が提供されています。アプリケーションに適した方法をご選択ください。
  • Cloud Logging Agent：google-fluentd によるファイルベースのログ転送
  • Cloud Logging API：API ベースによるログ転送

Cloud Logging Agent のインストール（ Google Compute Engine インスタンス上）

  1. インストール・スクリプトの取得
    $ curl -sSO https://dl.google.com/cloudagents/install-logging-agent.sh
    $ sha256sum install-logging-agent.sh
  1. sha256sum コマンドの出力結果が、下記と同一の文字列であることを確認
    ec78e9067f45f6653a6749cf922dbc9d79f80027d098c90da02f71532b5cc967  install-logging-agent.sh
  1. インストール・スクリプトの実行
    $ sudo bash install-logging-agent.sh

この段階で Logging Agent が テスト用のメッセージを syslog に出力するため、Logs Viewer から確認ができます。
2

Cloud Logging API の利用

アプリケーションから API 経由で、ログを Cloud Logging に書込むことも可能です。この場合、アプリケーション側では出力先のログファイル等を意識する必要はありません。

下記は Google App Engine 向けに Go 言語で書かれたログ出力のサンプルになります。12行目でコンテキストを取得し、13行目で実際に Info レベルのログの出力を行っています。

 1  package hello
 2
 3  import (
 4      "fmt"
 5      "net/http"
 6      "appengine"
 7  )
 8  … // 省略
 9  func handler(w http.ResponseWriter, r *http.Request) {
10     msg := "Hello, World!"
11
12     c := appengine.NewContext(r)
13     c.Infof(msg);
14
15     fmt.Fprint(w, msg)
16 }

ログファイルを意識せずに、Log Viewer からは下記のハイライトされたログとタイムスタンプを表示することができます。Google App Engine 以外でも Google Cloud Dataflow 上で動作するアプリケーションから同様に API 経由でログ出力が可能です。

3

ログのエクスポート

最後に Cloud Logging に格納されたログを 加工や分析のために BigQuery に出力する方法をご紹介します。エクスポートといっても Cloud Logging から Google Cloud Storage などにファイルとして出力する必要はなく、直接 BigQuery のテーブルにロードできるため、エクポート時に煩雑になりがちなデータファイルや一時ファイルの管理が不要です。

BigQuery へのエクスポートの設定

4

対象サービス、データの種別、データセットを選択後、設定を保存します。一旦、保存が完了すれば日次で下記のような名前でテーブルが作成され、データがストリーミングで出力されます。
<data set>.appengine_googleapis_com_request_log_20151116

テーブル内のログの問合せ  

5

後は、通常の BigQuery の利用方法と同様に BI ツールからのデータ解析や別テーブルにデータを加工して集計するなどの作業を容易に実現できます。
まとめ

  • Logs Viewer によるログの検索・閲覧、リアルタイムの読込み
  • Logging Agent による Google Compute Engine 上のログファイルの取込み
  • Logging API 経由でのアプリケーション（ Google App Engine または Google Cloud Dataflow ）からログの直接出力
  • Cloud Logging 内に蓄積されるログを BigQuery にエクスポート
ラベル: ,


図 1：Google のロード バランシング拠点

https://lh5.googleusercontent.com/QqKprZe-v15u9qaZG46_y84Seh6DxSTxnNTGJsEh1dy7lxrd8zbBXPTRjJNBVS53N0bpjmiKKq-EqroC3lYfjpnuZXjiCHSOgHNHTIXMO3fNgB6GpKka4_3bG2ivawCRtaEqGHZ_

サブネットワーク（VPC）

管理者によるきめ細かな制御を可能にするサブネットワークでは、IP スペースを地域のプレフィックスで区分できます。ここではプライベート IP スペースのすべての論理的な範囲を制御しながら、複数のネットワークを構築しなくても希望するトポロジーを柔軟に作成できます。

また、同じネットワーク内にある異なる目的地の地域ごとの IP レンジで VPN ゲートウェイを構成できるため、VPN のお客様は即座に改善を実現できます。VPN ルートでの制御を強化できることに加え、地域を特定することですべての地域にまたがる単一の IP レンジよりもレイテンシが低減します。サブネットワークはこちらから開始できます。

Google Cloud Router

Google Compute Engine のネットワークとお客様のオンプレミスのネットワーク間で、動的な BGP（Border Gateway Protocol）のルートをアップデートできます。いずれの側のネットワーク トポロジーの変更も BGP を使用して反映され、自動的に処理されるため、トラフィックの中断のないシームレスなエクスペリエンスが提供されます。開始に関する詳細についてはこちらをご覧ください。

アカマイ：CDN Interconnect のプロバイダー

この投稿の冒頭でご紹介したように、アカマイを利用して Google Cloud Platform にあるオリジン コンテンツを配信いただけるようになりました。トラフィックはピアリングの直接リンクを経由して選定されたアカマイの CDN 拠点に送られ、Google Cloud Interconnect の料金体系に基づいて料金が決定されます。CDN Interconnect のプロバイダーとしてのアカマイの利用の詳細についてはこちらをご覧ください。


-Posted by Morgan Dollard, Cloud Networking Product Management Lead

* この投稿は、米国時間 11 月 16 日、Google の Engineering Manager である Rick Buskens によって投稿されたもの（投稿はこちら）の抄訳です。

一連の継続的デリバリーを実施することで、速度と信頼性を確保しながら、コードの変更を本番環境でリリースできるようになります。これをビルド、テスト、リリースのプロセスに組み入れれば、市場のニーズや顧客の要求にすばやく対応することが可能です。

CAテクノロジーズ※1が 2013 年 9 月に実施した調査では、継続的デリバリーを実践することで新しく提供される機能が 21% 増加することが明らかになっています。また、製品の品質が 22% 改善するほか、収益が 19% 増加し、障害の発生が 50% 低下することもわかっています。

さらに、DZone が実施した 2015 Continuous Delivery Survey※2 によると、現在およそ 50% の組織が一部、またはすべてのプロジェクトに継続的デリバリーを導入していますが、これは前年比で 9% の拡大となっています。こうしたメリットがあるとなれば、継続的デリバリーが当たり前のことになるのは時間の問題でしょう。

Spinnaker の発表

本日、ネットフリックスは次世代型の継続的デリバリー システム「Spinnaker」を発表しました。これを活用することで、アプリケーションのデリバリー ライフサイクルをパイプラインと呼ばれる一連のステップとして定義することが可能になり、それぞれのパイプラインを紐づけることで継続的デリバリーのワークフローが構築されます。

各パイプラインは、たとえば「ジェンキンズの作業完了時」など、手動でも自動でもトリガできます。通常、パイプラインはデプロイの段階（テストやプレステージングなど）や推進時（本番環境へのプッシュなど）に組み入れられます。


ネットフリックスと Google が密接に連携した結果、Spinnaker は Google Cloud Platform で利用可能になりました。現在は Google Compute Engine で継続的デリバリーのワークフローを管理できるようになっています。

開始するには、Google Cloud Launcher を使ってSpinnaker をデプロイするか、Spinnaker の GitHub レポにある解説に従って、マシンにインストールしてから実行してください。

詳しくは、Google Cloud Platform での Spinnaker のデプロイについてのチュートリアルをご確認ください。また、Stack Overflow で質問をしたり、Spinnaker の Slack チャンネルで私たちとチャットをすることも可能です。今後数か月の計画としては、コンテナでのサポートの追加のほか、Kubernetes と Google Container Engine での継続的デリバリーへの対応が予定されています。


※1. 「DevOps によって新しいサービスの市場投入時間が 20% 短縮されていることが世界的な IT 調査で明らかに」（2013 年 9 月 12 日に CA テクノロジーズが世界 1,300 人の上級 IT 意思決定者を対象に実施した調査の結果） 
※2. DZone 2015 Continuous Delivery Survey.


- Posted by Andy Glover, Engineering Manager at Netflix, and Rick Buskens, Engineering Manager at Google
Share on Twitter Share on Facebook

Container Registry

Docker Registry V2 API のサポート
Container Registry での Docker イメージのプッシュとプルに、 V2 API を使用できるようになりました。これにより、コンテンツ アドレスのレファレンス、パラレル レイヤのダウンロード、ダイジェスト ベースのプルが可能になります。

1.6 以降の Docker は V2 API に対応しているため、ぜひ最新版にアップグレードしてください。クライアントバージョンを混合して使用されている場合は、Docker 最新のドキュメントで互換性をチェックしてください。

パフォーマンスの向上
内部のパフォーマンステストでは、このアップデートによってイメージのプルにかかる時間は、前のバージョンよりも40% 短縮しています。

高度な認証システム
継続的なデリバリ システム（推奨）をご利用の場合は、さらに簡単に Container Registry を活用できます。詳細とセットアップについては、認証に関するドキュメントをご覧ください。また、Circle、Codeship、Drone.io、Jenkins、Shippable、Wercker など、広く利用されている CI/CD システムとの統合についてはこちらから確認できます。

TwistLock の統合
TwistLock は、レジストリやランタイムでのルール違反の検出とポリシー強制を実行します。先日完了したベータ版では 15 社の顧客において良好な結果が出ています。

TwistLock は Google Container Registry と Google Container Engine で簡単に利用できます。詳しくは TwistLock のブログをご覧ください。



Container Engine

Kubernetes 1.1 のリリースに次ぎ、本日は Container Engine のユーザーに Kubernetes の最新情報をお届けします。このリリースでのパフォーマンスの改善により、高度なスケーリングが要求される環境でも Google Container Engine を活用できるようになりました。他にも下記の改善点にご注目ください。

 ポッドの水平的スケーリングの自動化
ワークロードが急増するなど、エクスペリエンスが一様でないという問題に役立ちます。ここではCPU の使用量に応じ、ポッドがスケーリングを行います。

 HTTP ロード バランサ
サブの URL に対して異なるサービスを使用するなど、HTTP トラフィックに基づいて異なるKubernetesサービスにトラフィックをルートできます。

 再設計されたネットワーキング システム
ネイティブ IP テーブルの導入が可能で、テイル レイテンシを最大 80% 削減します。また、CPU のオーバーヘッドを実質的に除外し、信頼性を向上させます。ベータ版で提供されているこのシステムは、下記のシェルコマンドを実行することで Google Container Engine において手動で有効にできます。
             for node in $(kubectl get nodes -o name | cut -f2 -d/); do
                   kubectl annotate node $node \
                      net.beta.kubernetes.io/proxy-mode=iptables;
                   gcloud compute ssh --zone=us-central1-b $node \
                      --command="sudo /etc/init.d/kube-proxy restart";
             done 
上記と 1.1 のリリースでの他のアップデートは、すべての Container Engine のユーザーに向けて来週に公開される予定です。

ぜひ、Googleコンテナのメーリング リストや Kubernetes on Slack の Google コンテナのチャネルからコミュニティに参加してください。皆さまのフィードバックをお待ちしています。

Google Cloud Platform はご利用されたことがなくても簡単に開始できます。こちらから無料トライアルをお試しください。


- Posted by Kit Merker, Product Manager, Google Cloud Platform
Share on Twitter Share on Facebook
ラベル: , , , ,

自社のデータ センターや物理的なインフラの設置が必要であれば、私たちがこの会社を立ち上げることはできなかったでしょう。NASA のサーバーからのペタバイト（8x1015ビット）以上の衛星画像をダウンロードするためには、ストレージと帯域幅だけでも無理があります。

幸いにも Google Earth Engine プロジェクトでは、公開されているすべてのランドサット画像のためのレポジトリがホストされています。

私たちはこうしたデータをすべて使用できるようになり、コンテナで実行される Google Compute Engine のアプリケーションと、衛星データ間の高帯域リンクが実現しました。もしこのやり方が出来なかったら、データの移行に膨大な時間を費やすことになっていたでしょう。
https://lh3.googleusercontent.com/QT2cNS1U_bsBnH-qQf4JDh895OSkRqliUQNUsHCCGjOljYbhhB1hWZCnE05eKhXN2zO3MAKt1h2_smJTwFBA3KE0JOtVimeUQwYqCW5v8pNJ_AbBoTjeg--KKsQLBqJ5BK_09Myt
Google Cloud Platform では、通常のスペース、電力、冷却、ネットワーキングの問題に対処する必要なく、オンデマンドの仮想スーパーコンピューターを活用できます。もし数年前であれば現在 Google のサービスを用いて行っていることを実行するためには、世界最大のスーパーコンピューターが必要だったことでしょう。

例えば、最近行った分析で起動したプロセッサコアは 30,000 個を超え、16 時間の持続スループットは 1 秒あたり 23 ギガバイトでした。このようなことは、ほんの数年前には想像すらできませんでした。

大規模な作業が終了した数秒後には使用されていたリソースが他の顧客に割り当てられて、次々とユーザーの各々のニーズに応じて活用されていく仕組みは信じがたいほど素晴らしいものです。



アナリストのレポートで Google Cloud Platform for Startups プログラムについて知った私たちは、私達の最初の出資者のベンチャーキャピタル Crosslink Capital を通じてすぐプログラムに申し込みました。

Compute Engine と Google Cloud Storage はすでに利用していましたが、このプログラムのおかげで Google Container Engine、Google Container Registry、Google BigQuery、Google Cloud Monitoring などの Cloud Platform サービスを利用するにあたり、検討材料を得る絶好の機会となりました。

現在、Descartes Labs でこれらすべてのサービスをお客様と共に活用しています。

もし仮にプログラムで 1 年間のクレジットを付与されていなければ、ペタバイト規模の作業を実行できることはなかったでしょう。


Google は寛大にも、支払を開始する前に活動する場所を与えてくれました。Cloud Platform は他のクラウド ソリューションに対してかなりのコスト競争力がある上、スケーリングの能力も備えています。しかも、Google はコンテナといった領域でのイノベーターであるため、Google のスタックにワークロードを移行するのも簡単です。
クラウド ソリューションの導入を検討しているスタートアップは、選択するソリューションが実験の自由を与えてくれるかどうかを確かめることが重要です。限られた予算のなかで、IT 管理ではなく製品開発にこそ活動の重きを置きましょう。 


小規模でも世界を変えるという夢を持っている Descartes Labs のようなスタートアップにとっては、GCP テクニカル チームとのパートナーシップが非常に重要です。

プラットフォームの立ち上げや運用からその価値の最大化まで、Google には本当に力を尽くしていただきました。クラウド コンピューティングの現状打破に向け、Google チームとさらに連携できることを楽しみにしています。


- Posted by Mark Johnson, CEO, Descartes Labs
Share on Twitter Share on Facebook
ラベル:

さらに今回のアップデートにより、数々の新しい方法でGCP アプリケーション内で発生する事象を把握することができるようになりました。

その一部をご紹介しましょう。


コンテキスト ログ

App Engine のアプリケーションや Compute Engine の VM などのリソースへ進むと、タップするだけでそのサービスのログを表示できます。

詳細ビュー

ログのエントリをタップすると、問題の解決に役立つ詳細を確認できます。

検索

アプリケーションやサービスのログのエントリを検索し、具体的な問題を特定して対処できます。

今すぐ Google Play ストア や App Store でアプリをダウンロードしてお試しください。皆さまのフィードバックをお待ちしています。
Share on Twitter Share on Facebook
ラベル:


Google Cloud Monitoring を利用することにより、ミドルウェア・OS を含む運用監視の負荷を大幅に削減することができます。一般的にシステム監視では、商用またはオープンソースの運用監視ソフトウェアで構築・運用を行いますが、その作業の大部分を Google Cloud Platform に任せることができます。

Google Cloud Monitoring の概要

Google Cloud Platform では標準で様々なメトリックを収集していますが、Cloud Monitoring を活用することにより、更に下記の３つのメリットを得ることができます：

Google Compute Engine に Google Cloud Monitoring のセットアップ（Debian Linux）

  1. Stackdriver API Key の生成
    API Key を未取得の場合、Cloud Monitoring API ページから作業を行います。
  1. Stackdriver agent のインストール
    $ curl -O https://repo.stackdriver.com/stack-install.sh
    $ sudo bash stack-install.sh --api-key=<STACKDRIVER_API_KEY>
  1. インストール後の確認作業
    $ /opt/stackdriver/stack-config info
    Stackdriver Host Info Dump
    Resource Id: 012345678901234567890
    API Key: ABCDEFG01234567890
    Error talking to Stackdriver gateway No JSON object could be decoded
    [ ok ] stackdriver-agent is running.
    Agent status:  Agent config snippets:
    [ ok ] stackdriver-extractor is running.
    Extractor status:  Extractor sample data:
    {
     ...[省略]
    }
    * この他にもChefやPuppetを用いた自動インストールの方法も紹介しています。
この時点で OS 上の Stackdriver Agent からメモリ使用量やプロセス数などのメトリックの収集が開始されます。
console

Nginx プラグインの活用

更に OS 上でエージェントとして動作する強みを生かし、インストール済みの Nginx からメトリックを収集します。
  1. ステータス情報の有効化
    「/etc/nginx/nginx.conf」に下記のエントリを追加し、Nginx 側でステータス情報の取得を可能にします。その後、Nginx を再起動します。
    server {
       listen 80;
       server_name local-stackdriver-agent.stackdriver.com;
       location /nginx_status {
         stub_status on;
         access_log   off;
         allow 127.0.0.1;
         deny all;
       }
       location / {
         root /dev/null;
       }
    }
  1. Nginx プラグインの有効化
    「/opt/stackdriver/collected/etc/collectd.d/nginx.conf」ファイルを作成し、下記のエントリを追記します。

    LoadPlugin "nginx"
    <Plugin "nginx">
     URL "http://local-stackdriver-agent.stackdriver.com/nginx_status"
    </Plugin>

  2. Stackdriver agent を再起動します。
    $ sudo /etc/init.d/stackdriver-agent restart
    [....] Restarting Stackdriver metrics collection agent: stackdriver-agent
    option = Hostname; value = 5024118606912828902;
    option = Interval; value = 60.000000;
    ...
    Created new plugin context.
    . ok

Cloud Monitoring に Nginx プラグインが有効化されたことが認識され、コンソール上に Nginx 用のタブが追加されます。
console

まとめ

Share on Twitter Share on Facebook
ラベル: ,

Maven Central Repository に API でアクセス

Google は、Java や Python、Node.js、Ruby から Cloud Storage にアクセスするための API ライブラリを提供しています。これらのライブラリは、Maven リポジトリ バケットへのアクセスに利用できます。

たとえば以下のコードは、“maven-central” ストレージ バケットのすべてのエントリを一覧表示します。
Maven Central と Cloud Platform 上のミラーについて詳しく知りたい方は、Jason van Zyl 氏の投稿をご覧ください。
**Java is a registered trademark of Oracle Corporation and/or its affiliates.


- Posted by Ludovic Champenois, Google Software Engineer

Share on Twitter Share on Facebook

チュートリアル、Use Firebase and Google App Engine in an Android App（Androidアプリで Firebase と Google App Engine を利用）では、Firebase に「to-do list（やることリスト）」を保存し、App Engine 上で実行されているバックエンドロジックを使って、毎日リマインダーメールを送信する Android アプリを作成する手順を解説しています。

このチュートリアルでは、以下の技術を使う方法が学べます。




- Posted by Benjamin Wulfe, Firebase
Share on Twitter Share on Facebook
ラベル: ,

- name: managed-by-puppet
 type: compute.v1.instance
 properties:
   zone: us-central1-f
   machineType: https://www.googleapis.com/compute/v1/projects/<your_project>/zones/us-central1-f/machineTypes/f1-micro
   disks:
   - deviceName: boot
     type: PERSISTENT
     boot: true
     autoDelete: true
     initializeParams:
       sourceImage: https://www.googleapis.com/compute/v1/projects/debian-cloud/global/images/debian-8-jessie-v20150818
   networkInterfaces:
   - network: https://www.googleapis.com/compute/v1/projects/<your_project>/global/networks/default
     accessConfigs:
     - name: External NAT
       type: ONE_TO_ONE_NAT
   tags:
     items:
       - http-server
   metadata:
     items:
     - key: startup-script
       value: |
         #!/bin/bash
         apt-get install -y puppet


         cat <<EOF >> /etc/puppet/puppet.conf
         
         [agent]
         server = <puppet_master_instance_name>
         EOF


         systemctl enable puppet
         systemctl restart puppet


このテンプレートを使って Deployment Manager を実行すると、Deployment Manager が新たな Debian ベースの f1-microインスタンスを作成し、テンプレートの  metadata セクションの  startup-script  属性で定義されるスタートアップスクリプトを実行します。このスタートアップスクリプトは、以下のアクションを実行するよう構成されています。



新たなインスタンスを作成し、接続する

以下のコマンドを実行し、Deployment Manager のテンプレートに基づいてデプロイメントを作成します。

$ gcloud deployment-manager deployments create managed-by-puppet --config web-server.yaml

これで Puppet ノードとして構成された新たな  f1-micro インスタンスが作成されました。

追加で同一のデプロイメントを作成する場合は、上のコマンドを再度実行し、 managed-by-puppet の部分に新たなデプロイメント名を置き換えてください。


保留中の証明書要求を承認する

各 Puppet ノードインスタンスは、証明書要求を作成し、送信することで Puppet マスターインスタンスに接続を試みます。

残念ながら安全上の理由から、この証明書要求の承認を自動化することはできません。Puppet ノードインスタンスを登録するには、保留中の証明書要求を手動で承認する必要があります。

証明書要求を承認するには:

1. お使いの Developers Console の VM Instances ページを開きます。

2. Puppet マスターインスタンスの隣にある SSH ボタンをクリックし、ブラウザベースの SSH ターミナルを介して皆さんのインスタンスへ接続します。

3. SSH ターミナルで以下のコマンドを実行すると、未処理の Puppet の証明書要求の一覧を確認できます。$ sudo puppet cert list       
結果は以下のようになります。表示される要求は1つだけです。
 [evan@puppet1-puppet-master c2d]# puppet cert list "managed-by-puppet.c..internal" (SHA256) 4D:B3:C2:33:38:

4. 以下のコマンドを実行して、その要求に署名します。<your_project>の部分は皆さまのプロジェクト名に置き換えてください。
$ sudo puppet cert sign                                                
managed-by-puppet.c.(your_project).internal

おめでとうございます！

これで Puppet マスターインスタンスが動作し、新たにデプロイされたインスタンスをPuppet マスターに自動的に接続する、Deployment Manager コンフィグレーションが完成しました。


デプロイメントとPuppetマスターを削除する

使用していないインスタンスに料金を支払い続けることのないよう、デプロイメントとPuppetマスターインスタンスを削除しましょう。

デプロイメントを削除するには:
1. Developers Console の Deployments ページを開きます。

2. デプロイメントの隣にあるゴミ箱アイコンをクリックします。

Puppet マスターインスタンスを削除するには:
1. Developers Console の VM Instances ページを開きます。
2. Puppet マスターインスタンスの隣にあるボックスにチェックを入れます。
3. ページ上部の Delete（削除）ボタンをクリックします。


-Posted by Evan Brown (@evandbrown), Solutions Architect
Share on Twitter Share on Facebook

ラベル:


先月（2015 年 10 月 ）発表された Google Cloud Platform 関連のニュースをブログ記事から振り返ってみます。

[新製品, 新機能]
新しく米国東海岸のリージョン us-east1 が開設され、Compute Engine をはじめ、App Engineと Cloud Datastore が利用可能になりました。Compute User Accounts がベータ版として発表されており、これを使うと Compute Engine の VM インスタンスにアクセスできるユーザアカウントをより柔軟に管理することができるようになります。

[顧客事例]
顧客事例としては、東京映画祭でも登場した「ザ・ウォーク」のレンダリングの事例が紹介されています。この中で、ピークで同時に15,000 コア以上、合計で 910 万コア時間が使われたことが紹介されており、一時的にバーストするワークロードをクラウドで処理することの有効性が示されています。

[パートナー関連]

[Developer Tips]
GCE のインスタンスをラベルを使って効率的に管理する方法が Tips として紹介されています。

[ソリューション]

[その他]
Share on Twitter Share on Facebook
ラベル: