Google Cloud Platform Japan Blog
最新情報や使い方、チュートリアル、国内外の事例やイベントについてお伝えします。
Cloud Launcher を使って人気のソフトウェア パッケージをデプロイする
2015年3月30日月曜日
* この投稿は、米国時間 3 月 26 日、
Google Cloud Platform の Product Manager である Varun Talwar によって投稿されたもの
の抄訳です。
パブリック クラウド プラットフォームでソリューションの構築やデプロイをする最大の利点は、アイデアをアプリケーションへ移行できるスピードにあります。Google は
ハイパフォーマンス VM
や
コンテナベース サービス
からマネージド
PaaS
まで、さまざまなオプションを提供しているので、ユーザー自身が最適なオプションを選択できるようになっています。
VM ベースのソリューションが必要な場合、アプリケーションをデプロイするには、その裏にあるランタイム コンポーネントやパッケージがインストールされ、正しく設定されている必要がありますが、時としてこれには大変な労力と時間がかかります。デベロッパーとしては、設計したりコードを書いたりする仕事に集中したいところですが、ライブラリのデプロイ、依存関係の修正、バージョン管理の問題解決、ツールの設定などの本来の仕事以外に時間を費やしてしまうことも多いでしょう。
そこで Google では、
Google Cloud Launcher
の提供を開始します。これは Bitnami や Google Click to Deploy で設定された 120 種以上のオープンソース パッケージを起動できるサービスです。これにより、デプロイはとても簡単になります。ユーザーはただ、ライブラリからパッケージを選択し、いくつかのパラメータを選択するだけで、数回のクリックでパッケージが起動できます。Cloud Launcher は、設定の作業を省いて開発者がより効率的に作業できるように設計されており、これによりデベロッパーは、アプリケーションとユーザーといった最も重要な事柄に集中することができます。
Cloud Launcher には、Apache Solr、Django、Gitlab、Jenkins、LAMP、Node.js、Ruby on Rails、Tomcat といった開発ツールやスタックが含まれています。また、MongoDB、MySQL、PostgreSQLなどのよく使われるデータベースや、Wordpress、Drupal、JasperReports、Joomla、SugarCRM などのよく知られたアプリケーションも含まれています。これらのパッケージの多くは、Google Cloud Platform 向けに構築され、パフォーマンスが調整されており、また、こうしたパッケージのパフォーマンスの状態表示、カスタムのダッシュボードの作成、クラウド インフラやソフトウェア パッケージのアラートなどが一か所からできるよう、
Google Cloud Monitoring
との統合も鋭意対応中で、今春には Cloud Launcher ですべての
サポート パッケージ
にロールアウトできる予定となっています。
Cloud Launcher では、パッケージを検索したり、Database、CRM、CMSといったカテゴリに絞ってブラウズしたりすることができます。
「Googleとパートナーを組むことによって、サーバーやアプリケーションのデプロイや構成の簡素化を実現できるのは喜ばしいことです。今後 Google Compute Engine との統合を進めていき新しいソリューションを生み出せることに期待しています。優れたユーザー エクスペリエンスを提供することが我々にとって重要であり、Compute Engine は数回クリックするだけで自分の好きなアプリをデプロイする素晴らしい方法を Bitnami ユーザーに提供することができます。」と、Bitnami Inc.の COO である Erica Brescia 氏は述べています。
Cloud Launcher
を使えば、ほんの数分で Google Cloud Platform でお気に入りのソフトウェアパッケージを起動することができるようになります。Cloud Launcher にあるリンクからフィードバックするのを忘れないでください。我々の
メーリングリスト
に参加すれば、アップデートを入手したりディスカッションに参加することもできます。さあ、始めましょう！
-Posted by Varun Talwar, Product Manager, Google Cloud Platform
Apache Flink のための Google Cloud Dataflow ランナーを発表
2015年3月27日金曜日
* この投稿は、米国時間 3 月 23 日、
Product Manager Reid Robison, William Vambenepe によって投稿されたもの
の抄訳です。
多くの人たちが大規模データに潜在する価値のみならず、並列データ処理によってそうした価値を発掘できるようになるということを学んできました。ただし、それを実践に生かすには、高速で容易かつ信頼性の高いデータ処理パイプラインを必要とします。
Google Cloud Dataflow
はこうした要求を満たすように設計されました。これはバッチ処理とストリーム処理のいずれにおいても管理が行われ、高度にスケーラブルでかつ一貫性の高い処理サービスです。バッチおよびストリームを統合プログラミングモデルに融合するため、プログラミングの単純化、パワフルな動作とフルマネージドで頑健性を担保したシステムを提供します。これら最初の 2 つのメリットは、Dataflow プログラミングモデル自体が持つ性質であり、Google により
SDK
を通じてオープンソースでリリースされてはいますが、Google Cloud Platform との連携はされていませんでした。
そこで、Dataflow 処理パイプラインのためのもう一つのデプロイメント オプションを発表します。急成長する
Apache Flink
プロジェクトを推進しているチームは、
Flink のための Cloud Dataflow ランナー
をリリースし、どんな Dataflow プログラムも Flink クラスタで実行可能になりました。Apache Flink はApache においてトップレベルの
新規プロジェクト
とされており、バッチおよびストリームのデータ処理のための API と分散処理エンジンが利用可能となります。
Flink を走らせることにより Dataflow パイプラインは Dataflow プログラミングモデルの利点が得られるのみならず、Flink ランタイムの移植性、パフォーマンス、柔軟性をも得られます。また、カスタムのメモリ管理やコストベースのオプティマイザと共に強靭な実行エンジンが提供されます。さらに、Dataflow パイプラインを Google Cloud Dataflow 以外にも移植できることが保証されます。つまり、Flink ランナーによって、パイプラインをオンプレミス（仮想化またはベアメタル）でもクラウド（VM 上にて）でも実行できるわけです。
Dataflow パイプラインのための本番前デプロイメントのランタイムが 3 種類に増えたため、ジョブにとって正しいプラットフォームや正しいランタイムを選択できるようになりました。ビッグデータが今後も増大し続けることを見越して選択肢の幅を広げておくことができます。また利用可能な Dataflow のランナーには次のものがあります。
Apache Flink、オンプレミスまたはクラウド（今回発表）
Apache Spark、オンプミスまたはクラウド、
Cloudera 提供のSpark 向けデータフロー ランナー
Google Cloud Dataflow、
フルマネージドサービス
（現行版はアルファ版、
こちら
で申込み)
詳細は、Flink 用のGoogle Cloud Dataflow ランナーを制作している
data Artisans
の
ブログポスト
をご覧ください。
移植可能な Dataflow プログラミあングモデルのためのデプロイメントのオプションが増え、大変嬉しく思います。Dataflow ジョブのデプロイ先は問わないので、
StackOverflow
(
“google-cloud-dataflow”
) に是非参加してください。質問も受け付けています。
-Posted by William Vambenepe, Product Manager
かっこ株式会社の導入事例: Google App Engine で動作する SaaS 型不正検知サービス
2015年3月25日水曜日
（写真左:
かっこ株式会社の企画開発ディビジョンのマネージャー 亀山 誠さん
、写真右:
同部署のリードエンジニア 石川 雄介さん
）
オンラインショッピングが一般化し、オンラインストアを運営するビジネスでは、増加するトラフィックの処理はもちろんのこと、セキュリティ面でも、お客様が安心して買い物ができる場所となるように取り組まれているエンジニアの皆さんも多いのではないでしょうか。
Google でも、昨年発表した
PCI DSS の認定取得
をはじめ、安心してオンライン決済の仕組みを構築できるプラットフォームとして、様々な取り組みを継続して進めています。しかし、このような情報セキュリティの文脈ではカバーできない種類のトラブルもまたオンラインストアでは発生します。
例えば、クレジットカードの不正利用によるチャージバック、アフィリエイト目的などでの受取拒否の代引き注文。不正なのかどうかの判断が難しい上に、不正であればオンラインストアにとっての収益阻害要因にもなります。
かっこ株式会社
の SaaS 型不正検知サービスである
O-PLUX
は、このようなトラブルへのソリューションの１つです。O-PLUX は統計解析によって過去の不正取引の手口や傾向と類似しているかをリアルタイムに分析・検知する審査サービスとして SaaS 型で提供されています。利用している全ての会社からのデータを分析し、常に最新の不正手段に対応でき、利用企業全体でネガティブな取引の情報（詐欺/未回収/クレームなど）を共有できます。
Google App Engine
を使い
Google Cloud Platform
で動作する O-PLUX について、かっこ株式会社の企画開発ディビジョンのマネージャーである亀山 誠さん（写真左）、同部署でリードエンジニアの石川 雄介さん（写真右）にお話をお聞きしました。
かっこ株式会社について、そしてお二人の会社での役割について教えてください。
亀山さん:
私は創業メンバーの 1 人なのですが、元々創業メンバーは同じ会社で、インターネット関連の決済代行サービス事業者で働いていました。クライアント企業の代わりに債権を引きとり、回収、請求代行をしてその分手数料を貰うというビジネスモデルで、不良の債権かどうかを審査しなければならない。そのため過去の不良取引の傾向から新規取引の不良可能性を予測する、という統計的なアプローチを採用していたのですが、この考え方をより広範に適用できると考え、かっこ株式会社を創業し、インターネット広告関連等の不正検知のコンサルティング事業を始めました。
その中で、インターネットにある不正の多くは共通したロジックで解決可能だということがわかってきて、そのロジックをもとに SaaS 事業として O-PLUX をはじめました。また、統計の解析の技術を使ってマーケティングにも転用できるということで、そのコンサルティングやサービス化検討もしています。
石川さん:
亀山は開発部門の総責任者。私はインフラを担当し、アプリケーションでエラーが発生した場合のエラーの原因調査や、システム上手作業で行わなければならないツールの実行や、データ投入を実施するチームのリーダーをしています。Google への問い合わせも私がしています。
現在 O-PLUX を利用している会社はどのような企業で、何社くらい利用しているのですか？ また、競合企業があるなら教えてください。
亀山さん:
大手 EC サイトを含め、2000 サイトくらいで利用されています。国内でトータルの不正検知というサービスをやっているところはないですね。海外企業でよく比較対象になるのは、FraudNet を提供している The 41st Parameter 社や、ReD Shield を提供している ReD 社があります。
EC が拡大し続けている中でこその、課題解決のためのサービスということですね。大まかにどのようにサービスをお客様に提供しているのかお聞かせください。
亀山さん:
Web API と管理画面というかたちで提供しています。API については、まずお客様の EC サイトで注文が入ります、そのエンドユーザーが、コンビニ後払いやクレジットカードを選択し、注文となった際に、その注文の情報と Javascript 経由で取得したブラウザの情報を送信してもらい、その情報から過去の傾向や統計解析した検知モデル、それに外部データを用いて、その決済の未回収のリスクを算出し、危ないかどうかのレスポンスを返すものです。審査は数秒程度で、クレジットカードの与信審査と同じくらいです。そこで、OK, NG 白黒つくものもありますが、お客様のポリシーによって、グレーゾーンを設けることができ、グレーゾーンの注文は、管理画面でお客様の担当者の方に白黒つけてもらう、というような仕組みになっています。
O-PLUX の構築をはじめたとき、はじめから Google Cloud Platform を使うことを決めていたんですか？
亀山さん:
元々 Google App Engine が出たころにさわったことがあったんです。
石川さん:
元々 1 人で作っていたんですよね。
亀山さん:
そう、1 人だったので、ハードウェア壊れただとかそういうことに対処することは実質不可能で、IaaS サービスを使うにしても、OS とかミドルウェアだとか見なければならないことが多く、1人では無理で、アプリケーションだけに集中するために PaaS サービスである GAE を選びました。Heroku だとか他の候補もあったのですが、さわったことがあるという親しみもあったし、オートスケールするという仕組みも当初からあったことから選んだ、という経緯もあります。
最初は亀山さん 1 人ということですが、今開発にかかわっている方はどれくらいいるのですか？
石川さん:
正社員としては 9 人で、それ以外にも学生インターンやアルバイト、協力会社の方々など、20人以上のエンジニアが携わっています。
開発は、どのような開発プロセスで進めているのですか？ そのとき利用しているツールについても教えてください。
石川さん：Scrum ですね。チケット駆動で進めていて、Redmine でチケットをあげてもらい、できることから実施していく、という感じです。
亀山さん:
リリースの頻度は短めで、だいたい週に1回、多いときで 2 回くらい、最低 2 週に 1 回はリリースしています。プログラミング言語は Java で、Eclipse や Git だとか使っています。
石川さん:
開発のやりとりは Slack を使っています。今後 チャットの中で全ての開発フローが完結するようにやっていきたいですね。他には、国外とのやりとりは Skype。ドキュメントや日報は Qiita Team に書いています。
亀山さん:
新しいプロジェクトでは、Play framework だとかを使っているので、その情報であるとか、App Engine に関することについては、Qiita で外部に公開しているメンバーもいます。
App Engine はどのような形で使われていますか？
亀山さん:
お客様からのリクエストを受けるフロントエンドのインスタンスが 100、多いときに 200 くらい起動しています。フロントエンド インスタンスでメインのアプリケーションが実行されていて、Dedicated Memcache にマスターデータとかを置いて、データを使い処理することろで使い、スループットを高めるために、後からでもいいような処理、データ書き込みの処理は多少のタイムラグがあっても構わないので、リアルタイムでなくても良いものは TaskQueue になげています。
Datastore は、当然データの保存、トランザクションのデータ、マスターデータなど全て Datastore に入れているという状況ですね。ほんとにシンプルに使っています。他にはメール用に Mail API、それにバックエンドのインスタンスとして、バッチ処理だとかを動かしているインスタンスがあり、そこで App Engine Cron Service を使ってます。
App Engine 以外に使っている Google Cloud Platform のサービスを教えて下さい。それをどう使っているのかも。
亀山さん:
今使っているのは、App Engine、Google Cloud Storage、それに BigQuery を少し使っていますね。サーバサイドのアプリケーションは全て App Engine で作っています。Cloud Storage については、お客様からデータをアップロードしてもらったりとか、逆にダウンロードしてもらえるストレージとして使っています。App Engine は 2012 年の 6 月からずっと使っていて、昔はインスタンス数も少なかったのですが、今はかなり増えています。
石川さん:
私は、2014 年の 2 月に参加したのですが、その頃とくらべてもお客様の数が拡大して、使うインスタンスも増えていますね。
Google Cloud Platform 以外に使われているサービスは何かありますか？
石川さん:
統計環境は Redshift を使っています。従来の RDB に慣れているコンサル・エンジニアが多いので。ユーザー部門がレポーティングする部分では Tableau を使ってますね。統計部門のアナリストは Redshift に直接アクセスしてデータを取得し、R 言語だとかを使って作業しています。
これまで Google Cloud Platform、特に App Engine を使っていただいてきた中で、率直にどういう感想をお持ちですか。
亀山さん:
サービス立ち上げの時はなくてはならなかった。なかったらここまで広がっていないと思いますね。それか僕が過労で倒れていたか（笑）
なによりサーバがメンテナンスフリーで、アプリケーションに専念できるというは大きかったですね。ミドルウェア、RDB、OS といったところのチューニングを考える必要ないですし、それにスケールする、負荷にあわせてスケール仕組みって自分で作ったら相当大変だと思いますし、メンテナンスも大変だと思います。アプリケーションを動作させておけば、あとは負荷が増えようがなんとかしてくれる、そこは安心できる、その満足度は高いですね。
石川さん:
なかったら会社もなかったかもしれないですね。ただ不正検知というサービスをやってるので、信頼性というところは求められています。多くの企業に導入していくなかで、少しでも処理が遅くなることは、センシティブな問題となり得ます。これからさらに導入企業を増やしていくなかで、我々もアプリケーションを改善していく必要がありますが、Google Cloud Platform にもさらなる速度向上と安定性を求めています。
Google Cloud Platform を今後こういう形で使いたい、と考えていることはありますか？
亀山さん:
Google Container Engine には興味があります。製品に使うのはまだ先だと思いますが、社内の統計分析環境の新しいツールを作るとか、社内の新しいビジネスに使ったり、SaaS 事業でもマーケティング系の新しいサービスを作っていきたいと思っているので、そういうプラットフォームの候補として検討すると思います。
石川さん:
先ほど Redshift 使っていると言いましたが、以前 Google Cloud Platform のイベントで、データが大量になるほど BigQuery の方がさくさく動くというのを聞いて、今後データが増えてきたら BigQuery の利用を検討したいと思います。また、現在 App Engine を使っていますが、開発メンバーも増えてきているので、Compute Engine に移行する、実際そういう調査をやっているのですが、何かあってお客さんに説明しなければならないときに詳しくログ調査をしたりできるようにしたりだとか、普通のサーバとして使う場面が必要になってきたと思っています。
それで Compute Engine にすることで、Fluentd でログ回収し、BigQuery に繋いだりだとか、Tableau とも BigQuery は繋がるようなので、もっと速くお客様にデータを見せられるようにしたい。今は 1 日 1 度のタイミングなので、見れるのが前日のデータだけになってしまう。そこにもリアルタイム性を出していけるかと思っています。
亀山さん:
Manged VM 含め段階的に考えていきたいですね。
O-PLUX を含め SaaS 事業の今後について教えてください。
石川さん:
調査レポートを出したりしているのですが、それらをプロダクト化していくようなことも含めて、いろいろなデータを扱っている会社なので、不正検知だけにとどまらず、世の中のためになるような、気を引くようなサービスが出せるんじゃないかと考えています。
不正検知も手口がどんどん進化していますし、EC も一般の人が自由に出品したりという時代になって、求められているニーズがどんどん高くなっているという実感があります。使っているお客様の要望もどんどん厳しくなっているという空気を感じていますね。
亀山さん:
成長とともにプレッシャーも増大している感じですね。注文フローのところに直接繋がっているという、ミッションクリティカルなところで使ってもらっているので。その分僕らも Google のサポートの方に要望を出しますが（笑）。
最後にスタートアップとして成長してきた経験から、他のスタートアップの方に Google Cloud Platform を勧めるとしたらどういうところですか？
亀山さん:
App Engine を使ってきたので App Engine の話になりますが、負荷が高くなったときや、セキュリティ面を Google にまかせて、アプリケーションに特化できる。自分たちのビジネスロジックに特化できるという部分は凄くお勧めできます。
スタートアップにとって、アプリケーションをいかに使ってもらえるかというところが大きいと思うのですが、そこはコンサルティングをやってきたというところが大きかったのですか。
亀山さん:
そうですね。そういった意味でコンサルティングの実績があったこと、最初に大手の会社が新事業を立ち上げるときに、ちょうど出会えたということは良かったです。スケジュールも決められて作るのは大変でしたし、求められるのも高かったですが（笑）
- Posted by Google Cloud Platform Japan Team
■ Google Cloud Platform のその他の
導入事例はこちら
から
Google Cloud Logging: ログデータのパワーを最大限に活用し、ビジネスをドライブする
2015年3月24日火曜日
* この投稿は、米国時間 3 月 19 日、
Product Manager の Deepak Tiwari によって投稿されたもの
の抄訳です。
ビジネスでは、システムやアプリケーション、ユーザーのリクエストなど様々な種類のログデータが大量に生まれます。これらの情報を有効活用すれば、セキュアにシステムの問題をデバッグしたり、ビジネスに役立つ情報を発見したりすることができます。
しかしその一方で、ログ管理は複雑です。大量に流れてくるデータを管理し、ピーク時の処理に対応し、早く効率的にスケールして、リアルタイムのデータを分析することが必要になるからです。
そこで今回、
Google Cloud Logging
をベータ版をリリースします。これは、
Google Compute Engine
や
Google App Engine
のログを一箇所にまとめ、確認、分析し、エクスポートできるサービスです。
Google Cloud Monitoring
とあわせて、日々増えるオペレーションとビジネスの情報を管理ができるパワフルなセットとなります。
Cloud Logging の主な機能は以下の通りです。
一箇所でのログデータのインジェスチョンと確認
リアルタイムでのログデータの検索
リアルタイムでのログデータの分析
長期ログデータをアーカイブ
すでに Cloud Logging を利用している Wix は、次のように述べています。
“ Wix では、BigQuery を用いて Compute Engine の自動スケール化されたデプロイメントのログを分析しています。
BigQuery へ大量の システムログ データを送ってシステムの健康状態やエラー率を調べており、時系列データを生成してそれを Google Cloud Monitoring で統合し、システム パフォーマンスとビジネス メトリックをモニタしています。運用状況を詳しく知るには不可欠なツールです。”
- Dmitry Shestak, Engineer@Infrastructure team, Wix
主要な機能
ログ インジェスチョンと確認：
ログを一箇所にまとめ、分析しやすいようにしておくのは重要です。Cloud Logging は、以下に方法でこれを可能にします。
Compute Engine VM
(20 を超える
ログタイプ
) のログは
fluentd
エージェント経由で自動で収集され、カスタム設定で他のログを収集することも可能です。
Compute Engine の Activity
ログは、システムのアクションをすべてログにし、API もデフォルトでオンになっています。エージェントのインストールは不要です。
システムログ、リクエストログ、アプリケーションログなどの App Engine ログは、すべての App Engine プロジェクトで自動でオンになっています。
Developers Console
の中で、「Monitoring」 の下にある 「Logs」リンクをクリックすることにより Logs Viewer にアクセスできます。
テキストまたはドロップダウンメニューから結果をフィルタ可能
リアルタイムでログデータを検索:
Logs Viewer で、問題の調査やデバッグを素早く実行して、関連する状況を調べることができます。ドロップダウン メニューや最上部にあるフィルタ バーを操作するとログをフィルタすることができ、タイムラインにそってログを確認することができます。
下の画像は、Compute Engine のログをフィルタして、 「Firewall」 サービスのログのみを表示させ、特定のファイアウォール リソースを選択してログを表示させ、それを特定のログ レベルで実行しています。
Logs Viewer にてフィルタした状態
リアルタイムでログデータを分析:
多くのシーンで、複雑なクエリでログデータを分析する必要がでてきます。Cloud Logging では、簡単に
Google BigQuery
へデータを渡し、SQL でデータを検索、統合、確認できるようになります。
BigQuery へのエクスポートは、Logs Viewer の 「
Exports
」タブまたは
こちら
の詳細情報を参照してください。
BigQuery でのログデータ
長期ログデータをアーカイブ:
Cloud Logging では、Logs Viewer にログを 30 日間保存します。これより長い期間データを保存したい場合は、ワンクリックで
Google Cloud Storage
へのエクスポートを設定できます。そこから、さらなるデータの処理や分析のために、
BigQuery
、
Cloud Dataflow
、あるいは何らかの
Hadoop
ソリューションへ転送することも可能です。また、先日ベータ公開した
Google Cloud Storage Nearline
で、より長期のログ保存がより
低価格
になりました。
始めるには:
すでに Google Cloud Platform を使用中の方は、追加料金なしで Cloud Logging をご利用いただけます。BigQuery や Cloud Storage などの Google Cloud Platform サービスのご利用料金は通常通りです。詳細については、
Cloud Logging ドキュメンテーション ページ
をアクセスしてください。
フィードバック
を待ちしています。
- Posted by Deepak Tiwari, Product Manager
Vitess と Kubernetes を使ってクラウドの MySQL をスケールする
2015年3月23日月曜日
* この投稿は、米国時間 3 月 20 日、
YouTube の Software Engineer, Anthony Yeh によって投稿されたもの
の抄訳です。
新しく作ったウェブサイトが急成長して知名度も上がり何度か波に乗ると、予期しない需要に対処するためにスケーラビリティの向上が課題になります。フロントエンド サーバはいつでも追加することはできますが、最終的にはデータベースがボトルネックとなり、次のような事態を迎えます。
読み出しスループットおよびデータ耐久性を向上させるためにレプリカを追加する
書き込みスループットをスケールし、1 台のマシンを超過するデータに対応させるためにシャーディングを導入する
バッチジョブやバックアップのために別のレプリカ群を生成し、それらをライブトラフィックから分離させる
災害復旧およびレイテンシー低減のために、デプロイメント全体を世界中の複数のデータセンターにクローンする
YouTube は MySQL デプロイメントをスケールするのと同様の過程を経ました。（詳細は
こちら
）その結果、毎日数十億ものビデオ閲覧、および
1 分間あたり 300 時間の新しいビデオ アップロード
に対応しています。
このシステムを影で支えているのが我々の開発した
Vitess
プラットフォームです。これによりスケーリング問題を解決すると同時に、それに伴う複雑性がアプリケーション レイヤに影響を及ぼさないようにします。
Vitess は
オープンソース プロジェクト
として入手可能で、コンテナ化された環境に最もよく適合し、
コンテナ クラスタ マネージャ
として
Kubernetes
や
Container Engine
を使用すれば比較的容易に始めることができます。我々は、
Kubernetes がサポートするプラットフォーム
で動作する Vitess 用のデプロイメント構成を作りました。
コンテナクラスターにおいてデプロイが容易になることに加えて、 Vitesss はコンテナクラスターマネージャーを用いることにより様々な恩恵を受けています。例えば以下の点です。
水平スケーリング :
1 つの巨大なノードを作るのではなく、ノードを追加していくことによってキャパシティを増加させる
ダイナミック プレースメント :
クラスタ マネージャによって Vitess コンテナを必要に応じてスケジュールできる
宣言的指定 :
期待する最終ステートを記述するとクラスタ マネージャがそれを生成できる
自己回復コンポーネント :
マシン障害から自動的に回復する
このように、Vitess によって MySQL のストレージ レイヤで耐久性やスケーラビリティが向上し、管理も容易になります。
我々はこの取組みに着手したばかりですが、すでに
Kubernetes で Vitess を実行
できる方もいらっしゃることでしょう。Vitess についての詳細は、
フォーラム
で質問するか、
GitHub
に参加してください。
-Posted by Anthony Yeh, Software Engineer, YouTube
Puppet を Google Compute Engine にワンクリックでデプロイ
2015年3月20日金曜日
* この投稿は、米国時間 3 月 18 日、
Product Manager の Pratul Dublish によって投稿されたもの
の抄訳です。
Google Compute Engine
への
オープンソース Puppet の Click-to-deploy
をリリースします。
Puppet マスター
をすぐに（ワンクリックのみで）セットアップできるようになります。この際、Google Compute Engine でリソースのプロヴィジョンニングと管理を行うための
node_gce
モジュールと
gce_compute
モジュールを組み込みます。
1 つの仮想マシンから数千の管理まで、Puppet はシステム管理を容易にします。Puppet は宣言型言語で、設定の適用に agent/master フレームワークを用います。例えば一般的なウェブ サーバーのデプロイでは、Apache をどう設定するかを定義し、複数の仮想マシンへ素早くデプロイできます。Puppet は世界中の 22,000 以上の会社ですでに利用されており、
Puppet Forge
は様々なシステムリソースのプロビジョニングと管理のための 3,100 以上のモジュールがあります。
「 Puppet の利便性と汎用性を Google に認識してもらえたことは非常に喜ばしい。Google のクリックデプロイにより初の IT 自動化ツールが可能になる。このソリューションによって、Puppet マスター機能の稼働に要する時間が少なくなり、Google Compute Engine におけるプロジェクト管理の完全自動化の障壁を飛躍的に低下させることができる。」と、Puppet Labs の CIO である Nigel Kersten 氏が述べています。
Google Compute Engine でのオープンソース Puppet
の実行について詳しく知りたい方は、
無料トライアルクレジット
を使ってまずは
Puppet マスターをデプロイ
してみてください。この機能についてご意見があれば遠慮なくお聞かせください。また、
プロフェッショナルなサービス
、
プレミアムサポート
、
トレーニング
については Puppet Labs にお問い合わせください。早速デプロイしましょう！
-Posted by Pratul Dublish, Technical Program Manager
株式会社グルーヴノーツの導入事例（後半）：モバイルのための次世代のクラウド プラットフォームを Google Cloud Platform で
2015年3月20日金曜日
グルーヴノーツの Google Cloud Platform 活用事例前半
で
は MAGELLAN を作成するに至った理由や、そのアーキテクチャーについて、また、なぜ Google を Google Cloud Platform を選んだのかについてお聞きしました。
後半では、グルーヴノーツでの開発方法や社内の雰囲気を中心に聞いていきます。
MAGELLAN で作るバックエンドの形
MAGELLAN で可能なこと、こういったバックエンドが実現できるという例を教えてください。
最首さん:
例えば、自動車、車載器からデータが送信されてくるとします。そのときニーズが 2 つあったとして、1 つはデータを 1 時間おきに集計をして、運行管理したいというニーズ、もう 1 つは、水温の急激な上昇だとか、衝突を検知したとか、インシデント管理したいというニーズ。そうすると送信されてくるデータ 1 個 1 個に対して処理をするということと、連続にストリーミング データとして処理をし続けるということが出てきて、それをどう作るかというと、車の台数が 1,000 台とか 2,000 台だったらいいですけど、100 万台となると難しくなるんですね。
僕らの MAGELLAN を使うと、トランザクションをスプリットするトランザクションルーターという機能があって、一方ではどんどんスケーラビリティのあるストレージにデータを投入して、もう一方ではワーカーを動かして 1 個 1 個データを見て、あ、これはやばいというときにアラート処理が動き始めるとか、こういうことが凄く簡単にできるようにしているんですよ。溜め込んだ大量データは BigQuery で後はよろしくなんですが（笑）
プロトタイプ、フィードバック
話が変わりますが、佐々木さんと最首さんはどういう役割分担をしているのですか？
最首さん:
製品の総責任者は佐々木で、社員にいつまでに何をやってこういう機能を先に出す、出さないという指示をしています。これから MAGELLAN をどう売っていこうか、というのは一緒に話していて、僕はどっちかというとお客さんのところに出向いて、仕事とってきたり、コンサルビジネスをしたりというのをやって、佐々木は製品をよりいいものにしていくというの役割分担をしています。
MAGELLAN の開発は、どのように進められたのですか？
佐々木さん:
うちの社内で MAGELLAN の原型になる種みたいなのがあって、それをやろうという話になって Google Cloud Platform を使うということを決めて開発チームが立ち上がって、今 15、6名の体制でやっています。皆新しい技術を追っかけていくのは好きで、エンジニアはその技術を吸収してそれをどう展開するか考えるのは得意なんですけど、そういうことを機能として伝えることとか凄い不得意なんですよね、優秀なエンジニア程。なんでそこを仕切って、だらっとしているところをスプレットシートに書いていくようなことを私がしている感じ。そうこうして落ち着いたのはつい最近なんですけど（笑）、お客さんがついていたので、プロトタイプに近いものは既に導入していたんですね、そこでのフィードバックをもとに MAGELLAN というものを12月の末にリリースしたという感じです。
最首さん:
一番最初は、去年の6月にプロジェクト ランディというものを立ち上げてですね、なんでランディかというとバース（BaaS）を作ろうと思ったんで、バースと言えばランディだろうと（笑）大変不評で。それでこういうのを作ろうと、ホワイト ペーパーを、どういうのをターゲットにして、おおまかにどんなアーキテクチャーで、どんな機能が必要で、それはどんなことをやるもので、というのを書いたんですね、こういうのをやりたいと。こうのがあったら絶対いけると。社内の半分くらいの人間はなるほど、もう半分くらいの人間はポカーンと、一部の人間は意味ないんじゃないかと（笑）。それで、少人数 2 人くらいでプロトタイプを作って、ある程度形ができて大きくして、本格的になってきたところで、よろしくと（佐々木さんへ）
開発のとき、どういうプロセスで進めているのですか？
最首さん:
アジャイルですね。最初はコンセプトありきで、そのコンセプトを実装して、ディスカッションして、また実装してと永遠と繰り返している感じですね。まず作ってみないとわからないことがあるんです。
佐々木さん:
あと使ってみてもらうものがないとわからない、ということで最初 3 社さんに使ってもらって、フィードバックいただいて、SDK も含めてフィードバックをもらいながら次期リリースの内容を決めるというのを私の方でジャッジメントしながら。
最首さん:
MAGELLAN には、シェアードモデルとデディケートモデルとあって、今ベータ リリースしているのはシェアードモデルの方で、ようするにリソースを皆でシェアする。デディケートは専用環境で、そこから営業を始めています。デディケートだとオンライン決済の機能もいらないですし、わかりやすい GUI もある程度なくてもいい。だから基本的な機能が出来あがったタイミングでこっちを売って、自動車関連、ゲーム、流通系の会社に使ってもらっています。そうするといろんな問題が出てくるわけです、こういうの必要だよねとか、ここわかりにくいだとか。どんどんフィードバック受けながらブラッシュアップしているんですよ。
佐々木さん:
案件毎のフィードバックを常に聞いて、次期リリースの機能の棚卸しをリリース前に必ずやってます。それにあわせて皆動いていて、そのマイルストーン毎にどういう機能をリリースをするのか、アジャイルはアジャイルなんですけど、チケット駆動というわけではなくて、スケジュール厳守の開発手法になってます。
開発を進めていく上で、使っているツールは？
佐々木さん:
GitHub を使っていて、GitHub のイシューを中心に使ってますね。そこを中心にディスカッションするし、そのマイルストーンとかアサインも全部そこでやって。あと Slack は結構使っています。お客様毎にそれぞれグループが作れるというのは、セキュリティ上わかりやすく、お客様に導入しやすいし、GitHub が Slack と連携できるので、イシューの変更があった場合、Slack のチャットルームに全部飛ばしてます。あと、常時連絡を取りたいときのツールとしては、音声じゃなくてチャットでいいんで、メールは殆ど使ってないですね、契約上のやり取りをするときに、履歴を残すという使い方で社内の連絡用には使ってないです。ドキュメントは Google Apps、東京と福岡にスタッフがいるので Docs で共有してディスカッションしたり。あと音声つないで東京と喋るとか、必要に応じて福岡に来てもらったりとか。開発チームが殆ど福岡なんですよ。
最首さん:
福岡に拠点があることの良さはいろいろあって、人と人との距離が近く、通勤時間が少なくて、みんな 15 分とかだいたい 30 分以内くらいで通勤しているし、天神のど真ん中、そこそこ都会ですし。一時期は社内でまかない作ってみんなで食べたりしていたんですよ。
佐々木さん:
まかない文化は、2007年くらいに（USの）Google さんに始めていって、そのときのランチミーティングが発祥なんですよ。これいいわ、と思って。それでずっと社内でまかないやりたくて。あの頃は、Google の話が今みたいに浸透してなくて、自分が会社作るときは絶対まかないやりたいなと思ってたんですよ。チームが別れると、いろんな人と話さなくなっちゃうんだけど、ランチが一緒だとしゃべるし、というアドバイスをたまたま Google に行ったときに教えていただいたんです。あと Dogfood の文化も。私が Dogfood の文化を聞いていたので、Google さんの出す製品についてはかなり社内で検証されたものしか出さないと聞いていたので安心感がある。
スピードとビジネスの成長にフォーカスした、クラウドの選択
では最後に、今回 Google Cloud Platform を使っていただいた感想と、今後どう使っていきたいか教えてください。
最首さん:
Google とちゃんと付き合うということによって、これから何をしようとしているのかということを知ることができる。これは僕らのようなサービスカンパニーにとってはとても重要なことです。自分で頑張ってこれからどうしようと考えるのと、もう一つベンチマークとして Google のような巨大な企業が、いろいろな情報に対するアプローチを持ってる会社が今何を考えているのか知れますから。時々、びっくりするようなものが出てくるので、僕らが抱えているニーズにハマったりすると、破壊的なことが起きる。最近、そういうことが多くて恐れ入ってるんですけどね。これが他のベンダーだったら、さっき言ったようにサーバの値段が安くなりましたとか、SSD がついて、早くなりましたとか、それは何のイノベーションでもない気がするんです。
その点について、今選択肢としてはオンプレミスもあるでしょうし、Google Cloud Platform も、MAGELLAN も他のクラウド ベンダーもある中で、どういう基準で選んでいくべき時代だと思いますか？
最首さん:
いろんな観点があると思うんですが、エンドユーザーは自分たちがやろうとしていることがもっとも簡潔にできて、コストがかからないものを選ぶべきだと思います。でもそれは、今までこうだったから、慣れているから、というのは忘れた方がいい。ドラスティックにびっくりするほど変わってきているので、慣れているからと 100 の努力でやっていたことが、1 の努力くらいで済んだりするんですよ。ちゃんと勉強して、ちゃんと調べて、ちゃんと評価して、その中で最適なものを選ぶということが常にエンドユーザーの視点であるべきだと思います。僕らみたいなサービス ベンダーにとって何が重要かというと、コンピューターを安く手に入れることが重要なのではなくて、やろうとしているサービスがドラスティックな結果を生みだせるか、劇的な効果とか、劇的なサービスの変化を世の中にもたらせるか、ということを考えなきゃいけない。今までこうだと思ってきたことが、がらがら変わっているので、あまり先入観なくフラットに今ある技術を評価しなきゃいけないですね、それができなければ人のいいなりになるしかないかなと。
佐々木さんはいかがですか？
佐々木さん:
見てると、どこもかしこもどんな企業も IT 部門がないと駄目な状況になってるんですけど Google の仕組みを使うとあまり必要がない。例えば、データセンター選んで、というのもいらないし、Google Apps を入れてみたいな話から、Google Cloud Platform を使えば直ぐにサービスを作り始められる利便性、BigQuery があればデータをとりあえず投げ込んで SQL をたたけばいい。それをしようとデータベースを何にしようかと考える必要もなく、専門性のある人を連れてこなくてもいいという導入のしやすさ。今までのビジネスを変えずに取り組めるという状況に近くになってきているので、選択肢としてはそういう考え方の方がいいのかなと。
他のベンダーだと結局インフラ エンジニアがいるし、データベースエンジニアいるしと、エンジニアもいないし、人集める方が大変。ゲームがわかりやすくて、今までフロントばかり作ってた人が、ネットワークが必要なゲーム、運用が必要なゲームという流れの中で、その継続していく仕組みを自分たちが持たなければならないという時代におもむろに放り出されたのがゲーム業界の人たちなんですよね。それをやるには人を探さなきゃいけないんですけど、それが IT の人なのかなんなのか、ゲーム会社の人たちはまだ漠然とわかってないんです。そういう人たちに対しては、やっぱり今までフロントに注力できてたんだが、もっと注力できる仕組みとして、他のベンダーより Google の方がいい。
さらに MAGELLAN であったら。
佐々木さん:
その通りです。今ゲーム会社さんも、Ruby on Rails はできないけど、Javascript ならできるということで Node.js で書いてもらっているお客様もいるんですよ。そこだけ今までやってきたことを、ちょっとだけ毛が生えた程度でも学べば、実際に直ぐに導入してもらえて、もう明日から使えるって。それをデータセンター借りてとなると、明日からは使えない。そのスピード感をどれだけ持てるか、という選び方は重要なのではないかと思います。
最首さん:
最近思うんですけど、やっぱり今の時代はできるだけ速くいろんなことがやれた方がいいし、コストもかけないでやったほうがよくて、でも企業経営していく上で SWOT 分析みたいな考えでいくと、その弱みを消して強みを伸ばしてというけれども、弱みなんて消さなくていいんじゃないかと思うんですよ。弱いと思うことはやらない。強みをとにかく伸ばすことに全経営資源投入するみたいな。じゃあ弱いところをどうするのかというと、ここで自分の会社が競争するわけではないので、どっかを使えばいいという時代になってるんだと思うんですよね。会社の弱いところを 1 個 1 個潰していったらとてつもないことになって、それは巨大企業でも成立しない。
コンピューターのリソースも、どんどんトランザクションが増えていくと運用が最も重いコストになるわけですよ。そこにいかに手間をかけないか、インフラに関するノウハウをできるだけ知らなくて済むようにする、という方向が、ひとつ考えていくべきことだと思います。これから IoT のサービスを考えたりだとか、新しいゲームを作りたいという人にとってはインフラのノウハウは重要ではないわけですよね。それよりも本当にビジネスになることをいろいろトライしてみて、本当に世の中に受け入れられるサービスの形を模索しなければならない。そういうところに特化してサービスを作っていくべきだと思うんですよ。なので、是非 MAGELLAN を使ってください（笑）。
- Posted by Google Cloud Platform Japan Team
■ Google Cloud Platform のその他の
導入事例はこちら
から
Google Genomics と Tute で遺伝子変異を研究する
2015年3月19日木曜日
* この投稿は、米国時間 3 月 16 日、 Tute Genomics の
Bryce Daines, Reid Robison, Chris London, Brendon Beebe, David Mittelman と Kai Wang によって投稿されたもの
の抄訳です。
本日は
Tute Genomics
から、科学分野でクラウドベースの技術とビッグデータツールがどのように利用され、高度なゲノミクス研究に役立っているのかをお話しいただきます。Tute は、
85億の遺伝子アノテーション データベースレコード
を
Google BigQuery
を通じて
Google Genomics
のユーザーに公開しています。
ヒトゲノム シーケンシングは臨床医や研究者の双方にとって急速に一般的なものになりつつあり、人間ひとりの DNA 30 億文字すべてを読むコストはわずか数千ドルにまで低下しています。しかしそのような情報は医学や健康にとってどんな意味があるのでしょうか。
Tute Genomics では、知られているすべての遺伝子変異と、それらの病気のリスク、薬物反応、および基礎研究にとって意味のある情報を包括するデータベースを構築することによって、先ほどの問に対する解を探索しています。このデータベースには 90 億のレコードが入っているため、ローカルのコンピュータやサーバーで作業するのは困難でした。だからこそ
Google BigQuery
の良さを実感しているのです。
科学者が BigQuery を用いて Tute データベースに対し高度なリクエストを行い、ある個人のゲノムを、遺伝子変異一般に関する膨大な情報へとリンクさせることができます。この情報には、すでに Google Cloud Platform で稼働している
1000 Genomes Project
のような大規模の公開データさえもが含まれています。
分析すべきデータが膨大なので、BigQuery のようなデータ分析ツールは不可欠です。一般的なコンピュータや VM ではかなり長い時間を要するでしょう。例えば、17 種のプラチナゲノムからの変異種を機能別に高速で数えることができます。88 GB の入力データでも、$ 1 未満で 30 秒程度で結果が得られます。これはもし BigQuery がなければ数分以上、あるいは数時間さえかかることもある作業です。
このデータベースの初期バージョンには 85 億個の遺伝子変異に関するアノテーションが含まれています。情報源には次のものが含まれています。
ClinVar および GWAS カタログの臨床的なアノテーション
1000 Genomes Project から得られる人口頻度
アミノ酸やタンパク質の置換など遺伝子および転写モデルのアノテーション
およびエクソン遺伝子変異の機能シーケンス
さらにこのデータベースには、Conservation スコアと Evolutionary スコア、また、メンデリアン表現型に関連する確率を予測するスコアリングも含まれています。
基礎研究と同様にゲノム シーケンシングが臨床ケアにとってますます一般的になっていくに従い、正確かつ包括的な遺伝子変異データベースが遺伝子情報を理解するうえで不可欠なものとなるでしょう。我々は、遺伝子変異の詳細なアノテーションが Google BigQuery を用いたビッグデータ処理に適合することを理解しました。このことを強く確信したので、
Google Cloud Platform
を通じて、この先例のないデータベースをゲノミクス コミュニティに寄贈したのです。
なにかご質問があれば、Tute Genomics の
こちら
からお問い合わせください。
Posted by Bryce Daines, Reid Robison, Chris London, Brendon Beebe, David Mittelman, and Kai Wang of Tute Genomics
株式会社グルーヴノーツの導入事例（前半）：モバイルのための次世代のクラウド プラットフォームを Google Cloud Platform で
2015年3月19日木曜日
（写真左: 株式会社グルーヴノーツ 代表取締役会長の佐々木 久美子さん、写真右: 同じく代表取締役社長の最首 英裕さん）
スマートフォンのゲーム市場は既に家庭用ゲーム機を超えていると言われほど大きくなり、その中でも人気のあるゲームのバックエンドのトランザクションはどれほどのものなのか、実際に運用しないことには ”想像もできないほど” なのでしょう。
こういう状況がゲームだけなのかというと、例えば自動車におけるテレマティクス分野で、数百万台の車から走行データが送られてくる状況や、年内にもより身近になってくるであろう IoT 分野でセンシング データが大量送信される状況が思い浮かびます。共通しているのは、モバイル、頻繁なアクセス、そして大量のデータ。
このような状況に当てはまる事業を始めようとしたとき、長い時間とコストを費やしバックエンド インフラストラクチャーを構築するよりも、それがウェアラブル デバイスならその利用体験に、なんらかのセンサーであるならその状況を伝えるアプリケーションに注力したいでしょうし、運用に費やす時間を事業の成長のために使いたいと考えるのではないでしょうか？
株式会社グルーヴノーツ
の
MAGELLAN
は、Google Cloud Platform を使い構築され、まさにその問題を解決するクラウド プラットフォームとして、昨年末に公開されました。その MAGELLAN について、代表取締役会長の佐々木 久美子さん、代表取締役社長の最首 英裕さんに話を聞きました。その様子を、前半、後半と 2 回に分けてお伝えします。
新しい時代に適用したコンピューター アーキテクチャーとしての MAGELLAN
2 人ともそれぞれ会社を経営してきた中で、グルーヴノーツを設立されたわけですが、設立にいたった背景と事業内容を教えてください。
最首さん:
僕らが、分散系技術を使って企業システムに取り組んでいた時、佐々木は福岡でゲーム会社を作っていて、僕のチームと佐々木のチームを一緒にすると面白いことができると思ったんですよ。なぜかというと、モバイル ゲームには未来の（サーバサイド）コンピューティングの形があるように思えたんです。モバイル デバイスが前提で、四六時中使う大勢の人から大量のアクセスがあり、そのレスポンスが要求される。その裏側では高速に分析をしたり、頻繁な機能の更新をしていく。それを見てると、これからはきっとパソコンも使われなくなって、未来の形がどんどん変わっていくだろうと。それを先取りしていく必要があると強く思って、ゲームのバックエンドに特化して事業をはじめました。
それからオンライン ゲームのバックエンドとなるクラウドサービスを提供していると、その安定したデータ収集の仕組みと、それを高速に処理するという仕組は、センサーデータや POS データといった大量のデータが絶え間なく集まるような、ハードウェアを作っている企業や、自動車向けサービスを行う企業、それに流通、特に物流データを扱う企業の用途にも共通性があって、モバイルデバイスであり、アクセス数が非常多い世界なので、製造業とか IoT 系の会社からの問い合わせが非常に多く、そういった企業にもサービスを提供しています。
MAGELLAN も、そのようなオンライン ゲームの経験から生まれたものなのですか？
最首さん:
そうですね。いろいろな案件をやるなかで、一時期は 1 日ごとに数万人ずつユーザーが増えるサービスをやったりもしました。そこで知ったのが、これまでやってきた金融系や製造業の、いわゆる業務システムレベルでの大規模システム技術では、全く通用しないということ。そのくらいの凄まじいことが起きていることを実感をして、こういうことが未来にどんどん起きていくのだとするならば、たぶん今までのコンピューター アーキテクチャは全然通用しなくなる。それならば、新しい時代に適用した形を作っていこうと試行錯誤して、そこでもいろんな問題が出てきて、それを乗り越えるためにはもっといろいろなことを考えて、そういう繰り返しを経験したことからできあがってのが MAGELLAN です。
パートナーとしての Google
その MAGELLAN を動かす環境として、Google Cloud Platform を選んでいただきました。また、最首さんは Blog にもクラウド ベンダーの違いについて書かれていましたが、Google Cloud Platform を選択した理由がなんであったのか教えてください。
最首さん:
根っこにあるのは、ゲームの凄まじいトランザクションを従来の発想で乗り越えるのがとても大変だったということ。それは普通に Web サーバや、アプリケーションサーバ、DB サーバなどを置いていくだけでは済まない、もっと高いレベルでの対応が必要だったんです。もちろん Google 以外のクラウド ベンダーを知らないわけじゃないですけど、ぼくらが直面していたことからすると、違和感を感じざるを得なかった。そんな中、Google の人達と話をすると、考えているのは安いコンピューターとか性能の良いサーバとかそういう話じゃなくて、何か本質的なことを考えている気がして…
それが Google と同じインフラストラクチャーで動かせるということ、最首さんたちの経験が MAGELLAN に還元されたように、Google のサービス提供者としての経験がそのまま Google Cloud Platform に還元されているということなのかもしれません。
最首さん:
だから組む相手としてふさわしく、やっぱり何をやろうとしているかを聞いておく、知っておくことで凄い勉強になって、新しい性能の良いサーバーが出ました、値段半分になりましたとかだと、あまり勉強する必要はないわけですよ。あ、凄いですね、というだけなんですけど、Google はもっと違うことを考えているので、そこは僕にとってもの凄く刺激的だし、面白いですね。
例えば、Hadoop で作ったプログラム。クロス集計的な機能を高速にしましたという類のプログラムを BigQuery に置き換えたら、とても簡単に置き換わってしまった。しかも、速度が桁違いに速く、運用コストは殆どかからない。サーバのセットアップをする必要もない。データを投入してコマンドを打つと、知らないあいだに数千台のサーバが勝手に動いて、何十億件のデータ処理をするのに 3 秒くらいで答えが帰ってきて、値段が 30 円ですと。集計を組み合わせるというレベルだったら（締め処理のようなこと）BigQuery が Hadoop の代わりになると気がついたときに半日くらい考えこみましたね、これなんなんだと（笑）。これまで結構頑張ってやってきたことが、ほんの僅かな時間で構築できて、コストはお小遣い程度。あまりにもドラスティックすぎて、みんな怖くて口にできないんじゃないかと思ってしまった。
しかもクエリーを書くのは簡単なので、僕らがプログラムを作るのではなくて、お客様に開発してもらっているんです。やってくださいって説明したらできてるんですよ。しかも日常的にプログラム組んでない人たちじゃないんです。でも BigQuery でバッチ作って流している。そういうことが目の前で起きているということを正確に理解して、受け入れないといけない。
大量のトランザクション処理は WhatsApp を参考に
あらためて MAGELLAN の話を聞かせていただきたのですが、Google App Engine のようにアプリケーションさえ作れば、あとは MAGELLAN がスケーリングだとか運用に必要なことをやってくれると理解しています。
そうですね。今の形は App Engine に似たところがあるけど Ruby on Rails で開発できる、これから他の言語プラットフォームも出していきますが、App Engine だけど Node.js で書ける、というような形です。しかも App Engine は App Engine アプリケーションを書く流儀がありますが、流儀がないのですよね。普通の Web アプリケーションとして書くとそのまま動きます、という形です。プロトコルも HTTP じゃなくて MQTT でも動いてしまう。HTTP じゃないのに何故か Web アプリケーションのように書ける。これって IoT では結構重要なことです。なぜかというと、デバイスは PC のように HTTP のようなリッチなプロトコルを自由に使えない状況にあるし、メーカーや業界独自のプロトコルだとかの存在もありますし、メモリサイズの問題や消費電力など、つまりデバイスの価格にも影響してきます。そのため MAGELLAN では通信プロトコルには依存しないような作りにしました。このおかげで、独自プロトコルを組込んでも、サーバーロジックはそのまま行けるであるとか、そういうことを考えられるようになりました。
先ほど話にあった、大量のトランザクション処理を MAGELLAN ではどう処理しているのですか？
MAGELLAN の中にトランザクション ルーターというものがあって、そこで処理しています。そこで大量のトランザクション処理をいかにこなすかというときに参考にしたのが
WhatsApp
。なぜ彼らはあれだけの処理を非常に少ないサーバーの台数で処理できるのか、それを調べたときに、Erlang OTP という電話交換機などの制御のための仕組みがあり、それがとても大きな効果を発揮するということを知って、じゃあその構造を見習って実装していこうと。おかげで非常に高性能なエンジンが完成しました。
最もふさわしい形として選んだ Docker
MAGELLAN で特徴的なのは Docker コンテナを使われていることだと思います。まだ実サービスとして使っているところはあまり多くはありませんが、今回 Docker を選択したというのはどういう理由からだったのですか？
最首さん:
開発に自由度を与えるにはどうしたらいいか、というときに、開発の自由度を下げて、開発流儀を縛るとやりやすくはなるんです。App Engine のように。でも自由に書けるように、いろんなライブラリを使えるようにしようとすると、プログラムソースを上げるというよりは、環境をあげられなければ、うまくデプロイできない。では、環境をどうやってあげるのか、というときに、Docker イメージを作ってあげれば、環境ごとあがるわけです。そういう形がふさわしいと使ったので、いち早く使ったつもりもなく、ただいろんな選択肢の中でこれが一番ふさわしいと選択しただけで、その準備している間に世の中が Docker ブームになってきて、あれあれ、みたいな（笑）
Google は Kubernetes をリリースしていますが、そういうものは使わずにクラスタリングマネージメントを？
最首さん:
そうですね。Kubernetes がオープンソースでリリースされたのは、MAGELLAN が結構できてからで、今後だんだん融合していくのかと思います。
ユーザーにわかりやすい仕組みとしてのコンテナ
最首さんは、イーシー・ワン時代にコンポーネントという形で機能の部品化を進めらていました。コンテナも大きな単位の部品化という考え方もできるかと思います。コンテナについてどうお考えですか？
最首さん:
プログラム モジュールをコンポーネント化し、再利用性を高めていくということは、うまく言った部分もあったかもしれませんが、考える粒度が小さすぎたのは問題だったのかなと。それにロジックがビューと切り離しにくく、結局うまく再利用ということろまでは踏み込めませんでした。その後出てきた流れ、SOA や、Web API、RESTful インターフェイスだとかのように、機能を比較的大きな単位で分割し、疎結合にして再利用を図るという流れは、うまくいったとは思うのですが、あの当時、やはりネットワークがボトルネックになりやすく、通信に冗長性を持たせることはなかなかできなかった。とはいえ今や、ある企業で使っている機能や、あるサービスで使っている機能を API 化することによって、機能分割して再利用性を高めるということは、当たり前のようになってきています。もっと時間をかけて考えていくべきテーマだったんでしょうね。
コンテナに関していうなら、VM で頑張る必要がなかった、ハードウェアレベルまで完全にエミュレーションする必要はなかったということだと思います。結局上位層で使っている部分というのはハードウェア I/O しているわけでもないし、もっと抽象化されているので、コンテナのような発想で十分だといえば確かにそうだと。昔 Google は VM を使ってないと聞いたんですけど、それは当たってたたわけですよね。全部ハードでやってるらしいと、それは嘘だったわけですね（笑）。
コンテナ時代の開発の仕方というのは、作っている側からするとまた違ったパラダイムなのかと思うのですが、実際に利用していていかがですか？
最首さん:
そうですね、デプロイし易いというか、どうですか？開発責任者として
佐々木さん: 自分たちがどうかということより、ユーザーさんが何か作るというときに、使わせやすいかというのはありますね。ここだけ作ればいいという説明ができて、ユーザーさんでも自分が開発したいもののためには、ここだけやればいいというのがわかるので、今までインフラよりのことまで全部やらなければいけなかったことが、コンテナによって上辺だけでよくなっている、作るアプリケーションだけ見ていればよくなるというユーザー視点では、私たちがサービス提供する上では凄くよかった。
最首さん:
ワーカーを開発するとき MAGELLAN に上げる前に、その Docker イメージのままローカルで動かすことができるんですよ。Web インターフェイスをエミュレートしているので、とりあえず Web インターフェイスのままテストして、これでOKとなってデプロイすると全然違うインターフェイスで動く。
佐々木さん:
技術もそうですけど、私はどちらかというとユーザーさんの使い易さの方が重要だと思っていて、そこが吸収される技術であれば、どちらかというとなんでもいいと言ってしまうタイプなんですけど、それが Docker だと本当にわかりやすい。単純にもう、そこが今は一番。
結局運用がどれだけ簡単になるか、というところですよね。
佐々木さん:
結局は技術がどうかよりも、運用のしやすさをお客様も求めるので、最初の開発で完了じゃなくて、その後継続していくものなので、ゲームもそうだし、一般のシステムもそうですけど、やっぱり継続した運用を考えたときには、メンテナンスのしやすさ。そのための人材を確保するよりは、Docker 部分だけ考えていられた方がいいですよね。
Google App Engine を使っているお客様も同じことを話していて、とりあえずデプロイしておけば、あとは運用する必要もなく、アプリケーションを良くすることだけを考えられると仰っています。
最首さん:
例えば、オンライン ゲームだと、来週からテレビコマーシャルを打ちますとなると、確実にユーザーが増えるのが見えていて、その増設規模が 100 台とか 200 台とか三桁単位で増設していったりとかで大変なんですよ。環境作って、最終的に性能とかも確認してリリースしてとか、もうそれだけで 10 時間、20 時間がまたたく間に過ぎていく。台数が多くなると、面倒見なきゃいけないことの負担はもの凄く多くなってきますし。また、サービスを止めないで機能を変えたり、あとは 例えば Apple に iOS のアプリを審査に出すと、そのために審査用のサーバを建てないといけない、でも終わったら本番に切り替えないといけないとか、そういう運用上の面倒くささ、というのは今までの企業システムでは考えられないレベルで出てくる。そういうことをいかに楽にできるかというのを MAGELLAN ではかなり考えて作っていますね。それが大変だと思ってない人には、なかなかわかりにくいかもしれませんが。
Google Cloud Platform でもそうですが、品質であったり運用を考慮した機能は、それができたストーリーに共感できる人でないと、使ってもらう前に伝えることは難しいですね。
最首さん：そうですね。
(
後半
に続く。)
- Posted by Google Cloud Platform Japan Team
■ Google Cloud Platform のその他の
導入事例はこちら
から
ファンがアジーリア・バンクスと同じステージに。新しいインタラクティブ ビデオは Google Cloud Platform で作られました。
2015年3月18日水曜日
* この投稿は、米国時間 3 月 13 日、
COLLINS の Director of Experience Design, Brett Renfer 氏によって投稿されたもの
の抄訳です。
本日のゲストは、
COLLINS
の Director of Experience Design Brett Renfer 氏です。COLLINS はニューヨーク市を拠点とするブランド コンサルティングの会社で、デザイン思考を用い、デザイン、音楽、映画、テクノロジーを融合させた記憶に残るブランド エクスペリエンスを創りだしています。
Azealia Banks（アジーリア バンクス）
と “Wallace” のビデオを企画していたころ、彼女がそうであるように、ビデオは革新的でなければならない - つまり、世の中をあっと言わせ、ファンに Azealia の新作を見たいと思わせるように、Azealia だからこその体験としてファンに提供できるようにしなければならないと話していました。音楽、映像、テクノロジー、デザインが融合することで産み出される力、それを信じて Azealize のために
これまでにないインタラクティブ ビデオ
を作る。そこで、もしビデオ見ている人の動きをそのままリアルタイムに重ね Azealia のステージにファンを登場させられたとしたら、ファンはビデオを見ながら、すぐ前のアジーリアが彼らに向かって歌うだけではなく、一緒に歌っているような体験ができるはず、COLLINS の Executive Creative Director, Lee Maschmeyer に、そのためにできる限界を超えるように言われ、そして達成しました。
制作に入り、数多くのミュージック ビデオを見ていったところ、自分たちがやろうとしているような形でビデオ ファイルやピクセルを扱っているものはまだないことがわかり、それから WebGL、HTML5 ビデオ、そしてウェブ カメラでのインタラクションを組み合わせたユニークなアプリケーションを創りあげました。
Google Cloud Platform
上でアプリケーション構築することで、エンジニアリングや最適化といったことではなく、ユニークなデザインや体験を創りだすことにだけ集中でき、小さなチームでしたが短期間での制作を可能にしてくれました。
COLLINS の開発チームは 2 拠点あり、 ニューヨークとテキサスにあります。Chrome でのプロトタイプから始め、その後もプロトタイピングをローカル Web サーバーで継続していけるように
Google App Engine
へ全て移行させ、テストをローカルで実施した後、そのままデプロイしてライブにし、世界中の関係者と一緒に作業を進められるようしました。完成までは 2 ヶ月程です。Azealia のファンの多さから、リリース後にスケール作業が必要になってくることは想定できたため、それをなくすためには App Engine を使用しなければならないことも想定していました。
製作中、 Chrome の WebGL では高解像度のビデオや高音質なサウンドを処理できることはわかったものの、そこで使われるコンテンツを処理し、それを高度に設定できる機能を提供しているコンテンツ ホスティングのサービスが必要になってきました。これには
Google Cloud Storage
がまさに最適で、すべてのユーザーに高品質なコンテンツを提供し（最大 300 MB のバンド幅を使用するユーザーも含めて）、そのコンテンツは WebGL からロードして操作できるようになりました。
このように進めてきた中で Azealia がくれるクリエイティブなインプットは、とにかく貴重でした。彼女はテクノロジーが好きで、ファンともっと近くで付き合える、ふれあえる方法を探している人です。彼女独自の芸術性がビデオの体験を通じて表現できるように、彼女は最初から最後まで密接に協力してくれました。
COLLINS は、クリエイティブな企業として、その強く訴えるストーリー テリングで知られています。今回のチームは、Azealia の歌のエモーショナルな部分を引き出し、それをリアルに表現し、かつ高い応答性を実現するために Google のテクノロジー利用して驚くべきことを成し遂げました。
ビッグなアイデアを持った小さな（スモール）チームが、どうやって Azealia とファンの距離を近づけることに成功したか、その
一部始終はこちらから
どうぞ。
大量のリソースを必要とするアプリケーションに Google の新しい大規模な仮想マシンを
2015年3月17日火曜日
* この投稿は、米国時間 3 月 13 日、
Google Compute Engine の Product Manager, Scott Van Woudenberg によって投稿されたもの
の抄訳です。
大量のリソースを必要とするアプリケーションをお持ちではありませんか。膨大なコンピューティング能力が必要になっていませんか。そうだとすれば、Google のソリューションで解決できます。
Google Cloud Platform では、新しい 32-vCPU 仮想マシン(ベータ)を利用いただけるようになりました。下記の表は構成と料金の詳細ですが、ここでも Google では引き続き
クラウドでのコスト削減に注力していく予定
であることがお分かりいただけるでしょう。
構成
メモリ
（GB）
継続利用時の
1 時間当たりの最低料金
（米ドル）
標準的な
1 時間当たりの料金
（米ドル）
1
非継続利用時の
1 時間当たりの最大料金
（米ドル）
n1-standard-32
120
1.412 ドル
1.538 ドル
2.016 ドル
n1-highmem-32
208
1.658 ドル
1.806 ドル
2.368 ドル
n1-highcpu-32
28.80
0.896 ドル
0.976 ドル
1.280 ドル
*
標準的な 1 時間当たりの料金（米ドル）：Compute Engine の全ユーザーを対象に算出された平均的な利用での 1 時間当たりの料金。継続利用割引を含む。
デジタル制作会社の
Industriromantik 社
では、Google の 32-vCPU マシンが初期段階からテストされています。同社の技術担当ディレクターを務める Fredrik Averpil 氏は、マシンについて次のように述べています。
「これまでのところ、すべてのジョブで 16-vCPU から 97 ～ 98% という安定した
スピードアップが実現しています。3D レンダリングとしては最高の効率です」
開始するには
デベロッパー コンソール
から 32-vCPU マシンを使って
新しいインスタンスを作成
するか、gcloud のコマンド ライン インターフェースを使用する
新しい仮想マシンの作成方法
をご覧ください。32-vCPU マシンは Ivy Bridge と Haswell
ゾーン
でのみ利用可能です。
ワークロードの実行やプラットフォームでの使用についてのフィードバックは、ぜひ
こちら
からお寄せください。
- Posted by Scott Van Woudenberg, Product Manager for Google Compute Engine
ライブ マイグレーションを使い、Google Compute Engine にダウンタイムのないサービス インフラストラクチャーを
2015年3月13日金曜日
* この投稿は、米国時間 3 月 3 日、
VM Migration の Tech Lead/Manager, Miche Baker-Harvey によって投稿されたもの
の抄訳です。
はじめに
去年の春、2014 年 4 月 7 日に起きたことを覚えていますか？ その日に起きたことではなく、起きなかったことが今日のポストの主題です。
その日は
Heartbleed
バグが公表された日で、ゼロデイ攻撃に対処するため、この脆弱性のパッチをシステムに当てようと世界中の人たちが対応していました。Google Clodu Platform 以外のパブリッククラウドのプラットフォームを利用していたら VM を再起動、あるいは少なくとも対象の各ノードで SSL ライブラリを更新し、Web サーバーを再起動しなければならないという影響を受けました。Google でも、
Google Compute Engine
でホストするサーバーを含むすべてのサーバーを直ちに修正しました。でも誰一人として気づくことはありませんでした。つまり起きなかったのです。
2013 年 12 月、Google Compute Engine に
トランスペアレント メンテナンス
（
透過的なメンテナンス
）を導入しました。それ以来、ソフトウェアのアップデート、ハードウェア問題の解決、予期しない問題の解決があっても VM を止めずに稼働させています。データセンター トポロジーのイノベーションと、ライブ マイグレーション テクノロジーを組み合わせることで、定期的なハードウェアやソフトウェアのメンテナンスがあったとしても、それに VM が影響を受けないようにし、VM、アプリケーション、ワークロード、そのどこにも何も起こらかなかったかのように、インフラを保護し高い信頼性を保てるようにしています。
透過的なメンテナンスの利点
ライブ マイグレーションによって Google が目指したのは、VM を再起動することなく、すべてのデータセンターにあるハードウェアやソフトウェアを最新の状態に保つことです。こういったメンテナンスは、ホストマシンの再起動が必要となるため、透過的なメンテナンスがないのなら、当然 VM にも影響がでます。
ライブ マイグレーションで解決するであろう問題は例えば次のようなものです。これらは実際に私たちが遭遇してきたも問題です。
インフラの定期的なメンテナンスやアップグレード
データセンターにおけるネットワークや送電網のメンテナンス
不良のメモリ、ディスクドライブ、マシン
ホストの OS や BIOS のアップグレード
直ぐに対策を要するセキュリティ関連のアップデート
ホストのルートパーティション、ホストのイメージやパッケージ用ストレージのサイズ変更を含むシステム構成の変更
皆さんが運用の中で様々な問題に直面したときに、ライブ マイグレーションがどれだけ役立っているかを知って驚きました。実際、サイトの信頼性に係わるエンジニアは、まだライブ マイグレーションが皆さんに提供されていなかったころにもツールとして使い、プロダクション時に起きる可能性のある障害への対処や、あるいは軽減していました。
以下は、予期せず実際に発生したものの、実行中のゲスト OS には影響なく対処できた問題です。
ネットワークカードのフラッピング
: ネットワークカードは時々故障します。VM のマイグレーションを繰り返し試み、無事にマイグレートできました。これは一部のみ故障する NIC でも効果があります。
バッテリ / 電源の問題の波及
: 過熱したバッテリの中には隣接するマシンを過熱させるものがありました。VM をマイグレートしてから、マシンを停止してバッテリを交換することができました。
バグのあるアップデートが稼働マシンに紛れ込んだ
: ロールアウトを停止しましたが、稼働マシンには達してしまいました（Canary 環境では出現せず）。バギーなソフトウェアであれば 1 週間もせずに VM 群をクラッシュさせていたと思います。ここでは、影響を受けたマシンの VM 群をバギーではない他のマシンにマイグレートしました。
予期しないホストのメモリ消費
: バックエンドのコンポーネントの 1 つはアロケートされた以上のメモリを消費し、VM で OOM（out of memory：メモリ不足）の兆候を示していました。過負荷のマシンから VM をいくつかマイグレードして OOM を回避すると同時に、バックエンドのシステムにパッチを当ててメモリの割り当てを超えないようにしました。
トランスペアレント メンテナンスの実施
導入後、マイグレーションは数十万回実施されてきています。多くの VM はマイグレーション導入後に立ち上げられて、すべて複数回マイグレートされました。反応は非常に好意的です。初期のマイグレーションのテスト期間中は、Rightscale でマイグレーションの効果を調べました。対象の VM をすべて 2 回マイグレートした後、次のようなレポートが得られました。
「ログファイルを調べましたが、データベースの中の全データは…まったく異常ありません。もしインスタンスがマイグレートされていたことを Google が教えてくれていなかったとしたら、まったくわかりませんでした。すべてのログとデータは正常ですし、RightScale のクラウド管理 ダッシュボードには、ゾーン、インスタンスのサイズ、IP アドレス、リソースなど、いずれも変化はありませんでした」。
ServerDensity の David Mytton 氏と協働で、レプリケートした MongoDB をライブ マイグレーションしたところ、マイグレーション終了後に David はツイートしました。
“
@MongoDB
レプリカ セットで
@googlecloud
ライブ マイグレーションをテスト。
まったく影響なし。どのノードも、プライマリが移動したことに気付かなかった！”
実際 Google は、ホストへのカーネルのアップグレードと全 VM にセキュリティ パッチ当てを、どの VM も欠けることなく行っています。そこに含まれる大量のコンポーネント、さらにその依存関係までが、どの時点においても 1 つとして障害を起こしたり、失うことがなかったことを考えると驚異的なことだと思いませんか？ マイグレーションの間、VM を構成する多くのコンポーネント（ディスク、ネットワーク、管理ソフトウェアなど）は、元のホスト マシンとマイグレート先となるマシンにデュプリケートされます。マイグレーション中のどこかで、その 1 つでも障害を起こせば、それがアクティブ（クラッシュなど）なものであれパッシブ（消失など）なものであれ、実行中の VM に影響を与えずにマイグレーションを完全に取り消します。
どのように動作しているのか
実行中の VM をあるホストから別のホストへマイグレーションするとき、ゲスト VM と、それと通信している全てに対して透過的な方法で、マイグレーション元から先へすべての状態を移す必要があります。これをシームレスに行うには、多くのコンポーネントが関与してくるのですが、ここでは、大まかなステップを見ていきます:
マイグレーションのプロセスは、VM を現在のホストマシンから移さなければならないという通知から始まります。その通知には、ファイルへの変更（例えば、リリース エンジニアが新しい BIOS が利用できるようになったことを指摘するため）、ハードウェアへのオペレーションのための定期メンテナンス、ハードウェア障害が起こりそうなときに発生する自動的なシグナルなどから始まります。
Google のクラスター マネージメント ソフトウェアは、データセンターやジョブを制御するポリシー（た（例えば、データセンターの最大稼働率や、ジョブにおいて 1 ユーザーのために 1 度にマイグレーションできる VM の数であるとか）に従って、こうしたイベントやメンテナンス スケジュールを監視しています。
マイグレーションの対象となる VM を選択されたら、
マイグレーションが差し迫っている
ことをゲスト VM に通知します。一定期間経過した後、マイグレーション先となるホストが選ばれ、そのホストでマイグレーション元の VM を受け入れる先となる新しい空の VM をセットアップするように依頼します。図の中の認証（Authentication）は、マイグレーション元と先との接続を確立するためです。
VM のマイグレーションには次の 3 つのステージがあります:
予定されたマイグレーションが行われるまでの間、ほとんどの状態をマイグレーション先へと送信しながら VM はマイグレーション元で動作します。この期間に、例えばすべてのゲスト VM のメモリをマイグレーション先へコピーすると同時に、再度変更された
ページ
がないか追跡しています。この状態がどれだけ続くかは、ゲスト VM のメモリー サイズや、そのページが変更される率（ダーティ状態の率）によります。
停止している間、VM が完全に実行を止める時間はほんの短い間ですが、一瞬停止し、マイグレーション先で VM が動作を始めるために必要な残りの状態が送信されます。停止状態に入るのは、マイグレート前の準備期間中の状態の送信が、動作状況に対して増えなくなったポイントに達したときです。ここでは特に、送られるメモリのバイト数とゲスト VM がページを変更する率とのバランスをとるアルゴリズムを採用しています。
マイグレート後の一定期間、VM はマイグレーション先で実行されていますが、マイグレーション元の VM もそのままマイグレーション先をサポートする機能を提供していることがあります。例えば、ネットワーク ファブリックが VM の新しいローケーションで用意できるまで、マイグレーション元の VM は、マイグレーション先の VM が送受信するパケットの転送サービスを提供します。
最終的にマイグレーションが完了すると、システムはマイグレーション元の VM を削除します。マイグレーションが実行されたことは、ログからわかります。
全てにおいて透過的にメンテナンスしていくことには、たった 1 つの VM でさえも犠牲にしないという目標があります。これを達成するため、超高レベルの厳格なテストをライブ マイグレーションに対して実施してきました。マイグレーション アルゴリズムの中で注意すべきポイントの全てで、障害を引き起こすためにフォールト インジェクションを使い、それぞれのコンポーネントごとにアクティブとパッシブの障害の両方を生成します。デベロップメント テスト（数か月にわたる）のピーク時には、毎日数万回のマイグレーション テストを実施してきました。
このような複雑で多面性のあるプロセスを行うには、インフラストラクチャーの隅々にまで、強力なスケジューリング、オーケストレーション、オートメーションの組み合わせを深くインテグレーションすることが求められます。
まとめ
ライブ マイグレーション テクノロジーによって、ゲスト VM への影響なくインフラストラクチャーを最高の状態に維持することができます。
Google が VM を不老不死にしたと主張するレビュワー
もいました。定期的、非計画的メンテナンスが要求される中、物理マシンの再起動が必要な数多くの問題がありながらも、長期間 VM を実行し続けることが可能となっています。
最近発生した、他のクラウド プロバイダに影響を与えたセキュリティ上の問題のいくつかが、私たちに影響がなかったように、今後発生しうる新たな脆弱性に対しても、Google は VM への影響なくCompute Engine を保護できるようにしていきます。
-Posted by Miche Baker-Harvey, Tech Lead/Manager, VM Migration
Google for モバイル アプリ - モバイル KPI 分析の新標準 〜 Fluentd + Google BigQuery セッション レポート（最終回）
2015年3月13日金曜日
Google for モバイル アプリ
レポート 5 回目、これまでに次のセッションをレポートしてきました。
モバイル アプリを支える Google Cloud Platform のビジョン
コンテナ技術と Google Compute Engine で実現するクラウド時代のアプリ実行環境
Google Cloud Platform の活用事例
Maps API で、かしこく地図アプリを開発しよう
最後となる今回は、デベロッパー アドボケイト 佐藤 一憲のセッションです。Google における Big Data から始まり、
BigQuery
が速い理由、fluentd と BigQuery によるリアルタイム ストリーミング インポート、それから Lambda アーキテクチャーによるリアルタイム KPI 分析を説明しました。BigQuery については
様々
な
情報
があるため、ここでは Lambda アーキテクチャーによるリアルタイム KPI 分析をレポートします。
Real-time KPI Analytics with Lambda Architecture
Lambda アーキテクチャ
を
Google Cloud Platform
で構成するために、データ入力には fluentd を使い、バッチ処理には BigQuery、リアルタイム処理には SQL を使ったストリーム処理が可能な、LINE の田籠さんによる
Norikra
、その結果を見るダッシュボードとして Google スプレッドシートを使い、デプロイには Docker コンテナを活用しています。
このビデオからも、リアルタイムにスプレッドシートのグラフが更新されていくのがわかります。今回のメインではないものの、スプレッドシートでこのようにリアルタイム ダッシュボードが作れることは、様々な用途に応用していけそうです。その他のアプリケーションの例として、モニタリング システムなどが考えられますね。
Lambda アーキテクチャーは、人的なミスを含めた対障害性としても、スケーラビリティの面でも優れたアーキテクチャーで、例えばリアルタイムでの集計の仕方を間違って、正しくメトリクスの値を把握できていなかったとしても、バッチ処理側で元データを管理しているため、後で正しく修正したレポートを見ることができる、そして想像すると殆どの用途が当てはまるアーキテクチャであることがわかると思います。
このソリューションで次のことが可能になります。
BigQuery と Fluentd で秒間 100 万行のストリーミングインポートが簡単に行える
Norikra で秒間 100 万行の KPI の解析をリアルタイムに SQL を使い簡単に行える
Google スプレッドシートで実現できるリアルタイム ダッシュボード
Docker を使うことで 10 分内にデプロイ可能
モバイル デバイスから送られてくる大量のデータを優先順位付けし、リアルタイムに処理/分析していくことは、デバイスの多様化や高機能化が進むほどに、より重要性が増してきます。今回紹介した方法を一例として、今後 Compute Engine や BigQuery を使った、どんなソリューションが出てくるのか楽しみです。
さらに詳しく見ていくには GitHub の
lambda dashboard
を見てください。
以上で、Google for モバイル アプリのセッションが終わりました。これまでのレポートから、何か今後のモバイル開発に役に立つことが見つけられたら、とても嬉しいです。また次のイベントで皆さんに会えることを楽しみにしています。
- Posted by Google Cloud Platform Japan Team
Google for モバイル アプリ - Maps API で、かしこく地図アプリを開発しよう セッション レポート（第 4 回）
2015年3月12日木曜日
Google for モバイル アプリ
第 4 回のレポートは、Google Maps API と Google Cloud Platform を使ったモバイル アプリケーション開発について、セールス エンジニア Maps for Work 丸山 智康が説明しました。
これまでのレポートは、
モバイル アプリを支える Google Cloud Platform のビジョン
、
コンテナ技術と Google Compute Engine で実現するクラウド時代のアプリ実行環境
、
Google Cloud Platform の活用事例
とまとめられています。
Google Maps と位置情報の今
Google Maps の登場が 2005 年、今年は 10 週年にあたります。覚えている人もいるかもしれません、登場した当時は、まだ日本もなく北米とヨーロッパの一部だけでしたが、当時としては革新的な AJAX ベースの UI でスムーズなパンニング、ズームイン、ズームアウトを実現していました。そして現在では多くの皆さんが日々使うアプリケーションとして成長し、機能的にも、ストリートビューや高解像度の衛星画像、航空写真など大きく発展しています。
US での調査結果ですが、モバイルが発展した今、Google の検索の 30％ が位置情報、または地理的要素に関連していると言われています。そしてインターネットを利用をする 40% 以上の人が、Google Maps か Google Maps API を使ったウェブ サイトを使い、さらにその内の半分がモバイルから利用しています。Google Maps から 10 年、位置情報の重要性はモバイルの発展とともに高まり、GPS、ビーコン、各種センサーなどと連動し、O2O ソリューションから、子供や高齢者を見守るサービスまで、これからもさらにその重要性が増していくでしょう。
“ 5 分” でわかる位置情報アプリの開発
セッションの一番最初で
Ingress
について説明しました。そこで、Ingress のように位置情報と連動し実際にポータルを訪れ、ハックするアプリケーションを作っていきます。
四国八十八ケ所
と名付けられたこのアプリケーション（どういうアプリケーションかは想像できますよね）は、Android Studio、Google Maps API、Google Cloud Platform といった Google の開発者向けツールの活用の仕方としても、Android Studio を使った開発ワークフローとしても、これから始める皆さんにはとてもわかりやすいチュートリアルなのではないでしょうか。
Android Studio
は Google Cloud Platform のモジュールを追加していくことで、Android アプリケーションに簡単に Google Cloud Platform をバックエンドとして追加できるようになります。ローカルでバックエンドを含めたテストができて、そのままデプロイまで Android Studio で行えます。現在サポートしているのは、App Engine、Cloud Endpoints、Cloud Messaging。そしてコードは
Cloud Repository
で
バージョン管理
できます。
さて、ここでは開発の詳細省くので、以下の画像をご覧ください。
これだと 5 分というより、5 秒ですね。
ソースコードは
GitHub
にあります。まずは API Key を取得して、
Developers Console
から新しいプロジェクト作りましょう。
次回で最後です。デベロッパー アドボケイト 佐藤 一憲による「モバイル KPI 分析の新標準 〜 Fluentd + Google BigQuery」をレポートします。
- Posted by Google Cloud Platform Japan Team
Google Cloud Storage Nearline ：オフライン価格でオンライン（に近い 〜 Near）データ ストレージ
2015年3月12日木曜日
* この投稿は、米国時間 3 月 11 日、
Avtandil Garakanidze によって投稿されたもの
の抄訳です。
世界中で産み出されているデータ量は想像もできないほどで、さらに指数関数的に増え続けています。このようにデータ量が増大するほど必要になってくるのは、それをどう保存しておくか。つまりデータの保存後も、頻繁にアクセスするデータには引き続き簡単にアクセスできるようにし、殆ど使っていないデータも必要なときに利用可能で、この 2 つのデータの状態を簡単に切り替えられる必要があるわけです。組織において、データ解析からマーケット インテリジェンスを高めることは必須ですし、データはもう使い捨てられるものではないものの、容量追加を続けなければならないストレージに投資し続けることも現実的ではありません。
そこで今日、シンプルで低価格、 素早くデータのバックアップが可能で、高速なレスポンスのストレージ サービス
Google Cloud Storage Nearline
を紹介します。今、データを高価なオンライン ストレージからオフラインのコールド ストレージへ移すために、階層化されたデータ ストレージやアーカイブ プロセスを使っている方も多いのではないでしょうか。でも、すべてのデータはオンデマンドでアクセスできることにこそ価値があります。Nearline では、低コストで容量制限なくデータのバックアップや保存が可能で、いつでも数秒でデータにアクセスできるようにしています。
これまでのソリューションとは違い、Nearline は長期保存に対しても、これ以上ないくらいの価格性能比を実現しています。
高パフォーマンス :
データを直ぐに利用することができながらも、コールド ストレージのすべての利点を持っています。似たサービスと違って、Nearline はデータにアクセスするときに最大 3 秒程の応答時間で済み、より良い SLA を提供します。
低コスト :
ストレージ価格は、データを保存しているだけなら 1 GB あたり 1セント という低価格です。
セキュリティ :
データを物理的に離れた複数の場所に冗長化することで、データを保護します。 OAuth と細かなアクセス制御が、強靭かつ必要にあわせて設定できるセキュリティを確保しています。
インテグレーション :
他の Google Cloud Storage サービスと完全にインテグレーションでき、Google Cloud Storage サービス全体で一貫したアクセス手段を提供します。
シンプル :
新しいプログラミング モデルを身につける必要もなく、データの操作は、Google Cloud Storage サービス全体で同じです。
それでも、ストレージ プラットフォームや、それを利用するプロセスを変えることは難しいですよね。それもあって、バックアップやストレージのリーディング プロバイダーと Nearline の導入が問題なく進められるように勧めてきました。次のパートナー（一部）のプロダクトやサービスは、皆さんが今使っている環境のデータ ストレージに、この新しいアプローチを取り入れるために利用できます。
Veritas/Symantec
:
NetBackup は企業向けバックアップ ソフトウェアのマーケット リーダーで、バージョン 7.7 から Google Cloud Storage Nearline をサポートします。NetBackup に Google Cloud Storage Nearline が統合することで、企業のビジネス アジリティと情報の利用性を促進していくことができます。NetBackup を利用することで、バックアップのライフサイクルを管理し、保護対象の情報全てに対してのカタログとリカバリー ポイントを保持できます。
NetApp
:
SteelStore はオンプレミス用の製品で、Google Cloud Storage Nearline へデータをストリームする前にデータの重複を排除し、暗号化して圧縮します。データ量を最大 30 分の 1 にまで縮小し、データ転送速度を 400% 高速化、簡単に直ぐクラウドにデータを移行します。現在は Google Cloud Storage をサポートしていて、Nearline のサポートは 2015 年の後半を予定しています。
Iron Mountain
:
Iron Mountain のセキュリティ、流通、データ管理機能を使って作られた、オフラインのインジェスチョン サービスを使いクラウドへのデータ移行を協業して進めています。大容量データがありつつも、ネットワーク接続が制限されているなら、ディスクを Iron Mountain へ送れば、彼らが Google Nearline Cloud Storage に直接アップロードしてくれます。
Geminare
:
Google Compute Engine
と Google Cloud Storage Nearline で動く災害復旧サービス（Disaster Recovery as a Service - DRaaS）ソリューションを利用できます。Geminare は、お客様のセカンダリのデータセンターとしてクラウドを使ってもらうことで、災害復旧の近代化と、現在利用しているデータセンターのコスト効果の高いリプリケーションの両方を可能にします。
オンライン データ ストレージ ソリューションと Nearline と従来型コールド ストレージとを比較
Google Cloud Storage Nearline
が、容量に制限なくデータを保存をでき、いつでもデータへアクセスできる、低コストで堅牢なストレージを可能にしました。特にフォーカスしたのは、生活の中に新しいユースケースをもたらすようにすること。それが、バックアップやストレージのリーディング プロバイダーと協業している理由であり、このエコシステの発展にフォーカスしている理由です。この独特で新しいストレージ オプションの素晴らしくイノベーティブな使い方を見れることを楽しみにしています。まずは、
Nearline のサイト
と
ドキュメント
を見て、そして使い始めましょう！
-Posted by Avtandil Garakanidze, Product Manager
Google for モバイル アプリ - モバイル アプリ企業の Google Cloud Platform 活用事例 セッション レポート（第 3 回）
2015年3月11日水曜日
Google for モバイル アプリ レポート、第 1 回は、
グレッグ ディミチュリ による Google Cloud Platform のビジョンと Firebase について
、第 2 回は
福田によるGoogle Compute Engine とコンテナについて
、それぞれのセッションをレポートしました。
そして 本連載の第 3 回は、Google Cloud Platform を活用して事業を展開している、あるいは準備をしている企業の皆さんに活用方法を聞いた「Google Cloud Platform の活用事例」セッションのレポートです。
Google Cloud Platform の利用について
最初は、人気のあるスマートフォンのオンライン ゲームを多数展開している
株式会社 Aiming
さんから。自社開発のゲーム タイトルだけではなく、海外タイトルの日本での展開をしていくなかで、運用効率と低コストにより一部のゲームを約 1 月ほどで
Google Compute Engine
に移設できたそうです。インフラ エンジニア マネージャーの野下 洋さんは、移設の結果、Google Apps と連動することでの運用効率の向上、継続利用でさらなるコスト削減に繋がり、そしてサービス品質が向上したと話してくれました。
しかし、これだけ人気のあるゲームを抱える中で、大量に蓄積されるログをどのように解析しているのか気になるところです。
リード ソフトウェア エンジニアの芝尾 幸一郎さんは、
Google BigQuery
を活用し、タイトルを横断して KPI を確認できるツールを作成したことを伝えてくれました。それまでに使っていたのは、別のサービスを使ったツールで、決められた時間に集計された内容を自社システムに一旦取り込みレポートを作るものでした。
それを BigQuery に変更したことで、リアルタイムに直接集計結果を取り出し、ほぼ最新の状況が見られるようになりました。さらに、毎回 BigQuery で集計して取り出すため、集計方法に変更があったとき過去データ全体の再集計の必要もなくなり、1 日 2 億件を超えるログの保存に対応できる大容量のストレージを使え、これまでの 1/5 の低価格！を実現したということです。
Google Cloud Platform の事例紹介とピタペラポン
続いては、
株式会社グラシス
の長谷川 祐介さん。Google Cloud Platform を使い MSP、システム コンサルティング事業をしていく中での事例を紹介いただきました。その中の 1 社として 4月に開始予定の新しい教育サービス、ハマる英語動画アプリ「ピタペラポン」を提供する
株式会社ハグカム
の道村 弥生さんにも登壇いただきました。
この Blog では、Google Cloud Platform のセッションに限定してお伝えしていますが、
Google for モバイル アプリ
では、モバイル アプリケーションのビジネスから開発、UI/UX までを総合的に扱ったイベントとして開催されました。その中でも新規事業開発の中で、長谷川さんと道村さんのお話は、多くの面を伝えてくれた内容でした。
グラシスさんの事例はゲームを中心に、例えば
株式会社 Zeadle
さんのソーシャル ゲームのバックエンドでは通信に WebSocket を使い、各種ログは BigQuery に送信、ディスクには SSD 永続化ディスクを使っていることや、その他グロバールなリアルタイム対戦ゲームの話など聞かせていただきました。そしてゲームだけではない、ということで道村さんと交代です。
道村さんのスライドの中で、長谷川さんが登場し引用されていた一言が印象的でした。
“インフラはまるっとお任せで、コンテンツ開発・運営に注力して下さい。”
Google Cloud Platform とグラシスさんでインフラを整え、ハグカムの皆さんは、サービス内容とアプリケーションの UX に集中する、事業に係わる様々な役割の人が自分のやるべきことに徹底的にフォーカスしている状況が道村さんのセッションから伝わってきます。
道村さんの伝えてくれた、サービスのコンセプトから、それを実現するために何が必要となるのか、その考え方は、新しくサービスを始めようと考えている人にも開発者の皆さんにも参考になることが多かったのではないでしょうか。
道村さんも、
イベントについてのレポート
を書いています（写真付き）。
MAGELLAN on Google Cloud Platform
このセッションの最後は、
株式会社グルーヴノーツ
さんです。Ruby 開発者としても有名な近永 智之さんに、ゲーム、車載機器、IoT などのモバイル アプリケーション向けプラットフォームである
MAGELLAN
と、MAGELLAN が動作している Google Cloud Platform について話していただきました。MAGELLAN プラットフォームでは、アプリケーションは Docker コンテナを使いデプロイするように構成され、柔軟なアプリケーション構成、高速なデプロイ、そしてスケーリングを実現し、HTTP(S) だけでなく、HTTP2、MQTT のサポートされていること、そしてマルチ ステージの仕組みも単に開発を簡単にするだけではなく、アプリケーションの審査までも考慮して設計されている点が特徴的でした。
様々な Google Cloud Platform サービスを活用していただいている中で、今回は Compute Engine と BigQuery について、利用する中で特に何が役に立つかという視点で説明されました。Compute Engine では大きく 4 つ：
起動時間の早さ
Google Cloud Platform 間のサービス連携
高可用性
開発者フレンドリーなインタフェース
他にも多くのクラウド サービスの経験があるグルーヴノーツさんのお話は Google Cloud Platform の特徴が良く分かるものだったのではないでしょうか。たとえば、高可用性についてのお話では、冗長化構成は必要だとしながらも、ライブ マイグレーションによって、メンテナンス再起動がスケジュールされたとしても自動的にインスタンスが物理マシンを移動し、ソケットを繋いだままのインスタンスであるにもかかわらず接続が切れることもないと、スクリーンショットを交えた説明が行われました。
BigQuery については、グルーヴノーツさんでの使い方は、ユーザーのアクションのログ、リソース情報を集め、状況分析、課金情報の計算のために利用し、データ投入はストリーミングのみ利用しているそうです。そして、BigQuery のとてつもなく速いクエリー、そして高いコスト パフォーマンスについて話してくれました。
Google Compute Engine の説明のときの Interoperability のお話の中で、Compute Engine から他のサービスへのアクセスは、スコープ設定をしておけば認証の設定を簡略化できる
（編集注：プロジェクト作成時に、他の Google サービスへアクセスするための
サービス アカウント
が自動作成されるため）
と説明してくれましたが、データ投入部分に使っている fluentd でもこのように認証を簡略化できているそうです。
コストについては、バッチでのインポート/エクスポートは無料、ストレージコストは容量あたり Google Cloud Storage よりも安く、ストリーミング インサートでは 10 万レコードあたり $0.01 と非常に高い性能に対して、コスパフォーマンスに優れていると説明してくれました。
次回は、セールス エンジニア 丸山 智康による、Google Maps API と Google Cloud Platform を使ったモバイル アプリケーション開発に関するセッション、「Maps API で、かしこく地図アプリを開発しよう」をレポートします。
- Posted by Google Cloud Platform Japan Team
12 か月間のトライアル
300 ドル相当が無料になるトライアルで、あらゆる GCP プロダクトをお試しいただけます。
Labels
.NET
.NET Core
.NET Core ランタイム
.NET Foundation
#gc_inside
#gc-inside
#GoogleCloudSummit
#GoogleNext18
#GoogleNext19
#inevitableja
Access Management
Access Transparency
Advanced Solutions Lab
AI
AI Hub
AlphaGo
Ansible
Anthos
Anvato
Apache Beam
Apache Maven
Apache Spark
API
Apigee
APIs Explore
App Engine
App Engine Flex
App Engine flexible
AppArmor
AppEngine
AppScale
AprilFool
AR
Artifactory
ASL
ASP.NET
ASP.NET Core
Attunity
AutoML Vision
AWS
Big Data
Big Data NoSQL
BigQuery
BigQuery Data Transfer Service
BigQuery GIS
Billing Alerts
Bime by Zendesk
Bitbucket
Borg
BOSH Google CPI
Bower
bq_sushi
BreezoMeter
BYOSL
Capacitor
Chromium OS
Client Libraries
Cloud API
Cloud Armor
Cloud Audit Logging
Cloud AutoML
Cloud Bigtable
Cloud Billing Catalog API
Cloud Billing reports
Cloud CDN
Cloud Client Libraries
Cloud Console
Cloud Consoleアプリ
Cloud Container Builder
Cloud Dataflow
Cloud Dataflow SDK
Cloud Datalab
Cloud Dataprep
Cloud Dataproc
Cloud Datastore
Cloud Debugger
Cloud Deployment Manager
Cloud Endpoints
Cloud Firestore
Cloud Foundry
Cloud Foundry Foundation
Cloud Functions
Cloud Healthcare API
Cloud HSM
Cloud IAM
Cloud IAP
Cloud Identity
Cloud IoT Core
Cloud Jobs API
Cloud KMS
Cloud Launcher
Cloud Load Balancing
Cloud Machine Learning
Cloud Memorystore
Cloud Memorystore for Redis
Cloud monitoring
Cloud NAT
Cloud Natural Language API
Cloud Networking
Cloud OnAir
Cloud OnBoard
cloud Pub/Sub
Cloud Resource Manager
Cloud Resource Manager API
Cloud SCC
Cloud SDK
Cloud SDK for Windows
Cloud Security Command Center
Cloud Services Platform
Cloud Source Repositories
Cloud Spanner
Cloud Speech API
Cloud Speech-to-Text
Cloud SQL
Cloud Storage
Cloud Storage FUSE
Cloud Tools for PowerShell
Cloud Tools PowerShell
Cloud TPU
Cloud Translation
Cloud Translation API
Cloud Virtual Network
Cloud Vision
Cloud VPC
CloudBerry Backup
CloudBerry Lab
CloudConnect
CloudEndure
Cloudflare
Cloudian
CloudML
Cluster Federation
Codefresh
Codelabs
Cohesity
Coldline
Colossus
Compute Engine
Compute user Accounts
Container Engine
Container Registry
Container-Optimized OS
Container-VM Image
Couchbase
Coursera
CRE
CSEK
Customer Reliability Engineering
Data Studio
Databases
Dbvisit
DDoS
Debugger
Dedicated Interconnect
deep learning
Deployment Manager
Developer Console
Developers
DevOps
Dialogflow
Disney
DLP API
Docker
Dockerfile
Drain
Dreamel
Eclipse
Eclipse Orion
Education Grants
Elasticsearch
Elastifile
Energy Sciences Network
Error Reporting
ESNet
Evernote
FASTER
Fastly
Firebase
Firebase Analytics
Firebase Authentication
Flexible Environment
Forseti Security
G Suite
Gartner
gcloud
GCP
GCP Census
GCP 移行ガイド
GCP 認定資格チャレンジ
GCPUG
GCP導入事例
gcsfuse
GEO
GitHub
GitLab
GKE
Go
Go 言語
Google App Engine
Google Apps
Google Certified Professional - Data Engineer
Google Cloud
Google Cloud Certification Program
Google Cloud Client Libraries
Google Cloud Console
Google Cloud Dataflow
Google Cloud Datalab
Google Cloud Datastore
Google Cloud Endpoints
Google Cloud Explorer
Google Cloud Identity and Access Management
Google Cloud INSIDE
Google Cloud INSIDE Digital
Google Cloud INSIDE FinTech
Google Cloud Interconnect
Google Cloud Launcher
Google Cloud Logging
Google Cloud Next '18 in Tokyo
Google Cloud Next '19 in Tokyo
Google Cloud Platform
Google Cloud Resource Manager
Google Cloud Security Scanner
Google Cloud Shell
Google Cloud SQL
Google Cloud Storage
Google Cloud Storage Nearline
Google Cloud Summit '18
Google Cloud Summit ’18
Google Cloud Tools for IntelliJ
Google Code
Google Compute Engine
Google Container Engine
Google Data Analytics
Google Data Studio
Google Date Studio
Google Deployment Manager
Google Drive
Google Earth Engine
Google Genomics
Google Kubernetes Engine
Google maps
google maps api
Google Maps APIs
Google Maps Platform
Google SafeSearch
Google Service Control
Google Sheets
Google Slides
Google Translate
Google Trust Services
Google VPC
Google マップ
Google 公認プロフェッショナル
GoogleNext18
GPU
Gradle
Grafeas
GroupBy
gRPC
HA / DR
Haskell
HEPCloud
HIPAA
Horizon
HTCondor
IaaS
IAM
IBM
IBM POWER9
icon
IERS
Improbable
INEVITABLE ja night
inevitableja
InShorts
Intel
IntelliJ
Internal Load Balancing
Internet2
IoT
Issue Tracker
Java
Jenkins
JFrog
JFrog Artifactory SaaS
Jupiter
Jupyter
Kaggle
Kayenta
Khan Academy
Knative
Komprise
kubefed
Kubeflow Pipelines
Kubernetes
KVM
Landsat
load shedding
Local SSD
Logging
Looker
Machine Learning
Magenta
Managed Instance Group
Managed Instance Group Updater
Maps API
Maps-sensei
Mapsコーナー
Maven
Maxon Cinema 4D
MightyTV
Mission Control
MongoDB
MQTT
Multiplay
MySQL
Nearline
Network Time Protocol
Networking
neural networks
Next
Node
NoSQL
NTP
NuGet パッケージ
OCP
OLDISM
Open Compute Project
OpenCAPI
OpenCAPI Consortium
OpenShift Dedicated
Orbitera
Organization
Orion
Osaka
Paas
Panda
Particle
Partner Interconnect
Percona
Pete's Dragon
Pivotal
Pivotal Cloud Foundry
PLCN
Podcast
Pokemon GO
Pokémon GO
Poseidon
Postgre
PowerPoint
PowerShell
Professional Cloud Network Engineer
Protocol Buffers
Puppet
Pythian
Python
Qwiklabs
Rails
Raspberry Pi
Red Hat
Redis
Regional Managed Instance Groups
Ruby
Rust
SAP
SAP Cloud Platform
SC16
ScaleArc
Secure LDAP
Security & Identity
Sentinel-2
Service Broker
Serving Websites
Shared VPC
SideFX Houdini
SIGOPS Hall of Fame Award
Sinatra
Site Reliability Engineering
Skaffold
SLA
Slack
SLI
SLO
Slurm
Snap
Spaceknow
SpatialOS
Spinnaker
Spring
SQL Server
SRE
SSL policies
Stack Overflow
Stackdriver
Stackdriver Agent
Stackdriver APM
Stackdriver Debugger
Stackdriver Diagnostics
Stackdriver Error Reporting
Stackdriver Logging
Stackdriver Monitoring
Stackdriver Trace
Stanford
Startups
StatefulSets
Storage & Databases
StorReduce
Streak
Sureline
Sysbench
Tableau
Talend
Tensor Flow
Tensor Processing Unit
TensorFlow
Terraform
The Carousel
TPU
Trace
Transfer Appliance
Transfer Service
Translate API
Uber
Velostrata
Veritas
Video Intelligence API
Vision API
Visual Studio
Visualization
Vitess
VM
VM Image
VPC Flow Logs
VR
VSS
Waze
Weave Cloud
Web Risk AP
Webyog
Wide and Deep
Windows Server
Windows ワークロード
Wix
Worlds Adrift
Xplenty
Yellowfin
YouTube
Zaius
Zaius P9 Server
Zipkin
ZYNC Render
アーキテクチャ図
イベント
エラーバジェット
エンティティ
オンライン教育
クラウド アーキテクト
クラウド移行
グローバル ネットワーク
ゲーム
コードラボ
コミュニティ
コンテスト
コンピューティング
サーバーレス
サービス アカウント
サポート
ジッター
ショート動画シリーズ
スタートガイド
ストレージ
セキュリティ
セミナー
ソリューション ガイド
ソリューション: メディア
データ エンジニア
データセンター
デベロッパー
パートナーシップ
ビッグデータ
ファジング
プリエンプティブル GPU
プリエンプティブル VM
フルマネージド
ヘルスケア
ホワイトペーパー
マイクロサービス
まっぷす先生
マルチクラウド
リージョン
ロード シェディング
運用管理
可用性
海底ケーブル
機械学習
金融
継続的デリバリ
月刊ニュース
資格、認定
新機能、アップデート
深層学習
深層強化学習
人気記事ランキング
内部負荷分散
認定試験
認定資格
料金
Archive
2019
8月
7月
6月
5月
4月
3月
2月
1月
2018
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2017
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2016
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2015
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2014
12月
11月
10月
9月
8月
6月
5月
4月
3月
2月
Feed
月刊ニュースレターに
登録
新着ポストをメールで受け取る
Follow @GoogleCloud_jp
