大分乗り遅れた感が強いですが、東京リージョンに変更しました。 GAE/Jのサイトでもかなり速くなりましたよ〜
私は個人でGoogle App Engineを使って以下のサイトを運営しています。GAE/Java＋素のServletで作っています。
今回リージョン変更の作業を行ったので、ざっくりとしたリージョン変更手順や効果等を書いてみます。
昔のGAE
昔はGoogle App Engineはアメリカのリージョンしか存在せず、通信するだけで200ms程度必ずかかってしまっていました。物理的にデータセンターが遠いので、通信だけで時間がかかってしまいます。各リージョンでどれくらいのレイテンシが発生するのかは以下の記事をご覧下さい。
このレイテンシによって、ただでさえスピンアップに時間がかかるのに加え、高レイテンシによる通信の遅延も発生していたので、GAE＝遅いという印象が強く植え付けられていると思います。実際私はus-centralリージョン＋GAE/Javaで運用していましたが、遅さに辟易していました。
GAE/Jのスピンアップが遅い ＋ 高レイテンシ ＋ フレームワークの初期化が遅い、という3重苦により、ついこの前まで酷い有様でした。GAE/Jを使う限りスピンアップ問題の解決はちょっと難しいし、レイテンシはどうにもならない。ならせめてフレームワークの初期化の時間をどうにかしよう、という事で以前以下の記事を書きました。
このような問題があったため、GAEといえば遅いわ制限キッツイわで萎える開発者が多かったことでしょう。
今のGAE
そしてついに 2016/11/08 に、GCPの東京リージョンができました！
cloudplatform-jp.googleblog.com
この時期と全く同じか不明ですが、GAEはGCP(Google Cloud Platform)の一部なので、GAEにも東京リージョンが追加されたのです！
これで今まで泣く泣くus-centralリージョンで200msのレイテンシを受け入れていたのが、今後はレイテンシ問題から解放されるのです！
という事で早速tree-mapsもus-centralからasia-northeast1に変更しましたので、ざっくり手順を書いてみます。
us-centralからasia-northeast1への変更手順
目標
- GAEを使う。
- 独自ドメインを適用する。
- 独自ドメインに対してLet's encryptでSSL証明書を発行し、適用する。
前知識
現在のGCPでは、リージョン変更は簡単に行えません。
新たに東京リージョンで新規プロジェクトを作成し、そちらにリクエストが向くよう変更しないといけません。
しかし、その手間をかけてでもリージョン変更する価値はあります。
リージョンが選択できない場合は新規にgoogleアカウントを作成する
早速ですが、注意点があります。
私がGAEのアカウントを作成した際は、今のGoogle Cloud Platformの管理画面ではなく、以下のような古い管理画面でした。
この時期に作った古いアカウントのせいか、Google Cloud Platformの管理画面で新しいプロジェクトを作成しようとしても、以下のようにリージョンが選択できませんでした。
Googleのサービスは往々にしてこういったこと（アカウント作成時期により機能が限定される）があるので、ここは素直に新規にGoogleアカウントを作成する事で、以下のようにリージョンの変更が可能な状態になりました。
新規GCPプロジェクトを作成する
GCP管理画面を開き、メニューの左上の部分を選択し、プロジェクトを作成します。
作成するプロジェクト名は、移行前のus-centralで作ったプロジェクト名と同一で問題ありません。ここで旧アカウントのユーザは馴染みが無い事が起こります。
昔のプロジェクト作成時はプロジェクト名＝プロジェクトIDだったのですが、今は異なります。プロジェクト名を入力すると、ユニークなプロジェクトIDが自動で振られます。デプロイする際のプロジェクトIDは、これを入力する必要があります。
GCPプロジェクトを作成後、GCP管理画面の左上のハンバーガーメニューからGAEを選択し、GAEプロジェクトを作成します。ここで何やら見慣れないチュートリアルを強制されますが、頑張って下さい。。。チュートリアルでは、Google Cloud Shell上でgitでサンプルをcloneしてデプロイするデモを体験できます。最終的に何らかのプロジェクトをデプロイし、ブラウザで確認できる状態にして下さい。
チュートリアル完了後、めでたく見慣れたGAEのダッシュボードを拝む事ができます。ここまでできれば後はこの新アカウント・新プロジェクトIDに向けてデプロイしていきます。
EclipseのGoogleログインのユーザを変更する
Quick Start | Google Plugin for Eclipse | Google Developers
上記のpluginを使っている場合のお話ですが、今回Googleアカウントを新規に作成したので、以前まで使っていたアカウントでログインしている状態になっているかと思います。従って、まずデプロイの向き先（Googleアカウント）を変える必要があります。向き先の変え方ですが、ちょっと解りにくいのですが、Eclipseの右下から変更可能です。
デプロイ先のプロジェクトIDの切り替え
デプロイの向き先のgoogleアカウントは変更できました。次はどのプロジェクトにデプロイするかの指定、プロジェクトIDを変更します。前項で確認したプロジェクトIDを、以下に入力して保存します。
これでデプロイ準備完了です！
デプロイする
eclipseプロジェクトを右クリック -> Google -> Deploy to App Engine でいつものようにデプロイしましょう。これで新アカウント・新プロジェクトに向けてデプロイできます。
デプロイは完了してブラウザからも画面表示を確認できますが、独自ドメインからのアクセスは以下のようになっているので、まだユーザは旧サイトを閲覧している状態です。
リクエスト -> www.tree-maps.com(独自ドメイン) -> GAEの旧プロジェクト
旧アカウントのGAEプロジェクトのカスタムドメインを削除する
www.tree-maps.comからのリクエストを、このGoogleアカウントのこのGAEプロジェクトにプロキシするぞ〜、という設定が残ったままなので、これを削除します。
新アカウントで再びカスタムドメインを登録する
新アカウントにはまだ独自ドメインが登録されていない状態なので、ざっくり以下のような感じで登録していきます。旧アカウント作成時に行った作業と全く同じですね。
tree-maps.comでドメイン追加し、tree-maps.comに対するエイリアスとしてwww.tree-maps.comを設定します。途中でドメインの所有権の確認が入るので、レジストラ側のTXTレコードに、指定された値を入力して保存し、TXTレコードの反映を待った後、ドメイン所有権の確認を通過させます。所有権が確認できた後、そのままウィザード通りに選択し、カスタムドメイン定義が完了します。
ここで「Aレコード、AAAAレコード、CNAMEレコードをこう設定しろ」という指示が表示されますが、これは旧アカウントで既にレジストラに入力したものと全く同じなので、レジストラ側の変更は不要です。レジストラ側の変更は、所有権確認のTXTレコードの追加のみです。
SSL証明書の反映
私の場合は旧アカウントで作成してあったLet's encryptのSSL証明書定義が既にあったのでそれを新プロジェクトに反映するだけでした。もし証明書が無ければ、以下の記事を参考にSSL証明を作成して反映して下さい。
トラフィック割当の変更
GAEのチュートリアルでデプロイしたプロジェクトがデフォルトとして登録されてしまっています。
GCP管理画面 -> GAE ->バージョン と選択し、トラフィックを移行し、チュートリアルプロジェクトに向いているのを、新サイトの方に向き先を変えます。向き先変更後、チュートリアルのバージョンを削除してしまいましょう。
移行完了
おめでとうございます！これで移行完了です！
今回は個人サイトだったのでサイト停止時間はあまり気にしませんでしたが、事前にSSL証明書だけ新アカウントに登録しておいたりし、停止時間を減らす事は可能だと思います。
リージョン変更の効果
chrome上で計測
us-centralの場合
TTFB(Time To First Byte) は 319.63ms です。
サイト全体の画面表示速度は以下の通りです。
asia-northeast1の場合
TTFB(Time To First Byte) は 48.14ms です。
サイト全体の画面表示速度は以下の通りです。
大分違いますね。画像やjsやcss等も1リクエスト飛ぶので、そのリクエスト毎に高レイテンシを背負っていたのが、低レイテンシ化した事で、全体の通信が高速されています。
アプリには全く手を入れず、リージョンの変更でサイトの高速化をする事ができました。
これでもう「GAEって高レイテンシなんでしょwwww」なんて事は言えなくなります。
スピンアップとフレームワーク初期化遅い件は？
GAE/J＋素のServletでこれだけ速度が出るようになりましたが、GAE/GOにする事で更なる高速化が望めます。
GAE/GOの驚異的なスピンアップ速度（GAE/Javaと比較して約12.6倍高速）を誇ります。
www.bunkei-programmer.net
Golang自体が超高速なのもあり、試しにフレームワークとしてginを使用した場合、画面にjsonを返すのに300〜600ms程度（この時はus-centralで計測した）だったので、大体1秒以内に画面表示まで完了させる事が可能になりそうです。ここまで高速ならGAEでSPAしても問題にならない領域になりそうです。
おまけ
ここまできたら東京リージョンでGAE/GOにしたらどれくらい速度出るかきになりますよね。せっかくなのでちょっとだけ試してみました。
東京リージョン＋GAE/GOの驚異的な潜在能力
| リージョン | asia-northeast1 |
|---|---|
| ランタイム | golang |
| ランタイム詳細 | go version go1.6.3 (appengine-1.9.48) darwin/amd64 |
| フレームワーク | echo |
上記環境でjsonpをシンプルに返却するURLを用意し、計測した結果は以下の通りです。
・・・・んん？？見間違いかな？
なんか 19msとかいうトチ狂った数値が見えますね。これは驚異的な速度ですね！これがGAEの真の力なのだ・・・！！
us-central + go + ginの場合
asia-northeast1 + go + echoの場合
雑感
GCPの東京リージョン追加は結構インパクト大きいですね。GCE方面でも、GCEがus-centralにあるせいでCloudSQLもus-centralに置かざるを得なかったのが、asia-northeast1に置けるようになったので、全体の高速化ができそうです。
巷ではコンテナの次のステージとして、サーバーレスが挙がっていますね。AWS lambdaの場合はどうやらamazon独自のコンテナ技術を使い、リクエスト時にコンテナを起動する事をしているようです。
d.hatena.ne.jp
これ、よく考えてみて下さい。GAEのスピンアップと似ていませんか？似ているというか、恐らく同じ事をしていますね。初回呼び出し時はコンテナが無いのでコンテナを作成、暫くアクセスが無いとコンテナは自動削除され、スピンダウン状態になる。完全にGAEじゃないですか。もしかしたら、
2008年4月に登場したGAEは、実は相当未来的なサービスだった
と言えるかもしれませんね。AWS lambda等と異なり、普通にjavaプロジェクトを用意する必要がある等の手間こそありますが、それ以外の仕組みはGAEと似ており、AWS lambdaはGAEをコンパクトにしたもののようなものに感じています。
しかし残念な事に昔のGAEは前述した通り、制限が厳しい（今もですが）、ランタイムがjavaとpythonのみだった（今はflexible environmentの登場でdockerで何でもできる）、東京リージョンが無い故の高レイテンシ、という問題があったため、中々日の目を見る事がありませんでしたが、それらを克服しつつある今、再度GAEを見直す時期なのかもしれません。
個人的には、無料でできる事が大きい（月間500万PVを捌く事例もあり）し、オートスケールやセキュリティスキャンの定期自動実行も完備され、OpenSSLの脆弱性地獄に悩む事も無いので、下手にVPS借りたりAWSやGCPでウェイウェイするよりも、GAEにした方が遥かに低価格で規模の大きいものを作る事ができるのではないかと思っています。