Google Cloud への移行: ワークロードの評価と調査

Last reviewed 2023-06-07 UTC

このドキュメントでは、Google Cloud への移行の評価フェーズを計画、設計、実装するときに役立つ情報をご紹介します。アプリとサービスのインベントリを調査してそれぞれの依存関係をマッピングすると、どのアプリをどの順序で移行すべきかを特定するのに役立ちます。Google Cloud への移行を計画して設計する際は、現在の環境と移行対象のアプリケーションおよびワークロードについて熟知している必要があります。

このドキュメントは、Google Cloud への移行に関する次の複数のパートからなるシリーズの一部です。

次の図は、移行の過程を示しています。

4 フェーズの移行パス

評価フェーズは、Google Cloud への移行の最初のフェーズです。このフェーズでは、Google Cloud に移行するアプリの要件と依存関係を判断します。

このドキュメントは、オンプレミス環境、非公開のホスティング環境、別のクラウド プロバイダからの移行を計画している場合に役立ちます。また、移行の機会を評価する目的、評価フェーズの内容を探る目的にも役立ちます。

移行を成功させるには、評価フェーズが非常に重要です。このフェーズで、移行するアプリとその要件、依存関係、および現在の環境について詳しく把握する必要があります。また、Google Cloud への移行を計画して実施するための出発点も理解する必要があります。

このフェーズでは、次の手順を行います。

  1. アプリの包括的なインベントリを作成する。
  2. プロパティと依存関係に応じてアプリを分類する。
  3. チームを Google Cloud でトレーニングして教育する。
  4. Google Cloud 上で実験と概念実証を作成する。
  5. ターゲット環境の総所有コスト(TCO)を計算する。
  6. 最初に移行するワークロードを選ぶ。

アプリのインベントリを作成する

移行のスコープを設定するには、まず、現在の環境内に存在するアプリやハードウェア アプライアンスなどのアイテムの数と、それぞれの依存関係を理解する必要があります。インベントリを作成するのは簡単な作業ではありません。とりわけ、自動カタログ化システムが整っていない場合は多大な労力を要する作業です。包括的なインベントリを作成するには、現在の環境内の各ワークロードと環境自体の設計、デプロイ、オペレーションを担当するチームの専門知識を活用する必要があります。

インベントリには、アプリだけに限定せずに少なくとも次のアイテムを含めてください。

  • 各アプリの依存関係(データベース、メッセージ ブローカー、構成ストレージ システム、その他のコンポーネント)。
  • アプリ インフラストラクチャをサポートしているサービス(ソース リポジトリ、継続的インテグレーション(CI)ツール、アーティファクトのリポジトリなど)。
  • サーバー、仮想環境または物理環境、ランタイム環境
  • 物理アプライアンス(ネットワーク デバイス、ファイアウォール、その他の専用ハードウェア)

以上のリストを作成する際は、各アイテムについて以下の情報も収集してください。

  • ソースコードの場所と、そのソースコードを変更できるかどうか。
  • ランタイム環境でのワークロードのデプロイ方法(たとえば、自動化されたデプロイ パイプラインを使用しているのか、あるいは手動でデプロイしているのかなど)。
  • ネットワークに関する制限事項またはセキュリティ要件。
  • IP アドレスの要件
  • ワークロードをクライアントに公開する方法。
  • ソフトウェアまたはハードウェアのライセンス要件。
  • ワークロードが Identity and Access Management システムに対して認証される方法。

たとえば、各ハードウェア アプライアンスについて、その名前、ベンダー、テクノロジー、インベントリ内の他のアイテムへの依存関係といった詳細な仕様を把握する必要があります。次に例を示します。

  • 名前: NAS アプライアンス
  • ベンダーとモデル: ベンダー Y、モデル Z
  • テクノロジー: NFS、iSCSI
  • 依存関係: ジャンボ フレームを使用した VM コンピューティング ハードウェアへのネットワーク接続

このリストには、技術面以外の情報も含める必要があります。たとえば、各アイテムの使用許諾に適用されるライセンス条項や、その他すべてのコンプライアンス要件についての情報です。ライセンスにはクラウド環境へのアプリのデプロイを許可しているものもあれば、クラウドへのデプロイを明示的に禁止しているものもあります。一部のライセンスは使用する CPU またはソケットの数に基づいて割り当てられますが、クラウド テクノロジーをベースに実行するアプリには、CPU やソケットの数といったコンセプトは適用されないこともあります。また、データによっては保管場所の地理的なリージョンに関して制限が課せられる場合もあります。さらに、機密性が高いワークロードには単独のテナントが必要になります。

インベントリとともに、収集したデータを視覚的に解釈できるようにすると役立ちます。たとえば、依存関係のグラフとチャートを用意すると、アプリが自動または手動のデプロイ プロセスでどのように配布されるかといった側面を明らかにできます。

インベントリの作成方法

アプリのインベントリを作成するにはさまざまな方法があります。最も早い方法は手動で作成することですが、大規模な本番環境では、この方法に従うのは困難です。手動で作成されたインベントリの情報はすぐに古くなりがちであり、誤った前提に基づく移行は失敗する恐れがあります。

インベントリの作成は、一度限りの作業ではありません。現在の環境が極めて動的である場合、インベントリの作成とメンテナンスの自動化にも取り組んで、最終的に環境内のすべてのアイテムをいつでも矛盾のない状態で把握できるようにしてください。アプリケーションのインベントリを作成する方法については、Migration Center: アセットの検出を開始するをご覧ください。

Google は複数の企業と提携して、移行の過程を支援します。詳細については、サポートをご覧ください。

アプリのインベントリの例

この例は、e コマースアプリをサポートする環境のインベントリを示しています。インベントリには、アプリ、依存関係、複数のアプリをサポートするサービス、ハードウェア アプライアンスが含まれます。

アプリ

次の表には環境内の各アプリについて、特に重要なテクノロジー、デプロイ手順、その他の要件が記載されています。

名前 ソースコードの場所 テクノロジー デプロイ手順 その他の要件 依存関係 システム リソースの要件
マーケティング ウェブサイト 会社のリポジトリ Angular フロントエンド 自動 法務部がコンテンツを検証すること キャッシュ サービス 5 CPU コア
8 GB の RAM
バックオフィス 会社のリポジトリ Java バックエンド、Angular フロントエンド 自動 なし SQL データベース 4 CPU コア
4 GB の RAM
e コマースアプリ 独自仕様のアプリ ベンダー X
モデル Y
バージョン 1.2.0
手動 顧客データを欧州連合内で保管すること SQL データベース 10 CPU コア
32 GB の RAM
エンタープライズ リソース プランニング(ERP) 独自仕様のアプリ ベンダー Z、モデル C、バージョン 7.0 手動 なし SQL データベース 10 CPU コア
32 GB の RAM
ステートレス マイクロサービス 会社のリポジトリ Java 自動 なし キャッシュ サービス 4 CPU コア
8 GB の RAM

依存関係

次の表に、インベントリにリストされているアプリの依存関係の例を記載します。これらの依存関係は、アプリが正常に機能するために必要です。

名前 テクノロジー その他の要件 依存関係 システム リソースの要件
SQL データベース PostgreSQL 顧客データを欧州連合内で保管すること バックアップおよびアーカイブ システム 30 CPU コア
512 GB の RAM

サポート サービス

環境には、複数のアプリをサポートするサービスがある場合があります。この e コマースの例には、次のサービスがあります。

名前