このドキュメントでは、Google Cloud への移行の評価フェーズを計画、設計、実装するときに役立つ情報をご紹介します。アプリとサービスのインベントリを調査してそれぞれの依存関係をマッピングすると、どのアプリをどの順序で移行すべきかを特定するのに役立ちます。Google Cloud への移行を計画して設計する際は、現在の環境と移行対象のアプリケーションおよびワークロードについて熟知している必要があります。
このドキュメントは、Google Cloud への移行に関する次の複数のパートからなるシリーズの一部です。
- Google Cloud への移行: スタートガイド
- Google Cloud への移行: ワークロードの評価と調査（このドキュメント）
- Google Cloud への移行: 基盤の構築
- Google Cloud への移行: 大規模なデータセットの転送
- Google Cloud への移行: ワークロードをデプロイする
- Google Cloud への移行: 手動デプロイから、自動かつコンテナ化されたデプロイに移行する
- Google Cloud への移行: 環境を最適化する
- Google Cloud への移行: 移行計画の検証に関するベスト プラクティス
- Google Cloud への移行: 費用を最小限に抑える
次の図は、移行の過程を示しています。
評価フェーズは、Google Cloud への移行の最初のフェーズです。このフェーズでは、Google Cloud に移行するアプリの要件と依存関係を判断します。
このドキュメントは、オンプレミス環境、非公開のホスティング環境、別のクラウド プロバイダからの移行を計画している場合に役立ちます。また、移行の機会を評価する目的、評価フェーズの内容を探る目的にも役立ちます。
移行を成功させるには、評価フェーズが非常に重要です。このフェーズで、移行するアプリとその要件、依存関係、および現在の環境について詳しく把握する必要があります。また、Google Cloud への移行を計画して実施するための出発点も理解する必要があります。
このフェーズでは、次の手順を行います。
- アプリの包括的なインベントリを作成する。
- プロパティと依存関係に応じてアプリを分類する。
- チームを Google Cloud でトレーニングして教育する。
- Google Cloud 上でテストと概念実証を作成する。
- ターゲット環境の総所有コスト（TCO）を計算する。
- 最初に移行するワークロードを選ぶ。
アプリのインベントリを作成する
移行のスコープを設定するには、まず、現在の環境内に存在するアプリやハードウェア アプライアンスなどのアイテムの数と、それぞれの依存関係を理解する必要があります。インベントリを作成するのは簡単な作業ではありません。とりわけ、自動カタログ化システムが整っていない場合は多大な労力を要する作業です。包括的なインベントリを作成するには、現在の環境内の各ワークロードと環境自体の設計、デプロイ、オペレーションを担当するチームの専門知識を活用する必要があります。
インベントリには、アプリだけに限定せずに少なくとも次のアイテムを含めてください。
- 各アプリの依存関係（データベース、メッセージ ブローカー、構成ストレージ システム、その他のコンポーネント）。
- アプリ インフラストラクチャをサポートしているサービス（ソース リポジトリ、継続的インテグレーション（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 コマースの例には、次のサービスがあります。
| 名前 | テクノロジー | その他の要件 | 依存関係 | システム リソースの要件 |
|---|---|---|---|---|
| ソースコード リポジトリ | Git | なし | バックアップおよびアーカイブ システム | 2 CPU コア 4 GB の RAM |
| バックアップおよびアーカイブ システム | ベンダー G、モデル H、バージョン 2.3.0 | 法律により、一部のアイテムは長期間保管する必要がある | なし | 10 CPU コア 8 GB の RAM |
| CI ツール | Jenkins | なし | ソースコード リポジトリ アーティファクト リポジトリ バックアップおよびアーカイブ システム |
32 CPU コア 128 GB の RAM |
| アーティファクト リポジトリ | ベンダー A モデル N バージョン 5.0.0 |
なし | バックアップおよびアーカイブ システム | 4 CPU コア 8 GB の RAM |
| バッチ処理サービス | CI ツール内で実行される cron ジョブ | なし | CI ツール | 4 CPU コア 8 GB の RAM |
| キャッシュ サービス | Memcached Redis |
なし | なし | 12 CPU コア 50 GB の RAM |
ハードウェア
この環境の例には、次のハードウェア アプライアンスがあります。
| 名前 | テクノロジー | その他の要件 | 依存関係 | システム リソースの要件 |
|---|---|---|---|---|
| ファイアウォール | ベンダー H モデル V |
なし | なし | なし |
| サーバー j のインスタンス | ベンダー K モデル B |
サポートされなくなったため、廃止する必要がある | なし | なし |
| NAS アプライアンス | ベンダー Y モデル Z NFS iSCSI |
なし | なし | なし |
デプロイと運用のプロセスを評価する
ワークロードのインベントリを構築したら、デプロイと運用のプロセスを評価することをおすすめします。デプロイと運用のプロセスは、本番環境とそこで実行されるワークロードを準備して維持するプラクティスの基本となる部分です。
これらのプロセスにより、必要なインフラストラクチャがプロビジョニングされ、ワークロードに必要なアーティファクト（オペレーティング システム パッケージ、ワークロード デプロイ パッケージ、オペレーティング システム イメージ、コンテナ イメージなど）がビルドされます。ワークロードごとに、必要なアーティファクトの数、各アーティファクトのタイプ、アーティファクトのビルド方法、アーティファクトの保存方法と保存場所、保存方法に関する情報を収集します。ランタイム構成の挿入方法に関する情報を収集し、これらのアーティファクトを環境間で再利用できるようにします。
デプロイと運用のプロセスを評価したら、これらのプロセスが Google Cloud への移行にどのように役立つか、また移行のスコープとリスクを軽減する方法を評価することもおすすめします。たとえば、移行中に、移行元の環境と Google Cloud の両方にアーティファクトが保存されるように、アーティファクト ビルドプロセスをリファクタリングできます。両方の環境にアーティファクトがあるため、ターゲット環境から最初から Google Cloud 環境にアーティファクト ビルドプロセスを実装しなくても、移行元の環境から Google Cloud へワークロードとデータを移行することに集中できます。
インフラストラクチャを評価する
デプロイ プロセスと運用プロセスを評価したら、移行元の環境で現在ワークロードをサポートしているインフラストラクチャを評価することをおすすめします。
このインフラストラクチャを評価するには、次の点を考慮してください。
- ワークロードに必要なリソースをプロビジョニングするために採用したプロセス（Infrastructure as Code など）。
- 移行元の環境でリソースを整理した方法。たとえば、一部の環境では、組織やプロジェクトなど、リソースのグループを互いに分離する構造を使用してリソースを論理的に分離できます。
- 環境を他の環境（オンプレミス環境や他のクラウド プロバイダなど）に接続した方法。
アプリを分類する
インベントリの作成が完了したら、アプリを各カテゴリに分類して整理する必要があります。分類することで、クラウドにアプリを移行する際の複雑さとリスクに応じて、移行するアプリの優先順位を付けられるようになります。
カタログ マトリックスには、環境内で検討する評価基準ごとに 1 つのディメンションが必要です。各アプリに必要なシステム リソースをはじめ、環境のすべての要件を網羅する一連の基準を選択してください。たとえば、アプリに依存関係があるかどうかという点や、ステートレスまたはステートフルのどちらであるかという点を把握する必要があります。カタログ マトリックスを設計する際は、各基準を追加するごとに、別の表現のディメンションを追加しているのだということを意識してください。最終的なマトリックスを可視化するのは難しい場合があります。この問題を解決するために考えられる方法は、1 つの複雑なマトリックスではなく、複数の小さなマトリックスを使用することです。
また、各アプリの横に、移行の複雑さを示す指標を追加してください。この指標は、各アプリの移行の難易度を推定するものです。この指標の精度は環境によって異なります。基本的な例として、移行の難易度低、難易度高、または移行不可という 3 つのカテゴリに分類します。 このアクティビティを完了するには、インベントリに含まれるアイテムごとに、専門家が移行の複雑さを見積もる必要があります。移行の複雑さを決定する要因は、各ビジネスに固有のものです。
カタログが完成したら、自分とチームが対象の指標を簡単に評価できるよう、図とグラフを作成することもできます。たとえば、依存関係を持つコンポーネントの数や、各コンポーネントの移行の難易度を明らかにするグラフを描画します。
アプリケーションのインベントリを作成する方法については、Migration Center: アセットの検出を開始するをご覧ください。
アプリケーション カタログの例
この例では、マトリックス軸ごとに以下の評価基準のうちの 1 つを使用します。
- ビジネスにとってのアプリの重要度。
- アプリに依存関係があるか、または他のアプリの依存関係となっているか。
- アプリのダウンタイムの最大許容限度。
- アプリ移行の難易度。
| ビジネスにとっての重要性 | 依存関係がない | 依存関係がある | ダウンタイムの最大許容限度 | 難易度 |
|---|---|---|---|---|
| ミッション クリティカル | ステートレス マイクロサービス | 2 分 | 簡単 | |
| ERP | 24 時間 | 高 | ||
| e コマースアプリ | ダウンタイムなし | 高 | ||
| ハードウェア ファイアウォール | ダウンタイムなし | 移行不可 | ||
| SQL データベース | 10 分 | 簡単 | ||
| ソースコード リポジトリ | 12 時間 | 簡単 | ||
| 非ミッション クリティカル | マーケティング ウェブサイト | 2 時間 | 簡単 | |
| バックアップとアーカイブ | 24 時間 | 簡単 | ||
| バッチ処理サービス | 48 時間 | 簡単 | ||
| キャッシュ サービス | 30 分 | 簡単 | ||
| バックオフィス | 48 時間 | 高 | ||
| CI ツール | 24 時間 | 簡単 | ||
| アーティファクト リポジトリ | 30 分 | 簡単 |
カタログの結果を可視化できるよう、図とグラフを作成できます。次のグラフは、移行の難易度を明らかにしています。
上の図から、アプリケーションのうちのほとんどは簡単に移行できる一方、3 つのアプリケーションのみ移行が難しく、1 つのアプリケーションは移行できないことがわかります。
Google Cloud についての学習を組織に提供する
Google Cloud を最大限に活用するには、組織がビジネスで利用できる Google Cloud 上のサービス、プロダクト、テクノロジーについての学び始める必要があります。それには、Google Cloud の無料トライアル アカウントを使用できます。スタッフはトライアル アカウントに含まれるクレジットを使って、サービスやプロダクトを試しながら実践的に学習できます。自由にテストして学習できる環境を作成することは、スタッフの学習体験にとって非常に重要です。
次のトレーニング オプションがあります。
- 一般公開されたオープン リソース: 無料のハンズオンラボ、動画シリーズ、Cloud OnAir ウェブセミナー、Cloud OnBoard トレーニング イベントを利用して Google Cloud について学習できます。
- 詳細なコース: Google Cloud の仕組みをより深く理解するには、Google Cloud Skills Boost のオンデマンド コースまたは Coursera の Google Cloud トレーニング スペシャライゼーションに参加できます。オンライン上で自分のペースでの参加や、世界中の認定トレーニング パートナーによるクラスルーム トレーニングの受講ができます。これらのコースの所要時間は、一般に 1 日から数日です。
- ロールベースの学習プログラム: 組織内でのロールに応じてエンジニアをトレーニングできます。たとえば、Google Cloud サービスの最適な使用方法をトレーニングできる、アプリ開発者向けの学習プログラムとインフラストラクチャ オペレーター向けの学習プログラムがあります。
また、さまざまなレベルの各種認定資格を取得して、Google Cloud に関するエンジニアの知識を認定することもできます。
- アソシエイト認定資格: Google Cloud の入門者にとって、Associate Cloud Engineer 認定資格などのアソシエイト認定資格はプロフェッショナル認定資格の取得に向けた出発点です。
- プロフェッショナル認定資格: 長年の経験で培った Google Cloud の高度な設計と実装のスキルを評価するには、Professional Cloud Architect や Professional Data Engineer などの認定資格を取得できます。
- Google Workspace 認定資格: Google Workspace 認定資格を取得すると、Google Workspace ツールを使用したコラボレーション スキルを実証できます。
- Apigee 認定資格: Apigee 認定 API エンジニア認定資格によって、堅牢で安全かつスケーラブルな API を設計、開発する能力を実証できます。
- Google Developers 認定資格: Associate Android Developer 認定資格（この認定資格は更新中です）と Mobile Web Specialist 認定資格によって、開発スキルを実証できます。
トレーニングと認定資格に加え、プロダクトを使用してビジネスの概念実証を作成することも、Google Cloud の経験を積むのにおすすめの方法の一つです。
概念実証を実験し、設計する
Google Cloud の価値と有効性を明らかにするには、アプリカタログに含まれるアプリの各カテゴリについて 1 つ以上の概念実証（PoC）を設計、開発することを検討してください。実験とテストによって、前提を検証し、ビジネス リーダーにクラウドの価値を実証できます。
概念実証には少なくとも以下の要素を含める必要があります。
- アプリがサポートするユースケースの包括的なリスト。例外的なケースや特殊なケースも含めます。
- 各ユースケースでのすべての要件。パフォーマンスとスケーラビリティの要件、期待される一貫性の保証、フェイルオーバー メカニズム、ネットワーク要件などを含めます。
- 調査とテストの対象のテクノロジーとプロダクトのリスト。
PoC と実験を設計して、リストにあるすべてのユースケースを検証してください。各実験では、正確な有効性のコンテキスト、スコープ、期待される結果、測定可能なビジネスへの影響を考慮する必要があります。
たとえば、需要のピークに対応するために CPU の制約を受けるアプリケーションの 1 つを迅速にスケーリングする必要がある場合、1 つのゾーンで複数の仮想 CPU コアを作成できることと、その処理にかかる時間を検証するための実験ができます。新しいアプリケーションのスケールアップ時間が現在の環境と比べて 95% 短縮されるなど、大幅な付加価値が得られる場合は、Instant Business の価値を実証できます。
オンプレミス データベースのパフォーマンスが Cloud SQL、Spanner、Firestore、Bigtable と比較してどのように評価されるかに関心がある場合、同じビジネス ロジックでさまざまなデータベースを使用した概念実証を実装します。このような概念実証では、さまざまなベンチマークと運用費用の中から適切なマネージド データベース ソリューションを特定する機会を低リスクで得られます。
Google Cloud での VM プロビジョニング プロセスのパフォーマンスを評価するには、PerfKit Benchmarker などのサードパーティ ツールを使用して、Google Cloud を他のクラウド プロバイダと比較できます。ピーク パフォーマンスの標準的な指標（レイテンシ、スループット、完了までの時間など）のレポートに加え、クラウドでリソースをプロビジョニングするためのエンドツーエンドでの時間を測定できます。たとえば、多くの Kubernetes クラスタをプロビジョニングするのにどれだけの時間と労力がかかるか知りたい場合には、このようなツールを使用してください。PerfKit Benchmarker はオープンソース コミュニティの取り組みであり、研究者、学術機関、Google を含む企業など、500 件を超える参加者が関わっています。
総所有コストを計算する
新しい環境で必要となるリソースを明確に把握したら、総所有コストモデルを作成し、それを使用して Google Cloud にかかる費用を現在の環境での費用と比較できます。
総所有コストモデルを作成する際は、ハードウェアとソフトウェアの費用だけでなく、電力、冷却、メンテナンス、その他のサポート サービスなど、独自のデータセンターを運用するための費用のすべても考慮する必要があります。Google Cloud リソースには柔軟なスケーラビリティが備わっていることから、より厳格なオンプレミスのデータセンターと比べると、通常は費用を削減しやすいという点も考慮してください。
クラウドへの移行を検討するときに見落としがちな費用は、クラウド ネットワークの使用料金です。データセンターでは、ルーターやスイッチなどのネットワーク インフラストラクチャを購入して適切なネットワーク ケーブルを配線するための料金を一度支払えば、ネットワークの全容量を使用できます。クラウド環境では、ネットワークの使用に対する課金はさまざまな方法で行われます。データ集約型アプリ、つまり大量のネットワーク トラフィックを生成するアプリの場合、クラウドでのネットワーク コストを削減するには、新しいアーキテクチャとネットワーク フローの検討が必要になることが考えられます。
Google Cloud には、リソースとコストをインテリジェントにスケーリングできるように幅広いオプションも用意されています。たとえば、Compute Engine でのサイズ適正化は、Migrate for Compute Engine による移行中、VM が実行中になった後、またはインスタンスの自動スケーリング グループを作成するときに行うことができます。これらのオプションはサービスの実行費用に大きな影響を与える可能性があるため、十分に調べてから総所有コスト（TCO）を計算する必要があります。
Google Cloud リソースの合計費用を計算するには、料金計算ツールを使用できます。
最初に移行するアプリを選ぶ
現在の環境を完全に把握したら、移行計画を完成させるために、初期の順序として、アプリを移行する順序を決めます。Google Cloud の経験を積んで、環境とアプリを理解してから、この順序を移行中に調整できます。
最初に移行するアプリで、チームは Google Cloud の知識と経験を築くことができます。チームがクラウドを扱って経験を積めば積むほど、移行プロセスの移行フェーズで問題が発生するリスクは低くなり、その後の移行が簡単かつ迅速になります。このため、最初に移行するのに適切なアプリを選ぶことが、移行を成功させる重要な鍵となります。1 つのアプリを選ぶことも、最初の移行リストに複数のアプリを設定することもできます。
最初に移行するアプリを特定するのは複雑な作業ですが、以下の基準がヒントになります。
- アプリのビジネス価値。
- インフラストラクチャの残りの部分と比べ、アプリが独特の方法でデプロイまたは実行されているかどうか。
- アプリの開発、デプロイ、運用を担当するチーム。
- アプリの依存関係の数、種類、範囲。
- アプリを新しい環境で動作させるために必要なリファクタリングの作業。
- アプリのコンプライアンスとライセンスの要件。
- アプリの可用性と信頼性の要件。
ビジネス価値
ビジネス クリティカルではないアプリを選ぶと、メインの業務が保護され、クラウド テクノロジーをまだ学習中のチームが気付かなかったリスクや誤りが及ぼすビジネスへの影響が少なくなります。たとえば、e コマースアプリの主要な金融取引ロジックが実装されているコンポーネントを最初に移行することにした場合、移行中に一つでも誤りがあると、メインの業務に支障をきたします。それよりも、アプリをサポートする SQL データベースを選択するほうが適切です。さらに適切なのは、ステージング データベースを選択することです。
めったに使用されないアプリは選ばないようにしてください。たとえば、わずかなユーザーが 1 年間に数回しか使用しないアプリを選ぶと、低リスクの移行ではあるものの、移行に弾みはつかず、問題を検出して対処するのが困難な可能性があります。
エッジケース
移行するその他のアプリに適用できるパターンを発見できるよう、エッジケースも選ばないようにしてください。最初に移行するアプリを選ぶ際の主要な目標は、ナレッジベースを構築できるよう、組織での共通パターンの経験を積むことです。最初に移行したアプリで学んだ教訓は、他のアプリを移行する際に生かすことができます。
たとえば、アプリの大多数がテストドリブン型開発手法に従って設計され、Python プログラミング言語を使用して開発されている場合、テスト カバレッジがほとんどなく、Java プログラミング言語を使用して開発されたアプリを選んでも、Python アプリを移行するときに適用できるパターンは発見できません。
チーム
最初に移行するアプリを選択する際は、各アプリの担当チームに注目してください。最初に移行するアプリを担当するチームは、非常に意欲的で、Google Cloud とそのサービスを積極的に試そうとするチームであることが理想的です。さらに、ビジネス リーダーシップが、最初にアプリを移行するチームの目標を明確に設定し、プロセス全体を通して積極的にチームの後援とサポートに取り組む必要があります。
たとえば、メインオフィスを拠点とし DevOps などの最新の開発方法を実装した確かな実績を持ち、サイト信頼性エンジニアリングなどに精通した高パフォーマンスのチームが有力候補となります。このようなチームにトップダウン型のリーダーシップによる後援もあり、各アプリの移行に関する明確な目標も設定されていれば、抜群の候補です。
依存関係
他のアプリまたはサービスからの依存関係の数が特に少ないアプリにも注目してください。Google Cloud での経験が限られている場合、依存関係のないアプリを移行する方が簡単です。
他のコンポーネントへの依存関係があるアプリを選ばなければならない場合は、依存関係に疎結合されているアプリを選んでください。最終的に依存関係が使用されなくなるように設計済みのアプリであれば、アプリをターゲット環境に移行する際の負担が軽くなります。たとえば、疎結合のアプリ候補としては、メッセージ ブローカーを使用して通信するアプリ、オフラインで動作するアプリ、またはインフラストラクチャの他の部分の利用不可状態を許容するように設計されたアプリが挙げられます。
ステートフル アプリのデータ移行戦略はありますが、ステートレス アプリにデータの移行が必要になることはほとんどありません。ステートレス アプリの移行では、一時的にデータの一部が現在の環境に置かれ、残りがターゲット環境に置かれるというフェーズを懸念する必要がないため、移行しやすくなります。たとえば、ステートレス マイクロサービスはローカルのステートフルなデータに依存しないため、最初に移行する有力候補です。
リファクタリングの作業
アプリのコードと構成に変更を加える作業に多大な労力をかけるのではなく、移行そのものと Google Cloud に集中できるよう、最初に移行するアプリは最小限のリファクタリングで済むものにしてください。リファクタリングでは、アプリのモダナイゼーションと最適化ではなく、ターゲット環境でアプリを実行できるようにするために必要な変更に焦点を絞ってください。アプリのモダナイゼーションと最適化には、移行の後の方のフェーズで取り組むことができます。
たとえば、構成の変更だけが必要なアプリは、コードベースに変更を実装する必要がなく、既存のアーティファクトを使用できるため、最初に移行するアプリの有力候補です。
ライセンスとコンプライアンス
最初に移行するアプリを選ぶ際は、ライセンスも考慮事項の 1 つになります。アプリに適用されるライセンス条項が、移行に影響する可能性があるためです。たとえば、ライセンスの中には、クラウド環境でのアプリの実行を明示的に禁止しているものもあります。
一部のアプリには単一テナントの要件が適用されるため、ライセンス条項を確認するときは、コンプライアンス要件を念頭に置く必要があります。以上の理由から、最初に移行するアプリとしては、ライセンスとコンプライアンスの制限が最も少ないアプリを選んでください。
たとえば、お客様がデータの保存先リージョンを選択する法的権利を持っている場合や、お客様のデータが特定のリージョンに制限されている場合もあります。
可用性と信頼性
最初の移行候補として有力なのは、カットオーバー期間によるダウンタイムの影響を受けないアプリです。可用性の要件が厳しいアプリを選ぶ場合、Y（書き込み / 読み取り）などのゼロ ダウンタイムのデータ移行戦略を実装するか、データアクセス マイクロサービスを開発する必要があります。このアプローチは可能ですが、チームがこうした戦略の実装に時間を費やさなければならなくなるため、Google Cloud で必要な経験を積むことに集中できなくなります。
たとえば、バッチ処理エンジンの可用性の要件は、e コマースサイトでユーザーがトランザクションを確定するのに使うお客様向けアプリよりも長い時間、ダウンタイムを許容できます。
次のステップ
- 移行を計画し、Google Cloud における基盤を構築する方法を確認する。
- 移行に関するヘルプを調べる方法を確認する。
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センターをご覧ください。