クラウドマイグレーション

Spanner への移行: Antigravity CLI で二重書き込みを自動化してサービス停止を最小限に

Mon, 14 Sep 2026 02:10:00 +0000

※この投稿は米国時間 2026 年 9 月 5 日に、Google Cloud blog に投稿されたものの抄訳です。

Google のファイナンスエンジニアリングチームは、レガシーデータレイヤーをモダナイズする必要が生じた際、グローバルに分散され、強整合性があり、高可用性機能を備えたマルチモデルデータベースである Spanner を選択しました。しかし、本番環境サービスをオフラインにせずに Spanner に移行することは、エンジニアリング上の大きな課題でした。アプリケーションを担当する社内チームとして、数十のデータアクセスオブジェクト（DAO）にわたって二重書き込みロジックを手動で書き換える必要がありましたが、このプロセスは時間がかかり、人的エラーが発生しやすいものでした。さらに、サービスを停止することなくこれを行うには、コードベース内のすべての DAO にわたって、マルチフェーズの二重書き込みアーキテクチャを実装する必要がありました。

この課題を解決するために、別のアプローチを採用しました。ヘッドレスモードの Antigravity CLI を利用した自動リファクタリングパイプラインを構築したのです。これにより、本番環境の準備を進めるなか、ステージング環境で厳格なデータパリティを維持しながら、移行速度を大幅に向上させることができました。

課題: 二重書き込みによる移行の仕組み

財務上の正確性が不可欠な高スループットの本番環境サービスを移行する場合、単純なカットオーバースクリプトは機能しません。過去のデータのバックフィルと検証がすべて完了するまで、レガシーデータストアと Spanner の両方が同じ書き込みを同時に受信することを確認する必要があります。

移行は、次の 3 つのフェーズに分けて実施しました。

過去のデータのバックフィル: 参照整合性を維持しながら、既存の過去のレコードを Spanner にコピーします。
二重書き込み / 二重読み取りの実装: 移行期間中に、すべての DAO を変更して、プライマリストアと Cloud Spanner の両方にミューテーションを並行して書き込みます。
自動化された API 検証とパリティチェック: RPC トラフィックをインターセプトし、すべての書き込みが両方のストアでバイト単位で同等に完了することをエンドツーエンドで検証します。

アーキテクチャパターンはクリーンですが、Google の規模では、摩擦が生じ始めました。これは、各 DAO に以下が必要なためです。

複雑なドメインモデルを Spanner スキーマ列にマッピングする専用の MutationConverter クラス
二重書き込みブランチの処理とロールバックまたはエラー報告のロジック
疑似時間ソースとテストダブル（FakeTimeSource）を使用して、プライマリと Spanner の両方の書き込みを検証する単体テストのスイート

30 以上の DAO にわたって、同一の高精度なコード変更を手作業で行っていたら、エンジニアリングに数か月を要していたでしょう。

解決策: 標準化されたミューテーションコンバータパターン

自動化パイプラインがクリーンなコードを確実に生成できることを検証するために、まず、分離された MutationConverter インターフェースを中心に DAO リファクタリングパターンを標準化しました。

中核的な DAO ビジネスロジック内に未加工の Spanner テーブル名と列割り当てを直接埋め込むのではなく、Spanner スキーマ変換を専用のコンバータユニットに分離します。

code_block: <ListValue: [StructValue([('code', '// Example of the standardized pattern generated by our pipeline\r\n\r\ntype BpcTransferAmountsMutationConverter interface {\r\n ToInsertMutation(entity *model.BpcTransferAmount) (*spanner.Mutation, error)\r\n ToUpdateMutation(entity *model.BpcTransferAmount) (*spanner.Mutation, error)\r\n}\r\n\r\ntype bpcTransferAmountsMutationConverterImpl struct {\r\n tableName string\r\n}\r\n\r\nfunc (c *bpcTransferAmountsMutationConverterImpl) ToInsertMutation(entity *model.BpcTransferAmount) (*spanner.Mutation, error) {\r\n if entity == nil {\r\n return nil, errors.New("entity cannot be nil")\r\n }\r\n \r\n // Map domain fields to Cloud Spanner table schema\r\n cols := []string{"TransferId", "AmountCents", "CurrencyCode", "LastModifiedTimestamp"}\r\n vals := []interface{}{\r\n entity.TransferId,\r\n entity.AmountCents,\r\n entity.CurrencyCode,\r\n spanner.CommitTimestamp, // Use Spanner commit timestamps\r\n }\r\n \r\n return spanner.Insert(c.tableName, cols, vals), nil\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff7d4503050>)])]>

DAO と Spanner SDK（spanner.Mutation）の間に厳格で決定論的なコントラクトを確立することで、AI コーディングエージェントが推論して確実に生成できる正確なターゲット仕様を作成しました。

Antigravity CLI をヘッドレスモードで使用する理由

IDE のインタラクティブな AI チャットインターフェースは、探索的なコーディングには適していますが、コードベース全体にわたる体系的な複数ファイルのコード更新には適していません。エッジケースを見逃さずに、数十のターゲットに繰り返し可能なリファクタリングを適用する必要がある場合は、自動化されたワークフローが必要です。

この問題に対処するため、Antigravity CLI をヘッドレスモード（-p）で実行するオーケストレーションスクリプト（migration_ui.py）を構築しました。

ヘッドレスモードでは、ターミナルのプロンプトに手動で応答しなくても、シェルスクリプト、継続的インテグレーションパイプライン、バックグラウンド自動化ジョブ内で Antigravity を直接実行できます。このアプローチにより、主に 3 つの方法で作業を効率化できました。

決定論的なプロンプトアーキテクチャ: プロンプトをバージョン管理されたエンジニアリングアーティファクトとして扱いました。タイムスタンプのシリアル化、null 可能性の変換、ミューテーションの曖昧さ、FakeTimeSource テストインジェクションなど、Spanner の一般的なエッジケースを処理する正確なルールを、再利用可能なプロンプトテンプレートに直接コード化しました。
バッチ実行と自動検証: オーケストレーションスクリプトが、ターゲット DAO 名を入力として使用し、既存の単一書き込みソースコードとスキーマを取得して、構造規則とともにヘッドレス Antigravity にフィードします。Antigravity は、新しいコンバータ、リファクタリングされた二重書き込み DAO、対応する単体テストを生成します。その後、スクリプトは blaze test を実行します。linter エラーやテストアサーションの失敗が発生すると、エラーログが Antigravity に直接フィードバックされ、自己修正が行われます。
夜間に大規模に実行: ループは無人で実行されるため、エンジニアは 1 日の終わりに 10 個の DAO をキューに入れることができます。朝までに、パイプラインは人間によるコードレビューの準備が整った 10 個のクリーンな変更リストを生成、テスト、検証します。

クラウドエンジニアにとっての成果と重要なポイント

Spanner の分散データベースプリミティブと Antigravity CLI のヘッドレス自動化を組み合わせることで、エンジニアリング組織全体に明確なメリットがもたらされました。

移行作業の大幅な削減: 二重書き込みによる DAO の移行は、以前は広範な手動コーディングとテストが必要でしたが、わずかな時間で完了し、確認されました。
信頼性の高いデータ移行: 生成されたすべての DAO が、テスト済みのまったく同じ MutationConverter パターンに準拠し、Spanner テストダブルに対する自動単体テストを受けたため、広範な移行テスト中も高いデータ忠実度を維持できました。
より価値の高いエンジニアリングに集中: エンジニアは、繰り返しのボイラープレートリファクタリングを回避し、データモデリング、アーキテクチャの復元力、パフォーマンスの最適化に集中する時間を確保できました。

次回のデータベース移行に役立つ 3 つのヒント

まずスキーマ変換を分離する: 移行スクリプトを記述する前に、新しいクラウドデータベース SDK の要件を既存のビジネスロジックから分離する厳密なインターフェース（MutationConverter など）を定義します。AI エージェントは、明確で限定された設計パターンを与えられた場合に、最も効果的に機能します。
インタラクティブなチャットからヘッドレス自動化に移行する: 3～4 個以上のファイルにわたって繰り返しリファクタリングを実行する場合は、スクリプト化されたヘッドレスワークフローにリソースを投入します。プロンプト入力とテスト検証を自動化されたビルドステップとして扱うことで、品質と一貫性を維持できます。
ビルドシステムをガードレールとして機能させる: AI 生成ループをビルドおよびテストハーネス（bazel test または go test）に直接接続します。これにより、デベロッパーがコードを確認する前に、モデルがコンパイルエラーとアサーションエラーを修正できます。

使ってみる

金融システムの移行でも、クラウドネイティブアプリケーションのゼロからの構築でも、Spanner と Antigravity はスケーラブルなソフトウェア開発の基盤となります。

Cloud Spanner を確認する: Spanner の分散アーキテクチャの詳細については、Google Cloud Spanner のドキュメントをご覧ください。
デベロッパー向け Gemini を確認する: AI を活用したコーディングとヘッドレス CLI の自動化がエンジニアリングワークフローにどのように役立つかを、デベロッパー向け Google Cloud AI でご確認ください。

- アプリケーションエンジニア Sachin Mathapati

Uber がクラウド移行を妨げることなくネットワークの信頼性を向上させた方法

Wed, 09 Sep 2026 03:00:00 +0000

※この投稿は米国時間 2026 年 8 月 27 日に、Google Cloud blog に投稿されたものの抄訳です。

Uber には、サービスを展開している都市との共通点が数多くあります。どちらも常に変化と成長を続けており、混雑や無秩序な拡大を防ぐために、それに伴うトラフィックを慎重に管理する必要があります。

Uber は、拡大するネットワークを管理するために技術戦略を絶えず進化させてきました。こうした綿密な計画と継続的な進化が、プラットフォーム全体のアプリケーショントラフィックの円滑な運用を支えています。最終的には、いつでもシームレスに動作する信頼性の高い大規模なプラットフォームを維持することが、ユーザーの信頼を維持する鍵となります。

この取り組みにおける重要なソリューションの一つが、Cloud Interconnect 上の Application Awareness です。ハイブリッドネットワーク全体でアプリケーションの優先順位付けを行う業界初のツールである Cloud Interconnect 上の Application Awareness は、Uber が重要なトラフィックを優先し、ネットワークの輻輳が発生した場合でもビジネスの継続性を確保するのに役立っています。

Uber は、Cloud Interconnect 上の Application Awareness の初期設計パートナーとして、この機能が Uber のグローバル規模の運用ニーズを満たすものとなるよう貢献しました。これにより、Uber の日々の業務が改善されただけでなく、切り替え時のサービス中断のリスクを抑えられるという確信を得たことで、Google Cloud への移行を自信を持って進められるようになりました。

この投稿では、Uber が最も求めていた機能とその理由、Cloud Interconnect 上の Application Awareness の内部の仕組み、そしてそれが他の組織にもどのように役立つかについて説明します。

重要なトラフィックの優先順位付け

分散型、ハイブリッド、またはマルチクラウドのアプリケーションをグローバル規模で移行する場合、ネットワークの信頼性が最大の懸念事項となります。どんなに意義のある移行であっても、稼働中のサービスを中断させてしまうようでは、その価値は損なわれてしまいます。Uber のような組織にとって、台頭する AI ユースケースを含む大規模なデータ分析ワークロードを支えるための膨大なデータ転送は、ネットワークリンクを飽和状態にし、重要なアプリケーショントラフィックの信頼性を損なうリスクを招きかねません。

標準的なクラウド接続手法では、企業は通常、膨大なインフラストラクチャのニーズを満たすために、単純に帯域幅をオーバープロビジョニングするという方法をとります。しかし、昨今のハイブリッドクラウドの需要と、Uber のような組織の規模を考えると、ピーク時の使用量に合わせてネットワーク容量をオーバープロビジョニングすることは、費用がかかりすぎるうえ、信頼性も低い場合があります。

最先端の AI イノベーションを統合すると、オーバープロビジョニングの欠点がさらに拡大します。Uber は、ネットワークを混雑させることなく、ビジネスクリティカルなアプリケーションのパフォーマンスを保護しながら、大量のデータ転送に対応できるシステムを必要としています。

Cloud Interconnect の Application Awareness が備える 4 つの主要機能（トラフィック処理、輻輳対応、レイテンシ管理、コスト効率）を活用することで、Uber は最新の技術スタックに不可欠なネットワークの最適化を実現しました。

Uber は限定公開プレビューの段階からこの機能の導入を開始しました。まずはアリゾナ州フェニックスとバージニア州アッシュバーンの Google Cloud Interconnect から着手し、その後インフラ全体へと展開を広げました。Cloud Interconnect 上の Application Awareness により、Uber は DSCP マーキングや構成済みのキューイングプロファイルを活用して、エンドユーザーのアプリケーショントラフィックを分類し、緊急性の低いデータよりも優先的に処理できるようになります。

次の表では、Cloud Interconnect 上の Application Awareness の 4 つの主な機能、従来の方式との違い、そして Uber のような組織の運用継続性の向上にどのように役立つかについて説明しています。

機能	標準的な接続ソリューション	Cloud Interconnect 上の Application Awareness
トラフィックの処理	すべてのトラフィックが平等に扱われる（先入れ先出し）	トラフィックを 6 つの異なるトラフィッククラスに分類
輻輳対応	バースト時に優先度の高いアプリケーショントラフィックがドロップされる可能性がある	ビジネスクリティカルなトラフィックは、厳密な優先度ポリシーまたは帯域幅共有ポリシーによって保護される
レイテンシ管理	優先度の高いアプリケーションのレイテンシが予測不能	時間的制約のあるワークロードに対して、予測可能かつ一貫した低レイテンシを実現
コスト効率	ピークを吸収するために高額なオーバープロビジョニングが必要	効率的な帯域幅利用と TCO の削減

Uber の事例の要点

Uber にとって、Cloud Interconnect 上の Application Awareness を導入し、ネットワーク上のビジネスクリティカルなトラフィックに優先順位を付けられることの価値は、すぐに目に見える形で現れました。この取り組みを通じて、Uber は、同様のハイブリッドクラウドの課題を抱える他の企業が再現できるブループリントも作成しました。このブループリントの主要な要素は次のとおりです。

ビジネス継続性の確保: Uber は、トラフィック量の多い大規模なイベントが発生した際に、優先すべきアプリケーショントラフィックをリアルタイムに決定できます。これにより、計画的か不測の事態かを問わず、極端な負荷が発生するような状況下でも、ミッションクリティカルなアプリケーションの稼働を維持できます。Uber の経営陣は、Cloud Interconnect 上の Application Awareness はグローバルな事業運営に重要であると述べています。
帯域幅の効率的な利用: 輻輳を防ぐために帯域幅を盲目的にオーバープロビジョニングするのではなく、Application Awareness により、Uber は予想されるネットワーク帯域幅のニーズに合わせて、既存の Cloud Interconnect 容量をより有効に活用できるようになりました。その結果、ネットワークインフラストラクチャの総所有コストが削減されています。
ワークロード移行の障害を排除: 重要なアプリケーションをネットワークの輻輳から保護することで、Uber は重要なワークロードを Google Cloud に移行し、その過程で運用上のオーバーヘッドを大幅に削減できました。

「Cloud Interconnect 上の Application Awareness は、より戦略的なワークロードの Google Cloud 移行を実現する鍵となりました。世界規模で需要が急増する際にも、サービスの信頼性を維持するうえで不可欠な役割を果たしています。トラフィックにインテリジェントに優先順位を付けることで、優先度の高いサービスを保護し、インフラストラクチャの効率を高め、総所有コストを削減できます。これは単なる機能の導入にとどまりません。当社のビジネスに不可欠なソリューションを共に創り上げた、両社の深いエンジニアリングパートナーシップの賜物です。」– Uber、エンジニアリングディレクター、Harry Liu 氏

AI とそれ以外のネットワークの信頼性を確保

クラウドベースの AI モデル、分散アプリケーション、データ分析を統合する企業が増えるにつれ、それに伴う大量のデータ転送に対応する準備を整えることが、ビジネス上の必須事項となっています。しかし、その一方で、重要なアプリケーションの信頼性を決して損なわないようにする必要もあります。

Uber は、Cloud Interconnect 上の Application Awareness を使用することで、ビジネスクリティカルなトラフィックを保護するために単に帯域幅をオーバープロビジョニングするのではなく、最新のハイブリッドクラウド戦略やマルチクラウド戦略を採用するために必要な安定性を構築することが不可欠なステップであることを実証しました。

Cloud Interconnect が組織にもたらすメリットについて詳しくは、さまざまな業界における Cloud Interconnect の可能性に関するブログをご覧ください。さらに詳しく知りたい場合は、Google のネットワーキングと業界のエキスパートがサポートいたします。

- Uber、上級エンジニア、Jean He 氏

- Google Cloud、プリンシパルアーキテクト、Gopinath Balakrishnan

Google Cloud のアプリケーションロードバランサへの移行: 実践ガイド

Tue, 21 Apr 2026 01:10:00 +0000

※この投稿は米国時間 2026 年 4 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。

既存のアプリケーションロードバランサインフラストラクチャをオンプレミスのハードウェアソリューションから Cloud Load Balancing に移行すると、スケーラビリティと費用効率が大幅に向上し、Google Cloud エコシステム内での緊密な統合が実現します。しかし、多くの場合、「現在のロードバランサ構成はどうなるのか」という根本的な疑問も生じます。

既存のオンプレミスロードバランサの構成には、トラフィック操作のためのビジネスクリティカルなロジックが何年分も蓄積されていることがよくあります。こうした既存の機能は完全に移行できます。加えて、この移行は、トラフィック管理をモダナイズして簡素化する絶好の機会にもなります。

このガイドでは、既存のロードバランサを Google Cloud のアプリケーションロードバランサに移行するための実践的なアプローチを紹介します。このアプローチでは、一般的な機能に対応するために、宣言型構成と革新的なイベントドリブン型 Service Extensions エッジコンピューティング機能の両方を活用します。

シンプルで段階的な移行アプローチ

命令型のスクリプトベースシステムからクラウドネイティブな宣言型ファーストモデルへの移行には、体系的な計画が必要です。そこで、4 つのフェーズからなるシンプルなアプローチをおすすめします。

フェーズ 1: 調査とマッピング

移行を開始する前に、現状を把握する必要があります。現在のロードバランサの構成を分析して分類しましょう。各ルールの意図は何ですか？単純な HTTP から HTTPS へのリダイレクトを行っていますか？HTTP ヘッダーの操作（追加または削除）に関与していますか？それとも、複雑なカスタム認証ロジックを扱っていますか？

ほとんどの構成は、次の 2 つの主なカテゴリに分類されます。

一般的なパターン: リダイレクト、URL の書き換え、基本的なヘッダー操作、IP ベースのアクセス制御リスト（ACL）など、ほとんどのウェブアプリケーションに共通するロジック。
カスタムビジネスロジック: カスタムの独自トークン認証、高度なヘッダーの抽出 / 置換、HTTP 属性に基づく動的なバックエンド選択、HTTP レスポンス本文の操作など、アプリケーションに固有の複雑なロジック。

フェーズ 2: Google Cloud における同等機能の選択

ルールを分類したら、次はそれらを適切な Google Cloud 機能にマッピングします。これは 1 対 1 の置き換えではなく、戦略的な選択となります。

オプション 1: 宣言型の方法（ルールの約 80%）一般的なパターンの大部分については、通常はアプリケーションロードバランサに組み込まれている宣言型機能を活用することが最適なアプローチです。スクリプトの代わりに、構成ファイルで望ましい状態を定義します。これにより、管理、バージョン管理、スケーリングが容易になります。

宣言型機能マッピングの一般的なパターン:

リダイレクト / 書き換え -> アプリケーションロードバランサの URL マップ
ACL / スロットリング -> Google Cloud Armor のセキュリティポリシー
セッションの永続性 -> バックエンドサービス構成

オプション 2: プログラムによる方法（複雑なカスタムルールの場合）複雑なカスタムビジネスロジックを扱う場合、プログラムによる同等の方法として Service Extensions があります。これは、Rust、C++、Go で記述したカスタムコードをロードバランサのデータパスに直接挿入できる強力なエッジコンピューティング機能です。このアプローチにより、最新のマネージド型高パフォーマンスフレームワークで柔軟性を確保できます。

このフローチャートは、各構成に適した Google Cloud の機能を判断するためにお役立てください。

フェーズ 3: テストと検証

構成に適した方法を選択したら、本番環境のセットアップを反映したステージング環境に新しいアプリケーションロードバランサ構成をデプロイする準備が整います。移行対象のロジックに特に注意しながら、アプリケーションのすべての機能を徹底的にテストします。自動テストと手動 QA を組み合わせて、リダイレクトやセキュリティポリシー、そしてカスタムの Service Extensions ロジックが想定どおりに動作することを検証します。

フェーズ 4: 段階的なカットオーバー（カナリアデプロイ）

すべてのトラフィックについて切り替えを一度に行うのではなく、段階的な移行戦略を実施します。最初は、本番環境トラフィックの少ない割合（5～10% など）を新しい Google Cloud ロードバランサにルーティングします。この初期段階では、レイテンシ、エラー率、アプリケーションのパフォーマンスなどの主要な指標を必ずモニタリングしてください。確信が持てたら、アプリケーションロードバランサにルーティングするトラフィックの割合を徐々に増やしていきます。重大な問題が発生した場合に備えて、以前のインフラストラクチャに戻すための明確なロールバック計画も常に用意しておきましょう。

スムーズな移行のためのベストプラクティス

Google の実践経験に基づき、ロードバランサの移行計画を立てる際に役立つ推奨事項を以下にまとめます。

先に分析してから移行する: 既存の構成を徹底的に分析することが最も重要なステップです。不要になったロジックの「リフト＆シフト」を行わないようにします。
宣言型を優先する: デフォルトとして、Google Cloud のマネージド型、宣言型の機能（URL マップ、Cloud Armor）を常に先に使用します。これらの機能は、よりシンプルでスケーラブルであり、メンテナンスも少なくて済みます。
Service Extensions は戦略的に使用する: Service Extensions は、宣言型機能では処理できない複雑なカスタムビジネスロジックのために取っておきます。
すべてをモニタリングする: 移行中は、既存のロードバランサと Google Cloud ロードバランサの両方を継続的にモニタリングします。トラフィック量、レイテンシ、エラー率などの主要な指標を注視して、問題が発生した場合は即座に検出して対処します。
チームのトレーニングを行う: Cloud Load Balancing のコンセプトについて、チームにトレーニングを提供します。これにより、チームは新しいインフラストラクチャを効果的に運用、維持できるようになります。

既存のオンプレミスロードバランサインフラストラクチャからの移行は、単なる技術的なタスクではなく、アプリケーション配信をモダナイズする機会です。現在のロードバランシングの構成と機能を、宣言型のアプリケーションロードバランサ機能またはプログラムによる Service Extensions のいずれかに入念にマッピングすることで、スケーラビリティ、復元力、費用対効果に優れたインフラストラクチャを構築し、将来の需要に対応できます。

移行を始めるには、アプリケーションロードバランサと Service Extensions の特徴や高度な機能を確認して、アプリケーションに適した設計を考案します。詳細なガイダンスや複雑なユースケースについては、Google Cloud チームにお問い合わせください。

- Google Cloud、カスタマーエンジニア、Gopinath Balakrishnan

- Google Cloud、カスタマーエンジニア、Xiaozang Li

Rapid Migration and Modernization Program（RaMP）の新しいインセンティブで移行を加速させましょう

Mon, 26 Jan 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 1 月 22 日に、Google Cloud blog に投稿されたものの抄訳です。

2026 年に主導的な立場を確立するには、あらゆるワークロードにわたり、AI 対応、スリム化、最適化が必要となります。多くの組織にとって、それは SAP、Oracle、NetApp、VMware などのアプリケーションをクラウドに移行してモダナイズすることを意味します。Google Cloud は、Rapid Migration and Modernization Program（RaMP）を通じて、数千ものお客様の移行を成功に導いてきましたが、このたび、移行すればするほど節約できる新しい RaMP を導入することになりました。新しいプログラムの重要ポイントは次のとおりです。

Google Cloud サービスクレジット: Google Cloud 上の対象ワークロードの使用量の増分に基づいてクレジットを獲得できます。
パートナーサービスファンドと Google Cloud プロフェッショナルサービスファンド: パートナーと Google Cloud プロフェッショナルサービスに資金を提供して、お客様のニーズの評価、ビジネスケースの構築、移行とモダナイゼーションのロードマップの実装を支援します。
高度なワークロードにより収益を拡大: 高度なワークロード（SAP、Oracle、VMware、データ分析など）に対して追加のクレジットとインセンティブを獲得し、高い技術費を相殺できます。

技術的負債から AI 対応へ

移行とモダナイゼーションの過程において、費用と複雑さは軽減されるべきであり、増すことがあってはなりません。Google Cloud に移行すると、技術的負債を柔軟に置き換えるのに必要なインフラストラクチャ基盤が提供されるため、費用と複雑さを抑えることができます。

しかし、インフラストラクチャの移行とモダナイゼーションにはそれ以上の意味があります。データアクセシビリティ、最適化、そしてイノベーションが重要なのです。たとえば、SAP のレガシー環境や大規模な Oracle データベースを Google Cloud に移行する場合、データは単に保存場所が変わるだけでなく、Vertex AI や Gemini モデルからアクセスできるようになります。

RaMP により、移行を加速させ、技術的負債をスケーラブルで安全な基盤に置き換えることができます。この基盤は、既存のエンタープライズワークロードにも、次世代の AI アプリケーション（何であれ）にも対応するものとなります。

将来を見据えて

RaMP を使用した移行とモダナイゼーションにより、世界クラスのインフラストラクチャ、データ、AI ソリューションにすぐにアクセスでき、2026 年以降の成功に必要な基盤を手に入れることができます。使用を開始するには、RaMP のページで詳細を確認し、評価を開始してください。RaMP で AI 時代を迎える準備を迅速に整えましょう。成功への近道へようこそ。

- GTM プラクティス担当バイスプレジデント Lindsay Myers

- GTM プログラム担当ディレクター Hani Shakeel

Searce とともに Google Cloud へのクラウド移行を加速し、収益性の高い成長を促進

Fri, 10 Oct 2025 01:10:00 +0000

※この投稿は米国時間 2025 年 9 月 26 日に、Google Cloud blog に投稿されたものの抄訳です。

企業が従来のインフラストラクチャから移行し、AI、マルチクラウド、プラットフォームエンジニアリングの要件を満たして成長を遂げるために、多くの企業が信頼性、パフォーマンス、費用対効果に優れた Google Cloud を選択しています。

特に企業レベルで移行を成功させるには、プラットフォームのモダナイゼーション、自動化、ビジネス成果を深く理解している経験豊富なパートナーが必要です。Searce は、複数の組織が Google Cloud に移行して大きなビジネス価値を実現できるよう支援している Google Cloud パートナーの一つです。

Searce は 1,000 件以上の移行を主導

Searce は、エンジニアリング主導の AI 搭載コンサルティング会社であり、Google Cloud プレミアパートナーです。これまでに 1,000 件以上の移行を成功させています。その焦点は、Google Cloud を使用して、あらゆる業界の企業がより迅速にスケールし、従来のプラットフォームをモダナイズし、新たな効率性を実現できるよう支援することです。

Searce は、実践的な経験を通じて、企業が Google Cloud に移行する際に得られる、一貫性があり測定可能な 3 つのメリットを特定しました。

信頼性の向上とクラウドネイティブサービス（信頼性が 25% 向上）
コスト削減による生産性の向上（例: TCO を 80% 削減）
スケーラビリティとパフォーマンス（例: ペタバイト規模のデータを移行し、ダウンタイムを 75% 削減、パフォーマンスを 30% 向上）

Google Cloud のグローバル VPC、AI/ML におけるリーダーシップ、Google Kubernetes Engine や GKE Autopilot などの強力なマネージドコンテナサービスが、こうした変革を可能にしています。Searce は、これらの機能をエンジニアリング主導のソリューション指向のアプローチと組み合わせて、特にレガシープラットフォームのモダナイズや AI ワークロードのスケーリングを行う組織に対して、迅速に効果をもたらします。Searce が実施した Google Cloud への移行の例をいくつか見てみましょう。

GKE Gateway Controller で医療の信頼性を向上

年間 5,000 万人以上の患者を治療する大手のデジタルヘルスケアプロバイダでは、プラットフォームの可用性をほぼ 100% にする必要がありました。別のクラウドプロバイダにおける従来の Kubernetes インフラストラクチャでは、マイクロサービスのアップグレード中に定期的に計画外の停止が発生し、ケアが遅れたり、薬局が中断したり、患者の信頼が損なわれたりしていました。

Searce はプラットフォームを GKE にアップグレードし、従来の Ingress リソースを GKE Gateway Controller に置き換えてルーティングを分離し、より安全かつ迅速なロールバックを可能にしました。結果Searce によると、このヘルスケア企業は次のような成果を上げました。

プラットフォームの信頼性が 25% 向上
インフラストラクチャ費用を 30% 削減
Cloud Logging によるログ集計の合理化と、グローバル VPC アーキテクチャによる単一のリソース管理

GKE を使用することで、アップデートを安全にリリースし、ダウンタイムを最小限に抑え、可用性を損なうことなく開発を加速できるようになりました。

GKE Autopilot でグローバルなフィンテックリーダーの TCO が 50% 削減

20 か国以上で事業を展開する国際的なフィンテック企業では、複数の Kubernetes クラスタを使用して大規模なパフォーマンスを実現していましたが、このようなグローバルなデプロイの管理にはコストがかかっていました。運用上のオーバーヘッドがエンジニアの時間を奪い、イノベーションの勢いを削いでいました。

Searce は、これらのワークロードを GKE Autopilot に移行するという方法で、サービス管理の統合と、複雑だった運用の Google Cloud への移行を支援しました。グローバル HTTP ロードバランシング、自己管理型の Infrastructure as Code（IaC）モジュール、チーム固有のリソース管理により、Searce のお客様のビジネスは次のような成果を上げました。

総所有コストの 80% 削減
エンジニアリングの生産性が 40% 向上
顧客向け機能の市場投入までの時間を短縮

この変革により、チームはインフラストラクチャの処理ではなく、ユーザーに価値を提供するという最も重要なことに集中できるようになりました。

グローバルな通信大手のパフォーマンスをスケーリング

ペタバイト規模のデータと 150 年以上の歴史を持つ世界有数の通信プロバイダは、妥協することなくスケーリングできる必要がありました。従来のシステムではパフォーマンスが制約され、メンテナンスに許容できないほど長いダウンタイムが必要でした。

同社は Searce と協力して、Google Cloud へのスムーズな移行を計画し、AI ワークロードのストレージとコンピューティングを最適化し、高スループットのデータパイプラインを組み合わせました。

結果、Searce とお客様は、次のことを実現しました。

システムパフォーマンスが 30% 向上
移行中のダウンタイムが 75% 減少
将来を見据えた基盤で、お客様のイノベーションとデータドリブンなサービスを強化

Searce が移行を成功に導く方法

1,000 件以上の移行を成功させてきた Searce は、深いエンジニアリングの専門知識と実績のあるフレームワークを活用して、企業が迅速かつ確実に、長期的な価値を伴う形で Google Cloud に移行できるよう支援します。

その中心にあるのは、インフラストラクチャ、データ、アプリケーション、AI 全体で企業のワークロードを簡素化、最適化し、将来にわたって対応できるようにする Searce の「evlos」（Solve differently）アプローチです。

実績のある 5 ステップの移行フレームワーク

Searce の構造化されたアプローチにより、調査から Day-2 運用までスムーズな移行が可能です。

調査と評価 – ワークロードと依存関係を特定する
計画 – 移行、DR、ロールバックの戦略を定義する
設計、移行、テスト – ダウンタイムを最小限に抑えたウェーブベースの自動化
実行 – カットオーバーとシステムの安定化
HyperCare – Searce の社内 SOC チームによる移行後の 24 時間 365 日サポート

企業が Google Cloud への移行を完了し、カスタマージャーニーをさらに合理化できるよう、Searce は 3 つの主要なアクセラレータを提供しています。

自動費用削減評価 – 24 時間で TCO レポート
自動化された技術評価 – 安全なソフトウェア主導のインベントリ
Google Cloud への自動移行 – スクリプトベースの自動化で迅速なカットオーバーを実現

移行の取り組みを加速させる準備は整いましたか？

世界中の企業が、スケーラブルで信頼性が高く、AI 対応のプラットフォームを構築するために Google Cloud を選択しています。Searce は、実績のある移行経験、ドメインの専門知識、独自の変革アプローチにより、お客様が目標をより早く達成できるよう支援する、信頼できるパートナーです。Google Cloud の機能を活用することで、Searce は移行を単なる技術的な移行ではなく、イノベーションを戦略的に実現するものに変えます。

自信を持って移行することで実現できることをご覧ください。詳細については、こちらのリンクからホワイトペーパーをご覧ください。

-Google Cloud、Google Kubernetes Engine、プロダクトマーケティングマネージャー Shubhika Taneja

-Searce、クラウドエンジニアリング担当ディレクター Harish Salian

AI を活用した BigQuery 移行サービスを使ってデータプラットフォームの移行を簡素化

Thu, 10 Apr 2025 16:00:00 +0000

※この投稿は米国時間 2025 年 4 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。

「データから AI への統合プラットフォーム」である BigQuery にデータワークロードを非常に簡単に移行できるようになりました。今後は、最新のデータプラットフォームに移行してデータアセットを最大限活用するか、リスクを抑えるため現状を維持するかで迷う必要はありません。BigQuery 移行サービスを使えば両方を実現できます。BigQuery 移行サービスは、無料で使えるクラウドネイティブサービスのコレクションで、移行プロセスを分割して、テンプレート化された繰り返し実行できる管理しやすいステップにすることにより、データウェアハウスとデータレイクの大規模な変換を可能にします。オンプレミスとクラウドプラットフォームからデータ、コード、ビジネスロジックを BigQuery に移行でき、その際には、「次に取るべき最適なアクション」のアプローチを使用して、移行にかかる時間をできる限り短縮し、ビジネス変革の ROI を最大化します。

Google Cloud Next 25 では、データサイエンスへの対応や、データエンジニアリングとデータ分析のワークロードに対するサポートの拡大など、BigQuery 移行サービスの新たなイノベーションを発表しました。新しい機能はデータプラットフォームの移行における 4 つの段階、1）自動評価と計画、2）自動コード変換、3）データ移行、4）検証のそれぞれに導入されています。

BigQuery 移行サービス

BigQuery 移行サービスの新しいイノベーションについてご紹介します。

1. 総所有コストの試算を含む自動検出と評価

データプラットフォームの移行は、移行元の環境の自動検出と評価から始まります。BigQuery 移行サービスの自動評価では、既存の環境に関する詳細情報、BigQuery に移行した場合のワークロードの想定される状態（パフォーマンスや総所有コストの試算など）に関する役に立つ分析ビュー、そして BigQuery への移行方法（移行計画）について確認できます。Google Cloud コンソールのボタンを押すだけで評価を実行でき、詳細な Looker Studio レポートと BigQuery データセットが出力されます。評価は Teradata、Snowflake、Redshift で利用できます。さらに Oracle の Exadata と Cloudera の Hive の評価が今すぐ利用できるようになったことと、Databricks の評価が近日公開されることをこのたび発表しました。

体系立てて移行を実行し成功させるため、プレビュー版のソースリネージサービスも発表しました。このサービスはワークロード間の依存関係を自動的に識別してグループ化し、ワークロードを処理する明確な順序を特定することで、リスクとサービスの中断を最小限に抑え、価値創出までの時間を短縮します。

aside_block: <ListValue: [StructValue([('title', '300 ドル分のクレジットで Google Cloud のデータ分析を試用'), ('body', <wagtail.rich_text.RichText object at 0x7ff7c25b0e10>), ('btn_text', '無料で構築を始める'), ('href', 'http://console.cloud.google.com/freetrial?redirectPath=/bigquery/'), ('image', None)])]>

2. 自動コード変換

過去数年間の BigQuery 移行サービスに対する投資のうち、特に大規模なものの一つが、15 種類以上のソースからコードを移行できるコード変換サービスです。今回、Google は Gemini 拡張コード変換の機能強化を発表しました。この機能はこれまでインタラクティブモードでのみ利用できましたが、今後は言わば Google 翻訳のようにコードを変換できるようになります。

Gemini 拡張コード変換はバッチモードと API モードでも利用可能となり、大規模な移行において役に立ちます。3 種類のモードすべてをサポートする新しい統合 Translation API と組み合わせて、まずバッチモードまたは API モードで大量のコードを変換し、その後インタラクティブモードを使ってファインチューニングとデバッグができます。

Gemini 拡張変換

Gemini でコードの前処理もできるようになったため、SQL だけでなく、XML 内に SQL が埋め込まれた ETL ジョブなど、その他の種類のコードも移行できます。つまり、完全にクリーンな SQL を送信する必要はありません。まだコンパイラに完全対応していないソースからもコードを変換できます。

最後に、コンソールのユーザーエクスペリエンスを改善しました。変換プロセスの各ステップで手順について説明があり、移行を完了するための次に取るべき最適なアクションが提案されます。

ユーザーエクスペリエンスの改善

このような機能強化によって、コード変換にかかる時間が大幅に短縮されると同時に、95% 超の精度を確保したまま、より効率的に大規模な移行作業を実施できるようになります。

3. データ、メタデータ、権限の移行

これまで、BigQuery 移行サービスでは Teradata と Amazon Redshift からの大規模なデータ移行をサポートしていました。このたび BigQuery 移行サービスは Teradata からの増分アップデート、Cloudera からのバッチおよび増分ファイルと権限の移行、Snowflake からのバッチおよび増分データの移行をサポートするようになります。これらはすべてプレビュー版です。移行されるデータはすべて、移行プロセスの一環で自動的に検証が行われます。

4. インテリジェントなエンドツーエンドの検証

移行プロセスの各ステップには、スキーマとデータ型のアップデートを組み込める、インテリジェントな検証メカニズムがまもなく導入されます。これまでの検証は静的データのチェックサム比較でした。検証にソースリネージを組み合わせることで、移行元の環境と移行先の環境の不一致を簡単にすばやく特定できます。この包括的なコード、データ、依存関係の検証により、ビジネスアプリケーションをそのまま維持して、段階的に移行できます。

データプラットフォーム移行の 4 つの段階それぞれにおいて、これらのイノベーションにより、移行プロセスを自動化すると同時にリスクを軽減し、確実な成果の実現と ROI の早期達成が可能になります。

お客様成功事例

お客様はミッションクリティカルなワークロードの移行に関して、BigQuery 移行サービスに信頼を置いています。BigQuery 移行サービスの利用は、前年比 3 倍に増加しており、何千ものお客様がこのサービスを使用して、ワークロードを BigQuery に移行しています。

「Databricks から BigQuery に移行し、当社独自のモデルを Google Cloud が提供するモデルと組み合わせることで、ML プロセスのパフォーマンスと効率が向上し、継続的な成長に向けてより良い体制を整えることができました。」- Yassir、AI 責任者 Hamdi Amroun 氏

「BigQuery により、VMO2 はこれまでにないスケーラビリティと柔軟性を手に入れました。データプラットフォームの可用性と稼働時間が改善し、その結果としてカスタマーエクスペリエンスが向上しました。また、すべての主要機能を Google Cloud に移行することで、TCO を同等のオンプレミスプラットフォームと比べて約 30% 削減できました。」- Virgin Media O2、データアーキテクチャ責任者 Vinay Pai 氏

次のステップ

データプラットフォームを BigQuery に移行される際は、いつでもサポートいたします。

BigQuery 移行サービスの詳細をご確認いただき、無料でお試しください。
Google Cloud コンサルティングにご連絡いただき、BigQuery 移行サービスに対応している移行パートナーを選べば、確実で費用対効果が高い成果を実現できます。
今すぐ BigQuery の移行インセンティブプログラムにご登録ください。Google Cloud クレジット、導入サービス、クラウド下り（外向き）クレジットなどの追加特典をご利用いただけます。

-データ分析担当プロダクト管理責任者 Mohit Virendra

-データ分析担当シニアプロダクトマネージャー Sajal Agarwal

データベースワークロードの調査と評価: Migration Center を使用した Google Cloud への移行

Fri, 07 Feb 2025 01:00:00 +0000

※この投稿は米国時間 2025 年 1 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。

組織は、より優れたビジネスおよび IT の成果を実現するために、パブリッククラウドの導入を進めています。しかし、移行やモダナイゼーションは複雑で、多面的な課題を引き起こします。そのため、インフラストラクチャとアプリケーションの現状を理解したうえで未来像を描き、その未来像を実現するために必要なことを見極めなければなりません。また、複数の関係者が多種多様なツール、プロセスを活用し、導入パートナーの力を借りる必要があります。しかし、ご心配にはおよびません。Google から朗報があります。

Google Cloud Migration Center は、現行のオンプレミス環境やクラウド環境から Google Cloud への移行を加速する統合プラットフォームです。クラウドへの移行を効率化するために設計されており、インテリジェントでデータドリブンなインサイトと実用的な推奨事項を提供します。これにより、組織は、最適な移行とモダナイゼーションの手法に関する重要な決定を下すことができます。

Migration Center では、IT インフラストラクチャの重要なコンポーネントであるサーバーとデータベースの両方を調査および評価できます。このブログ記事では、Migration Center 内で行うデータベースの調査と評価に焦点を当てます。

データベースの調査と評価は、主に以下の 3 つのフェーズで構成されます。

調査: オープンソースの収集スクリプトを使用して、データベース構成（メタデータのみ）を収集します。サポートされるデータベースは、Microsoft SQL Server、MySQL、PostgreSQL です。
技術的適合性評価: Cloud SQL や AlloyDB に対するソースデータベースの技術的な適合性を評価し、詳細な技術レポートを作成します。
費用予測: Cloud SQL や AlloyDB でのソースデータベースの実行にかかる全体的な費用を評価します。異なる移行シナリオ（複数リージョン、マルチゾーン、シングルゾーンなど）で、さまざまなサイズ適正化アルゴリズムを使用します。サーバーとデータベースの移行に予測される費用を 1 つのレポートにまとめて、インフラストラクチャの Google Cloud への移行にかかる全体的な費用予測を作成することもできます。

各項目について詳しく見ていきましょう。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7ff7c274e2d0>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

ソースデータベースの詳細の調査と収集

データベース構成と指標の収集: Microsoft SQL Server、MySQL、PostgreSQL のソースデータベース構成の収集には、オープンソースの収集スクリプトを使用します。

このスクリプトは、ソースシステム上で実行できます。データベースサーバーで直接実行するか、データベースにアクセスできるリモートサーバーから実行します。踏み台（ジャンプ）サーバーからスクリプトを実行する例を以下に示します。

code_block: <ListValue: [StructValue([('code', './collect-data.sh --collectionUserName <DB-Username> --collectionUserPass <DB-Userpassword> --hostName <Database-host> --port <DB-port> --databaseService <Db-servicename> --vmUserName <DB-Server-username>'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff7c1d45a10>)])]>

このスクリプトを実行すると、抽出された構成と指標のアーカイブ（データベースインスタンスごとに ZIP ファイル 1 個）が自動的に作成され、このアーカイブを Migration Center にアップロードできます。

注: データベースサーバーではなく、踏み台（ジャンプ）サーバーからスクリプトを実行している場合は、パラメータ「--vmUserName」を渡してホストの仕様の詳細を収集します。

調査アーティファクトを Migration Center にアップロードする

出力ファイルを生成したら、以下の手順に沿って、それらのファイルを Migration Center にアップロードしてプロダクトの評価を行います。

Google Cloud コンソールを開き、Migration Center のホームページにアクセスします。[探索] > [データ インポート] > [ファイルを追加] > [ファイルをアップロード] の順に選択します。
次のステップで、ファイル形式に [データベース インポート ファイル] を選択し、すべての DMA 出力 ZIP ファイルをアップロードして [ファイルをアップロード] をクリックします。
アップロードしたデータベースデプロイは Migration Center の [アセット] セクションで確認できます。

技術的適合性評価

Migration Center の [アセット] セクションで、検出されたすべてのサーバーとデータベースを確認できます。データベースのデプロイのリストには、検出されたデータベースの概要と、Cloud SQL および AlloyDB の適合性スコア（大まかな評価）が表示されます。

詳細な構成を確認するには、評価するソースデータベースをクリックし、利用可能なデータ（ソース論理データベース構成、ホスティングサーバー構成、パフォーマンスデータ、実現可能な Cloud プロダクト、適合性スコア、ターゲットインスタンスのサイズ）を選択します。

また、適合性スコア（[適合（作業が必要）] など）をクリックすると、その技術適合性レポートが表示され、ソースデータベースで特定されたサポートされていない機能、パラメータ、フラグを確認できます。これらについては、Cloud SQL や AlloyDB への移行時に対処する必要があります。

費用予測

Migration Center でクラウドのサーバーとデータベースの実行費用は、以下の 3 段階のプロセスで評価します。

評価対象のサーバーやデータベースのグループを作成する（複数可）。
評価の移行シナリオとして利用する移行設定を作成する（複数可）。
グループを最大 4 つの設定に割り当てて、TCO レポートを作成する。

1. グループを作成する

料金レポートを作成するには、費用予測の評価対象となるアセットを使用してグループを作成する必要があります。[探索] > [グループ] -> [グループを作成] の順に選択します。

グループとして評価する関連サーバーやデータベースを選択します。ソース環境（アプリケーション、環境など）に基づいてグループを作成することをおすすめします。

2. 移行設定を作成する

移行設定とは、基本的に、移行シナリオを表すために定義できるパラメータのセットのことです。複数の移行設定を作成し、それらを使用して TCO レポートに仮定のシナリオを生成することで、クラウド内のサーバーやデータベースの費用を比較できます。たとえば、高可用性やバックアップを有効にするオプションを使用して、Cloud SQL のさまざまなエディション用の移行設定を作成できます。

移行設定を作成するには、[Migration Center] > [探索] > [移行の設定] > [移行の設定の作成] の順に選択します。

3. サーバーとデータベースのワークロードの TCO レポートを作成する

[レポート] > [レポートの作成] > [TCO と詳細な料金レポート] の順に選択して、レポートの作成を開始します。
評価するアセットのグループ（複数可）を選択します。
各グループに入力として最大 4 つの移行設定を割り当てます。

TCO レポートでは、ソース環境の詳細、サーバーやデータベースの費用予測を確認できます。また、Google スライドに取り込んだり、CSV 形式でエクスポートしたりできます。以下は、データベースの費用予測の例です。

Google Cloud では、Migration Center により移行やモダナイゼーションプロジェクトの実行に必要な情報を提供し、お客様がこうしたプロジェクトに費やす時間、労力、費用を削減できるようにすることを目指しています。クラウドへの移行を進める際は、Migration Center と Google Cloud をぜひお役立てください。今すぐ Migration Center をご利用ください。詳細については、Migration Center および高速評価および移行プログラム（RAMP）のウェブページをご覧ください。

データマネジメントスペシャリスト Arkapravo Banerjee
シニアプロダクトマネージャー Nimrod Shavit

クラウド移行を簡単に: AWS から Google Cloud への移行ガイド

Wed, 05 Feb 2025 02:10:00 +0000

※この投稿は米国時間 2025 年 1 月 28 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud にワークロードをデプロイするお客様はますます増えています。しかし、ワークロードが別のクラウドにある場合はどうなるでしょうか。ワークロード、データ、プロセスの移行を計画、設計、実装するのは簡単な作業ではありません。ダウンタイムの回避（ゼロダウンタイム移行とも呼ばれます）など、移行に影響する要件を満たす必要がある場合はさらに難しくなります。さらに、移行によっては、ワークロードを新しい環境に適応させるなど、ある程度のリファクタリングが必要になります。特に、サードパーティソフトウェアやレガシーソフトウェアが関係する場合は、一連の課題が生じます。また、新しい環境で機能するように、デプロイや運用プロセスを調整する必要がある場合もあります。

そして、移行したくないワークロードがある場合はどうなるでしょうか。すべてを Google Cloud に移行しない場合でも、マルチクラウドアプローチを採用すれば、それも移行であることに変わりはありません。多くの組織は、一部のワークロードを現在のクラウドプロバイダに保持し、他のワークロードを Google Cloud に移行することを選択しています。

複数のクラウドにわたるワークロードの管理、特にワークロードの分散やクラウド間の接続に関しては、独自の課題がありますが、マルチクラウド戦略を適切に実施することで、柔軟性を維持し、ベンダーロックインを回避して、システムの復元力を向上させることができます。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7ff7c1ed3190>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

スムーズに移行していただけるよう、アマゾン ウェブ サービス（AWS）から Google Cloud への移行に関する一連のリファレンス ガイドを公開しました。これらのガイドは、AWS から Google Cloud への移行プロセスの設計、計画、実装を支援することを目的としています。また、移行の機会を評価中で、移行がどのようなものになるかを調べたい意思決定者にも役立ちます。たとえば、次のような移行プロセスを対象とするガイドを用意しています。

AWS コンピューティング サービスから Google Cloud へ

AWS データ ストレージ サービスから Google Cloud へ

Amazon S3 から Cloud Storage に移行する

AWS データベース サービスから Google Cloud へ

AWS データ分析サービスから Google Cloud へ

Amazon RedShift から BigQuery に移行する

AWS インテグレーション サービスから Google Cloud へ

AWS Step Functions から Workflows に移行する

これらのガイドは、AWS から Google Cloud への特定の移行ユースケースにおける Google Cloud 移行フレームワークのフェーズ（評価、計画、移行、最適化）に沿っています。

このアプローチは、移行計画の各タスクに取り組む際に、影響が大きく、リスクの高い移行を回避するのに役立ちます。この移行計画の各タスクを完了する方法の詳細については、AWS から Google Cloud への移行ガイドをご覧ください。

次のステップ

AWS から Google Cloud への移行を始める方法を今すぐ学びましょう。
サポートが必要な場合のために、ワークロード、データ、プロセスの大規模な移行に役立つリソースをいくつかご用意しています。
より視覚的なガイドが必要な場合は、新しい移行ガイドとチェックリストをダウンロードしてください。

さっそく始めましょう

詳しく知りたい場合は、Google Cloud への移行に関する詳細をご覧ください。また、お客様が学習、構築、運用し、成功を収めるうえで Google Cloud コンサルティングがどのようにお役に立てるかについてもご覧ください。

謝辞: クラウドソリューションアーキテクト Alex Cârciu、クラウドソリューションアーキテクト Xiang Shen

-クラウドソリューションアーキテクト Marco Ferrari
-ソリューションマネージャー Giuseppe Lino

Oracle ベースアプリケーションを Google Cloud に移行し、運用を簡素化する

Wed, 05 Feb 2025 01:19:00 +0000

※この投稿は米国時間 2025 年 1 月 24 日に、Google Cloud blog に投稿されたものの抄訳です。

昨年、Google Cloud と Oracle は、企業のクラウドトランスフォーメーションを加速させる戦略的パートナーシップを結び、Google Cloud 環境に Oracle の堅牢なデータベース機能を統合できるようにしました。

このパートナーシップは、Oracle データベースだけでなく、Oracle データベースを使用して実行するアプリケーションにも適用されます。つまり、お客様は既存の Oracle データベースアプリケーションを Google Cloud に移行することで、Google Cloud のパフォーマンス、安定性、セキュリティという利点を享受できます。また、Oracle はデータベース以外にも、移行したいと思うようなエンタープライズアプリケーションやミドルウェアアプリケーションも多数提供しています。Google Cloud のサービスとインフラストラクチャ上で Oracle のデータベースとサービスを使用して、新しいクラウドネイティブアプリケーションを構築し、デプロイすることももちろんできます。

このブログ投稿では、Oracle アプリケーションとデータベースを Google Cloud に移行する方法をご紹介します。コンテナ化と GraalVM がパフォーマンスとスケーラビリティの最適化にどのように役立つかに重点を置きながら、フルマネージドサービスからカスタマイズされたオプションまで、さまざまな移行パスについて詳しくご説明します。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud データベースを試用するための 300 ドル分の無料クレジット'), ('body', <wagtail.rich_text.RichText object at 0x7ff7d40b17d0>), ('btn_text', '無料で構築を始める'), ('href', 'http://console.cloud.google.com/freetrial?redirectPath=/products?#databases'), ('image', None)])]>

Google Cloud における Oracle データベース

Google Cloud では、フルマネージドから高度にカスタマイズされたものまで、Oracle ワークロード向けの移行パスが複数用意されているため、ニーズに応じて柔軟に対応できます。

高パフォーマンス:

Google Cloud における Exadata Cloud Service: Oracle の高パフォーマンスハードウェアである Exadata を、Google のデータセンター内で直接稼働させることができます。可能な限り最高の処理速度と処理性能を必要とする、要求の厳しいワークロードに最適です。

フルマネージド:

Google Cloud 上の自律型データベース: Google Cloud がすべてを処理するため、Oracle の運用が非常に簡単になります。プロビジョニング、パッチ適用、スケーリング、バックアップ、復元など、必要不可欠な管理タスクがすべて自動化されるため、企業にとって最も重要なことに集中できます。

上記の移行パスはいずれも高度なマネージドサービスであるため、Oracle データベースインスタンスに変更を加える必要が（あったとしても）ほとんどなく、物理的な移行自体も Google のサポートチームが実施できます。

柔軟なオプション:

ただし、こうした柔軟なオプションのいずれかを選択する場合でも、新しいクラウドベースの環境から可能な限り最高のパフォーマンスを得るには、検討すべきことがいくつかあります。

Compute Engine: 仮想マシン上で Oracle を実行し、制御を可能にして柔軟性を提供します。既存システムの「リフト＆シフト」の移行に適しています。
Google Kubernetes Engine（GKE）: Oracle の Kubernetes 向けデータベースオペレーターである OraOperator を使用すると、Oracle のプラグイン可能なデータベースをデプロイできます。このユースケースについては、以下で詳しくご紹介します。

Oracle ベースアプリケーションのコンテナ化

このパートナーシップは、Google Cloud での Oracle アプリケーションのデプロイと管理に必要な柔軟性を企業に提供し、移行、モダナイゼーション、イノベーションを加速させることを目指しています。その鍵となるのがコンテナ化のサポートです。これにより、開発チームに高いレベルのアジリティとスケーラビリティがもたらされます。Oracle ベースアプリケーションが Java、Python、.NET で構築されているか、WebLogic で実行されているかにかかわらず、コンテナは整合性のある隔離された環境を提供し、プログラミング言語やフレームワークが持つ根本的な複雑さを取り除きます。

Google Cloud にはコンテナベースのランタイムが幅広く用意されており、その中から選択できます。

Google Kubernetes Engine（GKE）は、Google Cloud 上で多様なワークロードのデプロイと管理を簡素化する、汎用性の高い強力なコンテナオーケストレーションプラットフォームです。複雑なセットアップやマイクロサービスアーキテクチャを実行する企業向けに設計された GKE は、Google のグローバルネットワークと高パフォーマンスな VM を活用して、コンテナをスムーズかつ確実に実行できるよう最適化されたインフラストラクチャを提供します。自動スケーリングとノード自動プロビジョニングにより、コストとパフォーマンスの両方を最適化し、リアルタイムの需要に合わせてリソースを自動的に調整します。さらに、GKE はコンテナランタイムを幅広くサポートし、高度なネットワーキング機能を備えているため、基本的なウェブアプリケーションからあらゆる言語で記述された要求の厳しい ML ワークロードまで、すべてを効率的に処理できるよう支援します。

次に、コンテナ化されたアプリケーションをデプロイするための、フルマネージドサーバーレスプラットフォームの Cloud Run があります。需要に応じて自動的にスケールする必要のあるアプリケーション向けに設計されているため、コードまたはコンテナイメージを提供するだけで、後は Cloud Run が処理します。Cloud Run はトラフィックに応じてリソースを自動的にスケールアップ / スケールダウンするため、アプリケーションがアクティブにリクエストを処理しているときにしか料金は発生しません。Cloud Run を活用してプロビジョニングやスケーリングのようなサーバー管理作業をなくすことにより、ユーザーはアプリケーションの構築やデプロイに集中できます。これは、マイクロサービス、API、ウェブアプリ、イベントドリブン関数に適しています。さらに、Cloud Run のベースイメージの自動更新により、コンテナに最新のセキュリティパッチやオペレーティングシステムのアップグレードの恩恵がもたらされるため、脆弱性を最小限に抑えてメンテナンスのオーバーヘッドを大幅に削減できます。

何より、Oracle ベースのアプリケーションをオープンスタンダードでコンテナ化するということは、前もってパスを選ぶ必要がないということです。Kubernetes を管理したくなければ、Cloud Run を使って始めましょう。後でさらに柔軟性が必要となったら、GKE に簡単に移行できます。どちらのサービスも標準的な OCI コンテナを活用し、CNCF によってサポートされているため、現在も今後も、コンテナ化されたアプリの完全な相互運用性とデプロイ選択の自由を得られます。

コンテナ化した Oracle データベースの実行

Google Cloud 内の Exadata 上で Oracle ワークロードを実行することが基本ですが、それが不可能である場合は、GKE 上での Oracle の実行を検討することをおすすめします。

GKE 上での Oracle データベースの実行は、ワークロードが非 RAC および非 Exadata である場合や、特定のリージョンで Exadata がサポートされていない場合に適しています。
これは、DBaaS 戦略を採用し、OraOperator を使用してライフサイクル（デプロイ、更新、削除）を実現できる多数の Oracle データベースを所有している企業にとって、効果的なソリューションとなります。
最新の DevOps ワークフローと継続的デプロイ戦略への統合を目的に設計されたこのアプローチは、データベースを迅速にスピンアップまたは破棄する必要がある場合に便利です。

このような背景から、前述の OraOperator はマルチテナンシーをサポートしています。これは、GKE 上で Oracle データベースを実行する際に役立つ機能です。隔離された複数のデータベースを同一の GKE クラスタ上で実行できるため、リソース使用率の向上とコスト削減に貢献します。

Java アプリケーションの強化

Oracle アプリケーションの多くは Java で記述されています。Oracle GraalVM は、ネイティブ Java アプリケーションを作成します。このツールは事前（AOT）コンパイルを使用して、Java バイトコードをネイティブ実行可能ファイルに直接変換します。実行時に Java 仮想マシン（JVM）に依存しないようにすることで、これらのアプリケーションははるかに高速に起動し、リソース（CPU とメモリ）の消費量は減少します。基本的に GraalVM は、Java が C や C++ といった言語のように動作できるようにし、クラウドネイティブなデプロイにおけるマイクロサービスやサーバーレス関数のような、リソースに制約のある環境に最適なスタンドアロン実行可能ファイルを生成します。

GKE 上で Oracle アプリケーションを実行する場合は、Java ネイティブイメージを使用することを強くおすすめします。Java ネイティブイメージを使用すると、VM 内から Java アプリケーションを実行する場合と比較して、リソース使用率を高度に最適化できます。その理由は、ネイティブイメージはフットプリントが小さいからです。これにより、ワーカーノードごとにより多くの Pod を実行し、GKE クラスタリソースを最大限に活用できるため、コストを削減できる可能性があります。Pod の起動レイテンシの短縮は、デプロイの展開時間と復元時間の短縮にも貢献し、アプリケーションのアジリティの向上につながります。

最後に、Java ネイティブイメージを使用すると、以下のような機能によって GKE クラスタ内のコンテナのセキュリティポスチャーを強化できます。

Binary Authorization によるイメージの署名と検証
実行中のコンテナの Java、Go、JavaScript、Python の言語パッケージのスキャンと脆弱性検出を提供する、Advanced Vulnerability Insights
サンドボックス環境を使用して Java ネイティブイメージに安全かつ隔離された環境を提供する、Artifact Registry に組み込まれた脆弱性スキャン
潜在的な攻撃対象領域を縮小し、脆弱性のリスクを最小限に抑える、Java ネイティブイメージに必要な依存関係のみを含んだ最小限のベースイメージ

その一方、Java ネイティブアプリケーションを Cloud Run 上で実行するとほぼ瞬時に起動するため、最初のリクエストのレイテンシを最小限に抑え、全体的な応答性を向上させることができます。Cloud Run の起動時 CPU ブースト機能は、インスタンスの起動時と起動後の 10 秒間、追加の CPU を提供します。

さらに、Cloud Run は、イベントによって関数がトリガーされるイベントドリブンアプリケーションにも適しています。これは、ネイティブ Java イメージの一般的なユースケースです。Java Runtime Environment がなくても、イベントに迅速に応答できます。

最後に、多くの組織が Java 21 への移行を希望しています。Java 21 を採用する主な理由は、継続的な更新、セキュリティパッチ、向上したランタイムパフォーマンス、新機能、テクニカルサポートを長期間保証することが LTS（長期サポート）で定められているという利点にあります。古い Oracle アプリケーションを GKE または Cloud Run に移行することは、同時に Java 21 にモダナイズする良い機会でもあります。

パートナーによるサポート

Oracle データベースとアプリケーションを Google Cloud に移行することは大変なタスクですが、単独で行う必要はありません。Google Cloud は、経験豊富な Oracle のエキスパートと連携して、移行をスムーズに成功へと導きます。こうしたパートナーは、Oracle のテクノロジーに関する深い知識と実績ある方法論を提供し、プロセスを通じて企業を支援します。Google のパートナーエコシステムにご連絡ください。Google Cloud 上での Oracle ワークロードの成功を加速させるお手伝いをいたします。

-アプリケーションプラットフォーム担当 EMEA プラクティスソリューションリード Darren Evans

IBM Power for Google Cloud を改めてご紹介

Tue, 10 Dec 2024 01:40:00 +0000

※この投稿は米国時間 2024 年 12 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。

2020 年 1 月、Google は IBM Power Systems for Google Cloud の提供を発表しました。当時はパンデミックの影響でクラウドコンピューティングの導入が加速していましたが、多くの大企業は依然として重要なワークロードの取り扱いに苦慮していました。そうしたワークロードの多くは、Enterprise IBM Power プラットフォームで実行されていました。

2022 年初め、Google は IBM Power ワークロードを扱うお客様へのサポートを拡大するために、この市場で深い専門知識を持つ Converge Technology Solutions との連携を強化しました。すでに Google の重要なパートナーであった Converge によって、IBM i オペレーティングシステムへの完全対応が実現すると同時に、Google Cloud へのネットワークの接続性が強化されて IBM Power for Google Cloud サービスがアップグレードされました。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7ff7d4197650>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

現在、Converge Enterprise Cloud with IBM Power for Google Cloud（IP4G）は IBM Power の 3 つの主要な環境である AIX、IBM i、Linux のすべてに対応しています。また、新たに 4 つのリージョンにおいて本番環境でのご利用が可能になりました。具体的には、カナダの 2 つのリージョンと欧州、中東、アフリカ（EMEA）の 2 つのリージョンが追加され、合計で 6 つのリージョンで利用可能になりました。

北米

us-east4（北バージニア）

us-central1（アイオア）

northamerica-northeast1（モントリオール）

northamerica-northeast2（トロント）

欧州、中東、アフリカ

eu-west3（フランクフルト）

eu-west4（オランダ）

このような発展と Converge による専門的サポートのおかげで、顧客環境における IP4G の導入は急増しました。

「Infor では IP4G を当初から利用していました。それから数年経った今も、IP4G で顧客向けにミッションクリティカルな　IBM Power ワークロードを実行しています。IP4G の可用性とパフォーマンスは当社の要件を余裕で満たし、それ以上のものを提供してくれるので、その利便性全般にとても満足しています。」- WMS 開発担当バイスプレジデント Scott Vassh 氏

IBM Power ワークロードのクラウドへの移行をお考えですか？カスタムクラウドプランに関するご質問や詳細については、power4gcp@googlegroups.com までお問い合わせください。いただきましたメールは Converge と Google Cloud の担当者のみが拝読したうえで直接ご連絡を差し上げます。先にもう少し詳しくお知りになりたい方は、データセンターの移行とメインフレームのモダナイゼーションのソリューションウェブページをご覧ください。

ー Google Cloud パートナー エンジニアリング、テクニカル ソリューション コンサルタント Andy Waddell

ー Converge Technology Solutions、北米担当 CTO Greg Rhoades 氏

Beam の Google Cloud への移行で行政機関のセーフティネットプログラムの効果が向上

Thu, 06 Jun 2024 03:00:00 +0000

※この投稿は米国時間 2024 年 5 月 29 日に、Google Cloud blog に投稿されたものの抄訳です。

Beam では、次世代の社会的デジタルセーフティネットを構築しています。当社のプラットフォームは、州政府、地方自治体、コミュニティベースの組織、大学が公的給付金や現金支援プログラムを管理するために使われています。当社のパートナーは、負担の少ない申請プロセスを進め、時間のかかる適格性判断のプロセスに対処し、社会的に弱い立場の人々に不可欠な支払いを行うことができます。

近ごろ、当社はそのインフラストラクチャ全体をダウンタイムやユーザーへの影響なく AWS から Google Cloud に移行しました。さらに、最新のクラウドテクノロジーを活用するために、アプリケーションのさまざまな側面やエンジニアリングのプロセスも変革しました。当社は、クラウドの料金を半分に抑えながら、より効果的で環境に優しいサービスを提供できるようになりました。この投稿では、Beam の移行戦略、Google Cloud への移行により当社が期待したメリット、主な成果と重要ポイントについてご説明します。

アーキテクチャに関する決定事項

Google Cloud に移行する際、Beam の全体的なアーキテクチャ戦略は、製品差別化技術の統合を最も効果的に加速し、スケーラブルでありながらわかりやすいクラウドインフラストラクチャを提供し、エンジニアリングチームの管理による負担を最小限に抑えるサービスを選択することでした。

エンジニアには、以前使用していた時代遅れで非効率的なインフラストラクチャをサポートするのではなく、行政機関のパートナーが必要とする機能を備えたユーザー中心の製品を構築することに専念してほしいのです。このような優先事項が、Google Cloud サービスの採用を決定する要因となりました。

Cloud Run

Beam のプラットフォームは、ユーザーへのサービスを提供するために相互作用し、個別にスケーリングする必要がある多くのコンテナ化されたアプリで構成されています。このプラットフォームは、以前は自己ホスト型の AWS Kubernetes クラスタで実行していましたが、エンジニアリングチームでは、クラスタ管理の負担が妨げになっているという結論に至りました。AWS を使用して Kubernetes を実装しても、スケーリングに必要な管理のしやすさやデベロッパー指向の UI は提供されませんでした。

そこで真価を発揮したのが Google Cloud のマネージドコンテナサービスです。Cloud Run は、スケーラビリティが高く、相互関連性がある多数のコンテナサービスを、可能な限り最小限の管理負担でデプロイしたいと考えていた当社の小規模チームに最適でした。今後もっと柔軟性が必要になった場合は、サービスを簡単に GKE に再デプロイすればよいのです。また、Cloud Run はサイドカーとマルチコンテナサービスをサポートするようになったため、このフルマネージドコンテナサービスを採用しない理由はありませんでした。

AlloyDB for PostgreSQL

Beam は、コアとなるデータベースには Google Cloud の PostgreSQL 対応フルマネージドデータベースが当社のニーズに最適だと考え、PostgreSQL と AlloyDB for PostgreSQL を使用しています。AlloyDB は、移行を開始した時点では比較的新しいサービスでしたが、当社は障害復旧や大量のトラフィック報告のためにゾーンおよびリージョン間でレプリケートできるスケーラビリティの高いデータベースを求めていたため、その条件を満たす AlloyDB はぴったりでした。さらに、AlloyDB の Query Insights ダッシュボードは、データベース管理（DBA）のギャップを解消し、アプリケーションのパフォーマンスを調整するのに役立つように思えました。最終的に、当社は専任の DBA のサポートや管理の必要がないデータベース製品を必要としていました。そうすることでチームがイノベーションに専念できるからです。

ML と AI サービス

ML と AI のテクノロジーをめぐる向上のペースの加速は、多大な期待と不安の両方を生み出しています。AI は、責任を持って実装されれば、公共サービス提供のための事務作業時間を短縮し、行政機関が国民に対応する方法に革命をもたらすことができます。しかし、不用意に AI を使えば、危害やバイアスが増幅され、社会的に弱い立場の人々がさらに取り残される可能性があります。

このような厳しい環境のなかで、Beam の責任ある AI 戦略は、Vertex AI などの、最先端の Google Cloud AI によって実現されています。当社が提供する AI は、ドキュメントやケースの履歴から適格性の判定プロセスを合理化することで、申請者の管理の負担とプログラム管理上のオーバーヘッドを根本的に軽減することを目的としています。Google Cloud により、責任と公平性の検討に、他の方法よりも多くの時間を割くことができます。

移行

私はこれまでのキャリアにおいてインフラストラクチャの大規模な移行を何回か行いましたが、Beam の AWS から Google Cloud への移行は最もスムーズでした。これは Beam のすばらしいエンジニアリングチームのおかげでもありますが、Google Cloud によるクラウドからクラウドへの移行が非常に簡単であるおかげでもあります。

その方法の概要をご紹介します。

すべてのインフラストラクチャを Terraform で立ち上げることで、すべてを文書化し、再現可能にし、今後も互換性があるようにしました。
Database Migration Service を使用して、AWS の PostgreSQL データベースから AlloyDB インスタンスへの継続的なレプリケーションを作成しました。
一方、デベロッパーは非同期のジョブキューイングのための Pub/Sub や、ファイルアップロードのための Cloud Storage などで、サービスアーキテクチャのモダナイズに注力しました。
Google Cloud への移行中に、DevOps プロセスを GitHub を中心に再構築しました。
新しい CI / CD パイプラインの一部として、コンテナサービスの Cloud Run へのデプロイに GitHub Actions を使用しました。
エンドユーザーの低レイテンシを維持しながらスケーリングできるように、Cloud Run サービスで負荷テストを実行しました。
カットオーバー当日、データベースへの書き込みを一時停止して、DNS を AWS エンドポイントから Cloud Run URL に切り替えました。
以前のデータベースと AlloyDB での継続的なデータ同期により、ユーザーは切り替え中もサービスが停止したりデータが失われることはありませんでした。また、Beam も、より軽量かつ最新のクラウドプラットフォームでアプリケーションを実行できることで負担が大幅に減りました。

主な成果と重要ポイント

半年がたち、当社は Cloud Run と AlloyDB を中心に再構築されたプラットフォームのパフォーマンスに大変満足しています。これらの改善により、人材開発、託児サービス、障害復旧、所得保証、住宅といったプログラムの分野に数億ドルを分配する予定です。

Cloud Run はとにかく便利です。サービスはトラフィックパターンに一致するようにスケールアップとスケールダウンを実施し、デプロイは GitHub Actions と yaml に保存されたコンテナサービス定義を使用して簡単に管理できます。異なるアプリケーションリビジョン間でトラフィックをルーティングするなど、手動による介入が必要な場合、Cloud Run UI は以前使用していたコンテナオーケストレーションツールよりもはるかに優れています。

AlloyDB にはまるでデータベースの健全性を維持するために働く DBA のチームが存在するようです。ビジネスが成長しても、レイテンシは驚くほど低いままです。コンソールで数回クリックするだけで、データ分析とレポート作成のニーズ用に別の読み取り専用プールを作成し、異なる時点のバックアップを新しいクラスタに復元して、以前のバージョンのユーザーデータを取得できました。また、確約利用割引を購入することで、今後 3 年間のデータベースの費用を半分に抑えました。

その他にも次のようなメリットがありました。

セキュリティ: Google は、Beam とその行政機関パートナーにとって重要な分野であるセキュリティを優先しています。たとえば、すべての Google Cloud サービスでのデフォルトでの保存データの暗号化、Workload Identity による簡単なキーなしのサービスアカウント、Security Command Center は、小規模ながらセキュリティ重視のエンジニアリングチームを強化するいくつかの特長です。
デベロッパー指向: 当社のデベロッパーは、Google Cloud のドキュメントはわかりやすく、SDK の統合は他のクラウドプロバイダに比べて簡単かつ迅速だと感じています。
イノベーションの実現: 当社の部門横断型チームは、Cloud Run やその他のサービスを基盤としてパイロットのパートナー向けの効果的な AI モデルを構築できました。
社会的配慮と環境に対する責任: 当社は、技術的な理由以外でも、Google Cloud を戦略的クラウドパートナーにしたことを誇りに思います。Google Cloud のサステナビリティ戦略は、主要なクラウドプロバイダのなかで最も先進的であり、Google の社会活動は、Beam のミッション、そして当社のパートナーや投資家の価値観と一致しています。

最も重要なのは、クラウドの月額合計費用を半分に抑えながら、当社とパートナーにこれらすべてのメリットがもたらされたことです。

Google Cloud がスタートアップにどのように役立つかについてや、最近立ち上げられた Startup Learning Center のリソースを活用する方法についての詳細もご確認ください。

Beam、クラウド運用担当ディレクター James Osborn 氏

Facturation.net が週末だけで Azure VM を Google Cloud に移行できた理由

Tue, 28 May 2024 01:00:00 +0000

※この投稿は米国時間 2024 年 5 月 22 日に、Google Cloud blog に投稿されたものの抄訳です。

Facturation.net は、請求書の作成および請求を行うクラウドベースのソフトウェアを提供するカナダの大手プロバイダです。カナダに多くの顧客を抱える同社の使命は、医師やその管理スタッフによる医療費の請求作業を支援し、カスタマイズされたソフトウェアとサービスを提供することです。

「ビジネスが成長するにつれ、既存の Azure インフラストラクチャでは当社が抱えるニーズを満たせないことが分かってきました。費用と複雑さが増すなかで、よりスケーラブルで費用対効果の高いソリューションはないかと考えていました。いくつかの選択肢を検討した結果、本番環境の VM を Google Cloud に移行することに決めました」と Facturation.net の CTO、Jacob Verret 氏は述べています。

課題としては、Azure にある本番環境の Facturation.net 仮想マシン（VM）を週末にかけて移行できるかどうかを見極めることでした。それも、本番環境のワークロードに支障をきたすことなくです。Facturation.net は、シンプルで信頼性が高く、費用対効果の高いソリューションを必要としていました。

さまざまな選択肢を検討した結果、Google Cloud の Migrate to Virtual Machines（M2VM）を採用することに決めました。

Google Cloud Migration Center に統合されているツールである M2VM を使用すると、ものの数分で VM を VMware、AWS、Azure 環境から Compute Engine に移行できます。M2VM なら VM を安全、高速かつ大規模に移行できます。

M2VM はシンプルで使いやすいように設計されています。ユーザーフレンドリーなインターフェースを備えており、特別なスキルや専門知識は必要ありません。このサービスには、クラウド間の移行に最適な選択肢となる次のようないくつかの利点があります。

高速かつ効率的な移行: M2VM は VM を高速かつ効率的に移行できる高性能なデータ転送エンジンを使用しています。
実証済みの信頼性: Google Cloud のお客様は M2VM を使用してオンプレミスとクラウド環境から数十万の VM を移行してきました。
エンタープライズ グレードのセキュリティ: M2VM は業界標準のセキュリティプロトコルを使用して移行中のデータを保護します。
費用対効果の高さ: マネージドサービスである M2VM は費用対効果の高いソリューションで、クラウド移行にかかる費用を節約できます。関連する Google リソースのほかに費用は発生しません。

Azure VM から Google Cloud への移行

Facturation.net チームは M2VM を使用して VM を移行するために、次のような段階的なアプローチを採用しました。

移行する VM のリスト、ターゲットとなる Google Cloud プロジェクト、希望する移行開始時刻と移行終了時刻を含む詳細な移行計画を作成しました。また、最新のセキュリティパッチのインストールや不要なサービスの無効化など、VM の移行準備が適切に行われていることも確認しました。
Google Cloud コンソールで移行プロジェクトを作成して M2VM を有効にし、Azure ソースを追加して、Google Cloud 上のターゲットプロジェクトを移行プロセス用に定義しました。
移行プロセスを開始するために、移行対象の VM とターゲットとなる Google Cloud プロジェクトを選択しました。その後、M2VM は各 VM のレプリケーションジョブを作成しました。M2VM コンソールでレプリケーションジョブの進行状況をチームでモニタリングしました。
レプリケーションジョブが完了すると、移行した VM をテストして正常に動作していることを確認し、カットオーバーを実行して、Azure VM から新しい Google Cloud VM にトラフィックを切り替えました。
移行が完了すると、不要になった Azure リソースをクリーンアップしました。

Google Cloud への迅速、柔軟、安全な移行

「M2VM を使用した移行の結果には非常に満足しています。プロセスはシンプルで、直感的なユーザーインターフェースのおかげで問題なく VM を移行できました。そのうえ、信じられないほど高速でした。本番環境にあるすべての VM を週末だけで Google Cloud に移行できました」と、移行作業を主導した Facturation.net のシニアクラウドアーキテクト、Alexander Grange 氏は述べています。

さらに、移行プロセス中のデータの損失や破損は発生しませんでした。M2VM は業界標準のプロトコルを採用しているため、Facturation.net チームは移行プロセス中に会社のデータが安全であると確信していました。移行の費用も非常にリーズナブルだったため、Facturation.net はクラウド移行にかかる費用を節約できました。

まとめると、Migrate to Virtual Machines と Google Cloud チームのおかげで、Facturation.net は本番環境に影響を及ぼすことなく、Azure から Google Cloud への移行を迅速に進めることができました。

-スタッフテクニカルソリューションコンサルタント Eitan Eibschutz
-カスタマーエンジニア Xavier Tremblay

データワークロードのモダナイゼーションと移行の比較

Thu, 02 May 2024 03:00:00 +0000

※この投稿は米国時間 2024 年 4 月 25 日に、Google Cloud blog に投稿されたものの抄訳です。

クラウドへの移行には、データ、アプリ、インフラストラクチャなどのデジタルアセットをクラウド環境へ移行することが含まれます。特に、データとデータプラットフォームはアプリケーション、分析、AI / ML などのワークロードに必要不可欠であるため、オンプレミスや他のクラウドプロバイダなど、他のプラットフォームから既存のデータを移行するのが一般的です。ほとんどの組織にとって最初の課題となるのが、データを新しいプラットフォームに移行する際のデータの処理方法を決めることです。

単純な移行（リフト＆シフトとも呼ばれます）を行うべきでしょうか？それとも、プラットフォームをモダナイズして、最新のクラウドテクノロジーを活用できるまったく新しいソリューションを構築することを検討すべきでしょうか？この投稿では、データワークロードのモダナイゼーションと移行のアプローチについて説明します

移行とモダナイゼーション: 違いは何か

一般的には、移行にはクラウドへのデータの移動が含まれます。最もよく見られる移行プロセスは、次の 2 つのカテゴリに分類されます。

オンプレミスからクラウドへの移行: ローカルサーバーやデータセンターからクラウドプロバイダへの運用の移行です。移行のユースケースとして一般的であり、企業はスケーラビリティ、柔軟性、費用削減といったクラウドのメリットを活用することを目指します。
クラウドからクラウドへの移行: クラウドプロバイダを切り替えることで、イノベーション、機能、費用、パートナーシップの面でさらなる価値を実現します。

一方、クラウドのモダナイゼーションは、既存のアプリケーション、データ、インフラストラクチャを変革して、クラウドコンピューティングによってもたらされるメリットをさらに活用するための戦略です。企業が成功するには、データを管理、分析するための統合された、柔軟かつスケーラブルで費用対効果に優れたデータプラットフォームが不可欠です。たとえば、フルマネージドデータベースサービスを利用すれば、パフォーマンスとスケーラビリティを強化して、クラウドでの全体的な運用コストを削減できます。クラウドファーストのデータレイクとデータウェアハウスを使った最新の分析機能にアクセスして、顧客データについてのより詳しい分析情報が得られます。

通常、クラウドのモダナイゼーションを検討されているのは、デジタルトランスフォーメーションの達成、高度なクラウドサービスの活用、継続的な改善と開発のサポート、生成 AI などの新たなテクノロジーの可能性の解放といったビジネス戦略を掲げているお客様です。

たとえば、以下を実現しようとしている場合は、クラウドのモダナイゼーションを検討するでしょう。

サーバーレスデータプラットフォーム、マイクロサービス、コンテナ化などのクラウドネイティブアーキテクチャを使用して、アプリケーションとインフラストラクチャを見直し、再構築する。
サーバーレスデータベース、データレイク、ML プラットフォーム、分析ツール、クラウド運用などのマネージドサービスを利用してタスクを自動化し、新機能を活用できるようにして、市場投入までの時間を短縮する。
DevOps の原則と CI / CD 手法を採用して、クラウド環境のイテレーションを行って最適化する。
スケーラブルなデータマネジメント、十分なコンピューティング能力、事前構築された AI サービスを備えた、生成 AI ユースケースの開発とデプロイのための強固な基盤を提供する。
自己管理のデータベースではなくマネージドサービスを通じて、費用を削減し、セキュリティとコンプライアンスの体制を強化し、信頼性と生産性を向上させる。

移行に関する決断をする際の重要な要因

お客様にとって、移行するかモダナイズするか、ましてや何を移行するかの決断は困難なプロセスであり、時には手に負えない場合もあります。

とはいえ、オンプレミスのデータベースをスケールするのは難しく、高額になることがほとんどです。そのため、データベースをクラウドベースのサービスに移行してモダナイズすることで、スケーラビリティが向上して大きなデータ列を処理できるようになり、オンデマンドのコンピューティングリソースを通じたパフォーマンスの向上が保証されます。さらに、クラウドソリューションによってガバナンスとセキュリティのより適切な選択肢が得られ、運用コストの削減が企業に大きな影響を与える可能性があります。

新しいソリューションの開発とデプロイも、クラウドネイティブの CI / CD プロセスの恩恵を受けられます。複数のチームに対して一元化されたクラウド環境を提供することで、データサイロを解消し、チーム間のコラボレーションを妨げる制限を取り除くことが容易になり、開発とデプロイのサイクル中の生産性が向上して、エラーが減少します。

では、組織のデータワークロードに最適なアプロ―チを決定するにはどうすればよいでしょうか？

次の 6 つの要素が、組織にとって役立つことがわかっています。

企業戦略: 企業戦略は、移行戦略を形作るうえで決定的な役割を果たします。移行プロセスについて最終決定を下す前に、合併や買収、地理的拡大、ベンダーロックインなどの要因がクラウド要件にどのような影響を与えるかを慎重に検討することが重要です。
費用に関する考慮事項: データセンターを所有して運用するには多額の資本的支出が必要ですが、クラウドホスティングでも、プロビジョニングとリソースの使用量を適切に監視しないと、予想外の料金になる可能性があります。特にクラウド間で大量のデータを移動する場合は、データの下り（外向き）料金を考慮する必要があります。
セキュリティとコンプライアンス: セキュリティモデルの複雑さとコンプライアンス要件は、移行戦略の決定において重要な要素となります。HIPAA、GDPR、PCI などの地方および政府の規則や規制は、移行プロセスがさまざまな種類のワークロードにどのように機能するかに大きな影響を与える可能性があります。
パフォーマンスと信頼性: クラウドへの移行には、ダウンタイムがわずかで信頼性の高いクラウドリソースへの期待が伴いますが、移行を計画しているサービスのレイテンシ、スケーラビリティ、ダウンタイムの要件を常に理解しておく必要があります。ほとんどのクラウドサービスは、3 桁、4 桁、または 5 桁（99.9%、99.99%、または 99.999%）の可用性 SLA を提供していますが、それでも、移行計画の決定要因となり得る計画的ダウンタイムやメンテナンスの時間枠は依然として存在します。
特長と機能: 企業の成長に伴って、クラウドのニーズも進化します。時間の経過とともに、ビジネスの拡大をサポートするための追加の機能、サービス、スケーリングが必要になったり、競争力を維持するために専門サービスを探したりする場合もあります。移行に関する決定を行う際には、クラウドサービスによって提供されるイノベーションと新しいテクノロジーについて、慎重に評価する必要があります。
サポートとカスタマー サービス: 移行には不明な点が多く、短期間で多くのことを習得する必要があります。移行プロセスにおける十分なサポートと支援があることを知っていれば、移行を確実に成功させるのに役立ちます。

モダナイゼーションまたは移行プロジェクトの計画に関するベストプラクティス

企業の IT 部門では数十年にわたって移行が行われてきました。そのため、ほとんどの組織は移行またはモダナイゼーションのプロセス（メインフレームから x86 サーバーへ、SQL ワークロードから NoSQL へ、Hadoop フレームワークの導入など）に慣れ親しんでいます。

独自のプロジェクトを計画する場合は、次の 4 つのカテゴリに従ってアプローチを組み立てると便利です。

オポチュニティ評価: オポチュニティとビジネスケースを特定して定量化し、関係者の連携の促進を開始します。デューデリジェンスや状況把握などのアクティビティにより、IT 環境全体に対する分析情報が得られ、さまざまなクラウドベースのオプションを適切に策定できます。
基盤と計画: 移行またはモダナイゼーションプロジェクトの成功への基本的な鍵となるのが、クラウドインフラストラクチャの強固な基盤の確立です。クラウドへの移行に最適なワークロードを判断して優先させ、それらの移行方法を計画します。
移行と検証: 実行、検証、古いシステムの廃止はすべて、移行プロジェクトにおける重要なステップです。クラウドに最適なワークロードから始めて、ビジネス価値、技術面での優先事項、クラウド適合性に基づいて後続のプロジェクトを計画します。各ステップを分析、評価することで、今後の移行に向けて微調整できます。
最適化と運用: 移行後、新しい環境に移行したワークロードを運用して最適化する必要があります。クラウドベースの運用を採用し、ワークロードのパフォーマンスをモニタリングして理解することは、どのクラウド移行プロセスにおいても非常に重要なステップです。このプロセスを行わないと、クラウド費用の高額化とクラウド環境の複雑化に頭を抱えることとなるでしょう。

モダナイゼーションと移行のループ（Gemini で作成した画像）

プロセスに関係なく、移行のアプローチは同じようなパターンに従い、同じような特性を表す傾向があります。たとえば、プロジェクトを計画する際には、人員、プロセス、テクノロジーの要素に焦点を当てることが重要で、これらはすべて、移行の成功に貢献する重要な要因となることがわかっています。各要素について考慮すべき事項をいくつか例示します。

人員: 関係者の連携、スキルの構築、リソースの管理
プロセス: ベストプラクティスの収集、ガバナンスモデルを通じたプロセスの追跡、または明確に定義された OKR の定義とモニタリング
テクノロジー: 技術的なギャップの特定、移行ワークロードの優先順位付け、財務、セキュリティ、コンプライアンスが十分に管理された、適切なプロジェクトランディングゾーンの構築

適切に実行される移行プロセスは、フライホイール効果を生み出します。すなわち、ワークロードの移行から得られた知識と経験が複合してビジネスケースの絞り込み、基盤の強化、後続の移行の加速を実現し、ワークロードの経時的な最適化が容易になります。

この記事の分析情報と私自身の現場での経験を踏まえて、可能であればデータワークロードのモダナイゼーションプロセスを検討することを強くおすすめします。サーバーレステクノロジーは、TCO を大幅に削減し、モダナイゼーションへの取り組みの費用対効果を高めることができる魅力的なメリットを提供します。これらのメリットには、費用の削減、セキュリティの強化、パフォーマンスとスケーラビリティの向上、最新テクノロジーの活用、アジリティとイノベーションの向上などが含まれます。モダナイゼーションを選択することで、Google の数多くのお客様が行っているように、多くのメリットをすぐに現実に享受できるようになります。

Google は、ツール、リソース、ベストプラクティス、インセンティブファンディングを使用したエンドツーエンドのガイダンスとサポートを提供して移行のリスクを軽減する、データベースのモダナイゼーションプログラムを提供しています。詳細情報およびプログラムのお申し込みについては、こちらをご覧ください。

ご精読ありがとうございました。質問やチャットをご希望の場合は、LinkedIn や Twitter で私をフォローしてください。

-カスタマーエンジニア Patrick Alexander

Next ’24 での移行に関する主な発表のまとめ

Thu, 25 Apr 2024 02:10:00 +0000

※この投稿は米国時間 2024 年 4 月 12 日に、Google Cloud blog に投稿されたものの抄訳です。

お客様がどのような移行またはモダナイズをお考えであっても、Google Cloud はその取り組みを支援することに尽力しています。このたびも、移行のプロダクトとプログラムのポートフォリオに関する数々の更新情報を新たに発表できることを嬉しく思っています。

Rapid Migration Program（RaMP）に関する最新情報

クラウド移行の取り組みは、費用の節約、効率性の向上、スケーラビリティからイノベーションの促進に至るまで、クラウドコンピューティングが提供する価値を引き出す必要があって推進されていると、Google は理解しています。お客様がクラウドの価値を存分に実現できるようにするため、RaMP がアプリケーションと基盤となるインフラストラクチャ、データ、分析にわたる移行とモダナイゼーションのユースケースに対応しました。RaMP には現在、RaMP for Databases、RaMP for Mainframe Migration、RaMP for Storage などの柱となるプログラムがあり、特定のワークロードに対する規範的なガイダンスをお客様に提供しています。

これにより、Google Cloud とそのパートナーはお客様のワークロードを総合的に検討し、サーバーレスやコンテナ化などのクラウドネイティブサービスをお客様が最大限に活用できるロードマップを提供できるようになります。Google は最近、生成 AI サービスを含むプロダクトポートフォリオ全体にわたり、お客様による移行とモダナイゼーションの成果を促進するさまざまなパートナーインセンティブも発表しました。

こうしたプログラムの改善に加えて、Google Cloud は、費用対効果に優れた移行およびモダナイゼーションプロジェクトを効率的に分析、計画、実行するための包括的なファーストパーティ製マネージドサービスとサードパーティ製ツール（Marketplace 経由）も提供します。

Migration Center に関する最新情報

RaMP の重要な要素となっているのが、統合プラットフォームの Migration Center です。Migration Center は、現在のオンプレミスまたはクラウド環境から Google Cloud へのエンドツーエンドのクラウド移行を加速させます。Migration Center は、クラウド費用の見積もり、現在の環境のアセットの検出、さまざまな移行シナリオに対応する種々のツールなどを取り揃えています。今回追加された便利な新機能を以下にご紹介します。

移行ユースケースナビゲータ: リソース（サーバー、データベース、データウェアハウスなど）をオンプレミスや他のクラウドから Google Cloud に直接移行する方法を正確にマッピングできます。これにより、参照、検討、確認できるオプションを備えた規範的で完全な計画を用意できます。
新しいクラウド費用の見積もりツール: オンプレミスの VMware から Google Cloud VMware Engine（GCVE）までと、Exadata から BigQuery までの TCO を迅速に評価できます。
データベースの調査と評価: MSSQL、PostgreSQL、MySQL から Cloud SQL への移行計画を作成できます。ソースデータベースごとに、Cloud SQL の推奨事項を含む技術的な適合性に関する詳細情報と、詳細な TCO レポートを得られます。

VMware ワークロードの移行に関する最新情報

Google Cloud VMware Engine は、可用性 SLA が最も高い統合 VMware サービスです。すべてのハードウェアとライセンスが含まれており、Google Cloud 内で VMware ワークロードの移行やホストを簡単に行えるこのプロダクトについて、以下のような優れた新機能を発表しました。

他のクラウドプロバイダに先駆けて VMware Cloud Foundation ライセンスポータビリティをサポートする意向を発表: このサポートにより、VMware Cloud Foundation ライセンスを持ち込み、Google Cloud で既存の VMware 資産を変革することを検討しているオンプレミスのお客様に幅広く対応できます。
ve1 と比較して、1.8 倍の vCPU、2.7 倍の RAM、1.3 倍のストレージを搭載し、200 Gbps の East-West 接続を備えたより大きなインスタンスタイプ（ve2-standard-128）の一般提供。
次世代 VMware Engine ネットワーキング、自動化された構成不要の VPC ピアリング、ワークロード向け Cloud DNS などのネットワーキングの進歩。
GCVE（Google Cloud VMware Engine）での Terraform の Infrastructure as Code による自動化: プライベートクラウド、クラスタ、ネットワークの管理を自動化するため、さらに多くの Terraform リソースのサポートを追加しました。VMware Engine Terraform プロバイダへのサポートが強化されたことで、VMware Engine 環境全体で Infrastructure-as-Code が実現します。

仮想マシンとディスクの移行に関する最新情報

Migrate to Virtual Machines は、オンプレミスの 1 つのアプリケーションを移行する場合も、複数のデータセンターにまたがる 1,000 のエンタープライズグレードのアプリケーションを移行する場合も、規模にかかわらずワークロードを Google Cloud に移行できるように IT チームを支援します。発表内容を以下にご紹介します。

ディスク移行: VM ではなくディスクボリュームを安心かつ簡単に Google Cloud に移行するための堅牢なソリューションを提供します。セルフマネージドのデータベース移行、OS の再構築などのユースケースに対応します。
イメージインポート（プレビュー版）: 「Migrate to Virtual Machines」プロダクト内のマネージドサービスの一種です。フリクションを軽減しインポートの実現を促進し、ユーザビリティとサポート性を向上させます。
BIOS から UEFI への変換（プレビュー版）: 移行の一環としてブートローダーを新しい形式（UEFI）に自動的に変換します。これにより、移行された VM が Google Cloud のあらゆるセキュリティ強化を活用できるようになります。
Amazon Linux の変換（プレビュー版）: Google Compute Engine で Amazon Linux を Rocky Linux に簡単に変換できます。
CMEK サポート: Migrate to Virtual Machines 内で顧客管理の暗号鍵（CMEK）のサポートを使用して独自の暗号鍵の制御性を維持できるため、Google Cloud への移行がさらに安全になります。

GKE や Cloud Run のコンテナへの仮想マシンのリプラットフォームに関する最新情報

新しい Migrate to Containers （M2C）CLI: アプリケーションオーナー専用に構築されており、ローカルマシンを使用して VM 上で実行されているアプリケーションコンポーネントを迅速かつ簡単にモダナイズできます。GKE や Cloud Run にデプロイ可能なアーティファクトが生成されます。オフラインモードでは、実行時にインターネットからリソースを pull せずにローカルで CLI を使用できます。
また、M2C Cloud Code 拡張機能のプレビュー版も発表しました。この拡張機能は、Visual Studio でアプリケーションを VM から GKE 上で実行されているコンテナに直接移行できる統合エクスペリエンスを提供します。GKE で既存のアプリケーションを実行するためのガイド付きのリプラットフォームプロセス、技術的な適合性評価、アーティファクトの自動生成機能がデベロッパーの生産性向上に役立ちます。

データベースの移行に関する最新情報

変換と移行が統合された単一のエクスペリエンスを介し、数回のクリックでデータベースの移行を開始できます。移行の複雑さが軽減されるため、クラウドのメリットを短期間で得ることができます。発表のハイライトを一部ご紹介します。

Database Migration Service での、任意のプラットフォーム上にある Oracle から PostgreSQL への AI によるラストワンマイルのコード変換: Gemini はストアドプロシージャ、関数、トリガー、パッケージ、カスタム PL/SQL コードなど、データベースコードから宛先の Cloud SQL for PostgreSQL または AlloyDB への変換を自動化します。実際の動作を確認するには、こちらの動画をご覧ください。さらに、説明可能性（プレビュー版）により、コードの詳細な説明や推奨事項とともに言語を並べて比較できるため、PL/SQL 開発者の再トレーニングと新しいスキルの習得に役立ちます。
DMS for SQL Server 移行（プレビュー版）: 任意のプラットフォームにおける SQL Server から Cloud SQL for SQL Server への新しい同種移行を最小限のダウンタイムで行います。
Datastream では、CDC のソースとしての SQL Server により、BigQuery へのシームレスでさらに高度なデータ移動が導入されます。
データベース向け RaMP の新しいモダナイゼーションプログラム: ベストプラクティス、ツール、魅力的な資金提供を組み合わせて、お客様が Oracle や SQL Server から Google Cloud データベースに移行できるように支援します。

メインフレームのモダナイズに関する最新情報

Google Cloud はメインフレームやミッドレンジシステムでレガシーアプリケーションを実行している大規模なお客様をサポートするために、メインフレームのモダナイゼーションへの投資を大幅に増やしています。Google Cloud では、ファーストパーティ製ツールとサードパーティ製ツールに加え、提供パートナーおよび技術パートナーとの主要なパートナーシップを備えた幅広いポートフォリオが、完全なエンドツーエンドのモダナイゼーションソリューションを実現します。今回は、メインフレームのモダナイゼーションプロセス全体にわたる、以下のような優れた新機能を発表しました（プロセスの各機能の頭文字を取って AARDVARK（ツチブタ）という愛称で呼んでいます）。

評価（Assess）- 生成 AI を利用した Mainframe Assessment Tool（MAT）は、アプリケーションのコードベースを分析し、適合性評価を行い、アプリケーションレベルの要約とテストケースを作成することで、移行プロセスを加速します。実際の動作を確認するには、こちらの動画をご覧ください。
拡張（Augment）- Mainframe Connector は、メインフレームの外部で分析するためにメインフレームデータのコピーを BigQuery に送信します。こちらの動画をご覧ください。
リファクタリングと書き換え（Refactor & rewrite）- G4 は、メインフレームのアプリケーションコード（COBOL、RPG、JCL など）とデータを元の状態 / プログラミング言語から最新のスタック（Java）にリファクタリングするか、AI を活用して完全に書き換えます。
リスク回避（De-Risk）- Dual Run を使用すると、新しいシステムを既存のメインフレームと並行して実行し、すべてのトランザクションを重複させ、新しいソリューションの完全性、品質、有効性を確認できます。Dual Run は、本番環境でこれを使用している Santander Bank と提携して設計、実装されました。

RaMP に参加しているパートナー様は、新しいインセンティブを活用し、メインフレームワークロードの検出と Google Cloud Platform へのモダナイゼーションを促進することもできるようになりました。

ストレージの移行に関する最新情報

場合によっては、大量のストレージを Google Cloud に移行しなくてはならないことがあります。こうした要件に対応するため、柱となるプログラムである RaMP for Storage の一環となる魅力的な 2 つの新たな発表をご用意しました。

Amazon S3 から Google Cloud Storage へのストレージの下り（外向き）コストが完全に無料になりました。
Python や Node.js、Java 向けの Cloud Storage クライアントライブラリがアップロードとダウンロードの並列処理に対応し、その上に構築されたアプリケーションの読み取りと書き込みの時間が大幅に短縮されました。この機能は Google のコマンドラインインターフェースを介して利用できましたが、現在はクライアントライブラリに完全に統合されており、Cloud Storage のお客様は使用する移行メカニズムに関係なく、最適なパフォーマンスを得られます。

次のステップ

移行およびモダナイゼーションプロジェクトを迅速かつ簡単に実施できるようにするための投資は、引き続き Google Cloud にとって大きな焦点となります。上記の魅力的な発表に加えて、特に移行ポートフォリオに生成 AI を組み込み続けるなか、今後も数多くの新機能を提供していく予定です。2024 年はさらに胸躍るニュースをお届けしてまいりますので、どうぞご期待ください。次のステップに進む準備ができている方は、Rapid Migration Program ウェブサイトにアクセスしてください。または、既存の IT 環境の無料の調査と評価に申し込み、Google の移行エキスパートと協力してクラウドへの移行計画を作成しましょう。

-Google Cloud、Cloud Migration チーム所属 Tom Nikl
-Google Cloud プロダクト管理担当ディレクター Anant Chintamaneni

IDC: Google Cloud IaaS への移行により、318% の費用対効果を実現

Wed, 07 Feb 2024 02:10:00 +0000

※この投稿は米国時間 2024 年 2 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。

世界中の組織が、継続的なデジタルトランスフォーメーションを実現してサポートするためにクラウドサービスを導入し続けています。費用削減、アジリティ、弾力性、スケーラビリティなど、クラウドインフラストラクチャのメリットはよく知られていますが、これらのメリットの定量化には課題が伴います。

2023 年後半、Google はクラウドインフラストラクチャへの移行による具体的な費用対効果について理解を深めるために、Google が資金提供した IDC の調査の結果を発表しました。この調査は、米国、英国、ドイツの金融サービス、政府機関、医療、不動産、小売、公益事業の各業界の組織を対象とする 9 件のインタビューで構成されています。選ばれた組織は、Google Cloud Infrastructure as a Service（IaaS）を導入し、そのメリットと費用を実際に体験しています。

IDC: Extracting more business value from cloud infrastructure（IDC: クラウドインフラストラクチャからより多くのビジネス価値を引き出す）

Google Cloud IaaS のビジネス価値に関する、Google が資金提供した調査の一環として、IDC リサーチチームがこの調査で発見したことの一部をご紹介します1。

5 年間で 318% の費用対効果を実現
5 年間でオペレーション費用が 51% 減少
IT インフラストラクチャ管理チームの効率性が 57% 向上
アプリケーションの新機能のデプロイが 75% 高速化
323 万ドルの追加収益を獲得

この IDC の調査と Google Cloud IaaS の導入が組織にもたらすメリットの詳細

IDC 調査の全文は、こちらからダウンロードできます。
IDC 調査担当 VP の Dave McCarthy 氏と、Google 北米デベロッパーアドボカシーリードでありベストセラー作家でもある Priyanka Vergadia が調査結果について詳しく語った対談をご覧ください。

^{1.出典: ビジネス価値に関する IDC の調査（Google が資金提供）「The Business Value of Google Cloud IaaS」、IDC #US51037323、2023 年 8 月。}

^{対象とした企業特性:
- 従業員数: 1,500～300,000 人
- IT スタッフ数: 300～2,000 人
- ビジネスアプリケーション数: 20～6,000 個
- 収益: 1 億 2,630 万～590 億ドル}

-クラウド移行担当シニア プロダクト マーケティング マネージャー Tom Nikl

クラウドの乗り換えが簡単に: Google Cloud から乗り換える際のデータ転送料金を廃止

Thu, 18 Jan 2024 03:00:00 +0000

※この投稿は米国時間 2024 年 1 月 12 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud は、オープンかつ安全で、相互運用可能なクラウドエコシステムの育成に努めています。お客様のビジネス要件が変化した場合、クラウドはその変化に対応できるような柔軟性をもつべきだと考えています。

Google Cloud はこのたび、Google Cloud からのデータ移行料金を廃止しました。Google Cloud の使用をやめ、他のクラウドプロバイダやオンプレミスへのデータ移行を希望するお客様は、ネットワークを通じて無料でデータ転送を行うことが可能となります。この変更は、地域を問わずすべてのお客様が対象となります。詳しくは、こちらをご覧ください。

クラウドプロバイダを乗り換える際のデータ転送料金を廃止することで、お客様はクラウドプロバイダを変更しやすくなります。ただし、そもそもクラウドプロバイダを選ぶ自由が阻まれているという根本的な問題は解決されていません。その問題は、制限を課す不公平なライセンス方式に根差しています。

以前から存在する一部のプロバイダは、自社のオンプレミスの専売ソフトウェアを通じて、顧客を囲い込むような制限的なライセンスによって競争を阻むことで、クラウド市場を独占しています。

ライセンスによる制限は複雑に入り組んでいます。たとえば、ユーザーが使用するプロバイダや手段の選択肢を狭める、特定の競合他社のクラウドを使用すると費用が 5 倍になる、必須ソフトウェアの相互運用を競合他社のクラウドインフラストラクチャ上で制限する、といったケースがあります。こうした制限に技術的な根拠はなく、ユーザーに 300% の費用増加をもたらす可能性があります。一方、クラウドプロバイダからデータを取り出して移行する費用は最小限に抑えられています。

クラウドプロバイダ間の移行を簡単にしたところで、このような制限のあるライセンスで囲い込まれている限り、ユーザーは選択の自由を得られません。過剰な制限を設けた契約条項や、罰則的なライセンスに縛られることなく、ユーザーの業務の観点から理にかなったクラウドプロバイダを選べるようにすべきです。

クラウドの特長は、企業や政府がテクノロジーの利用をシームレスにスケーリングできることです。Google Cloud はこの数か月、Google Cloud 上でワークロードを実行する大小さまざまな組織の皆様に提供する価値を高め、データ転送を改善すべく、複数の方策を盛り込んできました。このたびの発表は、こうした方策をさらに発展させたものです。

Google は、以前から存在するプロバイダから課されたライセンスの制限について、クラウドのお客様から直接相談を受けています。これらのお客様に代わり、今後も制限廃止に向けて主張し続ける所存です。クラウド市場において選択および競争の真の妨げとなっている制限的なライセンス方式をなくすため、山積している課題に取り組んでまいります。

-Google Cloud バイス プレジデント兼ゼネラル マネージャーおよびプラットフォーム担当責任者 Amit Zavery

Flipkart、大規模なクラウド移行により技術的環境を再構築

Tue, 14 Nov 2023 00:00:00 +0000

※この投稿は米国時間 2023 年 10 月 31 日に、Google Cloud blog に投稿されたものの抄訳です。

インドでは、消費者の 3 分の 1 以上が買い物のために Flipkart を利用しており、このプラットフォームは 4 億 5,000 万人以上のユーザーを抱えています。登録ショップは 110 万軒に上り、80 のカテゴリにわたって 1 億 5,000 万種類以上の商品を提供し、毎日数百万個の荷物を発送しています。

Flipkart は、技術的環境を再構築して事業の将来性を確保するために、Google Cloud を利用しました。Google Cloud との提携の成果は明らかで、Flipkart Data Analytics Platform（FDP）と Content Catalog Object Store という 2 つの重要なプラットフォームを Google Cloud インフラストラクチャ上で立ち上げることができ、その他すべてのものも含めて Google Cloud に移行しました。

Flipkart にとって 1 年で最も重要な日は Big Billion Day（BBD）セールです。これは、世界的なショッピングの祭典であるブラックフライデーやサイバーマンデーのようなものです。BBD は 9 月から 10 月にかけて行われ、インドの活気あるお祭りシーズンと重なります。数日間にわたり、Flipkart ではトランザクション量が通常業務（BAU）の 6～8 倍に急増します。

大規模で複雑なデータクラスタを短期間で移行

Flipkart の既存のデータプラットフォームは、オープンソースのビッグデータテクノロジー上に構築され、Flipkart 固有のビジネス要件に対応するために大規模なカスタマイズが施されていました。この複雑な環境は、チェンナイとハイデラバードにある自社管理のデータセンターに分散していました。約 8 か月間というタイトなスケジュールで移行しなければならなかった Flipkart は、次のようなさまざまな課題に直面していました。

大規模な Hadoop クラスタの移行: Flipkart は、膨大な計算能力とメモリリソースを持つ大規模な Hadoop クラスタを Google Cloud に移行する必要がありました。
複雑なデータ移行: 移行対象はインフラストラクチャだけでなく、10,000 以上のファクト、ジャーナル、スナップショットと、15,000 の ETL（抽出、変換、読み込み）ジョブにもおよびました。この複雑な作業では、毎日、10 PB の膨大なデータをバッチ処理し、2 PB のデータをニアリアルタイムで処理する必要がありました。
データ取り込みレイヤ: 大規模なデータ取り込みを容易にするため、チームはオンプレミスの Kafka から Google Cloud の Pub/Sub に移行する必要がありました。この複雑な作業には、1 日あたり 1,300 億以上のメッセージの取り込み、通常運用時には 1 日あたり 60 TB の圧縮データ、イベントのピーク時には 1 日あたり 500 TB の取り込みが必要でした。さらに、このプロセスには 3,000 のトピックが含まれ、一般的なデータと機密・個人情報（PII）の両方におよんでいました。
データ処理と分析: Flipkart は、リアルタイム分析のために、毎秒 125 万という膨大なメッセージを処理できる堅牢な処理プラットフォームを構築する必要がありました。これは Dataproc を使用して行われました。さらに、このプラットフォームはリアルタイムで約 2 ペタバイト、バッチモードで毎日 10 ペタバイトのメッセージを効率的に処理する必要もありました。
セルフマネージド Hive の移行: この移行は、既存のセルフマネージド Hive から Hive on Dataproc への移行を含む、重要なユーザー向けコンポーネントにまでおよびました。その目的は、約 20 のチームと 350 人近いテクニカルユーザーの要件を満たすことでした。驚くべきことに、この移行に要した期間はわずか 4 か月でした。
セキュリティの確保: Google Cloud のサービスとセルフマネージドサービスの両方で堅牢なセキュリティ対策を確保することが最も重要であり、綿密な計画と厳格な実装が求められました。Google のセキュリティ専門家は Flipkart チームと緊密に連携して、移行されたすべてのコンポーネントの徹底的な評価を行い、セキュリティ状態を確認し、潜在的なリスクと解決策を評価しました。この評価プロセスでは、セキュリティ対策レビューなどのフレームワークが活用されました。

Flipkart はこれらの課題への対処を単独で行ったわけではありません。Google Cloud チームと協力して対処し、移行全体で専門知識が共有されました。当初は BBD 前のリフト＆シフト移行として計画されましたが、BBD 後のモダナイゼーションフェーズは、より複雑で微妙なプロセスへと急速に発展しました。Flipkart のユースケースは複雑だったことから、Google Cloud とパートナー組織の 85 人以上のメンバーで構成される多専門的チームが招集され、この壮大な移行の舵取りをしました。

強固なクラウドインフラストラクチャで SLA を超える

チームは Google Cloud を使用して 15 のツールを構築しました。各ツールは、Flipkart の複雑なエコシステムが提示する固有の要件や課題に対応するように設計されています。移行には、データの取り込み、バッチ処理、メッセージングなど、さまざまな要素が含まれるため、これらのツールは移行を進めるうえで重要な歯車として機能しました。

微調整とパフォーマンスの最適化を絶え間なく行ったことにより、新しいインフラストラクチャはサービスレベル契約（SLA）を満たしただけでなく、それを上回りました。BAU の 5 倍の量に達する複数回のスケールテストを含む厳密なテストにより、Google Cloud インフラストラクチャ上で BBD セールイベントを円滑に実施するための基盤が固まりました。

この移行がもたらしたインパクトは劇的なものでした。Flipkart は、わずか 8 か月でオンプレミスから Google Cloud へのデータプラットフォームの移行を完了しました。この移行には、膨大な数の vCPU コアを持つ Hive クラスタや、膨大な量の Google Cloud ストレージなど、大量のメッセージのバッチ処理とリアルタイム処理を行う多数のコンポーネントのスムーズな移行が含まれていました。見落としてはならないのは、54 億ものオブジェクトを含むコンテンツ管理ストアを移行するという、非常に大規模で複雑な試みだったということです。

変革を通じて企業の将来性を確保

Google Cloud インフラストラクチャの実際の影響は、すぐに明らかになりました。Flipkart は BBD セールイベントを成功させ、BAU に比べてトランザクションデータを 7 倍増加させただけでなく、イベントのスムーズな実施により、社内外の関係者の間で信頼感と安心感が醸成されました。この移行は、技術的な偉業であっただけでなく、e コマースの領域におけるコラボレーション、イノベーション、変革の可能性の証でもありました。

振り返ってみると、Flipkart も Google Cloud も貴重な教訓を学びました。この移行は、JAPAC 地域における大規模インフラストラクチャの限界を押し広げる、現実世界のストレステストとして機能しました。そして、業界が進化し続けるなか、Google Cloud への Flipkart の移行は、パートナーシップと技術的進歩の成功モデルとなっています。これは、コラボレーションの力を明らかにしただけでなく、革新的なテクノロジーと人間の創造力を組み合わせれば無限の可能性が生まれることも浮き彫りにしています。

移行を検討されている場合は、Google Cloud の高速評価および移行プログラム（RaMP）で詳細をご覧ください。貴社の IT 環境を理解し、移行を確実に成功させるために、IT 環境に関する無料の調査と評価にお申し込みいただくことも可能です。

-Google Cloud、AI マネージャー Savitha Sethuram

-Flipkart、シニア プリンシパル アーキテクト Sudhir Reddy 氏

Google Cloud へのデータディスクの移行を適切かつ簡単に行う方法

Fri, 10 Nov 2023 01:25:00 +0000

※この投稿は米国時間 2023 年 11 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。

データディスクの移行は、1 台のストレージデバイスから別のデバイスにデータを移行するプロセスです。その際には、物理デバイス間や仮想マシン間のデータ移動、あるいはオンプレミスソリューションからクラウドベースプラットフォームへの移行が必要となります。データディスク移行時の最終的な目標は、データの整合性、セキュリティ、アクセシビリティを損なうことなく、シームレスに移行を行うことです。このブログ投稿では、Google Cloud の移行センターに組み込まれている Migrate to Virtual Machines を使用して、データディスクを迅速かつ簡単に Google Cloud に移行する手順を示します。

データディスクの移行が重要である理由

新しい OS へのアップグレード: サポート対象外のオペレーティングシステムは、正式アップデート、セキュリティパッチ、テクニカルサポートが利用できないため、大きな脅威をもたらします。その結果、システムでは、サイバー脅威、互換性の問題、規制へのコンプライアンス違反が生じやすくなると同時に、イノベーションや機能性が阻まれます。

ディスクを移行すると、サポート対象外の古いオペレーティングシステムからサポート対象の新しいオペレーティングシステムにデータが移されます。

モダナイゼーション: 技術の進歩に伴い、古いストレージデバイスがボトルネックとなり、パフォーマンスや容量が制限される場合があります。データディスクを移行すると、より新しく効率の高いハードウェアを利用できるようになります。
データ保護: ストレージデバイスが老朽化すると、障害やデータ損失が発生しやすくなります。データを新しいプラットフォームに移行することで、こうしたリスクを軽減し、安全性を確保できます。
パフォーマンス向上: 新しいストレージテクノロジーは、一般に読み取り / 書き込み速度が高いため、システムのパフォーマンス向上、アプリケーションのアクセス時間の短縮につながります。
スケーラビリティ: データディスクの移行により、ストレージインフラストラクチャのスケーラビリティが向上するため、データの需要が高まっても、効率性を損なうことなく対応できます。

Google Cloud のディスク移行

Google Cloud は、移行センター内に Migrate to Virtual Machines を直接統合することで、ディスク移行の負担を軽減しています。この強力で効果的なディスク移行手段は、クラウド移行テクノロジーの機能を活用して、クラウド環境との互換性に関係なく、OS ディスクやデータディスクをシームレスに移行します。オペレーティングシステムのアップデートや、ハードウェアの強化といった課題に直面している場合は、これが究極のソリューションとなります。

Migrate to Virtual Machines は、柔軟性やオープン性といった Google Cloud の特徴を引き継ぎ、VMware やその他のクラウドサービスプロバイダを含め、多くの移行元との接続が可能です。たとえば、大量の仮想マシンを管理し、そのうち一部は従来の Linux ディストリビューションか、昔の Windows バージョン（Windows 2003、2008、2012 など）で実行されているとします。このような場合に、Migrate to Virtual Machines のディスク移行機能が役立ちます。ソースワークロードのディスクを選択して移行してから、サポート対象のオペレーティングシステムに接続することで、結果的にワークロードインフラストラクチャのモダナイゼーションが実現します。

仕組み

ディスク移行プロセスの各ステージを以下に示します。

最初に、ディスクを移行したい VM をオンボーディングします。

以下の例では、ローカルの VMware Datacenter でホストされている VM が 1 台あります。これを選択し、GCP 移行サービスにオンボーディングします。

その後、レプリケーションを開始できます。

VM が移行サービスにオンボーディングされたら、ソース VM のディスクから、Google Cloud 上の Persistent Disk ボリュームへ、ディスクのレプリケーションをすぐに開始できます。データのレプリケーションは、最終的なカットオーバーまで、あるいは移行を削除するまで、バックグラウンドで継続的に進行するプロセスです。

Monitoring を利用することもできます。

詳細情報については、VM をクリックして、ディスクレプリケーションステータスの詳細表示、処理完了までの予想時間、ディスク移行に関するその他の情報にアクセスできます。

レプリケーションの進行中に、先にディスクのターゲットの詳細設定で、ホスティングプロジェクト（リージョンとゾーン）、ディスクタイプなど、移行後のディスクの設定を行うことができます。

これにより、時間を節約し、カットオーバー日が近づいたときに慌てずに済みます。

レプリケーションサイクルを調整し、段階的な変更の蓄積データのピークと同期させることもできます。

まとめ

Migrate to Virtual Machines のディスク移行機能は、任意のソース VM から Google Cloud のディスクストレージにコンピューティングディスクをスムーズに移行できる新しい機能です。この機能は Migrate to Virtual Machines のシームレスでエージェントレスの移行機能を活用するので、ソースワークロードが中断されることはありません。また、定期的なレプリケーションサイクルや、迅速なカットオーバーなどのメリットもあります。

この機能は移行の精度を個々のディスクまで拡張するため、ワークロードを別のオペレーティングシステムに簡単に移行する、データストア全体を新しいプラットフォームに移行するといった革新的な活用方法が可能です。

準備できたら、移行センターにアクセスし、Google Cloud の移行とモダナイゼーションの一元化されたエンドツーエンドハブをご確認ください。ここに Migrate to Virtual Machines が含まれます。まだご検討中の場合は、移行センターに関するこの 3 分間の動画をご覧になるか、IT 環境に関する無料の調査と評価を Google Cloud に申し込み、IT 環境の状況や適切な移行方法をご確認ください。

- Cloud 移行担当テクニカル リード Alon Pildus

- Google Cloud、Cloud Migration チーム所属 Tom Nikl

AWS から Google Cloud へのアプリの移行: あるスタートアップの視点

Thu, 26 Oct 2023 03:00:00 +0000

※この投稿は米国時間 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 氏

クラウド マイグレーション

Spanner への移行: Antigravity CLI で二重書き込みを自動化してサービス停止を最小限に

課題: 二重書き込みによる移行の仕組み

解決策: 標準化されたミューテーション コンバータ パターン

Antigravity CLI をヘッドレス モードで使用する理由

クラウド エンジニアにとっての成果と重要なポイント

次回のデータベース移行に役立つ 3 つのヒント

使ってみる

Uber がクラウド移行を妨げることなくネットワークの信頼性を向上させた方法

重要なトラフィックの優先順位付け

Uber の事例の要点

AI とそれ以外のネットワークの信頼性を確保

Google Cloud のアプリケーション ロードバランサへの移行: 実践ガイド

シンプルで段階的な移行アプローチ

スムーズな移行のためのベスト プラクティス

Rapid Migration and Modernization Program（RaMP）の新しいインセンティブで移行を加速させましょう

技術的負債から AI 対応へ

将来を見据えて

Searce とともに Google Cloud へのクラウド移行を加速し、収益性の高い成長を促進

Searce は 1,000 件以上の移行を主導

GKE Gateway Controller で医療の信頼性を向上

GKE Autopilot でグローバルなフィンテック リーダーの TCO が 50% 削減

グローバルな通信大手のパフォーマンスをスケーリング

Searce が移行を成功に導く方法

移行の取り組みを加速させる準備は整いましたか？

AI を活用した BigQuery 移行サービスを使ってデータ プラットフォームの移行を簡素化

データベース ワークロードの調査と評価: Migration Center を使用した Google Cloud への移行

ソース データベースの詳細の調査と収集

技術的適合性評価

費用予測

クラウド移行を簡単に: AWS から Google Cloud への移行ガイド

次のステップ

さっそく始めましょう

-クラウド ソリューション アーキテクト Marco Ferrari-ソリューション マネージャー Giuseppe Lino

Oracle ベース アプリケーションを Google Cloud に移行し、運用を簡素化する

Google Cloud における Oracle データベース

Oracle ベース アプリケーションのコンテナ化

コンテナ化した Oracle データベースの実行

Java アプリケーションの強化

パートナーによるサポート

IBM Power for Google Cloud を改めてご紹介

最新のデータ プラットフォームへの移行で BigQuery と Dataproc のインセンティブを獲得可能に

移行のインセンティブ

移行用のサービスとツール

BigQuery と Dataproc で AI 対応の統合データ プラットフォームを構築

-戦略と運営担当マネージング ディレクター兼データ分析担当アウトバウンド プロダクト マネージャー Yasmeen Ahmad-データ分析担当グループ プロダクト マネージャー Sami Akbay

Beam の Google Cloud への移行で行政機関のセーフティ ネット プログラムの効果が向上

アーキテクチャに関する決定事項

Cloud Run

AlloyDB for PostgreSQL

ML と AI サービス

移行

主な成果と重要ポイント

Beam、クラウド運用担当ディレクター James Osborn 氏

Facturation.net が週末だけで Azure VM を Google Cloud に移行できた理由

Azure VM から Google Cloud への移行

Google Cloud への迅速、柔軟、安全な移行

-スタッフ テクニカル ソリューション コンサルタント Eitan Eibschutz-カスタマー エンジニア Xavier Tremblay

Google Cloud へのデータディスクの移行を適切かつ簡単に行う方法

データ ワークロードのモダナイゼーションと移行の比較

移行とモダナイゼーション: 違いは何か

移行に関する決断をする際の重要な要因

モダナイゼーションまたは移行プロジェクトの計画に関するベスト プラクティス

-カスタマー エンジニア Patrick Alexander

Next ’24 での移行に関する主な発表のまとめ

Rapid Migration Program（RaMP）に関する最新情報

Migration Center に関する最新情報

VMware ワークロードの移行に関する最新情報

仮想マシンとディスクの移行に関する最新情報

GKE や Cloud Run のコンテナへの仮想マシンのリプラットフォームに関する最新情報

データベースの移行に関する最新情報

メインフレームのモダナイズに関する最新情報

ストレージの移行に関する最新情報

次のステップ

-Google Cloud、Cloud Migration チーム所属 Tom Nikl-Google Cloud プロダクト管理担当ディレクター Anant Chintamaneni

IDC: Google Cloud IaaS への移行により、318% の費用対効果を実現

IDC: Google Cloud IaaS への移行により、318% の費用対効果を実現

クラウドの乗り換えが簡単に: Google Cloud から乗り換える際のデータ転送料金を廃止

Flipkart、大規模なクラウド移行により技術的環境を再構築

大規模で複雑なデータクラスタを短期間で移行

クラウドマイグレーション

解決策: 標準化されたミューテーションコンバータパターン

Antigravity CLI をヘッドレスモードで使用する理由

クラウドエンジニアにとっての成果と重要なポイント

Google Cloud のアプリケーションロードバランサへの移行: 実践ガイド

スムーズな移行のためのベストプラクティス

GKE Autopilot でグローバルなフィンテックリーダーの TCO が 50% 削減

AI を活用した BigQuery 移行サービスを使ってデータプラットフォームの移行を簡素化

データベースワークロードの調査と評価: Migration Center を使用した Google Cloud への移行

ソースデータベースの詳細の調査と収集

-クラウドソリューションアーキテクト Marco Ferrari
-ソリューションマネージャー Giuseppe Lino

Oracle ベースアプリケーションを Google Cloud に移行し、運用を簡素化する

Oracle ベースアプリケーションのコンテナ化

最新のデータプラットフォームへの移行で BigQuery と Dataproc のインセンティブを獲得可能に

BigQuery と Dataproc で AI 対応の統合データプラットフォームを構築

-戦略と運営担当マネージングディレクター兼データ分析担当アウトバウンドプロダクトマネージャー Yasmeen Ahmad
-データ分析担当グループプロダクトマネージャー Sami Akbay

Beam の Google Cloud への移行で行政機関のセーフティネットプログラムの効果が向上

-スタッフテクニカルソリューションコンサルタント Eitan Eibschutz
-カスタマーエンジニア Xavier Tremblay

データワークロードのモダナイゼーションと移行の比較

モダナイゼーションまたは移行プロジェクトの計画に関するベストプラクティス

-カスタマーエンジニア Patrick Alexander

-Google Cloud、Cloud Migration チーム所属 Tom Nikl
-Google Cloud プロダクト管理担当ディレクター Anant Chintamaneni

強固なクラウドインフラストラクチャで SLA を超える