各種情報
• 無線LANアクセスポイント
– AP0007406A1B99
– Jumpstart-P1-4b363d
• ニコニコ生放送（18:30-）
– http://live.nicovideo.jp/watch/lv2129384
– 映ると問題のある方はカメラの位置にご注意下さい。
Google App Engine Hackathon in Kyoto
第一回 事前勉強会
京都GTUG
マネージャー 山下大介
はじめに
• 本日は、みなさまお越し下さいまして、ありが とうございます。
注意点
• ネットでライブ中継されています。
– 映ると問題のある方はご注意下さい。
注意点
• 写真撮影はご自由にどうぞ。
– フラッシュは控えて頂けると助かります。 – ブログへの掲載も問題ありません。
• スタッフ以外の顔が入っているものは、加工していた だくか個別に許可を取って下さい。
注意点
• スタッフもイベントの様子を撮影します。
– ８月８日のHackathon終了後に京都GTUGおよ び京都GTUGが許諾したメディアなどで公開され ます。
– 参加者には事前に写真データが共有され、公開 されると問題のある写真はご連絡頂ければ、削 除・加工の措置を取ります。
自己紹介
• 山下 大介
– メール：[email protected]
– ブログ：http://blog.daisukeyamashita.com/ – twitter：http://twitter.com/dddaisuke
• 京都GTUG マネージャー
• 株式会社ＳＯＢＡプロジェクト 取締役
– KRP２号館２階
• 会社では自社開発のP2P通信方式による、VoIP技術の普及に努めており、ここ 数年は主にサーバサイド周りの技術検証／実装をしています 。（主に、ウェブ会 議システムのSOBA CITYやSOBA mierukaの開発）
京都 GTUG とは？
正式名称
「Kyoto Google Technology User Group」
Kyoto GTUG Kyoto GTUGKyoto GTUGKyoto GTUG
目的
純粋・シンプルにGoogleのテクノロジーを 理解・習得するための活動をする。
（これは、世界中のGTUG共通の目的）
*漢字表記の「京都GTUG」は国内のみの利用でお願いします。
Google Technology User Groupとは？
• 現在、全世界で27ヶ国60を超える地域でローカルなGTUG が設立されています。
– http://www.gtugs.org/directory
• 各地域で、Googleのテクノロジーに興味のある方々が組織 を立ち上げています。
• 将来的には、地域を越えたイベントもやりたいよね！という 話が、マネージャのMLでやりとりされています。
京都 GTUG へ！
• まだ、参加してない方はぜひ参加して下さいね！
http://kyoto-gtug.org/
http://kyoto-gtug.org/ http://kyoto-gtug.org/ http://kyoto-gtug.org/
勉強会に入る前に・・・
• Hackathonで利用しようと思っている言語を 教えてください。
– Python – Java
– その他（PHP, Ruby, Scala・・・）
• Google App Engineとは？
• Google App Engine コンソールの解説
• データストア（BigTable）APIの使い方
Google App Engine とは？
• 2008年4月8日 Google Campfire Oneでローンチさ れたGoogleが提供するクラウドサービスです。
Google のインフラ上で
Web アプリを走らせられる！
• ハードウェア
• ネットワーク
• OS
• アプリケーションサーバ
• データベース（BigTable）
• ストレージサービス
• いくつかのサービス（API）
メンテナンスは Google 任せ！
• サーバのセットアップ・メンテナンス一切不要
– だけど、コンソールはたまにアクセス不能になっている
（笑）
• APIを通じてGoogleのサービスにアクセスできる
– バックエンドはGoogleが普段利用しているシステムその もの
主な特徴
• サーバをインストール、メンテナンスする必要がありません
• Googleがサーバをスケールアウトしてくれます
• 標準的なAPIを経由して、Googleのスケーラブルな各種サービスにアク セスできます
• 利用した分だけ料金を払えばいい
– ほとんどの場合は無料。（月間500万アクセス相当分は無料）
• 専用の管理コンソール
料金
項目名 購入単位 １日あたりの無料範囲
送信 $0.12/GByte 1.00 GBytes
受信 $0.10/GByte 1.00 GBytes
データ保存 $0.005/GByte-day 1.00 GBytes
メール送信 $0.0001/Email 2,000.00 Emails CPU Time
CPU Time
CPU TimeCPU Time $0.10/CPU hour$0.10/CPU hour$0.10/CPU hour$0.10/CPU hour 6.50 CPU hours6.50 CPU hours6.50 CPU hours6.50 CPU hours
アーキテクチャ
リクエスト App Engine
Front End App EngineFront End App EngineFront End
App Server App Server App Server
Other Google Infrastructure Other Google Infrastructure Other Google Infrastructure Other Google Infrastructure
•BigtableBigtableBigtableBigtable
•Google AccountsGoogle AccountsGoogle AccountsGoogle Accounts
•MemcacheMemcacheMemcacheMemcache
•Image manipulationImage manipulationImage manipulationImage manipulation APIAPI API API経由 ロードバランサ
Google App Engine の注意点
• 対象のウェブアプリケーション
– HTTPリクエストが30秒に制限されている – 長いバックエンド処理ができません
– サーバプッシュ通信ができません
• サンドボックス環境
– SecurityManagerが利用されています – スレッドが利用できません
– リードオンリーのファイルシステムです
ソフトウェアサービス
Javaの例
サービス名 Java Java Java Java 標準 Google InfrastructureGoogle InfrastructureGoogle InfrastructureGoogle Infrastructure
認証 Servlet API Google Accounts
データストア JPA, JDO Bigtable
URLフェッチ URLConnection Caching HTTP proxy E-mail javax.mail Gmail gateway
キャッシュ javax.cache memcacheg
ウェブサービスの成長について考える
アメリカの最大手ブログサイトのひとつ
「LiveJournal.com」
アメリカの最大手ブログサイトのひとつ
「LiveJournal.com」
Static File Servers Static File Servers Static File ServersStatic File Servers
Frontends Frontends
FrontendsFrontends Application ServersApplication ServersApplication ServersApplication Servers
Memcache Memcache Memcache Memcache
Storage StorageStorageStorage
シンプルな LAMP
• Linux, Apache, MySQL, プログラミング言語
• スケーラビリティは？
データベースとウェブサーバ共有
• 信頼性は？
Single point of failure (SPOF)
データベースの分離
• データ容量が増えてきたので、メインの サーバからデータベースを分離します。
• 要求
他のマシンを追加で管理しなければなら ない。
• スケーラビリティは？ １台よりはマシ
• 信頼性は？
SPOFが２ヶ所に！
ウェブサーバを増やす
• より多くのリクエストを処理するために、ウェブサーバを追加し ます。
• 要求
もっと多くのサーバを管理しなければなりません。 ロードバランサも必要になってきます。
ロードバランサの追加
DNSラウントロビン
• ロードバランシングの一番簡単な方法は、DNSラウンドロビン
– IPのリストをDNSに登録します
• 静的なロードバランシング
• DNSのレコードはTTL(Time To Live)時間キャッシュされます。
– このTTLは無視されることもある
ロードバランサの追加
• ロードバランシングの一番簡単な方法は、DNSラウンドロビン
– IPのリストをDNSに登録します
• 静的なロードバランシング
• DNSのレコードはTTL(Time To Live)時間キャッシュされます。
– このTTLは無視されることもある
DNSの変化が伝播されるの待つ必要が出てくる！
ロードバランサの追加
• スケーラブルか？
– もっと多くのウェブサーバを追加する必要があったら？
– データベースに対するI/Oの制限は？
• 信頼性は？
– トラフィックをすばやくリダイレクトすることができません – いまだ、データベースはSPOFになっている
リバースプロキシ
• ルーティングをカスタム設定できる
– 専用化された仕組み
– アプリケーションレベルのロードバランシング
• 要求
– より多くのマシンの管理
– リバースプロキシのためのプログラムと設定
リバースプロキシ
• スケーラブル？
– もっと多くのウェブサーバを追加したら？ – 専用の仕組みを持っている
– 制限
• リバースプロキシのルーティング容量
• １つのデータベースサーバ
• 信頼性は？
– そこそこ速いアプリケーションレベルのルーティング – 専用の装置だとより強固で速いです
– 複数のリバースプロキシを設置すると、ネットワークレベルのルーティ ングが必要となります
• DNSラウンドロビン（再び）
• 高級ネットワークルーティングハードウェア
– いまだ、データベースはSPOFです。
Master-Slave データベース
• 読み込みスループットが良くなります
• 要求
– さらに多くのマシンの管理
– MySQLやアプリケーションの設定変更
Master-Slave データベース
• スケーラブル？
– 台数に応じて、Readはスケールします
• けど、Writeはスケールしません
• 結局何がおこるのか？
Master-Slave データベース
• 信頼性は？
– 書き込みに使用するマスターはSPOF
– レプリケーション処理の前にマスターが死んだら？
仕切られたデータベース
Partitioned Database
• Read/Writeスループットが共に増加する
• 要求
– もっと多くのマシンを管理しなければならない
– マシン以外にもIPや権限設定など管理することが沢山！ – データモデルも変更しなければならない
– SQL クエリーも書き換えだ・・・
俺たちは、そんなにヒマじゃない！
誰か助けて！
App Engine スタック
全部 Google におまかせ！
• めんどうなサーバの管理
– 電源管理 – 空調管理 – アクセス制限
– ディスク残量の監視
– ネットワーク帯域・到達性の監視 – 各種デーモン・サービスの停止監視 ：
：
• さらには、スケールアウトまで
– ハードウェアの調達 – 最初の設定
– アプリケーションプログラムのデプロイ – IP・ロードバランサの設定
： ：
Google App Engine さまざまな数字
Google App Engine
• 8万を超えるアプリケーション
• 1.4億ページビュー/dayを超えるアクセス
• 20万を超える開発者に使われている
Open For Questions
• アメリカ、ホワイトハウスの「Open For Questions」アプリケーショ ンは、48時間で、10万件の質問と360万件の投票を処理した
Google App Engine データの処理について
静的コンテンツの取り扱い
Googleネットワークにおける 静的ファイルへのリクエスト
• 最も近いGoogleのデータセンターに接続します
• Googleのネットワークを探します
– 他のGoogle製品が使用するのと同じインフラ＆仕組み – 多くの利点があります
静的ファイルへのリクエスト Front Endへのルーティング
• Google App Engine Front End
– ロードバランシング – ルーティング
• Front Endは静的コンテンツ専用のサーバに静的ファイルの リクエストを送ります
静的ファイルへのリクエスト 静的コンテンツの配信
• Google Static Content配信
– 共有のGoogleインフラ上に構築
• 静的ファイルはコードファイルから物理的に分離されています
• どのように静的ファイルを定義するのか？
静的ファイルへのリクエスト
何が静的コンテンツとして扱われるのか？
...<static>
<include path="/**.png" />
<exclude path="/data/**.png" />
</static> ...
...- url: /images
static_dir: static/images OR- url: /images/(.*)
static_files: static/images/\1 upload: static/images/(.*) ...
Java Runtime: appengine-web.xml
Python Runtime: app.yaml
静的ファイルへのリクエスト ユーザへのレスポンス
• Front Endに戻り、ユーザにレスポンスします
• 専用インフラ
– アプリケーション・ランタイムは静的コンテンツを配信しません
Google App EngineのAPI
API リクエスト
Memcacheg
より多くの永続データを インメモリーキャッシュする
• メモリーキャッシュ
• memcacheg
– Brad Fitzpatrickによって書かれた – 追加：set_multi, get_multi, add_multi
• 最適化のために楽観的にキャッシュしてください
• 非常に安定していて、強く専門化しています
App Engine Datastore 永続ストレージ
App Engine Datastore 永続ストレージ
• あなたのデータは既に仕切られています
– エンティティグループを使用してください
• 速い読み込みのために、明示的なインデックスを作成します
– だけど、書き込みは遅い
• レプリケートされており、フォールト・トレラントです
– 3台以上のマシンにコミットされます – 物理的に分配されています
• ボーナス：グローバルにユニークIDを保ちます
他の API
•GMail
•Google Accounts
•Picasaweb
•Gadget API
•ロードマップ
•Pythonには実装済み
•Google Talk
• Google App Engineとは？
• Google App Engine コンソールの解説
• データストア（BigTable）APIの使い方
Dashboard
Quota Details
Logs
Cron Jobs
Task Queues
Indexes
Data Viewer（Kind）
Data Viewer（GQL）
Application Settings
Application Settings
Developers
Versions
Admin Logs
Billing Settings
Billing Settings
Billing History
System Status
• Google App Engineとは？
• Google App Engine コンソールの解説
• データストア（BigTable）APIの使い方
Google Plugin for Eclipse
Google Plugin for Eclipse
• 「Eclipse 3.3 (Europa)」をお使いの方
http://dl.google.com/eclipse/plugin/3.3
• 「Eclipse 3.4 (Ganymede)」をお使いの方 http://dl.google.com/eclipse/plugin/3.4
• 「Eclipse 3.5 (Galileo)」はまだ未対応です
詳細は、私が書いたこちらの記事をご参照下さい。 http://codezine.jp/article/detail/3835
プログラムのデプロイ
デモ
データストアの解説
デモ
• ソースコードはHackathon用のリポジトリに入っています
http://code.google.com/p/kyoto-google-technology-user-group/
