appengine ja night #35で発表した資料となります。 App Engine Admim API(Deployment Manager)を使用したデプロイでハマった点と東京GCPリージョン(GAE・Datastore・CloudSQL)の性能検証。

1. App Engine Admin API
を利用した
GAE/Go環境へのデプロイ
と
東京GCPリージョンの
性能評価
2016/11/08 appengine ja night #35

2. 熊野 良 (Ryo Kumano)
2014/06 〜 株式会社グルーヴノーツ 入社
- 肩書きは 「サーバエンジニア・データベースエンジニア」
- GCP上で稼動している自社サービスのインフラ設計・構築・運用を担当
- 2015/08 〜 東京 -> 福岡に移住
twitter: @ryok0607
過去(5年以内)に携わった業務
- 国内大手B2Cサイトのインフラ設計・構築・運用・DB設計・チューニング
など

3. App Engine Admin API
を利用した
GAE/Go環境へのデプロイ

4. “すいません
まずは
弊社サービス
のお話をさせてください

5. MAGELLAN BLOCKS
https://www.magellanic-clouds.com/blocks/

6. MAGELLAN BLOCKSの機能
● “VisionAPIとBigQuery” や
“BigQueryとSalsesforce” のように
API同士をマッシュアップする機能。
● ログ収集やファイルアップロード環境を
任意のGCP上に構築する
オーケストレーション機能。

7. MAGELLAN BLOCKSの機能
● “VisionAPIとBigQuery” や
“BigQueryとSalsesforce” のように
API同士をマッシュアップする機能。
● ログ収集やファイルアップロード環境を
任意のGCP上に構築する
オーケストレーション機能。 今日は
こちらの話

8. MAGELLAN BLOCKSによる
オーケストレーション

9. Message収集用のパイプラインと
Deployment Managerによる構築
https publish pull insert
構築には k8sのAPI や
BigQueryのAPI も
使ってますが図からは省略。

10. appengine ja night なので
https publish pull insert
GAE/Goのデプロイに
フォーカスをあてて
お話を進めます。

11. “Deployment Managerによる
GAE/Go運用で ハマったこと
が 2つ ありました

12. “その1
Deployment Manager
serviceを削除できない問題

13. Deployment Manager
serviceを削除できない問題
deploymentの削除時に
GAE上のserviceを削除することができない。
Cannot delete the final version of a service (module).
Please delete the whole service (module) in order to delete this version.
service上の最後のversionを削除しようとするが
versionが存在しないserviceとなってしまうので
version削除が実行できずエラーとなる。

14. Deployment Manager
serviceを削除できない問題
原因: Deployment Managerの仕様
version: 1
service: blocks
apps.modules.versions.create
version: 1
service: blocks
apps.modules.versions.delete
が実行されてしまう。
Create Destroy

15. “serviceを手動で消すか？
（ユーザさんに消していただく）
と思っていたところ…

16. App Engine Admin API
http://googlecloudplatform-japan.blogspot.jp/2016/08/app-engine-admin-api.html

17. App Engine Admin APIって
何ができるの？
GAEに対して柔軟な処理が可能。
● service/versionのcreateおよびdelete
● service/versionのupdate
○ トラフィック割り当ての変更
○ Scaling Policyの変更
○ Instance Typeの変更
○ etc…
詳しくはDocで
https://cloud.google.com/appengine/docs/admin-api

18. apps.services.delete
を実行してserviceと
versionを削除する。
事前にApp Engine Admin APIで殴る
ことでDeployment Managerによる
destroyを実行できる
version: 1
service: blocks
version: 1
service: blocks
apps.modules.versions.delete
が実行されるが既にserviceが
destroy済みなので問題ない。
Destroy: Phase1 Destroy: Phase2
App Engine
Admin API

19. “その1
Deployment Manager
serviceを削除できない問題
解決！！

20. “その2
GCSにライブラリファイルを
ステージングするの
面倒くさい問題

21. GCSにライブラリファイルを
ステージングするの
面倒くさい問題
アプリケーションのリソース？

22. ”アプリケーションのリソース”に
サードパーティのライブラリは
含まれますか？
答: 含まれます。
アプリケーションのソースコードだけでなく
go getコマンド等で取得済みの
サードパーティのライブラリファイル群も
GCSにアップロードしてから
Deployment Manager
(もしくは App Engine Admin API)で
deployする必要があります。

23. ライブラリのファイル群を洗い出すの
面倒では？

24. ライブラリのファイル群を洗い出すの
面倒では？
弊社では
“appcfg.pyの処理を模倣してGAE/Go用の
パッケージングを行うシェルスクリプト”
を利用してGCSへの配置を実現している。
https://github.com/groovenauts/magellan-gcs-uploader/blob/master/makepkg.sh

25. ライブラリファイル群のuploadと
Deployment Managerを用いた
GAE/Goのdeploy
makepkg
.sh
pkg
pkg
App Engine
Admin API
1. makepkg.shを
実行して
ファイル群を
作成する
2. ファイル群を
GCSに
uploadする
3. Deployment Manager
(またはApp Engine Admin API)
を用いてdeployする

26. “その2
GCSにライブラリファイルを
ステージングするの
面倒くさい問題
解決！！

27. 今回の発表における
App Engine Admin API まとめ
● GAEに対する操作を柔軟に実行できる。
● Deployment Managerのみでは
対応できない部分のフォローができる。
○ App Engine Admin API + Deployment Manager
のハイブリッド構成でいいとこ取りが可能。
● GAE/Goのdeployに関しては
ライブラリをGCSに配置するのが面倒。
○ ツールで頑張ればフォローできる。

28. “もう一つのテーマである
例のアレ
の話をさせてください！

29. 祝！！
東京GCPリージョン
(asia-northeast1)
リリース！！
GAEに関しては
asia-east1を
飛び越えてのリリース

30. 東京GCPリージョンの
性能評価

31. 検証内容
1. Client -> GAE
us-centralと
asia-northeast1の
GAEに対して
apache benchを実行し
レスポンス速度を
比較する。
2. GAE -> Datastore
us-centralと
asia-northeast1で
GAEから
Datastoreに対して
put / get 処理を実行し
regionごとの性能を
比較する。
3. GAE -> CloudSQL
us-centralと
asia-northeast1で
GAEから
CloudSQLに対して
日付取得のSQLを実行し
regionごとの性能を
比較する。

32. asia-northeast1
us-central
性能検証1. Client -> GAE
http
(apache bench)
VS
http
(apache bench)

33. 性能検証1. Client -> GAE
検証結果

34. 性能検証1. Client -> GAE
所感
● asia-northeast1の応答速度は
約1.79倍（弊社検証時）
● 福岡からのアクセスでの数値なので
東京からのアクセスだともっと早い？
○ client環境(HW/NW)を完全に同一にすることは
難しいので残念ながら検証を断念。

35. asia-northeast1
us-central
性能検証2. GAE -> Datastore
(10万件put)
put 10万件
VS
put 10万件

36. 性能検証2. GAE -> Datastore
(10万件put)
検証結果

37. asia-northeast1
us-central
性能検証2. GAE -> Datastore
(10万件から1件get x 10000回)
get x 10000回
VS
get x 10000回

38. 性能検証2. GAE -> Datastore
(10万件から1件get x 10000回)
検証結果

39. 性能検証2. GAE -> Datastore
所感
● なんか分からんけどasia-northeast1の方がput
もgetもパフォーマンスが良い。
● Datastoreのパフォーマンスを上げるために
asia-northeast1への移行検討はありかも。
○ 実際のデータ・クエリで検証してね。

40. asia-northeast1
us-central
性能検証3. GAE -> CloudSQL
select now() from dual x 1000回
VS
select now() from dual x 1000回

41. 性能検証3. GAE -> CloudSQL
(各regionのGAE -> us-central1)
検証結果

42. asia-northeast1
us-central
性能検証3. GAE -> CloudSQL
延長戦
select now() from dual x 1000回
VS
select now() from dual x 1000回
asia-east1

43. 性能検証3. GAE -> CloudSQL
(asia-northeast1のGAE -> asia-east1)
検証結果

44. “なんてことをやってたら
asia-northeast1に
CloudSQLがきました。
これで勝つる！

45. asia-northeast1
us-central
性能検証3. GAE -> CloudSQL
再延長戦
select now() from dual x 1000回
VS
select now() from dual x 1000回

46. 性能検証3. GAE -> CloudSQL
asia-northeast1同士での
検証結果

47. asia-northeast1の
CloudSQL
GAEで叩くと何故か遅い
(asia-east1越しに叩くより遅い)

48. 性能検証3. GAE -> CloudSQL
所感
● regionを跨いでCloudSQLのアクセスを
実行すると、ものすっごい性能が落ちる。
● asia-northeast1 での CloudSQL構成は
要検証。

49. 今回の発表における
東京GCPリージョン性能評価まとめ
● 国内からGAEへのHTTPレスポンスが向上。
○ asia-northeast1 利用で2倍近い性能向上も。
● Datastoreのput/get性能向上。
○ asia-northeast1 & Datastore はいいぞ！
● GAE/CloudSQLもバリバリ使いたいなー。
○ asia-northeast1 の検証をもう少し頑張る。
○ 発表当日にCloudSQLリリースとか資料しんどい

50. ご清聴ありがとうございました