GAE環境の変化

続きです。

【プレビュー】about GAE.｜Ndot｜note

閉じていたGAE環境の変化

1stでは言語のランタイムを変更するのは不可能でしたがそれ以外の制約は1stでも回避できました。コレアらの制限を回避する手段が用意されていました。例えば代表例にTaskQueueサービスがあります。GAE1ｓｔでは1分以内に利いクエスト処理をしなくてはならないという制限がありますが、TaskQueueサービスを利用すれば非同期に処理を行うことができます。そこで時間のかかる処理はTaskQueueを使って対応していました。ほかにも1stだけで次のようなことができました。
・Datastoreによるバックグラウンドで動くスケーラブルなDB
・Memcacheによる高パフォーマンスなインメモリキャッシュ機能
・cronによるジョブスケーリング
・User ServiceによるGoogleアカウントを使った認証
・Image Serviceによる画像変換

以上のようなサービスを併用することでGAEというWebアプリのプラットフォームをとても使いやすいものにしていました。一方でこれらGAE専用のサービスの存在は他のGCPのサービスと比べてGAEを非常に独立性の高いサービスにしています。ほかのGCPサービスは複数のサービスと連携して利用することが多く、マイクロサービスを実現しやすくしていますが、Webアプリ開発にGAEを選択するとほかのサービスとの連携を必要とせず1stだけで完結することもあります。

一方2ndになると、積極的にGCPサービスと連携するようになりました。
例えばTaskQueueはCloudTasksに置き換わり、cronはCloudSchedularで行うことができます。ほかにもクラウドクライアントライブラリが使えるようになったため、Spannerのように今までGAEからは使えなかったサービスを使えるようになりました。
1stしか使えないサービスが形を変えてGCPの新しいサービスになり、GAE以外でも使えるようになりました。2ndではこれらの新しいサービスを使うことで閉じたGAEの世界からマイクロサービスを意識してほかのGCPと連携したアプリ開発ができるようになりました。

GAEの目指すところ

GAEの目指すところはNoOpsなフルマネージドサービスです。
インフラの管理はGoogleがやってくれます。リクエストの増減を気にすることなく運用できます。セキュリティパッチも常に最新のものを当ててくれます。GoogleCloudSecurityScannerというサービスを使えば、アプリの脆弱性も発見できます。従来のWebアプリ環境ではアクセススパイクの対応やビッグデータの活用には非常に多くのマシンリソースを事前に用意する必要があり、ハードウェア障害の対応なども含めてインフラ管理者の多大なコストを必要としました。また、たくさんのマシンを用意することは事前の購入が必要となり初期費用が高くなります。エンジニアは開発以外の多くのことをしないといけませんでした。
クラウドになった場合、IaaSの世界ではハードウェアの管理は不要になりましたが運用の基本は同じでどうしても人が管理する必要がありました。そのコストをすべてアプリ開発に帰ることができればユーザビリティの高いアプリが開発できます。簡単に始められ、運用コストも抑えられるGAEですが使いこなすためには十分な理解とその思想を知っておく必要があります。

最後に

数回に分けて包括的にGAEのメリットを見てきました。1stから2ndに移る中でGCPのほかサービスとの連携を意識したマイクロサービスとして、よりインフラ環境はもうGoogleに任せてアプリ開発にフォーカスした開発を目指す、といったGoogleの意思表示が見て取れました。きたるNoOpsに向けて先進的に取り組む技術力の高さはさすがの境地です。
次回以降は、開発環境の構築方法についてみていきたいと思います。ではまた。

N