Google Cloud Platform Japan Blog
最新情報や使い方、チュートリアル、国内外の事例やイベントについてお伝えします。
株式会社グルーヴノーツの導入事例(前半):モバイルのための次世代のクラウド プラットフォームを Google Cloud Platform で
2015年3月19日木曜日
(写真左: 株式会社グルーヴノーツ 代表取締役会長の佐々木 久美子さん、写真右: 同じく代表取締役社長の最首 英裕さん)
スマートフォンのゲーム市場は既に家庭用ゲーム機を超えていると言われほど大きくなり、その中でも人気のあるゲームのバックエンドのトランザクションはどれほどのものなのか、実際に運用しないことには ”想像もできないほど” なのでしょう。
こういう状況がゲームだけなのかというと、例えば自動車におけるテレマティクス分野で、数百万台の車から走行データが送られてくる状況や、年内にもより身近になってくるであろう IoT 分野でセンシング データが大量送信される状況が思い浮かびます。共通しているのは、モバイル、頻繁なアクセス、そして大量のデータ。
このような状況に当てはまる事業を始めようとしたとき、長い時間とコストを費やしバックエンド インフラストラクチャーを構築するよりも、それがウェアラブル デバイスならその利用体験に、なんらかのセンサーであるならその状況を伝えるアプリケーションに注力したいでしょうし、運用に費やす時間を事業の成長のために使いたいと考えるのではないでしょうか?
株式会社グルーヴノーツ
の
MAGELLAN
は、Google Cloud Platform を使い構築され、まさにその問題を解決するクラウド プラットフォームとして、昨年末に公開されました。その MAGELLAN について、代表取締役会長の佐々木 久美子さん、代表取締役社長の最首 英裕さんに話を聞きました。その様子を、前半、後半と 2 回に分けてお伝えします。
新しい時代に適用したコンピューター アーキテクチャーとしての MAGELLAN
2 人ともそれぞれ会社を経営してきた中で、グルーヴノーツを設立されたわけですが、設立にいたった背景と事業内容を教えてください。
最首さん:
僕らが、分散系技術を使って企業システムに取り組んでいた時、佐々木は福岡でゲーム会社を作っていて、僕のチームと佐々木のチームを一緒にすると面白いことができると思ったんですよ。なぜかというと、モバイル ゲームには未来の(サーバサイド)コンピューティングの形があるように思えたんです。モバイル デバイスが前提で、四六時中使う大勢の人から大量のアクセスがあり、そのレスポンスが要求される。その裏側では高速に分析をしたり、頻繁な機能の更新をしていく。それを見てると、これからはきっとパソコンも使われなくなって、未来の形がどんどん変わっていくだろうと。それを先取りしていく必要があると強く思って、ゲームのバックエンドに特化して事業をはじめました。
それからオンライン ゲームのバックエンドとなるクラウドサービスを提供していると、その安定したデータ収集の仕組みと、それを高速に処理するという仕組は、センサーデータや POS データといった大量のデータが絶え間なく集まるような、ハードウェアを作っている企業や、自動車向けサービスを行う企業、それに流通、特に物流データを扱う企業の用途にも共通性があって、モバイルデバイスであり、アクセス数が非常多い世界なので、製造業とか IoT 系の会社からの問い合わせが非常に多く、そういった企業にもサービスを提供しています。
MAGELLAN も、そのようなオンライン ゲームの経験から生まれたものなのですか?
最首さん:
そうですね。いろいろな案件をやるなかで、一時期は 1 日ごとに数万人ずつユーザーが増えるサービスをやったりもしました。そこで知ったのが、これまでやってきた金融系や製造業の、いわゆる業務システムレベルでの大規模システム技術では、全く通用しないということ。そのくらいの凄まじいことが起きていることを実感をして、こういうことが未来にどんどん起きていくのだとするならば、たぶん今までのコンピューター アーキテクチャは全然通用しなくなる。それならば、新しい時代に適用した形を作っていこうと試行錯誤して、そこでもいろんな問題が出てきて、それを乗り越えるためにはもっといろいろなことを考えて、そういう繰り返しを経験したことからできあがってのが MAGELLAN です。
パートナーとしての Google
その MAGELLAN を動かす環境として、Google Cloud Platform を選んでいただきました。また、最首さんは Blog にもクラウド ベンダーの違いについて書かれていましたが、Google Cloud Platform を選択した理由がなんであったのか教えてください。
最首さん:
根っこにあるのは、ゲームの凄まじいトランザクションを従来の発想で乗り越えるのがとても大変だったということ。それは普通に Web サーバや、アプリケーションサーバ、DB サーバなどを置いていくだけでは済まない、もっと高いレベルでの対応が必要だったんです。もちろん Google 以外のクラウド ベンダーを知らないわけじゃないですけど、ぼくらが直面していたことからすると、違和感を感じざるを得なかった。そんな中、Google の人達と話をすると、考えているのは安いコンピューターとか性能の良いサーバとかそういう話じゃなくて、何か本質的なことを考えている気がして…
それが Google と同じインフラストラクチャーで動かせるということ、最首さんたちの経験が MAGELLAN に還元されたように、Google のサービス提供者としての経験がそのまま Google Cloud Platform に還元されているということなのかもしれません。
最首さん:
だから組む相手としてふさわしく、やっぱり何をやろうとしているかを聞いておく、知っておくことで凄い勉強になって、新しい性能の良いサーバーが出ました、値段半分になりましたとかだと、あまり勉強する必要はないわけですよ。あ、凄いですね、というだけなんですけど、Google はもっと違うことを考えているので、そこは僕にとってもの凄く刺激的だし、面白いですね。
例えば、Hadoop で作ったプログラム。クロス集計的な機能を高速にしましたという類のプログラムを BigQuery に置き換えたら、とても簡単に置き換わってしまった。しかも、速度が桁違いに速く、運用コストは殆どかからない。サーバのセットアップをする必要もない。データを投入してコマンドを打つと、知らないあいだに数千台のサーバが勝手に動いて、何十億件のデータ処理をするのに 3 秒くらいで答えが帰ってきて、値段が 30 円ですと。集計を組み合わせるというレベルだったら(締め処理のようなこと)BigQuery が Hadoop の代わりになると気がついたときに半日くらい考えこみましたね、これなんなんだと(笑)。これまで結構頑張ってやってきたことが、ほんの僅かな時間で構築できて、コストはお小遣い程度。あまりにもドラスティックすぎて、みんな怖くて口にできないんじゃないかと思ってしまった。
しかもクエリーを書くのは簡単なので、僕らがプログラムを作るのではなくて、お客様に開発してもらっているんです。やってくださいって説明したらできてるんですよ。しかも日常的にプログラム組んでない人たちじゃないんです。でも BigQuery でバッチ作って流している。そういうことが目の前で起きているということを正確に理解して、受け入れないといけない。
大量のトランザクション処理は WhatsApp を参考に
あらためて MAGELLAN の話を聞かせていただきたのですが、Google App Engine のようにアプリケーションさえ作れば、あとは MAGELLAN がスケーリングだとか運用に必要なことをやってくれると理解しています。
そうですね。今の形は App Engine に似たところがあるけど Ruby on Rails で開発できる、これから他の言語プラットフォームも出していきますが、App Engine だけど Node.js で書ける、というような形です。しかも App Engine は App Engine アプリケーションを書く流儀がありますが、流儀がないのですよね。普通の Web アプリケーションとして書くとそのまま動きます、という形です。プロトコルも HTTP じゃなくて MQTT でも動いてしまう。HTTP じゃないのに何故か Web アプリケーションのように書ける。これって IoT では結構重要なことです。なぜかというと、デバイスは PC のように HTTP のようなリッチなプロトコルを自由に使えない状況にあるし、メーカーや業界独自のプロトコルだとかの存在もありますし、メモリサイズの問題や消費電力など、つまりデバイスの価格にも影響してきます。そのため MAGELLAN では通信プロトコルには依存しないような作りにしました。このおかげで、独自プロトコルを組込んでも、サーバーロジックはそのまま行けるであるとか、そういうことを考えられるようになりました。
先ほど話にあった、大量のトランザクション処理を MAGELLAN ではどう処理しているのですか?
MAGELLAN の中にトランザクション ルーターというものがあって、そこで処理しています。そこで大量のトランザクション処理をいかにこなすかというときに参考にしたのが
WhatsApp
。なぜ彼らはあれだけの処理を非常に少ないサーバーの台数で処理できるのか、それを調べたときに、Erlang OTP という電話交換機などの制御のための仕組みがあり、それがとても大きな効果を発揮するということを知って、じゃあその構造を見習って実装していこうと。おかげで非常に高性能なエンジンが完成しました。
最もふさわしい形として選んだ Docker
MAGELLAN で特徴的なのは Docker コンテナを使われていることだと思います。まだ実サービスとして使っているところはあまり多くはありませんが、今回 Docker を選択したというのはどういう理由からだったのですか?
最首さん:
開発に自由度を与えるにはどうしたらいいか、というときに、開発の自由度を下げて、開発流儀を縛るとやりやすくはなるんです。App Engine のように。でも自由に書けるように、いろんなライブラリを使えるようにしようとすると、プログラムソースを上げるというよりは、環境をあげられなければ、うまくデプロイできない。では、環境をどうやってあげるのか、というときに、Docker イメージを作ってあげれば、環境ごとあがるわけです。そういう形がふさわしいと使ったので、いち早く使ったつもりもなく、ただいろんな選択肢の中でこれが一番ふさわしいと選択しただけで、その準備している間に世の中が Docker ブームになってきて、あれあれ、みたいな(笑)
Google は Kubernetes をリリースしていますが、そういうものは使わずにクラスタリングマネージメントを?
最首さん:
そうですね。Kubernetes がオープンソースでリリースされたのは、MAGELLAN が結構できてからで、今後だんだん融合していくのかと思います。
ユーザーにわかりやすい仕組みとしてのコンテナ
最首さんは、イーシー・ワン時代にコンポーネントという形で機能の部品化を進めらていました。コンテナも大きな単位の部品化という考え方もできるかと思います。コンテナについてどうお考えですか?
最首さん:
プログラム モジュールをコンポーネント化し、再利用性を高めていくということは、うまく言った部分もあったかもしれませんが、考える粒度が小さすぎたのは問題だったのかなと。それにロジックがビューと切り離しにくく、結局うまく再利用ということろまでは踏み込めませんでした。その後出てきた流れ、SOA や、Web API、RESTful インターフェイスだとかのように、機能を比較的大きな単位で分割し、疎結合にして再利用を図るという流れは、うまくいったとは思うのですが、あの当時、やはりネットワークがボトルネックになりやすく、通信に冗長性を持たせることはなかなかできなかった。とはいえ今や、ある企業で使っている機能や、あるサービスで使っている機能を API 化することによって、機能分割して再利用性を高めるということは、当たり前のようになってきています。もっと時間をかけて考えていくべきテーマだったんでしょうね。
コンテナに関していうなら、VM で頑張る必要がなかった、ハードウェアレベルまで完全にエミュレーションする必要はなかったということだと思います。結局上位層で使っている部分というのはハードウェア I/O しているわけでもないし、もっと抽象化されているので、コンテナのような発想で十分だといえば確かにそうだと。昔 Google は VM を使ってないと聞いたんですけど、それは当たってたたわけですよね。全部ハードでやってるらしいと、それは嘘だったわけですね(笑)。
コンテナ時代の開発の仕方というのは、作っている側からするとまた違ったパラダイムなのかと思うのですが、実際に利用していていかがですか?
最首さん:
そうですね、デプロイし易いというか、どうですか?開発責任者として
佐々木さん: 自分たちがどうかということより、ユーザーさんが何か作るというときに、使わせやすいかというのはありますね。ここだけ作ればいいという説明ができて、ユーザーさんでも自分が開発したいもののためには、ここだけやればいいというのがわかるので、今までインフラよりのことまで全部やらなければいけなかったことが、コンテナによって上辺だけでよくなっている、作るアプリケーションだけ見ていればよくなるというユーザー視点では、私たちがサービス提供する上では凄くよかった。
最首さん:
ワーカーを開発するとき MAGELLAN に上げる前に、その Docker イメージのままローカルで動かすことができるんですよ。Web インターフェイスをエミュレートしているので、とりあえず Web インターフェイスのままテストして、これでOKとなってデプロイすると全然違うインターフェイスで動く。
佐々木さん:
技術もそうですけど、私はどちらかというとユーザーさんの使い易さの方が重要だと思っていて、そこが吸収される技術であれば、どちらかというとなんでもいいと言ってしまうタイプなんですけど、それが Docker だと本当にわかりやすい。単純にもう、そこが今は一番。
結局運用がどれだけ簡単になるか、というところですよね。
佐々木さん:
結局は技術がどうかよりも、運用のしやすさをお客様も求めるので、最初の開発で完了じゃなくて、その後継続していくものなので、ゲームもそうだし、一般のシステムもそうですけど、やっぱり継続した運用を考えたときには、メンテナンスのしやすさ。そのための人材を確保するよりは、Docker 部分だけ考えていられた方がいいですよね。
Google App Engine を使っているお客様も同じことを話していて、とりあえずデプロイしておけば、あとは運用する必要もなく、アプリケーションを良くすることだけを考えられると仰っています。
最首さん:
例えば、オンライン ゲームだと、来週からテレビコマーシャルを打ちますとなると、確実にユーザーが増えるのが見えていて、その増設規模が 100 台とか 200 台とか三桁単位で増設していったりとかで大変なんですよ。環境作って、最終的に性能とかも確認してリリースしてとか、もうそれだけで 10 時間、20 時間がまたたく間に過ぎていく。台数が多くなると、面倒見なきゃいけないことの負担はもの凄く多くなってきますし。また、サービスを止めないで機能を変えたり、あとは 例えば Apple に iOS のアプリを審査に出すと、そのために審査用のサーバを建てないといけない、でも終わったら本番に切り替えないといけないとか、そういう運用上の面倒くささ、というのは今までの企業システムでは考えられないレベルで出てくる。そういうことをいかに楽にできるかというのを MAGELLAN ではかなり考えて作っていますね。それが大変だと思ってない人には、なかなかわかりにくいかもしれませんが。
Google Cloud Platform でもそうですが、品質であったり運用を考慮した機能は、それができたストーリーに共感できる人でないと、使ってもらう前に伝えることは難しいですね。
最首さん:そうですね。
(
後半
に続く。)
- Posted by Google Cloud Platform Japan Team
■ Google Cloud Platform のその他の
導入事例はこちら
から
0 件のコメント :
コメントを投稿
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
0 件のコメント :
コメントを投稿