App Engine ja Night Sapporo #1 Beer Talk teamcounter@ 株式会社プロサイト
自己紹介 吉田 博紀(よしだ ひろき) Java とか PHP とか .NET とかやってます。 Java 歴  1.5 年 AppEngine 歴  4 ヶ月くらい Twitter : @teamcounter Email  : [email_address] 株式会社プロサイト
「 cochica 」というサービスを作っています cochica はこんなサービスです 開発チーム構成と開発工数 なぜ appengine を選んだのか 実際に appengine を使ってみた感想 日本初 !?SDK1.3.6 を使ったサムネイル作成解説 運用費用の試算 などについてお話します
「 cochica 」 はこんなサービスです cochica とは。。。 幼稚園、保育園が園生活の様子を撮影した写真を   保護者に提供するためのサービスです。 現時点では写真販売のみですが、他機能も実装予定です。 現時点での主な機能 写真のアップロード、ダウンロード、販売 請求データのエクセル出力 保護者 幼稚園 cochica 写真 写真 お金 プロサイト お金
開発チーム構成と開発工数 チーム構成 メンバー1 WEB開発歴 8年、Java歴 5年 メンバー2 WEB開発歴 1年、Java歴 1ヶ月 メンバー3 WEB開発歴 3ヶ月、Java歴 なし 開発工数 開発期間 6月初旬~7月中旬(約1.5ヶ月) 開発工数 実質3人月(最初の0.5は試行錯誤) 開発規模 63画面
なぜ appengine なのか 開発チームの悩み ・予算がない -> 相当量の無料割当があるのは上司説得に有効 ・サーバーやネットワークの専門家がいない -> サーバーの設定、運用が不要 ・サクサク作りたい -> slim3 があるじゃないか 以上のことから appengine 一択となり開発スタート
実際に使ってみた感想 ~環境編 いろいろ制約はあるけど、なんとかなる 30 秒制約は Queue を使うとか、データ量制約は BlobStore を使うとか appengine 自体どんどん進化中なので、 開発中に新機能がリリースされてラッキーなんてこともある。 日本語ドキュメントがひどすぎる 情報量はすくないし、間違いも多い。 たとえば、 BlobStore については情報量はゼロ。 1 行も載ってなかった。 CPU 時間の Quotas が 46h (正しくは 6.5 h)になってたり、 発信・受信帯域が 10GB  (正しくは 1GB )になってたりする。 アプリケーションバージョンを活用する アプリケーション ID が一致しなければ DataStore にアクセスができないので ユーザーサイトと管理者サイトなどを分けたい場合はアプリケーションの バージョンを分けて管理する。
実際に使ってみた感想 ~モデル編1 予想通り DataStore 設計は非常に悩ましかった まず、なにが正解かわからなかった。(いまもわからない) どこまで非正規化するべきか。究極は1 Kind のみだけどそれは無理。 できたとしても、毎回全プロパティ読込とかはコストかかりすぎ。 非正規化にも限度があるし、それほど固執する必要もないかも。 なんだかんだで自然と読取処理が楽になるような設計になってくる。 エンティティグループ( EG )使わなくてもイケル。 トランザクションの範囲を指定するために EG があるのなら slim3 の gtx を使えば EG の設計を考える必要はないんじゃないか? 実際に今回は 1 個も複数エンティティの EG は作ってません。 リストプロパティ使わなきゃよかった コンポジットインデックスを使用することによるインデックス爆発怖い。 1 エンティティのサイズが大きくなる。 だったら最初から使わなきゃよかった。結局 1 箇所しか使ってません。
実際に使ってみた感想 ~モデル編2 スキーマバージョン管理ルールは決めておくべき DataStrore はスキーマレスなので Kind 内に構成が異なるエンティティが存在できる。 途中でエンティティのプロパティに増減があったりして 過去データとのマージが必要になった場合などに スキーマバージョンの運用ルールが決められていないと泣ける。 ちなみに今回のルールはプロパティの増減があった場合に バージョンを 1UP するという普通のルールでした。
実際に使ってみた感想 ~その他編 appengine に向いてる案件の条件 制限に対する代替案を決定する権限が開発側にある appengine 特有の制限にぶつかった場合、 代替案決定のイニシアチブがユーザー側にあると 制限を回避できないことがあるかもしれない。 ちょいちょいアクセス出来なくても大問題にならない appengine はちょいちょいアクセスできなくなったりします。 完全に業務系とかだと、いつ復旧するかわからなくて ドキドキしちゃうので、まだ appengine は使わない方が良いかも。
日本初 !?SDK1.3.6 を使った画像リサイズ解説 BlobStore の特徴 1 ブロブあたり 2GB まで保存可能 1 リクエスト 10MB 制限が関係ない サーブレットを経由しないでアップロード DataStore のようにデータ構造は保存できない    blob を保存できるだけ
SDK1.3.5 を使用したサムネイル作成 この他にもスペース都合で 未掲載の処理が 24 行あります。
SDK1.3.6 を使用したサムネイル作成 たった 2 行で完成!! 1.3.6 では画像を表示する URL を作成する 作成される URL http://localhost:8888/_ah/img/6Fv6uJwIwmQzNCrYj8T_JA =s160 =s160 ←  この部分で表示される画像サイズ(ピクセル)を指定する この指定だと縦横比を保持してリサイズされます =s160-c この指定だと正方形にリサイズされます 指定可能なサイズは 1.3.6 の JavaDoc にて確認できます 1.3.6 の結果ファイルサイズが 1.3.5 と比較して約 1/5 と圧倒的に小さい。 ※ 1.3.6 はプレリリースなのでデプロイは出来ません。
運用費用の試算 最初に予定されているユーザー数で試算してみた
ご清聴ありがとうございました。

cochica

  • 1.
    App Engine jaNight Sapporo #1 Beer Talk teamcounter@ 株式会社プロサイト
  • 2.
    自己紹介 吉田 博紀(よしだ ひろき) Javaとか PHP とか .NET とかやってます。 Java 歴  1.5 年 AppEngine 歴  4 ヶ月くらい Twitter : @teamcounter Email : [email_address] 株式会社プロサイト
  • 3.
    「 cochica 」というサービスを作っていますcochica はこんなサービスです 開発チーム構成と開発工数 なぜ appengine を選んだのか 実際に appengine を使ってみた感想 日本初 !?SDK1.3.6 を使ったサムネイル作成解説 運用費用の試算 などについてお話します
  • 4.
    「 cochica 」はこんなサービスです cochica とは。。。 幼稚園、保育園が園生活の様子を撮影した写真を   保護者に提供するためのサービスです。 現時点では写真販売のみですが、他機能も実装予定です。 現時点での主な機能 写真のアップロード、ダウンロード、販売 請求データのエクセル出力 保護者 幼稚園 cochica 写真 写真 お金 プロサイト お金
  • 5.
    開発チーム構成と開発工数 チーム構成 メンバー1WEB開発歴 8年、Java歴 5年 メンバー2 WEB開発歴 1年、Java歴 1ヶ月 メンバー3 WEB開発歴 3ヶ月、Java歴 なし 開発工数 開発期間 6月初旬~7月中旬(約1.5ヶ月) 開発工数 実質3人月(最初の0.5は試行錯誤) 開発規模 63画面
  • 6.
    なぜ appengine なのか開発チームの悩み ・予算がない -> 相当量の無料割当があるのは上司説得に有効 ・サーバーやネットワークの専門家がいない -> サーバーの設定、運用が不要 ・サクサク作りたい -> slim3 があるじゃないか 以上のことから appengine 一択となり開発スタート
  • 7.
    実際に使ってみた感想 ~環境編 いろいろ制約はあるけど、なんとかなる 30秒制約は Queue を使うとか、データ量制約は BlobStore を使うとか appengine 自体どんどん進化中なので、 開発中に新機能がリリースされてラッキーなんてこともある。 日本語ドキュメントがひどすぎる 情報量はすくないし、間違いも多い。 たとえば、 BlobStore については情報量はゼロ。 1 行も載ってなかった。 CPU 時間の Quotas が 46h (正しくは 6.5 h)になってたり、 発信・受信帯域が 10GB (正しくは 1GB )になってたりする。 アプリケーションバージョンを活用する アプリケーション ID が一致しなければ DataStore にアクセスができないので ユーザーサイトと管理者サイトなどを分けたい場合はアプリケーションの バージョンを分けて管理する。
  • 8.
    実際に使ってみた感想 ~モデル編1 予想通りDataStore 設計は非常に悩ましかった まず、なにが正解かわからなかった。(いまもわからない) どこまで非正規化するべきか。究極は1 Kind のみだけどそれは無理。 できたとしても、毎回全プロパティ読込とかはコストかかりすぎ。 非正規化にも限度があるし、それほど固執する必要もないかも。 なんだかんだで自然と読取処理が楽になるような設計になってくる。 エンティティグループ( EG )使わなくてもイケル。 トランザクションの範囲を指定するために EG があるのなら slim3 の gtx を使えば EG の設計を考える必要はないんじゃないか? 実際に今回は 1 個も複数エンティティの EG は作ってません。 リストプロパティ使わなきゃよかった コンポジットインデックスを使用することによるインデックス爆発怖い。 1 エンティティのサイズが大きくなる。 だったら最初から使わなきゃよかった。結局 1 箇所しか使ってません。
  • 9.
    実際に使ってみた感想 ~モデル編2 スキーマバージョン管理ルールは決めておくべきDataStrore はスキーマレスなので Kind 内に構成が異なるエンティティが存在できる。 途中でエンティティのプロパティに増減があったりして 過去データとのマージが必要になった場合などに スキーマバージョンの運用ルールが決められていないと泣ける。 ちなみに今回のルールはプロパティの増減があった場合に バージョンを 1UP するという普通のルールでした。
  • 10.
    実際に使ってみた感想 ~その他編 appengineに向いてる案件の条件 制限に対する代替案を決定する権限が開発側にある appengine 特有の制限にぶつかった場合、 代替案決定のイニシアチブがユーザー側にあると 制限を回避できないことがあるかもしれない。 ちょいちょいアクセス出来なくても大問題にならない appengine はちょいちょいアクセスできなくなったりします。 完全に業務系とかだと、いつ復旧するかわからなくて ドキドキしちゃうので、まだ appengine は使わない方が良いかも。
  • 11.
    日本初 !?SDK1.3.6 を使った画像リサイズ解説BlobStore の特徴 1 ブロブあたり 2GB まで保存可能 1 リクエスト 10MB 制限が関係ない サーブレットを経由しないでアップロード DataStore のようにデータ構造は保存できない   blob を保存できるだけ
  • 12.
  • 13.
    SDK1.3.6 を使用したサムネイル作成 たった2 行で完成!! 1.3.6 では画像を表示する URL を作成する 作成される URL http://localhost:8888/_ah/img/6Fv6uJwIwmQzNCrYj8T_JA =s160 =s160 ←  この部分で表示される画像サイズ(ピクセル)を指定する この指定だと縦横比を保持してリサイズされます =s160-c この指定だと正方形にリサイズされます 指定可能なサイズは 1.3.6 の JavaDoc にて確認できます 1.3.6 の結果ファイルサイズが 1.3.5 と比較して約 1/5 と圧倒的に小さい。 ※ 1.3.6 はプレリリースなのでデプロイは出来ません。
  • 14.
  • 15.