Apache ProjectのmBaaSであるUsergridを紹介します。 Usergridのサーバ構築方法、AP側のSDKやサンプルコードなどは改めて取り上げたいと思います。

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

2. Usergridとは

3. 背景
• 短納期でのアプリ開発でサーバ構築をどうするか？
• データ構造が決まらない、開発中に変更される…
• ユーザ管理、アクセス権限管理の作り込みが大変…
• データ操作のAPIの開発を素早く行いたい…

4. Usergridとは
• Apache ProjectのBaaS
• 2011年からOSSとして公開されている
• ユーザ管理・データ管理・ファイル管理の機能を提供する
• データ管理・操作体系が統一されていて、どれもエンティティとそのコレク
ションとして管理されて、それらをRESTで操作する
• バックエンド
• Apache Cassandra：分散型NoSQLデータベース
• ElasticSearch ：分散型検索エンジン
• Apache Tomcat ：Java Web APサーバ
• AzureやAWSなどのクラウドに配置できる

5. Usergridの特徴
1. マルチテナント対応
2. グラフ指向のアプリケーションデータ
• コレクションとエンティティ
• コネクションによるエンティティの関係付け
3. ユーザ管理
• ユーザ、パーミッション、ロール、グループ
4. ソーシャル
• ユーザアクティビティ
• コネクション（フォロー、フォロワー）
5. ジオロケーション
6. プッシュ通知

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

7. マルチテナント対応
Organization Organization
Usergrid
Application
Application
…
Application
…
…
組織を定義して、各組織ごとにアプリケー
ションを定義するマルチテナント構造
スーパーユーザ
（システム管理者）
組織管理者 組織管理者
Usergrid全体の管理者と、組
織ごとの管理者がある

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

9. コレクションとエンティティ
■/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特性がない（データ整合性の担保が難しい）
×列に制約をかけられない

10. コレクションとエンティティ
Application
Collection
Collection /shops
/spots
エンティティのURL
http://server/<org>/<app>/<collection>/<entity>
コレクションのURL
http://server/<org>/<app>/<collection>
Organization

11. 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形式で行う。

12. クエリー
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%27
Admin%20User%27"
■その他のクエリー機能
・ order byによる並び替え（昇順、降順）
・ limitによる取得件数の指定も可能（cursorで続きを取得可能）

13. ファイル・アセット管理
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

14. コネクションによるエンティティの関係付け
コネクションの作成
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なデータ構
造に加えて、エンティティのグラフ構造を併せ持つ

15. 特徴3
ユーザ管理

16. ユーザ
■/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

17. ロール
/roles
Application
Collection /users
john
admin
admin
user
users
users
ロールからユーザへusersコネ
クションで参照している
users
ユーザの役割を定義する。
・それぞれ異なるパーミッションが与えられる。

18. グループ
/aichi
/nagoya
Application
Collection /users
john
admin
グループからユーザへusersコ
ネクションで参照している
/mie
/yokkaichi
john
論理的なグループ構成
/groups
users
/mie/yokkaichi
/mie
/aichi
/aichi/nagoya
実際のグループ構成
階層的なユーザの集まりを定義する。
・/mie/yokkaichiに属するユーザ→/mieにも属する。
・それぞれ異なるパーミッションが与えられる。

19. パーミッション
/users /groups /roles
ユーザ、グループ、ロールに対
して設定可能
エンティティへのパスごとに
CRUDの可否を定義する。

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

21. ユーザ認証の流れ(1/3)
①認証を行い、アクセストークンを取得する。
curl -XPOST "http://server/<org>/<app>/token" -d '{"grant_type":"password", "username":<username>,
"password":<password>}'
{
"access_token": "YWMtDJ14AEjLEeafFxNnD71YkgAAAVYHMm6aIGHAwn7KlfzpF90MtNxZ24kU0ag",
"expires_in": 604800,
"user": { … }
}

22. ユーザ認証の流れ(2/3)
②アクセストークンを指定してAPIにアクセスする。
• 以下のHTTPヘッダを設定する。
• Authorization: Bearer {アクセストークン}
curl
–H "Authorization: Bearer YWMtDJ14AEjLEeafFxNnD71YkgAAAVYHMm6aIGHAwn7KlfzpF90MtNxZ24kU0ag"
-XPOST “http://sever/<org>/<app>/...” –d '{ … } '

23. ユーザ認証の流れ(3/3)
③ログアウトする。
curl -XPUT "http://server/<org>/<app>/users/<user_uuid_or_username>/revoketokens"
{
"action" : "revoked user token",
"timestamp" : 1382050891455,
"duration" : 24
}

24. 認証
• Facebookログイン
• FacebookのOAuth認証を使って、Usergridの認証を行える。
• 利用方法はともに検証中

25. 特徴4
ソーシャル対応

26. ソーシャル対応で求められるもの
• アクティビティ
• 近年のアプリはデータストリームを扱うことが多い。
• コメント、ツイートなど
• アクティビティを記録・取得する機能が求められる。
• ユーザの繋がり
• ユーザ同士のつながりを表すソーシャルグラフを管理する。

27. アクティビティ
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コレクションで管理される。

28. コネクション（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 アクティビティとして自動的に
記録される

29. 特徴5
ジオロケーション

30. ジオロケーション
■/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情報を取得する
四日市

31. 特徴6
プッシュ通知

32. プッシュ通知
• 対応するプッシュ通知
• Apple Push Notification Service
• Google Cloud Messaging
• 利用方法は検証中

33. アプリケーションレイヤー
ユーザ
インターフェース
データストア
入力値検証
ビジネス
ロジック
スマホアプリ
or
Webアプリ
Usergrid
スマホアプリ
or
Webアプリ
Usergrid
APサーバ
or
Azure Functions
or
AWS Lambda
2層 3層
Usergridはデータストア機能しか提供しないため、入力値検証とビジネスロジックは
APサーバを構築するか、アプリで実装する必要がある。
プロトタイプはこ
の形式

34. Usergrid利用アプリのシステム構成例
Apache Usergrid (mBaaS)
ユーザ登録 対戦結果管理 ゲット履歴管理ユーザ認証
Azure API Management
Amazon API Gateway
アプリ
Cassandra
Azure Functions
AWS Lambda
ビジネスロジック
Ubuntu Linux
ElasticSearch Tomcat Apache httpd
HTTPS
APサーバ
WebAPI
将来にWebAPIサーバを
構築した場合でも、アプ
リが利用するAPIは変更
されない。
DBサーバ
＋

35. まとめ
スキーマレスなデータ構造
• データ構造が決まっていない段階でアプリ開発のサーバ環境を迅速に構築できる
• 開発中のデータ構造の変更が容易である
RESTで統一されたデータ／ユーザ／ファイル管理
• APからのデータ操作が統一されるため、処理を作成しやすい
グラフ指向のデータ構造
• エンティティ間の関係性を記述できる