Google Cloud Platform Japan Blog
最新情報や使い方、チュートリアル、国内外の事例やイベントについてお伝えします。
株式会社ディンプスの導入事例:激変するネット負荷、予測困難なオンラインゲームのバックエンドをキッチリ支える
2017年11月20日月曜日
家庭用ゲーム機においても「オンライン対応」が当たり前の時代。しかしオンラインゆえにユーザーのトラフィックは予測困難で、バックエンドシステムには従来以上の柔軟性や高性能が求められます。今回「Google Cloud Platform」を採用することで、厳しい条件のバックエンドを、高性能、高可用かつ低コストで実現した事例をご紹介します。
■写真左から
株式会社ディンプス
ソフトウェア技術部 次長 兼 ネットワーク技術課 課長
田中 正樹 さん（写真、中央）
シリコンスタジオ株式会社
技術本部 オンライン技術部 リードソフトウェアエンジニア
岡田 正之 さん（写真、左）
シリコンスタジオ株式会社
技術本部 オンライン開発部 テクニカルディレクター
関谷 卓 さん（写真、右）
■ 利用している Google Cloud Platform サービス
Google Compute Engine
、
Cloud Storage
、
Cloud Load Balancing
■
株式会社ディンプス
大手ゲーム会社から独立した開発者たちによって、2000 年に設立。業務用および家庭用コンピュータ ゲームの研究、開発を行う。株主には、国内の著名なゲーム パブリッシャーが名を連ね、さまざまなプラットフォームに向けた、ゲーム、マルチメディア コンテンツの開発を手がける。
独自性を持ち、かつコスト効果の高いサービス実現に必須だったクラウド移行
株式会社バンダイナムコエンターテインメントが販売する、全世界規模での大ヒットゲーム「ドラゴンボール ゼノバース」。2015 年に発売され、悟空などの人気キャラクターと一緒に戦える、ファンにはたまらないゲームです。その続編である「ドラゴンボール ゼノバース 2」は期待の新作で、もちろんオンライン対応。ディンプスは、この両方を開発した実力派の制作会社で、「ゼノバース ２」のオンラインサービスのバックエンドに Google が提供する「Google Cloud Platform」を全面採用しました。
実は、同社は 2000 年の創業当時から、自社が開発するゲームのオンライン対応に着手。2005 年には本格的なオンライン対戦ゲームを運営開始しました。特筆すべきは、このゲームに向けて、独自のオンラインゲーム用サービスを可能にするため、自社にサーバーを設置し他のオンラインゲームとの差別化を図っていたことです。
ディンプスの田中さんは「2005 年当時はクラウドサービスが今ほど一般的ではなかったので、米国から巨大なサーバーを輸入し、オンプレミスで運用をしていました。初期導入や運用のコストも、とても大きかったですね」と当時を振り返ります。
このようにディンプスは自社でオンライン対応のノウハウを蓄積しつつ、一方で、ネットワークとバックエンドシステムに関しては、より高い技術力を持つパートナーとの協力体制を模索していました。そんな中、業界内で定評があったシリコンスタジオ株式会社とパートナーシップを締結。1 作目の「ドラゴンボール ゼノバース」では、オンライン対応に関わる開発や運用について、両社が協力してサービスの提供を行いました。
シリコンスタジオは、バックエンド領域での技術力に加え、自社で運営するデータセンターを持っています。これはネットワークサービスを提供するうえで、コスト面、運用面での大きなメリットです。では、両社が最新作である「ドラゴンボール ゼノバース 2」のバックエンドを、既存のデータセンターを使わず全面的に Google Cloud Platform へと移行した理由は何だったのでしょうか。
それは「コスト」に関する「柔軟性」と圧倒的な「優位性」だったといいます。
オンラインゲームのバックエンドに要求される適正なスペックは、ゲームの仕様やリアルタイムのプレイヤー数、ビジネス戦略などによって常に複雑に変化します。この変化に、合理的なコストで柔軟に対応できるバックエンドを確保するには「オンプレミスからクラウドへの移行は必然だった」と田中さんはいいます。
またシリコンスタジオでは、オンラインゲームの分野において、こうしたニーズが高まっていくことを視野に、2014 年ごろからクラウドサービスの検証や比較検討を始めていました。「ドラゴンボール ゼノバース」は、基本的にはオンプレミスのシステムで運用しつつ、一部を Google Cloud Platform を利用する形で、クラウドの運用実績を積んでいました。クラウドサービスの中から、Google Cloud Platform を選択した理由として、シリコンスタジオの岡田さんは圧倒的な「コスト」の優位性を挙げます。
「これまでオンプレミスでシステムを運用していた実績がありますので、それと同等の性能を IaaS 上のインスタンスで実現できることを基準に、各種クラウドの比較検討を進めました。Google Cloud Platform は、他の著名なサービスと比較して、料金が半額以下になる見込みがあり、それが選択理由のひとつでした。」
また課金体系が、他のサービスと比べてわかりやすい点にも魅力を感じているそうです。
シリコンスタジオの関谷さんは「他のクラウドサービスの場合、ある程度の性能を確実に確保しようとすると、月単位のリザーブ契約となり、コストが増える傾向にあります。一方、Google Cloud Platform では、そうした契約が不要で、かつ使ったリソースの量が増えれば、その量に応じて自動的にボリュームディスカウントがかかる仕組みになっています。われわれの場合には、この仕組みのほうが使い勝手が良いのです」と話します。
コスト面に加え「信頼性」「安定性」も実証－活用範囲の拡大を視野に
運用を開始してからは、コスト面のメリット以外に Google Cloud Platform の特長のひとつである「ライブ マイグレーション」にも大きなメリットを感じているそうです。ライブ マイグレーションは、IaaS 上のインスタンスを止めることなく、Google 側で自動的にインフラ部分のメンテナンスや機能強化を行う仕組みです。
「無停止でのライブ マイグレーションは、一般消費者向けにサービスを提供しているわれわれの立場からは、非常にありがたいです。」（岡田さん）
「加えてライブ マイグレーションは、インフラ部分の性能強化も自動的に行われる点が興味深いですね。われわれの場合、検討段階から現在に至るまで、継続的にオンプレミスと Google Cloud Platform 上のインスタンスとの間で性能比較を行っています。検討を開始した当時は『性能面でクラウドがオンプレミスの物理環境を超えることはない』と考えていたのですが、現時点で既にクラウドのほうがオンプレミスよりも高いパフォーマンスを出せるようになっています。」（関谷さん）
インフラの性能が、Google によって継続的に改善されることは、ユーザーにさまざまなメリットをもたらします。たとえば、稼働中のインスタンスに対し予想外のアクセスが集中しても、ライブ マイグレーションによってインフラ側の性能が上がっていれば、そのままでも十分に対応できる可能性が高まります。逆に、従来と同等のパフォーマンスを得るために必要なインスタンスのコストは相対的に下がっていくため、ユーザーが適宜調整を行えば、ランニングコストを圧縮することも可能です。
「ドラゴンボール ゼノバース 2」での Google Cloud Platform 全面採用を経て、両社では、今後さらにその活用範囲を拡大していくことも検討しているそうです。
© バードスタジオ/集英社・フジテレビ・東映アニメーション © BANDAI NAMCO Entertainment Inc.
「ゼノバース 2 では、オンプレミスで動かしていた前作のシステムを、そのまますべてクラウドに移行することを目標に構築しました。移行という部分は大成功でしたが、これだけではまだ Google Cloud Platform の本当の力を引き出せていないと思っています。ワールドワイドに展開するタイトルにおいては、コンテンツ配信を高速化するためにエッジロケーション（世界各地に設置された Google 専用ネットワークへの接続ポイント）を効果的に使えないかとか、プレイヤーデータ管理の仕組みとして分散データベースである『Cloud Spanner』を活用できないかなど、今後のタイトル開発では検討していきたいです。」（田中さん）
「Google Cloud Platform のマネージドサービスや、 PaaS である『App Engine』などについて、既に機能検証や、実案件への導入を始めつつあります。最新の機能についても、随時、検証や評価を進めながら、ニーズに応じて最適な部分に Google の技術を取り入れたいと思っています。さらに使い勝手の良いサービスに進化させていってほしいですね。」（関谷さん）
両社では、これまでの運用を通じ、技術的な問題に対する Google の対応にも信頼を感じているとのこと。加えて今後の活用レベルの向上にも期待に応えてくれるという感触を得ているようです。
ドラゴンボール ゼノバース 2
発売元:株式会社バンダイナムコ エンターテインメント
株式会社ディンプスの導入事例
PDF
はこちらをご覧ください。
GCP のその他の導入事例は
こちら
をご覧ください。
内部負荷分散によるスケーラブルなプライベート サービスの構築
2016年12月22日木曜日
クラウド ロード バランサは、復元性と弾力性の高いサービスを構築するうえで重要な要素です。ロード バランサにより、インフラストラクチャについてさほど考慮せずに、アプリケーションにもっと集中できるようになります。
もっとも、アプリケーション自体も進化しており、高度な分散と複数の層で構成されます。そして、その多くはマイクロサービスとして提供されています。
私たち Google が先ごろ
内部負荷分散（Internal Load Balancing）
を GA（一般公開）リリースしたのも、ロード バランサに関するこうした状況が背景にあります。
Google Cloud Load Balancing
のフルマネージド サービスである内部負荷分散は、ロード バランサをインターネットにさらすことなく、内部クライアント インスタンスのためのスケーラブルで可用性の高い内部サービスの構築を可能にします。
この 1 年間、私たちは
グローバル負荷分散
と
ネットワーク負荷分散
について、GCP NEXT や NSDI カンファレンスの場で詳しく説明してきました。最近の例で言えば、Google Cloud Platform（GCP）のお客様である Niantic が、非常に人気の高い Pokemon GO を拡張する際に、Google Container Engine やその他の GCP 技術と共に
HTTP（S）負荷分散
を使用しています。
内部負荷分散は現在、Google のクラウド ロード バランサ の 1 つとして、プライベート サービスが必要とする拡張性、パフォーマンス、可用性を提供しています。
内部負荷分散のアーキテクチャ
Google Cloud Load Balancing のソリューションをお客様にお見せすると、「ロード バランサはどこ？」という質問をよく受けます。そして、「1 秒間にサポートできる接続数は？」と聞かれます。
HTTP（S）負荷分散やネットワーク負荷分散と同様に、内部負荷分散はハードウェア アプライアンスでもインスタンス ベースのソリューションでもありません。これはソフトウェア定義型のロード バランサであり、Google のネットワーク仮想化スタックである
Andromeda
を介して提供されます。
内部ロード バランサは仮想ネットワーク上で必要な場所であればどこにでも存在しますが、ネットワークを停滞させるポイントとなることは決してありません。こうしたアーキテクチャのおかげで、内部負荷分散ではサービスが必要とする接続数を最大限までサポートできるのです。内部負荷分散の場合はクライアントとバックエンドのインスタンス間にロード バランサが存在しないので、1 秒間に多くの接続数をサポートできます。
内部負荷分散の機能
内部負荷分散を使用すると、プライベート サービスを実行するバックエンド間で内部クライアント トラフィックを分散できます。たとえば下図の場合、サブネット 1 のクライアント インスタンス（192.168.1.1）が内部負荷分散 IP（10.240.0.200）にトラフィックを送り、サブネット 2 のバックエンド インスタンス（10.240.0.2）に負荷分散されます。
内部負荷分散により、次のことが可能になります。
仮想ネットワークの内部からプライベート
RFC 1918
アドレスを負荷分散 IP に設定できます。
地域内の複数のゾーンにあるインスタンスにまたがる形で負荷分散できます。
クライアントのトラフィックが常に同じバックエンド インスタンスに負荷分散されるように、セッション アフィニティを設定できます。
TCP、SSL（TLS）、HTTP や HTTPS に対する高品質なヘルス チェックを設定できます。
プレウォーミングなしにバックエンド インスタンスを瞬時にスケーリングできます。
フルマネージド負荷分散サービスの利点をすべて享受できます。ロード バランサの可用性や、ロード バランサがサービス停止の原因となることを心配する必要はありません。
内部負荷分散の設定
内部負荷分散は、REST API や gcloud コマンド、Google Cloud Console による設定が可能です。設定の詳細は
こちら
をクリックしてください。
内部負荷分散の事例
内部負荷分散は、GCP のプライベート仮想ネットワークにおいてプライベート RFC 1918 負荷分散を実現します。ここでは、同サービスの興味深い事例を紹介します。
1. 内部サービスのスケーリング
典型的なマイクロサービス アーキテクチャの場合、デプロイした複数のインスタンスにまたがる形でトラフィックを分散させることで、各サービスに可用性と拡張性を提供します。内部負荷分散を使えばこれが実現できるほか、インスタンスを自動スケーリングしてサービスへのトラフィック増加にも対応できます。
2. GCP 上に多層アプリケーションを構築
内部負荷分散は多層アプリケーションを構築するうえで重要なコンポーネントとなります。
たとえば、ウェブ層のインスタンス全体にわたって、グローバルなウェブ フロントエンドのロード バランサとして HTTP（S）負荷分散をデプロイすることが可能です。そのうえで、（下図で内部層として示された）アプリケーション サーバーのインスタンスを地域内の内部ロード バランサの背後にデプロイし、そこにウェブ層のインスタンスからリクエストを送ることができます。
3. 仮想アプライアンスに高可用性と拡張性を提供
従来、ハードウェア アプライアンスの高可用性（HA）はアクティブ - スタンバイやアクティブ - アクティブといった形式でモデル化されており、2 つ（もしくはそれ以上）のデバイスがレイヤ 2 ネットワークの専用の物理的同期リンクを介してハート ビート通信を行い、ステート情報をやり取りすることによって実現していました。
このようなモデルは、ファイアウォールといったクラウド ベースの仮想アプライアンスでは機能しません。というのも、物理ハードウェアにアクセスできないからです。パブリック クラウド仮想ネットワークは通常レイヤ 3 ネットワークであり、レイヤ 2 ベースの高可用性を享受することはできません。
さらに重要なのは、クラウド アプリケーションが堅牢性などを高めるために共有状態をアプリケーションの外部に保管することです。そのため、従来のセッション同期状態を取り除くことができます。
こうした点をすべて勘案すると、GCP でうまく機能する高可用性モデルを構築するには、内部負荷分散の背後に仮想アプライアンス インスタンスを導入することです。内部負荷分散は、仮想アプライアンス インスタンスのヘルス チェックを実行したうえで、正常なインスタンス間でトラフィックを分散し、トラフィックに基づいてインスタンスの数を増減します。
内部負荷分散の今後
近いうちに、いくつかの機能が内部負荷分散に追加される予定です。たとえば、DNS によるサービス ディスカバリ、VPN を介したオンプレミス クライアントから内部ロード バランサの背後にあるバックエンドへのトラフィックの負荷分散、
地域インスタンス グループ
のサポートなどです。
まずは内部負荷分散を試してみてください。
チュートリアル
から始めて、
ドキュメント
をお読みになり、GCP 上でデプロイするのです。皆さんからの
フィードバック
をお待ちしています。
* この投稿は米国時間 12 月 15 日、Cloud Networking の Product Manager である Prajakta Joshi によって投稿されたもの（投稿は
こちら
）の抄訳です。
- Posted by Prajakta Joshi, Product Manager, Cloud Networking
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
