スタートアップの環境で Google Cloud のサーバーレス テクノロジーを活用して迅速なイテレーションを実現する方法
Google Cloud Japan Team
※この投稿は米国時間 2022 年 12 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。
スタートアップでは、最小実装製品（MVP）を速やかに開発して、先行ユーザーからのフィードバックを収集し、迅速なサイクルでイテレーションを行う必要があります。機能の開発とイテレーションに十分な時間をかけることができないとリリースが遅れ、製品化までの時間が伸びるという重大な問題になります。
Google Cloud は、バックエンド サービスをフルマネージド サーバーレス プラットフォームで構築、実行するためのさまざまなプロダクトを提供しています。こういったプロダクトを利用することで、バックエンド サービスの実行に必要なインフラストラクチャのプロビジョニングと管理の負担から解放され、時間が削減されます。インフラストラクチャの管理にかかる時間が減ると、その分をサービスの実装とイテレーションに回すことができます。そのうえ、ほとんどのサーバーレス プロダクトには、従量課金制料金モデルが採用されており、初期費用がほとんどかかりません。お客様のサービスとスタートアップの規模に合わせて高くなる料金体系となっているため、必要なときに使用した分のみが課金の対象となります。
ここでは、これらのプロダクトのいくつかを紹介し、迅速なイテレーションに活用する方法を見ていきます。
コードの実行に使用するプロダクト
まず、コードのデプロイと実行に使用するプロダクトを決める必要があります。Google Cloud でコードを実行するには、Cloud Functions が最も簡単な方法です。Cloud Functions を使用すると、サポートされている言語でシンプルな関数を記述し、その関数をトリガーする方法（HTTP またはイベント）を指定するだけで、関数の実行、トリガー、自動スケーリングの一部始終を Cloud Functions が処理してくれます。
Cloud Functions は、アプリ全体ではなく、主に単一目的のユースケースを対象に設計されているため、使用する際には制限事項に留意することが重要です。たとえば、使用できる言語セットが限られていることや、関数は一定時間内に応答する必要があることなどがあります。
Cloud Functions の制限事項が難点となった場合は、より柔軟性の高い Cloud Run の使用を検討してください。Cloud Run サービスを使用する場合は、関数ではなく、サーバーレス HTTP コンテナを実行します。これにより、独自のランタイムを定義できるので、コンテナ内ですべてを実行できさえすれば、任意の言語を使用し、シンプルな関数の代わりにより高度なロジックを実装できます。
リクエストを継続的に処理するサービスではなく、完了まで実行するコードだけが必要な場合は、Cloud Run ジョブの使用を検討してください。Cloud Run ジョブを使用すると、フルマネージド サーバーレス環境で、長時間実行するコンテナを並列実行できます。
Cloud Functions と Cloud Run のどちらを使用しても、関数またはコンテナの作成に集中できます。その実行とスケーリングに必要なインフラストラクチャは、Google Cloud によって自動的に管理されます。これにより、サービスの機能を迅速にイテレーションできるようになります。
サーバーレスでの開発用の Cloud Code
サービスの実行に Cloud Functions と Cloud Run のいずれを使用する場合でも、Cloud Code を利用して、お好きな IDE からサービスを作成し、Google Cloud に迅速にデプロイできます。
Cloud Code には、Cloud Functions アプリケーションまたは Cloud Run アプリケーションを迅速に作成するためのテンプレートが用意されています。
サービスを作成したらデプロイします。デプロイした Cloud Functions サービスや Cloud Run サービスの一覧は、IDE から確認できます。
サービスを連携させる方法
サービスを稼働できたら、シンプルな HTTP 以外でサービスをトリガーする方法を指定する必要があります。時間ベースで実行する場合は、Cloud Scheduler を使用できます。より細かく制御する場合は、HTTP サービスの前面に Cloud Tasks キューを置きます。Cloud Tasks キューには、再試行、レート制限、重複除去といったすぐに使用できる高度な機能が用意されています。
複数のサービスを実行する場合は、サービス間の通信と連携を行う方法を決める必要もあります。次のオプションがあります。
サービス間の直接通信
間接的なイベント ドリブン通信（コレオグラフィとも言う）
オーケストレーターによる通信の一元管理
サービス間の直接通信は簡単に実装できますが、サービスが密結合になるため、このオプションはおすすめしません。
イベント ドリブン通信の場合、Google Cloud の Pub/Sub と Eventarc を使用できます。Pub/Sub は、イベント配信を高度にカスタマイズできるローレベルのサービスで、Eventarc は、サービスを接続するためのセマンティクスが Pub/ Sub より簡単な、よりハイレベルのサービスです。重要なのは、両方ともフルマネージドのグローバル サービスであり、これらを使用すると、基盤となるインフラストラクチャの管理を心配することなく、イベントソースをイベント コンシューマに簡単に接続できるようになる点です。
サービスのオーケストレーションの場合は、Workflows を使用できます。サービスのオーケストレーションの定義で、サービスをどのように、どの順序で呼び出すのかを指定します。Workflows が、出力のキャプチャ（およびエラーの処理）を行いながら、定義された方法でサービスの呼び出しを行います。
これらの連携用サービスはすべてサーバーレスで行われるため、基盤となるインフラストラクチャの管理を心配する必要がなくなり、貴社の提供するサービスにより多くの時間を割けるようになります。
サーバーが必要な場合
サーバーレス プラットフォームの制限事項によって、サーバーが必要になることがあります。たとえば、すべてのサーバーレス プラットフォームには、1 つのワークロードが実行を継続できる時間、ワークロードが使用できる CPU とメモリリソースに上限があります。Cloud Functions や Cloud Run といったサーバーレス サービスでコードを実行できない場合でも、Compute Engine で Batch を使用して、仮想マシン（VM）上でバッチジョブを実行、管理できます。同様に、Workflows とその Compute Engine コネクタを使用して、VM 上でコードを実行し、Workflows で VM のライフサイクルを管理することができます。どちらの場合でも、実際のワークロードはサーバー上で実行されます（これにより高い柔軟性が生まれます）が、それらのサーバーの管理は、Batch や Workflows といったサービスによりサーバーレスで行われます。
まとめ
コードの実行が必要な際は常に、「このコードをサーバーレス プラットフォームで実行できるかどうか」を検討してください。その答えが「できない」の場合でも、そのコードのライフサイクルをサーバーレス プラットフォームで管理できる可能性があります。インフラストラクチャの管理をクラウドに任せれば任せるほど、独自のサービスの開発とイテレーションに費やせる貴重な時間が増えます。
