Apache Usergrid について＠第15回まどべんよっかいち2016/7/23青木 宣明

Usergrid とは

背景• 短納期でのアプリ開発でサーバ構築をどうするか？

• データ構造が決まらない、開発中に変更される…• ユーザ管理、アクセス権限管理の作り込みが大変…• データ操作の API の開発を素早く行いたい…

Usergrid とは• Apache Project の BaaS

• 2011 年から OSS として公開されている• ユーザ管理・データ管理・ファイル管理の機能を提供する

• データ管理・操作体系が統一されていて、どれもエンティティとそのコレクションとして管理されて、それらを REST で操作する

• バックエンド• Apache Cassandra ：分散型 NoSQL データベース• ElasticSearch ：分散型検索エンジン• Apache Tomcat ： Java Web AP サーバ

• Azure や AWS などのクラウドに配置できる

Usergrid の特徴1. マルチテナント対応2. グラフ指向のアプリケーションデータ

• コレクションとエンティティ• コネクションによるエンティティの関係付け

3. ユーザ管理• ユーザ、パーミッション、ロール、グループ

4. ソーシャル• ユーザアクティビティ• コネクション（フォロー、フォロワー）

5. ジオロケーション6. プッシュ通知

特徴 1マルチテナント対応

マルチテナント対応Organization Organization

Usergrid

Application

Application

…

Application

…

…

組織を定義して、各組織ごとにアプリケーションを定義するマルチテナント構造

スーパーユーザ（システム管理者）

組織管理者 組織管理者

Usergrid 全体の管理者と、組織ごとの管理者がある

特徴 2グラフ指向のアプリケーションデータ

コレクションとエンティティ

■/spots コレクションのエンティティデータ{ "uuid" : "5c0c1789-d503-11e1-b36a-12313b01d5c1", “type” : "spots", "created" : 1343074620374, "modified" : 1355442681264, “name” : “ 四日市 ", "location": { "latitude": 35. 0, "longitude": 136.61 }}

Application

Collection

Collection /shops

/spotsアプリケーションデータは属性の集合であるエンティティとして表現される。※ エンティティは UUID もしくは名前で識別される。

同じ種類のエンティティがコレクションを構成する。※ コレクションは UUID もしくは名前で識別される。

Usergrid は Cassandra を利用していて、スキーマレスである。■ メリットとデメリット　○柔軟に構造を変えられる　 ×ACID 特性がない（データ整合性の担保が難しい）　 × 列に制約をかけられない

コレクションとエンティティApplication

Collection

Collection /shops

/spots

エンティティの URLhttp://server/<org>/<app>/<collection>/<entity>

コレクションの URLhttp://server/<org>/<app>/<collection>

Organization

REST によるデータアクセス(1) エンティティの作成⇒ HTTP POST メソッド　 curl -X POST "http://server/<org>/<app>/<collection>"　　 -d '{"name":"spotname", …}'

(2) エンティティの参照⇒ HTTP GET メソッド　 curl -X GET "http://server/<org>/<app>/<collection>/<entity>"

(3) エンティティの更新⇒ HTTP PUT メソッド　 curl -X PUT "http://server/<org>/<app>/<collection>>/<entity>"　　 -d '{"name":"spotname", …}'

(4) エンティティの削除⇒ HTTP DELETE メソッド　 curl -X DELETE "http://server/<org>/<app>/<collection>/<entity>"

※<collection> はコレクションの名前もしくは UUID 。他も同様。

Application

Collection

Collection /shops

/spots

データアクセスは REST 形式で行う。

クエリーApplication

Collection

Collection /shops

/spots

Usergrid のデータストアは No-SQL だが、 SQL-likeなクエリーを URL に付与して、エンティティを取得できる。（例） name が‘ Admin User' のエンティティを /users コレクションから取得curl -XGET "http://server/<org>/<app>/users?ql=select%20*%20where%20name%3D%27Admin%20User%27"

■ その他のクエリー機能・ order by による並び替え（昇順、降順）・ limit による取得件数の指定も可能（ cursor で続きを取得可能）

ファイル・アセット管理Application

Collection /pictures

画像などのファイルやアセットを登録・取得できる。・ファイルやアセットもエンティティとして表現されて、指定したコレクションで管理される。■ 画像の登録curl -XPOST -F name='my-image.jpg' -F file=@image.jpg　 -F type=image/jpeg "http://server/<org>/<app>/pictures"

■ 画像ファイルの取得curl -XGET -H 'Accept: image/jpeg' "http://server/<org>/<app>/pictures/3e7299f8-433e-11e6-b0c4-000d3a506890"

■ 画像エンティティの取得curl -XGET "http://server/<org>/<app>/pictures/3e7299f8-433e-11e6-b0c4-000d3a506890"⇒ ファイルサイズ、 Content-Type などの情報を取得できる

3e7299f8-433e-11e6-b0c4-000d3a506890

コネクションによるエンティティの関係付け

コネクションの作成curl -X POST "http://server/<org>/<app>/users/john/likes/spots/yokkaichi"※ ユーザ john からスポット四日市へ likes コネクションを設定する。

Application

Collection

Collection /spots

/users

john

四日市

likes

エンティティ間を関係付けるコネクション< 参照元コレクション >/< 参照元エンティティ >/<relationship>/< 参照先コレクション >/< 参照先エンティティ >

※<relationship> で関係性を記述できる　　 likes, eat, …

コネクションの参照curl -X GET "http://server/<org>/<app>/users/john/likes/spots"※ ユーザ john に likes で関係付けられたスポット情報の一覧を取得する。

Usergrid のアプリケーションデータは、 No-SQL なデータ構造に加えて、エンティティのグラフ構造を併せ持つ

特徴 3ユーザ管理

ユーザ

■/users エンティティの例{ "uuid": "ded66d87-4727-11e6-b0c4-000d3a506890", "type": "user", "name": “john", "created": 1468214724927, "modified": 1468214724927, "username": “john", "email": “john@example.com", "activated": true, "picture":　　 "http://www.gravatar.com/avatar/e64c7d89f26bd1972efa854d13d7dd61",}

Application

Collection /users

ユーザ情報もエンティティとして表現されて、 /usersコレクションで管理される。・ユーザ管理（追加・参照・修正・削除）も REST 形式で行う。

john

ロール

/roles

Application

Collection /users

john

admin

admin

user

users

users

ロールからユーザへ users コネクションで参照している

users

ユーザの役割を定義する。・それぞれ異なるパーミッションが与えられる。

グループ

/aichi

/nagoya

Application

Collection /users

john

admin

グループからユーザへ users コネクションで参照している

/mie

/yokkaichi

john

論理的なグループ構成

/groups

users

/mie/yokkaichi

/mie

/aichi

/aichi/nagoya

実際のグループ構成

階層的なユーザの集まりを定義する。・ /mie/yokkaichi に属するユーザ→ /mie にも属する。・それぞれ異なるパーミッションが与えられる。

パーミッション

/users /groups /roles

ユーザ、グループ、ロールに対して設定可能

エンティティへのパスごとにCRUD の可否を定義する。

認証の種類• ユーザ ID とパスワードで認証する。• 発行されたアクセストークンを用いて REST API を呼び出す。• ユーザに指定されたパーミッションに基づいてアクセスが許可される。

アプリケーションユーザ• アプリケーションクライアントの ID ・シークレットで認証する。• 発行されたアクセストークンを用いて REST API を呼び出す。• AP において、どのような操作も許可される。

アプリケーションクライアント• 組織クライアントの ID ・シークレットで認証する。• 発行されたアクセストークンを用いて REST API を呼び出す。• 組織内において、どのような操作も許可される。組織クライアント• 管理者のユーザ ID とパスワードで認証する。• 発行されたアクセストークンを用いて REST API を呼び出す。• ユーザが所属する組織において、どのような操作も許可される。管理者ユーザ

ユーザ認証の流れ (1/3)① 認証を行い、アクセストークンを取得する。

curl -XPOST "http://server/<org>/<app>/token" -d '{"grant_type":"password", "username":<username>, "password":<password>}'

{　 "access_token": "YWMtDJ14AEjLEeafFxNnD71YkgAAAVYHMm6aIGHAwn7KlfzpF90MtNxZ24kU0ag", 　 "expires_in": 604800,　 "user": { … }}

ユーザ認証の流れ (2/3)② アクセストークンを指定して API にアクセスする。

• 以下の HTTP ヘッダを設定する。• Authorization: Bearer { アクセストークン }

curl –H "Authorization: Bearer YWMtDJ14AEjLEeafFxNnD71YkgAAAVYHMm6aIGHAwn7KlfzpF90MtNxZ24kU0ag"　 -XPOST “http://sever/<org>/<app>/...” –d '{ … } '

ユーザ認証の流れ (3/3)③ ログアウトする。

curl -XPUT "http://server/<org>/<app>/users/<user_uuid_or_username>/revoketokens"

{ "action" : "revoked user token", "timestamp" : 1382050891455, "duration" : 24}

認証• Facebook ログイン

• Facebook の OAuth 認証を使って、 Usergrid の認証を行える。

• 利用方法はともに検証中

特徴 4ソーシャル対応

ソーシャル対応で求められるもの• アクティビティ

• 近年のアプリはデータストリームを扱うことが多い。• コメント、ツイートなど

• アクティビティを記録・取得する機能が求められる。

• ユーザの繋がり• ユーザ同士のつながりを表すソーシャルグラフを管理する。

アクティビティApplication

/users

admin

アクティビティの仕様は、 IBM/Google/Microsoft らが定めた JSON Activity Streams 1.0 (http://activitystrea.ms/specs/json/1.0/) に準拠している

john時系列の流れ

日時　 2016/7/12 13:00:00アクター　 john活動内容　■■にチェックイン日時　 2016/7/13 13:10:00アクター　 john活動内容　★★を食べた

日時　 2016/7/12 18:20:00アクター　 john活動内容　※※で集会を開催

/activities

/groups

/mie/yokkaichi

/mie

/aichi

/aichi/nagoya

ユーザおよびグループの活動を記録する・「ユーザ○○が日時△△に活動 ×× を行った」 アクティビティもエンティティとして表現されて、 /activities コレクションで管理される。

コネクション（ Following ・ Followers ）ユーザの繋がりを管理する。・ Following ：あるユーザが関係をもつ他のユーザ群・ Follower ：あるユーザが関係を持たれている他のユーザ群

Application

Collection /users

john

taro

followingコネクションとしてフォロー先を設定する・ POST http://<server>/<org>/<app>/users/john/following/users/taro・ POST http://<server>/<org>/<app>/users/fred/following/users/taro

Following ・ Follower の取得はコネクションと同じく GET で行う。GET http://<server>/<org>/<app>/users/john/following　⇒ taro が返るGET http://<server>/<org>/<app>/users/taro/followers　⇒ john と fred が返る

following

fred アクティビティとして自動的に記録される

特徴 5ジオロケーション

ジオロケーション

■/spots コレクションのエンティティデータ{ "uuid" : "5c0c1789-d503-11e1-b36a-12313b01d5c1", “type” : "spots", "created" : 1343074620374, "modified" : 1355442681264, “name” : “ 四日市 ", "location": { "latitude": 35. 0, "longitude": 136.61 }}

Application

Collection /spots

位置情報を持ったエンティティに対して、距離を使ったQuery を発行できる。

GET /<org>/<app>/spots　 ?ql=location within 1000 of 35.0, 136.6

※ 北緯 35.0 度、東経 136.6 度の地点から 1000 メートル以内にある spot 情報を取得する四日市

特徴 6プッシュ通知

プッシュ通知• 対応するプッシュ通知

• Apple Push Notification Service • Google Cloud Messaging

• 利用方法は検証中

アプリケーションレイヤー

ユーザインターフェース

データストア

入力値検証

ビジネスロジック

スマホアプリor

Web アプリ

Usergrid

スマホアプリor

Webアプリ

Usergrid

AP サーバor

Azure Functionsor

AWS Lambda

2 層 3 層

Usergrid はデータストア機能しか提供しないため、入力値検証とビジネスロジックはAP サーバを構築するか、アプリで実装する必要がある。 プロトタイプはこ

の形式

Usergrid 利用アプリのシステム構成例

Apache Usergrid (mBaaS)

ユーザ登録 対戦結果管理 ゲット履歴管理ユーザ認証

Azure API ManagementAmazon API Gateway

アプリ

Cassandra

Azure FunctionsAWS Lambda

ビジネスロジック

Ubuntu Linux

ElasticSearch Tomcat Apache httpd

HTTPS

AP サーバ

WebAPI

将来に WebAPI サーバを構築した場合でも、アプリが利用する API は変更されない。

DB サーバ

＋

まとめスキーマレスなデータ構造• データ構造が決まっていない段階でアプリ開発のサーバ環境を迅速に構築できる• 開発中のデータ構造の変更が容易である

REST で統一されたデータ／ユーザ／ファイル管理• AP からのデータ操作が統一されるため、処理を作成しやすい

グラフ指向のデータ構造• エンティティ間の関係性を記述できる