年の瀬も押し迫り、寒さも身にしみてきますね。
12 日の六本木もそんな寒い夜でしたが、200 名以上もの GCP ユーザーが集まって 29 回目の gcp ja night が、ほっこりと開催されました。場所は、株式会社フリークアウトさんのヒルズガレージをお借りしています。

ピザとビールを楽しみながら、4 つのセッション(各 30 分)と 2 つのトーク(各 15 分)が行われました。その模様を、簡単なレポートと、Hangouts on Air で中継されたビデオの録画で一緒に振り返りましょう。

* 各セッションの内容は発表者個人の意見としての発言であり、発表者の所属する企業・組織と関係するものではありません。

トレタの BigQuery / Google Apps Script 活用術

GCP に含まれるサービスではありませんが、今回参加された皆さんは Google Apps Script (GAS) にすごく興味を持たれたのではないですか?
@masuidrive さんによるセッションは、会社で導入している Slack を勤怠管理にも使ってしまおうと、GAS で Bot を作り Google スプレッドシートに勤怠データが保存される「みやもとさん」の開発過程を紹介してくれました。「おはようございます」「お疲れさまでした」とチャットに書けば出退勤として記録される、そのアイデアも面白いのですが、なにより時間をかけずに GAS で作ってしまう発想に驚嘆します。
後半は、BigQuery も同様に GAS と Google スプレッドシートで制御するという内容です。サービスの利用状況を BigQuery で解析し、それを Google スプレッドシートに保存しながら、Slack にも書き込む、これを GAS で制御しています。BigQuery のクエリーなどの設定も Google スプレッドシートに記載して、誰にでも編集し易いようにしているそうです。

GAS を使うことで、非開発者の人でも Google Apps の使い慣れた UI を利用しながら、BigQuery のような Web のいろいろなサービスを組み合わせて使える仕組みを容易に開発でき、Google Apps の共有機能を使えば、誰がどの情報を編集・閲覧できるのかの制御も容易です。さらに多くのワークフローを簡単にできそうですね。

Kubernetesの機能とデモ、開発体制について

Kubernetes の読み方わかります?キュゥべえ!?
詳しくはビデオで聞いてください。
@yugui さんは、Kubernetes の機能やアーキテクチャ、そして実際にデモを動作させながら、時間の限り詳細に説明してくれました。Docker コンテナのオーケストレーションという課題、それに対し現在様々なプロジェクトが現れ、その中の何が決定的なプロジェクトとなるかはわからないとしながら、Kubernetes だけでなく、FleetMesos などのプロジェクトの良さについても Kubernetes と比較して教えてくれています。
その中で Kubernetes は、特別なテクノロジーではなく、比較的あたりまえのテクノロジーが使われており、それは Google のこれまでの経験から積み重ねてできているということ。そして開発体制も Google 以外の人が参加しながら速いスピードで発展していき、自らに固執することなく、調査を重ね正しい選択のできる体制である、それ故に Fluentd や Kibana などの他の優れたプロジェクトを利用するに至っているとのことです。

dotCloud の内部プロジェクトとして生まれた Docker。dotCloud のサービスは cloudControl へと移り、今では GCP 上で運用されていることを以前お伝えしました。一方で Docker は急速に普及し、そのジョブスケジューラーとして生まれた Kubernetes は、Google Container Engine (GKE) に組み込まれ GCP の 1 つのサービスとなりました。こういった変遷も面白いですね。

さて、ここまでで前半が終わりです。ビールとピザの時間を挟んで後半が始まります。
会場には、以前事例として紹介させていただいた、ゲーム攻略完全図鑑の千葉さんもいらしていました。

ログだけじゃない!BigQuery使おうぜ!とGCEも使えるよ

株式会社セブン&アイ・ネットメディア オムニチャネル推進事業部 中村悟さん、若林正裕さんによる、BigQuery を実際に大規模な業務で利用している経験を、楽しく聞かせてくれます。この内容だけは実際に会場に来た人だけの特権として非公開です。会場は興味と笑いに溢れ、とても濃い内容を聞かせてくれました。
トピックだけ紹介すると、Google Analytics Premium (GAP) と BigQuery の連携。GAP だけでは見えにくい部分が BigQuery で判明し、そして新しい仮設が成り立つということ。そして BigQuery の良い所、悪いところ、これからやりたいこと、やってほしいこと。

話の中で、@masuidrive さんと同様に、GAS との連動やデータの非正規化といった話題が出ました。BigQuery 実際に使っていく中で導かれたやり方として参考になるのではないでしょうか。

GCP最新動向まとめ

GCP の最近のアップデートについては既に紹介してきましたが、この半年だけでも、振り返ってみると GCP の変化と進化を実感します。
おなじみ @kazunori_279、Kaz さんです。個々の情報はビデオを見ていただくとして、一部だけ紹介します。
最大 680k IOPS にも達する Local SSD。この性能では、ディスクよりもむしろ CPU がボトルネックになってくるそうです。
先ほども Kubernetes での Fluentd の話がありましたが、Google Cloud Logging で採用された Fluentd は、それを契機に GCP のいろいろな部分で利用されることになりました。もちろんそれは純粋に技術的評価の上で。
新しく GCP の仲間に加わった Firebase の話では、先日の Google Cloud Platform Live のビデオを交え紹介してくれています。中核となっているのは Firebase Realtime Database、NoSQL の JSON Database ですが、そこに接続しているユーザーがリアルタイムにシンクする仕組みと、そのユーザーマネージメントから成り立ち、アプリケーションによっては、サーバサイドのコードを書くことも必要なくリアルタイムにコラボレーションするアプリケーションの開発が可能になります。
この他にも、Google Compute EngineAutoscaler、GKE、オンプレミスと Google とを接続できる Direct PeeringCarrier InterconnectVPN といったGoogle Cloud Networking、そして Managed VMs の話もありますので、是非ビデオをご覧ください。

それにしても、日本人エンジニアが生み出したテクノロジー Fluentd が、しっかりと評価された上でこのように利用されることは嬉しくなりますね。詳細は、Qiita に書かれている「Google、FluentdをKubernetesとCompute Engineの標準ログコレクタに採用」を読むとより良くわかります。
Firebase の話の中で出てきた Operational Transformation は、例えば Google Docs の共同編集のように、整合性の維持とコンカレンシー制御の技術です。Google Drive Realtime API でも使われていますが、Firepad での Firebase の実装も試してみることができます。そして、Firepad のページのデモで Firebase のリアルタイム性を確認できると同時に、GitHub のソースコードを読むと、フロントエンドのアプリケーションだけで、バックエンドのコードを書く必要がないということもわかります。
ここでは内容を記載していませんが、標準でネットワーク構成が可能な GCP に、Carrier Interconnect などで直接自社のネットワークを繋げられるようになり、Windows インスタンスを実行できるようになったこととあわせて、エンタープライズ システムのクラウドへの拡張が容易になったことも、大きな変化と言えるかもしれません。

Monitoring Kubernetes

ここからは 15 分間での発表となります。ところで、Kubernetes だけでなく kubelet や kubecfg は何と読むのでしょう?
@stanaka さんは、Kubernetes クラスタのモニタリングには、Minion とその中の Docker コンテナのステータスを知る必要があることや、Kubernetes には Grafana によるダッシュボードが用意されていますが、それが内部的にどのような要素が関連し構成されているのかについて話してくれます。詳しくは、Monitoring Kubernetes として話した内容をまとめられています。

GCPユーザーグループ「GCPUG」設立のお知らせと GCP Advent Calendarの話

本日最後の発表です。
@soundTricker318 さんから、Google Cloud Platform User Group、略して GCPUG 設立のお知らせです。ジーシーパグと読みます。今回の gcp ja night も 250 名定員のところ300 名以上の応募があり、もっと多くの人に、もっと参加しやすくなるようにと設立されました。ミッションはGCPの普及と、GCPの良いところを伸ばし、よくない所を改善するとのことです。誰でも支部を作成でき、GCPUG のロゴの改変も自由に行えます。まずは、GCPUG のサイトで参加登録をしましょう。東京での第1回は、来年 1 月 14 日を予定しているそうです。

印象に残る可愛いロゴですよね。
もう一つ、GCP Advent Calendar は、この日講演してくださった皆さんの中で参加されている方もいます。参考になることが、たくさんあると思いますよ。

さて、GCPUG も発足し、今回参加できなかった皆さん、場所的に参加できない皆さんも、これからはいろいろな場所で参加できるようになってくると思います。そう考えると、とても嬉しいです!

来年は、GCPUG の発展、そして皆さんが GCP で何を生みだすのか、とても楽しみにしています。

スマートフォンでゲームをする人なら「レギオンウォー」や「ダークサマナー」というタイトルの RPG で、実際に遊んだことがある人、あるいは今も熱中している人も多いのではないでしょうか。

開発している 株式会社エイチーム (Ateam Inc.) は、名古屋に本社があり、エンターテインメント事業として、多くのスマートフォンやタブレット向けデジタル コンテンツの企画と開発を手がけ、一方でライフスタイルサポート事業として日常生活に密着した比較サイトや情報サイトの企画から開発、運営を行っています。

今回エイチームから、スマートフォン向けの新感覚リアルタイム RPG「ユニゾンリーグ」がリリースされました。複数のプレイヤーでリアルタイムに行われる、ギルドバトルとクエストバトル、そしてユニゾンアタック、仲間とリアルタイムにプレイすることの面白さが凝縮された RPG ユニゾンリーグ、そのバックエンドは Google Cloud Platform (GCP) で構築されています。担当された、エンターテインメント事業本部 安藤 加奈子さんにお話をお聞きしました。


今回リリースされた、ユニゾンリーグで、Google Cloud Platform を初めて利用されるそうですが、何か理由があったのですか
きっかけは、GCP の東京で行われたカンファレンス(4 月 22 日にグランドハイアット 東京で行われた Google Cloud Platform セッション)に参加したときです。そこで GCP は GCP のために作られたサーバ環境ではなくて、Google が自社のサービスのために作った環境を一般にも公開する形ではじめたサービスということと、バックボーンにあるグローバルのネットワーク帯域がかなり確保されていて、レイテンシが最小限であるという内容を聞きました。ユニゾンリーグは、日本と世界中で配信する予定のゲームでしたので、グローバルでのリージョン間の通信が速いところが魅力に感じて、使うのは初めてでしたけど、GCP を導入してみようと思ったんです。

初めてとなると困ることもあったと思いますが、どうやって進めていったのですか
あまり困った記憶はないです(笑)。インスタンスの生成とかも、コンソールから視覚的に直感的に触れるのであまり苦労しなくて、インスタンス立ち上げてしまえば普通のサーバで、好きなようにさわれますから。使いやすいのは、しばらく使わないと思ったら、そのインスタンスを削除して、また使いたくなったらスナップショットから立ち上げる。その細かい単位での使い回しがし易いことです。

リリース当初は、多くのユーザーの皆さんが利用することを想定していますが、想定よりも足りなかったときに、即座に対応できる体制は必要だと話していた中で、 同じ設定を展開する準備だけしておけば、すぐに同じサーバを追加できることはすごく魅力的です。そこはすごく大きいところです。

Google Compute Engine (GCE) インスタンス使い、どのようなアーキテクチャでユニゾンリーグは構築されたのですか
一般的な Web の、HTTP サーバがあるような構成ではなくて、WebSockets を使っています。ゲームをしている端末からHTTPのようにリクエストのたびにアクセスしにくるのではなくて、ゲームログイン時にアクセスすると、そのままずっとソケットを繋いだままにします。Java のプロセスが常時動いていて、そこに端末から直接接続しにくる形です。あとは一般的なデータベースを使っているくらいです。ロードバランサも使っておらず、ゲームにログインする前に振り分け用のプロセスに事前に接続先を問い合わせ、プロキシというよりは繋ぎ先を指示するような形で動いています。

このようなアーキテクチャは経験的なものなのですか?
エイチームは、フィーチャーフォンの時代から、フィーチャーフォン向けの MMORPG を 5 作くらい出しています。その経験があるため独自のパケットを TCP でやりとりして、リアルタイムに処理していくことには、ある程度ノウハウがあります。スケーリングに関しては当時のゲームでは、そこまで複雑なことはやっていませんでしたが、スマホのゲームでは、PCの MMO のように1 つのワールドに何百人も入るようなことをすると、そもそも画面の描画も追いつきません。そのため、従来のMMOと同じようにワールドを分けていくことになるのですが、ユニゾンリーグではワールドをユーザーには見せず、内部的に、閉じられたロビー空間というワールドに近いものを作り、どのロビー(ワールド)に行けばまだ空きがあるか、ということを動的にマッチングする方法をとりました。わりと素直な進化系なのかなと思います。ユーザーの皆さんが自分のログインするワールドを選ぶのではなく、自動的にマッチングしていく方式です。

開発プロセスだとかを含め、開発はどのように進めていかれたのですか
何かのアジャイルな開発手法を使って、だとかということはしてないです。だいたい毎週タスクミーティングといって、大きなロードマップとしていつまでにこういう機能ができている、という大きなロードマップから一週間毎のタスクに落としこんでいきます。それをこれは誰々にと担当者を割り振って進めてます。

プロジェクトごとに、プロデューサー、ディレクター、プランナー、サーバ開発者であるとか、プロジェクトに係わる人の席を近くにして、コミュケーション取りやすい環境にしているので、わりと現場手動で進めているところがあります。開発も、そのプロジェクトにいる間は変わったりしないですけど、もともと、バックエンドばっかりとか、フロントエンドばっかりというエンジニアが殆どいなくて、プロジェクト変わるたびに変わったりしているんですよ。なので両方の知識をだいたいのメンバーが持っていて、コミュケーションは取りやすいです。

今後 GCP の中で使っていきたいサービスはありますか
BigQuery は早期に導入していこうと思っています。他のタイトルも含め、常に利用状況だとかの様々な指標を分析しているのですが、それをもっと効果的に分析していけるようにしたいです。



名古屋全体が見渡せるオフィスでは、スタッフの皆さんとすれ違うたびに声をかけてくれて、理念に掲げている「みんなで幸せになれる会社」を体現しているようでした。

新感覚のリアルタイム RPG ユニゾンリーグ、AndroidiOS で遊べます。
GCE も BigQueryも、GCP の全てを今なら 60 日間で $300 分のクレジットで試せます。


(ユニゾンリーグ公式ホームページはこちら: http://app.a-tm.co.jp/unisonleague/)

スマートフォンでゲームをする人なら「レギオンウォー」や「ダークサマナー」というタイトルの RPG で、実際に遊んだことがある人、あるいは今も熱中している人も多いのではないでしょうか。

開発している 株式会社エイチーム (Ateam Inc.) は、名古屋に本社があり、エンターテインメント事業として、多くのスマートフォンやタブレット向けデジタル コンテンツの企画と開発を手がけ、一方でライフスタイルサポート事業として日常生活に密着した比較サイトや情報サイトの企画から開発、運営を行っています。

今回エイチームから、スマートフォン向けの新感覚リアルタイム RPG「ユニゾンリーグ」がリリースされました。複数のプレイヤーでリアルタイムに行われる、ギルドバトルとクエストバトル、そしてユニゾンアタック、仲間とリアルタイムにプレイすることの面白さが凝縮された RPG ユニゾンリーグ、そのバックエンドは Google Cloud Platform (GCP) で構築されています。担当された、エンターテインメント事業本部 安藤 加奈子さんにお話をお聞きしました。


今回リリースされた、ユニゾンリーグで、Google Cloud Platform を初めて利用されるそうですが、何か理由があったのですか
きっかけは、GCP の東京で行われたカンファレンス(4 月 22 日にグランドハイアット 東京で行われた Google Cloud Platform セッション)に参加したときです。そこで GCP は GCP のために作られたサーバ環境ではなくて、Google が自社のサービスのために作った環境を一般にも公開する形ではじめたサービスということと、バックボーンにあるグローバルのネットワーク帯域がかなり確保されていて、レイテンシが最小限であるという内容を聞きました。ユニゾンリーグは、日本と世界中で配信する予定のゲームでしたので、グローバルでのリージョン間の通信が速いところが魅力に感じて、使うのは初めてでしたけど、GCP を導入してみようと思ったんです。

初めてとなると困ることもあったと思いますが、どうやって進めていったのですか
あまり困った記憶はないです(笑)。インスタンスの生成とかも、コンソールから視覚的に直感的に触れるのであまり苦労しなくて、インスタンス立ち上げてしまえば普通のサーバで、好きなようにさわれますから。使いやすいのは、しばらく使わないと思ったら、そのインスタンスを削除して、また使いたくなったらスナップショットから立ち上げる。その細かい単位での使い回しがし易いことです。

リリース当初は、多くのユーザーの皆さんが利用することを想定していますが、想定よりも足りなかったときに、即座に対応できる体制は必要だと話していた中で、 同じ設定を展開する準備だけしておけば、すぐに同じサーバを追加できることはすごく魅力的です。そこはすごく大きいところです。

Google Compute Engine (GCE) インスタンス使い、どのようなアーキテクチャでユニゾンリーグは構築されたのですか
一般的な Web の、HTTP サーバがあるような構成ではなくて、WebSockets を使っています。ゲームをしている端末からHTTPのようにリクエストのたびにアクセスしにくるのではなくて、ゲームログイン時にアクセスすると、そのままずっとソケットを繋いだままにします。Java のプロセスが常時動いていて、そこに端末から直接接続しにくる形です。あとは一般的なデータベースを使っているくらいです。ロードバランサも使っておらず、ゲームにログインする前に振り分け用のプロセスに事前に接続先を問い合わせ、プロキシというよりは繋ぎ先を指示するような形で動いています。

このようなアーキテクチャは経験的なものなのですか?
エイチームは、フィーチャーフォンの時代から、フィーチャーフォン向けの MMORPG を 5 作くらい出しています。その経験があるため独自のパケットを TCP でやりとりして、リアルタイムに処理していくことには、ある程度ノウハウがあります。スケーリングに関しては当時のゲームでは、そこまで複雑なことはやっていませんでしたが、スマホのゲームでは、PCの MMO のように1 つのワールドに何百人も入るようなことをすると、そもそも画面の描画も追いつきません。そのため、従来のMMOと同じようにワールドを分けていくことになるのですが、ユニゾンリーグではワールドをユーザーには見せず、内部的に、閉じられたロビー空間というワールドに近いものを作り、どのロビー(ワールド)に行けばまだ空きがあるか、ということを動的にマッチングする方法をとりました。わりと素直な進化系なのかなと思います。ユーザーの皆さんが自分のログインするワールドを選ぶのではなく、自動的にマッチングしていく方式です。

開発プロセスだとかを含め、開発はどのように進めていかれたのですか
何かのアジャイルな開発手法を使って、だとかということはしてないです。だいたい毎週タスクミーティングといって、大きなロードマップとしていつまでにこういう機能ができている、という大きなロードマップから一週間毎のタスクに落としこんでいきます。それをこれは誰々にと担当者を割り振って進めてます。

プロジェクトごとに、プロデューサー、ディレクター、プランナー、サーバ開発者であるとか、プロジェクトに係わる人の席を近くにして、コミュケーション取りやすい環境にしているので、わりと現場手動で進めているところがあります。開発も、そのプロジェクトにいる間は変わったりしないですけど、もともと、バックエンドばっかりとか、フロントエンドばっかりというエンジニアが殆どいなくて、プロジェクト変わるたびに変わったりしているんですよ。なので両方の知識をだいたいのメンバーが持っていて、コミュケーションは取りやすいです。

今後 GCP の中で使っていきたいサービスはありますか
BigQuery は早期に導入していこうと思っています。他のタイトルも含め、常に利用状況だとかの様々な指標を分析しているのですが、それをもっと効果的に分析していけるようにしたいです。



名古屋全体が見渡せるオフィスでは、スタッフの皆さんとすれ違うたびに声をかけてくれて、理念に掲げている「みんなで幸せになれる会社」を体現しているようでした。

新感覚のリアルタイム RPG ユニゾンリーグ、AndroidiOS で遊べます。
GCE も BigQueryも、GCP の全てを今なら 60 日間で $300 分のクレジットで試せます。


(ユニゾンリーグ公式ホームページはこちら: http://app.a-tm.co.jp/unisonleague/)

調査した読み書き比のなかでも、このグラフで示す TPS の 80 % は 50% のクライアント(10 ノード)で達成できています。さらにクライアントを追加してもスループットの向上はごく僅かでした。

ディスクの IOPS は、サイズに依存します。この実験では、高 IOPS を確保するために 500 GB 非 SSD の永続化ディスクを使い、ディスクがボトルネックにならないようにしています。より大きなクラスターには 500 GB は余計でありコストを考えて減らしても構いません。今回記録した高パフォーマンスには、さらに高い IOPS を得られる SSD 永続化ディスクを使う必要さえありませんでした。

異なる読み書き比での一貫した低いレイテンシー(サーバー: 10 ノード, クライアント: 20 ノード)
100% の読み込み負荷状態で、16ms 以上かかったのは全体の 3.5% にとどまり、4ms 以上かかったのも 20% 未満でした。Aerpspike での読み込みはクライアントから 1 ホップ(ネットワークの往復)であるためこのレイテンシーを達成できました。2 往復必要な書き込みでさえ、負荷 100% の時 32ms 以上かかったのは 16% の書き込みにとどまりました。Aerospike を動作させているノードでは、8 つある CPU コアの 7 つを使い動作させています。コアをひとつアイドルにさせておくのはレイテンシーのためです。全てのコアが busy 状態であるなら、ネットワークのレイテンシーは上昇してしまいますから (レイテンシーは、サーバーサイドでの記録です)。

読み書きともに、右肩上がりのスケーラビリティ
このグラフでは、100% の読み込みと100 % の書き込みそれぞれで、リニアにスケールしていく状況を示していますが、読み書きの負荷が変わっても同様だと考えられます。読み込みでは、サーバーとクライアントの比率は 1:2 としました。6 つのノードからなるクラスターに対して 12 クライアントという形です。書き込みでは、1:1 の構成としています。書き込み時の低いスループットではこれで十分だからです。

読み書きのデータ アクセスが混在する新世代のアプリケーションは、インターネットの中でウェブサイトやモバイル アプリでユーザーの動きを感知し応答する必要があります。このようなアプリケーションでは、クリックやスワイプ毎にデータを書き込み、判断、記録、応答をリアルタイムを行う必要があるのです。

今回の GCE で実行する Aerospike は、読み書きの両方で高スループットと一貫して低いレイテンシーが要件となるアプリケーションの例になったのではないでしょうか。たったの 50 サーバーで秒間 100 万回の書き込みを処理し、これまでにない費用対効果も備えています。皆さんもこのステップに添って実際に確かめてください、そして願わくば私たちに挑戦してください。

Share on Twitter Share on Facebook


この配置は、運用面からも合理的な判断です。もしひとつがダウンしても、トラフィックは他の稼働しているロケーションに送られます。ひとつのクラウドプロバイダーを利用し、その中で可用性をどう高めるかを検討するよりも、ユーザーのウェブ ブラウザで障害が発生しない方法を探してきました。

Wix のプラットフォームは複数のサブシステムからなり、それぞれ独自の SLA (サービス品質保証) を持ちます。設計上の鍵は、それぞれのサブシステムが、別のロケーションのサブシステムで完全にバックアップされている状態を維持することです。

課題:
目標は、ユーザーのデータを損失から保護しながら処理するために、100 % に近いアップタイムを実現することです。以前はホスティング環境だけで運用していましたが、障害からの復旧に備えて別の環境を追加しアクティブ/アクティブ構成をとるようにしました。さらにその後、3 つめのデータセンターを追加し 3 拠点からなるアクティブ/アクティブ構成としました。

前回のブログポストでお伝えしたように、3 つのデータセンターをまたぐ複製を管理するのは、2 つのデータセンターよりもさらに複雑になります。ましてや、冗長性のため、それぞれ異なる ISP を利用していればなおさらそうなります。3 拠点のアクティブ/アクティブ構成としたことによる課題は、データベースのレプリケーションでした。3 つのデータセンター間でのレプリケーションを実現するために、MySQL をリング型トポロジーに構成し直す必要がありました。しかしこのリングは、ひとつのデータセンターがしばらくダウン、または停止すると壊れてしまうのです。

この対策として、3 拠点のアクティブ/アクティブ構成とするかわりに、2 拠点をアクティブ/アクティブ構成とし、3 つめの複製はまったく別のテクノロジーを使うプラットフォームで実行することにしました。この 3 つめの複製では、データ ポイズニング (問題のあるコードが、不意にデータを損傷してしまい、それがしばらく検知されないこと) を保護する機能も追加します。

そして、Google Cloud Platform ネイティブの完全な機能を持たせたデータセンターを構築することを決断したわけです。半年後の 2013 年 4 月には一部地域での Wix のメディアを GCP から提供しはじめ、2013 年の終わりにはトラフィックの 100 % は GCP から提供されるようになりました。NORM(Not Only Replication Manager) と呼んでいる、複数のデータセンター間でのデータ複製、同期の仕組みも GCP 上で開発し、NORM によって GCP, Amazon Web Services, Wix の各データセンター間でのデータ複製、同期を実施しています。

終わりに:
世界のクラウド ウェブサイト作成サービスをリードする立場として、クラウドにおける障害情報には常に目を光らせています。一分でも障害があるごとに、お客様にとっては損害が発生します。複数のクラウドプラットフォームを利用し、障害におけるリスクを軽減しようとする対策は当然の流れといえます。

複数のクラウドプラットフォームを利用するための課題は、その恩恵に比べれば小さなものです。その恩恵は、予想した機能の強化、コストの削減、性能の改善を超えるものでした。

運用上のタスクはストレスにはならず、眠れない夜と障害対応室はもう過去のものです。なにかあっても、トラフィックを機能しているシステムへ切り替えるだけで、調査は後でできます。この新しい構造によって、お客様には最高の体験を提供できるようになりました。
Share on Twitter Share on Facebook

ゲーム攻略完全図鑑は、ソーシャルゲームを中心にゲームの攻略方法が掲載されたオンライン メディアで、専属のライターによる攻略コンテンツに加え、サイトに来るユーザーも自分で攻略方法を書いて公開できることが特徴です。

10 月の時点で、月間 PV が 1 億 3,000 万、MAU (Monthly Active User) 950 万に達するサイトは全て Google Cloud Platform (GCP) 上で動作しています。プログラミングから攻略方法のライティングまでされているお二人、株式会社ゲーム攻略完全図鑑 代表取締役 内田 一樹さんと、事業開発部 エンジニアリングチーム 千葉 幸士郎さんにお話を伺いました。

スタートアップとして、ソーシャル ゲームの市場の中で、ゲームを作るという発想ではなく、なぜゲーム攻略完全図鑑のようなメディア ビジネスをやることにしたのですか
内田さん:Google App Engine (GAE) が出始めた頃、ガラケーのゲームが流行っていて、そのときは GAE を使いゲームを作っていましたが、今のグラフィカルなゲーム作りについていけなくて。そういう状況で、ゲームを開発する人をいかに手伝えるかというところを考えて攻略サイトを作り、ゲームをする人にも、ゲームだけしていても生活できるようになる環境を作りたくて、ユーザーが自由に攻略サイトを立ち上げることができる仕組みを作りました。

GAE でサービス全体が作られているそうですが、なぜ GCP を選んだのですか
千葉さん:元々 GAE をゲームで使っているときに、1 日に何千万 PV を処理した実績があって、何も心配していなかったし、もしそのトラフィック処理のためにサーバ管理を自分でやろうとしたら、僕達にはできないですから。

開発について、使っているツールや開発プロセス、GAE での開発について教えてください
内田さん:開発プロセスはないです(笑)。こうあるべきというのは僕の中で固まっているので、それをどんどん小出しにして。二人でアイデアを出して二人で作る感じです。

千葉さん:ソースコード管理は GitHub、後はエディターくらい。二人とも Vim を使って。GAE のデプロイは手動で、自分たちでツールを作ってデプロイしています。GAE では、データは全て Datastore に保存して、他には Task Queue をほぼ全ての処理に使うという程に使ってますね。フロントエンドは全てキャッシュ(Memcache)から取り出すようにして、後は全てバックエンドで Task Queue を経由して処理している、という構成です。

今かなりの PV があるなかで運用されていますが、コストも含めていかがですか
内田さん:運用自体すごく楽なんですよ。アプリケーション開発のみで後は全て面倒を見てくれるので。サーバの面倒を見る時間があったら、アプリケーション開発をしたいですから。コストは、チューニング次第かなと思ってます。先ほど話したようにキャッシュを使うなど工夫して、今かなり安いですね。あとは Datastore の使い方次第で、SQL 的な考え方をしていると、トラフィック捌けないし、高額になってしまう。Datastore の使い方をチューニングしたら劇的にコストが下がりました。

運用をしていく中で、ユーザーからのフィードバックをどう得ているか、またフィードバックを得てユーザーの体験を高めるために何かしていることはありますか
内田さん:イベントトラッキングをして Google Analytics で見ている部分もありますが、直接声を聞くためにメールを送ってやり取りすることもあります。

千葉さん:そこはさらに力を入れてやっていこうと思っています。実際にサイトを作ってくれているユーザーは貴重で、そういう人たちにはどんどん連絡して、例えば内部リンク貼っていないユーザーには、貼った方がいいですよとやりとりしたりして、日々使いやすくなるように取り組んでいます。

今後計画されていることと、GAE に限らず GCP をどのように使っていく予定があるか、教えてください
内田さん:そうですね、まずはトラフィックをもっと集めようとは思っています。倍くらいには伸ばしたいですね。その後は海外展開も考えています。GCP では、BigQuery を使っていきたいと思っていて、ログをもっと活用していきたい。ターゲティングできるような仕組みを、BigQuery でどうにかできないかと考えています。

最後に、いろいろなクラウド プラットフォームがあるなかで GCP を、これから起業するスタートアップに勧めるとしたら、どういうところを勧めますか
内田さん:エンジニアが起業するような形だと、他を使うこともあるかと思いますが、プロダクトのことを考える人なら、エンジニアであっても Google の方がいいかな、と思いますね。本当にプロダクトに集中できるので、運用の手間がかからない。サーバはまったく触ってないです。


社内の雰囲気は、ネットカフェのよう。「ジュース飲み放題、お菓子食べ放題、漫画があって、ゲームしてる」と、内田さん。

攻略したいゲームがあれば、ゲーム攻略完全図鑑へ。Google App Engine と BigQuery を試すならフリートライアルから。今なら 60 日間で $300 分のクレジットが使えます。



■ Google Cloud Platform のその他の導入事例はこちらから
Share on Twitter Share on Facebook

好評いただいている「Google Cloud Platform 始めてみよう! ハンズオンセミナー」の番外編として、大阪で Google & Tableau セミナーを開催することになりました。

大規模なデータを高速分析することができる Google のクラウド ツール Google BigQuery - 全世界 19,000 社で多種多様なデータ分析に使われている Tableau Desktop。この両者を組み合わせたハンズオントレーニングを、今年の10 月に東京で開催したところ大変好評だったため、急遽大阪にて第 2 回目となる同セミナーを開催します。是非この機会に体験ください。



■ 日時:12 月 10 日(水) 14 : 00 - 17 : 00
■ 会場:AP 大阪梅田茶屋町 会議室 D〜F
■ 対象:データ分析を伴うを業務ご担当者様
■ 費用:無料

【セミナーの内容】
13:30 受付開始(受付終了は14:30)
14:00 セミナー開催挨拶
14:05 Google BigQuery 製品説明
14:35 Tableau 製品説明
15:00 休憩
15:10 Google BigQuery と Tableau のハンズオン
16:30 Tableau デモ
16:45 Q&A
17:00 終了

セミナーの詳細、参加における準備事項の確認、また、お申込みはこちらのセミナーページからどうぞ。

皆様のご参加をお待ちしております。
Share on Twitter Share on Facebook

Share on Twitter Share on Facebook

Share on Twitter Share on Facebook