Developers Summit 2011のLT大会で発表してきました

デブサミオフィシャルコミュニティから選出のLT大会2011】にappengine ja nightコミュニティから私が発表させて頂きました。このような機会を与えてくれたみんなに感謝します。

資料


当初はLTなのでネタで発表する予定でしたが、その時にちょっとした笑いがもらえるよりも(いやもらえる自信がないけど・・)何か一つでも時間を割いて聞いてくれている方にGoogle App Engineの魅力が伝わった方がいいのではないか.と考えてガチで紹介する事にしました。紹介するにあたって参加者はajnと違ってあんまりGoogle App Engineを知らない方が多いだろうと判断し難しい話を出来るだけ避けましたが如何だったでしょうか。話を詰め込み過ぎて3分30秒では時間が足らず早口でギリギリ時間内という形になってしまいました><);反省します。


今回資料を作る際にGoogle App Engineの良さを整理していたので下記に列挙してみます。

  • Webアプリケーションを公開するのにGmailアカウントを用意したらコードを書いてデプロイするだけ
  • インフラの知識は全く要らない。Webサーバ、DBサーバ、キャッシュサーバ等ははじめから用意されている
  • Googleのインフラ(各サービス/サーバ)はそれぞれが別のノードで動作し、それぞれが無限にスケールアウトする仕組みになっている
  • Webサーバはリクエスト数に応じて自動的にサーバが追加され自動スケールアウトする
  • 自動スケールアウトは、秒間620リクエストをも軽々と捌く実績あり(mixi Xmas2010)
  • Googleの40万台以上あるといわれるサーバリソースを用いて圧倒的な低コストを実現し、無料でも使える。無料でも月間数百万PVを捌ける。(※無料でどれだけこなせるかは作りによります。)
    • バスキュールさん曰く、課金の目安は1日1000万ダイナミックリクエストで約100ドルの計算で試算が出来る。例えば2000万リクエストなら200ドル。一般的に?Google App Engineだと一桁は減る。ものによっては二桁違うという感じです。
    • 雨の日めーるのような多くのリクエストを捌く必要がないアプリケーションなら無料で運用できる
  • 新しいプラットフォームはわからない事が多い。でも、Google App Engineにはappengine ja nightコミュニティがある。Twitterで#appengine, #slim3ハッシュタグ付きで疑問点をつぶやけば大抵はその日の内に返信がもらえる。
  • Google App Engineは無料でもDBを1GB使えて、Cronも動かせるしメールの送信受信も出来る。Google Apps(無料)と連携することで独自ドメインでもメール送受信できる。
    • 受信はGoogle Appsのアカウントで受信させて、Gmailのフィルタでappspot.comのメールアドレスに転送すればok
  • App Engineではメンテナンス期間中にデータベースが読み取り専用になってしまう事があった。システムによってはこれがいままでは最大の欠点だった。High Replication Datastoreというストレージを選択する事ができるようになり、メンテナンス中でも書き込みが可能になった。
  • 30秒ルールが緩和された。1リクエストは30秒しか処理できないという制限があった。普通にWebアプリケーションを作成するのには問題ないように思えるがGoogle App Engineバッチ処理もWebのハンドラで実装する必要があるため30秒ルールはバッチ処理を難しいものにしていた。しかし、CronとTaskQueueは10分まで処理できるようになった。
  • Chanel APIでサーバPushできるようになり、チャットのようなリアルタイムWebなサービスが簡単にできるようになった。簡単にできるだけではない、何せインフラがGoogleという安心感が違う。Googleのインフラだからこそ価値があるのだ。
  • Always On(常時サーバ起動オプション), Warm Up RequestsでSpringなどの重量級なフレームワークが使用できるようになった(?)疑問符をあげているのは私はGoogle App Engineで既存のフレームワークを使うことはあまりお勧めできないからである。また、Always Onで対応できるのはリクエストが少ない間だけでサーバが増える場合はどうしてもspinupは発生するからだ。
  • 自動スケールアウトするPaaSと従量制課金であるという事。
    • mixi Xmas2010はGoogle App Engineの二つの大きな特徴を活かしている。一つ目は自動スケールアウトで公開2日半(57時間)で100万ユーザ、一週間ほどで200万ユーザと急激なトラフィックを捌いている。こんなトラフィックが急増するシステムなのにインフラ担当者が不要なのには驚きだ。二つ目、mixi Xmasは期間限定のサービスで実際に稼動したのは30日もない。このような多くのサーバを必要として即座に多くのサーバが不要となる企画をも可能にするのが従量制課金の凄いところである。今まで不可能だった企画が簡単に出来てしまうのだ。
  • Google App Engineで不要になるものを整理しよう
    • サーバ管理者が不要
    • サーバ機器の管理コストが不要
    • サーバの死活監視が不要
    • ロードバランサー不要
    • トラフィックが急増してもハードウェアを慌ててセットアップする必要無し
    • DBのバックアップが不要。Google App Engineでは一回の書き込みで3台以上のDBサーバに必ず書き込み、その全てで障害が起きない限りデータがロストすることはない。(※但し、コーディングミスによってデータを消してしまう場合はあるので絶対にバックアップが不要とは言えない)
    • ログの一元管理。複数台のサーバを管理した人は経験があると思うが、複数台にまたがるログの収集と解析は大変だ。Google App Engineなら管理コンソールで一元的にどのサーバで発生したかを気にすることなくログが参照できる。またログはダウンロードも可能だ。
    • ミドルウェアの組み合わせ検証不要。
    • セキュリティパッチの適用やOSライセンス、またOSのアップデートによるプログラム修正は不要。なんてたってPaaSだからね。