エンジニア長期インターン GREE Studio 2010 3日目

2010/09/03

インターン生の時原です。
3日目の様子を報告します！
今日も盛りだくさんの内容でした。

webアプリケーション講座（その2）

今日はこの前に引き続きウェブアプリケーション入門ということで、GREE　Platformについて教えていただきました！

Open Social

GREE Platform はOpen SocialというソーシャルアプリのAPIをベースにしています。で、ソーシャルアプリを作る時に用いるのがだいたい以下の2つのどっちかという感じのようです。

  • JavaScript PCブラウザ上で動かす（mixiアプリとか）
  • RestfulAPIサーバー モバイルで動かす。

アプリにはviewer,ownerという概念があって、
viewerはアプリを使う人（ユーザー）で、ownerはアプリを入れた人です。英語のまんまですね。

GREE Platformの仕組み

ソーシャルアプリの大雑把な説明が終わったんで、GREE Platformの仕様についてみてみましょう。
基本的なやり取りはこの図

といった感じです。
ガジェットにはおもに

  • URL変換を行ってgree.jp経由でアクセスするようにする。これによって外部サイトへのアクセスを制限します。
  • ヘッダーとフッター（ページの最上面と最下面の全体共通の部分）の付加
  • 画像のキャッシュ

といったことをしています。うーんすごいです。

で、リクエストが送られてくるときにはOauth認証というのが行われるそうです。
認証方法はOauth専用に取ってきた複数の情報を規則通りにくっつけて文字列にしたものを使って認証を行うようです。
詳しくは仕様書に書いてあるそうです（後でちゃんと読みます）。

ここまでは内部の仕様についてですが、アプリを起動させるためには…
gadget.xmlファイルにどのアプリを参照するかの設定を行う。
基本これだけです。なんと単純なんだろう！

APIについて

各APIについても簡単に説明してもらいました。以下にまとめると

  1. people ユーザーとその友達の情報
  2. activity 更新情報について
  3. appdata　モバイルでは特に使わない（サーバーで同じようなことをしているため）でもJavaScriptでは使ったりするかも
  4. message アプリ側からユーザーに送信
  5. payment コイン（課金）関係
  6. inspection 文章の監視
  7. ignorelist　アクセス拒否

特に最初の4つはソーシャルアプリにおいては超重要な機能です。たしかに友達の情報とかそういったものがちゃんと反映されないと意味ないですよね。

このほかにもサービスとして位置情報を提供したりとかもできるようです。

こんな環境で開発するんですねー。でもまだまだ仕様は見ていかないといけませんね。頑張らねば…。

大規模アプリケーション

さらに今回はもう１つ大規模アプリケーションについても講義がありました！

分散処理という考え

あるサーバーに大量アクセスが来た時に何が問題となるか？という始まりでした。
考えられるものとして

  1. Disk I/Oによるレイテンシ
  2. メモリI/Oによるレイテンシ
  3. ソフトウェアが落ちる
  4. CPUレスポンスが落ちる
  5. ネットワークの回線速度

といったことがあります。確かに言われれば「あー確かにそうだ」と思いますが普段そんなの気にもしていなかったです…。
そんな感じでこういったボトルネックを補てんするためにはということで2つの考え方。

  • scale up　そのものを強化する（回線を太くするなど。）
  • scale out　別のものを作る（サーバーをもう1個作る）

があります。垂直的、水平的ともいうそうです。
で、基本的には分散を行っていくのがGREEの（というより大部分の所の）考え方のようです。分散なら後で拡張などが楽ですからね。
そしてサーバーを分散する際にはロードバランサというものを使って各サーバーにユーザを割り振っていくことで負荷を低減していきます。さらにそのあとでプロクシを使って制御しています。
こんな感じでしょうか

サーバーは複数ありますが、次に問題となっていくのがデータベースです。
最初GREEは１つのデータベースですべての情報を管理をしていました。しかしどんどんユーザーが増えたり日記を書いたりといったことでデータがどんどん増えていきました。
なので、各テーブル（ユーザー情報、ブログなど）を別々にデータベースにすることにしました。これも分散の考え方と一緒ですね。
各情報で分けるのはjoin（別のテーブルを使って処理をしたりする）ができないという問題があったります。
各ユーザーである程度のまとまりにしてデータベースを分ける、という考えもあるのですが、そうすると二度手間処理を行ったりすることが多いというの問題があります。
例えば全体ユーザーの最新日記を10件表示したいという場合に、この方法で管理していると各データベースでまず10件最新の日記を見つけて、さらにその後ソートして…というようなことになります。
そうすると前者の方法よりも処理が多くなることが多いので各テーブルごとにデータベースを割り当てているとのことです。

そして最後に大事なことを言われました。

今自分がやっていることがどんどん規模がでかくなったときに何が起きるのか、
そしてその問題は何が原因か、そしてどうやれば解決できるのかを考えていこう。
そしてそれを考えだけでとどまらすちゃんと実装できるように技術を磨き勉強しよう！

つまりimagination&studyが大事であるということだそうです。
これから企画もある程度に詰まってきたのでどんどん実装作業に移っていきます。
その時に、こういうことを考えて作っていければいいなあと思います。

お昼のカレーはうまかったです。だけどレジ前にあったよくわからない謎の芳香剤のような味のするものは半端なかったです…；；

来週はデータセンターの見学があるようです。見てもわからないことが多いかもしれませんが、貴重な体験なので楽しみです。