Google Cloud には、アマゾン ウェブ サービス（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 ワークロードのリファクタリングが必要かどうかを判断するうえで役立ちます。ワークロードに必要なデプロイ アーティファクトを特定するには、次の情報を収集します。
- ワークロードをデプロイするデプロイ パッケージのタイプ。
- ライブラリやその他の依存関係など、追加のコードを含む 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 ジョブを実行します。
どの Cloud Run 呼び出しまたは実行メカニズムが AWS Lambda 呼び出しメカニズムに相当するかを理解するには、次の表をご覧ください。プロビジョニングする必要がある Cloud Run リソースごとに、適切な呼び出しまたは実行メカニズムを選択してください。
| AWS Lambda の機能 | Cloud Run の機能 |
|---|---|
| HTTPS トリガー（関数 URL） | HTTPS 呼び出し |
| HTTP/2 トリガー（外部 API ゲートウェイを使用して部分的にサポート） | HTTP/2 呼び出し（ネイティブでサポート） |
| WebSockets（外部 API ゲートウェイを使用してサポート） | WebSockets（ネイティブでサポート） |
| N/A（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 ボリューム マウント、インメモリ ボリューム マウント、シークレット、サービス アカウント
- 例外条件の処理: 最大再試行回数
- メタデータ: ラベルとタグ
Cloud Run の構成オプションと AWS Lambda の構成オプションの比較については、次の表をご覧ください。プロビジョニングする必要がある Cloud Run リソースごとに、適切な構成オプションを選択してください。
| AWS Lambda の機能 | Cloud Run の機能 |
|---|---|
| プロビジョニングされた同時実行 | 最小インスタンス数 |
| インスタンスあたりの予約済み同時実行数 （同時実行プールは、AWS アカウントの AWS Lambda 関数間で共有されます）。 |
サービスあたりの最大インスタンス数 |
| N/A（サポート対象外、1 つのリクエストが 1 つのインスタンスにマッピングされる） | インスタンスあたりの同時リクエスト数 |
| N/A（メモリ割り当てによって異なります） | 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 Cloud Run と Google Cloud プロダクトの統合 |
| スティッキー セッション（外部ロードバランサを使用） | セッション アフィニティ |
| 有望なお客様 | 変更内容 |
前の表に記載されている機能に加えて、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 APIs を使用するようにリファクタリングする必要がある場合があります。
- エラー報告。ワークロードが標準出力とエラー ストリームを使用してエラーを報告するかどうかを検討します。このようなエラーレポートを行うワークロードは、他のメカニズムを使用してエラーをレポートするワークロードと比較して、リファクタリングの必要性が少ない場合があります。
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への移行: 環境を最適化すると Google Cloud Well-Architected Framework: パフォーマンスの最適化をご覧ください。
次のステップ
- 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 | デベロッパーリレーションズ エンジニア