Google Cloud Platform Japan Blog
最新情報や使い方、チュートリアル、国内外の事例やイベントについてお伝えします。
4月20日 Google for Mobile｜Game Bootcamp 開催
2016年4月12日火曜日
Google for Mobile は、Google が主催するモバイル サービス コンテンツ提供事業者の皆様をサポートするためのイベントです。今回のイベントでは、ゲーム デベロッパーの皆様を対象に、先日サンフランシスコで行われた GDC (Game Developers Conference) 内で Google からの発表内容を改めて説明させていただくと共に、Google Cloud Platform、Google AdWords、AdMob、Google Play のそれぞれの製品からゲームビジネスを更に発展させていただくために役立つ実践的ノウハウを共有させていただきます。
また Google Cloud Platform トラックでは、3 月 23 日（水）にサンフランシスコで開催された GCP NEXT 2016 で発表された最新情報はもちろん、日本ならではの内容も事例を交えながらご紹介いたします。
是非お申し合わせの上、ご参加ください。
＜イベント概要＞
日程
2016 年 4 月 20 日（水）
スケジュール
9:30: 受付開始
10:00 - 11:30: 基調講演
11:50 - 13:00: ライトニングトーク
14:00 - 18:00: ブレイクアウトセッション (Google Cloud Platform トラック と Google Play/Google AdWords/AdMob トラック の 2 トラック)
2 トラックの中から、お好きなセッションにご参加いただけます。
18:00 - 19:30: ハッピーアワー
会場
六本木アカデミーヒルズ
住所:〒106-6149 東京都港区六本木6丁目10番1号 六本木ヒルズ森タワー49F
アクセス:東京メトロ 日比谷線「六本木」駅1C出口より徒歩3分（コンコースにて直結）
イベントウェブサイト
Google for Mobile | Game Bootcamp ウェブサイト
※サイト内では完全招待制となっておりますが、一般のお客様へのお席もご用意がありますので、ぜひお申し込みください。
SRE の教訓 : App Engine で 1 日 1,000 億件以上のリクエストに対応する方法
2016年4月11日月曜日
* この投稿は米国時間 4 月 6 日、Google Cloud Platform の Managing Editor である Jo Maitland によって投稿されたもの（
投稿はこちら
）の抄訳です。
今回は、3 年半にわたって Google App Engine のサイト信頼性エンジニアを務め、Google でのサイト信頼性エンジニア経験が 9 年近くに及ぶ Chris Jones に、Google の本番システムの運用についてインタビューした内容を紹介します。
Chris は、O'Reilly から最近発売されたばかりの書籍『
Site Reliability Engineering : How Google Runs Production Systems
』の著者の 1 人でもあります。
Google App Engine
は 1 日あたり 1,000 億件以上のリクエストに対応しています。そしてそれがサイト信頼性エンジニアのおかげであることを、すでに皆さんはご存じかもしれません。
ちょっと驚異的にも思えますが、こうした稼働規模にはコンピュータ科学および工学の原理を応用したコンピューティング システムの設計と開発が大きくかかわっています。それらは通常、非常に大規模で分散されたシステムであることから、運用が重要な意味を持っています。
サイト信頼性エンジニアリング（SRE : Site Reliability Engineering）は、私たち誰もが本番システムを適切に運用することを可能にする一連の工学的な技術アプローチです。広範な IT コミュニティに普及している DevOps の考え方にも影響を与えました。
SRE の興味深いところは、地球規模のシステムのパフォーマンスと信頼性を向上させる比較的シンプルな方法でありながら、どのような企業でも、たとえば Windows デスクトップを展開する場合などにも同様に役立つことです。SRE のテクニックを適切に使用すれば、あらゆるコンピューティング サービスの運用効果を高めることができます。
Q :
App Engine は、何人のサイト信頼性エンジニアがどのような規模で運用しているのですか？
Chris Jones（以下、CJ）:
App Engine では数百万のアプリケーションが使用されていて、1 日に 1,000 億件以上のリクエストに対応しています。そしてそれを数十人のサイト信頼性エンジニアでサポートしています。
Q :
そんなに少ない人数で、どうやってこなしているのですか？
CJ :
SRE は、大規模分散コンピューティング サービスを運用するための工学的アプローチです。そこで重要なのは、システムを高度に標準化することです。つまり、すべてのシステムがどれも同じように動作するようにします。そうすれば、運用に必要な人数は少なくなります。理解し、対処すべき複雑さが軽減されるからです。
自動化も重要です。App Engine では、キャパシティの追加やロード バランシングのためのリソース拡張プロセスが自動化されています。多くの人によってではなく、コンピュータによってこのプロセスをうまくスケーリングできるようにするためです。退屈な反復的プロセスを人手で行うと、徐々にエラーが増えてしまいます。
また、コンピュータは障害が発生したときも、人間よりずっと迅速に対処します。私たちがエラーに気づくまでの間に、コンピュータはもうトラフィックを別のデータセンターに移動して、サービスの稼働を維持します。人間は人間が得意なことを、コンピュータはコンピュータが得意なことを担当するようにするのが望ましいのです。
Q :
SRE モデルのアプローチには、他にどのようなものがありますか？
CJ :
Google の各サービスの SRE チームは、他の多くのサービスの SRE チームと協力し合っています。そのため、私たちはプロダクトの垣根を越えて標準化の原理を適用していくことができます。
たとえば、もともと Gmail の新バージョンをデプロイするためにサイト信頼性エンジニアが作成したツールが、もっと多くの状況をカバーするように汎用化されるかもしれません。そうなれば、各チームは更新プログラムをデプロイする手段を自前で用意せずに済みます。すべてのプロダクトが、そのツールに加えられた改良の恩恵を受けることができ、全社レベルでツール環境が向上することになります。
さらに、SRE においてソフトウェア エンジニアリングとシステム エンジニアリングの知識を融合することで、両者のいいとこ取りのソリューションが生まれることがよくあります。Google のソフトウェア ネットワーク ロード バランサである
Maglev
はその一例です。これは
Google Cloud Load Balancer
を支えている技術です。
Q :
そうしたアプローチは App Engine と、App Engine を使用するお客様にどのように影響しますか？
CJ :
それがよくわかる事例があります。私たちは 2013 年夏に、App Engine の US リージョンで使用されていたアプリケーションとデータ全体を、米国内を横断するような形で移動させました。その際、ダウンタイムは発生しませんでした。
Q :
どのように行ったのですか？
CJ :
私たちはまず、ある App Engine クラスタをシャットダウンしました。設計どおり、その上で稼働していたアプリケーションは、残っていたクラスタに自動的に移動しました。
さらに、US リージョンの
High Replication Datastore
のコピーを移動先データセンターに作成しました。これらのアプリケーションのデータ（ペタバイト規模の量でした）をあらかじめ用意しておくためです。それ以降に Datastore に加えられた変更は、自動的にほぼリアルタイムで複製され、この移動先データセンターのデータは最新に保たれました。
App Engine を新しい場所で立ち上げる段になると、そのクラスタに割り当てられているアプリケーションがバックアップ クラスタから自動的に移行してきて、すでに用意されていたデータがすべて利用可能になりました。私たちは残りのクラスタについて、移動が完了するまでこのプロセスを繰り返しました。
入念に準備し、幅広いテストを行うとともに、緊急時対応計画も策定しておくことで、
少し問題が生じたとき
でも、私たちは対応できる態勢が整っていて、お客様への影響を最小限に抑えることができました。
そしてもちろん、私たちはチーム内で事後検証を行いました（これも SRE の重要な要素です）。犯人探しをするのではなく、問題の原因を究明し、将来のために、それを修正する方法を見いだすためです。
Q :
素晴らしいですね。SRE についてもっと知るためには、どうすればよいですか？
CJ :
SRE が Google でどのように実践されているか、その過程で私たちがどのような教訓を学んだかについて詳しく知りたい方は、こちらの
ウェブ サイト
や
新刊書
をチェックしてみてください。また、私たちは先ごろ（4 月 7 ～ 8 日）、
SREcon
において、このトピックに関していろいろと話をしたところです。
- Posted by Jo Maitland, Managing Editor, Google Cloud Platform
HIPAA 準拠のモバイル BaaS を共同で構築した Kinvey と Google
2016年4月8日金曜日
* この投稿は米国時間 4 月 4 日、Kinvey の Founder/CEO である Sravish Sridhar によって投稿されたもの（
投稿はこちら
）の抄訳です。
ここに投稿されるゲスト ブログは、
Google Cloud Platform
によるアプリケーションの構築や運用で実践的なノウハウを有するサードパーティのデベロッパー、パートナー、専門家の方々によって書かれています。クラウド コンピューティングのソフトウェア エンジニアリングやビジネス開発の最前線に立つ人々の考え方や意見に触れるのにうってつけです。
今回のゲスト ブログは、モバイル BaaS（Backend-as-a-Service）プロバイダーである
Kinvey
の創業者で、CEO を務める Sravish Sridhar 氏です。
レガシー エンタープライズ アプリケーションをモダナイズし、モバイル デバイスで使えるようにするのは容易なことではありません。モバイル環境でもこうしたアプリケーションを厳しい政府規制に確実に対応させるとなると、一筋縄ではいかないのです。
私たち Kinvey は
Google と協力
し、このプロセスを単純化しました。医療機関や製薬会社に勤務する、あるいはライフ サイエンスに携わる開発者向けに、私たちはモバイル BaaS を展開しています。
Kinvey のモバイル BaaS は、
Google クラウド
上に構築された HIPAA 準拠のフルマネージド プラットフォームを提供するサービスです。このサービスは、米国政府の HIPAA 規制で定められた厳格な患者プライバシー ポリシーを満たしています。
Kinvey は、フロントエンドとバックエンドを分離したアーキテクチャを GCP 上で提供しています。これは、フロントエンド開発者が、バックエンド システムのオーナーによる企業データや認証システムへのコネクタのプロビジョニングを待つことなく、アプリケーションを繰り返し開発し、機動的に提供できるようにするためです。
その仕組みは次のとおりです。
開発者は、Android、Objective-C、Swift、Ionic、Xamarin、PhoneGap などから選択したフロントエンド プログラミング言語やフレームワークを使って、アプリケーションの UI/UX 開発を始めます。
開発者は、自分の使用言語の Kinvey SDK をダウンロードし、適切に使ってクライアント側機能を用意します。用意される機能には、認証トークンの管理と匿名化、アプリと Kinvey のバックエンド API の間におけるデータのマーシャリング、オフライン キャッシングおよび同期、データの暗号化などが含まれます。
Kinvey のバックエンド機能
を利用して、アプリがバックエンドに接続されます。利用される機能は、ユーザーの登録 / ログインのためのアイデンティティ サービス、クラウドでデータを保存して取り出すためのデータ ストア、写真や動画のような大きなファイルをキャッシュするためのファイル ストア、Kinvey の Node.js PaaS で記述やプロビジョニングが可能なカスタム ビジネス ロジックなどです。
一方、バックエンド エンタープライズ システムのオーナーは、コードを記述することなく、Kinvey を社内認証システムおよびデータ ソースに接続できます。Kinvey の
Mobile Identity Connect
（MIC）を使って Active Directory や OpenID、LDAP、SAML などの認証プロトコルに接続したら、Kinvey の
RAPID データ コネクタ
およびカスタム データ リンクを使って Epic や Cerner、SAP、SharePoint のような社内データ サービスに接続します。MIC や RAPID を使ってプロビジョニングされたサービスは、Kinvey の Service Catalog で適切なアクセス ポリシーとともに発行することで、フロントエンド開発者が利用できるようになります。
フロントエンド開発者は “スイッチを入れる” ことで、Kinvey のデフォルト認証サービスの代わりに MIC 認証サービスを使用することや、Kinvey のデータ ストア内のサンプル データ集の代わりに 1 つまたは複数の RAPID サービスを使用することを、Kinvey に対して指示できます。
上記により、フロントエンド アプリのコードに変更を加えることなく、アプリが社内認証およびデータ システムと完全に連携するようになります。
Kinvey では、Epic や Cerner のような電子医療記録（EHR）システムへのコネクタを提供することで、開発者が複雑なエンタープライズ統合に労力をかけることなく、アプリを簡単にリリースできるようにしています。
医療機関のお客様は、患者データの包括的な安全性を確保するために、HIPAA に準拠したソリューションを求めています。そうしたことから Kinvey では、GCP の
インフラストラクチャ
に含まれる
Cloud Storage
と
CDN
の下で、安全性が高く、かつ法令を遵守した方法でデータやファイルの保存と提供を行えるようにしています。
Kinvey のモバイル BaaS は、具体的には GCP 上で下記のような機能を提供します。
オフライン キャッシング、ネットワーク管理、開発を迅速化する RESTful データ アクセスのためのプラグイン クライアント機能
新しいモバイル ユースケースに対応した形でデータ統合や IAM、オーケストレーションを実現するターンキー バックエンド サービス
エンタープライズ システムの相互接続を可能にするマイクロサービス
モバイル クライアントからインフラストラクチャ層に至るすべてのレベルでのセキュリティ
運用の調整に向けたモバイル アプリの分析とレポーティング
HIPAA が適用されるエンタープライズ アプリケーションのモバイル化に取り組もうという方は、
Kinvey の HIPAA 準拠モビリティ プラットフォーム
にぜひサインアップしてみてください。
- Posted by Sravish Sridhar, Founder/CEO, Kinvey
株式会社エニタイムズの導入事例：エンジニアがサービス開発に専念できる環境を求め、煩雑化していたシステムをGoogle Cloud Platform で完全リニューアル!
2016年4月8日金曜日
IT 技術を駆使した現代のまち作りサポートを目的に 2013 年に起業したスタートアップ、株式会社エニタイムズが、今後の更なる飛躍を見据え、サービス ＆ アプリを Google Cloud Platform でゼロから作り直すという大英断を行いました。それによって同社が抱えていた課題がどのように解決されたのでしょうか。
■ 写真左から
株式会社エニタイムズ
エンジニア 叶力華さん
代表取締役社長 角田千佳さん
■ 利用中の Google Cloud Platform サービス
Google App Engine
、
Google Cloud SQL
、
Google Cloud Storage
など
これからの時代の新しい地域コミュニティを作る手伝いをしたい。それが角田さんが株式会社エニタイムズを立ち上げた理由です。同社が提供する生活密着型の個人間のスキルシェアサービス「
ANYTIMES
」は、同じ地域で暮らす人同士が、空き時間とスキルをシェアすることで日常の“困った”を解消していくサービス。例えば部屋の掃除を任せたり、犬の散歩を代行してもらったり、あるいは何か自分の得意なことで誰かの力になってあげたりといったことができます（現在は iOS 向けアプリと Web アプリでそのマッチングを提供）。
「起業する前から、“まち作り”に携わる仕事がしたいと考えていました。現在の日本では、高齢世帯や共働き世帯の増加により、日常の手助け需要は増加しています。また一方で、正規雇用を一度離職をするとなかなか雇用機会を与えられないという事実があり、それが現在の非労働者・非正規雇用者人口の増加、また個々の能力の非活用にも繋がっています。
これもまた大きな社会問題になっていますよね。そう考えた時、この 2 つの状況を上手に組み合わせることで“問題”を解決できるプラットフォームを作れるのではないかと考えました」（株式会社エニタイムズ代表取締役社長・角田さん）
そうした志のもと、2013 年 5 月に株式会社エニタイムズを起業した角田さん。起業当初は外部のフリーランス エンジニアの力を借りる形でサービスを構築していったのですが、結果として、外注での開発体制で、それ以上のサービス拡大と継続的な改善が難しい状態と成りました。
そこで、昨年夏頃から社内開発に完全切り替え。9 月に入社した叶さんら社内チームで新たにサービスを再開発することに。プロモーションもいったん停止するなど、本格的な仕切り直しが始まりました。
「多くの課題がありましたが、まず解決したかったのがサーバー運用に多くの時間を奪われていたこと。従来利用していた大手クラウドプラットフォームは自由度が高い反面、インフラへの知識と経験が要求されたり、スケーリングが面倒などといった問題がありました。そこでチーム内で協議し、このタイミングでの Google Cloud Platform への移行を決定。結果的にこれが大英断でしたね。賢いオートスケーリングなどのおかげで、エンジニアがアプリ開発に集中できるようになりました」（同社エンジニア・叶さん）
実際、これまではサービスがテレビなどで紹介されるたびにエンジニアがサーバーに張り付き、準備をせねばならなかったそうです。「例えば夜中のビジネス番組に紹介されると、その直後からアクセス数が 10 ～ 20 倍になってしまうんです。それまではサービスが停止してしまわないようハラハラしながら寝ずにサーバーの番をせねばならなかったんですが、Google 移行後は完全にお任せに。安心してぐっすり眠れるようになりました（笑）」（叶さん）
ほか、Google Cloud Platform のメリットとして、導入が簡単なこと、Google ならではのインフラの信頼性、大幅なコスト減（なんと従来の 10 分の 1 程度に！）を挙げる叶さん。特にインフラの安定性や強固なセキュリティは 2 万人以上のユーザーを抱える ANYTIMES にとって心強いものだったそうです。
そして、昨年 10 月中旬から開始されたリニューアル作業はなんと年始にはほとんど終了。1 月には新アプリのリリースが、4 月には Web アプリも刷新されました。Google App Engine を駆使してバックヤードをシンプルに組み上げ、ユーザーとダイレクトに接することになるフロントエンドの開発に時間を割けたことも、目標のクオリティを短期間で達成できた秘訣だと言います。
「とは言え、現在はまだ道半ば。今後も、多くの機能追加を予定しています。その上で、今一番注目しているのが Google BigQuery。これを使ったユーザビリティ解析をやってみたいですね。パフォーマンスの良いユーザーを積極的に薦めていくという機能も実現したいと考えています。また、画像データの内容を分析してくれる Cloud Vision API にも興味があります。不適切な画像を排除するパトロール機能に使えるほか、投稿された写真が料理や美容など、どういったカテゴリーに属すかを判別できるようになることで、より効率的なマッチングができるのではないかと期待しているんですよ」（叶さん）
Google Cloud Platform を活用して、大規模リニューアルを順調に進めているエニタイムズ。5 月からは停止していたプロモーションも再開予定とのことです。
■ Google Cloud Platform のその他の
導入事例はこちら
から
Google Cloud Datastore API 新ベータでパフォーマンスが大幅アップ
2016年4月7日木曜日
* この投稿は米国時間 4 月 4 日、Google Cloud Platform の Product Manager である Dan McGrath によって投稿されたもの（
投稿はこちら
）の抄訳です。
このたび、私たち Google は NoSQL データベースの
Google Cloud Datastore
に関して、もう 1 つの重要な発表を行いました。
重要な発表とは、
Google App Engine
の外にある
Google Container Engine
や
Google Compute Engine
などから Datastore にアクセスするためのクロスプラットフォーム API について、それをサポートする基礎の部分のアーキテクチャを再設計したことです。これにより、Datastore のパフォーマンスと信頼性が飛躍的に向上しました。
“もう 1 つの発表”としたのは、先日、
Cloud Datastore の料金体系を刷新して単純化
することも発表したからです。今回の発表は、それに続くものです。
現在、
Cloud Datastore API
の新ベータ（v1beta3）が利用可能です。このベータ バージョンの API を使用するには、以前のバージョンの API を有効化してある場合でも、改めて新 API を有効化する必要があります（
Cloud Datastore API を有効化
）。
また、この API の
SLA
（Service Level Agreement）も作成しました。SLA は API の GA （General Availability）リリースに合わせて有効になる予定です。
v1beta3 のリリースとともに旧ベータ（v1beta2）は非推奨となり、6 か月の猶予期間を挟んで 2016 年 9 月 30 日に提供を終了します。
新ベータの改定内容
今回リリースしたベータ版の API では、パフォーマンスと信頼性を高めるという観点から、サービス パス全体を見直しています。
Cloud Datastore API の v1beta3 は、平均でも最悪のケースでも、従来と比べてレイテンシが低くなっています。プレイヤーの手元に魔法のアイテムが届く場合でも、ウェブサイトで財務レポートを見る場合でも、そのスピードが速ければ誰もがきっと喜ぶでしょう。
v1beta3 API では、パフォーマンスの大幅な向上に加えて、新しいプラットフォームがサポート対象に追加されています。今後は、この新プラットフォームも含めて、パフォーンマンスと機能を継続的に高めていくことになります。
v1beta3 API は、従来からお馴染みの
Google Cloud Client Libraries
（Node.js、Python、Java、Go、Ruby）だけでなく、JSON や Protocol Buffers 上の gRPC のための低水準ネイティブ クライアント ライブラリでも使えるようになります。こうしたクライアント ライブラリについては、
こちらのドキュメント
に詳しい説明があります。
Cloud Datastore の SLA
今回作成した
SLA
は GA リリース用なので、v1beta3 API を介した
Cloud Datastore
へのアクセスは同 SLA の対象にはなりませんが、この API のパフォーマンスがどの程度のものなのかは SLA から推計できます。SLA が有効になるのは API のGA リリース時です。
なお、
Cloud Datastore
に対する App Engine Client ライブラリは、まだ
App Engine SLA
の一部となっています。
Google Cloud Client Libraries を使用する場合、アップグレードは GitHub からクライアント ライブラリをアップデートするだけの単純な作業になります。
速くなった
Cloud Datastore
のクロスプラットフォーム API を皆さんがどのように使われるのか、私たち Google は楽しみにしています。
Cloud Datastore
の詳細は
スタート ガイド
を参照してください。
- Posted by Dan McGrath, Product Manager, Google Cloud Platform
フィンテック企業のロード テストで、Cloud Bigtable による株式イベント処理が 250 億件 / 時間を記録
2016年4月7日木曜日
* この投稿は米国時間 3 月 31 日、Google Cloud Bigtable 担当 Product Manager である Misha Brukman によって投稿されたもの（
投稿はこちら
）の抄訳です。
金融テクノロジーおよびサービスを手がける
FIS
は、
FinTech Top 100 ランキング
で上位に位置するグローバル企業です。そうした同社が先ごろ、
Google Cloud Platform
で構築したシステムのロード テストを行いました。
ロード テストの内容は、米国の株式取引市場で発生するイベントの処理、妥当性検証、およびリンクです。FIS は
Google Cloud Dataflow
と
Google Cloud Bigtable
を使用して、テスト対象の市場イベント 250 億件を 50 分間で処理し、素晴らしいパフォーマンスを記録しました。
対象のシステムは、3,500 の
Cloud Bigtable
サーバー ノードと、
Cloud Dataflow
を実行する 300 台の n1-standard-32 VM からなり、
Cloud Bigtable
におけるイベントの読み込み件数は最大で 1 秒あたり 3,400 万件を超え、書き込み件数は同 2,200 万件に達しました。
また、持続的な読み込み件数は 1 秒あたり 2,200 万件以上、持続的な書き込み件数は同 1,600 万件となりました。
Cloud Bigtable
はロード テストで高い I/O レートも達成しました。読み込み時のデータ転送速度は最大で 34 GB / 秒、書き込み時は同 18 GB / 秒で、30 分間の持続的な読み込みでも 22 GB / 秒、持続的な書き込みでも13 GB / 秒と高い数字を記録しています。
FIS にとってこうしたテスト結果は、米国市場における株式とオプションの 1 日分の取引データを、4 時間以内で分析用に処理できることを示しています。
テスト結果は
こちらのスライド
にまとめられています。
FIS
の Neil Palmer 氏と Todd Ricker 氏、および
Google Cloud Bigtable
のエンジニアリング マネジャーを務める Carter Page が行ったテスト結果のプレゼンテーションの模様を収めた下記の動画では、テストに使用されたシステムの全体的なアーキテクチャの詳しい解説がご覧になれます。
私たち Google は、FIS のような革新的企業と協力しながら、Cloud Bigtable が提供するパフォーマンスやスケーラビリティ、NoOps アプローチによってデータ処理の課題に対応していくことを楽しみにしています。
- Posted by Misha Brukman, Product Manager for Google Cloud Bigtable
Google Cloud Datastore の料金が大半のユースケースで大幅値下げへ
2016年4月6日水曜日
* この投稿は米国時間 3 月 31 日、Google Cloud Platform の Product Manager である Dan McGrath によって投稿されたもの（
投稿はこちら
）の抄訳です。
Google Cloud Datastore
は、ウェブやモバイル アプリケーションのためのスケーラブルな NoSQL データベースです。このデータベース サービスの料金体系について、私たち Google は先ごろ、より単純化することを発表しました。これにより、ユーザーの多くは大幅なコスト削減が期待できます。
料金体系の単純化に伴い、
Cloud Datastore
に格納されているデータの計算方法も透明性の高いものになります。こうした新しい料金体系とストレージ計算方法は、2016 年 7 月 1 日から適用される予定です。大多数のお客様にとって、これは実質的な値下げです。
新しい料金体系
Google は、皆さんからのフィードバックに応えて
料金体系
を単純化します。新しい料金体系は、
Cloud Datastore
とのアクセス方法に関係なく、2016 年 7 月 1 日から適用されます。今よりシンプルになるだけでなく、多くのお客様が大幅値下げの対象となるでしょう。
また、インデックスの最適化作業からデベロッパーを解放する強力なインデクシング機能に魅力を感じつつも、現在の料金体系を理由に
Cloud Datastore
の導入をためらっていたお客様にとっても、今回の変更は大きな障害が取り除かれることを意味します。
エンティティの書き込み、読み出し、および削除にかかる料金は、現状では内部オペレーションの数で決まります。これに対して新しい料金体系のもとでは、より直接的にエンティティの数から決まるようになります。具体的には次のとおりです。
書き込み
現状の料金体系では、インデックスの数とタイプに応じて、1 つのエンティティの書き込みが 1 以上の書き込みオペレーションとして計算されます。
一方、新しい料金体系のもとでは、インデックスがどのようなものであれ、1 つのエンティティの書き込みは 1 と数えられ、100,000 あたり 0.18 ドルとなります。アプリケーションのニーズに合わせてインデックスをいくつ付けても、書き込み料金は高くなりません。
現状では、大多数の Entity 書き込みはエンティティあたり 4 以上の書き込みオペレーションとして計算されます。そのため、新料金はデベロッパーにとって大幅なコスト削減につながります。
読み出し
現状では、クエリによってはエンティティの読み出しの 1 に対して、別途読み出しオペレーションの数が加算される場合があります。
これに対して新しい料金体系では、エンティティの読み出しに対してのみ課金されます。小規模なオペレーション（射影やキーのみのクエリ）については現状でもクエリあたり 1 と計算されているので、変更はありません。
Entity 読み出しオペレーションあたりの料金は据え置きで、100,000 あたり 0.06 ドルです。そのため、ほとんどのデベロッパーにはコスト削減となります。
削除
現状の料金体系では、インデックスの数とタイプにより、削除は 2 以上の書き込みとして計算されます。
一方、新しい料金体系のもとでは、削除されるエンティティごとに削除オペレーションの料金のみがかかり、100,000 あたり 0.02 ドルです。これにより、削除の料金は少なくとも 66 % 値下げとなり、多くの場合、値下げ率はもっと高くなります。
無料クォータ
1 回の書き込みが複数のオペレーションに換算されることはないので、書き込みの無料クォータ（無料利用枠）は現状でも 1 日あたり 20,000 リクエストです。
削除には独立の無料クォータが与えられ、現状で 1 日あたり 20,000 リクエストです。これは、大多数のアプリケーションでは 1 日あたりの無料リクエストが増えることを意味します。
ネットワーク
Standard Network 料金
が適用される予定です。
データ量の新しい計算方法
7 月 1 日には、料金体系の変更に合わせて格納データ サイズの計算方法も変更されます。新しい方法では Entity のプロパティ値とインデックスから直接ストレージ料金を計算できるので、デベロッパーにとっては透明性が高まります。これは、ストレージ コストを下げることにもつながります。
現状の計算方法は、変更可能な内部実装の詳細に大きく依存しています。これに対して新しい方法では、サブミットされたデータから直接計算できる固定料金体系になります。
Google では、デベロッパーがストレージ コストを推計できるようにするため、新しい計算方法の確定後に詳細を発表する予定です。
時間を有効活用
Cloud Datastore の料金体系が単純化されることにより、インデックスのマイクロマネジメントに費やす時間を減らし、そのぶんを次の開発に充てることができます。
Google Cloud Datastore の詳細
、もしくは
入門ガイド
をご覧ください。
- Posted by Dan McGrath, Product Manager, Google Cloud Platform
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
