Tweet
・37.Google Cloud Datastoreを試してみた GCE編 (2/3)
・38.Google Cloud Datastoreを試してみた その他環境編 (3/3)
Ryo Yamasaki(@vierjp)です。
Google I/O 2013で発表された「Google Cloud Datastore」について調べたので、
今回から三回に分けて書いていこうと思います。
第1回は概要や仕組み、注意点についてです。
今回は以前に書いた「Blog @vierjp : 27.Google I/Oで発表されたGoogle Cloud Platformの新機能」と重なっている部分がいくらかあります。
◯概要
・App EngineのDatastoreが単独で利用可能になるこれまでAppEngine上のアプリからしか利用できまなかったDatastoreがそれ以外からも利用できるようになりました。
Compute Engineや他のクラウド環境、オンプレミス環境からも利用が可能です。
・特徴はApp EngineのDatastoreと同じ
・クエリの速度がデータ量に影響しない
・データは複数データセンターにレプリケートされる
・計画されたダウンタイムはなし
・メンテナンスフリー
・etc…
・環境や言語を問わず利用可能
Protocol Buffer形式かJSON形式でAPIを利用してDatastoreを操作する事が可能です。
PythonとJava、node.js向けには公式のクライアントライブラリも提供されています。
・現在「Preview Release」という扱い
まだPreviewなのでAPIが突然変わる可能性あります。
と言っても通常過去のAPIバージョンもしばらく並行して動くようにしているようなので、
おそらく安全に移行するための期間はあるのではないでしょうか。
「Google APIs Explorer」を見ると、
例えばCompute EngineのAPIは現在v1beta13〜v1beta15を利用可能であることがわかります。
◯仕組み
サービス的な位置づけとしては「AppEngineのDatastoreを別のサービスとして切り出した」で良いと思いますが、実際の仕組みは「AppEngine のDatastoreを切り出した」というよりも
「既存のAppEngineのDatastoreそのものにアクセスするためのAPIを提供した」
というのが正しいようです。
APIによる操作は「API実行時に指定したAppEngineアプリケーションのDatastore」に対して行われます。
(厳密には指定したCloud Projectに紐づくAppEngineアプリケーション)
そしてAPIはAppEngine上で動作するアプリとして作られているようです。
Admin Consoleの「Logs」には、以下のように「ah-builtin-datastoreservice」という暗黙的なバージョンが「Built-ins」というカテゴリで追加されています。
(一度でもCloud Datastore APIを実行すると表示されるっぽい)
そしてAPIを実行するとこのバージョンのリクエストログに記録されます。
システム的な特性もAppEngineのDatastoreと同じということになります。
このような仕組みなので、
自分でAppEngine上にデプロイしたアプリからはこれまで通りにそのアプリケーションの Datastore を操作できます。
その上で「そのアプリケーションのDatastoreをAPIを使って外部からも操作できる」という事になります。
そのためAppEngine上の既存アプリケーションは全く修正することなく、
アプリケーション外の環境とデータを共有することができます。
◯Indexの管理
AppEngineから使っている場合はこれまでどおりに「datastore-indexes.xml」を配置してデプロイすればOKです。加えてAppEngine"以外"から使う場合のために、
AppEngineのアプリをデプロイせずにインデックスを設定するための手段が追加されています。
と言っても「datastore-indexes.xml」を作成するのは同じですし、
コマンドからこのファイルを指定して「インデックスの更新」と「使ってないインデックスの削除ができる」というものなので、
機能的にはappcfgのインデックス関連の機能をそのまま持ってきて単体で使えるようにしたという感じです。
Index Configuration - Google Cloud Datastore — Google Developers
◯Preview期間中の制限
・Read、Write、Small Operationの回数に制限あり1,000万/日 500/秒まで
ただしこれらは連絡すれば増やしてもらえるとのことです。
◯Memcacheの利用に関する注意
特にフレームワークでEntityの自動キャッシュ制御をしている場合には注意が必要です。これまでは「DatastoreはAppEngine上のアプリからしか操作しない」という前提でした。
そのためアプリで使うフレームワーク(NDB等)で自動的にMemcacheにEntityデータの登録や削除を行い、
必ずその処理を通してDatastoreを操作することでDatastoreとキャッシュの内容が一致していました。
しかし、
例えば「AppEngine上のアプリから追加されたEntityをアプリ外からCloud Datastore API経由で更新する」というケースを考えた場合、
APIけ更新処理はアプリで使っているフレームワークの処理を通らないのでキャッシュが更新されません。
よってこのタイミングで Datastore のデータとキャッシュの内容がずれてしまうことになります。
同様に自前でクエリ結果をキャッシュしているような場合にも
Entityが更新されたタイミングでそのキャッシュを削除することができません。
AppEngine 上のアプリで Entity の自動キャッシュ制御をしている場合には、
外部から操作するKindだけキャッシュしないようにしたり、
それが困るならその処理だけ専用のAPIを自前で作ったり(Cloud DatastoreのAPIを使わない)とする必要があります。
APIのアプリのソースコードが公開されてAPIのアプリを置き換え可能になると良いのですが。
◯課金に関する注意
・少なくとも現時点ではAPIの使用量はAppEngineの使用量として加算されます冒頭に書いたとおりAPIがAppEngine上で動作しているという仕組みを考えると納得ですが、
APIの使用量はAppEngineの使用量として加算され「Usage History」(「Billing History」)で確認できます。
そしてAppEngineの無料枠を超えた分が課金の対象になります。
これはPreview期間中だけの暫定仕様で、今後はAppEngineとは別の請求になる予定だそうです。
この時に Cloud Datastore の利用に無料枠があるかどうかわからないので、
もしかしたら試すには今が都合が良い時期かもしれません。
・API実行によって課金されるリソース
・Datastore Storage
・Datastore Writes
・Datastore Reads
・Small Datastore Operations
・Frontend Instance Hours
・Bandwidth Out
最初の4つはDatastoreの操作に伴うものなので当然ですが、
Frontendインスタンス利用時間と帯域使用量にも加算される点は注意です。
どちらもAPIがAppEngine上のアプリとして動作していると考えれば理解できます。
(挙動として理解はできるけどFrontendインスタンス使用量は課金対象から外してくれても良い気がする)
Bandwidth OutはAPIのレスポンスデータの通信分に適用されていると思います。
(Compute Engineから実行すればBandwidth Outはかからないかも)
◯ユースケース1 App EngineのバックエンドとしてCompute Engineを利用する
Cloud Datastore API によってApp EngineとCompute Engineの両方の環境からデータの共有が簡単になりました。
よって、
・AppEngineのアプリが保存する大量データの更新処理をCompute Engine上から行う
・DatastoreのデータをBigQueryに転送する前に加工する
・Compute Engine上で特殊なミドルウェアが必要な処理を行った上で処理結果をDatastoreに記録する
といった、App Engineで実装しづらい(できない)処理をCompute Engineで行う事なりました。
ただし前述のようにAppEngine上のアプリでキャッシュ制御をしている場合には留意してください。
Cloud Datastoreの登場によって、
AppEngineのバックエンドとしてのCompute Engineの価値が高まったと言えるでしょう。
◯ユースケース2 Compute Engineから使うNoSQLデータベースとして利用する
・App Engineの対応言語に縛られずにCompute Engine上のWebアプリからDatastoreを利用できる
・Compute Engineが使う「メンテナンスフリー・ダウンタイム無し」のデータ保存領域として利用できる
例えばCompute Engine上にnode.jsのサーバーを立ててデータ保存領域としてCloud Datastoreを使うことができます。
また、これまでCompute Engineでデータベースを利用したい場合には
Compute Engine上に自前でRDBやNoSQLデータベースを構築するかCloud SQLを使うという選択肢がありましたが、
今回新しくCloud Datastoreという選択肢が増えたと言えます。
また、Compute EngineからはCloud DatastoreのAPIを利用するための認証が簡単です。(詳しくは第2回に)
◯ユースケース 3 Googleのクラウド環境以外からDatastoreを利用する
JSON APIがあるので基本的に環境・言語を問わずに利用できます。
別のクラウド環境からも、自社にあるオンプレミスのサーバーからアクセスすることも可能です。
アプリのアップグレードに伴うデータの一括更新処理をローカル環境から実行するようなこともできます。
ただこのケースの場合にはCompute Engineから操作するのと比べて通信速度が遅いでしょうから、
Webアプリでユーザーに対してリアルタイムにレスポンスを返す目的で使うなら、
App EngineやCompute Engineから利用した方が良いかと思います。
どちらかというと、このケースはバックグラウンドでの処理や既存システムとの連携において有用でしょう。
(App Engine、Compute Engine以外からの利用は第3回に)
◯参考リンク
Ushering in the Next Generation of Cloud Computing (I/O Session)What's New and Cool with Google Compute Engine (I/O Session)
Google Cloud Datastore 公式ドキュメント
Report of Google I/O 2013 Google Cloud Platform
◯次回以降の予定
第2回はCompute Engineから、第3回はその他の環境から、サンプルコードを使ってCloud Datastore APIを実行してみようと思います。
Tweet
0 件のコメント:
コメントを投稿