Google Cloudが推進する、さまざまな「サーバレス」：Google Cloud Next ‘18発表まとめ（1）
Googleのクラウド事業部門Google Cloudが、2018年7月にサンフランシスコで年次カンファレンス「Google Cloud Next ‘18」を開催した。本連載では、同イベントにおける数々の発表を、クラウドエースおよび吉積情報のエンジニアが解説する。第1回として、アプリケーション開発関連の発表をまとめる。
2018年7月24〜26日、Google Cloud Next ’18が米サンフランシスコで開催された。同カンファレンスで頻繁に聞かれたワードの1つは「サーバレス」だった。また、Googleは今回サーバレスにまつわるサービスを複数発表した。本稿では同カンファレンスの前に発表済みのものも含め、アプリケーション開発に関係のある動きを取り上げる。最後にGoogleが考えるサーバレスとは何かを考える。
対応言語が広がるGoogle App Engine
Google App Engine（GAE）は2008年にサービスが開始され、2018年で10周年を迎える。GAEは、開発者がコードをデプロイするだけで、インフラの管理を必要とせず自動でスケールするWebアプリケーションを構築できる、サーバレスWebアプリケーションプラットフォームである。利便性は高いが、開発言語が限られるという欠点があった。
Googleは2018年になって、App Engine standard environmentで利用できる開発言語を増やしてきている。6月にはNode.js 8のサポートを発表。Google Cloud Next ’18ではPython 3.7、PHP 7.2への対応を追加した。
Google Cloud Functionsは4リージョンでの一般提供が開始
Google Cloud Functionsは2017年にβ版として登場し、数行単位のコードからなるワークロードをデプロイできる、いわゆるFaaS（Functions as a Service）である。今回β版から一般提供への移行が発表され、SLAが保証されるようになった。
以前は米国の1リージョンのみ利用可能だったが、一般提供に伴い米国、ヨーロッパ、アジアにそれぞれ1リージョンが追加され、計4つのリージョンでCloud Functionsが利用できるようになった。
さらに、以下の機能拡充が発表された。
サポート言語の追加
Cloud Functionsは、以前はNode.js 6のみのサポートであったが、Node.js 8とPython 3.7のサポートが発表された。ただし現時点ではβのため、SLAは保証されない。
環境変数が使用可能に
Cloud Functionsで環境変数を設定できるようになった。環境変数はコマンドライン、API、Cloud Consoleから設定可能。デプロイ時にキーバリュー型のデータを設定することで、ワークロード実行時に参照できる。ソースコードの変更を必要としないので、柔軟に設定値を変更できるのが特徴。現在β版として提供されている。
Cloud SQLインスタンスへの内部接続
これまでCloud FunctionsからCloud SQLインスタンスへのアクセスは難しく、Cloud SQLインスタンスへの通信経路はGCPネットワークの外側であるインターネットを経由していた。新たなCloud SQL Direct Connectを使うことで、従来よりも簡単にCloud SQLにアクセスできる。また、Cloud SQLインスタンスへの通信経路がGCPネットワークの内側に限定されることにより、セキュアに通信できる。なお、Cloud SQL Direct Connectは、現時点ではβ版の位置付けだ。
スケーリング数のコントロール
Cloud FunctionsからCloud SQLなどのDBへ接続する際には同時接続数の制限がある。「これを超えることなくワークロードをスケーリングさせたい」というユースケースに最適なのが、今回発表されたScaling Controlだ。デプロイ時にスケール上限数を指定することにより、Cloud Functionsがこれを超えないように、一度にスケールするインスタンス数がコントロールされる。
VPC対応とIAMによるセキュリティコントロール
Cloud FunctionsがVPC（Virtual Private Cloud）対応となったことにより、VPC上のCompute Engine仮想マシンインスタンスへのアクセスが可能になった。Google Cloud Identity & Access Management（Cloud IAM）に「roles/cloudfunctions.invoker」という役割が新たに追加され、デプロイ時にこの役割を付与するメンバーを指定することで実行者をそのメンバーに限定することができる。
Serverless Containers on Cloud Functionsが登場
「Serverless Containers」は、Cloud Functionsでコードをデプロイする時と同じコマンドで、Source Repository上のコンテナイメージを指定することにより、コンテナ化されたワークロードをサーバレスで実行できる。Serverless Containersは現在、早期プレビュー段階であり、希望する一部ユーザーのみに提供されている。
Kubernetes Engine serverless add-onという新たな選択肢
コンテナ化されたアプリケーションのオーケストレーションツールとして、Kubernetesはデファクトスタンダードとなっており、これをGCP上で動かすサービスとしてGoogle Kubernetes Engine（GKE）がある。だが、GKE上でアプリケーションを構築する際には、複雑なYAMLファイルを記述する必要があった。今回Google Cloudが発表した「Kubernetes Engine serverless add-on」では、複雑な定義ファイルを書くことなく、ワンステップでサーバレスのワークロードをデプロイできる。通常のGKEで構築されたワークロードと比べて、スケールアウトが速くゼロまでスケールダウンするという。GKE serverless add-onは、現在希望する一部ユーザーのみに提供されている。
Container BuilderはCloud Buildに進化
Container BuilderはCloud Buildに進化した。これは指定したソースコードに対してワークフローを実行するためのサーバレスCI/CD（継続的インテグレーション／継続的デリバリー）基盤。入力ソースにはCloud Source RepositoryやCloud Storageが対応しており、ビルドトリガーという機能を使用することによりソースコードの変更をトリガーとしてワークフローを自動実行するように設定することも可能。ソースコードをクラウド上の共有空間にアップロードし、それに対し「ビルドステップ」と呼ばれるコンテナ化されたCLIツールを使ってビルド・テストなどを行い、最終的にビルドした成果物をApp Engine、Cloud Functions、Kubernetes Engineなどにデプロイしたり、Container RegistryやCloud Storageなどに保存したりできる。git、 Docker、maven、gradleなど一般的なCLIのビルドステップはオープンソースソフトウェア（OSS）として公開されている。
さまざまな「サーバレス」をどう使い分けるか
構築したアプリケーションをGCP上のプラットフォームにデプロイする際、どのプラットフォームを選択すればいいのだろうか。現時点における明確な判断基準の1つは、デプロイするアプリケーションがコンテナ化されているかどうかだ。コンテナ化されたアプリケーションの場合はServerless ContainersかGKE serverless add-onが選択肢になる。そうでない場合はApp EngineかCloud Functionsになる。
App EngineとCloud Functionsの使い分けの基準は、どのイベントを起点にワークロードを実行させるかに依存する。App EngineはHTTPリクエストのみに反応するが、Cloud FunctionsはCloud Pub/SubやCloud Storage、Firebaseのイベントにも対応している。
一般的なWebアプリケーションを構築したい場合はApp Engineが向いている。一方、Cloud Storageにファイルがアップロードされたのを検知してバッチ処理を実行したい場合は、Cloud Functionsで構築した方が簡単な場合が多い。
GKE serverless add-onとServerless Containersの使い分けについては、サービスがまだ一般提供されていないため推測が含まれるが、GKE serverless add-onはGKEのオプションであり、従来のGKEワークロードと組み合わせて使うことが想定される。Serverless Containersはコンテナイメージを使用することで任意の言語を選択できるため、現在Cloud Functionsでサポートしていない言語を使ったワークロードを構築したいといったユースケースが考えられる。
Googleの考えるサーバレスとは
従来のサーバレスの考え方といえば、開発者がコードをデプロイするだけでハードウェアやOSなどのインフラストラクチャを管理することなく、スケールするアプリケーションを構築できるプラットフォームを指す。しかしGoogleはサーバレスの定義に新たに「ロックインからの解放」を加えた。
通常、特定のプラットフォームを選択してアプリケーションを構築する際、開発者はプラットフォーム独特の操作や設定方法を学び、これに則ってアプリケーションを構築することを強いられてきた。そうして構築したアプリケーションは、そのプラットフォーム上でのみ動作することが多く、他のプラットフォームに移行することは難しくなる。このことは、企業が自社のサービスをクラウドへ移行させる際の障害となっている。
Googleはこれを改善するため、Kubernetesに代表されるOSSを多数公開している。Googleが長年培ってきたコンテナ技術をOSSとして公開し、他クラウド事業者がこれを導入したプラットフォームを提供することで、構築したアプリケーションを他のプラットフォームに移行したり、複数のプラットフォームで展開したりすることが容易になる。
また、開発者にとっては、複数プラットフォームに共通のOSSを使用することにより、プラットフォーム独自の仕様を学習するコストが減らせるというメリットがある。これは企業のクラウド導入促進、そして自社のクラウドのみならずクラウド市場全体の成長を狙った施策とも解釈できる。
Copyright © ITmedia, Inc. All Rights Reserved.