2015-01-20

　年末年始でじっくり調べてみようと思っていたのがCognitoです。先日ようやく時間が取れて、何となく解ってきたので簡単にまとめてみます。Cognitoは、モバイル向けに設計されたユーザーアイデンティティおよびデータ同期のサービスです。主な機能としては、以下の3点です。

FacebookやGoogleなどのOpenID ConnectベースのIdentity Providerを利用して認証できる
Cognito Syncで、同一ユーザの複数の端末のデータを同期できる
認証／未認証のユーザにIAM Roleを利用して、AWSリソースのアクセス制御

　上記の説明を聞いても、Cognitoの良さはさっぱり解らないと思います。私もCognitoの説明を読んでも、Facebookで認証できるのかぁくらいにしか感じませんでした。Cognito Syncの同期機能も、ほーっと思ったけど必要とする場面はどれくらいあるのだろうなぁと思いました。

Cognitoの重要性

　しかし、Cognitoのユースケースが出始めることで、ようやくCognitoの重要性が解ってきました。Cognitoの重要な機能は、安全簡単にAWSリソースのアクセス制御ができることなのだと思います。モバイル・アプリの場合、サーバサイドのプログラムのようにアクセスキーとシークレットアクセスキーを埋め込むことはできません。配布するために、アプリ内からキーを取り出される可能性があるからです。かといって、インスタンスのようにIAM Roleを発行するということも出来ません。モバイルからAWSのリソースを利用しようとすると、従来であればSecurity Token Service（STS）とToken Vending Machine（TVM）を利用して一時的な認証と認可の仕組みを構築する必要がありました。
　これ非常に面倒くさいですよね。ということで、どういうアーキテクチャが主流だったかというと、下の図のような形だと思います。

f:id:dkfj:20150119232504p:plain

　いわゆる三層構造（3Tier Architecture）です。AWSのリソースの制御はEC2側でやってしまって、モバイル側には結果をJSON等で返すだけという形です。この構成だと、当然全てのリクエスト・レスポンスがEC2を通ることになるので、この部分の性能と可用性が重要になります。必然的に、ELBやAutoScalingを利用することになります。EC2は、直接的な利用料がAWSサービスの中でも比較的高いことや、構築運用監視に人手が必要なため、コストが高くつきます。

Cognitoがもたらすアーキテクチャの変化

　では、Cognitoを利用するとどう変わるのでしょうか？EC2を経由せず、モバイルから直接AWSのリソースにアクセスする構造を簡単に実現できます。2Tier構成です。

f:id:dkfj:20150119233617p:plain

　CognitoはIAM Roleを利用して、認証／未認証のユーザにそれぞれアクセス認可を与えることができます。この未認証ユーザにもというところが味噌で、これのお陰でモバイル・アプリに簡単安全にアクセス認可する仕組みとして利用できます。事実、CognitoのIdentity Poolを作成する時に、実はIdentity Providerの設定は必須ではありません。実装面では、Cognitoの設定をしておけば、後はSDKを取り込んで少しコードを書くだけで、簡単に利用可能です。従来のようにSTS+TVMを使って独自の認証認可の仕組みを実装する必要はありません。Cognitoのウリは、安全簡単に認可の仕組みを組み込めるので、アーキテクチャすら変える力があるということです。

まとめ

　ということで、ここ最近Cognitoについて考えてきたことをまとめてみました。Cognitoは、2Tierアーキテクチャの要になると思います。ただ、まだドキュメント読んだりサンプルコードを動かしているレベルなので、今後本格的にアプリを開発し運用してみると考え方は変わるかもしれません。しかし、Lambdaが出てきたこともあり、AWSはシステムのアーキテクチャ自体を変えるような何かを考えているのではと思います。今年はそこを見極めてみたいですね。たぶんそのうちに、Node.js向けのCognito SDKもでるでしょうし。ツッコミどころあれば、ご指摘頂ければ幸いです。