AWS から Google Cloud へのアプリの移行: あるスタートアップの視点
Google Cloud Japan Team
※この投稿は米国時間 2023 年 10 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。
編集者注: この投稿では、Fluxon の最高技術責任者を務める AJ Ross 氏が、AWS から Google Cloud への移行を検討しているスタートアップに向けて、主に考慮すべき事項と、AWS と Google Cloud のテクノロジーの違いについて説明しています。
スタートアップがアマゾン ウェブ サービス（AWS）から Google Cloud への移行を検討している場合に重要となるのは、この 2 つのクラウドの間にある技術的な違いを理解することです。幸い、ある程度のところまでは、どの最新型クラウド プラットフォームを使っても変わりはありません。しかし Fluxon の経験から言って、貴社がすでに移行を決定しているなら、Google Cloud の高度なソリューションの数々には嬉しい驚きを覚えるはずです。
移行する際に理解しておくべき重要な点は、アプリのワークロードにかかる費用だけでなく、クラウド プラットフォームのテクノロジーの機能の優位性や導入のしやすさによって、どれだけ運用支出を削減できるかということです。この点で Google Cloud は際立った存在です。実績のある幅広いソリューション、魅力的な機能を備えた API、パフォーマンス、信頼性のすべてをリーズナブルな価格で提供しています。Google Cloud は、Kubernetes や BigQuery など、競争他社のものよりはるかに優れたサービスも提供しています。
この記事では、AWS から Google Cloud への移行を検討しているスタートアップに向けて、主に考慮すべき事項と、AWS と Google Cloud のテクノロジーの違いについて説明します。また、機能、価格、スケーラビリティの観点からこの 2 つのプラットフォームを比較します。別々のクラウドに共通するフルスタックのアプリケーションを比較して理解するための、いわば「ロゼッタ ストーン」を求めている方、あるいは Google Cloud が AWS よりもはるかに優れている点を確認したい方は、この先を読み進めてください。
Identity Access Management（IAM）の管理
ユーザー、グループ、ロール、権限が複雑に絡まった IAM は、クラウド プラットフォームを管理するうえで最も難しい側面の一つです。AWS と Google Cloud はどちらも、IAM の詳細な点まで高度にカスタマイズできます。しかし、アプローチが異なっていることを理解するのは大切です。
大きな違いの一つとして、Google Cloud は専用のサービス アカウントのサポートが優れていることに気付くでしょう。サービス アカウントとはユーザーに相当します。その下で自社（および Google Cloud）のプログラムによる API が動作しています。トップレベルの Google Workspace のユーザーは、人力による認証やアクション専門です。一方、サービス アカウントはプログラムによる動作すべてを実行することが想定されています。Google Cloud のサービス アカウントでは、きめ細かくアクセス権を制御でき、最小権限のメリットを活用できます。サービス アカウントは Google Cloud で非常に広範に使用されています。貴社のためにサービスを実行するサービス アカウントは自動で作成されます。貴社ではロールとサービスを分離するためにチューニングするだけなので、時間と労力の節約になります。
AWS ではほぼすべてのアクションが、ポリシーとユーザーによって管理されます。ユーザーはグループとロールに属し、各アクションがポリシーに対してチェックされるという仕組みです。それとは異なり Google Cloud では、ユーザーごとに一般化したロールとポリシーを割り当てます。それらにアクセスできるユーザーは、リソースでも定義できます。
たとえば、AWS で本番環境のデータベースと S3 バケットへのアクセス権を持つ新しいユーザーを作成するとします。それにはまず、新しいユーザーにそれらのリソースの特定のアクションへのアクセス権を与えるポリシーを作成します。Google Cloud は、ユーザーまたはサービス アカウントを作成しても、そのユーザーの権限はバケット自体で設定します。かつて、AWS では S3 バケットにリソース固有のポリシーを適用していましたが、これらのポリシーが非推奨になってからしばらく経ちます。
アプリケーションをどこで実行すべきか？
Fluxon で構築しているアプリケーションのほとんどはウェブベースのものなので、アプリケーションをどこに、どのようにデプロイするかは非常に重要です。基本的に、AWS と Google Cloud ではどちらも仮想マシン（VM）を使用できます。AWS の場合は EC2、Google Cloud の場合は Compute Engine で VM が提供されます。どちらのプラットフォームでも、CPU、RAM、アタッチされるストレージのパラメータを構成して VM を作成できます。また、どちらのプラットフォームでも、リザーブド インスタンスやスポット インスタンスを使用して費用を削減したり、VPC を使用してサービスを安全に隔離したりできます。
既存の VM ベースのワークロードを AWS から Google Cloud に移行することを検討している場合は、どちらのサービスも大差ないと思えるかもしれませんが、Google Cloud には明確なメリットがあります。それは、エンドツーエンドのシームレスな移行エクスペリエンスを実現する移行センターと、リソース管理を大幅に容易にする最新型の包括的なインターフェースが提供されていることです。
しかし、サーバーを管理するとなると、エンジニアリング チームの業務にかかるオーバーヘッドが増えます。このことから、ほとんどの人がコンテナベースのデプロイを採用するようになっています。Cloud Run は、ECS Fargate などの AWS Elastic Container Service（ECS）パイプラインからコンテナを移行する際の理想的なソリューションです。Cloud Run を使用すれば、任意のコンテナを容易にホストしてスケールできます。さらに、Cloud Build では、アプリケーションの新しいバージョンをデプロイするパイプラインを迅速に構築できます。
ワークロードでマイクロサービスや複数のサービスを相互運用しなければならない場合は、Google Kubernetes Engine（GKE）という最高水準のソリューションでそのニーズを満たせます。GKE は、最大 15,000 個のノードまでのスケーリングと、各種の自動化に対応できる唯一のマネージド Kubernetes サービスです。競合他社とは異なり、Google Cloud では Cloud Run と GKE の両方を簡単に利用して、必要に応じて使い分けることができるため、チームがどちらか一方の選択を迫られることはありません。
AWS ですでに Kubernetes アプリケーションを使用している場合、Google Cloud もデプロイ、モニタリング、可用性、コマンドライン ツールという点で同等の機能を備えているため、Google Cloud への移行は難しくないでしょう。Google Cloud には Google Cloud コンソールという強みがあります。このコンソールでは、やや断片化された AWS よりもわかりやすい UI で Kubernetes を管理できます。
データベースに関する決定
AWS と Google Cloud で提供しているトランザクション データベースのオプションはほぼ同じです。両方とも、デベロッパーにとって魅力的なフルマネージドの PostgreSQL、MySQL、SQL Server を用意しています。また、VM を柔軟に構成できて、冗長性を確保するためのレプリケーション オプションとアベイラビリティ ゾーンをサポートしています。しかし、Google Cloud は Identity and Access Management システムでアクセス制御を管理できるという点で異なります。つまり、各データベースでそれぞれ個別にユーザーとロールを管理するのではなく、データベース アクセスを容易に Google Cloud に統合できるのです。
Memcache や Redis のような軽量のストレージまたはエフェメラル ストレージをお求めの場合、Google Cloud には Redis API 対応の Memorystore というサービスがあります。これは、キャッシュ保存をはじめ、Redis に期待する Key-Value ペアの高速処理に対応するのに理想的なサービスです。ただし、Memorystore では永続性が保証されないことに注意してください。Memorystore のより高価なスタンダード ティアでは複数の高可用性レプリカを使用できるものの、データがどこかしらのディスクにフラッシュされることはありません。理論上はそれでも問題ないはずですが、完全に Memorystore に切り替える前に、その違いを理解しておく必要があります。
Google Cloud が卓越している領域の一つは、レポート データベースです。AWS でデータレイクを使用している場合、BigQuery に感動するでしょう。BigQuery は、膨大な量のデータを保存できる費用対効果に優れたソリューションであり、保存したデータに対して SQL クエリを実行できます。BigQuery では（Kinesis と同様に）レコードをストリーミングして、（Redshift と同様に）レコード固有の形式で保存できます。さらに、（Spectrum や Athena と同様に）外部データソースをスキャンすることもできます。
AWS からデータを移行するには、Google Cloud Storage Transfer Service（クロスクラウド同期に対応）や、このサービスのTransfer Appliance についてご確認ください。大容量ストレージ デバイスの Transfer Appliance では、データを Google Cloud 施設に安全に転送できます。その後、データは Cloud Storage にアップロードされます。すでにビジネス インテリジェンスおよび分析プラットフォームを使用している場合、それらはおそらく BigQuery をサポートしているはずですが、こうしたプラットフォームを使用してない場合は、BigQuery 対応の Looker Studio（無料）をお試しいただくか、Looker Studio Pro にサブスクライブできます。
Cloud Storage は AWS S3 と同等のプラットフォームです。どちらも費用対効果に優れた形でオブジェクトを保存し、提供できます。ただし、どちらのプラットフォームの料金オプションも、ストレージ クラス、リージョン、冗長性、データ転送の量と方向、さらにアクセス頻度によって異なります。機能に関しては、Cloud Storage には馴染み深い機能が備わっています。Cloud Storage は S3 プロトコル（現在、クラウド プロバイダの間では事実上の標準となっているプロトコル）で直接通信しませんが、「gsutil」コマンドライン ユーティリティや Storage Transfer Service を使用すれば、他のプロバイダからデータをインポートできます。
次は、貴社の番です
アプリケーションがどれだけ複雑かによって、AWS から Google Cloud への移行は簡単かつ迅速なプロセスになることも、さまざまな複雑さが伴う、時間のかかるプロセスになることもあります。AWS のソリューションの多くは Google Cloud のソリューションに直接対応付けることができますが、そうはいかないのがアクセス制御やネットワーキング、その他のプラットフォームの独自性といった細かい部分です。いずれにしても、このガイドが AWS から Google Cloud への移行に関する概要を理解するのにお役に立っていれば幸いです。AWS と Google Cloud では多くのサービスが類似していますが、使いやすさ、最新型のインターフェース、厳格なセキュリティ管理という点で、Google Cloud は際立っています。
Google Cloud によるスタートアップのサポートにご関心をお持ちの場合は、こちらのページでプログラムの詳細をご確認ください。また、こちらから更新情報の配信にご登録いただいた方には、コミュニティ活動、デジタル イベント、スペシャル オファーなどの情報をお届けします。
-Fluxon、最高技術責任者 AJ Ross 氏
