VisasQ Dev Blog

ビザスク開発ブログ

レガシーGAEからの脱却に向けて

技術記事

ビザスクに入社してから半年が経ちました。松下です。

弊社サービスサイト（https://service.visasq.com/）はGoogle App Engineの Python2 スタンダード環境（以後、GAE SE 1st）で動作しています。

中々レガシーな印象ですが、サービスがスタートしてしばらくの間は事業の成長を優先していたため、どうしても技術面にリソースを割けなかったという背景があったようです。（現在は負債解消や技術のための投資に力を入れています！）

PythonにおけるGAEの環境は3種類あり、それぞれ以下の図のような特徴を持っています。

脱Python2のためには脱GAE SE 1stをしなければなりません。

環境の切り替え自体は図のようにapp.yamlの指定を変えて

gcloud app deploy

とするだけです。しかし、そう簡単な話ではありません。

脱SE 1stで使えなくなるサービスと代替手段

SE 1stにバンドルされた各種サービスは利用できなくなります。言い換えると、google.appengineパッケージは軒並み使えなくなります。

ビザスクのサービスサイトでは以下のようなものが利用されています。

Memcache

GAEにバンドルされたキャッシュサービスです。NDBのキャッシュとしても利用されます。

移行先はGoogle CloudのフルマネージドRedisサービスである Memorystore for Redisや、Googleのサービスではありませんが似たようなDBaasのRedis Labsがあります。

基本的にどちらもオープンソースのRedisと同じインターフェースを持ちますが、Memorystore for Redisは永続化をサポートしていなかったり、一部利用できないコマンドがあったりと細かなところでは違いがあります。

既に弊社での導入実績のあったというのもあり、Redis Labsを採用することになりました。

ちなみに最近ではMemorystore for Memcachedもリリースされましたが、まだベータ版でしたので候補からは外れました。

Images(Blobstore)

画像のアップロードにはBlobstoreサービスを利用し、画像の提供にはImagesサービスを利用して任意のサイズのサムネイル画像を表示させることができます。

非常に便利なサービスですがこちらも利用できなくなります。

代替手段としてGoogle Cloud Storage(GCS) を利用することにしました。画像の配信にはサードパーティのコンテンツ配信ネットワーク（CDN）を使用する方法も紹介されていましたが、ユーザのアップロードする画像はプロフィール画像程度なのでアップロード時にサムネイル画像を生成して、GCSから直接提供するというシンプルな構成を採用しました。

NDB

基本的な永続化データの保存にはCloud SQLを利用していますが、Cloud Datastoreを利用している箇所もいくつかあります。

Python2にはDatastoreとのやりとりのためにNDBライブラリ(google.appengine.ext.ndb)が提供されています。このパッケージはSE 1stでしか利用できません。代わりにCloud NDB(google.cloud.ndb)が提供されているので、素直にそちらを利用するようにします。

基本的にimport文を差し替える作業にはなるのですが、当然違いもありますし、NDBよりも更に古い google.appengine.ext.dbも一部のコードには利用されていたため注意が必要でした。

TaskQueue(deferred library)

時間のかかる処理をバックグラウンドで実行させるために、deferredライブラリ(google.appengine.ext.deferred)もアプリケーション内で使っています。これは非同期処理を実現させるTaskQueueというGAEにバンドルされたサービスを使いやすくしたものです。

TaskQueue(pushキュー)の移行先としてCloud Tasksがありますが、Cloud Tasksにははdeferredライブラリが提供されていません。そのためインターフェースは従来のまま、内部実装をCloud Tasksに変えた内製deferredライブラリを作成し、そちらを利用することにしました。

脱SE 1stで使えなくなるapp.yaml構文

login: admin

SE 1stではapp.yamlに以下のように指定すると、urlで示したパターンのアクセスに関して「App Engine アプリ管理者」ロールが付与されたユーザしかアクセスできないように制御できます。

handlers:
- url: /protected-url/.*
  script: admin.app
  login: admin

簡単にGoogle認証がかけられる便利機能ですが、これも利用できなくなります。

検討した結果、Identity-Aware Proxy（IAP）の導入がすることにしました。これにより認証のためのコードをアプリケーション側に追加する必要がなくなります。

脱 SE 1stの先

ビザスクサービスサイトのリポジトリのfirst commitを確認したところ2012年の3月でした。現在に至るまでに多くのプロダクトの変遷があり、事業の成長と共に順調に（？）技術的負債が溜まってきているように感じます。

ビザスクは今年の3月に上場したことですし、負債は返済しなければなりません。

そのための脱SE 1stですが、これはやるべきことの一部です。

  • 脱SE 1st
  • Python3化
  • Djangoアップデート
  • サービス分割

Python3化まではマストですが、現在モノリシックなアプリケーションになってしまっているコードを効果的に分割してお互いの責務をはっきりさせることができれば、より良いサービスが提供できると思っています。

ちなみに今回の脱SE 1stを進めるにあたり、各開発チームから数名集まってタスクフォースチームが結成されました。（自分もその一人です。）やるべきことは無数にありますが、一つ一つのマイルストーンに向けて美味しいビールが飲めるよう頑張っています。

まとめ

脱SE 1stするにあたって使えなくなるものと代替手段についてざっくりと紹介しました。

次回以降の記事では移行するにあたって具体的にどのようなことを行ったのか、タスクフォースの各メンバーにもうすこし掘り下げて紹介してもらおうと思います。お楽しみに！

一緒に働くエンジニアを募集中！

ビザスクに少しでも興味のあるWebエンジニアの方がいたら、ぜひお話を聞かせてください！詳しい募集要項は下記リンクからアクセスしてください。