バックエンドゲーム開発者向け Firebase新着情報
トドオ・カーペルマン：こんにちは
このオンラインイベントに ご参加いただき感謝します
今回の講演はもともと
バックエンドゲームデベロッパー向け Firebaseの新機能というタイトルでした
ネタバレ注意ですが
Cloud Firestoreについてお話しします
関心を向けるべき理由
隣にいるそのデータベースエンジニアが ワクワクしている理由です
ご存知かもしれませんが Firebaseには
ゲームの起動・実行を容易にする
ツールがいくつかあります
一般的には インフラストラクチャの
退屈な作業は委託して
楽しいゲームを作るなどの
最優先事項の 他のタスクに
集中しようと考えます
Firebase認証などのサービスを提供します
ユーザーはさまざまなプロバイダーから
非常に簡単に ゲームにサインインできます
Firebaseホスティングがあります
これはデフォルトでSSLなどの
優れた機能を備えた グローバルCDNで
ウェブサイトを すばやく簡単に
立ち上げるという考えです
たとえば 迅速にホストしたい1回限りの
ゲーム向けマーケティングサイトが ある場合などに便利です
大きなバイナリオブジェクトを格納する
強力かつシンプルなサービスの Cloud Storageがあり
スクリーンショットや動画のような
ユーザーが作成したコンテンツや インストール後のゲームデータのチャンクなど
あなたが提供するコンテンツかもしれません
Cloud Functions for Firebaseを使うと
サーバーを自分で立ち上げる必要なく
バックエンドコードを実行できます
クラウドにデータを保存するデータベースがあります
Realtime Databaseは 耳にした事のある開発者も
多いと思います
独立した スタートアップだったときの
Firebaseの主力製品です
今でも優れた製品です
ここでの考え方は ユーザーが1つのデバイスの値を変更すると
サーバーのSDKがその値を捉え
他のすべてのデバイスの変更を
自動的に更新するというものです
ここでのリアルタイムとは
ゲーム開発者が慣れているものとは
少し異なります
数百ミリ秒のレイテンシなので
ファーストパーソン・シューターには 向かないでしょう
しかしそれを使って ビンゴゲームなどが可能です
興味深い点ですが
Realtime Databaseは Loteriaを動かすために使用されました
これはGoogle Doodleとして 実行されたビンゴのようなゲームです
12か国以上の Googleフロントページで実行されました
Realtime Databaseが マッチメイキングを処理し
スクエアを呼び出し
対戦相手の動きをリアルタイムで示し
勝者を宣言しました
素晴らしい点は
Googleのトッページに このゲームが表示され始めたとき
文字通り一晩で プレーヤーがゼロから
数百万人になったことです
Googleのトラフィックが 多いことがわかりました
Realtime Databaseが すべて処理しました
パニックでエンジニアに 電話がかかることもありませんでした
エンジニアリングチームが これをどのように行ったか
詳細に説明した 素晴らしいブログポストがあります
読むとより多くの 情報が得られ素晴らしいです
しかし多くのネイティブアプリ およびWeb開発者には
次世代のリアルタイムで
Cloud Firestoreと呼ばれる製品の
データベースを導入しました
現在あるいはアルファリリースで
利用可能と発表した 数週間前までは
C +やUnity向けの クライアントライブラリがないこと以外は
全体的に非常に好評です
そのアルファタグは重要なので
さらに扱いたいと思います
とてもワクワクし
ご自身の複合インデックスや
お持ちのものを 構築する方もおられるでしょう
しかしかなりの データベースオタクではない
残りの人にとっては こう自問するでしょう
これは良いニュースだと思うけど
これはどういう意味か？
関心を持つべき理由は？
詳しくご説明します
Cloud Firestoreは Realtime Databaseと同様
NoSQLデータベースと呼ばれる
データベースファミリーの一部です
どういう意味か 簡潔に知りたい場合は
従来のデータベースを考えてください
多数のテーブルがあり それぞれに高度に構造化された
データのタイプが格納されています
またSQLと呼ばれるクエリ言語を使用して
これらのデータを結合できます
多くのことが行えますね？
さまざまな種類のテーブルから
さまざまなデータや計算データを
統合できます
素晴らしいですが
パフォーマンスは かなり変動する可能性があります
クエリにかかる時間も 長かったり短かったりします
持っているデータの量と それがどう設定されているか
どんな種類のクエリを 求めているかにより異なります
NoSQLデータベースは
いくつかの重要な点で異なります
1つ目に気づくのは
データが少しゆるい傾向があることです
公式には スキーマレスとして知られています
良いと見なされることが多いです
これにより開発者は
古いレコードに加えたすべての変更を
バックフィルを心配せずに
基礎となるデータをはるかに高速に
反復処理できます
また類似していても 厳密には異なるデータを
格納する機能もあります
この様に 同じコレクションに
多数の文字をまとめて保存しています
確かに似ていますが
先に進んで メイジ用のスペルブックと
ファイター用のバトルクライを追加し
泥棒にロックピックを設定できます
当社データベースは データ構造が文字ごとに
まったく同じではないことに
不満は出ず対応しました
しかしNoSQLデータベースとの 最大の違いは
SQLがないことです
クエリはずっと単純になりがちです
すべてのデータまたは 計算データを一緒に統合する
こうした結合が 得られるわけではありません
つまり同じデータのコピーが 複数の場所に存在するなど
最初は変に見えるものを
頻繁に目にすることになります
これらの奇妙な点のいくつか 特にここでは
d正規化データと呼ばれるこの概念は
最初はベテランの SQL開発者を驚かせていました
しかし長期的には この奇妙さを相殺する
素晴らしい価値があります
まずNoSQLデータベースは 水平方向に拡張できます
本当に優れています
データセットが大きくなるにつれ
より多くのマシンを投入でき
先に進み これら様々なマシンすべてに
そのデータを提供します
クラウドでホストする環境で 非常に役立ちます
たとえば データベースの必要に応じて
オンとオフを切り替えられ
大量のサーバーがある Google Cloud Platformを選ぶだけです
データベースは こうしたさまざまなサーバーに
増え拡大しますが
背後でこうした作業を 行っているとは気づきません
対照的に 従来のSQLデータベースは
垂直方向に拡張する傾向があり
データセットが大きくなるにつれ
それらをホストする
もっと大きなコンピューターが必要で
それが問題になる場合があります
1つにはある時点で
データセットを実行する 大規模なスーパーコンピューターが
不足する可能性があります
大型で高速な スーパーコンピューターに切り替える
必要があるたびに ダウンタイムが
発生する可能性もあります
NoSQLデータベースを使用すると
パフォーマンスが 向上することがよくあります
Cloud Firestoreの世界で
我々が気に入っている点の1つは
クエリは基になる データセットのサイズではなく
結果セットのサイズに スケーリングすることです
どういう意味でしょう？
たとえば ユーザーが生成したパズルを
Cloud Firestoreに保存するゲームがあり
データベースに 評価の高い順に並べられた
米国の上位10のアクティブレベルを 送信するよう求めた場合
そのクエリが 検索するレコードが300か
3億かに関わらず
掛かる時間は同じですね？
基になるデータセットが どれほど大きくても
このクエリには 基本的に同じ時間がかかります
ゲームの人気が高まるにつれ
パフォーマンス上の理由から データベースを再構築する必要を
心配しなくてよいので
非常に優れています
ではCloud Firestoreの扱いを
快適なものとする 他のいくつかの機能も
見ていきましょう
まず第一に データ構造モデル
特にRealtime Databaseや
他のNoSQLデータベースと 比較すると
かなり使いやすいと言えます
すべてのデータは ドキュメントやコレクションに
保存されることが多いです
キーバリューのペアを含む
ドキュメントと見なせます
これらの値は 配列から文字列
浮動小数点数 JSONyに見えるオブジェクト
少量のバイナリデータまで
さまざまです
これらのドキュメントは ドキュメントごとに
最大1メガバイトの データになる場合があり
ここではテキストと数値 およびJSONyを主に扱っているので
実際にはかなり大きなデータです
これらのドキュメントは コレクションに格納されています
ドキュメントの集まりです
これらのドキュメントは
他のドキュメントを含む サブコレクションを指す
他のサブコレクションを
指すこともあります
ここで重要なのは すべてのクエリは浅く
その下にあるデータすべての取得を 心配することなく
ドキュメントを取得できます
つまりユーザーが
こうしたドキュメントの1つを ここでリクエストするたびに
不要なデータを大量に 取得することを心配せずに
論理的に意味のある仕方で
データを階層的に構造化できます
Cloud Firestoreには すべてのクライアントライブラリに
組み込まれた非常に堅牢な
オフラインサポートがあるため サーバーからデータを取得すると
SDKがデータを自動的にキャッシュします
新たに飛行機に 飛び乗るユーザーの場合でも
飛行機モードをオンにし
デバイスにキャッシュされた すべてのデータに引き続きアクセスできるので
ゲームをプレイし続けられます
さらにオフラインキャッシュに 保存されている
データも照会できます
さらにプレーヤーが行った書き込みは
デバイスのキューに入れられます
ユーザーがオンラインに戻るとすぐに
記録された順序で
データベースに配信されます
ゲームプレイセッションデータが 失われることはありません
Cloud Firestoreは データを1回限り
取るサポートがあり
より従来型のデータベースを 使用している場合に
慣れているでしょう
多くの開発者がこの方法で
Cloud Firestoreの使用を開始しますが リアルタイムリスナーを追加して
ドキュメントの値が変更されたときに
クライアントにすぐに 通知されるようにもできます
便利ですね？
このクエリの結果を聞きたいと
ライブラリに伝えれば
Cloud Firestoreが更新を送信します
これらの値が変更された場合
更新のために
そうしたプルは不要です
新しいデータが 利用可能になると
すぐに表示されます
これはマルチプレイヤーゲームなど
ユーザーの順番が変わった後に ゲームの状態を更新したい場合に最適です
Cloud Firestoreは マルチリージョンサポートがあり
互いに数マイル離れた
さまざまな場所に データを保存できます
信頼性の観点から本当に優れています
たとえば放射性トカゲなどで
都市全体がオフラインになっても
他の地域からデータに
アクセスできるからです
しかし同時に とても一貫しています
つまり取得データは
クライアントが最初に 置いた場所に関係なく
データベースに書き込まれた
最新バージョンのデータです
正直に言うと
この種のマルチリージョンサポートと
強い一貫性を持たせるのは
素晴らしと同時に 我々が舞台裏で解決するのに
困難を覚えた問題でもあります
正直言って これがいかに優れているか
理解できません
我々が解決した かなりすごい
問題だと言えます
Cloud Firestoreは 他のクライアントが
同時にデータを いじらないようにしたい場合に
アトミック トランザクションもサポートしています
そのスライドはありませんが
みんな関心を持っているので
ここで触れておきます
皆ゲームを作っており
常にクライアントを信頼できるとは限らないので
Cloud Functionsと セキュリティルールもサポートしています
セキュリティルールは
クライアントが 必要のないデータを要求したり
期待どおりに 見えないデータを書き込もうとする
クライアントからのリクエストを
拒否するように定義したルールです
ただしより高度な コントロールが必要な場合は
Cloud Functionsを使用できます
ユーザーが制御および信頼する
環境のクラウドで実行される
サーバーレス機能で
この機能がすべてのクライアントで
一貫していることを確認できます
さらに重要なのは データベースに加えられた
変更を信頼することです
クラウドで動作するリアルタイム対応の
NoSQLデータベースである Cloud Firestoreについては
大分扱いました
こう自問するかもしれません ちょっと待って
リアルタイムデータベースの Firebase Realtime Databaseとの比較はどうか
クラウドにあるのか？
どちらか一方を 選択する必要はありません
ニーズに応じて 同じプロジェクト内で
両方使用できます
ただしこの2つを 比較対照するなら
一般的にCloud Firestoreを Realtime Databaseの
強力なバージョンと見なせるでしょう
一般的に より複雑なデータを
より適切に処理できると思います
個人的な意見ですが
データモデルの方が 扱いやすいと思います
より強力なクエリ機能があります
取引が少し洗練されています
Realtime Databaseよりも 優れた拡張性を備えています
また信頼性を高めるために マルチリージョンサポートを利用できます
ただしRealtime Databaseの方が
優れている点がいくつかあります
クライアントが北米で プレゼンスのサポートが組み込まれている場合は
多少速くなる傾向があります
多くのゲーム開発者が プレイヤーに友達がオンラインか
知れるようにしたいと考えています
これとCloud Firestoreには回避策がありますが
ネイティブに組み込まれておらず
Realtime Databaseほど
エレガントではありません
価格モデルも異なります
Realtime Databaseでは
コストは主に クライアントとの間でやり取りする
データの量に基づいています
Cloud Firestoreのコストは 主に実行する読み取り
または書き込み操作の数に基づいています
一般的にRealtime Databaseは
小規模な操作が多数ある場合に
費用対効果が少し高くなります
ビンゴやポーカーのような ゲームを考えてください
クライアントは コール レイズ B14などの
小さな情報を
非常に頻繁に送信しています
クラウドファイアストアは
大規模な操作が少ない場合に
費用対効果が高くなる傾向があります
非同期の描画ゲームについて考えてみましょう
プレーヤーの描画を表す JSONデータの大きな塊や
ターンベースの単語または
チェスゲームでさえも 送信する可能性があり
プレイヤーはターンする前に 長時間考えがちです
それほど多くの操作を実行していません
しかし価格にこだわりすぎないでください
Cloud Firestoreで便利になる点が
沢山あります
エンジニアリング時間にも費用がかかります
サーバーコストを18ドル節約するのに
10時間余分にかかる場合
適切なトレードオフではありません
エンジニアリング時間を賢く使ってください
こうした人たちは おしゃれなスナックを食べる傾向があります
では実際にCloud Firestoreをどのように使用しますか？
潜在的な状況を見てみましょう
最もシンプルな使用例の1つです
プレーヤーのゲームをクラウドに保存します
ユーザーは複数のデバイスで ゲームをプレイしたいと考えています
Cloud Firestoreを使用すると
ゲームの状態をクラウドに簡単に保存できます
プレーヤーの状態をドキュメントに書き込み
そのドキュメントをデータベースに書き込むだけです
その値を聞いている他のクライアントは
最新バージョンを取得して プレーヤーの進行状況が
ゲームをプレイしているすべての場所に
反映されていることを確認します
Cloud Firestoreのストレージは
特にRealtime Databaseと比較して
比較的安価であることも指摘しておきます
先に進んでいくつかのバージョンを 保存して戻すことができます
カスタマーサポートに 必死に電話をかけ
ゲームに問題があるという
プレーヤーなら
以前のセーブゲームに戻すことができます
Cloud Firestoreのもう 1つの優れた使用例は共有ゲーム状態です
ターン制の単語ゲームや 描画ゲームについて考えてみましょう
始めにクライアントが先に進んで
参加しているゲームを クエリするのはとても簡単です
プレーヤーが順番を望むときはいつでも
この共有ドキュメントに 新しいゲームの状態を
記録するだけで 適切なプレーヤーが
アクセスできます
リアルタイムリスナーの魔法のおかげで
他のプレーヤーのクライアントは
ゲームの状態が変更されると すぐに更新されるため
自分の番であることがわかります
クライアントにこのドキュメントを 直接更新させるのではなく
追加のセキュリティが必要な場合は
希望する動きをCloud Functionに
中継させることができます
これらはクラウドに存在する
サーバーレス機能です
次にこのCloud Functionは プレーヤーの動きを検証し
すべてが正当に見えることを確認します
共有ゲームの状態を
実際に更新する作業を実行して
他のプレイヤーに送信できます
またFirebase Cloud Messagingとの
統合により
他のプレーヤーに通知を送信できます
現時点でアプリを開いていなくても
自分の番であるという アラートを受け取れます
毎日の課題も 別の良い例です
サインインするたびに すべてのクライアントに
送信する必要がある
コンテンツの集まりです
ロールプレイングゲーム パズルゲーム
クロスワードパズルなど 毎日の挑戦がありますが
これはCloud Firestoreを通じて
簡単に保存および提供できるデータです
ユーザーが作成したコンテンツも 良いユースケースとなるでしょう
繰り返しますが 動画やスクリーンキャストなどの
大きなバイナリオブジェクトの場合は
Cloud Storageをお勧めします
でもユーザーが独自のレベルを作成している あらゆる種類のパズルゲーム
またはプラットフォーマーゲームについて 考えてください
おそらくJSONデータとして保存しているデータです
Cloud Firestoreでうまく機能します
北米で作成されたすべてのパズルを 評価で並べ替えて検索したり
最新のパズルを検索したり 特定の作者によるすべてのパズルを
検索したりできます
しかし多くのより大規模で 世間に認められた企業にとって
政治的に最も興味深いユースケースは
現在のインフラストラクチャ上で リアルタイムでグローバルに
スケーラブルな キャッシングレイヤーとして
Cloud Firestoreを使 用することだと思います
航空会社を考えましょう
これらの航空会社には 30年前のレガシーサーバーがあり
多数のビジネスロジックと
規制コンプライアンスが 組み込まれています
すべてを新しい NoSQLデータベースに
置き換えることはできません
しかし同時に 何百万ものクエリを処理でき
リアルタイムの更新と 優れたオフラインサポートなどの
優れた最新の アプリケーションインフラストラクチャが
必要かもしれません
これらの企業は データの一部を
Cloud Firestoreインスタンスに コピーできます
これらのクライアントは
非常に簡単に検索できます
たとえばチケットの価格や フライトステータス情報などを取得し
レガシーサーバーがチケット購入
おそらくまだ元のサーバーを 通過する必要があるものなどの
重要なことを処理しながら
これらの更新を リアルタイムで取得できます
このプレゼンテーションを ご覧になっている方々は
飛行機ではなくても
MMO 収集可能なカードゲームや
ロールプレイングゲームを使用していて 大量のデータがある場合は
それがゲームプレイのバランス設定 プレーヤーのプロファイル
またはクライアントが
定期的に読むようなものがあるでしょう
繰り返しますが 常にサーバーにアクセスする
クライアントが多くいます
Cloud Firestoreを その前に置くことを
検討してください
クライアントは先に進んで
Cloud Firestoreに プッシュしたデータをクエリしながら
元のサーバーを解放して プレーヤーのトランザクションや
ユーザーの購入などの重要な処理を
行うことができます
以上のことを踏まえると
Cloud Firestoreでの構築は ワクワクしますが
そのAlphaラベルについて ここで話したいと思います
Cloud Firestoreバックエンドサービスは
かなり前から存在しており
実際の本番環境生産アプリで 使用されていますが
これらの新しい クライアントライブラリは非常に新しく
まだ実際にテストされていません
バグが予想されます
いくつかあるでしょう
Unity SDKは高度な機能が幾つか
欠けていることがわかっています
より洗練されたクエリのいくつかは まだ利用できません
数値変換のようなものは
まだサポートされていません
APIサーフェスは今後数か月で
変化すると予想しています
クライアントライブラリを更新するときに
メソッドの名前を
変更する必要があります
これらの新しいライブラリを
お試しください
それらがゲームのインフラストラクチャに どのように適合するかをご覧ください
フィードバックもお待ちしています
しかし数か月先まで ビジネス全体を
Cloud Firestoreベースのビジネスに 移行することを控えるかもしれません
その恐ろしい免責事項は脇に置いて
最新のゲームで Cloud Firestoreを使用することに
少し興味を持っていただければ幸いです
Cloud Firestore または当社が提供する
その他のサービスの詳細は
firebase.google.com / gamesに アクセスしてご確認ください
ご視聴に感謝します
ゲームを次のレベルへ ゲーム用グーグルをさらに見る