こうした変更が可能になったのは、データセンター インフラストラクチャの分野における Google のたゆまぬイノベーション（この場合はネットワーキング）が理由です。Google では、ハイパフォーマンスでグローバルなストレージ ファブリックである Colossus と組み合わせることで、パフォーマンスと信頼性を損なうことなく 1 つのインスタンスにアタッチできるネットワーク ストレージのサイズとボリュームを拡張し、柔軟性を高めてきました。

このことは、Google Cloud Platform の重要な長所の 1 つ、すなわち Linux コンテナのホスティングと密接に結びついています。

私たち Google は、Linux コンテナの上で蓄積してきた 10 年超の経験を基に、Docker ベースのワークロードの実行において GCP が最高のプラットフォームになるように力を注いできました。

私たちの場合と同じメリットを皆さんにも理解していただくため、私たちは Docker コンテナ クラスタの作成や管理ツールとして Kubernetes を作り、オープンソース化しました。そして、Docker アプリケーション向けにマネージドでホステッドな Kubernetes ベースのサービスを提供する Google Container Engine を立ち上げました。

Red Hat は、こうした Kubernetes の大口のユーザーです。同社は、製品ポートフォリオ全体を通じて Kubernetes を採用するとともに、Kubernetes を PaaS 製品である OpenShift のコア コンポーネントに位置づけています。


Google では昨年末、OpenShift Dedicated を GCP 上で提供するための準備作業を Red Hat と共同で行いましたが、その際、1 つのインスタンスにアタッチされる永続ディスク ボリュームの数を増やす必要があることが明らかになりました。

Red Hat が Kubernetes Pods（個々の Pods は 1 つ以上のボリュームをアタッチできます）を GCP インフラストラクチャ全体を通じて効率良くビンパックするのを手助けするためです。


1 つのインスタンスにアタッチできる永続ディスク ボリュームが増えることを歓迎しているのは Red Hat だけではありません。Kubernetes と Docker のサポート強化に加え、大量のディスクを必要とするさまざまなシナリオにおいても、今回の拡張は役に立ちます。

たとえば、1 つのインスタンスで複数のウェブ サーバーを実行している場合は、データの隔離に保険をかけるため、ウェブ サーバーごとにデータを個別のボリュームに保持できます。

Google Compute Engine で実行中の Kubernetes クラスタで今回の拡張の恩恵にあずかりたい場合は、そのクラスタのノードで使えるようにしたいボリューム数の上限に基づいて、その数を環境変数 KUBE_MAX_PD_VOLS に設定するだけです。


- Posted by Martin Buhr, Product Manager
ラベル:




詳細は、このデザインによるソリューションの説明を参照してください。お役に立てることを願っています。また、皆さんからのフィードバックも歓迎します。ここにコメントを残すか、Twitter の @petermark にメッセージをお送りください。


- Posted by Peter-Mark Verwoerd, Cloud Solutions Architect
ラベル:



もちろん、HTTP（S）、TCP、UDP の各ロード バランサの構成には固有の違いが細部にありますが、新 UI ではこれらすべてのロード バランサを全体的に同様の手順で構成できるようになっています。

構成の最初のステップは、ロード バランシングを適用したいトラフィックのプロトコルを HTTP（S）、TCP、UDP の中から選択することです。なお、SSL（TLS） については、ロード バランシングの対象として SSL（TLS） をサポートする機能がベータ段階に移行した時点で、新 UI に追加される予定です。

下の画面は、プロトコルを選択しやすくするために用意されている一覧ページです。



ここでは例として、HTTP ロード バランサの構成を設定してみましょう。

まず、“HTTP(S) Load Balancing” の下の “Start configuration” ボタンをクリックします。すると、ロード バランサの名前、バックエンド構成、ホスト / パス ルール、フロントエンド構成の設定ページが表示されます。ホスト / パス ルールは、クライアントのリクエスト URL に基づいてリクエスト ルーティングを実行したい場合に設定する項目です。



これらの項目を設定したら、構成を確認したうえで確定します。構成を設定したロード バランサは次のように一覧表示されます。



構成したロード バランサのいずれかについて追加情報を確認したい場合は、次のようにドロップダウン カードを使えば、構成および監視情報を詳しく見ることができます。



ロード バランサの構成は、いつでも上の画面の “Edit” ボタンをクリックすることで編集できます。

Cloud Load Balancing を使い始める際の手助けとなるように、私たちは新 UI のクイックスタート動画を作成しました。この動画を見てから新 UI に触れ、HTTP（S）、TCP、UDP ロードバランサの構成や編集を行い、UI の流れや構成オプションを理解することをお勧めします。

また、下の画面の “Send feedback” ボタンをクリックすれば、フィードバックを送信することもできます。



今回は、Google Cloud Load Balancing に導入された新 UI の最初のリリースを紹介しました。Google は今後も開発を継続し、改良を進め、そして何よりも重要な皆さんのフィードバックを活かすことで、この UI を将来にわたってリリースしていきます。

ぜひ新しい UI を試していただき、何がうまくいっているか、次のリリースでどんな機能が欲しいかをお知らせください。

2016 年 3 月開催の GCP NEXT に参加された方は、Google Cloud Load Balancing を支える Google のグローバル ネットワークと、ソフトウェアで定義された分散システム技術について知る機会を楽しまれたことと思います。

一方、参加されなかった方は、GCP NEXT での Global Load Balancing に関する講演の動画や、同じく 2016 年 3 月開催の NSDI で Google が行った TCP / UDP ネットワーク ロード バランシングに関する講演のスライドを公開中ですので、ぜひご覧ください。

適切なロード バランシングでハッピーに！


- Posted by Prajakta Joshi, Product Manager, Google Cloud Platform 

$ mvn gcloud:deploy
次に、一定の間隔（下記の例では 30 分）でサーブレットの URL を呼び出すように、App Engine Cron Service を構成する cron.yaml ファイルを app.yaml と同じところに作ります。
cron:
 - description: Cron job to schedule Dataflow pipeline
   url: /dataflow/schedule
   schedule: every 30 mins
   login: admin

最後に、gcloud を使って App Engine に cron ジョブをデプロイする必要があります。

$ gcloud preview app deploy cron.yaml 
Beginning deployment...
Updating config [cron]...done.

以上で完了です。cron ジョブは、Cloud Platform Console で App Engine -> Task Queues -> Cron Jobs を選択すると確認できます。



同様に、Dataflow Monitoring Interface をチェックすれば、Dataflow パイプラインが実行されたことを確認できます。


Cloud Functions（実験的な方法）

Cloud Functions のアルファ テストに参加していただいている場合は、App Engine Cron Service とは別の興味深いアプローチを試すことができます。ただし、本番ジョブでこの方法に頼るのは、まだお勧めできません。

Cloud Functions のもとでは、クラウド環境でイベントが発生したときに実行される Node.js を書くことができます。フルマネージドなので、関数を書いてデプロイすれば、インフラについて心配する必要はありません。この種の関数は、複数のトリガ（ Pub/Sub メッセージ、クラウド ストレージの変化、HTTP 呼び出し）に反応できるので、さまざまなシナリオで役に立ちます。

別のアプローチというのは、任意の Cloud Functions トリガ（ Pub/Sub、クラウド ストレージ、HTTP ）によって Dataflow パイプラインが起動されるように Cloud Functions を書くというものです。そのためには、やるべきことがいくつかあります。

第 1 に、Dataflow パイプラインは通常 Java で Dataflow SDK を使って書かれるので、Node.js が呼び出せる実行可能 JAR を作る必要があります。このサンプルでは、Dataflow に付属している WordCount.java を使います。このサンプルから JAR を作る方法はたくさんあります。たとえば Eclipse ユーザーなら、ファイルを右クリックして実行可能 JAR をエクスポートできます。

第 2 に、Cloud Functions のために Node.js モジュールを作る必要があります。

module.exports = {
  wordcount: function(context, data) {
    context.success(“Success”);
  }
}


そして、この Node.js モジュールから実行可能 JAR を呼び出すための手段が必要です。これは、Node.js の spawn で作ることができます。spawn を追加したモジュールは次のとおりです。

module.exports = {
  wordcount: function(context, data) {
    const spawn = require('child_process').spawn;
    const child = spawn(
            'jre1.8.0_77/bin/java',
            ['-cp',
             'WordCount.jar',
             'com.google.cloud.dataflow.WordCount',
         '--jobName=FromACloudFunction',
         '--project=[YOUR_PROJECT_ID], 
         '--runner=BlockingDataflowPipelineRunner',
         '--stagingLocation=gs://[YOUR_BUCKET]/staging',
         '--output=gs://[YOUR_BUCKET]/output'
            ],
            { cwd: __dirname });

    child.stdout.on('data', function(data) {
        console.log('stdout: ' + data);
      context.success("Success: " + data);      
    });

    child.stderr.on('data', function(data) {
        console.error('error: ' + data);
        context.failure("Error: " + data);
    });

    child.on('close', function(code) {
        console.log('closing code: ' + code);
    });
  }
}
Node.js の spawn コマンドが JAR の実行のためにローカル Java ランタイム フォルダを使用することに注意してください。Cloud Functions は Google Compute Engine VM の上で動作しますが、これらの VM には Java がインストールされていないので、Cloud Functions コードのほかに独自の Java ランタイム フォルダを提供しなければなりません。そうした理由から、ローカル Java ランタイム フォルダが使われるのです。

最後に Cloud Functions をデプロイします。Node.js モジュールは必ず index.js という名前にし、依存する Java ファイル（ WordCount.jar と jre1.8.0_77 ）をすべて同じフォルダに格納してください。

デプロイ中、Cloud Functions がローカル データを格納するためのバケット名を指定する必要があります。また、Cloud Functions が使えるトリガも指定しなければなりません。このサンプルでは単純に HTTP トリガを使うことにします。

$ gcloud alpha functions deploy wordcount --bucket [BUCKET_NAME] --trigger-http

次のようにすれば、デプロイした Cloud Functions をチェックできます。

$ gcloud alpha functions list

最後になりますが、単純な HTTP リクエストを用意します。

$ curl -X POST https://[REGION].[PROJECT_ID].cloudfunctions.net/wordcount --data

'{"message":"contents not matter in this example"}'

この HTTP リクエストが Cloud Functions を起動し、それが Dataflow パイプラインを起動します。Dataflow Monitoring Interface により、Dataflow パイプラインが本当に実行されていることを確認できます。


Pub/Sub トピックから起動される Cloud Functions を作り、そのトピックにメッセージを送る任意のシステムが Dataflow パイプラインを起動できるようにすれば、より高度なメカニズムになります。

前述したとおり、Dataflow には組み込みのスケジューリング メカニズムはありませんが、App Engine Cron Service を使用すれば、わかりやすい形でパイプラインのスケジューリングが可能です。

一方、それでは物足りない場合は Cloud Functions を使用します。そうすれば、App Engine Cron Service よりも多くのトリガで柔軟にパイプラインをスケジューリングできます。


- Posted by Mete Atamel, Developer Advocate
Share on Twitter Share on Facebook



Google は 2015 年 7 月に OpenStack Foundation に参加し、OpenStack への Kubernetes の統合を発表しました。Google の Mitaka での取り組みは、OpenStack 環境をシームレスに補完するパブリック クラウドとして Google Cloud Platform を位置づけるというロードマップにおける次のステップです。


バックアップとリカバリ サービスは、大規模インフラストラクチャの管理において最もコストがかかる複雑なプロセスの部類に入ります。OpenStack の場合は、永続ブロック ストレージの効率的な割り当てと管理を行うメカニズムを Cinder によって提供しています。

OpenStack のデプロイでは、Cinder ボリュームには仮想マシンの保存中のデータが格納されるほか、OS の起動デバイスが格納される可能性もあります。本番デプロイでは、包括的なビジネス コンティニュイティおよびディザスタ リカバリ戦略の一環として、この永続データを保護することが重要です。

こうした要件を満たすため、Cinder はバックアップ サービスと共にバックアップ ドライバの仕様も提供しています。ストレージ ベンダーはこの仕様に基づいて Cinder 用ドライバを用意することで、自社のストレージを Cinder のバックアップ先としてサポートできます。


そこで私たち Google の出番です。高い耐久性と可用性を備えるクラウド スケールのオブジェクト ストレージが、サポートされるバックアップ先として加われば、企業はバックアップ先を大容量のコモディティ ストレージから、運用効率の高い経済的なアーキテクチャに移行できます。追加の設備投資は不要で、ストレージ デバイスのスケール アウトにかかわる複雑な管理に悩むこともありません。

ファイルまたはブロック ストレージにアクセスするように設計された既存のソフトウェアやシステムを、オブジェクト ストアのネイティブ REST インターフェースに対応させることは、エンジニアリング上の労力がかかるため、これまではオブジェクト ストレージを導入するうえで障害となってきました。

Cinder のバックアップ ドライバ モデルは、OpenStack ユーザーにとってのこうしたエンジニアリングの複雑さを抽象化してくれる可能性があります。適切なバックアップ ドライバがインストールされていれば、バックアップ先のストレージは想定どおりに Cinder と連携して機能します。


Google の OpenStack Cinder バックアップ ドライバは、Mitaka で提供される Cinder の標準バックアップ ドライバ セットの一部として含まれており、最小限のセットアップで動作します。1 GB、5 GB、10 GB の Cinder ボリューム サイズで、Cloud Storage 用ドライバによる Cinder のフルバックアップ機能の検証に成功しています。

また、このドライバは、管理者側でインストールを調整できるようにするため、ユーザーが構成可能な下記のパラメータを提供します。
パラメータ
目的
backup_gcs_credential_file
Google サービス アカウントの JSON ファイル（ステップ 3 で Google Developer Console からダウンロードされる）のフルパス。
backup_gcs_bucket
バックアップに使用する GCS バケット名。バケットの命名に関するオフィシャル ガイドラインを参照してください。
backup_gcs_driver
Google バックアップ ドライバを選択するために使用されます。
backup_gcs_project_id
バックアップ バケットが作成されるプロジェクト ID。
backup_gcs_object_size
GCS バックアップ オブジェクトのバイト数。

デフォルト : 52428800 バイト
backup_gcs_block_size
増分バックアップのための変更トラッキング サイズ（バイト）。

backup_gcs_object_size は、backup_gcs_block_size の倍数でなければなりません。

デフォルト : 327678 バイト
backup_gcs_user_agent
gcs API の HTTP ユーザーエージェント文字列。
backup_gcs_reader_chunk_size
GCS オブジェクト ダウンロードのチャンク サイズ（バイト）。

デフォルト : 2097152 バイト
backup_gcs_writer_chunk_size
GCS オブジェクト アップロードのチャンク サイズ（バイト）。-1 の値を渡すと、ファイルが単一のチャンクとしてアップロードされます。

デフォルト : 2097152 バイト
backup_gcs_num_retries
転送のリトライ回数。

デフォルト : 3
backup_gcs_bucket_location
GCS バケットの場所。

デフォルト : ‘US’
backup_gcs_storage_class
GCS バケットのストレージ クラス。

デフォルト : ‘NEARLINE’
backup_gcs_retry_error_codes
リトライを開始するための GCS エラー コードのリスト。

デフォルト : [‘429’]
backup_gcs_enable_progress_timer
GCS バックエンド ストレージにボリュームをバックアップするときに、Ceilometer （OpenStack のテレメトリ サービス）に進行状況の通知を定期的に送信するためのタイマを有効または無効にします。デフォルト値は True（有効）です。

デフォルト : True

Cinder バックアップ ドライバは、アーカイブ オプションである Google Cloud Storage Nearline を含めてあらゆるクラスの Cloud Storage に対応しています。


Nearline は Standard Storage と同等の高い耐久性を備え、可用性は若干低く、レイテンシは若干高くなっています。その読み込み性能は、格納されているデータ 1 TB あたり 4 MB / 秒で、データ量が多いほど高くなります。


たとえば、3 TB のバックアップ データは 12 MB / 秒でリストアできます。低コストながら高いパフォーマンスを提供する Nearline により、Cinder ボリュームを経済的にバックアップでき、必要に応じて高速にリストアできます。


OpenStack をお使いなら、バックアップとリカバリのためにストレージ システムに追加投資したり、セカンダリ データセンターを構築したりする必要はありません。Mitaka で提供される Cinder バックアップ ドライバにより、Cloud Storage はバックアップとリカバリの最適な選択肢となっています。


- Posted by Ben Chong, Product Manager and Mark Lambert, Program Manager, Google Cloud Platform
Share on Twitter Share on Facebook
ラベル:



今回は、アプリケーションで頻繁に起きるエラーや新規のエラーを早期に見つけ出すのに役立つ Stackdriver Error Reporting を紹介します。

Stackdriver Error Reporting は、実行中のクラウド サービスで発生したクラッシュをリアルタイムでカウントして、分析および集計を行い、何か新しいことが起きるたびに通知します。

発生回数順にソートされたエラーの一覧


Stackdriver Error Reporting は、アプリケーションのエラーを監視し、プログラミング言語とフレームワークに合った適切なグループに分類して集計します。そのため、これを使用するとノイズに邪魔されることが減り、エラーに気づきやすくなります。

特定のサービスで最近起きたエラーを監視したり、機能停止がユーザーに及ぼした影響を判断したりすることもあるでしょう。その場合は、最初 / 最後の検出日、発生回数、影響を受けたユーザー数でソートすれば、求める情報が得られます。

過去に発生したエラーの分類に当てはまらない新しいエラーをメールで通知


過去に発生したエラーの分類に当てはまらない新しいエラーが発生したときは、メールで担当者に通知し、そのメールから新エラーの詳細に直接ジャンプできます。

“detail view” には、エラーの発生回数を時系列的に示す棒グラフと、最初 / 最後の発生日時、影響を受けたサービス バージョンなどの重要なエラー情報が表示されるため、エラーの深刻度を評価したり、根本原因を究明したりするのに役立ちます。

関連部分に焦点を絞ったスタック トレースを検査し、Stackdriver Debugger でデバッグを開始すれば、エラーを発生させたリクエストの詳細を把握し、関連するログにたどり着くことができます。このようにしてエラー サンプルの全体を見られるので、問題を正しく診断するのに効果的です。

根本原因の究明に役立つエラーの詳細


さしあたって次に行うべきことはサービスのロールバックかもしれませんが、エラーのフィックスにも取りかかりたいところです。Stackdriver Error Reporting ではエラーから問題箇所にリンクを設定し、通常のワークフローにエラー フィックスを統合できます。これにより、エラーと対応する問題がひと目でわかるようになります。

お気に入りのバグ トラッカで問題箇所の URL にリンクを設定


Stackdriver Error Reporting は、アルファ テスターの方からとても高く評価されています。これまではログに埋もれて簡単にキャッチできなかった間欠的なエラーを捕捉できるようになり、それが製品の品質向上につながったという報告が多数寄せられています。お寄せいただいたフィードバックに感謝します。


さあ始めよう

Stackdriver Error Reporting は現在、誰もが試用できるベータの段階にあります。App Engine アプリケーションではセットアップ不要ですが、他のプラットフォームでは若干の構成作業が必要になります。

http://console.cloud.google.com/errors にアクセスし、プロジェクトを始めましょう。


- Posted by Steren Giannini, Product Manager, Google Cloud Platform
Share on Twitter Share on Facebook


また Google Cloud Platform トラックでは、3 月 23 日（水）にサンフランシスコで開催された GCP NEXT 2016 で発表された最新情報はもちろん、日本ならではの内容も事例を交えながらご紹介いたします。


是非お申し合わせの上、ご参加ください。

＜イベント概要＞
※サイト内では完全招待制となっておりますが、一般のお客様へのお席もご用意がありますので、ぜひお申し込みください。

Share on Twitter Share on Facebook
ラベル:


■ 写真左から
株式会社エニタイムズ

エンジニア 叶力華さん
代表取締役社長 角田千佳さん

■ 利用中の 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 のその他の導入事例はこちらから
Share on Twitter Share on Facebook
ラベル: , , ,




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
Share on Twitter Share on Facebook


金融テクノロジーおよびサービスを手がける 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
Share on Twitter Share on Facebook



データ量の新しい計算方法

7 月 1 日には、料金体系の変更に合わせて格納データ サイズの計算方法も変更されます。新しい方法では Entity のプロパティ値とインデックスから直接ストレージ料金を計算できるので、デベロッパーにとっては透明性が高まります。これは、ストレージ コストを下げることにもつながります。

現状の計算方法は、変更可能な内部実装の詳細に大きく依存しています。これに対して新しい方法では、サブミットされたデータから直接計算できる固定料金体系になります。

Google では、デベロッパーがストレージ コストを推計できるようにするため、新しい計算方法の確定後に詳細を発表する予定です。


時間を有効活用

Cloud Datastore の料金体系が単純化されることにより、インデックスのマイクロマネジメントに費やす時間を減らし、そのぶんを次の開発に充てることができます。

Google Cloud Datastore の詳細、もしくは入門ガイドをご覧ください。


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