Google Cloud Platform Japan 公式ブログ: 7月 2018

Cloud OnAir 番組レポート : Google Cloud Next '18 最新情報

2018年7月31日火曜日

Cloud OnAirGoogle Next ‘18Cloud AI : AI を簡単にそして高速に使うための製品

Cloud AutoML Vision、Cloud AutoML Natural Language、Cloud AutoML Translation

Cloud ML Engine での scikit-learn と XGBoost のサポートと学習とオンライン推論、Cloud TPU v3（第 3 世代 TPU のアルファ版）

コンタクトセンター向けソリューション Contact Center AI

IoT : ML と連携した IoT アプリの可能性を広げる製品

Google Cloud の強力な AI 機能をゲートウェイや接続されたデバイスまで拡張できる Cloud IoT Edge

TensorFlow Lite 機械学習モデルをエッジ側で実行することができる ASIC チップ「Edge TPU」

Data Analysis : データ解析ツールの拡張機能

BigQuery から機械学習モデルを構築できる BigQuery ML

複数の地理データタイプを扱うことができる BigQuery GIS

BigQuery と Google スプレッドシートの連携

ワンクリックで視覚化するツール Data Studio Explorer

データ処理を高速化する Cloud Composer 、Dataproc Autoscaling、Dataproc Custom Packages

DevOps : クラウドとオンプレミスの環境において高度な運用管理機能を提供

サーバレスアプリケーションを構築できる新しい継続的インテグレーション／継続的デリバリー（CI/CD）サービス Cloud Build

オンプレミスコンテナをサポートする GKE On-Prem

Istio と App Engine のワークロードを可視化する Stackdriver Service Monitoring

7 月 26 日放送 : Google Cloud Next ’18 最新情報こちら

[Cloud OnAir] Google Cloud Next '18 最新情報 2018年7月26日放送 from Google Cloud Platform - Japan

Google Cloud Next ’18 初日の出来事、Google Cloud Next ’18　2 日目の出来事、Google Cloud Next ’18　3 日目の出来事でも詳しく解説しているので、ぜ日ご覧ください。Cloud OnAirこちら

Cloud Services Platform 登場 : サービスの高度な運用基盤をクラウドとオンプレミスの両方で提供

2018年7月31日火曜日

Cloud Services Platform

サービスメッシュ : Istio 1.0（オープンソース）、Managed Istio、Apigee API Management for Istio のリリース

ハイブリッドコンピューティング : マルチクラスタ管理機能を持つ GKE On-Prem

ポリシーの徹底 : Kubernetes ワークロードを統制する GKE Policy Management

Ops ツール : Stackdriver Service Monitoring

サーバーレスコンピューティング : GKE サーバーレスアドオン、オープンソースサーバーレスフレームワークの Knative

開発者用ツール : フルマネージド CI/CD プラットフォームの Cloud Build

Cloud Services Platform ファミリー「私たちは、オンプレミスとクラウドの両方でコンテナを統一的にデプロイし管理できるプラットフォームを必要としていました。Kubernetes が業界標準となりつつある中で、デプロイのリスクとコストを低減するために GCP 上の Kubernetes Engine を採用することは自然な流れでした。」 Istio によるアプリケーションアーキテクチャのモダナイゼーションオープンソースのサービスメッシュ、Istio

サービスディスカバリとインテリジェントなトラフィック管理 : Managed Istio は、クラスタ内で実行されているすべてのサービスを把握し、サービス間のネットワークトラフィックを管理します。アプリケーションレベルの負荷分散や、コンテナと VM ワークロードのための高度なトラフィックルーティングを使用して、健全性チェックやカナリア / Blue-Green デプロイメントなどを提供し、サーキットブレーカーとタイムアウトに対応したフォールトトレラントなアプリケーションを実現します。

認証を必要とするセキュアな通信 : Managed Istio は、エンドポイントのセグメント化と粒度の細かいポリシー設定、異常動作の検出とコンプライアンスの確保、デフォルトでの mTLS 使用によるトラフィックの暗号化などを提供します。

モニタリングと管理 : Google Cloud のモニタリング / 管理ツールスイートである Stackdriver とのインテグレーションにより、Managed Istio のもとで実行されるサービスシステムの把握とトラブルシューティングを可能にします。

エンタープライズグレードの Kubernetes をあらゆる場所で実現マネージドサービスの Kubernetes Engine は数多くのテストを通じて飛躍的に成長GKE On-Prem

統一されたマルチクラスタ登録とアップグレード管理

Stackdriver との連携によるモニタリングとロギングの一元化

ハイブリッド IAM（Identity and Access Management）

Kubernetes アプリケーション向けの GCP Marketplace

GCP とオンプレミスの両方における統合的なクラスタ管理

プロフェッショナルなサービスとエンタープライズグレードのサポート

Kubernetes ワークロードの自動的な管理こちら環境に対するサービスセントリックビュー

サービスグラフ : 環境全体のリアルタイムな鳥瞰図を提供します。通信方法と依存関係を含めた形ですべてのマイクロサービスを表示します。

SLO（サービスレベル目標）モニタリング : Google の SRE 担当者がGoogle サービスに対して実施しているのと同様の方法（お客様中心で疲労が少ない方法）でモニタリングとアラートを行います。

サービスダッシュボード : 1 つのサービスに対するすべてのシグナルを 1 か所にまとめ、従来よりも簡単かつ迅速にデバッグできるようにし、平均修復時間（MTTR）の削減に貢献します。

マイクロサービスが API になるときApigee API Management for Istio クラウドの可能性を最大限に引き出すために

GKE サーバーレスアドオンを使用すれば、サーバーレスワークロードを Kubernetes Engine にワンステップでデプロイして実行できます。ソースからコンテナを瞬時に生成し、コンテナベースのステートレスワークロードの自動スケーリングやゼロへのスケールダウンさえ可能です。GKEサーバーレスアドオンの早期プレビューにはこちらから参加できます。

Knative（ケイネイティブと発音）は、GKE サーバーレスアドオンを支えているのと同じテクノロジーによるオープンソースのサーバーレスコンポーネントです。クラウドかオンプレミスかを問わず、Kubernetes 上で動作するサーバーレスアプリケーションの構築とデプロイに必要なビルディングブロックを提供します。Knative を使用すれば、モダンでコンテナベースのクラウドネイティブなアプリケーションを作成できます。

Cloud Build は、フルマネージドの CI/CD（継続的インテグレーション / 継続的デリバリ）プラットフォームです。ソフトウェアの迅速かつ大規模なビルド、テスト、デプロイを可能にします。

こちらこちら

株式会社LIFULL の導入事例：物件画像のカテゴリー分類を AutoML で自動化。数十秒かかっていた分類を自動化で 2 秒に

2018年7月30日月曜日

Google Cloud AutoML VisionGoogle Cloud Machine Learning EngineGoogle App EngineGoogle Cloud EndpointsGoogle Cloud Storage株式会社LIFULL AutoML の導入で HOME'S における利便性の向上を目指す

専門知識がなくても非常に高い精度で物件画像を分類できる AutoML

物件情報入稿ツールシステム構成図TensorFlow

物件情報入稿ツール : 画像を一括でアップロードすると AutoML により自動で画像種別を分類

PDFこちら

Cloud OnAir 番組レポート :Google Compute Engine に Deep Dive

2018年7月24日火曜日

Cloud OnAirGoogle Compute Engine 自動割引と低コスト

割引の種類 : 課金は秒単位で、実際に使用した分しか料金はかかりません。継続利用割引と確約利用割引という 2 種類の割引があります。

マシンタイプ : 事前定義されたマシンタイプの中にニーズにあったものがない場合、仮想 CPU 数やメモリ量を自由に設定できます。これをカスタムマシンタイプと呼びます。カスタムマシンタイプでは、GPU もアタッチ可能です。

推奨サイズ : サーバスペックの推奨サイズを自動的に提示する機能です。

プリエンプティブル VM : 通常のインスタンスに比べて低価格で作成できるインスタンスです。最大 24 時間利用可能で、プリエンティブル VM には、GPU を追加することもできます。

安定したパフォーマンス

VM の起動時間 : 1VM あたり 20 秒から 40 秒と高速に起動することができます。クラスタサイズを増やしても起動時間は変わらず、1000VM を 1 分程度で立ち上げることができます。

永続ディスク : ストレージに関しては、高いパフォーマンスと信頼性、柔軟性に富んだサービスを提供します。永続ディスクは、標準のハードディスクと SSD を選択できます。さらに、より高いパフォーマンス要求に対応するため、ローカル SSD を利用することもできます。

運用のしやすさ

ライブマイグレーション : ハードウェアやホスト OS などのメンテナンスが発生した際にインスタンスを稼働させたまま、同一ゾーン内の別ホストへ自動的に移行する機能です。Google Compute Engine には、ライブマイグレーションをシミュレーションする機能もあります。

仮想マシンのログイン管理 : IAM によりインスタンスへの SSH アクセスを管理することが可能です。

オートスケールの動作原理 : 負荷の増減に基づいてインスタンスを追加、削除する機能です。ポリシーを定義するだけで、自動的にスケールさせることができます。

仮想マシンのバージョンアップ : ブルーグリーンデプロイメント、カナリアリリースといったローリングアップデートをデモと合わせてご覧いただけます。

7 月 19 日放送 : Google Compute Engine に Deep Diveこちら

[Cloud OnAir] Google Compute Engine に Deep Dive！基本から運用時のベストプラクティスまで 2018年7月19日放送 from Google Cloud Platform - Japan

Cloud OnAirこちら

エラーバジェットの使い過ぎを解消する : CRE が現場で学んだこと (後編)

2018年7月24日火曜日

CRE が現場で学んだことサービスのエラーバジェットエラーバジェットを使い過ぎる理由エラーバジェットの負債下流での消費状況を把握するブログ記事ソフトウェアのリリースに問題があるケース

合意のもとで機能と信頼性のバランスを調整する : たとえば、いつも 2 週間分の仕事を割り振り、通常はそのうち機能面の開発に 95 %、事後分析への対応やその他の信頼性関連の仕事に 5 % 費やしているとします。SLO が遵守できていない間は、その割合を 50 % ずつにすると決めるのです。

サービスをオーバープロビジョニングする : たとえば、ほかのクラウドゾーンやリージョンにレプリケートするための投資を増やしてみましょう。もしくは、サービスのレプリカを稼働させ、トラフィックの負荷が上昇しても対応できるようにします。ただしこれは、このアプローチがエラーバジェットの消費抑制に有効だと判断した場合のみ有効です。

リライアビリティインシデントが発生したと申告する : 事後分析とエラーバジェットの使用状況を分析し、解決法を探る担当者を決めましょう。こうした解決法を最優先にすると事前に表明しておくことが重要です。

凍結状態の期間エスカレーションポリシーの例を分析リリースの凍結による長期的なコスト特効薬エラーバジェットを自社（およびユーザー）のために利用するSRE の原則をサービスのデプロイや管理に適用する方法関連コンテンツ

SLO のエスカレーションポリシー : CRE が現場で学んだこと

可用性とどう向き合うべきか、それが問題だ : CRE が現場で学んだこと

こちら

株式会社シグナルトークの導入事例：Google App Engine を駆使して少人数・低コストでのソーシャルゲーム開発・運用を実現

2018年7月23日月曜日

Google App EngineGoogle BigQueryGoogle Cloud StorageCloud Datastore株式会社シグナルトーク Google App Engine の高機能・柔軟性が開発のリスクを大幅に低減

『ダンまつま！～ダンジョンで待ってます！～』システム構成図
低コストで安定した開発環境もスムーズな制作に貢献

GKE（Kubernetes Engine）Cloud Spanner Cloud MemorystoreGoogle Cloud Machine LearningPDFこちら

Google Cloud Next '18 in Tokyo スケジュール公開、セッション登録開始

2018年7月19日木曜日

Google Cloud Next '18 in Tokyo イベント申し込み & セッション登録Building a Cloud for EveryoneBringing the Cloud to You イベント申し込み & セッション登録 イベント名： Google Cloud Next '18 in Tokyo
公式ハッシュタグ： #GoogleNext18
日　　程： 2018 年 9 月 19 日（水）・20 日（木）
開　　場： 8:30 （予定）
基調講演： 9:30 〜 11:30 （予定）
セッション： 12:00 〜 19:20
会　　場：
　ザ・プリンスパークタワー東京〒105-8563 東京都港区芝公園 4 - 8 - 1
　東京プリンスホテル〒105-8560 東京都港区芝公園 3 丁目 3 - 1
お問い合わせ先：
　Google Cloud Next Tokyo '18 運営事務局
　googlecloud-next18-tokyo＠google.com （注意事項）

本カンファレンスは、各種 Google Cloud 関連製品サービスの導入を検討中のエンドユーザー企業、団体、教育機関、政府自治体向けのイベントになります。導入を検討されていない方には、ご登録いただいてもご受講いただけない場合もございます。
十分な座席数をご用意しておりますが、定員を超えた場合にはエンドユーザー企業様優先の抽選とさせていただきます。

ご不明な点は、こちらの FAQ をご確認ください。

エラーバジェットの使い過ぎが意味するもの : CRE が現場で学んだこと

2018年7月18日水曜日

CRE が現場で学んだことCRE（顧客信頼性エンジニアリング）何にエラーバジェットを費やしているか

ほとんどのエラーがバイナリリリースの際に発生している場合は、リリースの頻度を控えたり、エラーを起こりにくくしたり、エラーが発生しても影響があまり出ないようにしたりといった対策が必要です。そうしないと、エラーバジェット内に収めることは難しいでしょう。

断続的なアプリケーション障害によってずっと同じようなエラーが発生し、それがエラーバジェットの大半を占めている場合は、アプリケーションに根本的な欠陥があるということです。ログを掘り下げて問題のクエリを探し、エンジニアと協力して根本的原因を特定したうえで、直接対処するか、もしくは次のプロジェクトの計画サイクルで修正しなくてはなりません。

“configuration pushes” や過度の負荷、“queries-of-death” が原因でサービスの大半が何分間にもわたって停止するような大規模アプリケーション障害が発生し、そこにエラーバジェットの大半が費やされている場合は、効果的な事後分析を実施して根本的原因を突き止め、障害を緩和させるべきでしょう。開発エンジニアの力を借りて、事後分析で優先順位トップとされた事項に対応する必要があります。したがって、機能の開発やリリースはおのずと後回しになります（これについては別の記事で詳しく説明します）。

クリティカルなバックエンドやコンピューティングプラットフォームのような制御対象以外との依存関係によって多くのエラーバジェットが消費されている場合は、その依存関係を見直すか、プラットフォームのオーナーと直接交渉し、SLI を示したうえで、サービスの信頼性を向上させる方法や予期される障害モードへの耐性を高める方法について話し合ってみましょう。

シグナルを正しく査定しているかユーザーエクスペリエンスが低下してもユーザーは耐えられるかユーザーエクスペリエンスが明確でないケースパート 2SRE の原則をサービスのデプロイや管理に適用する方法関連コンテンツ

優れた SLO を策定するには : CRE が現場で学んだこと

SLO 違反への対処 : CRE が現場で学んだこと

* この投稿は米国時間 6 月 28 日、Adrian Hilton、Alec Warner、および Alex Bramley によって投稿されたもの（投稿はこちら）の抄訳です。- By Adrian Hilton, Alec Warner and Alex Bramley

Cloud OnAir 番組レポート :GCP 活用事例紹介 - 株式会社リクルートライフスタイル

2018年7月17日火曜日

Cloud OnAir どんな課題があったのか？クラウド導入後の変化BigQueryKubernetes EngineBigtable CET のアーキテクチャ

7 月 12 日放送 : リクルートライフスタイル様の GCP 活用事例
こちら

[Cloud OnAir] お客様事例紹介リクルートライフスタイルにおけるデジタルトランスフォーメーションとクラウド活用 2018年7月12日放送 from Google Cloud Platform - Japan

Cloud OnAirこちら

第 5 回 INEVITABLE ja night を開催します

2018年7月17日火曜日

開催概要 INEVITABLE 対談「エンターテックを実現するテクノロジーとプレイヤー」
スピーカー : 鈴木貴歩氏（パレードオール株式会社代表取締役 / エンターテック・アクセラレーター氏）
聞き手: 小島英揮氏（Still Day One合同会社代表社員パラレルマーケター・エバンジェリスト）
Google テクノロジーアップデート
スピーカー: 松田白朗（グーグル合同会社デベロッパーアドボケート）
※その他、調整中
講演後は講師や参加者の皆さんとの交流や情報交換をお楽しみください。
参加を希望される方は、お申し込みサイトをご覧ください。
皆様のご参加をお待ちしております。 ■■■　INEVITABLE TV のご案内　■■■INEVITABLE TV

TPU が拓く AI 活用の近未来（グーグル合同会社佐藤一憲）

VUI の普及と進化の方向性（ゲスト : 岩佐琢磨氏）

クラウド時代のトラブルシューティング : 解決に役立つプロバイダーとのコミュニケーション（前編）

2018年7月6日金曜日

編集部注 : 今回の記事は、数年前に SRE（サイト信頼性エンジニアリング）の本を出した（本当に！）Google エキスパートチームが執筆してくれました。実際に手を動かして学ぶ同書の姉妹書『The Site Reliability Workbook』も発売に向けて準備が進んでいるようです。ここでは、多くの IT チームにとって重要な SRE の一分野である、クラウドコンピューティング時代のトラブルシューティングについて取り上げます。今回は 2 回連載の前編です。本稿を読み終えたら、クラウドプロバイダーとのコミュニケーション方法をテーマにした後編もぜひご覧ください。書籍『Site Reliability Engineering』の中後編クラウドプロバイダーのサポートワークフローを把握する

サポートに対する典型的なイシューレポートのライフサイクルはどうなっているか？

問題が複雑もしくは重大な場合の社内のエスカレーションプロセスはどうなっているか？

<サービス名>の社内サービスレベル目標（SLO）はあるか？　ある場合、その内容はどうなっているか？

プレミアムサポートとしてどのようなタイプのものを利用できるのか？

クラウドプロバイダーのサポート担当との効率的なコミュニケーション基本情報の提供4 つの必須情報時刻製品位置具体的な識別子

太平洋夏時間 2017 年 9 月 8 日 15 時 13 分から 5 分後まで～が観察されました

2017 年 9 月 10 日以降、間欠的に 2～5 回観察されたことですが、～

太平洋夏時間 2017 年 9 月 8 日 15 時 13 分以降ずっと～

太平洋夏時間 2017 年 9 月 8 日 15 時 13 分から同 22 時 22 分まで～

ISO 8601 形式認知的負荷

今日早く : 十分に特定できていません。

昨日 : 連絡を受け取った側が暗黙の日付を明らかにしなければなりません。特に日付変更線をまたがる場合は曖昧になります。

9/8 : 曖昧です。米国では 9 月、他の地域では 8 月だと解釈される恐れがあります。明確にするために ISO 8601 形式を使いましょう。

REST API がエラーを返しました。

データマイニングのクエリインターフェースがハングアップしています。

仮想マシンを作成できません。仮想マシンをどのようにして作ろうとしたのかがはっきりしません。エラーモードがどうなっているのかもわかりません。

CLI コマンドがエラーを返します。

エラーの内容を具体的に書き、コマンドの構文を明示して、他の人も実行できるようにしましょう。
より良い書き方 : “mktool create my-instance --zone us-central1” を実行したところ、次のようなエラーメッセージが返ってきました。

us-east1 において～

リージョン eu-west-1 と eu-west-3 で試したところ～

プロジェクト 123412341234 または my-project-id で～

複数のプロジェクト（123412341234 が含まれます）にわたって～

社内のゲートウェイ 56.56.56.56 からクラウドの対外 IP 218.239.8.9 に接続するとき～

弊社インスタンスの 1 つにつながりません : 曖昧すぎます。

インターネットから接続できません : 曖昧すぎます。

5W1H 問題発生の影響と回答に対する要望の明確化期待する優先順位希望する回答期限後編関連コンテンツ

SRE vs. DevOps

SRE の教訓 : Google におけるインシデント管理とは

エスカレーションポリシーの適用 : CRE が現場で学んだこと

Special thanks to Ralph Pearson, J.C. van Winkel, John Lowry, Dermot Duffy and Dave Rensin* この投稿は米国時間 5 月 31 日、Luke Stone と Jian Ma によって投稿されたもの（投稿はこちら）の抄訳です。- By Luke Stone and Jian Ma

クラウド時代のトラブルシューティング : 解決に役立つプロバイダーとのコミュニケーション（後編）

2018年7月6日金曜日

編集部注 : この記事は、数年前に SRE（サイト信頼性エンジニアリング）の本を出した（本当に！）Google エキスパートチームが執筆してくれました。同書の続編も発売に向けて準備が進んでいるようです。ここでは、多くの IT チームにとって重要な SRE の一分野である、クラウドコンピューティング時代のトラブルシューティングを取り上げます。今回は 2 回連載の後編です。クラウドプロバイダーのサポート部門に送るイシューレポートの基本的な書き方については前編をご覧ください。前編クラウドにおけるトラブルシューティングの要点

トリアージ : 可能な範囲で問題の影響を緩和する。

検証 : 観察されたことを集約、共有する。

診断 : 観察されたことを説明するための仮説を立てる。

テストと修復 :

仮説を証明、または反証するテスト方法を見つける。
テストを実施し、結果の解釈を統一する。
次の仮説に移り、問題が解決するまでこのプロセスを繰り返す。

1. すでに自分で行ったトラブルシューティングの内容を伝える2. 問題を明確かつ具体的に示す伝言ゲーム

見たとおりのものを示すため、スクリーンショットを添付する。

ウェブベースのインターフェースとして HAR（Http Archive）ファイルを提供する。

tcpdump 出力、ログの一部、サンプルスタックトレースなどの情報を添付する。

3. 本番アウテージは早い段階で報告する

インフラストラクチャに影響を及ぼす既知の問題を直ちにチェックする。

問題の性質を確認する。

通信チャネルを開設する。

複数の顧客に影響を及ぼす既知の問題の有無

報告した問題をプロバイダー側で観察することの承認や、詳細情報のリクエスト

希望する通信手段（たとえば、電話、Skype、イシューレポート）

SRE 本のインシデント管理の章を参照4. ネットワーク関係の問題はとりわけ具体的に報告する

パケットの送信側から受信側までの経路における重要なホップと、経路に沿って行われる重要な変換（たとえば NAT）を書き出す。

最初に、インターネット IP アドレスまたは RFC 1918 プライベートアドレスと、ネットワークの AS 番号を用いて、影響を受けたネットワークエンドポイントを識別する。

エンドポイントの管理者、DNS ホスト名との関連の有無など、エンドポイントに関して意味がある情報を書き込む。

VPN トンネル、プロキシ、NAT ゲートウェイなど、間に入るカプセル化や間接参照の情報を書き込む。

ファイアウォール、CDN、WAF など、途中のフィルタリングの情報を書き込む。

MTRtcpdumpWireshark5. 必要に応じてエスカレーションする6. 長く続く問題や困難な問題についてはサマリードキュメントを作成する

最新の状況が冒頭にまとめられている。

すべての関連イシューレポートや社内バグ管理情報へのリンクがまとめられている。

正しいかもしれない仮説と、すでに除外された仮説のリストがまとめられている。特定の仮説について検証を開始するときはそのように書き、使用する予定のテストやツールを明らかにする。そうすることで、適切なアドバイスをもらえたり、作業の重複を避けたりすることができる。

コミュニケーションスキルを磨く詳細なイシューレポートを書いて認知的負荷を下げる認知的負荷ナラティブ（ストーリーテリング）のテクニックを使う“昔々あるところに…”テキストの書式グラフ

タイトルや軸ラベルを付けた状態でスクリーンショットを取得する。絶対数には単位（分あたりのリクエスト数、秒あたりのエラー数など）を付加する。

スクリーンショットに矢印や丸でコメントを付け、重要なポイントを目立たせる。

何を測定しているグラフなのかを簡潔に説明する。

正常な場合のグラフがどのような形になるかを簡潔に説明する。

グラフに対する自分なりの解釈、問題との関連を簡潔に説明する。

Y 軸が個別的なエラー（たとえば自分のハンドラ内の例外数）を示しており、調査中の問題（たとえば永続化レイヤのレイテンシ）との関係がはっきりしない。このような場合は、問題にとってこのグラフがなぜ重要なのかを説明する必要がある。

Y 軸が絶対数（たとえば 1 分あたりの数）になっていて、相対的な影響についての手がかりが得られない。

X 軸にタイムゾーンの指定がない。

Y 軸が 0 から始まっていない。これでは Y 軸の値のわずかな差が非常に大きく見えてしまう。

軸ラベルがなかったり、消されたりしている。

株式会社バンダイナムコスタジオ様の導入事例動画： Google App Engine の活用で、ゲームリリース後のトラブルとは無縁の「平和な日々」という驚きを体験

2018年7月4日水曜日

Google App EngineGoogle Kubernetes EngineCloud DatastoreBigQueryGoogle Stackdriver株式会社バンダイナムコスタジオ IaaS ベースのインフラの課題とソーシャルゲーム運用の難しさ

「アイドルマスターミリオンライブ！シアターデイズ」
（配信元：株式会社バンダイナムコエンターテインメント）
©窪岡俊之 ©BANDAI NAMCO Entertainment Inc.
Google App Engine の活用でエンジニアが開発に集中できる環境を構築PDFこちら

Cloud OnAir 番組レポート :ビッグデータ事例紹介 - e-Learning 編

2018年7月3日火曜日

Cloud OnAirCloud OnAir 番組レポート :ビッグデータ事例紹介

Google アナリティクス 360 Suite に蓄積された Google Merchandise Store のログデータ（デモ用）を利用して、BigQuery で分析

Google Colaboratory を利用した分析例

6 月 28 日放送: ビッグデータ事例紹介 - eLearning 編こちら [Cloud OnAir] ビッグデータ事例紹介データ分析と実践編 (e-Learning) 2018年6月28日放送 from Google Cloud Platform - Japan Cloud OnAirこちら

進化する Google Cloud マネージドデータベース

2018年7月3日火曜日

Cloud Spanner の commit タイムスタンプ機能を提供

Cloud Bigtable のレプリケーション機能をベータリリース

Cloud Memorystore for Redis をベータリリース

Cloud SQL for PostgreSQL を正式リリース

Cloud Spanner の commit タイムスタンプ機能Cloud SpannerOptivaBandai Namco変更履歴の作成commit タイムスタンプ機能 Cloud Bigtable のレプリケーション機能リージョナルレプリケーション機能 Cloud Memorystore for Redis ベータ版Cloud Memorystore for Redis Cloud SQL for PostgreSQL の正式リリースCloud SQL正式提供が開始416 GB拡張機能HIPAA の適用DBMS of the Year 20171* この投稿は米国時間 4 月 25 日、Director of Product Management の Dominic Preuss によって投稿されたもの（投稿はこちら）の抄訳です。- By Dominic Preuss, Director of Product Management

Cloud SQL for PostgreSQL を正式リリース

2018年7月2日月曜日

Google Cloud PlatformCloud SQLSRE チーム高可用性と自動フェイルオーバーSLA高可用性とレプリケーション19 種の追加エクステンションのサポートHIPAA コンプライアンスGoogle Cloud Business Associates Agreement（BAA）誰もが使える Cloud SQL でデータ管理を分散化した OneMarketOneMarketグローバルなロケーションKubernetes EngineCloud SQL 「私はビジネス問題に全力を注ぎたいと思っています。私のチームが Cloud SQL for PostgreSQL などのマネージドサービスを使っているのは、品質の高いコードを送り出し、市場投入の時期を早めることに集中するためです。サーバーやシステムの心配をしなければならないとしたら、重要とはいえ直接的には意味のない管理作業に多くの時間を割くことになるでしょう。当社の CTO が言うように、私たちは配管ではなく家を建てたいのです。」
— Peter McInerney 氏、OneMarket の技術運用担当 VP

OneMarket のプラットフォームは 15 個のマイクロサービスで構成され、それぞれが 1 つ以上のストレージサービスに支えられています。Cloud SQL for PostgreSQL は、リレーショナルデータが必要な部分のマイクロサービスを支えています。

「私は時々、2008～2009 年ごろの Westfield Digital のことを考えます。当時のチームは、データセンターに常駐して、サーバーをメンテナンスしたり壊れたディスクを修復したりしていました。今は簡単にスケーリングできます。」
— Peter McInerney 氏BigQuery Cloud SQL for PostgreSQL の使用にあたってpg_dumpAloomaInformaticaSegmentStitchTalendXplentyChartIOiChartsLookerMetabaseZoomdataこちらのページでサインアップ公開バグトラッカーCloud SQL ディスカッショングループ* この投稿は米国時間 4 月 18 日、Product Manager の Brett Hesterberg によって投稿されたもの（投稿はこちら）の抄訳です。- By Brett Hesterberg, Product Manager

Google Cloud Platform Japan Blog

Cloud OnAir 番組レポート : Google Cloud Next '18 最新情報

Cloud Services Platform 登場 : サービスの高度な運用基盤をクラウドとオンプレミスの両方で提供

株式会社LIFULL の導入事例：物件画像のカテゴリー分類を AutoML で自動化。数十秒かかっていた分類を自動化で 2 秒に

Cloud OnAir 番組レポート :Google Compute Engine に Deep Dive

エラーバジェットの使い過ぎを解消する : CRE が現場で学んだこと (後編)

株式会社シグナルトークの導入事例：Google App Engine を駆使して少人数・低コストでのソーシャルゲーム開発・運用を実現

Google Cloud Next '18 in Tokyo スケジュール公開、セッション登録開始

エラーバジェットの使い過ぎが意味するもの : CRE が現場で学んだこと

Cloud OnAir 番組レポート :GCP 活用事例紹介 - 株式会社リクルートライフスタイル

第 5 回 INEVITABLE ja night を開催します

クラウド時代のトラブルシューティング : 解決に役立つプロバイダーとのコミュニケーション（前編）

クラウド時代のトラブルシューティング : 解決に役立つプロバイダーとのコミュニケーション（後編）

株式会社バンダイナムコスタジオ様の導入事例動画： Google App Engine の活用で、ゲームリリース後のトラブルとは無縁の「平和な日々」という驚きを体験

Cloud OnAir 番組レポート :ビッグデータ事例紹介 - e-Learning 編

進化する Google Cloud マネージドデータベース

Cloud SQL for PostgreSQL を正式リリース

12 か月間のトライアル

Labels

Archive

Feed

Company-wide

製品・サービス

デベロッパー