AWS Cognito(4)Cognitoストリーム

Cognitoストリームとは

Cognito Datasetに蓄積されたデータを取得するためには、Cognitoストリームを設定してKinesis経由でデータを出力する必要がある。Cognitoストリームを設定すると、Cognito Datasetに変更が生じる度にKinesisにそのデータを入力することができる。

Cognitoストリームの設定

Cognitoのダッシュボードから「Edit identity pool」をクリックし、Cognito Streamの項目を編集する

Cognitoストリームの設定

Kinesis stream名とシャード数を設定する

  • 「Create stream」をクリック
  • シャードとはKinesisの入出力処理のパイプの太さを表す

Kinesisストリームの作成

ロール設定を行う

  • 「Create role」をクリック
  • ロール名が自動入力されるので、作成ウィザードで登録を行う

ロールの設定

有効化する

  • 「StreamStatus」を「Enabled」に設定することで、Cognito Streamが有効化される

設定変更を実行する

  • また、上記の設定を行った上で「Save Changes」をクリックしてもストリーム名、シャード、ロールなどがきちんと反映されていない場合があるので、反映されているか確認することが重要である
  • ユーザのロール設定と同様に、先ほど作成したロールのポリシーを確認する
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "kinesis:PutRecord"
      ],
      "Resource": [
        "arn:aws:kinesis:ap-northeast-1:172664222583:stream/STREAM_NAME"
      ]
    }
  ]
}

なお、Bulk publishをクリックすることでこれまで蓄積されたCognito DatasetをKinesisに一括で送り出すことが可能だが、24時間に1回しか実行できないことに注意が必要である。

ストリームレコード

CognitoからKinesisへは、以下のフォーマットでレコードが送信される。

{
  "identityPoolId" : "Pool Id"
  "identityId" : "Identity Id "
  "dataSetName" : "Dataset Name"
  "operation" : "(replace|remove)"
  "kinesisSyncRecords" : [
    { 
      "key" : "Key",
      "value" : "Value",
      "syncCount" : 1,
      "lastModifiedDate" : 1424801824343,
      "deviceLastModifiedDate" : 1424801824343,
      "op": "(replace|remove)"
    },
    ...
  ],
  "lastModifiedDate": 1424801824343,
  "kinesisSyncRecordsURL": "S3Url",
  "payloadType" : "(S3Url|Inline)",
  "syncCount" : 1
 }

AWS CLI経由でコマンドを入力することで、Cognitoから正常にレコード入力されているかの確認を行うことが可能である。

AWS EC2(1)EC2の概要

EC2(Elastic Compute Cloud)とは

EC2は、クラウド内で規模の変更が可能なコンピュータ処理能力を提供するウェブサービス。様々な種類の仮想サーバを起動し、Webコンソールやターミナルから操作することが可能である。

リージョンとアベイラビリティーゾーン

東京リージョンは、コード名:ap-northeast-1、名称:アジアパシフィック(東京)である。AWS SDK for Javaなどは、デフォルトのリージョンがバージニア州(us-east-1)に指定されていることに注意が必要である。すべてのインスタンスを 1 か所でホストしている場合、同じ場所にあるインスタンスすべてに影響する障害が起きたときに、インスタンスがすべて利用できなくなるため、複数のアベイラビリティゾーンにインスタンスを分散配置することが望ましい。

インスタンスを起動するときは、同じリージョン内にある AMI を選択する必要がある。AMI が別のリージョンにある場合は、これから使用するリージョンに AMI をコピーできる。異なるアベイラビリティゾーンにインスタンスを移行したい場合は、AMIを作成し、このAMIを用いて希望するアベイラビリティゾーンにインスタンスを生成する。

アベイラビリティーゾーンは、各アカウントの識別子に個別にマッピングされる。つまり、アカウントAのap-northeast-1aと、アカウントBのap-northeast-1aは、同じアベイラビリティゾーンを指していない場合がある。また、各アカウントごとに指定できるアベイラビリティゾーンの使用が制限され、アカウントによってリージョン内で使用できるアベイラビリティーゾーンの数が異なる場合がある。

リージョンとアベイラビリティーゾーンに関する概念

インスタンスファミリー

利用用途に合わせて様々なインスタンスの種類が存在する。

カテゴリ 名称 特徴/用途
汎用 M4 通常用途
バーストパフォーマンス T2 普段は殆ど負荷がないが一時的に負荷がある 開発機、小規模システム
コンピューティング最適化 C4 CPU性能が必要な用途 APサーバ、画像処理
メモリ最適化 R3 コアあたりのメモリが大きく大量のメモリが必要な用途 DBサーバ
ストレージIO最適化 I2 高速なIOPSを実現するSSDを内蔵 DBサーバ、ビッグデータ
ストレージ密度最適化 D2 大容量HDDを内蔵 DBサーバ、ビッグデータ
GPUインスタンス G2 GPUコアが必要な用途 グラフィック表示、画像処理

IP

  • Elastic IP
    • 明示的に割り当てられたIP。使用していないと課金される
  • Public IP
    • ランダムに割り当てられるPublic IP
    • EC2をStop/Startすると別のIPが割り当てられる
  • Private IP
    • 必ず割り当てられるIP
    • EC2をStop/Startしても同じIPが割り当てられる

Amazon Linux

デフォルトユーザはec2-user、sudo権限が付与されている。

OpenStack Summit Tokyo 2015(2)日本におけるOpenStackの現状

OpenStack Sumit Tokyo 2015「日本でのOpenStack、企業の導入状況と今後の活用予測」(2015/10/27 17:30-)より。OpenStackは今後も活用が広がっていくだろうとのこと。

日本におけるOpenStackの現状

大企業の6-7割、中小企業の2-3割が仮想化技術を用いたサーバ管理を行っている。このうちのほとんどがVMWare社製品を用いた仮想化である。 OpenStackは楽天やYahoo!Japanなどの大手が徐々に導入を始めている。日本は技術に関心がある層が非常に厚いが、品質を求めすぎるため に導入までに非常に時間が掛かるのがネック。また、SIerにシステム開発を依存しているのが日本企業の特徴である。とはいえ、日本の大企業は皆こぞって AWSを使っている。AWSは可用性や耐障害性があるのでAWSを使うことで仮に基幹系の一部のアプリが止まってしまうリスクが増加したとしてもそれを超えるメリットがAWSにはある、と言い切る 企業すらある。これからプライベートクラウドの利用も進み、OpenStackの利用も増えていくのではないか。

日本の企業のOpenStack導入事例

株式会社DeNAでは、事業の多角化を進めており非常に多くの案件が動いているため、多くのサーバのリソースを必要としている。これをOpenStack等の仮想化、自動化技術で解決したい。ネットワークに関してもネットワーク専任部署を設けてお任せするのではなく、自分たちできちんとネットワークも使いこなしたい。AWSは安価だと言われることもあるが必ずしもそうではない。大きなオンプレミス環境を持っているところは、オンプレミス環境の方がコストメリットがある。OpenStackは確かにバグも多いが、数年前に比べて大きく改善している。DeNAでは4-5名の担当者でOpenStackの運用からリサーチまで行っている。OpenStackは複雑なシステムではあるが、これを利用するほうが敷居が低い。例えば、スタートアップ系の企業は、AWSは料金が高すぎて使いづらいと言っている。

株式会社サイバーエージェントは、OpenStackを用いてサーバを300台以上を構築しており主にアドテク系で仕様している。OpenStackはバージョンアップが非常に早く、2世代前のバージョンをサポートしないのでどのように対応していくべきか迷っている。稼働させながらバージョンアップすることも可能ではあるが、難しいので結局新しいサーバをセットアップさせて移行している。AWSなどのバプリッククラウドよりも安価にそして性能よくしたいと考えている。運用担当者は現状3名だがもう少し欲しいところ。

その他のセッション

Getting Started With OpenStack, Hands-On Lab
spotzz/openstack2015-gitandgerrit・GitHub

PayPal’s Cloud Journey From Folsom to Kilo

Clusters, Routers, Agents and Networks: High Availabirity in Neutron
fghaas/openstacksummit2015-tokyo-neutron-ha・GitHub

AWS Cognito(3)OpenID Connectとの連携

OpenID Connect Provider Identifierの登録

AWS CognitoはOpenID Connectによる認証に対応している。OpenID ConnectのIdentifierを登録することで、FacebookやGmailなどの既存のパブリックログインプロバイダに加えて利用できる。

登録方法

OpenID Connectのプロバイダの登録はCognito設定画面上ではなく、IAMで行う。IAMから「Identity Provider」をクリックすると登録画面が現れるので、新規で作成する場合は「Create Provider」をクリックする。

OpenID Connect プロバイダの登録

認証プロバイダは「SAML」と「OpenID Connect」から選択可能であるので、「OpenID Connect」を選択。

プロバイダタイプの選択

OpenID Connectによる認証を追加する場合は、「Provider URL」と「audience」の情報が必要となる。

OpenID Connectの設定

Yahoo! Japan(YConnect)との連携

ここで試しに、Yahoo! Japanが提供している認証サービス「YConnect」をCognitoに登録してみる。日本でOpenID Connectによる認証に対応している有名処はYahoo! Japanの他に、mixiやIIJなども存在するようである。

プロバイダーの設定エラー

プロバイダーの設定エラー

しかし、登録の際に問題が生じる。

YConnectのOpenID Provider Configuration DocumentのURLは、
https://auth.login.yahoo.co.jp/yconnect/v1/.well-known/openid-configuration

一方で、このOpenID Provider Configuration Document内のissuerのURLは、
https://auth.login.yahoo.co.jp

となっている。

OpenID Connect Discovery 1.0 incorporating errata set 1には、issuerのURLに.well-known/openid-configurationを付加したURLがOpenID Provider Configuration DocumentのURLとなると記述があるが、YConnectでは両者のURL間にズレが生じている。その結果として、IAMに登録する際に以下のエラーメッセージが表示されてしまう。

Please check .well-known/openid-configuration of provider: https://auth.login.yahoo.co.jp/yconnect/v1/ is valid.

ということで、YConnectのCognitoへの登録は断念。

IIJなどはきちんとCognitoに登録できるので、YConnectがOpenID Connectの仕様に準拠していないのが原因か。Cognitoの設定は、なかなか一筋縄にはいかない。

OpenStack Summit Tokyo 2015(1)キーノート

日本初開催となるOpenStack Sumit Tokyo 2015に参加してきました。会場は品川のグランドプリンス新高輪、国際館パミール。OpenStackがいかに急速に発展し熱気あるプロジェクトであるか、ということを肌で感じたカンファレンスでした。

キーノート

まずはキーノートから。数日前にリリースされたOpenStack Libertyの話から企業の導入事例まで。

Keynotes Day 2

OpenStack導入事例

Lithiumは、マイクロサービスの即時実行サービスを提供している。AWS, OpenStack関係なくデプロイ、実行が可能である。ワニを撃ち落とすこんなゲームも、プログラムを変更してデプロイすればすぐにサービスに反映させることができる。

Yahoo! Japanは、月間650億PVある日本最大のポータルサイトを運用している。うちモバイルからが319億PVである。OpenStackを用いて100ラック分、4000台のマシンで運用している。天災アプリを提供していることもあって、地震発生の数十秒後にアクセスにスパイクが立つ。エンタプライズ市場でOpenStackは利用されるのかという議論があるが、Yahoo! Japanではアプリケーションの実装次第で活用できると考えている。同じAPIを提供することでデータセンタの抽象化ができるのが大きなメリットで、使っているハードウェアのライフサイクルを明確化し、移行計画を立てることも可能となる。2013年より前はIaaSを自分たちで作っており、全てのアプリケーションを自分たちで作成する必要があったが、OpenStack導入後は汎用的な部分はコミュニティにお任せして、特殊な機能の実装に集中することができるようになった。

Keynotes Day 2

Cloud Hostingを行っているbitnamiは、シャドークラウドをいかに無くすかという点が重要であると考えている。俊敏性や使い勝手がよくないと皆勝手に別のクラウドサービスを利用してしまう。

NTT Resonantは、日本で第3位のポータルサイトを運営している。月間PVは10億PVで、1800VM、4000Hypervisorを使用している。アップデートの時に障害ポイントになり得るので、カスタマイズして使うということはしていない。また、Puppet、Zabbixの利用など、既存の運用やツールは極力活用している。

Booth Crawl Happy Hour

OpenStack Liberty

10月16日に12番目のリリースとなるLibertyがリリースされた。今回からOpenStackは、主要機能であるCoreと周辺機能Big Tentにプロジェクトが分割された。成熟し開発が落ち着いたプロジェクトもあればまだまだ発展途上のプロジェクトもあるが、中でも現在最も急激に進化を遂げているのはネットワーク機能を提供するNeutronである。SDN市場は昨年比2倍で成長しているが、NeutronにはSDNコントローラも実装されSDNに対応している。また今回、コンテナのネットワークを接続する「Project Kuryr」が登場する。

Lunch Buffet

AWS DynamoDB(1)DynamoDBの概要

DynamoDBとは

DynamoDBは高速かつフレキシブルな、完全マネージド型のNoSQLデータベース。データはKey, Value型で保存される。高速なレスポンススケーラビリティドキュメントデータモデル(JSON)をサポートしていることなどが特徴的。同一リージョン内の3つの設備で同期レプリケーションされるため障害にも強い。

管理不要で信頼性が高い

  • 単一障害点が存在しない構造
  • 同一リージョン内の3つの設備にデータが保存される
    • 設定と構成、レプリケーション、ソフトウェアのパッチ適用などが不要
  • ストレージの自動パーティショニング

プロビジョンドスループット

  • Read/Writeの速度を指定できる
    • ダウンタイムやパフォーマンスの低下が生じない

1キャパシティユニットは、最大4KBの読み込み項目に対して、1秒あたり1回の強力な整合性のある読み込み、もしくは1秒あたり2回の結果整合性のある読み込み最大1KBの書き込み項目に対して、1秒あたり1回の書き込みを表す単位。読み込みや書き込みのリクエストがプロビジョニングしたスループットを超えた場合は、HTTP 400 コード (Bad Request) : ProvisionedThroughputExceededExceptionのエラーレスポンスが返る。DynamoDB Auto Scalingを用いることで、キャパシティを自動的に変更することが可能であるが、バーストトラフィックには対応できないので注意が必要である。

2018年からプロビジョニングモードに加えて、前に到達したトラフィックレベルまで拡張または縮小(前のピークトラフィックの最大 2 倍まで瞬時に対応)して、ワークロードを即座に受け入れることができるオンデマンドモードを指定することが可能となった。プロビジョニングモードとオンデマンドモードは、24時間に1回切り替えることができる。プロビジョニングモードからオンデマンドモードに切り替えた場合、プロビジョニングされたキャパシティーが維持されるため、大量のトラフィックが予想される場合は、プロビジョニングモードで想定されるキャパシティを設定しておき、その後オンデマンドモードに切り替えると良い。

その他の特徴

  • 容量制限が存在しない
  • 結果整合性
    • 書き込みに関しては、2箇所への書き込みが完了した時点でACK
    • 読み込みに関しては、最新の結果が反映されていない可能性がある

複数のクライアントが同時にアクセスし値を更新するようなシナリオの場合は、「現在この値であれば値を更新する」といったような条件付き書き込みを行うことで、想定外のデータ上書きを防止することが可能である。

条件付き書き込み

料金

  • 指定したスループットによる時間課金
  • 保存データ量による課金

DynamoDBへのアクセスにはHTTPおよびHTTPSが用いられる。HTTP/HTTPSによる通信はオーバヘッドが大きいため、ゲームアプリ等の早い応答速度が求められるサービスでは、DyamoDBではなくRDSなど他のデータベースを選択することが多い。シリアライズフォーマットとしては、JSON形式が使用される。

データモデル

DynamoDBのテーブルは複数のItemから構成され、Item内には、KeyValue型のデータ(Attributes)が格納されている。各Itemに格納されているAttributesの数は不ぞろいでも良く(スキーマレス)、あるアイテムにはuser-id, name, e-mail, ageの4つのAttributesが、別のItemにはuser-idのみが格納されているとことも可能である。格納するAttributesのうち1つにPartitionKeyを指定する。PartitionKeyはプライマリーキーとして利用でき、ハッシュインデックスを構築されるときのキーとなる。この場合同じ項目を持つPartitionKeyは持つことができない。また、SortKeyを指定することもでき、この場合はPartitionKey + SortKeyでプライマリーキーとなる。

DynamoDBは、数値や文字列、バイナリ(圧縮ファイルや画像)などのスカラー型、これらのスカラー型をセットにしたセット型、リストやマップ(JSON)などのドキュメント型の3つの形式をサポートしている。格納することのできる値の範囲や制限事項などは、DynamoDB での制限 – Amazon DynamoDBを参照のこと。文字列や多値データセット型は空白や空白セットはサポートされていない。スカラー型の場合、NULL値を格納することは可能である。ドキュメント型を用いることで入れ子構造のデータを保存することも可能である。

DynamoDBには予約語が存在し、予約語を属性名として定義する式を実行することはできない。予約語と競合する属性名を式の中で使用したい場合には、代替の属性名を定義するなどし使用する。

パーティショニング

DynamoDBは、スループット性能を維持するためテーブルをパーティショニングする。PartitionKeyが同じでSortKeyが異なる項目は、SortKeyによって並べ替えられて物理的に近いところに配置される。パーティション間のデータ分散にはPartitionKeyを用いられ、またスループットは各パーティションに均等に配分されるために、特定のPartitionKeyにアクセスが偏ると性能が出ない場合がある

セカンダリインデックス(Secondary Index)

セカンダリインデックスは、SortKey以外に使用することのできる絞込み検索用のAttributesである。ローカルセカンダリインデックス(local Secondary Index)はSortKeyの代替となる検索用インデックスで、同一PartitionKeyのItem検索に利用できる。グローバルセカンダリインデックス(Glocal Secondary Index)は、PartitionKeyの代替となる検索用インデックスで、異なるPartitionKeyのItem検索にも利用できる。セカンダリインデックスは便利ではあるが、追加のスループットやストレージを必要とするためRDSで代替できないか検討すべきである。

テーブルあたり20個のグローバルセカンダリインデックスと5つのローカルセカンダリインデックスを定義することができる。

項目の操作

DynamoDB は、作成、読み込み、更新、削除 (CRUD) の 4 つの基本的なオペレーション機能を提供する。また、以下に加えて、複数のGet/Put処理を1回の呼び出しで行うBatchGetItem/BatchWriteItemという関数も用意されている。

  • PutItem – 項目の作成
  • UpdateItem – 項目の更新
  • GetItem – 項目の読み取り
  • Query – 特定のPartitionKeyがある全ての項目の読み取り
  • Scan – 指定されたテーブルまたはインデックスの全ての項目の読み取り
  • DeleteItem – 項目の削除

また、Time to Live(TTL)を用いてテーブルの項目の有効期限を設定することが可能で、データベースから項目を自動的に削除することができる。指定する時刻はUnixtimeで、DynamoDBはこの期限から48時間以内に項目を削除する。有効期限すぐに削除されるとは限らないために、これを考慮したアプリケーション実装とすることが必要。

DynamoDB ストリーム

DynamoDBストリームは、DynamoDBテーブルのデータ変更イベントをキャプチャする。ストリームには24時間の有効期限があり、Lambdaや等を用いてこれらのストリームデータの処理を行うことができる。

DynamoDBストリームは、変更前のイメージと変更後のイメージの両方を含むことができるため、これらを比較することで変更の差分を取得することができる。

AWS Cognito(2)JavaScriptによるクライアントの実装

前回のCognitoのAWS側の設定に続いて、今回はWebコンテンツ側でCognito認証を利用する際のJavascript SDKを用いた実装方法について確認する。AWS Javascript SDKを用いたCognitoの認証はサーバ側にスクリプトを用意する必要がなく、S3などを用いて安価にWebサーバを構築することが可能である。

なお、AWSの認証情報とパブリックログインプロバイダから取得したトークンは、一定期間後に認証切れとなる。Cognitoはトークンの再取得についての機能は提供していないが、多くのパブリックログインプロバイダはリフレッシュトークンを用いたトークンの再取得をサポートしている。

Javascriptによる実装

AWS Javascript SDKを用いたCognitoの認証とデータ同期の実装は以下の通り。

  • AWS Javascript SDK のインポート
  • Amazon Cognito Sync Manager for JavaScript の取得とインポート
    • Cognito Sync(データセットの同期)処理をライブラリで提供している
    • Github からライブラリファイルを取得し、配置する
<script src="https://sdk.amazonaws.com/js/aws-sdk-2.2.6.min.js"></script>
    <script src="amazon-cognito.min.js"></script>
  • Credentials Objectを初期化する
    • AWS.CognitoIdentityCredentialsクラス を利用する
    • オブジェクト初期化には、Cognito Identity Pool IDとパブリックログインプロバイダのトークンを用いる
// Cognito認証を行う
    // 
    // @param {String} provider provider name
    // @param {String} token token
    // @param {Object} data data
    function getIdentityId(provider, token, data){

    		var logins = {};
    		// insert key of associative array in a variable
    		logins[provider] = token;
    		log("You have SUCCESSFULLY logged in. provider: " + provider + " token:" + token);
    		// region (tokyo)
    		AWS.config.region = 'ap-northeast-1';
    		// authentication providers
    		if(provider!=null && token!=null){
    			AWS.config.credentials = new AWS.CognitoIdentityCredentials({
        				// identity pool id
        				IdentityPoolId: 'ap-northeast-1:**********',
        				// provider name and token
        				Logins: logins // object (associative array)
    			});
    		// unauthenticated identities
    		}else{	
    			AWS.config.credentials = new AWS.CognitoIdentityCredentials({
        				IdentityPoolId: 'ap-northeast-1:**********',
    			});
    		}
    		//
    		// 以下に続く
    		//
    	}
  • 作成したCredentials Objectを用いて、Cognito IDを取得する
    • AWS.config.credentials.get()
    • Cognito IDは、 AWS.config.credentials.identityIdで取得できる
		AWS.config.credentials.get(function(err) {
            		if (!err) {
                			//
                			// データセット処理
                			//
            		}else{
                			log("Error Occurred: " + err);
            		}
    		});
  • データの保管と同期を行う( Amazon Cognito Sync Manager
    • syncClient.openOrCreateDataset()
    • dataset.put()
    • dataset.synchronize()
	AWS.config.credentials.get(function(err) {
            		if (!err) {
                			log("Cognito Identity Id: " + AWS.config.credentials.identityId);
    				var syncClient = new AWS.CognitoSyncManager();
    				if(data != null){
    					// open or create dataset
    					syncClient.openOrCreateDataset(provider, function(err, dataset) {
    						$.each(data, function (key, val) {
    							dataset.put(key, val, function(err, record){
                    						log("Put Dataset: { " + key + ": " + val + " }");
    							});
    						});
    						// synchronize dataset
    						dataset.synchronize({
    							onSuccess: function(data, newRecords) {	
                    						log("Syncronize Dataset: { " + provider + " }");
    							},
    							onFailure: function(err) {
                    						log("Error Occurred: " + err);
    							}
    						});
    					});
    				}else{
    					log("NOT Syncronize Dataset: no data");
    				}
    			}else{
    				log("Error Occurred: " + err);
    			}
    		});

Cognitoには各ユーザごとに保存領域が用意されており、各ユーザごとに複数のデータセット(テーブル)を持つことができる。ユーザデータは一旦ローカル上に保管されるため、通信状況には影響しない。ローカルに保存されたデータセットは、明示的に同期メソッドを実行した際にAWSと同期される。同期の際にデータが衝突した場合は、ローカルを優先するかAWSを優先するか選択することができる。詳細は、Amazon Cognito Sync Manager for JavaScriptに記述されている。

AWS Kinesis(1)Kinesisの概要

Kinesisとは

Kinesisは、大量のデータを受け付けて配信先に順序通りに配信するバッファ機構である。Kinesisを利用することで高速かつ継続的にデータの取り込みと集約を行うことが可能であり、ログデータやセンサーデータなどの継続的に入力されるストリームの処理に適している。Kinesisにデータが入力されて取得できるようになるまでは1秒未満である。瞬時に処理を実行することが可能である。各クライアントから直接S3やDynamoDB, RDS等にデータ入力するのと比べ、より信頼性が高く安価なシステム構築が可能である。なお、データレコードは通常はストリームに追加されてから24 時間のみアクセス可能(オプションを使用すれば、最大168時間までアクセス可能)である。

Amazon Kinesis の主要なコンセプト - Amazon Kinesis

Kinesisに入力されたデータは、 Amazon Kinesis Client Library を用いたプログラム( Amazon Kinesis Application)をEC2上で動作させることで、加工や抽出・他のデータベースへの転送を行うことができる。Amazon Kinesis Applicationは、 DynamoDB上に制御テーブルを用意して、現在のチェックポイントを記録する。このため複数のプログラムを同時に実行させて、重複することなく並列でデータ処理を行うことが可能である。Application名は一意である必要があり、DynamoDBの制御名にも利用される。なお、「シャード」は、Kinesis上のデータ処理経路を、「プロデューサ」はKinesisへのデータの入力部分を、「コンシューマ」はKinesisからのデータ取得部分(役割)を指す。

レコードの順序

シャードイテレータは、シャード単位でデータを取得する。データの取得方法に関しては以下の4つが規定されている。

ShardIteratorType 取得方法
AT_SEQUENCE_NUMBER 特定のシーケンス番号からデータを取得
AFTER_SEQUENCE_NUMBER 特定のシーケンス番号の次のデータを取得
TRIM_HORIZON シャードの中でトリムされていない一番古いデータから取得
LATEST シャードの一番新しいデータから取得

レコードを取得(GetRecords)する際には、レコード毎に付与されたシーケンス番号がキーとなる。シーケンス番号は、シャード単位で管理されており、レコードを入力(PutRecords)した際にシャードごとにインクリメントされる。したがって、シーケンス番号順に取得するということは、すなわち各シャードに入力されたレコードを時系列順に取得するということと等しい。

ただし、シーケンス番号はシャード単位で管理されているため、1つのKinesis Client Libraryが、複数のシャードから同時にレコードを取得した場合などは、複数シャードのレコードが混在して取得されることから、取得データが時系列順に並ぶとは限らない。また、シャードへのデータ入力処理は並列で実施されるために、シャードへレコードが同時に入力された場合には、シーケンス番号が意図した通りにインクリメントされるとは限らない。レコード入力の際に、シャード内で厳密にシーケンス番号をインクリメントさせる場合には、SequenceNumberForOrderingパラメータを付与して、レコードの入力を行う。

時系列順に厳密にレコードを取得する必要がある場合には、プロデューサごとに毎回同じパーティションキーを使用し、かつSequenceNumberForOrderingパラメータを付与した上でレコードの入力を行う。これによって同一のプロデューサからのレコードは、同一のシャードに入力される。また、レコードを取得する際も、1シャードにつき1つのKinesis Client Libraryを用意することで、複数シャードのレコードを混在させることなく、レコードを取得・処理することが可能となる。ただし、各プロデューサごとに同じパーティションキーを使用する手法は、シャードごとにレコード量の偏りを生じる可能性もあるので注意が必要である。

課金

  • 無料枠は存在しない
  • シャード時間および PUT ペイロードユニットによる従量課金制

AWS CLIを用いたデータの取得

Kinesisの雰囲気をつかむためにawscliで操作する – Qiita

  • シャードイテレータの取得
    aws kinesis get-shard-iterator --shard-id shardId-000000000000 --shard-iterator-type TRIM_HORIZON --stream-name STREAM_NAME
    {
        "ShardIterator": "AAAAAAAAAAEJa+Y5A5ZF3pdoe9Yfwefjiwfweifw9eOy5kguQL7aglWO4VI+Fcb/A9bzR/tKQBW8Yxco9RyOlRfs0q8RgFC0g6wHCnznhzDjpP9Xpfg6vuY/EPPHhYyxDdSKwePQjojgmTTqQlZzbkRHSEo/qSB+Nuqbg4asIsKiYwv96vvJoqxGkQi6RTN3DVf83Vf4nirQ0Sa4tg2A1sAyPfvr/r4etOX"
    }
  • シャードイテレータを使ったレコードの取得
    aws kinesis get-records --shard-iterator AAAAAAAAAAEJa+Y5A5ZF3pdoe9Yfwefjiwfweifw9eOy5kguQL7aglWO4VI+Fcb/A9bzR/tKQBW8Yxco9RyOlRfs0q8RgFC0g6wHCnznhzDjpP9Xpfg6vuY/EPPHhYyxDdSKwePQjojgmTTqQlZzbkRHSEo/qSB+Nuqbg4asIsKiYwv96vvJoqxGkQi6RTN3DVf83Vf4nirQ0Sa4tg2A1sAyPfvr/r4etOX
  • レコードの例
  • Data部分はBase64エンコードされる
  • レコードが存在しない場合は、Recordsが空の状態でレコードが返る
    {
      "Records":[ {
        "Data":"dGVzdGRhdGE=",
        "PartitionKey":"Batch-SagbXhGLwl”,
        "SequenceNumber":"49544985256907370027570885864065577703022652638596431874"
      } ],
      "MillisBehindLatest":24000,
      "NextShardIterator":"AAAAAAAAAAEDOW3ugseWPE4503kqN1yN1UaodY8unE0sYslMUmC6lX9hlig5+t4RtZM0/tALfiI4QGjunVgJvQsjxjh2aLyxaAaPr+LaoENQ7eVs4EdYXgKyThTZGPcca2fVXYJWL3yafv9dsDwsYVedI66dbMZFC8rPMWc797zxQkv4pSKvPOZvrUIudb8UkH3VMzx58Is="
    }

文献

AWS Cognito(1)Cognitoの概要

Cognitoとは

Facebookなどのパブリックログインプロバイダ認証を元に、AWSの認証を得ることのできるサービス。このサービスを利用することで、例えば特定のSNSアカウントに紐づけられたユーザにのみS3へのアクセスを許可するなど、AWSリソースへのアクセスを設定することができる。また、各ユーザごとにkey, Value型のデータを保存することが可能であるので、例えばゲームの設定情報やスコア情報などを、デバイス間で共有することやバックアップすることも可能である。

アプリケーションユーザーの認証

  • 対応しているパブリックログインプロバイダ
    • Facebook
    • Google
    • Amazon
    • OpenID Connect
    • Twitter
    • Gigits
  • パブリックログインプロバイダから返されるOAuth や OpenID Connect のトークンを渡すと、Cognito IDと呼ばれる一意のIDが割り振られる
  • Cognito IDによって、AWSのリソースにアクセスすることが可能となる
  • パブリックログインプロバイダ認証は自分で実装する必要がある
    • Cognitoはプロバイダ認証の結果を受けて、プロバイダのトークンの確認やCognito IDとの紐づけを行う
  • AWSリソースへのアクセス権限はIAMで指定する
  • 未認証ゲストをサポートすることもできる

アプリケーションデータの保存

  • 各ユーザのデータ(データセット)は一度ユーザーのローカルデバイスに保存され、その後 AWS クラウドと同期される
    • アプリケーションデータを同期する際は、同期メソッドを明示的に呼び出す必要がある
  • データセットの取得や解析には、Kinesisストリームを利用する

課金

  • ストア容量とデータ同期回数に基づいて課金を行う
  • 1 か月につき 10 GB の同期ストア容量と 100 万回の同期オペレーションまでは無料枠が設定されている

Cognitoの設定

1. Identity Poolを作成する

  • 「Create new identity pool」をクリックする

Create new identity poolをクリック

Identity pools – Amazon Cognito – Amazon Web Services

2. 名称とプロバイダ情報を入力する

  1. 東京リージョンを選択する
  2. identity pool名を入力する
  3. 各種プロバイダ情報を入力する
  4. 登録を実行する

名称とプロバイダ情報を入力
New identity pool

3. ユーザのロールを設定

  • ダッシュボードから「Edit identity pool」をクリック
    • ダッシュボードには、各種データが表示される

ダッシュボード

  • 「Unauthenticated role」の「Create new role」をクリック
  • 「Authenticated role」の「Create new role」をクリック

Create new role

  • ロール名が自動入力されるので、作成ウィザードで登録を行う
    • Unauthenticated role
      Unauthenticated role
      –Authenticated role
      Authenticated role
  • IAMのロール一覧を開き、先ほど作成したロールを選択する
  • 作成済みのロールポリシーを確認する
{
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "mobileanalytics:PutEvents",
                    "cognito-sync:*"
                ],
                "Resource": [
                    "*"
                ]
            }
        ]
    }

次回は、JavaScriptを用いたコンテンツ側の実装を確認する。