Furyu
[フリュー公式]

Tech Blog

フリュー株式会社の技術ブログです

2011年09月29日

関西Javaエンジニアの会 ’11 9月度 に参加してきました

モバイル事業部でエンジニアをしています、稲富です。

今回、2011/9/14に大阪で行われた関西Javaエンジニアの会(通称 関ジャバ)にスピーカーとして参加してきました。
その時の様子をお話したいと思います。

関ジャバとは

関ジャバとはJavaの話題を中心に毎月大阪で行われているJavaエンジニアのコミュニティです。

2ヶ月毎ぐらいに興味深いテーマについてアツ~いセッションが開催されています。
内容もWebフレームワーク、開発プロセスなど多岐に渡っています。

発表1: Redmineの実業務における活用事例紹介

発表者:中村 洋さん

RedmineとはRuby on Railsで作られたプロジェクト管理ツールで、バグ管理システム(BTS:Bug Tracking System)としても活用できるツールです。

実際にいくつものプロジェクトでRedmineを使ってこられた方の成果や課題を生々しい実体験を元にお話されていました。チーム毎の特徴にあわせた工夫が見所でした。

発表2: 勉強会にいこう。東京の。

発表者:野崎 啓史さん

夜行バス+ネットカフェで1週間滞在という常人ではとてもまねできない荒業が大変インパクトのある発表でした。
でも、工夫次第でこんなに安価で東京の往復・滞在ができるのだという人間の無限の可能性!?を感じました。

結論「行けば何とかなるよ!」とのこと。

発表3: ぺあぷろ!

発表者:稲富 研人/谷口 光

今回フリューからは私と同僚の谷口の2名がスピーカーとして発表しました。

前半はペアプログラミングについて導入から8年になる自社での導入の歴史と近況についてとその効果について私が話をさせていただきました。

後半はペアプログラミング導入政治編として政治的問題を交えながら同僚の谷口が話しました。

導入・政治編への質問が多く寄せられたのでペアプロ自体の効果などは情報で知っているが職場にどうやって導入するのか悩まれている方が多いのだと感じました。

発表4: Javaニュース(懇親会中)

発表者:谷本 心 さん

最近のJavaにまつわるニュースについてお話されていました。
ここまで今回の関ジャバは若干(かなり)Javaの成分は薄めでしたが、このセッションが過去参加した関ジャバの中でも1番じゃないかというぐらいに開発プロセスの話題を中心に盛り上がりました。

これだけ開発プロセスで盛り上がるというのは普段、「なぜこんなやり方なんだろうか」とか「もっとよりよく開発をしたい」という思いを強く感じているからでしょうね。

フリューの中でも開発プロセスについて今の状態がとてもベストとは思わないし、これからもより良く変えていく必要があります。

実はいつの間にか自分自身が老害になってしまうそんな恐怖心と戦っているのかもしれません。

社外のエンジニアと話すことで自社の様子が俯瞰して見えたり、自分自身を見つめ直したりといった刺激をもらえるのが社外勉強会の魅力でもあります。

さいごに

東京では毎週や毎日のように勉強会が開催されていますが、大阪でも毎週に近いくらいに盛んに開催されています。

みなさんもこういった刺激を受けることができる社外勉強会にぜひ参加してみませんか!

フリューモバイル事業部では毎週社内勉強会を開催しています。開催回数もなんと270回を超えています。機会があればぜひまたこの話についてもお話したいと思います。


2011年09月29日

AWS 1ヶ月導入記 part 6 SimpleJPAを用いたプログラミング

みなさん、こんにちは!フリューでモバイルサイト開発を行っている鷲見といいます。

現在、あるソーシャルプラットフォーム上のアプリケーションを構築するプロジェクトでの、クラウド環境の導入の進行状況をそのまま記事にしています。

前回はAWS SDK for Javaを用いてSimpleDBを操作するプログラムについて解説しました。

クラウド1ヶ月導入記 part 1 比較編
クラウド1ヶ月導入記 part 2 見積編
Amazon Web Services 1ヶ月導入記 part 1 データベース編
Amazon Web Services 1ヶ月導入記 part 2 アーキテクチャ設計編
Amazon Web Services 1ヶ月導入記 part 3 SimpleDBの特徴と制限
Amazon Web Services 1ヶ月導入記 part 4 SimpleDBの制限を回避する
AWS 1ヶ月導入記 part 5 AWS SDK for Javaを用いたプログラミング

前回から『Amazon Web Services 1ヶ月導入記』を『AWS 1ヶ月導入記』と省略表記にしています。

さて、今回はSimpleJPAを使って、プログラムからSimpleDBへの接続を行うを方法を解説したいとおもいます。


SimpleJPAとは?

SimpleJPAとはオープンソースのAmazon SimpleDB向けのJava Persistence API(JPA)実装です。つまりはSimpleDB向けのORM(Object-relational mapping)フレームワークです。SimpleDBのドメインから取得したアイテム情報をJavaオブジェクトに変換して操作することができます。

SimpleJPA

The Java Persistence API – A Simpler Programming Model for Entity Persistence

特徴

SimpleJPAには以下のような特徴があります。

  • ManyToOneの関連での遅延ローディングのサポート
  • OneToManyの関連での遅延ローディングのサポート
  • Amazon S3を利用したラージオブジェクト(LOB)のサポート
  • 二次キャッシュ
  • 結果セットの並行参照
  • JPA Queriesのサブセットを利用可能

依存するライブラリ

SimpleJPAは以下のライブラリに依存しています。

  • commons-lang
  • commons-collections
  • commons-logging
  • commons-codec
  • cglib-nodep
  • kitty-cache
  • ehcache
  • scannotation
  • javassist
  • ejb3-persistence-api
  • AWS SDK for Java
  • Apache HttpClient
  • AMS

上記の依存ライブラリにAWS SDK for Javaがあることからも分かるように、内部的にAWS SDK for Javaを利用しています。

SimpleJPAの制限

SimpleJPAはAWSのサンプルプログラムでも利用されるフレームワークですので、非常に便利なのですが、その便利さの反面制限もあります。

私が利用して気づいた制限は以下のとおりです。

  • プロキシ経由のアクセスを行うことが出来ない
  • ドメイン名に接頭辞を付けなければならない(付けないという設定がない)
  • アイテム名と同じ値を持つ属性が必要になる
  • 複数値を扱うことができない(putはできるがget,selectできない)
  • BatchPutAttributes,BatchDeleteAttributesなどのバッチ処理APIが利用できない

このような制限で問題が発生する場合には、SimpleJPAでなく、AWS SDK for Javaで実装することをおすすめします。

また、ドキュメントが少なく、日本語の資料はほとんど無いというデメリットも挙げられます。

ちなみに弊社プロジェクトではSimpleJPAの利用も検討しましたが、上記のような制限が多く、自由度が低かったという点で利用は見送りました。


サンプルプログラム

前回と同じく、東京リージョンで以下のようなドメインを作り、データを投入し、情報を取得するといったサンプルプログラムです。

Employee

アイテム名 name pref unit manager age
Emp1 鷲見 京都 企画 31
Emp2 九岡 福井 開発 佐藤 26
Emp3 川下 宮崎 企画 鈴木 27

Employee.java(Employeeドメインを表すJavaクラス)

EmployeeTest.java(Employeeドメインを操作するJavaクラス)

リージョン設定とEntityManagerの生成

クライアントはデフォルトのままではus-eastリージョンに接続するようになっているので、東京リージョンに設定するようにリージョンの設定を行います。

SimpleJPAではEntityManagerを使って、データの操作を行います。リージョン情報などの情報を設定したMapを使ってEntityManagerのFactoryを生成し、FactoryからEntityManagerを生成します。

EntityManagerFactoryImpl生成時に渡している”TEST”という文字列は、ドメイン名の接頭辞に使われます。

アカウント設定

SimpleJPAは内部的にAWS SDK for Javaを利用しているため、アカウント情報はAWSCredentials.propertiesから読み込みます。

AWS Credentials.propertiesファイルの内容は以下のようになっています。

AWS Credentials.propertiesファイルをパス上に生成しておくことで、アカウント情報を自動的に設定してくれます。

データの投入

AWS SDK for Javaではデータの投入前にドメインの作成を行なっていましたが、SimpleJPAではデータの投入時にドメインが存在しない場合は、自動的にドメインを生成します。Factory生成時に”TEST”という接頭辞を渡しているため、データ投入実行時に『TEST-Employee』というドメインが生成されます。ちなみにこの接頭辞は省略することはできません。空文字を渡した場合『-Employee』というドメイン名になってしまいます。

データの投入はEmployeeドメインを表すJavaオブジェクトを生成、値の設定を行い、EntityManagerのpersistメソッドに渡すだけです。

なお、ドメインを表すクラスには@Entityアノテーションを付ける必要があります。また、ドメインを表すクラスには必ず@Idアノテーションが付いたフィールドが必要です。@Idアノテーションが付いた項目の値がそのままアイテム名となります。サンプルプログラムでは@Idがついたidフィールドの値がアイテム名となります。(上の例では『Emp1』がアイテム名となります。)

データの取得1

SimpleDBのGetAttributes APIに相当するのがEntityManagerのfindメソッドを利用します。findメソッドにはドメインを表すクラスとアイテム名を引数で渡して、該当するドメインのアイテムを取得します。

データの取得2

SimpleDBのSelect APIを呼び出すためにはJPAQueryを利用します。EntityManagerのcreateQueryメソッドにSelect APIに渡すのと同等のクエリを渡します。『:unit』となっているのはプレースホルダーで、QueryのsetParameterで渡した値に置き換えてくれます。

SimpleDB上ではドメイン名は『TEST-Employee』となっていますが、createQueryメソッドに渡すクエリ内では『Employee』で問題ありません。内部でSimpleJPAが『TEST-Employee』に変換してくれます。

後処理

SimpleJPAではEntityManagerFactoryとEntityManagerは必ずcloseメソッドを呼び出す必要があります。

実行結果

上記のサンプルプログラムを実行した結果は以下のとおりになります。

数値型の扱い

サンプルプログラムではageフィールドが数値型となっています。この値がSimpleDB上では『9223372036854775808 + フィールドの値』を文字列にした値が保存されています。上記Emp1の場合は『09223372036854775839』(9223372036854775808+31)となっています。

これは以前に『Amazon Web Services 1ヶ月導入記 part 4 SimpleDBの制限を回避する』で紹介した基準値を決めて数値型を扱う方法で、『9223372036854775808』を基準値としています。これにより64ビットの符号付き整数を扱うことができます。『9223372036854775808』が基準値となっているのは64ビットの符号付き整数の範囲が-9223372036854775808 – 9223372036854775807となっているからだと思われます。

もちろん、SimpleDBからデータを取得したときにはSimpleJPAが内部で通常の数値型に変換してくれます。

なお、数値型のデータを実際に見ると24桁の数値なうえ、計算しないと元の値がわからないので、データを把握しづらいので注意が必要です。


まとめ

今回はSimpleJPAを用いてSimpleDBを操作するプログラムを解説しました。

SimpleJPAでのSimpleDBプログラミングでは

  • EntityManagerからドメインを表すオブジェクトを通じてドメインの操作を行う
  • ドメインは存在しない場合は自動的にドメインが生成される
  • ドメイン名には接頭辞が付く
  • @Idがついているフィールドの値がアイテム名となる
  • 数値型はSimpleDBでは『9223372036854775808』を基準値とした文字列として扱われる。

ということを確認しました。

SimpleJPAをつかえばSimpleDBから簡単にJavaオブジェクトへのマッピングを行うことができます。ただし、制限も強く自由度が低くなってしまうので、利用を検討する際には、制限やデメリットを確認して、要件にマッチするかを確認することが必要です。

さて、次回以降はSimpleDBから離れ、AWSでのデータバックアップなどについてお話ししたいと思います。


2011年09月28日

AWS 1ヶ月導入記 part 5 AWS SDK for Javaを用いたプログラミング

みなさん、こんにちは!フリューでモバイルサイト開発を行っている鷲見といいます。

現在、あるソーシャルプラットフォーム上のアプリケーションを構築するプロジェクトでの、クラウド環境の導入の進行状況をそのまま記事にしています。

もう実はプロジェクト自体は終了しているのですが、気にせずそのまま行きます。

前回はSimpleDBの制限の回避方法についてお話しました。

クラウド1ヶ月導入記 part 1 比較編
クラウド1ヶ月導入記 part 2 見積編
Amazon Web Services 1ヶ月導入記 part 1 データベース編
Amazon Web Services 1ヶ月導入記 part 2 アーキテクチャ設計編
Amazon Web Services 1ヶ月導入記 part 3 SimpleDBの特徴と制限
Amazon Web Services 1ヶ月導入記 part 4 SimpleDBの制限を回避する

今回はAWS SDK for Javaを使って、プログラムからSimpleDBへの接続を行うを方法を解説したいとおもいます。


AWS SDK for Javaとは?

AWS SDK for Javaとは、AWSが提供しているJavaのプログラムからAWSのAPIを簡単に呼び出すためのライブラリです。アカウントに関する設定を少し行うだけで本当に簡単にAPIを呼び出すことができます。

AWS SDKの対応言語

私たちは開発にJavaを利用するので、AWS SDK for Javaを利用していますが、その他の言語向けにも以下のようなSDKが提供されています。

  • AWS SDK for Java
  • AWS SDK for PHP
  • AWS SDK for .NET
  • AWS SDK for Ruby
  • AWS SDK for Android
  • AWS SDK for iOS

AWS SDK for Javaが対応しているAWSのサービス

現在AWS SDK for Javaから利用可能なAWSのサービスは以下のとおりです。

  • Amazon CloudWatch
  • Amazon ElastiCache
  • Amazon Elastic Compute Cloud
  • Amazon Elastic MapReduce
  • Amazon Relational Database Service
  • Amazon Simple Email Service
  • Amazon Simple Notification Service
  • Amazon Simple Queue Service
  • Amazon Simple Storage Service
  • Amazon SimpleDB
  • Amazon Virtual Private Cloud
  • Auto Scaling
  • AWS CloudFormation
  • AWS Elastic Beanstalk
  • AWS Import/Export
  • AWS Identity and Access Management
  • Elastic Load Balancing

上のサービスに先日追加されたばかりのElastiCacheが含まれていることからも分かることなのですが、AWSが提供しているライブラリなので、AWSに新しいサービスが提供されたり、既存のサービスに新しい機能が提供されたりして、APIに変更が加わった際には、リリースとほぼ同時にSDKもバージョンアップが行われているのも大きな特徴です。

AWS SDK for Javaの利用条件

AWS SDK for Javaを利用条件は以下のとおりです。

  • Java SDK 5.0以降を利用していること
  • Apache Commonsライブラリ(Codec, HTTP Client, Logging)が利用できること
  • 利用するAWSサービスのサインアップが完了していること

※上記は2011年9月15日現在の情報です。最新情報はAWSのホームページを参照してください。

AWS SDK for Java


サンプルプログラム

今回は東京リージョンで以下のようなドメインを作り、データを投入し、情報を取得するといったサンプルプログラムです。

Employee

アイテム名 name pref unit manager
Emp1 鷲見 京都 開発
企画
Emp2 九岡 福井 開発 佐藤
Emp3 川下 宮崎 企画 鈴木

クライアントの生成とアカウントとリージョンの設定

AWS SDKではAmazonSimpleDBインターフェースを実装するクライアントを生成し、クライアントのメソッドを通じてAPIの操作を行います。クライアントの生成時にアカウントの情報を設定します。アカウント情報はAWSCredentials.propertiesからアカウントのAccess Key IDとSecret Access Keyの情報を読み込みます。

AWS Credentials.propertiesファイルの内容は以下のようになっています。

また、クライアントはデフォルトのままではus-eastリージョンに接続するようになっているので、東京リージョンに設定するようにリージョンの設定を行います。

ドメインの作成

AWS SDK for Javaではクライアントに準備されているメソッドに対し、各メソッドに応じたRequestを渡します。Requestにはドメイン情報やアイテム情報など操作対象の情報を設定します。

ドメインの作成ではCreateDomainRequestにドメイン名を設定し、createDomainメソッドに渡して実行しています。

BatchPutAttributes APIによるデータの投入

データの投入・更新にはPutAttributes APIとBatchPutAttributes APIの二種類があります。複数のアイテムに対して操作を行う際にはBatchPutAttributes APIを利用します。

投入するアイテムはReplaceableItemとしてアイテム名を指定して生成し、属性はReplaceableAttributeとして生成したReplaceableItemに設定します。なお、同じ属性に複数の値を設定する場合は、同じ属性名のReplaceableAttributeを複数設定します。(下記Emp1のunitの例を確認してください)

BatchPutAttributesAPIの場合は生成したReplaceableItemをListにしてリクエストに渡し、batchPutAttributesメソッドに渡して実行します。

GetAttributes APIによるデータの取得

データの取得にはGetAttributes APIとSelect APIを利用します。

GetAttributes APIはドメイン名とアイテム名を指定して属性情報を取得します。

実行結果はAPIに応じた形のGetAttributesResultで返されます。GetAttributesResultには該当アイテムの属性情報であるAttributeのリストが設定されています。

Select APIによるデータの取得

Select APIはSelectのSQLに対応した表現を用いてデータを取得します。下記の例ではSQLそのままになっています。
指定できるSQLには制限はありますが、ほぼSQLそのままで実行することが可能です。

実行結果はAPIに応じた形のSelectResultで返されます。GetAttributesResultとは異なり、アイテムを複数取得することが出来るため、ResultにはItemを複数保持し、各Itemが属性情報であるAttributeのListを保持しています。

実行結果

実行結果は以下のようになります。


まとめ

今回はAWS SDK for Javaを用いてSimpleDBを操作するプログラムを解説しました。

AWS SDK for JavaでのSimpleDBプログラミングでは

  • AmazonSimpleDBを実装するクライアントを生成する
  • クライアントにアカウント情報・リージョン情報を設定する
  • クライアントに準備されているAPIのメソッドを実行する。
  • 各メソッドに沿ったRequest,Resultが準備されている

ということを確認しました。

AWS SDK for Javaを利用すれば簡単にSimpleDBを操作することが出来ることを確認していただけたと思います。

また、今回は触れませんでしたが、属性の削除、アイテムの削除、ドメインの削除、統計情報の取得などといったメソッドもAWS SDK for Javaには準備されています。

さて、次回はSimpleDBのデータとJavaオブジェクトのマッピングを行うことのできるO/Rマッパーである『SimpleJPA』について、サンプルプログラムを交えて解説したいと思います。


2011年09月27日

Amazon Web Services 1ヶ月導入記 part 4 SimpleDBの制限を回避する

みなさん、こんにちは!フリューでモバイルサイト開発を行っている鷲見といいます。

現在、あるソーシャルプラットフォーム上のアプリケーションを構築するプロジェクトでの、クラウド環境の導入の進行状況をそのまま記事にしています。

前回はSimpleDBの詳細な特徴と制限についてお話しました。

クラウド1ヶ月導入記 part 1 比較編
クラウド1ヶ月導入記 part 2 見積編
Amazon Web Services 1ヶ月導入記 part 1 データベース編
Amazon Web Services 1ヶ月導入記 part 2 アーキテクチャ設計編
Amazon Web Services 1ヶ月導入記 part 3 SimpleDBの特徴と制限

前回説明したSimpleDBの制限としては

  • サイズ・容量の制限
  • 文字列型の制限
  • 整合性の制限
  • その他の制限

の4つをあげました。

今回はこれらのSimpleDBの制限の回避方法について説明します


サイズ・容量の制限の回避

基本的にサイズ・容量の制限を超えそうな大容量のデータを扱うのであればRDSを選択する方がよいかもしれませんが、それでもSimpleDBを使う必要があるのであれば、以下のような方法で制限回避方法を検討するのがよいかもしれません。

1アイテムあたりの属性数の制限の回避

SimpleDBではJoinができないという制限もあり、冗長なデータ構造をとることが多くなり、属性数が通常のRDBより多くなることが予想されます。しかし、1アイテムあたりの属性ペアの数が256個までという制限もあるので、無制限に属性を追加することができません。

このような制限を回避するために以下のような方法が考えられます。

動的に属性・属性値が増えるような設計をしない

SimpleDBはスキーマレスなデータベースなので、アプリケーションから新たに属性を追加することが可能です。もし、アプリケーションから動的に属性を追加することができるようになっている場合、この属性値のサイズ制限を超えてしまうことになりかねません。また、属性は複数の値を持つことができますが、この属性値が動的に増えることによっても同じ制限に引っかかってしまうことになります。

動的に属性・属性値が追加されるような構成の場合は、事前にアイテムの属性数を確認し、アプリケーション側から属性・属性値の追加を制限する必要があります。

ドメインの分割

予め属性数が256個を超えそうなことが予測される場合は、ドメインを複数に分割し、保存先を複数にすることで、1ドメインあたりの属性数を削減することができます。

属性値サイズの制限

SimpleDBには属性名・属性値・アイテム名のサイズの上限は1,024バイトまでという制限があります。

日本語の文字列にして500文字ちょっとですので、ちょっと長いテキストデータを保存したい場合には、以下のような方法で制限を回避する必要があります。

複数の属性を利用する

保存するデータのサイズに応じて属性を予め複数用意しておく、または動的に変更できるようにしておくことで上記の制限を回避することができます。

例えば、最大2,000文字のテキストを保存する場合、属性名にdescription-1,descrption-2,description-3,description-4の様にサフィックスをつけて属性を作成し、データを分割してサフィックスの値の小さな順に保存していくことで、大きなサイズのテキストデータも保存することができます。

ただし、上述の属性値数の上限に注意しておかないと制限に引っかかってしまうことが考えられます。

S3を利用する

保存したいデータがあまりに大容量の場合は、属性値を複数にする対応にも限界があります。

このような場合は、データそのものをテキストファイルとしてS3上に保存し、属性にはS3の保存先情報を保存しておくという方法が考えられます。

この方法を使えばバイナリデータも扱うことができ、保存するデータサイズにほぼ上限がなくなりますが、データが一意になるような保存先の情報管理をアプリケーション側で行う必要があります。

1ドメインあたりの容量および属性数の制限の回避

SimpleDBにはドメインあたりのサイズが10GBまで、ドメインあたりの属性数が10億個までという制限があります。

履歴データのような増え続けるデータの場合は、運用を続けている内にデータが増え、この制限に引っかかってしまうことが想定されます。

このような事態が予想される場合、以下のような方法で制限を回避することが考えられます。

シャーディング

データの水平分散手法であるシャーディングを行い、ドメインを複数に分割し、1ドメインあたりのサイズ・属性数を減らすことで制限を回避します。

シャーディングではIDや日付といった特定の属性の値によって保存先を変更します。たとえばIDが数値として管理されているような場合、IDの値が奇数の場合はドメイン1に、偶数の場合はドメイン2に保存するといったような方法で、データの保存先を分散させます。

この方法ではアプリケーション側でデータ操作の際に、分散のキーとなる属性(パーティショニングキー)の値によって、操作対象ドメインを変更するといった対応が必要になります。また、分散のキーとなる属性(パーティショニングキー)の設定次第では、データの参照効率が落ちることが考えられるので、よく検討して設計を行う必要があります。


文字列型の制限の回避

SimpleDBのデータ型はすべて文字列型となっています。それゆえ、数値型として扱い、ソートを行う場合に制限があります。

詳細は前回の記事を参照していただくとして、数値型でソートを行うような場合、以下のような制限回避方法を行う必要があります。

ゼロ埋めを行う

数値型のソートで問題となるケースとしては以下のようなケースがあります。

『1』,『9』,『50』,『10』を昇順でソートすると、辞書順になるので『1』,『10』,『50』,『9』の順になる。

このようなケースを回避するために、予め数値として扱う属性毎に桁数を決めておき、指定桁数に満たない部分に関しては『0』を埋め、正しくソートを行えるようにします。

上述のケースで桁数を3桁で『0』埋めを行うと、

『001』,『009』,『050』,『010』を昇順でソートすると、辞書順になるので『001』,『009』,『010』,『050』の順になる。

となり想定した通りの結果となることがわかります。

基準値を決める

マイナス値を含む数値型のソートで問題となるケースとしては以下のようなケースがあります。

『9』,『8』,『−8』,『-9』を昇順でソートすると、辞書順で『9』,『8』,『−9』,『−8』という順になる。

このようなケースを回避するために、予め基準値を決めておき、基準値と値を合算した値を保存します。

例えば、上述のケースで基準値を『100』とし、3桁で『0』埋めを行うと、

『109 (9)』,『108 (8)』,『092 (-8)』,『091 (-9)』を昇順でソートすると、辞書順で『091』,『092』,『108』,『109』という順になる。

となり、想定した通りの結果となることがわかります。

ただし、基準値からの計算を行わないと値がわからないので、パッと見て値がわからないというデメリットもあります。


整合性の制限の回避

こちらに関しては特に制限を回避する方法はなく、アプリケーションの要求に応じ、呼び出し箇所の整合性オプションを適宜変更する必要があります。


その他の制限の回避

ドメイン名の制限

SimpleDBにはRDBでいうところのデータベースのようなものが存在しません。1つのアカウントの1つのリージョンに対して、1つのデータベースが与えられているというイメージになります。

データベース内でテーブル名が重複してはいけないように、SimpleDBでもドメイン名の重複は許可されていません。

これによって何が困るかというと、同じアカウントで開発環境と本番環境を構築した場合、同じドメイン名を利用することができないという事態が発生します。

このような事態での対応としては以下のような方法が考えられます。

同じドメインをテスト環境と本番環境で共同利用する

例えば、『Employee』というドメインがあったとして、属性『environment』が『PRODUCT』のアイテムは本番環境、『TEST』のアイテムはテスト環境というようにして区別します。

ただし、同一ドメインにテストデータと本番データが混在することになるので、データの誤操作が発生する可能性があります。

ドメイン名にプレフィックスを用いる

例えば、『Employee』というドメインがあったとして、テスト環境では『TEST-Employee』、本番環境では『PRODUCT-Employee』といったケースです。

ただし、同一アカウントの同一リージョンにテストデータと本番データが混在することになるので、データの誤操作が発生する可能性があります。

本番環境とテスト環境でアカウントを分ける

本番環境とテスト環境で別々のAWSアカウントを利用することで同じドメイン名が利用することができます。

ただし、AWSの操作やアカウント管理が煩雑になります。

本番環境とテスト環境でSimpleDBのリージョンを分ける

同じアカウントでも別リージョンであれば同じドメイン名を利用することができます。

本番環境は東京リージョン、テスト環境はシンガポールリージョンと分けることで、同じドメイン名を利用することが出来ます。

AWSの操作やアカウント管理は簡単ですが、別リージョンとの通信が発生するため課金が発生することと、東京リージョン以外との通信をおこなうため、ネットワークのレイテンシが発生します。


まとめ

今回はSimpleDBで発生する制限の回避方法について説明しました。

制限の回避方法を簡単にまとめると以下のようになります。

  • サイズ・容量の制限については、データの分割と複数属性の効果的な利用で制限を回避する
  • 文字列型の制限については、ゼロ埋めと基準値の利用で制限を回避する
  • 整合性の制限については、アプリケーション側で適切なオプションを利用することで回避する
  • ドメイン名の制限については、ドメイン名のプレフィックスの利用やアカウント・リージョンを分けることで制限を回避する

次回はSimpleDBを用いたプログラミングについてAWS SDK for Javaを利用するケースを説明したいとおもいます。


2011年09月22日

Casual Connect Seattle に参加してきました – part.3

みなさん、こんにちは!フリューでモバイルサイト開発を行っている鷲見といいます。

去る7月19日から21日にかけてシアトルで開催された北米最大のカジュアルゲームの祭典『Casual Connect Seattle』に、我々フリューのモバイル事業部より中島、九岡、鷲見の3名で参加してきました。

今回はそのCasual Connect Seattleへの参戦記を参加した3名それぞれの観点で掲載していきます。

今回はpart.3ということで、わたくし鷲見の特に印象に残ったセッション2つについて解説したいと思います。


Smart Gamification

最近は日本でも耳にするようになった『ゲーミフィケーション』という言葉。ゲーム分野で使われるユーザを夢中にさせる要素をゲーム以外の分野に取りいれるという考え方で、日本ではWebやソーシャルアプリケーションの分野でよく使われるようになった感じがします。ただ、日本では抽象的な話を語られることは多いものの、具体的にどうするべきかといったことが説明されていることが少ない気がします。

そんなゲーミフィケーションについて、具体的にどのように構築するべきかといった方法論を5つのキーワードから紹介したセッションです。

ユーザーを没頭させるための5つのキーと題して以下のような点をあげています。

1.ユーザーのソーシャルスタイルを知る

どのような人がユーザーなのか。そのユーザーはどのようにすれば没頭してくれるのかを考える必要がある。

ユーザーが没頭するスタイルを『競争』『表現』『冒険』『コラボレーション』の4つに分類し、その4つの分野に該当する動詞にあたるアクションをゲーム内に散りばめることでユーザーが没頭しやすくする。

2.ユーザーのゲーム上でのライフサイクルステージに合わせてデザインする

ユーザーはゲーム上のライフサイクルで『初心者』・『常連』・『熱狂的なファン』の3段階に分類される。

それぞれの段階ごとにユーザーが求めることが異なるので、それぞれの段階のプレーヤーが楽しめるようデザインする必要がある。

  • 初心者はゲームのコツを覚えることを求める
  • 常連は新たなコンテンツ・活動・挑戦を求める
  • 熱狂的なファンは独占・認知・反響を求める

これらの段階別のユーザーの欲求を考慮してデザインを行うことが重要。

3.活動にPERMAを導入する

ポジティブ心理学という分野のPERMAというフレームワークを活動の中に導入することでユーザーが没頭しやすくなる。

PERMAとは

  • Positive Emotion・・・ポジティブな感情。喜び・楽しみ・面白さ・安全の経験
  • Engagement/Flow・・・没頭。意識して活動に巻き込む
  • Relationships・・・人間関係。楽しめる・協力できるような他の人との交流
  • Meaning・・・意義・目的のある物語を作る。
  • Accomplishment・・・ゴールの達成

の頭文字の略です。

これらPERMAの要素を導入することで、ユーザーが没頭しやすくなる。

4.簡単にマスターになれるような成長のメカニズムを導入する

良いゲームにはユーザーを学習させ、マスターに向かわせるようなガイドのメカニズムがある。ガイドのメカニズムを利用し、ユーザーのスキルを上げ、没頭させる仕組みが重要です。

5. 個人の内発的な欲求を満たす報酬を準備してユーザの動機づけを行う

タスクの達成などの外から与えられる報酬よりも、 認知欲求や所属欲求のような個人の内発的な欲求を満たす報酬の方がユーザーのモチベーションを高める。

認知欲求や所属欲求などをみたせるような報酬も準備することでユーザーがゲームを使い続ける動機付けとなる。

これらの5点をちゃんと考慮することで、ゲーミフィケーションを盛り込むことができるようです。今後のソーシャルゲームの企画・開発に使える。非常に有意義なセッションでした。

資料

Smart Gamification資料


2011: Social Games Year in Review

2011年のソーシャルゲーム市場を振り返るセッション。

日本では一つ一つのアプリの特徴について触れる機会は多いのですが、市場全体を見た傾向がどうかといった情報があまりないような気がします。そんな市場全体の傾向について、成功事例や失敗事例を交えて発表してくれるセッションでした。

今後のソーシャルゲームの流れを把握し、さらに先を行くために非常に参考になりました。

2011年の傾向としては以下のような点が挙げられています。

Trend #1 LONG,LONG TAILS

ランキングTOP50内で、1年以内にリリースされたものは6個。リリース後1年以上立っているものが1/3を占め。成功したゲームの寿命が非常に長くなっている。

メンテナンスを定期的に行い、週ごとに改善していくような努力をして寿命をのばす努力が必要。

Trend #2 VIRALITY:ALIVE AND WELL

FBのゲームのリクエスト、通知のようなバイラルが新規ユーザ獲得でなく、現状のユーザの維持のために役だっている。

Trend #3 EVERYTHING MUST BE A FRONTIER

2009年から2010年は農場系のゲームが元気だった。現在でも農場系のゲームが多いけど、農場の真似をしただけのゲームが多くなってきた。

農場の真似をするだけでなく、フロンティアとして新しい分野を開拓していく必要が出てきている。

Trend #4 THE AGE OF HIGH QUALITY

同じゲームでもここ数年ですごく高品質化しており、高品質の時代がやってきている。

ユーザーは一度いいものを味わうと元に戻れなくなるので、機能・コンテンツを磨き続ける必要がある。

ただ、目新しい機能・コンテンツばかりになると、ユーザーが学ばなければならないことが多くなってしまうので、バランスの調整が退治。

クオリティが高く、新しいものであることが大切。

Trend #5 THE AGE OF ITERATION

似たようなゲームが大量に発生。特に農場系ゲームが大量。

2009年−2010年は モノマネでもDaily Active User(以下、DAU)が多かった。しかし、2010年−2011年にはDAUが低下していき、そして、ほとんど消えてしまった。

既存のゲームと似ていてもテイストを変えるなど、ひとひねりすることが大事!

Trend #6 THE CASUAL INVASION

テトリスのような昔からあるゲームが売れていたり、売れていなかったりしており、ケースバイケースの様相を呈している。

なぜかと考えたところ?以下のような原因が考えられる。

  • カジュアルゲームのターゲット層と対象のターゲット異なる
  • ゲームに親しみやすさがない
  • 1セッションが長い

Trend #7 CASUAL CONFLICT

2010年の対戦型ゲームは、誰が進んでいるのかといった進み具合を表示するようなタイプのゲームが多かった。これは構築型のゲームには適していた。けれども、他のユーザと協力することはできても、他のユーザーの邪魔をすることができない。

2011年になって戦争ゲームのような競争系のゲームが売れるようになってきた。

なぜかと考えると、以下のような原因が考えられる。

  • 戦争分野はゲーム機の分野でも既に実績のあるニッチ分野であること
  • ユーザーが洗練され、他のユーザーの邪魔をできるよう競走系のゲームを望むようになってきたこと

Trend #8 THE RISE OF I.P.

ライセンスを購入して作成するようなゲームはプロバイダーの助けになるのか?

答えはある程度のインパクトは与えるけど、それだけでどうにかなるようなものではない。

ライセンス系のゲームのメリットとデメリットは
メリット

  • ユーザを獲得しやすい
  • コンテンツが揃っている

デメリット

  • ライセンスコストが高い
  • ライセンサーの承認が必要
  • プレッシャー

が挙げられる。

ライセンサーからのニーズがあり、決められた期限内のリリースが必要で、スケジュール的にきつくなるようなことも多い。

ESPN U:CollegeTownはゲームバランスが悪く、チュートリアルもあまりよくなく、納期的にもピンチだったけど、現在は質のよいユーザを獲得できている。

ただし、ケースバイケースなので注意が必要。

Trend #9 WHITHER THE FACEBOOK RPG?

FacebookアプリのRPG分野は2010年はすごく調子が良かったが、現在は下降傾向にある。

  • アイソメトリックミッション系・・・2011年は調子が良い
  • モンスター収穫系・・・同じく調子がいい
  • ダンジョン探検系・・・調子が悪い。

これから健全な多様化が行われていくことが今後期待される。

Trend #10 IT’S A HARD,HARD ROAD

ソーシャルゲームの会社は結構多くの数がクローズしている。また、大きな会社でもDAU稼げていないところが多い。

なぜ?

  • ソーシャルゲームは難しい
  • ソーシャルゲームは本当に難しい
  • ソーシャルゲームは本当に本当に難しい

リリースしてからも、ブラッシュアップし続けていかなければならない。また、2,3回失敗しても、持ちこたえるような体力が無いと成功するのは難しい。

資料

2011: Social Games Year in Review資料


まとめ

今回はわたくし鷲見がCasual Connect Seattleに参加して特に印象に残ったセッション2つを解説させていただきました。

『Smart Gamification』では
ユーザーの段階に応じて、ユーザの所属欲求や認知欲求を考慮して、動機付けすることが大切である
ということを学ぶことができました。

『2011: Social Games Year in Review』では、

  • ゲームがどんどん高品質化し、ユーザーの求めるレベルが高くなってきている
  • モノマネだけでなく、新しい試みが必要である
  • ブラッシュアップをつづけ、ユーザーを飽きさせないことが必要である

ということを学ぶことができました。

これら2つのセッションから学べば、ヒットするソーシャルアプリを作れるかもしれませんね!

私もこれらのセッションから学んだことを活かして、アプリをヒットさせてみたいと思います。

part.4以降は、私と一緒にCasual Connect Seattleに参加した中島・九岡からのレポートとなります。