AppsScript がどこで動いているのかなんて普通気にしないですよね。 今回は、場合によってはそこを気にしないといけないこともあるよ！というお話。
本番リリースで無事死亡
AppsScript で Cloud SQL にアクセスする方法については、以下の記事を読んでください。
Cloud SQL にアクセスする処理のある AppsScript で作ったアプリをリリースしようとしていました。 次のような構成でテスト環境で動作確認を行った後、本番環境をリリースという流れで進めました。
- テスト DB
- リージョン: us-central1 (アイオワ)
- インスタンスタイプ: db-f1-micro
- 本番 DB
- リージョン: asia-northeast1 (東京)
- インスタンスタイプ: db-n1-standard-1
テスト環境では、一番安い組み合わせである us-central1 リージョンと db-f1-micro インスタンスを使いました。 本番環境では、一番近い asia-northeast1 リージョンと SLA 対象の一番安いインスタンスである db-n1-standard-1 インスタンスを選択しました。
テストも終わり、いざ本番リリース！というところでテスト環境だと 2 分ほどで終わっていた処理が本番環境ではいつまで経っても終わらない...なんで...
原因は DB アクセスのレイテンシ
そりゃ太平洋を渡った位置にある二つのリージョンですから、レイテンシに違いがあることは当たり前なんですが、完全に盲点でした...
実際にどれくらい違いがあるか試してみましょう。
検証
asia-northeast1 と us-central1 にそれぞれ同じ db-f1-micro のDBインスタンスを作成しました。
こんな感じでそれぞれの DB に対して select 1 を実行してみます。
結果1 (V8 ランタイム無効化状態)
実行トランスクリプトを見るために V8 ランタイムを無効化して実行しました。 結果は次のようになりました。
us-central1 の DB のクエリ実行が 0.006 秒であるのに対し、 asia-northeast1 の DB のクエリ実行は 0.137 秒でした（なんと約 23 倍！）。
結果2 (V8 ランタイム)
V8 ランタイムでは実行トランスクリプトが見れないので、プログラムを次のように修正します。
結果は次のようになりました。
us-central1 の DB のクエリ実行が 37 ミリ秒であるのに対し、 asia-northeast1 の DB のクエリ実行は 187 ミリ秒でした。 両方とも V8 ランタイムを無効化した時より 30 ~ 50 ミリ秒ほど遅くなりましたが、やはり asia-northeast1 の方が数倍遅い結果となりました。
AppsScript はアメリカのサーバーで動いている
結果1 で us-central1 へのクエリ実行が 6 ミリ秒なのを考えると、AppsScript はアメリカ国内で実行されていると考えてよいでしょう。
まとめ
- AppsScript はアメリカで実行されている
- AppsScript で使う DB インスタンスは us-central1 もしくはその周辺のリージョンで立てるのがよさそう
- DB 接続する場合は V8 ランタイムは無効化しておいた方が良いかもしれない
