ajn13では大規模事例ということでバスキュールさんの「mixi X'mas2010」と「the Actress」の話があった。
コスト1/30で無限スケーラビリティの衝撃
クラウドを空想してあれこれ議論するよりも論より証拠。１００の理論より１つの事例。
mixi X'mas2010 （詳細はtogetterや、kazunori_279さんの記事を参照）
* 登録者数275万、ピーク時の最大風速620req/sec。ただし上限(limit)については最初からGoogleに相談済み。
* 2200万-2500万req/日くらい。420インスタンス、を目撃した。ただし、このリクエスト数に静的リクエストは含まない。
(またflashのダウンロードなどあるので、そこはAWS CloudFrontを使ったり、ちゃんと使い分けている）
* 12/1-24までのリクエスト総数5億3千万ほど。データストア95GB、レコード数2億件程。
* 開発期間は2ヶ月くらい。実装は1ヶ月*一人。WebAPI*20 モバイル画面*50
バスキュールさん曰く、「今までは面白いことをたくさんの人を巻き込んで大規模にやろうとしても初期コストが問題になっていたが、appengine で初期コストを気にせずできるようになった。」とのこと。
「大体、1000万リクエスト＝100ドル！インフラの桁が1個違う。もう戻れない」
個人的に聞いたところコストは約1/30で済むとのことだった。３０％ではなく１/３０！私はこれを聞いて電撃的ショックに見舞われて真空状態に陥った。
（広告でもよく見かける「クラウド導入で30%コスト削減」とか、そんなのは鉛筆舐めて工数叩いてやってるだけのエセクラウドなんですよ。逆に、GAEが本物のクラウドだという証拠でもある。）
しかも、オートスケールが素晴らしい。2200万req/日のシステムというだけでも相当難易度の高いシステムが要求されるはずだが、GAEは「mixiクリスマスはたった二日半で100万ユーザ、一週間で200万ユーザ。2200万req/日。想定していない数字だったが涼しい顔でスケールアウト」
こんなの、LAMPで作れる自信はありません。
これを一人で作って、しかも、開発期間は2ヶ月くらい。実装は1ヶ月*一人、運用まで全部やるなんていうから、これまでの常識では到底考えられません！！
たしかに、実際の開発では、大規模システムのための高いスキルやノウハウが必要とされ、GAEという特殊環境のなかでチューニングをやっていくのは大変だと思う。
だが、それらを乗り越えられる者だけが、これまでの常識では到底考えられないような、スケーラビリティとコストメリットという果実を得ることができる。
今後はさらに、この全く新しいパラダイムが加速されて広がっていくのは必定で、無限のスケーラビリティ、コスト1/30に古い世界が駆逐されていくのは火を見るより明らかだ。そうなるのは、もう時間の問題である。
その新しい舞台にで生き残っていくためにも、私たちはGAEは必須と考えて、スキルノウハウの蓄積やソフトウェア開発を惜しみなくすすめていく必要があると思っている。
大規模リクエストを処理するためのテクニックについて
大規模なリクエストを処理するには、GAEといえども、様々なチューニングを必要とする。
こういったテクニックやノウハウはajnだからこそ得られる大変貴重なものだ。（運営者の方々、感謝です！）
* 設定情報をstatic変数に保持し、Memcacheへのアクセスを減らすのが効果的。static変数に有効期限を設ければ、全インスタンスに行き渡らせることができる。
static変数-（期限切れor価なし）->Memcache-（価なし）->Datastore の順にアクセス
* mixiの10秒制限対策（millisec/reqのグラフで、普段は数百msなのにたまに數千msかかるタイミングが集中する事がある）では、datastoreのdeadline設定を行う
(DatastoreServiceConfig でDatastoreのタイムアウト時間を設定できる。datastoreのdeadline指定は、今のところ全てのアクセスに対して行ってる。クエリの種類などに応じて制御はしてない)
* 「query よりbatch getを優先」→これは #appengine で超重要
* カスタムインデックスとマージジョインは使用しなかった。カスタムインデックスが作られないと怖いので。十分に検証する時間がなかったため避けた → 現在のバージョンであれば大丈夫。
マージジョンはデータ件数が多いと効かなくなる。→ 現在のバージョンでも変わらないので、カスタムインデックスを作ることで対応する
* 規模が大きいためTQの利用を限定的にした。→ TQのQuotaはDatastoreと共有なので、設定ファイルに定義できる。（解決可能かもしれない）
* エンティティのキーの先頭にタイムスタンプをつけてた→特定のタブレットにアクセスが集中することでタイムアウトエラーが発生しやすくなった→ハッシュ値をつけてエンティティの分散を行った
* メモリ使用量問題への対策：１リクエストでの処理を減らす。モジュールのロードを減らす、使用頻度の低いものは極力ロードしない。変数によるキャッシュを減らす
(メモリに一度に取得するのではなく、非同期get/putとIteratorを使うことで、３０％のパフォーマンス改善を見込めるとのこと。V1.4以降）
現状の課題について
現状の課題について、気になったところをピックアップしてみる。
* アクセスが多い場合にログが全部取れないという問題がある。名前はいえないが、現地のとあるGooglerによれば、解決する作業は始めてはいますよとのこと。今後に期待したい。
* 複数のappidが連携するアプリを構築したら利用規約に違反するという問題。→ 複数appidを使って無料クオータを使うような悪質なものでなければＯＫ
* バージョンアップ時のSpinup問題（spinupが猛烈に発生して、スケールアウトが間に合わなくなりそう） → うーん。
* セキュリティ（個人的に会話した部分）：個人情報などを格納できないので、他のサービスを使わざるを得ない。
フラッシュマーケティングなどでクラウドに置く事例も出てきてはいるが、問題解決していないまま使っているケースであり、かなり危険（赤信号、皆で渡れば怖くない状態になっている現状）
最後に、appengineは劇的なスピードで機能追加・パフォーマンス改善が行われてる。夏と今で比べてもかなり違う気がする。過去断念した人ももう一度トライしてみよー。
GAEは、ソーシャルアプリに向いてる！gae/j+slim3+eclipseの生産性が素晴らしい！
