Google Cloud Platform Japan Blog
最新情報や使い方、チュートリアル、国内外の事例やイベントについてお伝えします。
クラウドの料金体系を理解する: 第 4 部 – 真のクラウド エコノミクス編
2015年7月30日木曜日
* この投稿は、米国時間 7 月 27 日、Google Cloud Platform, Global Head of Solutions の
Miles Ward によって投稿されたもの
の抄訳です。
今夏の NEXT イベント
(東京では6月18日開催)では、世界中の開発者の方々と現在抱えている問題について話し合う機会がありましたが、その中で常に皆さまの念頭にあったものの 1 つが、クラウドを検討する際のコストの問題です。
さらにはお客様が本当に理解したいと考えているのは、単なる価格表でも割引でもなく、長期的な視点から見た真のクラウド エコノミクスであり、現在ある数え切れないほどのシステムの構築方法に伴う経済性です。
長年の経験を持つ実績のあるベテランの専門家にとっても、クラウド サービスの柔軟性/パフォーマンスと価格との対比を、熟知しているオンプレミスでの対比と比較することは非常に困難です。
よく知られた一般的な方法(キャパシティ プランニング、サプライチェーン マネジメント、不動産/施設運用、デコミッショニングなど)が多数あるものの、これらは単純にクラウド環境に対して適切であるとは言い難く、またこれらの手法を切り捨ててしまうことでどの程度状況が変わるのかは判断しにくいところです。
クラウドのコストについてお客様に理解を深めていただくために、私のチームはいくつかのアプローチを採用しています。粒度が細かくオンデマンドでかつ従量課金制でロックインのない
Google Cloud Platform
を用いることによって、分散ソフトウェアと機械学習、超高速ツールの機能を最大限に活用でき、極めて低い TCO(総所有コスト)で目覚ましいパフォーマンスを実現できます。しかしこれらの仕様は時に複雑さをもたらすので私達は、機能の背景・文脈を提供し、わかりやすくすることに焦点をおいています。
まず私達は
コンピューティング
と
ストレージ
の両方を対象に Google Cloud Platform の月額料金を見積もるための使いやすい
料金計算ツール
と TCO ツールを構築しました。また過去のブログの投稿では、少し実装変えるだけで TCO にどれほどの違いがもたらされるかを比較対照する具体例も紹介しています。
過去の料金ポスト
クラウドの料金体系を理解する: 第 1 部 ― 仮想コンピュータ編
クラウドの料金体系を理解する: 第 2 部 ― ローカル SSD 編
クラウドの料金体系を理解する: 第 3 部 ― データ ウェアハウス編
クラウドの料金体系を理解する: 第 3.2 部 ― データ ウェアハウスに関する追加情報編
今後も料金ページのアップデートのほか、コスト効率の観点からシステムの最適化を支援ツールの構築も継続していきます。ぜひ今後もフィードバックをお寄せください。
こうした価格/パフォーマンスに対するアプローチは、ただ単に
競争力のある料金体系
を決定づけているだけではありません。Google は自動的な継続使用割引のほか、前払いによるロックインを防ぎ、分単位で課金することでユーザーが余計にお金を払う必要をなくすなどといった革新的な方法を提供しながら、クラウド エコノミクスにおけるリーダーシップを発揮することに焦点を置いています。
私はチューバを演奏しますので、
私の写真
をみて大ぼらを吹いていると思われても仕方ないかもしれません。冗談はさておき、私達はこれらの事実が第三者の検証によって得られることは、ビジネスとテクニカルサイド双方の賢明な意思決定者にとっても極めて重要なことは当然理解しています。トヨタ自動車のエンジニアがあなたの自動車についてアドバイスをするからといってもすべてを聞いてすべて言うとおりにすることはないですよね。
Google が構築したツールと
Google Cloud Platform
の総コストに関するステートメントは、技術システムの価格/パフォーマンスの評価で長年の経験を持つ、独立した分析会社の
Enterprise Strategy Group
(以下 ESG ) によって詳細に検証されています。
こうした評価の実行は容易ではありませんが、
ESG
は入念かつ系統的な徹底したアプローチをもって Google のサービスを理解した上で、独自のモデリングと設定した前提(TCO の評価にあたって理にかなう前提を設定することは、まさに数学にほかなりません)に従って、
Google Cloud Platform
の TCO に関する分析値を弾き出しました。
(詳細はこちらを参照:
ESG Lab White Paper "Price Comparison: Google Cloud Platform vs. Amazon Web Service
)
この分析では、私達がずっと主張し続けてきた TCO における優位性のほか、
ESG
が新たに着眼した複数の点でその正当性が実証されました。
正直なところ検証結果を見てひと安心しました。 聡明で探求心のある人に成果物をチェックしてもらい、太鼓判を押してもらうのはいつだってうれしいことです。
ESG の調査資料
は明確でわかりやすい上に情報がたくさん詰まっています。クラウドの複雑な TCO の理解に苦労している方はお読みいただくことをお勧めします。皆さまのご意見のほか、他にどんな比較や評価が意思決定のプロセスに役立っているか、体験談もぜひお知らせください!
-Miles Ward, Global Head of Solutions, Google Cloud Platform
Google Cloud Storage Nearline がついに一般公開
2015年7月28日火曜日
* この投稿は、米国時間 7 月 23 日、Product Manager の
Avtandil Garakanidze によって投稿されたもの
の抄訳です。
Google Cloud Storage Nearline
の目標は、単純、低コストで反応が早く、バックアップ、検索、データアクセスが素早いストレージサービスを企業や組織に提供することです。(
過去の Nearline に関する記事
を参照)
ユーザーが作り出すデータの量が増えていることを考えると、企業、組織がデータを死蔵するようになってきていることは意外なことではありません。企業はもうデータを捨てることなど許されないのです。実際、集めたデータを分析して市場についての知識を獲得し、競争力を維持することは、企業にとってきわめて重要になっています。
初めてリリースされた頃、
Google Cloud Storage Nearline
は、
コールドストレージの概念が不要に
なるようなストレージソリューションと広く考えられてきましたが、私たちはそんなところには留まりませんでした。
ユーザーエクスペリエンスを向上させるために、99% の稼働時間を誇る SLA、
オンデマンド I/O
、
ライフサイクル管理
を追加し、
パートナー エコシステム
を大幅に拡大した上で、
Cloud Storage Nearline
と
Cloud Storage Transfer Service
が今日ついに一般公開されます。
さらに、Google が用意した
Switch and Save プログラム
を使えば、
Google Cloud Storage Nearline
への移行がスムースに行えますし、費用も低く抑えられます。
オンデマンド I/O の導入
格納されているデータ 1TB あたり 4MB /秒というプロビジョニングされたスループットよりも高速に、
Google Cloud Storage Nearline
バケットからデータを取得しなければならないときに I/O の能力を増強できるオンデマンド I/O を導入します。
オンデマンド I/O
は、必要なときに限りスループットを増強することができるだけでなく、料金は使った分だけしか発生しません。データリカバリを確実なものとして計算に入れつつ、数秒でデータにアクセスできるようになります。
一般リリース後 3 か月間は、追加料金なしで
オンデマンド I/O
を使えます。
Cloud Storage Transfer Service を公開
また、
Cloud Storage Transfer Service
(従来は Online Cloud Import と呼ばれていたもの)がすべての企業、組織に対して公開されます。Amazon S3(Amazon Simple Storage)などの HTTP/HTTPS 上の位置から
Google Cloud Storage
に大量のオンラインデータを簡単にインポートできるようになり、効果的にコストを削減できるようになります。反復されるデータ転送をスケジューリングするだけでなく、1 度限りのデータマイグレーションも設定できるようになります。Cloud Storage Transfer Service を使えば、
ライフサイクル管理
も実現できます。
Cloud Storage Nearline
への自動アーカイブ、削除のスケジューリングなど、オブジェクトのライフサイクル管理を単純化する機能が提供されます。
Switch and Save プログラムを開始
さらに、
Cloud Storage Nearline
で 6 か月以内の期間、100PB の無料ストレージを手に入れられる
Switch and Save プログラム
も今日からスタートします。ほかのクラウドサービスプロバイダやオンプレミス インフラストラクチャから移行するために、新規利用者として Google Cloud Platform を契約すると、ストレージのコストを大幅に削減できるのです。Amazon Web Services と比べて、
Google Cloud Storage Nearline
ならどれくらいのコスト節減効果があるのかを推計するための
TCO 計算ページ
も用意してあります。
ストレージのプラットフォームとプロセスを乗り換えるのは容易なことではありません。強力なパート ナーエコシステムがない限り、
Cloud Storage Nearline
をスムースに採用することは覚束ないでしょう。お客様がデータストレージのためにまったく新しいアプローチを取れるようにするために、
Cloud Storage Nearline
パートナーを一気にベータテスト時の倍以上にしたのはそのためです。従来の
Veritas/Symantec
、
NetApp
、
Iron Mountain
、
Geminare
に加えて、新たに次の 5 社がパートナーになりました。
Google Cloud Platform プレミア パートナー
Actifio は、企業のデータ回復、機動的データ操作のあらゆるユースケースで、今までにないスピード、効率、単純さでアプリケーションデータをキャプチャ、管理、利用できるようにする製品を提供しています。
Actifio の賞を受けている企業データコピー仮想化プラットフォームを使えば、企業データを Google Cloud Storage Nealine に格納する作業は驚くほど単純になります。
Pixit Media は、特別なハードウェア機器を必要とすることなく、Google Cloud にホスティングされた映像リソースのユーザーをオンプレミスストレージに接続します。
さらに、Pixit Media PixStor ユーザーは、Pixit のオブジェクトプラグインを使って「よりコールドな」データの、バックアップ、アーカイブ用に Google Cloud Storage を使うことができます。
バックアップ、アーカイブに必要な時間を数日から数分に短縮するという Pixtor のポリシーに従い、データは記録的な速さで保護、マイグレーションされます。
Unitrends Free™ for Google Cloud Platform は、VMware vSphere や Microsoft Hiper-V 環境の仮想アプライアンスとしてすばやくデプロイできる無料のバックアップソフトウェアです。
Unitrends Free for Google Cloud は、ローカルにデータをバックアップし、Google Cloud Storage や Google Cloud Storage Nearline とシームレスに統合され、クラウドにバックアップのコピーを作ります。
Google Cloud プラットフォーム パートナー
CloudBerry Backup は、Google Cloud Storage Nearline を活用するクラウドバックアップソリューションです。
CloudBerry は、リアルタイム/スケジュールによるローカルディスクイメージの暗号化されたバックアップと未初期化システムへ のリストアを提供するほか、効率を最大限に引き上げるブロックレベルのバックアップを採用し、バックアップ、リストアプランをリモートに監視するアラート機能を提供しています。
Filepicker は、6 万種を越えるアプリケーションが簡単、単純にクラウドドライブと統合されるように支援します。
Filepicker を使うアプリケーションは、自動的に Google Cloud Storage Nearline に統合され、コスト削減とライフサイクル管理のメリットを享受するようになります。
今挙げたパートナー以外にも、
Google Cloud Strage
を統合し、Google Cloud Storage Nearline サポートを追加して、ユーザーが障害からの回復、バックアップを最適化できるようにしているグローバルなストレージベンダーのエコシステムは拡大しています。
Commvault の Simpana プラットフォームは、ver.10サービスパック11のリリース以来、Google Cloud Storage Nearline の単純でシームレスなネーティブサポートを提供しています。
Commvaultというひとつのプラットフォームのもとで、ユーザーは Cloud Storage Nearline をデータバックアップやアーカイブのリポジトリとして利用することができます。しかも、社内全体で使っているさまざまなストレージプラットフォームを通じて、内容をきちんと把握することができます。
EMC NetWorker 8.2 with CloudBoost と EMC Avamar 7.1 with CloudBoost は、Google Cloud Storage Nearline を使ってバックアップデータの効率的で安全な長期保存を実現し、テープを不要にするとともに、設備投資にかかるコストを削減します。 EMC CloudArray は、クラウドストレージを NAS や SAN のような外観、使用感に変えるもので、あまり使われないデータをオンラインでアクセスできるようにしておきたいと考えている企業にとってはコスト的に魅力的なソリューションです。
CloudBoost と CloudArray は、Standard、DRA、Nearline という Google Cloud Storage の 3 つのティアをすべてサポートします。
Egnyte は、一元的な管理、統一的な視野、セキュリティの担保されたアクセスのもとでファイル共有環境を統合するもので、Google Cloud Storage Nearline、Google Cloud サービスを統合しています。
エンドユーザーは、どのアプリケーション、デバイスを使っても最適化され統一された操作をすることができます。
今すぐ始めよう
Cloud Storage Nearline を試したい場合には、
Nearline サイト
と
ドキュメント
を参照して下さい。Google Cloud Platform を初めて使われるお客様は、最長で 6 か月に渡って Cloud Storage Nearline の 100PB の無料ストレージを手に入れられる
Switch and Save プログラム
をご利用ください。また、
Cloud Storage Nearline パートナー
のページでも、Google プラットフォームを統合してその機能や射程を拡大し、サービスを早く使いこなせるようにするソリューションを提供しているパートナーが見つかるかもしれません。
- Posted by Avtandil Garakanidze, Product Manager
ウェビナー開催のお知らせ「Google Cloud Platform を始めよう」
2015年7月27日月曜日
Google のウェビナー「Google Cloud Platform を始めよう」が、世界中の開発者に向けて 3 つのタイム ゾーンで実施されます。段階的なデモンストレーション形式で実施されるコンテンツとなっていますので、ぜひご参加ください。
面倒なインフラストラクチャ周りの作業に手間をかけずに、自分のアイデアをできるだけすばやく開発し、形あるものにしたい。ソフトウェア エンジニアであれば、誰もがそう考えるに違いありません。そういった開発者達のために
Google Cloud Platform
は、 Google の持つ極めてスケーラブルでかつ信頼性の高いインフラストラクチャを土台にして、アプリケーションを構築、テスト、デプロイできるよう設計されています。
Google は、試用の申し込み、仮想マシンの作成、アプリケーションのローンチといったタスクを、簡単に、かつ素早く実行できるようにするべきだと考えています。そこで私達はデベロッパー アドボケイトを結集し、利用頻度の高く一般的なタスクや、 Google Cloud Platform の利用を検討しているユーザーからよく聞かれる質問をまとめたハウツーガイドを作成しました。
ウェビナー
:Google Cloud Platform を始めよう
所要時間
:30 分
トピック
:
1. Google Cloud Platform のアカウント設定
2. Cloud Launcher によるすばやい WordPress のデプロイ
3. 料金計算ツールよる料金の見積もり
4. ファイアーウォールとネットワークの構成
5. カスタム スタックの設定方法
6. バックアップ、ディスク容量の増加、サーバーのアップグレード
7. まとめ
下記のタイム ゾーンで同じウェビナーが実施されます。
南北アメリカ
2015 年 7 月 28 日 (火) 午前 10 時〜 (米国西海岸時間; 太平洋時間)
2015 年 7 月 29 日 (水) 午後 3 時〜(日本時間)
[
申し込みはこちらから
]
ヨーロッパ、中東、アフリカ
2015 年 7 月 29 日(水)
午前 10 時〜(イギリス)
午前 11 時〜(フランス)
午後 12 時〜(イスラエル)
[
申し込みはこちらから
]
アジア太平洋
2015 年 7 月 30 日(木)
午前 10 時 30 分〜(インド)
午後 1 時〜(シンガポール/香港)
午後 3 時〜(シドニー、 オーストラリア東部夏時間)
午後 2 時〜(日本時間)
[
申し込みはこちらから
]
Google Cloud Platform アカウントの
無料トライアル
もぜひお試しください。トライアルではクレジットカードに料金が請求されることはありません。
gRPC を使用した効率的なモバイル アプリの構築
2015年7月27日月曜日
* この投稿は、米国時間 7 月 20 日、Google Cloud Platform Technical Writer の
Syne Mitchell によって投稿されたもの
の抄訳です。
モバイル端末からバックエンド サーバーにデータを送信する場合、大量のリソースが消費される場合があります。HTTP/1.1 標準を使用して頻繁に接続を行うと、電池の消耗やレイテンシの増加のほか、他のアプリの接続を遮断する原因になります。
Google のフレームワークである
gRPC
は、モバイル クライアントとバックエンド サーバー間のリモート プロシージャ コール(RPC)をより効率良く処理します。
HTTP/2
標準が採用されているため、双方向ストリーミング、フロー制御、ヘッダー圧縮、単一の TCP/IP 接続に対する多重リクエストが可能です。
また、モバイル アプリの帯域幅の効率が改善され、クラウドで実行されるアプリとサービス間のレイテンシも低減します。データ送信にかかる料金の節約と応答時間の短縮により、モバイルユーザーの満足度が向上します。
gRPC と Google Cloud Platform を使用したモバイル アプリの画像管理
のケースでは、これらの技術を使用した効率的な写真共有アプリの構築に関する解説だけでなく、2 つのバックエンド サービスや iOS と Android の両方のモバイル クライアントを含む、設計パターン全体のオープンソースのリファレンス実装が詳しく紹介されています。
上記ケースは 3 つの要素で構成されています。
モバイル アプリ:
ユーザーはモバイル アプリを使用して写真のアップロードや写真への投票ができるほか、アップロードした時期や人気別に分類された、友達の写真リストを閲覧できます。
メタデータ サービス:
gRPC や Google Cloud Datastore を使用する大量のトラフィック向けに設計されたメタデータ サービスには、画像、ユーザー、投票に関する情報が保存されます。
画像処理のアプリケーション:
Google App Engine のアプリケーションは Google Cloud Platform の一連のサービスのオーケストレーションを実行し、ユーザーがアップロードした画像をモバイル端末で表示する最適なサイズに変更します。
詳しくは
gRPC と Google Cloud Platformを使用したモバイル アプリの画像管理のケース
構築に関する解説や、
コードのダウンロード
をご覧ください。
Google では皆様のご意見を歓迎しています。
こちら
のページ右上にある「
フィードバックを送信
」からご感想をお寄せください。
-posted by Syne Mitchell, Google Cloud Platform Technical Writer
コンテナ + プライベート クラウド: Google、OpenStack Foundation のスポンサーへ
2015年7月25日土曜日
* この投稿は、米国時間 7 月 16 日、 Product Manager の
Craig McLuckie によって投稿されたもの
の抄訳です。
Google は本日、エンタープライズ向けのオープン IaaS の開発に取り組む業界団体の
OpenStack Foundation
のスポンサーになりました。
最も多く採用されるプライベート クラウドに Google のコンテナ技術に関する専門知識を提供し、プライベート クラウドとパブリック クラウドの相互運用性の向上に貢献できることに喜びを感じています。
今後のエンタープライズ コンピューティングについては、2 つの重要なトレンドが浮上しています。
1 つめはハイブリッド クラウドへの動きです。すべてのインフラストラクチャをパブリック クラウドに移行できる企業はほとんどなく、大半の場合はハイブリッドのデプロイが一般的になるでしょう。OpenStack はこうしたデプロイのオンプレミス コンポーネントのスタンダードとして浮上しています。
2 つめはコンテナによるコンピューティングへの動きです。Google はコンテナ、動的なスケジューリング、マイクロサービスのアーキテクチャの新しいパターンをいち早く開発しました。
インターネット サイズでのアプリケーションの構築と、運用に関する困難な問題の解決が目的でしたが、このモデルは日常的なアプリケーションにうまく適合し、オペレーションでの長年の問題を解決しています。最近、Google は
Kubernetes
プロジェクトを通じ、オープンソースのコミュニティにこれらのパターンの公開を開始しました。
これら 2 つの傾向の接点があらゆるビジネスにとって重要だと考える Google は、OpenStack Foundation との協力のもとに、コンテナ ネイティブのパターンをエンタープライズ向け開発者の開発ツール群に追加し、パブリック クラウドとプライベート クラウドの相互運用性を向上させたいと考えています。強力なハイブリッドクラウドの実現に向け、今後数か月にわたってコミュニティと連携する中で、Kubernetes やコンテナの補完的技術の統合に取り組む予定です。
Kubernetes やオープンソースのコンテナ オーケストレーション システムの詳細については、
こちら
からご確認いただけます。また、Google の OpenStack への参加については、
こちら
をご覧ください。
- Posted By Craig McLuckie, Product Manager
Application Default Credentials による Google Cloud API で認証設定をシンプルに
2015年7月25日土曜日
* この投稿は、米国時間 7 月 20 日、Google Cloud Platform, Technical Program Manager の
Vijay Subramani によって投稿されたもの
の抄訳です。
Google Compute Engine
のインスタンスを使用するアプリケーションの作成時に、そのアプリケーションを
Google Cloud Storage
や
BigQuery
などの Google Cloud Platform サービスに接続する必要があるかもしれません。適切な呼び出し元が正しく呼び出しできるようにするために、こうしたサービスでは認証の国際基準である OAuth2 が採用されています。ところが、今までOAuth2 は使いづらいものでした。API の最初の呼び出しをしようとするだけで、多くの場合に専門知識や認証設定のボイラープレート コードが多数必要になるからです。
Google は本日、こうした問題を解決する
Application Default Credentials
(ADC)の提供を開始します。ほとんどの場合、アプリケーションで必要になるのは下記の 1 行の認証コードだけです。
Credential credential = GoogleCredential.getApplicationDefault();
2LO、3LO、サービス アカウントなど、認証のコンセプトについてご存知でない場合は、
こちらの解説
が役立つでしょう。ADC は複雑さを完全に排除し、API 呼び出しを 1 回のみにします。これは以下のような点を活用することによって可能になっています。
2-legged(2LO)OAuth VS 3-legged(3LO) OAuth:
OAuth2 は、ユーザー、API プロバイダー、アプリケーション開発者が認証のプロセスで関与する必要がある、ユーザー所有のデータに対応しています。大半のクラウド API はユーザー所有のデータを処理しないため、API プロバイダーとアプリケーション開発者間だけのより単純なフローを使用できます。
gcloud CLI :
クラウド リソースの検討や管理を行う際に、アプリケーションの開発やデバッグでコマンドライン ツールの gcloud を使用した経験はないでしょうか。ADC では gcloud でアプリケーションに認証フローを使用できるため、認証情報の設定は一度だけです。
サービス アカウント:
App Engine または Google Compute Engine で実行されるアプリケーションでは、安全な「サービス アカウント」へのアクセスが自動的に確保されるため、API 呼び出しは必ず確かな呼び出し元から行われることになります。API プロバイダーがこれを信用できることは、アプリケーションにとって有益です。
Google Application Default Credentials の詳細については、
こちら
からご確認いただけます。Java、Python、Node.js、Ruby、Go に対応しているほか、PHP と .Net のライブラリも開発中です。
- Posted by Vijay Subramani, Technical Program Manager, Google Cloud Platform
Click to Deploy で Wowza Streaming Engine を活用した ライブ メディア ストリーミング
2015年7月24日金曜日
* この投稿は、米国時間 7 月 22 日、Google Cloud Platform, Product Manager の
Srikanth Belwadi によって投稿
されたものの抄訳です。
動画コンテンツへの消費者の爆発的な需要によって、 2020 年までに世界的なインターネットのトラフィックはオンライン動画が 80 % を占めると予測されています。現時点でさえも、デスクトップとモバイルで消費されている動画はコンテンツ全体の半分を優に上回っています。
こうした状況の中ユーザーは、HD 品質の優れたコンテンツを最小限のラグで、オンデマンドかつ端末を選ばずに視聴することをますます期待しています。また、リアルタイムでのライブ ストリーミングへの需要も拡大しています。
しかし動画と音声の高品質で確実なストリーミングを可能にするメディア サーバーの調達、構成、デプロイは、高額で複雑になる場合があります。そこで Google は
Wowza Media Systems
と連携し、クリックするだけで Google のインフラストラクチャにデプロイできるストリーミング ソリューションである
Wowza Streaming Engine
の提供を開始しました。
Google Cloud Platform で
Wowza Streaming Engine
を実行することで、Google の信頼できるネットワークから世界中のあらゆる場所にいるユーザーに向けて、高品質なオンデマンドのライブ コンテンツをストリーミングできます。
このクラウド ネイティブの設定では、VM の高速なプロビジョニングやグローバル ロード バランシングを自動的に活用できる
Google の高パフォーマンスの仮想マシン
が利用されます。そのため、分単位での課金や自動的に適用される継続使用割引など、コスト面のメリットもあります。
Wowza Streaming Engine
の持つ業界最先端の機能はすべて利用することができます。例えば、リアルタイム トランスコーディングを無制限に実行できる
Wowza Transcoder
は、エンドユーザーのさまざまなデバイスやネットワークの状況に対応するアダプティブ ストリーミングが可能です。
「
Google Compute Engine
は信頼できるクラウド プラットフォームというだけでなく、極めて優れたネットワーク パフォーマンスも期待通りに実現します」とWowza Media Systems の共同創設者であり CTO を務めるチャーリー グッド氏は述べています。
「
Google Compute Engine
の Click to Deploy から
Wowza Streaming Engine
を提供できることを光栄に思っています。すばやいデプロイとストリーミングを希望される Wowza のお客様にとって、オンデマンドのライブ動画をあらゆるデバイスを対象に一貫してグローバルにストリーミングする
Google Compute Engine
は、最適な選択肢でしょう」
33 か国に 70 か所以上存在する Google のグローバル ネットワーク フットプリントによって、世界中のオーディエンスにすばやく、かつてないほどの規模でリーチできます。
クラウドベースのコンテンツのストリーミングは、ユーザーに優れたコンテンツを提供する最もシンプルでコスト効率の高い方法です。Click to Deploy を活用することで、わずか数分であらゆるデバイスを対象にコンテンツをストリーミングできる新しいメディア サーバーを作成することができます。
Wowza と Google 両社ゲストによるウェビナーも開催!
「
Google Compute Engine の Click to Deploy で Wowza Streaming Engine を活用し、 すばやいデプロイとストリーミングを
」
日程:2015 年 7 月 29 日(水)
時間:午前 11 時(太平洋時間)| 午後 2 時(東部標準時)| 午後 6 時(グリニッジ標準時)
こちらから今すぐ登録
- Posted by Srikanth Belwadi, Product Manager, Google Cloud Platform
Google Cloud Platform でディザスタ リカバリを行うには
2015年7月24日金曜日
* この投稿は、米国時間 7 月 16 日、Solutions Architect の
Grace Mollison によって投稿
されたものの抄訳です。
システムがホストされている場所や活用されている一連の技術、使用される言語にかかわらず、災害によってサービスが中断され、企業の顧客がシステムを利用できなくなる可能性はゼロではありません。優れたシステムに不可欠なディザスタ リカバリ計画(以下 DR 計画)は災害発生時のランブックとなり、システムをできるだけ速やかに復旧することに役立ちます。
災害復旧を支援する
Google Cloud Platform
では DR 計画の実装に伴うコストと労力を大幅に削減できますが、だからといって万能なソリューションは存在するわけではありません。
そこで、Google は企業のビジネスや特定のユース ケースに合ったコスト効率の高いソリューションの特定に役立つ
DR 計画ガイド
と
手順書
をリリースしました。
計画の作成時に考慮すべき事項が詳細に解説される
DR 計画ガイド
では、リカバリの目標に合わせた計画の作成からインスタンスの開始に使用する構成が RTO(recovery time objective)に与える影響まで、さまざまなトピックが網羅されています。Google Cloud Platform についてよくご存知でない場合も、DR 計画で一般的に利用されている製品のリストを確認することができます。
DR 計画ガイド
を補完する
手順書
では、Google Cloud Platform を活用したさまざまな DR 計画の実装に関するガイダンスが提供されています。
例えば階層型ストレージ ソリューションの実装を検討しているものの、コストが原因で実現していない場合にコストを抑えながらそれに対処するシナリオが紹介されています。
また、オンプレミスの本番アプリケーションをクラウドにフェイルオーバーする方法も解説されています。これらはほんの一例であり、他にも多くのシナリオが網羅されています。これらのシナリオは、オンプレミスで導入する場合でも、Google Cloud Platform や他のクラウド プロバイダーを利用する場合でも活用できます。
Google Cloud Platform
を活用されていなくても、お客様のユースケースに合った DR 計画の実装に
DR 計画ガイド
と
手順書
をぜひご活用ください。
-Posted by Grace Mollison, Solutions Architect
Kubernetes V1 リリースとコンテナ イノベーションをリードする CNCF の設立
2015年7月23日木曜日
* この投稿は、米国時間 7 月 21 日、Product Manager の
Craig Mcluckie によって投稿されたもの
の抄訳です。
コミュニティを代表してお伝えします。お待たせしました。オープンソースのコンテナ管理システム、
Kubernetes
が v1 という大きなマイルストーン(
GitHub
)に到達しました。400 人のコントリビュータが構築したこの重要なリリースにより、Kubernetes は本番稼働に耐えるものになりました。これは大きなニュースですが、コンテナ ツールセット全体を完成させるためには、まだ多くの仕事が残されています。
今日、Google は、コンテナベース コンピューティングの未来を切り開くために、Linux Foundation や一流企業から構成されるパートナーグループとともに CNCF(
Cloud Native Computing Foundation
)を発足させます。CNCF は、オープンソース、パートナーコミュニティと協力して、Kubernetes の将来の開発を管理するとともに、コンテナ ツールセット全体を堅牢にする新しいソフトウェアを構築していきます。
Kubernetes は 400 人のコントリビュータからの 14,000 コミットにより v1 に到達
今年2月、Kubernetes のコントリビュータたちはサンフランシスコに集まり、機能、信頼性、サポート対応力という観点から 1.0 に求められる内容について合意に達しましたが、今日、その目標を達成しました。Kubernetes は、すばらしい機能セットを備え、本番稼働使用に耐えられるものになりました。
アプリケーション サービス、ネットワーク、ストレージ
DNS、ロードバランシング、スケーリング、アプリケーション レベルでのヘルス チェック、
サービスアカウント
など、本番システムのデプロイ、ワークロードの管理に欠かせないコア機能を揃えています。
Google Compute Engine
の永続ディスク、AWS Elastic Block Store、NFS のようななど、ローカルやネットワークベースのさまざまな
ストレージボリューム
により、ステートフル アプリケーションをサポートします。
密接に関連するコンテナをポッドにまとめられるようになっており、アップデートやロールバックが容易になっています。
コマンド実行・ポート転送
、
ログ収集
、CLI と UI を介したリソース モニタリングによってアプリケーションを点検、デバッグすることができます。
クラスタ管理
稼働中のクラスタのアップグレード、動的なスケーリングをサポートします。
名前空間
を介してクラスタをパーティションに分割してリソースをきめ細かく管理できます。たとえば、アプリケーションごと、あるいはテスト環境と本番環境にクラスタを分割できます。
パフォーマンスと安定性
平均 5 秒未満でスケジューリングされるコンテナにより高速な API 応答を実現します。
クラスタあたり千個前後、ノードあたり百個前後のコンテナのスケーリングがテスト済みです。
非推奨の正式なポリシーが決められており、安定した API を提供しています。
Kubernetes は、わずか 1 年でもっとも多くの人々から支持され、成功を収めたオープンソースプロジェクトのひとつになりました。Red Hat、CoreOS、IBM、Intel、Microsoft、VMware を始めとする多くの一流企業のデベロッパを含む 400 人のコントリビュータが 14,000 回を越えるコミットをしています。
顧客企業各社は、すでに Kubernetes 上で本番インフラの一部を実行しています。
「Box は、コラボレーションを促進し、情報を安全に保つシステムとして信頼されています。Kubernetes の導入により、アプリケーションの移植性と運用の機動性という点で新しい可能性が開けました。Kubernetes の技術的な品質の高さと完成度にはいつも感心しており、Kubernetes は弊社のインフラストラクチャのコア コンポーネントになると考えています」
- Sam Ghods, Box 技術担当 VP
「eBay は、世界でもっとも大規模なオープンプライベート クラウドのひとつを構築、運用し、この分野のイノベーションをリードしてきました。コンテナとデータセンター OS が新しい地平を切り開いたことにより、クラウドファースト アプリケーションをシームレスに提供したいインフラストラクチャ プロバイダやデベロッパには、比類ないチャンスが到来しています。私たちは Kubernetes ファウンデーションに参加し、コミュニティ主導のオープンなプロジェクトをリードして、イノベーションのペースを加速し、Kubernetes の普及をお手伝いできることを楽しみにしています」
- Debashis Saha, eBay クラウドサービス担当 VP
「コンテナにパッケージされ、動的にスケジューリングされるマイクロサービス指向のアプリケーションを作れるようにするという Google のビジョンには、RedHat も共感しています共有するものです。そして、弊社の Kubernetes と Docker への投資は、デベロッパ エクスペリエンスの向上、運用の単純化、効率の向上、アプリケーション全体の機動性とメンテナンス性の向上という形ですでに顧客のために大きな成果を生んでいます」
- Lars Herrmann, Red Hat 統合ソリューションビジネスユニット及びコンテナ戦略担当本部長
Samsung SDS
「私たちはプライベート インフラストラクチャからパブリッククラウドまでの多様なグローバル インフラストラクチャのもとで複雑なアプリケーション エコシステムを運用しています。Kubernetes は、弊社のようなエンタープライズ インフラストラクチャのもとでアプリケーションを開発、デプロイ、運用、マイグレートするときの不協和音を大幅に緩和できる基幹テクノロジだと思っています」
- Richard Kaufmann, Samsung SDS Research America アーキテクチャ担当 VP
「Shippable では、弊社のプラットフォームのコンテナ、クラスタ管理を Kubernetes にコンバートしました。現在では、毎月百万以上のコンテナを Kubernetes 上で実行しています。弊社は非常に早い時期に Docker を採用したので、ほぼ 2 年間はコンテナのデプロイ、実行に関して do-it-yourself の状態でした。そのため、弊社は産みの苦しみを味わってきました。しかし、Kubernetes のおかげで、アプリケーションとインフラの管理は単純で信頼できるものに変わりました。Kubernetes 導入以前は、デベロッパたちは週に平均 120 時間も運用がらみの仕事をしていましたが、今では 2、3 時間になっています。これはかなり控え目な数字です。不満は、2 年前に Kubernetes があったらということだけですよ」
- Avi Cavale, Shippable CEO
「Kubernetes はアーキテクチャ的な基礎が正しく、Google のシステム運用の経験が詰まっており、レベルが高く熱心で多様なコミュニティに支えられたオープンソースプロジェクトでもあることから、弊社は当初から非常に注目していました。すでに本番システムで Kubernetes を実行してしばらくたちますが、成熟のペースの速さとコントリビュータたちのコードの品質の高さには感心しています」
- Steve Reed, Zulily コアエンジニアリング部プリンシパル エンジニア
CNCF(Cloud Native Computing Foundation): Google、Linux Foundation、一流パートナー企業がコンテナベース コンピューティングの未来を切り開くために結集
コンテナは、アプリケーションのデプロイ、管理の方法を変えようとしていますが、クラウドネーティブなマイクロサービスベース アプリケーションはまだ生まれたばかりです。弊社は、Linux Foundation、及び Docker、IBM、VMware、Intel、Cisco、Joyent、CoreOS、Mesosphere、Univa、Red Hat などの錚々たるパートナー企業各社とともに、コンテナベースコンピューティングを容易にする CNCF(Cloud Native Computing Foundation)を設立します。
第1歩として、Kubernetes を CNCF に移管することを計画しています。CNCF は、今後の Kubernetes のオープンソース開発を管理し、パブリッククラウド、プライベートクラウド、ベアメタルのいずれのインフラストラクチャのもとでも快適に動作し続けるようにします。
しかし、Kubernetes はまだ始まったばかりです。CNCF の方向性は、技術委員会によって与えられます。技術委員会は、オープンソースやパートナーコミュニティを指揮してコンテナツールセット全体をより堅牢にする新しいソフトウェアを開発します。また、技術委員会は、CNCF で担当すべき新たなプロジェクトの評価も行い、ツールセットを全体として快適に動作させるようにしていきます。
CNCF の運営方針、参加方法などの詳細は、
ウェブサイト
を御覧ください。
Kubernetes パートナー企業の発表
今日、ポートランドで開催されている OSCON では、Kubernetes エコシステムの メンバー企業各社も優れた製品を次々に発表します。
CoreOS は Tectonic Preview with Kubernetes 1.0 をリリースします
CloudBees は、Jenkins のための Kubernetes プラグインをリリースします
Hitachi Data Systems がユニファイド コンピューティング プラットフォーム用の Kubernetes を提供します。
今すぐ 始めよう
Kubernetes はパブリック クラウドプロバイダからプライベート インフラストラクチャまで、あらゆるプラットフォームで動作します。是非、
パートナー企業の製品
をご覧になってください。また、Google のマネージド Kubernetes サービス、、
Google Container Engine
も試してみてください。さらに詳細な情報については、こちらの
OSCON のサイト
にて Kubernetes 1.0 発表のライブストリーミングをご覧ください。
- Posted by Craig Mcluckie, Product Manager
Google Cloud Bigtable 対応の Go クライアント
2015年7月23日木曜日
* この投稿は、米国時間 7 月 17 日、Software Engineer の
David Symonds によって投稿されたもの
の抄訳です。
Go 言語のプログラマーに朗報です。Google Cloud Bigtable に対応する
Go クライアント ライブラリ
が利用可能になりました。
Google Cloud Bigtable
は検索、Gメール、Google Earth、YouTube など、データ処理量の多い Google のアプリケーションを機能させている、ほぼ無限にスケーラブルな NoSQL データベースです。ますます普及している
プログラミング言語の Go
は、クラウド アプリケーションの構築に広く利用されるようになっています。今回、Google Cloud Bigtable では Java HBase API に加え、
慣用的な Go API
を使用することが可能になりました。
Go API には多くのメリットがあります。
容易なインストール
:
go
get
google
.
golang
.
org
/
cloud
/
bigtable
を実行するだけで必要なライブラリをインストールできます。
シンプルな API
: Go クライアント ライブラリは Java HBase API よりも単純なインターフェースです。
低レベル
: Cloud Bigtable の gRPC インターフェースは API の薄い層で包囲されているため、基礎となる RPC が厳密に反映されます。これにより、プログラムのパフォーマンスやコストの特性について容易に判断できます。
Google Cloud Bigtable のすべての機能が利用可能
:スキャン、行フィルタ、条件付きの変換、読み込み/変更/書き込み操作、ミドルアウト圧縮のすべてに対応しています。
すでに数多くの重要な作業に使用されている Go クライアントをぜひお試しください。GitHub でのサンプルは
こちら
から確認できます。
ドキュメント
をお読みの上、
こちら
までご意見をお寄せください。
- Posted by David Symonds, Software Engineer
Cron ハンドラを実装してユニットテストを行う - Google App Engine
2015年7月22日水曜日
* この投稿は、米国時間 7 月 6 日、Cloud Technical Support の
Alex Martelli によって投稿されたもの
の抄訳です。
ソフトウェアの開発ではコードのユニット テストが極めて有効です。モジュール、クラス、機能など、それぞれのコード ユニットを個々に検証する簡単な自動テストを実行することで、開発プロセスの早い段階でエラーの特定とデバッグが可能になります。
Google App Engine
は、現在
Python
、
Java
、
Go
に対応している Local Unit Testing ツールによって、ユニット テストを強力にサポートしています。
ローカルでのユニット テストではリモート コンポーネントを呼び出すことなく、開発環境でユニット テストを実行できます。また Local Unit Testing ツールでは、多数の App Engine のサービスをシミュレーションするためのサービス スタブを使用できます。
ローカルのユニット テストでは必要に応じてこのスタブを使用し、アプリケーションのコードを実行することが可能です。また、
NoseGAE
などのオープンソース パッケージを使用すれば、App Engine でのローカルのユニット テストの作成プロセスをさらに簡略化することができます。
ただし、サービス スタブを使用するローカルのユニット テストの場合、ルーティングとログイン制限はサービスを直接呼び出すコードとは異なって扱われます。テストを作成する際はこの点に留意しなければなりません。
App Engine の
cron
ハンドラのユニット テストで、あるお客様に問題が発生しました。私はその解決にあたりましたが、ここでは
app.yaml
に下記を入力した上で cron のハンドラが定義されていました。
- url: /crontask.*
script: thecron.app
login: admin_only
App Engine Cron Service では、スケジュールされているタスクが使用する
URL へのアクセスを管理者アカウントのみに制限することが推奨
されています。これは
login: admin_only
の設定で実行されます。
お客様は管理者以外のユーザーによる、これらの URL へのアクセスがブロックされるかどうか確認しようとしました。
そこでまず、cron ハンドラ
thecron.py
にプレース ホルダを実装しました。
import webapp2
import time
class TestCronHandler(webapp2.RequestHandler):
def get(self):
self.response.headers['Content-Type'] = 'text/plain'
self.response.write('Cron: {}'.format(time.time()))
app = webapp2.WSGIApplication([
('/crontask/test', TestCronHandler),
], debug=True)
次にユニット テスト
ut.py
が書き込まれました。
(注:下記のテスト コードでは
mock
モジュールが使用されています。ローカルの Python 2.7 のインストールで
mock
モジュールを使用できるようにするには、
pip install mock
を実行します。)
import sys
# configure unit testing for the case
# where the App Engine SDK is installed in
# /usr/local/google_appengine
sdk_path = '/usr/local/google_appengine'
sys.path.insert(0, sdk_path)
import dev_appserver
dev_appserver.fix_sys_path()
import mock
import unittest
import webapp2
from google.appengine.ext import testbed
import thecron
class CronTestCase(unittest.TestCase):
def setUp(self):
self.testbed = testbed.Testbed()
self.testbed.activate()
self.testbed.init_user_stub()
def _aux(self, is_admin):
self.testbed.setup_env(
USER_EMAIL = 'test@example.com',
USER_ID = '123',
USER_IS_ADMIN = str(int(bool(is_admin))),
overwrite = True)
request = webapp2.Request.blank('/crontask/test')
with mock.patch.object(thecron.time,
'time', return_value=12345678):
response = request.get_response(thecron.app)
return response
def testAdminWorks(self):
response = self._aux(True)
self.assertEqual(response.status_int, 200)
self.assertEqual(response.body, 'Cron: 12345678')
if __name__ == '__main__':
unittest.main()
最初のテスト
testAdminWorks
は問題なく通過したため、2 つめのテストが追加されました。
def testNonAdminFails(self):
response = self._aux(False)
self.assertEqual(response.status_int, 401)
ところが、ステータスは想定された 401(forbidden)ではなく 200(success)となり、このテストは通過しませんでした。
ここでの問題はユニット テストが
app.yaml
まで遡っておらず、ユニット テストのスタブではなく、サービスを呼び出すアプリケーションの場合のように、完全なルーティングとログイン制限がテストの対象になっていないことでした。つまり、対象となっていたのはログイン制限が課されていない
thecron.py
の二次的なルーティングだったのです。そのため、
app.yaml
のルーティングのほか、MIME タイプやログインなどのその他諸々は、ユニット テストのスタブではなくサービスを呼び出すテストだけの対象となっていました。
そこで、管理者の権限をチェックするデコレータ
needs_admin
を
thecron.py
に追加しました。
def needs_admin(func):
def inner(self, *args, **kwargs):
if users.get_current_user():
if not users.is_current_user_admin():
webapp2.abort(401)
return func(self, *args, **kwargs)
return self.redirect(users.create_login_url(request.url))
return inner
さらに、これを
CronHandler.get
でデコレートしました。
class CronHandler(webapp2.RequestHandler):
@needs_admin
def get(self): # etc, as before
これで cron サービスのスタブを呼び出すローカルのユニット テストは機能しますが、実際の App Engine Cron Service の機能を使ったエンドツーエンドのテストはステータス 401で失敗となります。なぜでしょうか。
簡単に言うと、App Engine Cron Service は指定された URL にアクセスするどのユーザーもログインさせません。そのため、ハンドラでは
users.get_current_user()
から
None
が返されます。
これを解消するのは、特別なリクエスト ヘッダ
X-AppEngine-Cron: true
の設定です。App Engine では外部リクエストで設定されたヘッダが除外されるため、このヘッダはアプリケーション コードが完全に信頼できるヘッダとなります。
つまり、ユニット テスト、エンドツーエンド テスト、ローカル開発のアプリケーション、デプロイされたアプリケーションを機能させるために必要だったのは、デコレータ
needs_admin
のわずかな修正だけだったのです。
def needs_admin(func):
def inner(self, *args, **kwargs):
if self.request.headers.get('X-AppEngine-Cron') == 'true':
return func(self, *args, **kwargs)
if users.get_current_user():
if not users.is_current_user_admin():
webapp2.abort(401)
return func(self, *args, **kwargs)
return self.redirect(users.create_login_url(request.url))
return inner
新しい
if
の記述はモック化されているかどうかにかかわらず、cron ジョブを処理します。2 つめの
if
の記述は、これまで通り管理者以外の(またはログインしていない)ユーザーを確実にブロックします。
コードの品質はユニット テストに時間と注意を注ぐことで継続的に維持できます。こうしたテストの作成と実行は、App Engine の
Local Unit Testing ツール
のほか、NoseGAE といったオープンソースのアドオンを活用することによって単純化することが可能です。
- Posted By Alex Martelli, Cloud Technical Support
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