Cloud Console

最後になりましたが、私たちは Cloud Console インターフェースにもさまざまな改良を加えました。まだ使用したことのない方は、コンソール内でのエンティティ編集に関する新しいドキュメントを読んでみてください。ここでは、ハイライトを 2 つ紹介します。
  • Entities ページの Key Filter フィールドで URL-Safe Keys がサポートされたことは、App Engine Python ユーザーにとって朗報でしょう。
  • エンティティ エディタは、Array や Embedded エンティティといった複雑なタイプのプロパティをサポートしています。


Cloud Datastore の詳細は Getting Started ガイドをご覧ください。


- Posted by Dan McGrath, Product Manager for Cloud Datastore


エンティティをクリックすると、分析は少し深くなり、同じタイプの “related“(関連する)エンティティのグラフが表示されます。この場合の “relatedness”(関連性)は Wikipedia コーパス全体で計算され、両方のエンティティが現れる記事の数を数えます。

消費財のエンティティの場合、こうした関連性から類似商品に関する知見が得られることがよくあります。その証拠として “Android” をクリックすると、次のグラフが表示されます。




これをどのようにして計算したのか、以下で見ていきましょう。

手品の種は前処理ステップにあります。このデモでは Wikipedia の記事を処理していますが、タイムスタンプ付きのニュース記事、顧客フィードバック、その他任意のコーパスの場合も、原則として同じ処理を実行できます。

データ分析の柔軟性をできる限り確保するため、私たちはすべての記事にエンティティ検出と感情分析を適用し、得られた構造を直接保存しています。Google Cloud Platform では、Cloud DataflowBigQuery を組み合わせることで、これをすっきりとしたプロセスにまとめています。

最初に、Wikipedia の XML dump に軽く前処理をかけ、XML をパースおよびマークダウンし、Wikipedia メタページをフィルタリングします。

     def parse_xml(xml):    
         page = etree.fromstring(xml)    
         children = dict((el.tag, el) for el in page)    
         if 'redirect' in children or \            
                 WIKIPEDIA_NAMESPACES.match(children['title'].text):        
             raise StopIteration()    
         revisions = (rev.text for rev in children['revision'].iter('text'))    
         yield {        
             'article_id': children['id'].text,        
             'article_title': children['title'].text,        
             'wikitext': revisions.next(),    
         }

     def parse_wikitext(content):
         text = content['wikitext']
         parsed_md = mwparserfromhell.parse(content['wikitext'])
         content['text'] = _strip_code(parsed_md)
         yield content

     p = apache_beam.Pipeline(argv=pipeline_args)
     value = p | apache_beam.Read('Read XML', 
     custom_sources.XmlFileSource('page', gcs_path))
     value = value | apache_beam.FlatMap('Parse XML and filter', parse_xml)
     value = value | apache_beam.Map('Wikitext to text', parse_wikitext)
     ... 

Cloud Dataflow は、このパイプラインを自動的に並列実行します。53 GB におよぶ未加工の XML を 500 万以下のテキストのみの記事に変換するには 1 時間ほどを要します。

次に、この記事群を Natural Language API に通します。そして、すべてのエンティティを出力し、記事の感情とその他のメタデータを結合して BigQuery に格納します。

     def analyze_entities(content):
         analysis = language.annotate_text(
             content['text'], extract_entities=True,
             extract_document_sentiment=True)

         sentiment = analysis.get('documentSentiment', {})
         for entity in analysis.get('entities', []):
             entity_dict = {
                 'article_id': content['article_id'],
                 ...            
                 'article_sentiment_polarity': sentiment.get('polarity'),
                 'entity_name': entity['name'],
             }
             yield entity_dict

     value = value | apache_beam.FlatMap('Entities', analyze_entities)
     value = value | apache_beam.Write(
         'Dump metadata to BigQuery', apache_beam.io.BigQuerySink(
             destination_table,
             schema=', '.join([
                'article_id:STRING',            
                 ...
                'article_sentiment_polarity:FLOAT',
                'entity_name:STRING',
            ]),
            ...))) 
以上で、構造化されていないテキストから構造化データを作ることができました。


BigQuery で得られる知見

定義された構造をテキスト ブロップが持つようになれば、BigQuery などのツールを適用できます。それまで不透明なテキスト ブロッブだったものにクエリを発行し、今まで決して手に入らなかったような知見を得られるかもしれないのです。こうしたことは、特に手作業での処理が困難な巨大なデータセットの場合にはとても考えられませんでした。

このデータでできることを少しだけ見てみましょう。下記の単純なクエリを実行すると、Wikipedia で最も言及されているエンティティを記事数順に 5 個抽出できます。

      SELECT top(entity_name, 5) as entity_name, count(*) as num_articles
      FROM [nl-wikipedia:nl_wikipedia.nl_wikipedia];
順位entity_name(エンティティ名)num_articles(記事数)
1United States653420
2English591128
3American562490
4British336654
5London325461
もっとも、英語版の Wikipedia が英語に関連するエンティティを頻繁に取り上げるのは、ごく自然なことです。私たちが興味をそそられるのは、こうした国民国家のことよりも、たとえば消費財のことではないでしょうか。であれば、次のようなクエリを送りましょう。
     SELECT top(entity_name, 5) as entity_name, count(*) as num_articles 
     FROM [nl-wikipedia:nl_wikipedia.nl_wikipedia]
     where entity_type = 'CONSUMER_GOOD';
順位entity_name(エンティティ名)num_articles(記事数)
1Windows14610
2iTunes13281
3Android6020
4Microsoft Windows5754
5PlayStation 25301
この結果からは、Wikipedia の住人がどんな製品について執筆しているのかがわかります。ただし、製品に触れている記事の数だけでは、その製品がどのように見られているかはわかりません。幸いなことに、私たちの前処理パイプラインは記事から感情も抽出しています。それを使って、私たちのコーパスにおいて、どの製品が最も好意的に描かれているかを調べましょう。
          SELECT entity_name, sum(article_sentiment_polarity) as sentiment
     FROM [nl-wikipedia:nl_wikipedia.nl_wikipedia]
     where entity_type='CONSUMER_GOOD'
     and entity_salience > .5
     group by entity_name
     order by sentiment desc 
     limit 5


順位 entity_name(エンティティ名) sentiment(感情)
1NASCAR1.8
2SRX1.5
3Sugar1.2
4Formula One1.1
5iPod Touch1.1
注意 : 上のクエリには entity_salience、すなわちエンティティが記事内でどれくらい重要かを示す値(0 ~ 1)によるフィルタも含まれています。つまり、エンティティが何かのついでに触れられているだけなら、記事全体の感情はエンティティを反映したものにはならないということです。

与えられた消費財と関連性の深いエンティティを見つけるため、前述のデモ アプリに含まれている関連エンティティ クエリ(related-entities query)を実行することも可能です。

           select top(entity_name, 5) as entity_name, count(*) as num_articles
​     from [nl_wikipedia.nl_wikipedia]
     where article_id in (    
         SELECT article_id    
         FROM [nl_wikipedia.nl_wikipedia]    
         where entity_name like '%Android%')
     and entity_name not like '%Android%'
     and entity_type = 'CONSUMER_GOOD'  
順位entity_name(エンティティ名)num_articles(記事数)
1iOS2733
2iPhone2035
3Windows1543
4iPad1223
5Windows Phone841
Natural Language API の美点は、ここで取り上げたようなユースケースに用途が限定されるわけではなく、エンティティ、感情、構文の構造を広く一般的に出力し、通常のツール セットで存分に分析できるようにすることです。ぜひ、皆さんのユースケースで Natural Language API を試していただき、何が実現できるのかを確かめてください。

このデモの処理パイプラインのコードは、こちらから入手できます。App Engine アプリのコードはこちらにあります。また、この投稿で使用したその他の Google テクノロジーについても、ぜひチェックしてみてください。
  • Natural Language API : エンティティ、感情、構文の検出
  • BigQuery : 任意のビッグデータを対象にしたアドホックなデータ分析
  • Cloud Dataflow : 簡単な分散データ処理
  • Google Cloud Storage : ファイル ストレージとスクラッチ スペース
  • App Engine : ウェブ アプリケーション サービスの提供


- Posted by Jerjou Cheng, Developer Programs Engineer

新たにエラーが発生すると、詳細なエラー情報とともにモバイル プッシュ通知が届きます

私たちは、モバイル デバイスに最適化するために Error Reporting UI を全面的に設計し直しました。サービス エラーやそのスタック トレースの掘り下げ、時間の範囲、サービス、バージョンによるフィルタリング、さらには出現回数、影響を受けたユーザー数、最初 / 最後の発生日によるソートなども含め、デスクトップ版とまったく同じ機能を使用できます。

また、いつものイシュー トラッカーにエラーをリンクしたり、ミュートしたり、チームメートと共有したりといった操作も可能です。

Cloud Console モバイル アプリに表示されたクラウド サービスのトップ画面

モバイル版 Error Reporting は、Cloud Console モバイル アプリの他の機能と見事に統合されています。たとえば、エラーから最新の要求ログにジャンプしたり、発生したエラーを基に Google App Engine サービスの問題のあるバージョンの詳細を調べたりできます。

Android 版はすでにダウンロード可能です。iOS 版も近日中にダウンロードできるようになります。ぜひお試しいただき、[email protected] までご感想をお寄せください。

- Posted by Steren Giannini, Product Manager, Google Cloud Platform








Google for Work Premier Partner である SADA Systems が実施したパブリック クラウド サービスの利用動向調査(回答者 : IT 管理者 200 人超)


- Posted by Alex Barrett, Editor, Google Cloud Platform Blog
Share on Twitter Share on Facebook

本番システムはどれもそうですが、本番パイプラインを管理するにあたっては、定期的な(場合によっては継続的な)アップデートが必要になります。

たとえば、稼働中のゲーム アナリティクス パイプラインを需要に応じてスケーリングするときに、レコード間の時間的な差がどの程度短ければセッションと判断するかに関して調整を加えたいものとします。バッチ システムの場合は実行の間にシステムに変更を加えて新コードをデプロイするだけなので話は簡単ですが、ストリーミングではこの種の変更は複雑になります。

Cloud Dataflow では、こうした作業を少しでも楽にするために、パイプライン コードの更新方法を選択できるようになっています。

Cloud Dataflow のストリーミング パイプラインを更新するときは、まず 2 つの選択肢からどちらかを選びます。Dataflow の Update 機能を使って既存のパイプラインを新バージョンに置き換えるか、手動で既存パイプラインを停止して交換し、新しいパイプラインを起動するかです。


Update の使い方


実行中の Dataflow ジョブは、多くの場合、インフライト データを持っています。インフライト データは、必ず入力から読み込まれ、バッファリングされているものの、まだシンクに送り出されていないデータです。

パイプラインは、たとえば Dataflow の WindowingTriggers 機能を用いて、イベント時間に基づいてデータをウィンドウにまとめることがあります。また、バッファリング済みデータを抱えた “オープン” ウィンドウが、パイプラインに多数残っていることもあります。バッファリングされているのは、ウィンドウのイベント トリガを遅らせるイベント時間の透かしの設定待ちをしているデータです。

Update を使用すると、Dataflow の exactly-once(正確に 1 回)保証 1 を維持しながら、既存のパイプラインをその場で新バージョンに置き換えます。インフライト データ(既存パイプラインがバッファリングしたデータ)はすべて残され、新パイプラインで処理されます。2 つのジョブの間でデータの重複処理は発生しません。

Cloud Dataflow ジョブの Update は簡単です。そのジョブの名前を --jobNameフラグに指定し、--update フラグ付きで新バージョンのジョブを実行するだけです。他のストリーミング システムとは異なり(たとえばApache Spark の場合は、新コードでは旧パイプラインのチェック ポイントを使えません)、あらかじめ何かを構成したり、手動でジャーナリングを追加したり、パイプラインのアップデートのために特別なコードを組み立てたりする必要はありません。Cloud Dataflow サービス上で実行されるすべてのストリーミング パイプラインは、まったく準備することなくアップデートできます。

Update 機能は、インフライト データを残して新しいパイプラインで処理を再開するようにします。そのため、旧パイプラインの永続ストアを新パイプラインで再利用します。

したがって、新旧 2 つのパイプラインは互換要件を満たしていなければなりません。たとえば、アップデート中に CodersSide Inputs を変更することはできません。新パイプラインでパイプライン ステップの名前を変えたり、ステップを取り除いたりした場合は、新旧の名前のマッピングを提供する必要があります。

Dataflow サービスは、新しいジョブの互換性チェックを行い、両パイプラインの互換性を保証します2。新しいジョブが非互換であれば、そのジョブは起動されず、古いジョブが実行を続けます。

Update は、パイプラインで使用されるワーカーの数の上限を手動でスケーリングするときにも使えます。Update の詳細は、Cloud Dataflow サービスのドキュメントを参照してください。


手動での交換



新旧のパイプラインが非互換になるような変更が必要になることがあります。その場合、Update の互換チェックはエラーを起こします。そのため、既存パイプラインから非互換の新パイプラインに切り替えるときは、既存の Dataflow ジョブを停止し、その代わりとして新パイプラインを起動しなければなりません。

このようなジョブの停止に対応するため、Dataflow は新たに Cancel と Drain の 2 種類のオプションを提供しています。


Cloud Dataflow Monitoring Interface の新しい “Stop Job” ダイアログでは、Cancel と Drain のいずれかを選択できます。パイプラインの Drain は、gcloud alpha dataflow jobs drain <​job_id> コマンドを使って gcloud CLI から開始させることも可能です。



パイプラインを Cancel に設定すると、ジョブは終了し、ジョブ関連のすべてのリソース(Google Compute Engine 仮想マシン、永続ディスクなど)は開放されます。そして、パイプラインは直ちに終了し、インフライト データやバッファリング済みデータはすべて失われます。

Cancel のときに新パイプラインで実行を再開しても、ジョブで処理されたデータの保証という点では最も弱いものとなります。ジョブ間でデータの重複処理が発生しないことだけは保証されますが(たとえば、入力ソースが exactly-once セマンティクスを提供していない場合)、インフライト データの消失は起こります。

これに対して Drain では、直ちにジョブが停止することはありません。ジョブの停止のために Drain を使うと、ジョブは入力ソースの読み出しを止めるものの、インフライトおよびバッファリング済みのデータの処理は最後まで行われ、オープン ウィンドウの内容を押し出すトリガはすべて発生します。

ただし、この場合、ウィンドウは不完全なものになることがあります。ドレイン中に閉じられるウィンドウには、ドレイン開始時にすでに入力ソースから読み出され、バッファリングされたデータしか含まれていないのです。

Drain は、Cloud Pub/Sub ソースから取り出されたすべてのメッセージが認識されることを保証し、すべての無制限カスタム ソースの finalize() 呼び出しを保証します。バッファリングされたデータがすべて処理され、ジョブに与えられていたすべてのリソースが開放されたことを Dataflow が検出すると、ジョブは停止します。

このように、Drain は at-least-once(少なくとも 1 回)セマンティクスを提供します。これは、Update の強力な保証と、Cancel の極めて弱い保証の中間点と言えるでしょう。ソースが exactly-once を保証しない場合はデータの重複処理が発生することがありますが、すべてのインフライト データの処理は保証します(インフライト データの扱いについては Update と似ています)。

方法 処理セマンティクス
その場で Update exactly-once
Drainして交換 At-least-once3
Cancel して交換 なし
詳細は Cloud Dataflow ドキュメントのパイプラインの停止に関するページを参照してください。

これだけのツールが揃えば、処理セマンティクスの要件に合わせてパイプライン コードを更新するのは簡単です。パイプラインがメンテナンスの重荷になることを恐れる必要はなくなるでしょう。



1 Google Cloud Dataflow マネージド サービスは、ストリーミング パイプラインに対して exactly-once セマンティクスを保証します。つまり、データを重複して送ることがあるソースを使っても、Dataflow パイプラインはすべてのユニークなデータを正確に 1 回必ず処理します。

2 Dataflow サービスはパイプライン グラフの最適化も行います。パイプライン グラフは、非互換性を引き起こすことがあります。

3 カスタム ソースが exactly-once デリバリを保証し、ソース サイド バッファリングを提供する場合は、“Drain して交換” のときでも exactly-once セマンティクスを提供できます。




- Posted by Matt Lang, Software Engineer



Share on Twitter Share on Facebook



私たち Google は、5 年前に第 1 世代の Google Cloud SQL をリリースして以来、このサービスで多くの企業のアプリケーション構築を支援してきました。


その間、Google Cloud Platform永続ディスクにおけるイノベーションにより、Google Compute Engine では IOPS が大幅に向上しました。そこで私たちは、永続ディスクを利用して第 2 世代の Cloud SQL を開発しました。そのおかげで、極めてパフォーマンスの高い MySQL ソリューションを安価に提供できるようになっています。


Cloud SQL 第 2 世代は、第 1 世代と比べて 7 倍高速で、ストレージ容量も最大 20 倍に増えていますが、コストは下がっています。また、スケーラビリティが向上し、データベースの自動バックアップと任意の時点へのリストアが可能で、99.95 % の可用性が保証されており、世界のどこでも利用できます。こうしたことから、お客様は IT ソリューションを気にかけることなく、アプリケーションに集中できます。


Cloud SQL 第 2 世代におけるパフォーマンスの向上は目覚ましく、各インスタンスは最大で 10 TB のデータ、20,000 IOPS、104 GB の RAM を利用できます。


Cloud SQL 第 2 世代 vs. 競合サービス



このように、Cloud SQL 第 2 世代は第 1 世代から大きく進化しています。では、Amazon Web Services のデータベース サービスと比べてどうなのでしょうか。





Cloud SQL のスレッドあたりの TPS(トランザクション / 秒)は、RDS for MySQL より一貫して高く、16 スレッドまでの構成では Aurora をも上回っています。


詳細
同一ワークロードで Cloud SQL 第 2 世代、Amazon RDS for MySQL、Amazon Aurora のマルチゾーン(高可用性)インスタンスを比較します。いずれも各サービスで提供される最新版の MySQL が実行されています。


これら 3 つのサービスで使われるレプリケーション技術はかなり異なっており、パフォーマンスとレイテンシに大きく影響します。Cloud SQL 第 2 世代は MySQL の準同期レプリケーションを使用しており、RDS for MySQL はブロック レベルの同期レプリケーションを、Aurora はプロプライエタリなレプリケーション技術を使用しています。


スループットを測定するため、プライマリ データベース インスタンスと同じゾーン内の MySQL クライアントから sysbench の OLTP ワークロードが生成されました。ワークロードは一連のステップ ロード テストであり、1 回実行するごとにスレッド(接続)数が倍増します。使用されるデータセットは、読み込み後にディスクへの書き込みが行われるように、データベース インスタンスの総メモリの 5 倍のサイズとなっています。


TPS(トランザクション / 秒)の結果は、Cloud SQL と Aurora が RDS for MySQL より高速であることを示しています。また、16 スレッドまでは、Cloud SQL の TPS が Aurora を上回っています。しかし 32 スレッド以上では、Cloud SQL はレプリケーション ラグが大きくなっている可能性があることからパフォーマンスが低下しており、Aurora のピーク TPS が Cloud SQL の TPS を上回っています。


このワークロードは、3 つのサービスのレプリケーション技術の違いを浮き彫りにしています。Aurora はパフォーマンスの変化が最も小さく、レプリケーション ラグが一定のレベルで推移します。これに対して Cloud SQL はパフォーマンスに重点が置かれており、レプリケーション ラグを許容します。そのためフェイルオーバー時間は長くなりますが、データ損失の心配はありません。




レイテンシ
私たちは、シングル クライアント スレッドのエンド ツー エンドの平均レイテンシを測定しました(これは、いわば “純粋な” レイテンシです)。


レイテンシの比較順位はスレッドが多いと変わります。Cloud SQL のレイテンシは、すべてのテストで RDS for MySQL より小さくなっています。また、Aurora と比べると、ロードの生成に使用されるスレッドが 16 以下では Cloud SQL のほうが小さく、このスレッドが 32 以上ではその逆になります。





ベンチマークの実行




私たちのテストでは、以下の環境構成と sysbench のパラメータを使用しました。
テスト インスタンス :
  • Google Cloud SQL v2、db-n1-highmem-16(16 CPU、104 GB RAM)、MySQL 5.7.11、1000 GB PD(永続ディスク)SSD + フェイルオーバー レプリカ
  • Amazon RDS Multi-AZ(マルチ アベイラビリティ ゾーン)、db.r3.4xlarge(16 CPU、122 GB RAM)、MySQL 5.7.11、1000 GB SSD、10,000 プロビジョンド IOPS + Multi-AZ レプリカ
  • Amazon RDS Aurora、db.r3.4xlarge(16 CPU、122 GB RAM)、MySQL 5.6(最新)+ レプリカ


テスト概要 :
sysbench によるベンチマーク テストでは、それぞれ 2,000 万行の 100 テーブル(合計 20 億行)を使用しました。


このデータセットは、メモリに収まらないようにするために各インスタンスのメモリ(100 GB 強)の倍数のサイズに設定しました。これにより、テストに十分な容量のバイナリ ログがレプリケーションに使われることになりました。具体的には、ロードされる 100 テーブル × 2,000 万行のデータセットのサイズは 500 GB 強でした。


各ステップの実行時間は 30 分間で、ステップ間に 1 分間の “クールダウン” 時間を設け、実行時には 1 秒ごとにレポートが 1 行出力されるようにしました。


データのロード :


Ubuntu setup
sudo apt-get update
sudo apt-get install \
 git automake autoconf libtool make gcc \
 Libmysqlclient-dev mysql-client-5.6

git clone https://github.com/akopytov/sysbench.git
(apply patch)
./autogen.sh
./configure
make -j8
Test variables
export test_system=<test name>
export mysql_host=<mysql host>
export mysql_user=<mysql user>
export mysql_password=<mysql password>
export test_path=~/oltp_${test_system}_1
export test_name=01_baseline
Prepare test data
sysbench/sysbench \
 --mysql-host=${mysql_host} \
 --mysql-user=${mysql_user} \
 --mysql-password=${mysql_password} \
 --mysql-db="sbtest" \
 --test=sysbench/tests/db/parallel_prepare.lua \
 --oltp_tables_count=100 \
 --oltp-table-size=20000000 \
 --rand-init=on \
 --num-threads=16 \
 run
Run the benchmark:
mkdir -p ${test_path}
for threads in 1 2 4 8 16 32 64 128 256 512 1024
do
sysbench/sysbench \
 --mysql-host=${mysql_host} \
 --mysql-user=${mysql_user} \
 --mysql-password=${mysql_password} \
 --mysql-db="sbtest" \
 --db-ps-mode=disable \
 --rand-init=on \
 --test=sysbench/tests/db/oltp.lua \
 --oltp-read-only=off \
 --oltp_tables_count=100 \
 --oltp-table-size=20000000 \
 --oltp-dist-type=uniform \
 --percentile=99 \
 --report-interval=1 \
 --max-requests=0 \
 --max-time=1800 \
 --num-threads=${threads} \
 run
Format the results:
Capture results in CSV format
grep "^\[" ${test_path}/${test_name}_*.out \
 | cut -d] -f2 \
 | sed -e 's/[a-z ]*://g' -e 's/ms//' -e 's/(99%)//' -e 's/[ ]//g' \
 > ${test_path}/${test_name}_all.csv
Plot the results in R
status <- NULL # or e.g. "[DRAFT]"
config <- "Amazon RDS (MySQL Multi-AZ, Aurora) vs. Google Cloud SQL Second Generation\nsysbench 0.5, 100 x 20M rows (2B rows total), 30 minutes per step"
steps <- c(1, 2, 4, 8, 16, 32, 64, 128, 256, 512)
time_per_step <- 1800
output_path <- "~/oltp_results/"
test_name <- "01_baseline"
results <- data.frame(
 stringsAsFactors = FALSE,
 row.names = c(
   "amazon_rds_multi_az",
   "amazon_rds_aurora",
   "google_cloud_sql"
 ),
 file = c(
   "~/amazon_rds_multi_az_1/01_baseline_all.csv",
   "~/amazon_rds_aurora_1/01_baseline_all.csv",
   "~/google_cloud_sql_1/01_baseline_all.csv"
 ),
 name = c(
   "Amazon RDS MySQL Multi-AZ",
   "Amazon RDS Aurora",
   "Google Cloud SQL 2nd Gen."
 ),
 color = c(
   "darkgreen",
   "red",
   "blue"
 )
)
results$data <- lapply(results$file, read.csv, header=FALSE, sep=",", col.names=c("threads", "tps", "reads", "writes", "latency", "errors", "reconnects"))
# TPS
pdf(paste(output_path, test_name, "_tps.pdf", sep=""), width=12, height=8)
plot(0, 0,
 pch=".", col="white", xaxt="n", ylim=c(0,2000), xlim=c(0,length(steps)),
 main=paste(status, "Transaction Rate by Concurrent Sysbench Threads", status, "\n\n"),
 xlab="Concurrent Sysbench Threads",
 ylab="Transaction Rate (tps)"
)
for(result in rownames(results)) {
 tps <- as.data.frame(results[result,]$data)$tps
 points(1:length(tps) / time_per_step, tps, pch=".", col=results[result,]$color, xaxt="n", new=FALSE)
}
title(main=paste("\n\n", config, sep=""), font.main=3, cex.main=0.7)
axis(1, 0:(length(steps)-1), steps)
legend("topleft", results$name, bg="white", col=results$color, pch=15, horiz=FALSE)
dev.off()
# Latency
pdf(paste(output_path, test_name, "_latency.pdf", sep=""), width=12, height=8)
plot(0, 0,
 pch=".", col="white", xaxt="n", ylim=c(0,2000), xlim=c(0,length(steps)),
 main=paste(status, "Latency by Concurrent Sysbench Threads", status, "\n\n"),
 xlab="Concurrent Sysbench Threads",
 ylab="Latency (ms)"
)
for(result in rownames(results)) {
 latency <- as.data.frame(results[result,]$data)$latency
 points(1:length(latency) / time_per_step, latency, pch=".", col=results[result,]$color, xaxt="n", new=FALSE)
}
title(main=paste("\n\n", config, sep=""), font.main=3, cex.main=0.7)
axis(1, 0:(length(steps)-1), steps)
legend("topleft", results$name, bg="white", col=results$color, pch=15, horiz=FALSE)
dev.off()
# TPS per Thread
pdf(paste(output_path, test_name, "_tps_per_thread.pdf", sep=""), width=12, height=8)
plot(0, 0,
 pch=".", col="white", xaxt="n", ylim=c(0,60), xlim=c(0,length(steps)),
 main=paste(status, "Transaction Rate per Thread by Concurrent Sysbench Threads", status, "\n\n"),
 xlab="Concurrent Sysbench Threads",
 ylab="Transactions per thread (tps/thread)"
)
for(result in rownames(results)) {
 tps <- as.data.frame(results[result,]$data)$tps
 threads <- as.data.frame(results[result,]$data)$threads
 points(1:length(tps) / time_per_step, tps / threads, pch=".", col=results[result,]$color, xaxt="n", new=FALSE)
}
title(main=paste("\n\n", config, sep=""), font.main=3, cex.main=0.7)
axis(1, 0:(length(steps)-1), steps)
legend("topleft", results$name, bg="white", col=results$color, pch=15, horiz=FALSE)
dev.off()

Cloud SQL 第 2 世代の機能

前節では Cloud SQL 第 2 世代のパフォーマンスの高さを紹介してきましたが、それはこのサービスの半面でしかありません。私たち Google は、フルマネージド サービスは強力であるのと同じくらい便利でなければならないと考えています。そこで私たちはこのサービスに、データを簡単に保存、保護、管理するのに役立つ新機能を追加しました。


データの保存と保護




接続と管理




もちろん、私たちは Cloud SQL を非常に誇りに思っています。ですが、皆さんが気になるのは、Cloud SQL 第 2 世代に対するお客様からの評価でしょう。ここでは、2 社のお客様から寄せられたコメントを紹介します。


「私たちは SaaS 企業として、お客様の数百のインスタンスを管理しています。Cloud SQL は、私たちのスタックの主要なコンポーネントです。Cloud SQL のベータ テストを行ったところ、大口のお客様に素晴らしいパフォーマンスでサービスを提供できました。そこで私たちはすぐに、大口のお客様のうち数社の環境を Cloud SQL に移行しました。これらのお客様では、クエリのパフォーマンスが 7 倍に向上したのです」
- Rajesh Manickadas 氏、Orangescape のエンジニアリング ディレクター


「モバイル アプリケーション企業である私たちにとって、お客様に最高の製品を提供するにはデータ管理が不可欠です。Cloud SQL のおかげで私たちは、データ ポイントが毎月 1 億 2,000 万 ~ 1 億 5,000 万件ずつ増えるようなデータベースを管理できています。実際、お客様の 1 社である年間売上高 60 億ドルの通信事業者のデータベースには、毎月 15 GB 以上のデータが追加されています。ピーク時には書き込み操作が毎秒 400 件程度に達しますが、API 呼び出しの平均応答時間は 73 ミリ秒 以下にとどまっています」
- Andrea Michaud 氏、www.teamtracking.us のクライアント サービス責任者


次のステップ



Cloud SQL はこれからどうなるのでしょうか。永続ディスクのパフォーマンスが今後も向上し、仮想ネットワーキングの改良も進むほか、第 1 世代ユーザーが第 2 世代にアップグレードするための移行ツールが効率化されます。ご期待ください。


Google Cloud Platform(GCP)をまだご利用でない方は、ぜひ無料トライアルにお申し込みください。300 ドル分のクレジットで Cloud SQL と他の GCP サービスを無料でお試しになれます。


有償アカウントにアップグレードするときは、手始めに安価なマイクロ インスタンスをテストや開発にお使いになるとよいでしょう。準備ができたら、それらを簡単にスケールアップして、パフォーマンス集約型アプリケーションの運用に利用できます。


また、Google のパートナーのエコシステムを利用して Cloud SQL を導入することもできます。データ転送の効率化は TalendAttunityDbvisitXplenty が、分析データの可視化は TableauLookerYellowfinBime by Zendesk が、データベースの管理と監視は ScaleArcWebyog が、専門サポートは PythianPercona がそれぞれ手がけています。


「Cloud SQL を導入する Tableau のお客様がますます増えています。クラウドで高速な分析ができるというメリットがあるからです。Cloud SQL 第 2 世代ではパフォーマンスが大幅に向上しており、導入にさらに拍車がかかるでしょう」
- Dan Kogan 氏、Tableau のプロダクト マーケティング & テクノロジー パートナー担当ディレクター


「Google の Cloud SQL 第 2 世代が GA(一般公開)リリースとなり、Looker 製品との高度な統合をサポートできることに、私たちはわくわくしています。Looker Data Platform のインデータベース分析のアプローチと Cloud SQL のフルマネージド データベース サービスを組み合わせることで、お客様はクラウド ベースのリアルタイム分析および可視化環境を手に入れ、社内の誰もがデータに基づく意思決定を行えるようになります」
- Keenan Rice 氏、Looker の戦略アライアンス担当バイス プレジデント


「データベース アプリケーションのクラウドへの移行は、多くのお客様にとって優先課題となっています。私たちは Attunity Replicate により、ダウンタイムを発生させることなく、Cloud SQL に容易に移行できるようにすることで、その課題の解決を後押ししています。Cloud SQL 第 2 世代では、このサービスの企業における利用拡大の鍵となるパフォーマンス、信頼性、セキュリティが一段と向上しています。お客様はこうした機能強化の恩恵を受けることができ、私たちはお客様と協力してデータ転送の障害の解消に取り組むことを楽しみにしています」
- Itamar Ankorion 氏、Attunity の最高マーケティング責任者(CMO)


Cloud SQL は大きな波を起こしつつあり、皆さんがそれに加わっていただけることを私たちは願っています。


- Posted by Brett Hesterberg, Product Manager, Google Cloud Platform
Share on Twitter Share on Facebook