Furyu
[フリュー公式]

Tech Blog

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

2011年09月22日

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

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

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

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

今回はpart.2 ということで、わたくし鷲見の観点でCasual Connect Seattleの感想、特に印象に残ったセッションについて、その他シアトルの街で感じたことなどを書き綴っていきます。


Casual Connect Seattleについて

初めての海外カンファレンスへの参加ということで、大丈夫かと不安に駆られながら参加したものの、なんとかセッションにも着いていくことができました。

北米最大のカジュアルゲームのカンファレンスで3日間の開催期間ということもあり、非常に多くの企業が参加・出展されていました。日本からもGREE Internationalの青柳さんのセッションがあったり、GREEが買収したOpenFeint社主催のネットワーキングイベントがあったりと、日本の関連企業も参加されていました。参加企業の印象としては大きな企業が少数と、ソーシャル分野で成功を収めはじめたベンチャー企業が多数という印象でした。

また、北米中心ながらいろんな国の方々が参加されている印象が強かったです。日本の方も多く、異国の地で同じ国の人を見かけてちょっとほっこりした気持ちになったりしていました。

セッションは4つの会場で並行して行われるため、すべてのセッションに参加することは出来なかったのですが、セッションの内容としてキーワードとなっていたのは、「ソーシャルゲーム」「ゲーミフィケーション」「モバイル」の3つだったと思います。これらの3つについて、学術分野・テクノロジー分野・ベンチャーキャピタリストなど様々な分野から傾向・成功事例・研究結果などが語られていました。やっぱり今後はスマートフォンでのソーシャルゲームというものがカジュアルゲームの主流になっていくのだろうということをセッションの内容からも感じることができました。

今回Casual Connect Seattleに参加して特に印象が残ったセッションは、ゲーミフィケーションについての方法論を教えてくれた『Smart Gamification』というセッションと、現在のソーシャルゲーム分野の傾向について教えてくれた『2011: Social Games Year in Review』の2つです。これらの2つのセッションについては、長くなるので別のページにまとめさせて頂きます。

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

3日間にわたり多くのセッションがあったのですが、セッション終了後に、多くのネットワーキングイベントが開催されていました。公開されているイベントもあれば、企業のブースを訪れると教えてくれるような非公開のイベントもありました。中には夜の水族館を貸し切って行われるような豪華なイベントもあったりして、カジュアルゲーム企業の勢いを感じることもできました。英語があまりできないので、あまりネットワーキング出来なかったのが残念です。


その他シアトルの街で感じたこと

本屋での技術書の構成の違い

シアトルで少し時間があったので、Barnes & Nobleという大きな本屋さんに寄って来ました。

そこで技術書のコーナーにいってみたのですが、日本の技術書のコーナーと少し構成が違い違和感を覚えました。日本ではまだあまり見かけないような新しい分野の本がたくさん見かけられました。

日本に翻訳されて入ってくるのはまだまだ先なのだろうと思うと、この時間差を解消し、世界と戦うためには、英語で技術書が読めるようにならないといけないなとつくづく実感しました。

また、もう一つ印象的だったのは、円高ということもあり技術書を2冊ほど買ったのですが、その時にレシートと一緒にレコメンデーションのシートも渡してくれたことでした。かなり的確にリコメンデーションをしてくれていて、日本でもぜひやってもらいたいと思いました。

日本人との感性の違い

Casual Connectの会場で、パンフレットや資料をたくさんもらいました。

カジュアルゲームの祭典ということで自社のゲームを紹介するものが多かったのですが、そのキャラクターの絵がことごとく日本人の私には受け付けにくい感じが非常に強かったです。いうなればポケモンとアメコミの差という感じでしょうか。

このあたりに日本人と海外の感性の差というものを非常に感じました。

海外、特に北米で成功するにはこの感性の差を乗り越えないといけないだろうと実感しました。


まとめ

そんなこんなで、Casual Connect Seattleでは

  • ゲーミフィケーションの重要性
  • ゲームに求められるクオリティが高くなっていっていること
  • ソーシャルゲームで当てることの難しさ

ということを改めて感じてきました。

これら実感し学んだことを活かし、ぜひカジュアルゲームでヒットゲームを作ってやろう!そう改めて思い直すカンファレンスでした。

次は英語をもっと勉強して、来年のCasual Connect Asia(シンガポール)にいければ。。。

上司がこのブログを見て私をシンガポールに行かせてくれることを期待しています。

次回は鷲見の特に印象に残った2つのセッション『Smart Gamification』『2011: Social Games Year in Review』について解説させていただきます。


2011年09月15日

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

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

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

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

今回はpart.1 ということでカジュアルゲームやCasual Connectについての簡単な説明を触りとして説明させていただきます。

ちなみに今回のCasual Connect Seattleへは福岡市さん、ジェトロ福岡さん共済の『福岡市・シアトルゲーム産業ミッション』を通じて参加させていただきました。福岡市さん・ジェトロ福岡さんほんとうにありがとうございました。


カジュアルゲームとは?

カジュアルゲームに関する団体であるCasual Game Associationによるとカジュアルゲームは以下のように定義されています。

  • ファミリーを含む広い一般ユーザー向けに作られた、比較的簡単に遊ぶことが出来るビデオゲーム
  • プラットフォームにとらわれず、ゲーム機、パソコン、iPhoneなどのスマートフォン・携帯電話、FacebookなどのSNSといった様々なメディアで遊ぶことができる
  • パズルゲーム・麻雀・テトリス・ソリティアのような、暴力的でないゲームが多い
  • ワンプレーが5−20分くらいの、短時間で遊べるアーケードスタイルのゲームが多い

要は「短時間で、簡単に遊べて、幅広いユーザーをターゲットにしたゲーム」といったところでしょうか。

また、そんなカジュアルゲームの市場規模やユーザー数なども気になるところですが、Casual Game Associationでは以下のように説明されています。

  • 2009年時点でインターネット経由のカジュアルゲームプレーヤーは、世界に2億人以上いると推測される
  • 携帯電話、iPhoneなどのスマートフォン、FacebookのようなSNS、パソコン、ゲーム機といった媒体を合算した2009年度の全世界売上は30億ドル(約2,400億円)を突破

出典:Casual Game Association


Casual Connectとは

Casual Game Associationが主催するカジュアルゲームの祭典です。年に3回ほど、ヨーロッパ・北米などで開催されており、今年はドイツのハンブルグ、アメリカのシアトルで開催され、10月にはウクライナのキエフで開催予定です。また来年はシンガポールでの開催が予定されています。

我々が参加したCasual Connect Seattleは北米唯一かつ最大のカジュアルゲームイベントで、ネットワーク経由の様々なジャンルを網羅し、 北米・ヨーロッパの市場動向や、最新の技術動向に関する情報が入手することが可能です。

北米での開催とはいえ、世界中で年3回しか開催されないイベントですので、我々同様、海外からの参加者が非常に多かったのが印象的でした。

気になるのはどのような企業が参加しているのかといったところですが、Casual Connect Seattleへの参加企業としては日本で知られている企業としては

  • Rovio Mobile(Angry Birds開発元)
  • Big Fish Games
  • Google
  • Amazon
  • Microsoft
  • OpenFeint
  • ngmoco

のような企業が挙げられます。


シアトルについて

なぜシリコンバレーではなくシアトルで開催?と思われた方も多いのではないかとおもいますが、シアトルはマイクロソフトやニンテンドーオブアメリカなども本拠地を置くゲーム産業都市なのです。
ゲーム会社でシアトルに本拠地を置く企業も多く、そのため毎年シアトルで開催されているのではないかと思います。

日本との時差は15時間。飛行機で片道約9時間ほどの時間がかかります。

ゲーム産業以外にはボーイング社が本拠地を置き航空産業が盛んな他、日本でも有名なスターバックス、タリーズ、シアトルズベストコーヒーなどのシアトル系カフェの発祥の地でもあります。

また、イチローで有名なシアトル・マリナーズも当然シアトルのチームです。

ちなみに下の写真はシアトルのシンボル『スペースニードル』です。某映画で宇宙船の隠し場所にされてたりしました。

スペースニードル


まとめ

と今回はさわり部分なので、このあたりで。
次回からは参加者3名それぞれの観点から、Casual Connectでの気になったセッションや感想について掲載していきます。


2011年09月14日

Amazon Web Services 1ヶ月導入記 part 3 SimpleDBの特徴と制限

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

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

1ヶ月導入期という記事を書き始めてもう4ヶ月経ちますが、たぶん気のせいです。

前回はAWSでのアーキテクチャ設計を行いました。

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

今回からしばらくは利用するデータベースサービスAmazon SimpleDBについて、
その制限や特徴、回避方法、データ設計、プログラミングについて説明していきたいとおもいます。

今回はSimpleDBの特徴と制限について説明します


SimpleDBのおさらい

http://aws.amazon.com/jp/simpledb/

SimpleDBはAWS上で展開されている非リレーショナル型のデータストアサービスです。

イメージとしてはKVS(Key Value Store)型のデータベースをイメージすると分かりやすいかと思います。

特徴としては高い可用性と運用の容易さが上げられます。負荷が高くなったような場合にもAWS側で自動的にスケールアウト・スケールアップを行ってくれます。

また、データは自動的に複数のAvailability Zone(AZ)に分散して保存されるので、データがなくなってしまうといったリスクも少なく、可用性も高くなっています。

メリット

  • 可用性が高い
  • AWS側で管理するサービスなので運用のコストがほとんど掛からない
  • スケールアウト・スケールアップを自動で行ってくれる
  • 価格が安い

デメリット

  • トランザクションに対応していない
  • RDBでは当たり前のJOINを行うことができない
  • データサイズなどの制約が多い
  • AWS側でほぼ全ての管理が行われるので細かな設定・管理は行うことはできない

SimpleDBの詳細な特徴

ドメイン・属性・アイテム

RDBではテーブル、列という概念が利用されていますが、SimpleDBでは少し異なる考えをとっています。

ドメイン(Domain)

RDBでいうところのテーブルに該当します。ドメインには複数の属性をもつことができます。

属性(Attribute)

RDBでいうところの列によく似ています。属性は名前と値のペアで、ドメインに属します。1つの属性に複数の値を設定することも可能です。
また、他のアイテムに設定されている属性が他のアイテムに存在するとは限りません。

アイテム(Item)

RDBでいうところの行によく似たものです。アイテムはドメイン内において一意となるアイテム名を持ちます。

二次元表における例

Employee

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

この表で説明すると

  • ドメイン名はEmployee
  • 属性名はname,pref,unit,manager
  • アイテムはEmp1,Emp2,Emp3
  • 属性は複数の値を持つことができる。(アイテムEmp1の属性unitには開発と企画の2つの値が設定されている。)
  • 他のアイテムで設定されている属性が、別のアイテムで存在するとは限らない(アイテムEmp1には属性managerは存在しない)

となります。

すべての値は文字列

SimpleDBではすべてのデータ項目が文字列として扱われます。そのため、プログラム側のデータ型に合わせる際には文字列から該当するデータ型への変換処理が必要となります。

SQLの知識を生かせるSELECT API

Select APIでは通常のSQLのQueryとよく似たQueryを利用することができ、SQLの知識をそのまま活かすことができます。

例えば、上述の表のEmp1をname属性を指定して取り出す場合、

といったクエリをSelect APIに投げることで取得することができます。

もちろん、『order by』によるソートや、『limit』による取得件数の制限も可能です。

自動的なインデックス付け

SimpleDBではすべての属性値に対して、自動的にインデックス付けが行われます。RDBでは自分で設計してインデックスを作成する必要がありましたが、SimpleDBでは自動的に作成されます。

自動的にインデックス付けが行われることによりSelect APIでの検索やソートが行えるようになっています。


SimpleDBの制限

SimpleDBには通常のRDBにはない多くの制限が存在します。

サイズ・容量の制限

SimpleDBには他のAWSのサービス同様、データのサイズ・容量に関する制限が多く存在します。

下記の情報は2011年8月25日時点での情報です。
最新の情報は以下に掲載されているので各自で確認してください。
http://docs.amazonwebservices.com/AmazonSimpleDB/latest/DeveloperGuide/index.html?SDBLimits.html

ドメインあたりのサイズの上限 10GB
ドメインあたりの属性値の数 10億個
ドメイン名の制限 3−255文字(半角英数および’-‘,’_’,’.’)
1アカウントあたりのドメイン数の上限 250個
1アイテムあたりに含まれる属性ペアの数の上限 256個
属性名・属性値・アイテム名のサイズの上限 1,024バイト
属性名・属性値・アイテム名に利用できる文字 XMLとして有効に扱うことのできるすべてのUTF-8の文字
PutAttribute APIで操作可能な属性値の数の上限 256個
Select APIでリクエスト可能な属性値の数の上限 256個
BatchPutAttributes APIで操作可能なアイテム数の上限 25個
Select APIで取得可能なアイテム数の上限 2,500個
クエリの実行時間の上限 5秒
Select APIで指定可能なユニークな属性の数の上限 20個
Select APIで利用可能な比較演算子の数の上限 20個
Select APIのレスポンスサイズの上限 1MB

文字列型の制限

上述の特徴でも述べている通り、属性値はすべて文字列となります。

文字列を扱うだけであれば問題はないのですが、数値項目でソートを行う場合などに文字列であるがゆえの制限が発生します。

SimpleDBでは全てのデータが文字列になるので、ソートも辞書順でのソートとなります。

例えば『1』,『9』,『10』を昇順でソートすると、辞書順になるので『1』,『10』,『9』の順になってしまいます。

またマイナス値が入ってくるとさらにややこしくなり、『9』,『8』,『−8』,『-9』を昇順でソートすると、辞書順で『9』,『8』,『−9』,『−8』という順になってしまいます。

このように全てが文字列であるがゆえの制限があるので、この制限をデータ設計やプログラムで吸収する必要があります。

整合性に関する制限

SimpleDBでは基本的に『結果的な整合性』という考え方で整合性をとっています。

SimpleDBではデータは物理的に離れた複数のAvailability Zone(AZ)にデータの複製が配置され、読み込みの際にはこの複製のデータも読み込みにいきます。

データの更新要求が発行された際に、複製が発行されているサーバに対し、データの更新を転送します。データの更新がすべての複製に反映されるまで少し時間がかかるので、全ての複製が更新されるまでの間、更新前の結果が返ることがあります。このタイムラグは通常は1秒以内とされています。結果的に整合性はとれるのですが、このタイムラグの間は更新前の結果が返ることがあるという整合性の取り方を『結果的な整合性』と呼びます。

必ず更新されたデータを返す『整合性』のオプションも準備されています。更新の結果は必ず反映されますが、データの更新が反映されるまで待つことになるので、『結果的な整合性』より処理時間がかかるようになってしまいます。

更新が行われるデータの特性を考慮し、どちらの整合性オプションを採用するのかを検討する必要があります。

データ構造に関する制限

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

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

これによって何が困るかというと、同じアカウントで開発環境と本番環境を構築した場合、

  • 本番環境とテスト環境で同じドメインを利用し、特定の属性の値により本番環境かテスト環境かどうかを判別する
  • 本番環境とテスト環境で異なるリージョンで同じドメインを利用する
  • 本番環境とテスト環境でドメイン名を異なるものにする

という対応が必要になります。

データベースという考え方が存在しないため、通常のRDBで行う開発環境と本番環境でデータベースを切り替えるという対応ができないのです。

この開発環境と本番環境の差を吸収する設計が必要になります。


今回のまとめ

今回はSimpleDBについて詳細な特徴と制限について説明してみました。

特徴としては

  • ドメイン・属性・アイテムという考え方
  • すべての値は文字列であるということ
  • SQLの知識を生かせるSELECT API
  • 自動的なインデックス付け

制限としては

  • サイズ・容量の制限
  • 文字列型の制限
  • 整合性の制限
  • データ構造の制限

について説明しました。

次回はこれらの制限の回避方法について説明したいとおもいます。