Google Cloud には、Amazon Web Services（AWS）Lambda から Google Cloud へのサーバーレス ワークロードの移行を支援するツール、プロダクト、ガイダンス、プロフェッショナル サービスが用意されています。Google Cloud には、サーバーレス アプリケーションを開発してデプロイできるサービスがいくつかありますが、このドキュメントでは、サーバーレス ランタイム環境である Cloud Run への移行に焦点を当てます。AWS Lambda と Cloud Run は、リソースの自動プロビジョニング、クラウド プロバイダによるスケーリング、従量課金制の料金モデルなど、類似点があります。
このドキュメントは、サーバーレス ワークロードを AWS Lambda から Cloud Run に移行する計画を設計、実装、検証する際に役立ちます。また、このような移行の潜在的なメリットとプロセスを評価するユーザー向けのガイダンスも提供します。
このドキュメントは、AWS から Google Cloud への移行に関する複数のパートからなるシリーズの一部です。このシリーズには、次のドキュメントが含まれています。
- 始めましょう
- Amazon EC2 から Compute Engine への移行
- Amazon S3 から Cloud Storage への移行
- Amazon EKS から Google Kubernetes Engine への移行
- Amazon RDS for MySQL および Amazon Aurora for MySQL から Cloud SQL for MySQL への移行
- Amazon RDS for PostgreSQL と Amazon Aurora for PostgreSQL から Cloud SQL for PostgreSQL と AlloyDB for PostgreSQL への移行
- Amazon RDS for SQL Server から Cloud SQL for SQL Server への移行
- AWS Lambda から Cloud Run への移行（本ドキュメント）
ビジネス ロジックに適したサーバーレス ランタイム環境を選択する方法については、マネージド コンテナ ランタイム環境を選択するをご覧ください。AWS サービスと Google Cloud サービスの包括的なマッピングについては、AWS サービスや Azure サービスと Google Cloud サービスを比較するをご覧ください。
Google Cloud に移行する場合は、Google Cloud への移行: スタートガイドで説明する移行フレームワークに従うことをおすすめします。
次の図は、移行の過程を示しています。
移行元の環境から Google Cloud には、一連のイテレーションで移行できます。たとえば、最初に一部のワークロードを移行した後、残りのワークロードを移行できます。個別の移行イテレーションごとに、以下の一般的な移行フレームワークのフェーズに従います。
- ワークロードとデータを評価して検出します。
- Google Cloud で基盤を計画し、構築します。
- ワークロードとデータを Google Cloud に移行します。
- Google Cloud 環境を最適化します。
このフレームワークのフェーズの詳細については、Google Cloud への移行: スタートガイドをご覧ください。
効果的な移行計画を設計するには、計画の各ステップを検証し、ロールバック戦略を常に持っていることをおすすめします。移行計画の検証については、Google Cloud への移行: 移行計画の検証に関するベスト プラクティスをご覧ください。
サーバーレス ワークロードの移行は、多くの場合、関数をクラウド プロバイダ間で移動するだけではありません。クラウドベースのアプリケーションは相互接続されたサービス ネットワークに依存しているため、AWS から Google Cloud に移行する際に、依存する AWS サービスを Google Cloud サービスに置き換える必要がある場合があります。たとえば、Lambda 関数が Amazon SQS と Amazon SNS とやり取りするシナリオについて考えてみましょう。この関数を移行するには、Pub/Sub と Cloud Tasks を採用して同様の機能を実現する必要があります。
移行は、サーバーレス アプリケーションのアーキテクチャと設計に関する決定を徹底的に検討する貴重な機会でもあります。この確認により、次のような改善の機会を見つけることができます。
- Google Cloud の組み込み機能で最適化する: Google Cloud サービスが独自のメリットを提供しているか、アプリケーションの要件に適しているかどうかを検討します。
- アーキテクチャを簡素化する: 機能を統合するか、Google Cloud 内でサービスを別々に使用することで、合理化できるかどうかを評価します。
- 費用対効果を改善する: Google Cloud で提供されるインフラストラクチャでリファクタリングされたアプリケーションを実行した場合の費用の差異を評価します。
- コードの効率を高める: 移行プロセスとともにコードをリファクタリングします。
移行を戦略的に計画します。移行を再ホスト（リフト＆シフト）演習と見なさないでください。移行をサーバーレス アプリケーションの全体的な設計とコード品質を向上させる機会として活用します。
移行元の環境を評価する
評価フェーズでは、移行元の環境を Google Cloud に移行するための要件と依存関係を確認します。
移行を成功させるには、評価フェーズが非常に重要です。このフェーズで、移行するワークロードとその要件、依存関係、および現在の環境について詳しく把握する必要があります。また、Google Cloud への移行を計画して実施するための出発点も理解する必要があります。
評価フェーズは、次のタスクで構成されます。
- ワークロードの包括的なインベントリを作成する。
- プロパティと依存関係に応じてワークロードを分類する。
- チームを Google Cloud でトレーニングして教育する。
- Google Cloud 上でテストと概念実証を構築する。
- ターゲット環境の総所有コスト（TCO）を計算する。
- ワークロードの移行戦略を選択する。
- 移行ツールを選択する。
- 移行計画とタイムラインを定義する。
- 移行計画を検証する。
評価フェーズとこれらのタスクの詳細については、Google Cloud への移行: ワークロードの評価と検出をご覧ください。以下のセクションは、このドキュメントの情報に基づいています。
AWS Lambda ワークロードのインベントリを作成する
移行の範囲を定義するには、インベントリを作成し、AWS Lambda ワークロードに関する情報を収集します。
AWS Lambda ワークロードのインベントリを構築するには、AWS API、AWS デベロッパー ツール、AWS コマンドライン インターフェースに基づくデータ収集メカニズムを実装することをおすすめします。
インベントリを構築したら、インベントリ内の各 AWS Lambda ワークロードに関する情報を収集することをおすすめします。ワークロードごとに、潜在的な摩擦を予測するのに役立つ側面に焦点を当てます。また、そのワークロードを分析して、Cloud Run に移行する前にワークロードとその依存関係を変更する必要があるかどうかを把握します。まず、各 AWS Lambda ワークロードの次の側面に関するデータを収集することをおすすめします。
- ユースケースと設計
- ソースコード リポジトリ
- デプロイ アーティファクト
- 呼び出し、トリガー、出力
- ランタイムと実行環境
- ワークロードの構成
- アクセス制御と権限
- コンプライアンスと規制の要件
- デプロイ プロセスと運用プロセス
ユースケースと設計
ワークロードのユースケースと設計に関する情報を収集すると、適切な移行戦略を特定できます。この情報は、移行前にワークロードとその依存関係を変更する必要があるかどうかを把握するのにも役立ちます。ワークロードごとに、次のことをおすすめします。
- ワークロードが提供する特定のユースケースに関する分析情報を取得し、他のシステム、リソース、プロセスとの依存関係を特定します。
- ワークロードの設計とアーキテクチャを分析します。
- ワークロードのレイテンシ要件を評価します。
ソースコード リポジトリ
AWS Lambda 関数のソースコードをインベントリに登録すると、Cloud Run との互換性を確保するために AWS Lambda ワークロードをリファクタリングする必要がある場合に役立ちます。このインベントリの作成には、コードベースの追跡が含まれます。コードベースは通常、Git などのバージョン管理システム、または GitHub や GitLab などの開発プラットフォームに保存されます。ソースコードのインベントリは、継続的インテグレーションや継続的開発（CI/CD）パイプラインなどの DevOps プロセスに不可欠です。これらのプロセスは、Cloud Run に移行するときに更新する必要もあります。
デプロイ アーティファクト
ワークロードに必要なデプロイ アーティファクトを把握することは、AWS Lambda ワークロードをリファクタリングする必要があるかどうかを判断するうえで役立つもう 1 つのコンポーネントです。ワークロードに必要なデプロイ アーティファクトを特定するには、次の情報を収集します。
- ワークロードをデプロイするデプロイ パッケージのタイプ。
- ライブラリやその他の依存関係など、追加のコードを含む AWS Lambda レイヤ。
- ワークロードが依存する AWS Lambda 拡張機能。
- バージョンとエイリアスを指定するために構成した修飾子。
- デプロイされたワークロードのバージョン。
呼び出し、トリガー、出力
AWS Lambda は、トリガーなどの複数の呼び出しメカニズムと、同期呼び出しや非同期呼び出しなどのさまざまな呼び出しモデルをサポートしています。AWS Lambda ワークロードごとに、トリガーと呼び出しに関連する次の情報を収集することをおすすめします。
- ワークロードを呼び出すトリガーとイベントソースのマッピング。
- ワークロードが同期呼び出しと非同期呼び出しの両方をサポートしているかどうか。
- ワークロードの URL と HTTP(S) エンドポイント。
AWS Lambda ワークロードは、他のリソースやシステムとやり取りできます。AWS Lambda ワークロードの出力を消費するリソースと、それらのリソースがどのように出力を消費するかを把握する必要があります。この知識は、他のシステムやワークロードなど、これらの出力に依存する可能性のあるものを変更する必要があるかどうかを判断するのに役立ちます。AWS Lambda ワークロードごとに、他のリソースとシステムに関する次の情報を収集することをおすすめします。
- ワークロードがイベントを送信する可能性がある宛先リソース。
- 非同期呼び出しの情報レコードを受信する宛先。
- ワークロードが処理するイベントの形式。
- AWS Lambda ワークロードとその拡張機能が AWS Lambda API や他の AWS API とどのようにやり取りするか。
機能するために、AWS Lambda ワークロードは永続データを保存し、他の AWS サービスとやり取りする場合があります。AWS Lambda ワークロードごとに、データやその他のサービスに関する次の情報を収集することをおすすめします。
- ワークロードが Virtual Private Cloud（VPC）または他のプライベート ネットワークにアクセスするかどうか。
- ワークロードが永続データを保存する方法（エフェメラル データ ストレージや Amazon Elastic File System（EFS）の使用など）。
ランタイム環境と実行環境
AWS Lambda は、ワークロード用の複数の実行環境をサポートしています。AWS Lambda 実行環境を Cloud Run 実行環境に正しくマッピングするには、AWS Lambda ワークロードごとに次の点を評価することをおすすめします。
- ワークロードの実行環境。
- ワークロードが実行されるコンピュータ プロセッサの命令セット アーキテクチャ。
AWS Lambda ワークロードが言語固有のランタイム環境で実行されている場合は、AWS Lambda ワークロードごとに次の点を考慮してください。
- 言語固有のランタイム環境のタイプ、バージョン、一意の識別子。
- ランタイム環境に適用した変更。
ワークロードの構成
AWS Lambda から Cloud Run に移行するときにワークロードを構成するには、各 AWS Lambda ワークロードの構成方法を評価することをおすすめします。
AWS Lambda ワークロードごとに、次の同時実行とスケーラビリティの設定に関する情報を収集します。
- 同時実行制御。
- スケーラビリティ設定。
- 使用可能なメモリ量と許可される最大実行時間に関するワークロードのインスタンスの構成。
- ワークロードが AWS Lambda SnapStart、予約済み同時実行、プロビジョニングされた同時実行を使用してレイテンシを短縮しているかどうか。
- 構成した環境変数、AWS Lambda が構成する環境変数、ワークロードが依存する環境変数。
- タグと属性ベースのアクセス制御。
- 例外的な状況を処理するステートマシン。
- コンテナ イメージを使用するデプロイ パッケージのベースイメージと構成ファイル（Dockerfile など）。
アクセス制御と権限
評価の一環として、AWS Lambda ワークロードのセキュリティ要件と、アクセス制御と管理の観点からその構成を評価することをおすすめします。この情報は、Google Cloud 環境に同様のコントロールを実装する必要がある場合に重要です。ワークロードごとに、次の点を考慮してください。
- 実行ロールと権限。
- ワークロードとそのレイヤが他のリソースにアクセスするために使用する Identity and Access Management 構成。
- 他のアカウントとサービスがワークロードへのアクセスに使用する Identity and Access Management 構成。
- ガバナンス コントロール。
コンプライアンスと規制の要件
AWS Lambda ワークロードごとに、次の手順でコンプライアンスと規制要件を理解していることを確認します。
- ワークロードが満たす必要があるコンプライアンスと規制要件を評価します。
- ワークロードが現在これらの要件を満たしているかどうかを判断します。
- 今後満たす必要のある要件があるかどうかを判断します。
コンプライアンスと規制要件は、使用しているクラウド プロバイダとは独立している場合があり、これらの要件は移行にも影響する可能性があります。たとえば、データとネットワーク トラフィックが特定の地域（欧州連合（EU）など）の境界内に留まるようにする必要があります。
デプロイと運用のプロセスを評価する
デプロイ プロセスと運用プロセスの仕組みを明確に理解することが重要です。これらのプロセスは、本番環境とそこで実行されるワークロードを準備して維持するプラクティスの基本となる部分です。
デプロイ プロセスと運用プロセスで、ワークロードが機能するために必要なアーティファクトをビルドする場合があります。したがって、各アーティファクト タイプに関する情報を収集する必要があります。たとえば、アーティファクトには、オペレーティング システム パッケージ、アプリケーションのデプロイ パッケージ、オペレーティング システム イメージ、コンテナ イメージなどがあります。
アーティファクト タイプに加えて、次のタスクの実施方法を検討してください。
- ワークロードを開発する。ワークロードを構築するために開発チームが実施しているプロセスを評価します。たとえば、開発チームはワークロードの設計、コーディング、テストをどのように行っているのか評価します。
- 移行元の環境にデプロイするアーティファクトを生成する。移行元の環境にワークロードをデプロイするには、コンテナ イメージやオペレーティング システム イメージなどのデプロイ可能なアーティファクトを生成するか、ソフトウェアをインストールして構成することで、サードパーティのオペレーティング システム イメージなどの既存のアーティファクトをカスタマイズします。これらのアーティファクトの生成方法に関する情報を収集すると、生成されたアーティファクトが Google Cloud へのデプロイに適していることを確認できます。
アーティファクトを保存する。移行元環境のアーティファクト レジストリに保存するアーティファクトを生成する場合は、Google Cloud 環境でアーティファクトを利用可能にする必要があります。これは、次のような方法で実行できます。
- 環境間の通信チャネルを確立する: 移行元の環境のアーティファクトが移行先の Google Cloud 環境からアクセスできるようにします。
- アーティファクトのビルドプロセスのリファクタリング: 移行元の環境と移行先の環境の両方にアーティファクトを保存できるように、移行元の環境のマイナー リファクタリングを完了します。このアプローチでは、ターゲットの Google Cloud 環境にアーティファクトのビルドプロセスを実装する前に、アーティファクト リポジトリなどのインフラストラクチャを構築することで、移行をサポートします。このアプローチは直接実装することも、最初に通信チャネルを確立する以前のアプローチをベースにして実装することもできます。
移行元環境と移行先環境の両方でアーティファクトを使用できるため、移行の一部としてターゲットの Google Cloud 環境にアーティファクト ビルド プロセスを実装する必要はありません。
コードをスキャンして署名する。アーティファクトのビルドプロセスの一環として、コードスキャンを使用して一般的な脆弱性や意図しないネットワーク公開を防ぐことができます。また、コード署名を使用して、環境で実行されるコードが信頼できるものであることを確認できます。
ソース環境にアーティファクトをデプロイする。デプロイ可能なアーティファクトを生成した後、それらを移行元の環境にデプロイしていることがあります。各デプロイ プロセスを評価することをおすすめします。この評価により、デプロイ プロセスに Google Cloud との互換性があるかどうかを確認できます。また、最終的にプロセスをリファクタリングするために必要な作業についても把握できます。たとえば、デプロイ プロセスが移行元の環境で機能する場合は、Google Cloud 環境をターゲットとするようにリファクタリングが必要になることがあります。
ランタイム構成を挿入する。特定のクラスタ、ランタイム環境、ワークロード デプロイのランタイム構成を挿入していることがあります。この構成では、環境変数と、シークレット、認証情報、キーなどの構成値が初期化される場合があります。ランタイム構成の挿入プロセスが Google Cloud で機能するように、移行元の環境で実行されるワークロードの構成を評価することをおすすめします。
ロギング、モニタリング、プロファイリング。移行元環境の健全性、関心のある指標、これらのプロセスによって提供されるデータの使用方法をモニタリングするために、実装されているロギング、モニタリング、プロファイリングのプロセスを評価します。
認証。移行元の環境に対して認証を行う方法を評価します。
リソースのプロビジョニングと構成。移行元の環境を準備するために、リソースをプロビジョニングして構成するプロセスを設計して実装している場合があります。たとえば、Terraform を構成管理ツールとともに使用して、ソース環境でリソースをプロビジョニングして構成している場合があります。
評価を完了する
AWS Lambda 環境からインベントリを構築したら、Google Cloud への移行: ワークロードの評価と検出で説明されている評価フェーズの残りの作業を実施します。
基盤の計画と構築
計画と構築フェーズでは、インフラストラクチャをプロビジョニングして構成し、以下のことを行います。
- Google Cloud 環境でワークロードをサポートします。
- 移行元の環境と Google Cloud 環境を接続して、移行を完了します。
計画と構築のフェーズは、次のタスクで構成されます。
- リソース階層を構築する。
- Google Cloud の Identity and Access Management（IAM）を構成する。
- お支払いとご請求の設定をします。
- ネットワーク接続を設定する。
- セキュリティを強化する。
- ロギング、モニタリング、アラートを設定する。
これらの各タスクの詳細については、Google Cloud への移行: 基盤の計画と構築をご覧ください。
AWS Lambda ワークロードを移行する
AWS Lambda から Cloud Run にワークロードを移行する手順は次のとおりです。
- Cloud Run 環境を設計、プロビジョニング、構成する。
- 必要に応じて、AWS Lambda ワークロードをリファクタリングして Cloud Run と互換性を持たせます。
- デプロイ プロセスと運用プロセスをリファクタリングして、Cloud Run にワークロードをデプロイし、モニタリングします。
- AWS Lambda ワークロードに必要なデータを移行します。
- 機能、パフォーマンス、費用の観点から移行結果を検証します。
移行中の問題を回避し、移行に必要な労力を見積もるために、AWS Lambda の機能と類似した Cloud Run の機能の比較を評価することをおすすめします。AWS Lambda と Cloud Run の機能は、比較すると似ているように見えることがあります。ただし、2 つのクラウド プロバイダで機能の設計と実装が異なると、AWS Lambda から Cloud Run への移行に大きな影響を与える可能性があります。これらの違いは、次のセクションで説明するように、設計とリファクタリングの両方の決定に影響する可能性があります。
Cloud Run 環境を設計、プロビジョニング、構成する
移行フェーズの最初のステップは、AWS Lambda から移行するワークロードをサポートできるように Cloud Run 環境を設計することです。
Cloud Run 環境を正しく設計するには、評価フェーズで収集した各 AWS Lambda ワークロードに関するデータを使用します。このデータは、次のような場合に役立ちます。
- ワークロードをデプロイする適切な Cloud Run リソースを選択します。
- Cloud Run リソースの構成を設計する。
- Cloud Run リソースをプロビジョニングして構成します。
適切な Cloud Run リソースを選択する
移行する AWS Lambda ワークロードごとに、適切な Cloud Run リソースを選択してワークロードをデプロイします。Cloud Run は、次の主なリソースをサポートしています。
- Cloud Run サービス: コンテナ化されたランタイム環境をホストし、一意のエンドポイントを公開し、需要に応じて基盤となるインフラストラクチャを自動的にスケーリングするリソース。
- Cloud Run ジョブ: 1 つ以上のコンテナを完了まで実行するリソース。
次の表に、AWS Lambda リソースがこれらの主要な Cloud Run リソースにどのようにマッピングされるかを示します。
| AWS Lambda リソース | Cloud Run リソース |
|---|---|
| ウェブサイトやウェブ アプリケーション、API やマイクロサービス、ストリーミング データ処理、イベントドリブン アーキテクチャで使用されるイベントによってトリガーされる AWS Lambda 関数。 | トリガーで呼び出せる Cloud Run サービス。 |
| バックグラウンド タスクやバッチジョブなど、実行がスケジュールされた AWS Lambda 関数。 | 完了まで実行される Cloud Run ジョブ。 |
Cloud Run には、サービスとジョブ以外に、これらのメインリソースを拡張する追加リソースも用意されています。使用可能なすべての Cloud Run リソースの詳細については、Cloud Run リソースモデルをご覧ください。
Cloud Run リソースの構成を設計する
Cloud Run リソースをプロビジョニングして構成する前に、その構成を設計します。リソースの上限やリクエストのタイムアウトなど、特定の AWS Lambda 構成オプションは、同様の Cloud Run 構成オプションに匹敵します。以降のセクションでは、サービス トリガーとジョブの実行、リソース構成、セキュリティに使用できる Cloud Run の構成オプションについて説明します。また、これらのセクションでは、Cloud Run の構成オプションと同等の AWS Lambda 構成オプションについても説明します。
Cloud Run サービス トリガーとジョブの実行
AWS Lambda ワークロードを移行する際に考慮する必要がある主な設計上の決定事項は、サービス トリガーとジョブの実行です。Cloud Run には、AWS Lambda で使用されるイベントベースのワークロードをトリガーして実行するためのさまざまなオプションが用意されています。さらに、Cloud Run には、ストリーミング ワークロードとスケジュール設定されたジョブに使用できるオプションが用意されています。
ワークロードを移行する場合は、まず Cloud Run で使用可能なトリガーとメカニズムを理解することが役に立ちます。この情報は、Cloud Run の仕組みを理解するのに役立ちます。次に、この理解に基づいて、AWS Lambda の機能と比較できる Cloud Run の機能と、これらのワークロードのリファクタリングに使用できる Cloud Run の機能を決定できます。
Cloud Run が提供するサービス トリガーの詳細については、次のリソースをご覧ください。
- HTTPS 呼び出し: HTTPS リクエストを送信して Cloud Run サービスをトリガーします。
- HTTP/2 呼び出し: HTTP/2 リクエストを送信して Cloud Run サービスをトリガーします。
- WebSockets: クライアントを Cloud Run で実行されている WebSockets サーバーに接続します。
- gRPC 接続: gRPC を使用して Cloud Run サービスに接続します。
- 非同期呼び出し: Cloud Tasks を使用してタスクをキューに追加し、Cloud Run サービスによって非同期に処理されるようにします。
- スケジュールされた呼び出し: Cloud Scheduler を使用して、スケジュールに従って Cloud Run サービスを呼び出します。
- イベントベースの呼び出し: CloudEvents 形式の特定のイベントで Cloud Run サービスを呼び出す Eventarc トリガーを作成します。
- Pub/Sub との統合: Pub/Sub push サブスクリプションから Cloud Run サービスを呼び出します。
- Workflows との統合: ワークフローから Cloud Run サービスを呼び出します。
Cloud Run が提供するジョブ実行メカニズムの詳細については、次のリソースをご覧ください。
- オンデマンド実行: 完了まで実行されるジョブ実行を作成します。
- スケジュールに従った実行: スケジュールに従って Cloud Run ジョブを実行します。
- Workflows との統合: ワークフローから Cloud Run ジョブを実行します。
AWS Lambda の呼び出しメカニズムに匹敵する Cloud Run の呼び出しまたは実行メカニズムを確認するには、次の表をご覧ください。プロビジョニングする Cloud Run リソースごとに、適切な呼び出しまたは実行メカニズムを選択してください。
| AWS Lambda 機能 | Cloud Run 機能 |
|---|---|
| HTTPS トリガー（関数 URL） | HTTPS 呼び出し |
| HTTP/2 トリガー（外部 API ゲートウェイを使用した部分的なサポート） | HTTP/2 呼び出し（ネイティブでサポート） |
| WebSocket（外部 API ゲートウェイを使用） | WebSocket（ネイティブでサポート） |
| なし（gRPC 接続はサポートされていません） | gRPC 接続 |
| 非同期呼び出し | Cloud Tasks との統合 |
| スケジュール設定された呼び出し | Cloud Scheduler との統合 |
| 独自のイベント形式のイベントベースのトリガー | CloudEvents 形式のイベントベースの呼び出し |
| Amazon SQS と Amazon SNS の統合 | Pub/Sub との統合 |
| AWS Lambda Step Functions | ワークフローの統合 |
Cloud Run リソースの構成
移行したワークロードのトリガーと実行のために行った設計上の決定を補足するため、Cloud Run は、ランタイム環境のさまざまな要素を微調整できるいくつかの構成オプションをサポートしています。これらの構成オプションは、リソース サービスとジョブで構成されます。
前述のように、Cloud Run で使用可能なすべての構成オプションを理解すると、Cloud Run の仕組みをより深く理解できます。この理解は、AWS Lambda の機能を類似の Cloud Run 機能と比較し、ワークロードをリファクタリングする方法を決定する際に役立ちます。
Cloud Run サービスが提供する構成の詳細については、次のリソースをご覧ください。
- 容量: メモリ上限、CPU 上限、CPU 割り当て、リクエスト タイムアウト、インスタンスあたりの最大同時リクエスト数、最小インスタンス数、最大インスタンス数、GPU 構成
- 環境:コンテナポートとエントリポイント、環境変数、Cloud Storage ボリュームのマウント、インメモリ ボリュームのマウント、実行環境、コンテナ ヘルスチェック、シークレット、サービス アカウント
- 自動スケーリング
- 例外的な状況の処理: Pub/Sub の障害処理、Eventarc の障害処理
- メタデータ: 説明、ラベル、タグ
- トラフィック サービング: カスタム ドメインのマッピング、自動割り当て URL、Cloud CDN との統合、セッション アフィニティ
Cloud Run が提供するジョブの詳細については、次のリソースをご覧ください。
- 容量: メモリ上限、CPU 上限、並列処理、タスクのタイムアウト
- 環境: コンテナ エントリポイント、環境変数、Cloud Storage ボリュームのマウント、インメモリ ボリュームのマウント、シークレット、サービス アカウント
- 例外的な状況の処理:最大再試行回数
- メタデータ: ラベルとタグ
AWS Lambda の構成オプションと比較できる Cloud Run の構成オプションについては、次の表をご覧ください。プロビジョニングする必要がある Cloud Run リソースごとに、適切な構成オプションを選択してください。
| AWS Lambda の機能 | Cloud Run 機能 |
|---|---|
| プロビジョニングされた同時実行 | 最小インスタンス数 |
| インスタンスあたりの予約済み同時実行数 （同時実行プールは、AWS アカウント内の AWS Lambda 関数間で共有されます）。 |
サービスあたりの最大インスタンス数 |
| なし（サポート対象外、1 つのリクエストが 1 つのインスタンスにマッピングされます） | インスタンスあたりの同時リクエスト数 |
| なし（メモリ割り当てに依存） | CPU の割り当て |
| スケーラビリティ設定 | サービスのインスタンスの自動スケーリング ジョブの並列処理 |
| インスタンスの構成（CPU、メモリ） | CPU とメモリの上限 |
| 最大実行時間 | サービスのリクエスト タイムアウト ジョブのタスク タイムアウト |
| AWS Lambda SnapStart | 起動時の CPU ブースト |
| 環境変数 | 環境変数 |
| エフェメラル データ ストレージ | インメモリ ボリュームのマウント |
| Amazon Elastic File System 接続 | NFS ボリュームのマウント |
| S3 ボリュームのマウントはサポートされていません | Cloud Storage ボリュームのマウント |
| AWS Lambda ワークロードの AWS Secrets Manager | Secret |
| ワークロードの URL と HTTP(S) エンドポイント | 自動割り当て URL Google Cloud プロダクトとの Cloud Run の統合 |
| スティッキー セッション（外部ロードバランサを使用） | セッション アフィニティ |
| 有望なお客様 | 変更内容 |
上記の表に記載されている機能に加えて、AWS Lambda と Cloud Run が実行環境のインスタンスをプロビジョニングする方法の違いも考慮する必要があります。AWS Lambda は、同時実行リクエストごとに 1 つのインスタンスをプロビジョニングします。ただし、Cloud Run では、インスタンスが処理できる同時リクエスト数を設定できます。つまり、AWS Lambda のプロビジョニング動作は、Cloud Run でインスタンスあたりの最大同時リクエスト数を 1 に設定するのと同じです。同時リクエストの最大数を 1 より大きく設定すると、インスタンスの CPU とメモリが同時実行リクエストで共有されるため、料金は 1 回しか発生しません。これにより、費用を大幅に削減できます。ほとんどの HTTP フレームワークは、リクエストを並行して処理するように設計されています。
Cloud Run のセキュリティとアクセス制御
Cloud Run リソースを設計する際は、移行したワークロードに必要なセキュリティとアクセス制御も決定する必要があります。Cloud Run は、環境の保護や Cloud Run ワークロードのロールの設定と権限の設定に役立ついくつかの構成オプションをサポートしています。
このセクションでは、Cloud Run で使用可能なセキュリティとアクセス制御について説明します。この情報は、移行されたワークロードが Cloud Run でどのように機能するかを理解し、ワークロードをリファクタリングする際に必要となる Cloud Run オプションを特定するのに役立ちます。
Cloud Run が提供する認証メカニズムの詳細については、次のリソースをご覧ください。
Cloud Run が提供するセキュリティ機能の詳細については、次のリソースをご覧ください。
- Identity and Access Management（IAM）を使用したアクセス制御
- サービスごとの ID
- Google Cloud Armor との統合
- Binary Authorization
- 顧客管理の暗号鍵
- ソフトウェア サプライ チェーンのセキュリティ
- 上り（内向き）制限の設定
- VPC Service Controls
AWS Lambda で使用できるセキュリティとアクセス制御と比較して、どの Cloud Run セキュリティとアクセス制御が同等であるかを把握するには、次の表をご覧ください。プロビジョニングする必要がある Cloud Run リソースごとに、適切なアクセス制御とセキュリティ機能を選択してください。
| AWS Lambda の機能 | Cloud Run 機能 |
|---|---|
| AWS Identity Access and Management によるアクセス制御 | Google Cloud の IAM によるアクセス制御 |
| 実行ロール | Google Cloud の IAM ロール |
| 権限の境界 | Google Cloud の IAM 権限とカスタム オーディエンス |
| ガバナンス コントロール | 組織ポリシー サービス |
| コード署名 | バイナリ承認 |
| VPC への完全アクセス | きめ細かい VPC 下り（外向き）アクセス制御 |
Cloud Run リソースをプロビジョニングして構成する
ワークロードをデプロイする Cloud Run リソースを選択したら、それらのリソースをプロビジョニングして構成します。Cloud Run リソースのプロビジョニングの詳細については、以下をご覧ください。
AWS Lambda ワークロードをリファクタリングする
AWS Lambda ワークロードを Cloud Run に移行するには、リファクタリングが必要になる場合があります。たとえば、イベントベースのワークロードが Amazon CloudWatch イベントを含むトリガーを受け入れる場合、CloudEvents 形式のイベントを受け入れるようにワークロードをリファクタリングする必要があります。
各 AWS Lambda ワークロードに必要なリファクタリングの量には、次のような要因が影響する可能性があります。
- アーキテクチャ。アーキテクチャの観点からワークロードがどのように設計されているかを確認します。たとえば、ビジネス ロジックと AWS 固有の API にアクセスするロジックを明確に分離している AWS Lambda ワークロードでは、2 つのロジックが混在しているワークロードと比較して、リファクタリングの必要性が低くなる可能性があります。
- べき等性。ワークロードが入力に関してべき等であるかどうかを検討します。入力に対してべき等であるワークロードは、すでに処理した入力に関する状態を維持する必要があるワークロードと比較して、リファクタリングの必要性が低くなる場合があります。
- 状態。ワークロードがステートレスかどうかを検討します。ステートレス ワークロードでは、状態を維持するワークロードと比べて、リファクタリングが不要な場合があります。Cloud Run がデータの保存にサポートするサービスの詳細については、Cloud Run のストレージ オプションをご覧ください。
- ランタイム環境。ワークロードがランタイム環境について前提としているかどうかを検討します。このようなワークロードの場合、Cloud Run ランタイム環境で同じ前提条件を満たす必要があるか、Cloud Run ランタイム環境で同じ前提条件を満たせない場合はワークロードをリファクタリングする必要があります。たとえば、ワークロードで特定のパッケージまたはライブラリを使用できるようにするには、そのワークロードをホストする Cloud Run ランタイム環境にインストールする必要があります。
- 構成の挿入。ワークロードが環境変数とシークレットを使用して構成を挿入（設定）できるかどうかを検討します。このタイプの挿入をサポートするワークロードでは、他の構成挿入メカニズムをサポートするワークロードと比較して、リファクタリングの必要性が低くなる場合があります。
- API。ワークロードが AWS Lambda API とやり取りするかどうかを検討します。これらの API を操作するワークロードは、Cloud APIs と Cloud Run API を使用するようにリファクタリングする必要があります。
- エラーの報告。ワークロードが標準出力とエラー ストリームを使用してエラーを報告しているかどうかを検討します。このようなエラー レポートを行うワークロードでは、他のメカニズムを使用してエラーを報告するワークロードと比較して、リファクタリングの必要性が低くなる場合があります。
Cloud Run ワークロードの開発と最適化の詳細については、次のリソースをご覧ください。
- 全般的な開発のヒント
- Cloud Run 向けに Java アプリケーションを最適化する
- Cloud Run 用に Python アプリケーションを最適化する
- 負荷テストのベスト プラクティス
- ジョブの再試行とチェックポイントに関するベスト プラクティス
- Nginx を使用したフロントエンド プロキシ
- Cloud CDN と Cloud Run を使用して静的アセットを提供する
- Cloud Run ゾーン冗長性について
デプロイ プロセスと運用プロセスのリファクタリング
ワークロードをリファクタリングしたら、デプロイ プロセスと運用プロセスをリファクタリングして、次のことを行います。
- 移行元の環境でリソースをプロビジョニングするのではなく、Google Cloud 環境でリソースをプロビジョニングして構成します。
- ワークロードを構築して構成し、移行元の環境にデプロイするのではなく、Google Cloud にデプロイします。
このプロセスの前の評価フェーズで、これらのプロセスに関する情報を収集しました。
これらのプロセスで検討すべきリファクタリングの種類は、どのように設計し実装したかによって異なります。リファクタリングは、プロセスごとに最終状態をどうするのかによっても異なります。たとえば、次の点を考えます。
- これらのプロセスを移行元の環境に実装した可能性があり、Google Cloud でも同様のプロセスを設計して実装したい場合もあります。たとえば、Cloud Build、Cloud Deploy、Infrastructure Manager を使用するようにこれらのプロセスをリファクタリングできます。
- これらのプロセスを移行元の環境外の別のサードパーティ環境に実装している場合もあります。この場合、移行元の環境ではなく Google Cloud 環境を対象とするように、これらのプロセスをリファクタリングする必要があります。
- 前述のアプローチを組み合わせたケース。
デプロイ プロセスと運用プロセスのリファクタリングは複雑になり、多大な労力が必要になる場合があります。ワークロードの移行の一環としてこれらのタスクを実行すると、ワークロードの移行が複雑になり、リスクが発生する可能性があります。デプロイ プロセスと運用プロセスを評価すると、その設計と複雑さを理解できるはずです。デプロイ プロセスと運用プロセスのリファクタリングに多大な労力が必要になると予想される場合は、これらのプロセスを別の専用プロジェクトの一部としてリファクタリングすることをおすすめします。
Google Cloud でデプロイ プロセスを設計して実装する方法については、以下をご覧ください。
このドキュメントでは、デプロイするアーティファクトを生成し、ターゲット ランタイム環境にデプロイするデプロイ プロセスについて説明します。リファクタリング戦略は、これらのプロセスの複雑さに大きく依存します。次のリストに、一般的なリファクタリング戦略の概要を示します。
- Google Cloud にアーティファクト リポジトリをプロビジョニングします。たとえば、Artifact Registry を使用してアーティファクトを保存し、依存関係をビルドできます。
- 移行元の環境と Artifact Registry の両方にアーティファクトを保存するように、ビルドプロセスをリファクタリングします。
- デプロイ プロセスをリファクタリングして、移行先の Google Cloud 環境にワークロードをデプロイします。たとえば、Artifact Registry に保存されているアーティファクトを使用して、Google Cloud にワークロードの小さなサブセットをデプロイできます。次に、移行するすべてのワークロードが Google Cloud で実行されるまで、Google Cloud にデプロイされるワークロードの数を徐々に増やします。
- アーティファクトを Artifact Registry にのみ保存するようにビルドプロセスをリファクタリングします。
- 必要に応じて、以前のバージョンのアーティファクトを移行して、移行元環境のリポジトリから Artifact Registry にデプロイします。たとえば、コンテナ イメージを Artifact Registry にコピーできます。
- リポジトリが不要になったら、移行元の環境のリポジトリを廃止します。
移行中に予期しない問題が発生した場合のロールバックを容易にするために、Google Cloud への移行中に、Google Cloud の現在のアーティファクト リポジトリと Artifact Registry の両方にコンテナ イメージを保存できます。最後に、移行元の環境の運用停止の一環として、コンテナ イメージのビルドプロセスをリファクタリングして、アーティファクトを Google Cloud にのみ保存できます。
移行の成功に不可欠ではないかもしれませんが、以前のバージョンのアーティファクトを移行元の環境から Google Cloud のアーティファクト リポジトリに移行することが必要になる場合があります。たとえば、ワークロードを任意の時点にロールバックできるようにするには、以前のバージョンのアーティファクトを Artifact Registry に移行する必要があります。詳細については、サードパーティ レジストリからイメージを移行するをご覧ください。
Artifact Registry を使用してアーティファクトを保存する場合は、アクセス制御、データ流出防止、脆弱性スキャン、Binary Authorization など、アーティファクト リポジトリを保護する制御を構成することをおすすめします。詳細については、アクセスを制御してアーティファクトを保護するをご覧ください。
運用プロセスをリファクタリングする
Cloud Run への移行の一環として、運用プロセスをリファクタリングして、Cloud Run 環境を継続的かつ効果的にモニタリングすることをおすすめします。
Cloud Run は、次の運用サービスと統合されています。
- Google Cloud Observability: ワークロードのロギング、モニタリング、アラートを提供します。必要に応じて、Cloud Run ワークロードの Prometheus スタイルのモニタリングまたは OpenTelemetry 指標を取得することもできます。
- Cloud Audit Logs: 監査ログを提供します。
- Cloud Trace: 分散パフォーマンス トレースを提供します。
データの移行
このプロセスの前の評価フェーズでは、移行する AWS Lambda ワークロードが AWS 環境内のデータに依存しているのか、データを生成しているのかを判断しました。たとえば、AWS S3 から Cloud Storage に、または Amazon RDS と Aurora から Cloud SQL と AlloyDB for PostgreSQL にデータを移行する必要があると判断した場合があります。AWS から Google Cloud にデータを移行する方法については、AWS から Google Cloud への移行: スタートガイドをご覧ください。
デプロイ プロセスと運用プロセスのリファクタリングと同様に、AWS から Google Cloud へのデータの移行は複雑になり、多大な労力が必要になる場合があります。AWS Lambda ワークロードの移行の一環としてこれらのデータ移行タスクを実行すると、移行が複雑になり、リスクが発生する可能性があります。移行するデータを分析すると、データのサイズと複雑さを把握できます。このデータの移行に多大な労力が必要になると予想される場合は、別の専用プロジェクトの一部としてデータを移行することをおすすめします。
移行結果を確認する
ワークロードの移行の検証は 1 回限りのイベントではなく、継続的なプロセスです。AWS Lambda から Cloud Run への移行前、移行中、移行後に、テストと検証に重点を置く必要があります。
パフォーマンスを最適化し、中断を最小限に抑えて移行を成功させるには、次のプロセスを使用して、AWS Lambda から Cloud Run に移行するワークロードを検証することをおすすめします。
- 移行フェーズを開始する前に、移行先の Google Cloud 環境を考慮して既存のテストケースをリファクタリングします。
- 移行中は、各移行マイルストーンでテスト結果を検証し、徹底した統合テストを実施します。
- 移行後、次のテストを行います。
- ベースライン テスト: さまざまな負荷での実行時間、リソース使用量、エラー率など、AWS Lambda 上の元のワークロードのパフォーマンス ベンチマークを確立します。これらのテストを Cloud Run で複製して、移行または構成の問題を示唆する不一致を特定します。
- 機能テスト: 両方の環境でさまざまな入力と想定される出力シナリオを網羅するテストケースを作成して実行し、ワークロードのコアロジックの整合性を維持します。
- 負荷テスト: トラフィックを徐々に増やして、実際の状況での Cloud Run のパフォーマンスとスケーラビリティを評価します。移行をスムーズに行うには、エラーやリソースの制限などの不一致に対処します。
Google Cloud 環境を最適化する
最適化が移行の最終フェーズになります。このフェーズではターゲット環境が最適化の要件を満たすまで最適化タスクを繰り返します。このイテレーションの手順は次のとおりです。
- 現在の環境、チーム、最適化ループを評価する。
- 最適化の要件と目標を設定する。
- 環境とチームを最適化する。
- 最適化ループを調整する。
最適化の目標を達成するまで、このシーケンスを繰り返します。
Google Cloud 環境の最適化の詳細については、Google Cloud への移行: 環境の最適化とパフォーマンスの最適化プロセスをご覧ください。
次のステップ
- AWS から Google Cloud への移行のその他の工程を確認する。
- AWS サービスや Azure サービスと Google Cloud を比較する方法を学習する。
- 移行に関するヘルプを確認するタイミングを確認する。
- Cloud Architecture Center で、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
寄稿者
著者:
- Marco Ferrari | クラウド ソリューション アーキテクト
- Xiang Shen | ソリューション アーキテクト
その他の寄稿者:
- Steren Giannini | グループ プロダクト マネージャー
- James Ma | プロダクト マネージャー
- Henry Bell | クラウド ソリューション アーキテクト
- Christoph Stanger | 戦略的クラウド エンジニア
- CC Chen | カスタマー ソリューション アーキテクト
- Wietse Venema | デベロッパーリレーションズ エンジニア