Java Cloud Meeting Tokyo 2010に行ってきた - pekeqのブログ
Java Cloud Meeting Tokyo 2010に行ってきた。いろいろ聞いてきたけど、id:higayasuo さんのセッション「Google App Engineの本質とSlim3による進化したサクサク開発」だけ軽く書き取ってきた。 今日は予定を変更して、AppEngineの本質の話を全体的にやります。 AppEngineで誤解されがちなところ py/javaどっちがいいの？とか みんな結構気になっていて、pyマンセーみたいにチラホラ出ている 本当のところもあれば誤解されているのもある。 今日はAppEngineはこういうもんだと全部理解して帰ってほしい 1.クラウドの本質 皆さんも考えてみてください。１分くらいあげますんで。 世の中の記事とか本とか、buzword的に取り上げられているけど 自分にとってのクラウドの本質って 一般的にはスケールアウトと言われているのが多いと思い
GAE/J使うならこの設定をしておけ！ - 手抜きぷろぐらまのメモ帳
※2010/4/23 sessionのクリアについてご指摘頂き、追記しました。Google App Engine for Java(GAE/J)にて、どんなアプリを使う場合でも （自分的に）ほぼ必須となる設定ファイルのまとめ。 ていうか、リファレンス読めばいーんだけどさ １．sessionを有効にする & クリアの設定をする Javaでsession使わないケースなんてあるのか？ appengine-web.xml に 下記を追加 <sessions-enabled>true</sessions-enabled> GAE/Jでsessionを使う場合、このままだとDatastoreにsession情報が残ったままなので定期的にクリアするcronを設定する web.xml に 下記を追加 <servlet> <servlet-name>_ah_sessioncleanup</servlet-
URLのトラッキング用パラメータを無視するFirefox拡張 Through utm_ - SWDYH
URLのトラッキング用パラメータを無視するFirefox拡張(Through utm_) を作りました。インストールすると、utm_から始まるパラメータがついたURLにアクセスしようとした場合に、そのアクセスをキャンセルし、そのパラメータを削除したURLへアクセスします。 Through utm_ https://relucks-org.appspot.com/through_utm_/through_utm_.xpi Jetpack SDKを使っていて、ソースはいつものようにGithubに置いてあります。 swdyh's Through-utm_ at master - GitHub http://github.com/swdyh/Through-utm_ Jetpack SDKを使ってちょっと書いてみたという感じのもので、いま思うと他のトラッキング用パラメータ(?ref=rssとか)も
Google App Engine をはじめてみよう
メディア関係者向けお問い合わせ先 メールでのお問い合わせ: pr-jp@google.com メディア関係者以外からのお問い合わせにはお答えいたしかねます。 その他すべてのお問い合わせにつきましては、ヘルプセンターをご覧ください。
Google App Engine上のベスト・プラクティス、その１: Datastore
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
Twitter APIの回数制限をGAE上のプロキシで回避する方法
Twitter API proxyをGoogle App Engine上で動かす方法 プロキシの必要性 プロキシを経由してAPIにアクセスすると何がいいのか TwitterのAPIはアカウント&IPアドレスでカウントされているので、APIの使用回数を増やせる。 グローバルIPアドレスをPCごとに変えられない環境で2台のPCから見るときに便利 Twitterへのアクセスが制限されている環境でも使用できる。 元々GFW（グレート・ファイアー・ウォール）を超えるために作られたっぽい ちゃんと確認してないけど、GAEはホワイトリストに入ってる気がするので、API回数が20000になったりする事もある。 要はAPI使用回数を増やせるよって話。 必要なもの Google App Engineのアカウント Google App Engine SDK とPython実行環境 birdnest 一式のファイ
Song of Cloud: 分散トランザクション処理の最適化
前回の「送金のトランザクション処理パターン」では、EntityGroupにまたがるトランザクション処理について簡単に紹介しました。 様々なコメントいただきまして(ありがとうございます)、どうやら「Distributed Transactions on App Engine - Nick's Blog」のやり方が非常に優れているようですので、今回は「送金のトランザクション処理パターン」で紹介した手法に最適化を施して、Nickさんのやり方に近付けてみようと思います。 今回紹介する最適化は、前回のような「狭い範囲のACIDトランザクション」と「べき等性による処理の伝搬」を組み合わせた分散トランザクション一般に適用できそうな手法です。そんなに大層なことはしていませんが、例によってまだ構想段階ですので、また至らない点があればご指摘いただければ幸いです。 おさらい 送金のトランザクション処理パターンで
Song of Cloud: 送金のトランザクション処理パターン
App Engineで現実的な送金処理について考え中です。 ドラフト版なので、怪しい点があればご指摘いただければ幸いです。 コメントで情報いただきました。 Distributed Transactions on App Engineで紹介されてる方法と基本的に同じなので、おそらく問題なく動きそうです。ありがとうございました。 今回はこんな図を使います。 この図の読み方は、矢印の方向にユースケースの一連の処理(またはリクエストの処理)が流れていて、右に行くほど時間が経過しています。そして、矢印がくし刺しにしている四角形は、そのユースケース中で操作するエンティティを表しています。 また、左右の位置が同じ矢印は、基本的には同じ時刻に発生したイベントを表しています。上記の図では、A, B, Cがそれぞれの口座エンティティを同時に操作している感じです。 並行性制御(おさらい) 最初の図のように、それ
Twitterに140文字以上つぶやきたい時のためのサービス、Tiny Message
Google App Engineでプログラムを書き始めて１週間ほど経つが、ようやくDatastoreの基本が分かってきたので、サービス運営の経験値を積むためにもアプリを一つリリースしてみることにした。 サービス名は、Tiny Message。Tiny URLはTwitterに書くURLを短くしてくれるサービスだが、こちらはTwitterに書くメッセージそのものを短くするサービス。 使い方はいたって簡単。Tiny Messageのホームページ（http://tinymsg.appspot.com/）でメッセージを書き、"make my tweet"というボタンを押すとTwitter投稿用の要約（最初の１００文字）＋URLが表示されるので、それをコピペしてTwitterでつぶやけば良いという仕組みである（メッセージの全文を読みたい人にはURLをクリックしてもらう）。 こんなサービスがチャチャ
ここが大変だよBigtableとGoogle App Engine
ここが大変だよBigtableとGoogle App Engine：分散Key-Valueストアの本命「Bigtable」（3）（1/2 ページ） RDBとは別の、クラウド時代のデータベースとして注目を浴びている「分散Key-Valueストア」。その本命ともいえる、Googleの数々のサービスの基盤技術「Bigtable」について徹底解説 月間3000万PVの大規模サイトの運用費が月額4万円!? 月間3000万PV相当の膨大なトラフィックを楽々とさばく大規模サイトが、月額4万円弱で運用されている。 Google App Engine（以下、App Engine）が普及するにつれて、そんな驚愕の国内事例も登場しつつあります。GClueがApp Engine上で実装したmixiアプリモバイルモバイルには、1日100万PV以上のアクセスが集中している状態でもサービスのレスポンス低下やダウンは皆無
Google App Engine入門：Datastore上で「ユニーク制限」を実現する方法
Google App Engine のDatastoreには、通常のリレーショナルデータベースと比べた時にいくつかの制限があるが、その一つが「このプロパティの値は常にユニークでなければならない」という指定（ユニーク制限）ができないことである。 Invoice IDのように自動生成するものであれば、アプリケーション側でなんとかすることも簡単だが、メールアドレスやハンドル名など、ユーザーが入力するものになると、ユニークであることをきちんと判定した上でEntityを作ることが必要になる。 もちろん、単純に「有無をチェックして、なければ作る」というプログラムではスレッド間の競合に対応できないので、そこはトランザクションを使ってアトミックに処理をする必要がある。 App Engine上でトランザクションを実現するには、エンティティグループという仕組みを使って行うが、気をつけなければいけないのは、エン
App EngineのEntityGroupを理解しよう - ひがやすを技術ブログ
App EngineのEntitiGroupは、Keyの親子関係を利用して組み立てられたEntityの集まりです。 Entityとは、Bigtable上の1つの行で、ユニークに識別するためのKeyを持っています。 Keyは、種類をあらわすkindとAppEngineから自動的に採番されるidもしくはアプリケーション側で自由に決めることのできるnameで構成されます。 通常は、AppEngineの自動採番に任せますが、Emailのアドレスをキーに使いたい場合などは、nameを使います。kindはテーブル名のようなものだと思ってください。 Keyの親子関係は次のようにして作ります。 Key grandparentKey = KeyFactory.createKey("Grandparent", "しげお"); Key parentKey = KeyFactory.createKey(grand
Google App Engine - 独自ドメインでSSL使えない件 - komagataのブログ
Google App Engine の一般的質問 - Google App Engine - Google Code SSL（HTTPS）を Google Apps ドメインの App Engine で使用できますか Google App Engine のすべてのセキュアなトラフィックは、appspot.com ドメイン（https://your-app-id.appspot.com）から提供される必要があります。アプリケーションを Google Apps ドメイン以外から提供している場合、すべてのセキュアなトラフィックをアプリケーションの appspot ドメイン経由で転送する必要があります。 なんと。 独自ドメインでSSL使えないんだったら殆どの仕事で使えなくない？ 要は、"セキュアな通信が簡単に行える環境"が無いのであれば使えないよねえ。 改善か代替案が提供される予定が無いんだとした
Cloud Computing考：Amazon ec2とGoogle App Engineの違いを私なりにまとめてみた
Cloud Computing の話が注目されるようになってしばらく経つが、商用での本格応用という意味ではまだまだ未熟な市場である。PhotoShareは去年の７月サービス開始時から Amazon の ec2＋S3 という組み合わせで運営しており、私から見れば当然の選択だったわけだが、あのタイミングで商用サービスへの採用に踏み切った会社も少なかったのか、何件かインタビューの申し込みが来たりして少し驚いている（参照）。 すぐに陳腐化するハードウェアの資産はできるだけ持ちたくないし、自分でデータセンターにラックを借りるなんてことはコスト的に見合わない。かといって、通常のレンタルサーバーは初期費用がばかにならない（今は少しは改善されているのかも知れないが、去年の段階では「それじゃあハードが自分で買えるじゃん」と言わせるぐらいの初期費用を請求する企業がほとんどであった）。それに加えて、どのくらいの
JJUG CCC 2009 Fall - goldenportのブログ
10月8日に開催されたJJUG CCC 2009 Fallのセッションのスライドです。 クラウド・アプリケーションの作り方View more documents from Tomoharu ASAMI.
Memcacheでスピンロックを実装してTask Queue処理結果を集約してみるテスト - スティルハウスの書庫の書庫
TaskQueueで分散処理した結果をまとめるときは、排他を考慮する必要があります。Datastoreを使う場合なら、単に結果を新規エンティティとして追加したり、エンティティグループの楽観排他を使ったりすればOKです。一方、やっぱりMemcacheでスピーディーに集約したいよ、という場合は、Memcache上で排他を実装する必要があります。以前のエントリにちょろっと書いたMemcacheService#incrementでスピンロックという方法について説明してほしいというコメントをid:miztakaさんよりいただいたので、ここに改めて書きたいと思います。 Memcacheでは排他制御が必要 ご存じのとおり、App Engineはデフォルトで複数のApp Serverによるクラスタが構成されており、またMemcacheサービスはクラスタ全体で共有されるグローバルなキャッシュとして機能します
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: Google App Engineプログラミング入門: 中居良介, 岡野真也, 船井裕, 松尾貴史: 本
100万PV／日のmixiアプリモバイルをGoogle App Engineで実装した@gclue_akira氏に直撃インタビュー
http://atnd.org/events/1850
http://www.machu.jp/posts/20090927/p01/