Google App Engineとその影響 2009/11/13 きしだ なおき Javaコミュニティ@九州 例会
自己紹介 <ul><li>きしだです。 </li></ul>
なぜクラウドか
初期のネットワーク
構造化されたネットワーク <ul><li>サーバーごとに役割を決める
データの内容でも構造化 </li><ul><li>ex:はてなはidごとに サーバーをわける
ex:2chは板ごとに サーバーをわける </li></ul></ul>
ネットワークへ携帯端末の参加
端末の大きさと通信頻度
端末の大きさと端末の数
つまり全体の通信量
構造化されたネットワーク <ul><li>再配置が追いつかない
爆発する通信に対応できない
WEB+DB PRESSのヤフオクみたいなことを今はできない。 </li></ul>
クラウド <ul><li>構造化しない
すべてのサーバーですべての処理 </li></ul>
Google App EngineとAmazon EC2
Amazon EC2は仮想サーバー貸し <ul><li>サーバーを存在させただけ課金
なんでもできる
アクセスがなくても課金される
サーバーの設定は自分で
サーバーの構成は自分で
つまり、クラウド上の構造化サーバー </li></ul>
Google App Engineはリソース貸し <ul><li>リソースを使っただけ課金
アクセスがなければ課金されない
制約が大きい </li><ul><li>スレッドが起動できない
リレーショナルデータベースではない
データをまたがるロックができない </li><ul><li>データは複数サーバーに配置されるので、複数サーバーがロックされる </li></ul></ul></ul>
Google App Engineの機能
分散key-value-store <ul><li>各データはどこかのノードに配置される
データはProtocolBuffersでシリアライズされて格納される </li><ul><li>Protocol Buffers ・・・ Googleのシリアライズ仕様 </li></ul><li>RDBとの設計思想の転換 </li><ul><...
GAE:データを処理して格納してストレートに抽出 </li></ul></ul>
Google App Engineでのデータストア <ul><li>データは分散して配置される </li></ul>
JDOとネイティブAPI <ul><li>JDO </li><ul><li>コード書きやすいけど制約
GAEのすべてを使い切れない
実装が未熟 </li><ul><li>クエリー最適化
バグ </li></ul></ul><li>ネイティブAPI(low level API) </li><ul><li>仕様が小さい
GAEのすべてを使える
コードめんどくさい </li></ul></ul>
JDO
準備 <ul><li>PersistenceManagerFacoryを取得するコード </li><ul><li>Googleのドキュメントに書いてあるコード </li></ul></ul>public final class PMF { pr...
エンティティ定義 <ul>アノテーションでいろいろ指定 </ul>@PersistenceCapable(identityType = IdentityType.APPLICATION) public class Member { @Prima...
登録 <ul><li>オブジェクトを生成してmakePersistentする </li></ul>//データベース登録 PersistenceManager pm = PMF.get().getPersistenceManager(); Mem...
Upcoming SlideShare
Loading in …5
×

Google App Engineとその影響(補足)

5,223 views
5,106 views

Published on

2009/11/13 Javaコミュニティ@九州 例会でのプレゼンテーション
11/18 本番でしゃべったことをふまえて補足をいれました。

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,223
On SlideShare
0
From Embeds
0
Number of Embeds
440
Actions
Shares
0
Downloads
32
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Google App Engineとその影響(補足)

  1. 1. Google App Engineとその影響 2009/11/13 きしだ なおき Javaコミュニティ@九州 例会
  2. 2. 自己紹介 <ul><li>きしだです。 </li></ul>
  3. 3. なぜクラウドか
  4. 4. 初期のネットワーク
  5. 5. 構造化されたネットワーク <ul><li>サーバーごとに役割を決める
  6. 6. データの内容でも構造化 </li><ul><li>ex:はてなはidごとに サーバーをわける
  7. 7. ex:2chは板ごとに サーバーをわける </li></ul></ul>
  8. 8. ネットワークへ携帯端末の参加
  9. 9. 端末の大きさと通信頻度
  10. 10. 端末の大きさと端末の数
  11. 11. つまり全体の通信量
  12. 12. 構造化されたネットワーク <ul><li>再配置が追いつかない
  13. 13. 爆発する通信に対応できない
  14. 14. WEB+DB PRESSのヤフオクみたいなことを今はできない。 </li></ul>
  15. 15. クラウド <ul><li>構造化しない
  16. 16. すべてのサーバーですべての処理 </li></ul>
  17. 17. Google App EngineとAmazon EC2
  18. 18. Amazon EC2は仮想サーバー貸し <ul><li>サーバーを存在させただけ課金
  19. 19. なんでもできる
  20. 20. アクセスがなくても課金される
  21. 21. サーバーの設定は自分で
  22. 22. サーバーの構成は自分で
  23. 23. つまり、クラウド上の構造化サーバー </li></ul>
  24. 24. Google App Engineはリソース貸し <ul><li>リソースを使っただけ課金
  25. 25. アクセスがなければ課金されない
  26. 26. 制約が大きい </li><ul><li>スレッドが起動できない
  27. 27. リレーショナルデータベースではない
  28. 28. データをまたがるロックができない </li><ul><li>データは複数サーバーに配置されるので、複数サーバーがロックされる </li></ul></ul></ul>
  29. 29. Google App Engineの機能
  30. 30. 分散key-value-store <ul><li>各データはどこかのノードに配置される
  31. 31. データはProtocolBuffersでシリアライズされて格納される </li><ul><li>Protocol Buffers ・・・ Googleのシリアライズ仕様 </li></ul><li>RDBとの設計思想の転換 </li><ul><li>RDB:データをストレートに格納して抽出時に処理
  32. 32. GAE:データを処理して格納してストレートに抽出 </li></ul></ul>
  33. 33. Google App Engineでのデータストア <ul><li>データは分散して配置される </li></ul>
  34. 34. JDOとネイティブAPI <ul><li>JDO </li><ul><li>コード書きやすいけど制約
  35. 35. GAEのすべてを使い切れない
  36. 36. 実装が未熟 </li><ul><li>クエリー最適化
  37. 37. バグ </li></ul></ul><li>ネイティブAPI(low level API) </li><ul><li>仕様が小さい
  38. 38. GAEのすべてを使える
  39. 39. コードめんどくさい </li></ul></ul>
  40. 40. JDO
  41. 41. 準備 <ul><li>PersistenceManagerFacoryを取得するコード </li><ul><li>Googleのドキュメントに書いてあるコード </li></ul></ul>public final class PMF { private static final PersistenceManagerFactory pmfInstance = JDOHelper.getPersistenceManagerFactory(&quot;transactions-optional&quot;); private PMF() {} public static PersistenceManagerFactory get() { return pmfInstance; } }
  42. 42. エンティティ定義 <ul>アノテーションでいろいろ指定 </ul>@PersistenceCapable(identityType = IdentityType.APPLICATION) public class Member { @PrimaryKey @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY) private Key id; @Persistent // @javax.jdo.annotations.Unique unique属性は効かない private String screenName; @Persistent private String name;
  43. 43. 登録 <ul><li>オブジェクトを生成してmakePersistentする </li></ul>//データベース登録 PersistenceManager pm = PMF.get().getPersistenceManager(); Member m = new Member(screenName, name); try{ pm.makePersistent(m); }finally{ pm.close(); }
  44. 44. クエリー <ul><li>抽出はクエリーで行う
  45. 45. 文字列での指定もできる </li></ul>PersistenceManager pm = PMF.get().getPersistenceManager(); try{ Query q = pm.newQuery(Member.class); q.setUnique(true); q.setFilter(&quot;screenName == pScreenName&quot;); q.declareParameters(&quot;String pScreenName&quot;); Member m = (Member)q.execute(screenName); if(m != null){ message = m.getName() + &quot;がみつかったよ&quot;; }else{ message = screenName + &quot;はみつからなかった&quot;; } }finally{ pm.close(); }
  46. 46. エンティティグループ <ul><li>同じエンティティグループのエンティティは同じサーバーに配置される </li><ul><li>※正しくは同じ「ネットワークのサーバー」 </li></ul><li>同じエンティティグループのエンティティに対してだけトランザクションが保証される </li><ul><li>複数のノードにまたがったロックをしたくない
  47. 47. トランザクションは楽観的ロック </li><ul><li>とりあえずデータ取得
  48. 48. 処理
  49. 49. データ更新・・・だれかが先に更新してたら失敗 </li></ul></ul></ul>
  50. 50. ネイティブインタフェース <ul><li>Low Level API </li></ul>
  51. 51. サービス
  52. 52. メール <ul><li>メール送信 </li><ul><li>Java Mail
  53. 53. ネイティブAPI </li><ul><li>こちらのほうが楽 </li></ul></ul><li>メール受信 </li><ul><li>/_ah/mail/メールアドレス というアドレスにアクセスがくる
  54. 54. HTMLメールが処理できてないかもしれない
  55. 55. くわしくは http://d.hatena.ne.jp/nowokay/20091024 </li></ul></ul>
  56. 56. 画像処理 <ul><li>拡大縮小
  57. 57. 回転
  58. 58. アップロードはCommons FileUploadで </li><ul><li>デフォルトでは一時ファイルを作るのでオンメモリで </li></ul><li>DBへの格納はBlob型 </li></ul>Image img = ImagesServiceFactory.makeImage(uploadBlob.getBytes()); Transform tr = ImagesServiceFactory.makeResize(48, 48); ImagesService ims = ImagesServiceFactory.getImagesService(); Image smallImg = ims.applyTransform( tr, img, ImagesService.OutputEncoding.PNG); blob = new Blob(smallImg.getImageData());
  59. 59. TaskQueue <ul><li>重たい処理をあとで実行 </li><ul><li>通常のリクエスト処理は30秒制限がある </li></ul><li>再試行の必要な処理 </li><ul><li>queueは、失敗すると自動的に再試行 </li></ul><li>時間がくると指定したURLが呼び出される </li><ul><li>CRONも同様 </li></ul></ul>Queue queue = QueueFactory.getDefaultQueue(); queue.add(TaskOptions.Builder.url(&quot;/queue/tweet&quot;) .param(&quot;tweet&quot;, t.getId().toString()) .countdownMillis(0));
  60. 60. memcache <ul><li>JCacheかLow Level API
  61. 61. JCacheの場合 </li></ul>Cache ch; try { CacheManager cm = CacheManager.getInstance(); CacheFactory cf = cm.getCacheFactory(); Map<Integer, Object> conf = Maps.newHashMap(); ch = cf.createCache(conf); } catch (CacheException ex) { throw new ServletException(ex); } String contents; if(ch.containsKey(USERLIST)){ contents = (String) ch.get(USERLIST) + &quot;<br>read&quot;; }else{ String contents = なにか処理 ch.put(USERLIST, contents); }
  62. 62. 認証 <ul><li>通常の認証は通常のコーディング
  63. 63. Googleアカウントでの認証 </li><ul><li>クラス名がかぶるのでUserという名前のエンティティ名は使いにくい </li></ul></ul>UserService us = UserServiceFactory.getUserService(); if(request.getUserPrincipal() == null){ String url = us.createLoginURL(&quot;/loggedin.jsp&quot;); out.printf(&quot;<a href='%s'>ログイン</a>&quot;, url); }else{ User u = us.getCurrentUser(); out.printf(&quot;ようこそ%sさん<br>&quot;, u.getNickname()); }
  64. 64. サーバーはJetty <ul><li>Tomcatと挙動が違うところがある </li><ul><li>たとえばServletResponseWrapper </li><ul><li>詳しくは http://d.hatena.ne.jp/nowokay/20091027 </li></ul></ul></ul>
  65. 65. GAEによる言語精力図の変化 <ul><li>Javaの復権
  66. 66. PHPは相対的にさがる </li><ul><li>Azureで対応? </li></ul><li>Pythonが劇的にあがる
  67. 67. Rubyがやばい </li><ul><li>JRubyでは余分にCPU課金の可能性
  68. 68. JRubyを使ってまでGAEで動かす人がどれだけいるか </li></ul></ul>
  69. 69. Javaの今後
  70. 70. ブラウザアプリケーションの高度化
  71. 71. まずこれを見て欲しい
  72. 72. HTML5 <ul><li>キャンバス
  73. 73. ローカルストレージ </li><ul><li>サーバー側DBとの同期
  74. 74. ローカルストレージの使えないブラウザの対応
  75. 75. サーバー切断時のスタンドアローン処理 </li></ul></ul>
  76. 76. JavaScriptの欠点 <ul><li>継承の使いづらさ
  77. 77. コレクション
  78. 78. データ処理
  79. 79. 補完などのツール </li><ul><li>GUIフレームワークはクラス数が非常に多いので、ドキュメントで調べながらでは効率が悪い
  80. 80. Javaなら補完で適切なクラスが推薦される </li></ul></ul>
  81. 81. JavaScriptコンパイラ <ul><li>Java->JavaScript </li><ul><li>GWT </li></ul><li>Python->JavaScript </li><ul><li>Pyjamas </li></ul><li>PHP->JavaScript </li><ul><li>PHP GWT </li></ul></ul>
  82. 82. モバイル <ul><li>Android
  83. 83. iPhone
  84. 84. HTML5なら動くよ! </li></ul>
  85. 85. Javaの復権! <ul><li>クラウド動くよ!
  86. 86. JavaScriptにも変換できる
  87. 87. 携帯もAndroid!
  88. 88. Pythonもやばい </li></ul>
  89. 89. プログラマの復権 <ul><li>Webアプリはプログラムとして単純 </li><ul><li>request->responseのフィルタ処理
  90. 90. RDBMSと文字列処理ができればよい
  91. 91. 言語の百花繚乱 </li></ul><li>ユーザーインタフェースは難しい
  92. 92. ローカルストレージも難しい
  93. 93. 分散key-value-storeも難しい
  94. 94. プログラマの力量でサーバー課金が変わる </li></ul>
  95. 95. がんばりましょう

×