GCP への移行: はじめに

このドキュメントでは、ワークロードを Google Cloud Platform(GCP)に移行するプロセスを計画、設計、実装する際に役立つ情報を提供します。経験豊富なチームであっても、別の環境にアプリを移行するのは容易ではありません。移行を慎重に計画して実施する必要があります。

この記事は、シリーズの最初のパートです。

このドキュメントでは、オンプレミス環境、非公開のホスティング環境、または別のクラウド プロバイダから GCP に移行する計画を作成する際に役立つ情報を提供します。また、移行について検討している場合、その概要を把握するためにも利用できます。

はじめに

GCP への移行を計画する場合は、まず、移行に関わる環境の定義から始めます。出発点は、オンプレミス環境、非公開のホスティング環境または別のパブリック クラウド環境になります。

オンプレミス環境は、自社がすべての所有権を持ち、責任を負う環境です。冷却、物理的な安全対策、ハードウェアのメンテナンスなど、環境のあらゆる側面を管理します。

コロケーション施設などの非公開のホスティング環境では、物理的インフラストラクチャとその管理業務の一部を外部に委託しています。このインフラストラクチャは通常、複数の顧客で共有されています。非公開のホスティング環境では、物理的な安全対策やサービスを管理する義務はありません。ホスティング環境によっては、サーバー、ラック、ネットワーク デバイスなどの物理ハードウェアの一部を自社で管理している場合もあれば、他社がハードウェアの管理を行う場合もあります。通常、電源ケーブルとネットワーク ケーブルはサービスとして提供されるため、自社で管理する必要はありません。物理リソースを仮想化するハイパーバイザー、プロビジョニングする仮想化インフラストラクチャ、このようなインフラストラクチャ上で実行するワークロードはすべて自社で管理します。

パブリック クラウド環境の場合、リソース スタック全体を自社で管理する必要はありません。自社にとって最も重要なスタックに焦点を当てることができます。非公開のホスティング環境と同様に、基盤となる物理インフラストラクチャを管理する必要もありません。さらに、リソースを仮想化するハイパーバイザーの管理も必要ありません。仮想化されたインフラストラクチャを構築し、この新しいインフラストラクチャにワークロードをデプロイできます。また、フルマネージド サービスを購入すると、ランタイム環境の管理作業を気にすることなく、ワークロードに専念できます。

それぞれの環境でリソースと関連サービスの提供と管理を行う担当者は次のようになります。

リソース オンプレミス環境 非公開ホスティング環境 パブリック クラウド環境
物理的な安全対策 自社 サービス プロバイダ サービス プロバイダ
電源ケーブルとネットワーク ケーブル 自社 サービス プロバイダ サービス プロバイダ
ハードウェア(メンテナンス含む) 自社 サービス プロバイダによって異なる サービス プロバイダ
仮想化プラットフォーム 自社 自社 サービス プロバイダ
アプリのリソース 自社 自社 自社(最終的にはフルマネージド サービスを利用)

このドキュメントのターゲット環境は GCP です。

移行前の環境と移行先の環境を定義したら、移行対象となるワークロードの種類と関連する運用プロセスを定義します。このドキュメントでは、従来型とクラウド ネイティブの 2 種類のワークロードと運用について説明します。

従来のワークロードと運用プロセスは、クラウド環境を考慮せずに開発されています。通常、これらのワークロードと運用プロセスはスケーラビリティに対応していないため、変更が容易ではなく、実行とメンテナンスに多額の費用がかかる可能性があります。

クラウド ネイティブのワークロードと運用プロセスはスケーラブルで、移植可能であり、安全に利用できます。このようなワークロードと運用プロセスでは、実際のワークロードに集中できるため、デベロッパーの生産性と俊敏性が向上します。開発環境やランタイム環境の管理に煩わされることなく、煩雑なデプロイ プロセスを手動で行う必要もありません。GCP では、セキュリティに関する共有責任モデルを採用しています。クラウドのセキュリティに対しては、GCP だけでなく、利用者も責任を負います。インフラストラクチャの物理的な安全対策とセキュリティは GCP 側の責任となりますが、インフラストラクチャにデプロイするワークロードのセキュリティは利用者側の責任となります。

このような環境とワークロードの種類を考慮すると、最初の状況は次のいずれかになります。

  • オンプレミス環境または非公開のホスティング環境で、従来のワークロードと運用プロセスを使用している。
  • オンプレミス環境またはプライベート ホスティング環境で、クラウド ネイティブのワークロードと運用プロセスを使用している。
  • パブリック クラウド環境または非公開のホスティング環境で、従来のワークロードと運用プロセスを使用している。
  • パブリック クラウド環境または非公開のホスティング環境で、クラウド ネイティブのワークロードと運用プロセスを使用している。

移行プロセスは出発地によって異なります。

従来のオンプレミス環境や非公開のホスティング環境からパブリック クラウドなどのクラウド ネイティブの環境にワークロードを移行する作業は容易ではなく、リスクを伴います。移行に成功するには、移行プロセスの実施中に、移行するワークロードをできるだけ少なくする必要があります。従来のオンプレミス アプリをクラウドに移行する場合は、複数の移行手順が必要になります。

移行の種類

移行には次の 3 つの種類があります。

  • リフト&シフト
  • 改善して移行
  • 削除して置き換え

以下では、これらの移行タイプの違いと、どの種類を選択すべきかについて、事例を挙げながら説明します。

リフト&シフト

リフト&シフトの場合、変更やリファクタリングをほとんど行わずに、移行前の環境から移行先の環境にワークロードを移行します(変更やリファクタリングをまったく行わない場合もあります)。ワークロードを移行先の環境で実行するために必要な場合に限り、移行するワークロードに変更を行います。

ワークロードを移行先の環境でそのまま実行できる場合や、ビジネス上の変更が必要ない場合(または、ほとんど必要ない場合)は、リフト&シフトが理想的です。このタイプでは、リファクタリングの量が最小限になるため、短時間で移行を行うことができます。

技術的な問題から、リフト&シフトを強制的に行う場合もあります。移行するワークロードのリファクタリングや廃止ができない場合、リフト&シフトで移行する必要があります。たとえば、ワークロードのソースコードを変更することが困難または不可能な場合や、ビルドプロセスが簡単でない場合は、ソースコードのリファクタリング後に新しいアーティファクトが生成されないことがあります。

リフト&シフトの場合、新しい専門知識を必要としません。同じツールとスキルを使用できるので、最も簡単な移行タイプといえます。この移行は、既製のソフトウェアにも対応しています。既存のワークロードを最小限のリファクタリングで移行するため、改善して移行や削除して置き換えと比べると、リフト&シフトによる移行は短い時間で完了する傾向があります。

ただし、リフト&シフトで移行した場合、移行先の環境で実行されるのはクラウド ネイティブでないワークロードになります。これらのワークロードでは、水平方向のスケーラビリティ、きめ細かな料金体系、高度なマネージド サービスなど、Cloud Platform の機能を活用できません。

改善して移行

改善して移動では、移行中にワークロードを最新化します。この移行では、新しい環境で機能するように変更するだけでなく、クラウド ネイティブの機能を利用できるようにワークロードを変更します。これにより、ワークロードのパフォーマンス、機能、費用、ユーザー エクスペリエンスを改善します。

アプリの現在のアーキテクチャやインフラストラクチャが移行先の環境でサポートされていない場合、これらの制限を克服するため、一定のリファクタリングが必要になります。

改善して移行を選択するのは、移行に必要な変更だけでなく、ワークロードの大幅な変更が必要になる場合です。

改善して移行することで、アプリケーションはスケーラビリティや高可用性などの Cloud Platform の機能を利用できるようになります。また、アプリの移植性を高めるために改善を行うこともできます。

改善して移行は、リフト&シフトよりも時間がかかります。これは、アプリの移行でリファクタリングが必要になるためです。アプリのライフサイクルの一部として、追加の時間と作業を評価しておく必要があります。

改善して移動の場合、新しいスキルの習得も必要です。

削除して置き換え

削除して置き換えでは、既存のアプリを廃止し、設計を見直してクラウド ネイティブ アプリに書き換えます。

現在のアプリが目標を達成していない場合(たとえば、アプリのメンテナンスを行いたくない場合、アプリが GCP でサポートされていない場合、前述の方法では移行コストやかかりすぎる場合など)は、削除して置き換えを行います。

削除して置き換えでは、アプリで水平方向のスケーラビリティ、高度なマネージド サービス、高可用性などの GCP の機能を最大限に活用できます。アプリを最初から書き換えるので、既存のレガシー バージョンの技術的な問題も解決されます。

ただし、削除して置き換えは、他の 2 つの移行方法よりも時間がかかります。また、アプリを書き直す必要があるため、既製のアプリの移行には適していません。アプリのライフサイクルの一部として、追加の時間と作業を評価し、アプリの再設計を行う必要があります。

削除して置き換えでは、新しいスキルも必要です。新しいツールチェーンを使用して新しい環境のプロビジョニングと構成を行い、環境にアプリをデプロイする必要があります。

Google Cloud 導入フレームワーク

移行を開始する前に、クラウド テクノロジの導入に対する組織の成熟度を評価する必要があります。Google Cloud 導入フレームワークを利用すると、組織のビジネス情報技術の現状を把握し、目標の達成に何が必要かを確認できます。

このフレームワークを使用すると、次の図のように GCP に対する組織の準備状況を評価し、新しい技術に対応するために必要な作業を確認できます。

4 つのテーマと 3 つのフェーズから構成される Google Cloud 導入フレームワークのアーキテクチャ。

このフレームワークでは、次の 4 つのテーマを評価します。

  • 学習。学習プログラムの質と規模。
  • リード。GCP への移行で IT 部門がサポートされる範囲。
  • スケール。クラウド ネイティブ サービスの使用範囲と、現在の運用プロセスで自動化を行う範囲。
  • 安全性。現行の環境を不正アクセスから保護する能力。

それぞれのテーマごとに、次のどのフェーズにあるかを評価します。

  • 戦術的。すべてのワークロードを網羅する一貫した計画はありません。投資の迅速な回収と IT 組織の混乱を少なくすることに重点が置かれています。
  • 戦略的。将来のスケーリングのニーズに合わせて個々のワークロードを開発する計画があります。業務を合理化し、現在よりも効率的にする中期的な目標に重点が置かれています。
  • 変革期。クラウド運用は円滑に機能し、運用から収集したデータで IT ビジネスを改善しています。IT 部門を組織のイノベーションの原動力の 1 つにするという長期的な目標に重点が置かれています。

4 つのトピックを 3 つのフェーズで評価することで、クラウド技術に対する組織の成熟度を測ることができます。それぞれのテーマで、新しいテクノロジを採用したときに、どのような変化が起きるかを把握できます。組織全体でより戦略的に取り組むには、チームでより包括的で一貫したトレーニングを行う必要があります。

移行パス

移行プロセスは始まったばかりです。まだ、A 地点で既存のインフラストラクチャと環境を使用しています。ここから B 地点に移動します。この A から B に移動するときに、前述のいずれかのオプションを選択します。

次の図は、移行パスを表しています。

4 フェーズの移行パス

移行には 4 つのフェーズがあります。

  • 評価。このフェーズでは、アプリと環境を把握するため、既存の環境を徹底的に評価します。アプリの依存関係と要件を特定し、総所有コストを計算して、アプリのパフォーマンス ベンチマークを設定します。
  • 計画。このフェーズでは、ワークロードに基本的なクラウド インフラストラクチャを構築し、アプリの移行方法を計画します。たとえば、ID の管理、組織とプロジェクトの構造、ネットワーキング、アプリの並べ替え、優先度に従った移行戦略などを計画します。
  • デプロイ。このフェーズでは、ワークロードを GCP に移行するデプロイ プロセスを設計、実装、実行します。また、新しい要件に合わせてクラウド インフラストラクチャの修正が必要になることもあります。
  • 最適化。このフェーズでは、パフォーマンス、スケーラビリティ、障害復旧、コスト、トレーニングなど、クラウド ネイティブのテクノロジと能力を最大限に活用し、ビジネスの可能性を広げることができます。さらに、アプリに機械学習や人工知能を統合することもできます。

移行フェーズ 1: 評価

評価フェーズでは、移行するワークロードと現在のランタイム環境に関する情報を収集します。

一覧を作る

移行を成功させるには、現在の環境にどのようなアプリ、データベース、メッセージ ブローカー、データ ウェアハウス、ネットワーク アプライアンスが存在し、どのような依存関係があるのかを理解する必要があります。そのためには、環境内のすべてのマシン、ハードウェアの仕様、オペレーティング システム、ライセンス、それぞれのマシンで実行されているアプリとサービスの一覧を作成します。

カタログアプリ

一覧を作成したら、カタログのマトリックスを作成します。これにより、GCP への移行の複雑さとリスクに基づいて、アプリをカテゴリに分類します。

次の表に、カタログ マトリックスの一例を示します。

依存関係がない 依存関係がある
ミッション クリティカル
  • ステートレスのマイクロサービス(中程度)
  • ERP(難しい)
  • OLTP データベース(難しい)
  • e コマースアプリ(難しい)
  • データ ウェアハウス(難しい)
  • ファイアウォール アプライアンス(不可能)
ミッション クリティカル以外
  • マーケティング ウェブサイト(簡単)
  • バックアップとアーカイブ(簡単)
  • 開発環境とテスト環境(簡単)
  • バッチ処理(簡単)
  • バックオフィス(難しい)
  • データ分析(難しい)

このカタログ マトリックスの例には 2 次元の評価基準が含まれています。アプリによっては、次元数や考慮事項の追加が必要になる場合があります。マトリックスには環境固有の要件をすべて含めます。

GCP について組織に説明する

評価フェーズの一部として、組織で GCP について学習する必要があります。ソフトウェア エンジニアとネットワーク エンジニアを対象に、クラウドの仕組み、利用できる GCP プロダクト、ワークロードを GCP にデプロイする際の使用するフレームワーク、API、ライブラリについて研修を行い、習熟度を確認する必要があります。

概念実証を選択してテストする

評価フェーズのもう 1 つの重要な部分は、概念実証(PoC)の選択と実装です。また、ユースケースや不確実性のある領域を検証するため、GCP プロダクトでテストを行う必要があります。

以下のようなユースケースが考えられます。

テストごとに、次のようなビジネスへの影響を測定します。

  • 現在の環境と比較して、GCP で仮想 CPU コア数が 50,000 になるまでの時間が 95% 短縮された場合、特定の要因により、市場投入までの時間が短縮されます。これにより、重要な基幹業務のダウンタイムが減少するため、障害復旧環境のセットアップ時間にも影響を及ぼします。
  • グローバルで常時稼働の障害復旧プランを利用できる場合、アプリの信頼性を高めることができます。
  • クラウド スケーリング テクノロジーにより、リソースの需要が低いときにスケールダウンし、需要が高くなったときにスケールアップします。これにより、サービスの総コストを抑えることができます。

総所有コストを計算する

総所有コストモデルを構築すると、現在のコストと GCP へ移行後のコストを比較できます。GCP 料金計算ツールなどのツールや、パートナー サービスを利用することもできます。オンプレミスまたは独自のデータセンターで運用する場合の運用コスト(電力、冷却、メンテナンス、総所有コストに影響を与える他のサポート サービス)の計算も忘れずに行ってください。

最初に移行するワークロードを選択する

移行の準備をするため、最初に移行する機能を提供するアプリを特定します。アプリを 1 つだけ選択することも、最初の移行リストに複数のアプリを設定することもできます。このリストを使用してクラウド環境でアプリのテストを行うことで、アプリの複雑さを気にすることなく、移行に専念できます。それほど複雑でないアプリから移行することで初期のリスクを軽減できます。チームが習得した新しい技術を後から適用すると、アプリの移行が難しくなります。

最初の移行する対象の選択は難しい場合もありますが、次のような条件を満たす候補を選択してください。

  • ビジネスにクリティカルでない。クラウド技術に対するチームの経験が少ないため、このようなワークロードを移行しても、メインの業務に支障をきたすことはありません。
  • エッジケースでない。移行する他のワークロードに同じパターンを適用できます。
  • 知識ベースの構築に使用できる。
  • GCP への移行に熱心に取り組んでいるチームがサポートしている。
  • 他のワークロードを移行したチームが移行を行う。最初のワークロードを移行すると、その経験を将来のワークロードの移行に生かすことができます。
  • 依存関係のないワークロード。たとえば、ステートレスのワークロードは他のワークロードに影響を及ぼすことなく、また、構成の変更が最小限で済むため、移行が容易です。
  • アプリの変更やリファクタリングが最小限で済む。
  • 大量のデータを移行する必要がない。
  • 厳格なコンプライアンス要件がない。
  • サードパーティの独自ライセンスが不要。プロバイダがクラウドでの使用を許可していない場合や、ライセンス タイプの変更が必要になる場合があります。
  • カットオーバー期間のダウンタイムによる影響を受けない。たとえば、現行のデータベースからデータをエクスポートしてから、計画されたメンテナンス期間中に GCP のデータベース インスタンスにインポートする場合があります。2 つのデータベース インスタンスを同期して、ダウンタイム ゼロで移行する場合は、移行プロセスが複雑になります。

移行フェーズ 2: 計画

このフェーズでは、GCP 上のワークロードをサポートするクラウド インフラストラクチャとサービスをプロビジョニングし、構成します。重要な構成やサービスの基盤を構築する作業は終わりがありません。ルール、ガバナンス、設定を決める場合は、後で変更できるように余裕を持たせてください。選択肢を狭めるような判断は避けましょう。後で変更が必要になったときに備えて、変更を対応できるオプションを用意しておく必要があります。

移行を計画する場合、次の作業を行います。

  • ユーザー ID とサービス ID を設定する。
  • リソースの組織を設計する。
  • リソース アクセス用のグループと役割を定義する。
  • ネットワーク トポロジを設計し、接続を確立する。

ID を設定する

GCP では、次のタイプの ID を使用できます。

  • Google アカウント。GCP を操作する個々のユーザーに属するアカウント。
  • サービス アカウント。ユーザーではなく、アプリまたはサービスに属するアカウント。
  • Google グループ。Google アカウントの名前付きコレクション。
  • G Suite ドメイン。組織の G Suite アカウントに作成された仮想グループで、すべての Google アカウントが含まれます。
  • Cloud Identity ドメイン。これは G Suite ドメインに似ていますが、G Suite アプリケーションにアクセスすることはできません。

詳しくは、各 ID タイプの説明をご覧ください。

たとえば、GCP を Active Directory と連携すると、ハイブリッド環境で一貫した認証と承認を行うことができます。

リソースの組織を設計する

アプリに必要な ID を設定したら、アプリで使用するプロジェクト、フォルダ、バケットなどのリソースに対する権限を付与します。具体的には、各 ID に役割を割り当てます。役割は権限のコレクションです。権限は、リソースに対して許可されている操作のコレクションです。

同じ構成ステップを繰り返さないように、さまざまなタイプの構造にリソースをまとめます。これらの構造は階層構造になっています。

  • 組織はリソース階層のルートで、会社などの実際の組織を表します。組織にはフォルダとプロジェクトを含めることができます。組織管理者は、その組織に含まれているすべてのリソースに権限を付与できます。
  • フォルダは、プロジェクトを分離する追加層で、組織内のサブ組織と考えることができます。フォルダには他のフォルダやプロジェクトを含めることができます。管理者は、フォルダを使用して管理者権限を委任できます。
  • プロジェクトは基本的な組織エンティティであり、他の GCP リソースにアクセスする際に使用する必要があります。デプロイして使用するリソース インスタンスはすべてプロジェクトに含まれます。

リソースは親ノードから権限を継承します。同じ親を持つリソースに同じ構成手順を繰り返す必要はありません。Cloud Identity and Access Management(Cloud IAM)の継承メカニズムの詳細については、Resource Manager のドキュメントポリシーの継承をご覧ください。

組織、フォルダ、プロジェクトはリソースで、他の GCP リソースと同様に一連の操作をサポートします。他の GCP リソースと同様に、これらのリソースを操作できます。たとえば、Resource Manager API を使用して階層の作成を自動化できます。また、必要に応じてリソース階層を整理できます。各階層のルートノードは常に組織です。以下では、組織に実装できる階層の種類について説明します。階層タイプによって実装の複雑さと柔軟性が異なります。

環境指向の階層

環境指向の階層では、環境ごとに 1 つのフォルダを使用します。

次の図は、環境指向の階層の例を示しています。

環境指向の階層のアーキテクチャ。

ここには、開発、品質保証、本番環境という複数の環境が存在します。各環境には、My App 1 と My app 2 という 2 つのアプリのインスタンスが存在します。

この階層は 3 つのレベルしかないため、実装は簡単ですが、複数の環境で共有されているサービスをデプロイする場合は、実装が複雑になる可能性があります。

機能指向の階層

機能指向の階層では、IT や管理など、ビジネス機能ごとに 1 つのフォルダを使用します。1 つのビジネス機能のフォルダには、複数の環境フォルダを含めることができます。

次の図は、機能指向の階層の例を示しています。

機能指向の階層のアーキテクチャ。

この階層では、アプリ、管理、IT というビジネス機能が存在しています。My アプリのインスタンスだけでなく、Jira や Website などの共有サービスもデプロイされています。

このオプションは環境指向の階層よりも柔軟で、同じ環境を分離できるだけでなく、共有サービスもデプロイできます。ただし、機能指向の階層は環境指向の階層よりも管理が複雑になります。環境指向の階層では、営業や財務などの事業単位ごとにアクセス権を区別することはありません。

アクセス指向のきめ細かい階層

アクセス指向のきめ細かい階層では、営業や財務など、1 つの事業単位に 1 つのフォルダが使用されます。1 つの事業単位フォルダには、ビジネス機能ごとに 1 つのフォルダを含めることができます。1 つのビジネス機能フォルダには、環境ごとに 1 つのフォルダを含めることができます。

次の図は、アクセス指向のきめ細かい階層の例を示しています。

アクセス指向の階層構造。

この階層には、複数の事業単位、ビジネス機能、環境が存在します。My app 1 と My app 2 アプリの複数のインスタンスと、共有サービス、Net host がデプロイされています。

この階層は最も柔軟で、拡張性の高いオプションです。その反面、構造、役割、権限の管理は煩雑になります。他のオプションと比べるとプロジェクトの数が多くなるため、ネットワーク トポロジもかなり複雑になる可能性があります。

リソース アクセスのグループと役割を定義する

リソースに必要なアクセス権を付与するには、グループと役割を設定する必要があります。GCP では、組織内のリソースに管理者のアクセス権を委任できます。その場合、少なくとも次の役割が必要です。

  • 組織管理者。Client IAM ポリシー、組織の階層、組織のリソースを定義します。
  • ネットワーク管理者。ネットワーク、サブネットワーク、Cloud RouterCloud VPNCloud Load Balancing などのネットワーク デバイスを作成し、構成します。また、セキュリティ管理者とともにファイアウォール ルールを維持する責任があります。
  • セキュリティ管理者。組織とそのリソースにポリシーと制約を設定し、プロジェクトの新しい Cloud IAM 役割を構成します。また、ログとリソースの可視性を維持します。
  • 課金管理者。請求先アカウントを構成し、組織全体のリソース使用量と費用をモニタリングします。

ネットワーク トポロジを設計して接続を確立する

計画フェーズの最後のステップは、ネットワーク トポロジを設計し、既存の環境から GCP への接続を確立することです。

プロジェクトを作成して ID を作成したら、少なくとも 1 つの Virtual Private Cloud(VPC)ネットワークを構築する必要があります。VPC を使用すると、複数のリージョンにまたがる非公開のグローバル アドレス空間を使用できます。リージョン間の通信に公共のインターネットを使用しません。VPC を作成してアプリの一部を分離することも、複数のプロジェクトにまたがる共有 VPC を作成することもできます。VPC を設定したら、Stackdriver を使用してネットワーク フローのロギングファイアウォール ルールのロギングも構成します。VPC とその設定方法については、VPC 設計のベスト プラクティスとリファレンス アーキテクチャをご覧ください。

GCP では、既存の環境を GCP プロジェクトに接続する多くのハイブリッド接続オプションが用意されています。

  • 公共のインターネット
  • Cloud VPN
  • ピアリング
  • Cloud Interconnect

公共のインターネットを利用した接続は、Google の既存のエッジ ネットワークを使用する復元性の高いインフラストラクチャで支えられているため、シンプルで安価な接続オプションといえます。ただし、このインフラストラクチャはプライベートでも専用でもありません。このオプションのセキュリティは、それぞれの接続でデータを交換するアプリに依存します。このため、暗号化されていないトラフィックの送信に、このタイプの接続を使用することはおすすめしません。

Cloud VPN は、IPSec トンネルを使用して既存のネットワークを GCP に接続します。暗号化されたトラフィックが公共のインターネットを介して 2 つのネットワーク間を移動します。Cloud VPN の場合、追加の構成が必要で、接続のスループットに影響を与える可能性がありますが、アプリレベルでトラフィックを暗号化しない場合や、プライベートな GCP リソースにアクセスする必要がある場合は、これが最適な選択肢になります。

ピアリングを使用すると、プライベート チャンネルを介して Google のネットワークまで接続を拡張できます。ピアリングには次の 2 つの種類があります。

  • ダイレクト ピアリング。お客様のネットワークと Google のエッジ ネットワークとの間に直接的なピアリング接続を確立できます。GCP でプライベート リソースにアクセスする必要がなく、Google のピアリング要件を満たしている場合は、これが最適な選択肢となります。サービスレベル契約(SLA)はありませんが、このオプションを使用すると、Cloud VPN の公共インターネット経由のアクセスに対する下り料金を削減できます。
  • キャリア ピアリングサービス プロバイダが管理するエンタープライズ クラスのネットワーク サービスを使用して、Google のネットワークに接続します。Google はこの接続オプションに関する SLA を提供していませんが、サービス プロバイダの SLA で網羅されている可能性があります。このオプションの料金設定を評価する際は、GCP の下り料金とサービス プロバイダの費用の両方を考慮する必要があります。

Cloud Interconnect は、可用性が高い接続を通して、ネットワークを Google のネットワークまで拡張します。デフォルトでは、暗号化されたチャネルは提供されません。このオプションを使用する場合は、アプリ単位で重要なトラフィックを暗号化することをおすすめします。Cloud Interconnect には次の 2 つのオプションがあります。

  • Cloud Interconnect – Dedicated。10 Gbps 以上の高帯域幅でプライベート接続が可能ですが、コロケーション施設にはルーティング機器が必要です。つまり、Google のいずれかの接続拠点(PoP)で Google に接続する必要があります。Google では Dedicated Interconnect 接続にエンドツーエンドの SLA を提供しています。専用の帯域幅とアタッチメントの数に基づいて課金されます。
  • Cloud Interconnect – Partner。Google のコロケーション施設で、サービス プロバイダが管理する専用の高帯域幅をプライベート接続に使用できます。ルーティング機器を構成する必要はありません。Google は、Google とサービス プロバイダとの間の接続に SLA を提供します。サービス プロバイダが、お客様とプロバイダの間の接続に SLA を提供する場合があります。Partner Interconnect では、接続容量と相互接続を通過する下りトラフィックの量に基づいて課金されます。サービス プロバイダから請求される可能性もあります。

移行フェーズ 3: デプロイ

GCP 環境の基盤を構築したら、ワークロードのデプロイを開始できます。デプロイ プロセスを実装し、移行中にプロセスを修正できます。移行作業が進むにつれ、環境基盤の再検討が必要になることもあります。新しいクラウド環境、プラットフォーム、サービス、ツールに慣れるにつれ、新しいニーズが生まれる可能性があります。

ワークロードのデプロイ プロセスを設計する際は、必要な自動化と柔軟性を考慮する必要があります。手動プロセスから自動プロセスまで、複数の導入プロセスを選択できます。

完全な手動デプロイ

プロビジョニング、構成、デプロイをすべて手動で行うと、プラットフォームとツールをすばやく試すことができますが、エラーが発生しやすくなります。また、多くの場合、ドキュメント化されていないため、再現性もありません。このため、他に選択肢がない場合を除き、すべてのデプロイを手動で行わないようにしてください。たとえば、GCP Console で Compute Engine インスタンスなどのリソースを手動で作成し、コマンドを手動で実行してワークロードをデプロイできます。

構成管理ツール

構成管理(CM)ツールを使用すると、環境の構成を自動的に行うことができます。この構成は、繰り返し可能な方法で実行できます。CM ツールを使用すると、環境を構成し、ワークロードをデプロイできます。完全な手動デプロイと比較すると、これは優れたプロセスです。手動デプロイの場合、ダウンタイムなしの配備や Blue / Green デプロイメントなど、複雑なデプロイを実装する機能はありません。一部の CM ツールでは、独自のデプロイ ロジックを実装し、このように不足している機能を補完できます。ただし、CM ツールをデプロイツールとして使用すると、デプロイ プロセスが複雑になり、専用のデプロイツール チェーンよりも管理やメンテナンスが難しくなります。カスタマイズされたデプロイ ソリューションの設計、構築、メンテナンスは運用チームに多大な負担をかけることになります。

コンテナ オーケストレーション

すでにコンテナ化を行っている場合は、Google Kubernetes Engine(GKE) などのサービスを使用して、ワークロードをオーケストレートできます。Kubernetes でコンテナをオーケストレートすると、基盤となるインフラストラクチャやデプロイメント ロジックを気にする必要がなくなります。

デプロイの自動化

継続的インテグレーションとデプロイ(CI / CD)パイプラインなどの自動アーティファクトの作成とデプロイ プロセスを実装すると、アーティファクトの作成とデプロイを自動化できます。このプロセスは完全に自動化できます。また、必要に応じて手動の承認手順を挿入することもできます。

このプロセスの実装例については、Spinnaker と Google Kubernetes Engine を使用した継続的デリバリー パイプラインをご覧ください。

Infrastructure as Code

CI / CD パイプラインを実装することでデプロイ プロセスを自動化できますが、インフラストラクチャにも同様のプロセスを導入できます。インフラストラクチャをコードとして定義すると、ワークロードの実行に必要なすべてのリソースを自動的にプロビジョニングできます。この種のプロセスでは、インフラストラクチャをより観察可能で再現可能なものにします。テストドリブンな開発をインフラストラクチャに適用することも可能です。ただし、インフラストラクチャをコードプロセスとして実装するには、時間と労力を費やす必要があるため、移行を計画する際にはこの点を考慮に入れてください。

Cloud Deployment Manager は、インフラストラクチャを GCP 上のコードプロセスとして実装する際に役立つツールです。

移行フェーズ 4: 最適化

ワークロードをデプロイしたら、移行先の環境の最適化を始めることができます。この最適化フェーズでは、次のアクティビティがこの環境の最適化に役立ちます。

  • チームを編成してトレーニングする
  • すべてをモニタリングする
  • すべてを自動化する
  • すべてをコード化する
  • セルフマネージドではなく、マネージド サービスを使用する
  • パフォーマンスとスケーラビリティを最適化する
  • コストを削減する

チームを編成してトレーニングする

移行を計画するときに、新しいクラウド環境を最大限に活用できるように、開発チームと運用チームのトレーニングを行います。効率的なトレーニングを行うだけでなく、最適なクラウド ネイティブ ツールやサービスを選択することもできます。トレーニングを実施することで技術力を維持し、エンジニアが GCP をフルに活用できるようになります。

このフェーズでは、チームを管理するビジネス プロセスの見直しも行います。これらのプロセスで非効率な作業や不要な作業が見つかった場合は、プロセスを修正し、トレーニングで作業効率を高めることができます。

すべてをモニタリングする

モニタリングを行い、環境内のすべてが想定どおりに機能していることを確認します。これは、環境やプロセスの改善に役立つ重要な作業です。

環境で本番環境のトラフィックを処理する前に、モニタリング システムを設計して実装することをおすすめします。このシステムで、ワークロードを含む環境とコンポーネントの正常な動作を評価する指標を定義します。たとえば、コンテナ化されたインフラストラクチャをデプロイする場合、Prometheus と Stackdriver を使用してホワイトボックスのモニタリング システムを実装できます。また、Stackdriver と Cloud Functions を使用して Cloud IoT Core デバイスをモニタリングできます。

また、Stackdriver のアラートなどの警告システムを設定することをおすすめします。重大なエラーや条件にアラートを設定するだけでなく、ユーザーに影響を与える前に問題を解決できるように警告を設定する必要があります。

Stackdriver ログの保存期間は限られているため、長期保存用に Stackdriver ログをエクスポートできます。また、このようなログから抽出された指標を分析して環境のパフォーマンスを把握し、計画の改善を行うことができます。

すべてを自動化する

手動での操作はエラーが発生するリスクが高く、また時間もかかります。デプロイ、シークレットの交換、構成の更新など、重要なアクティビティの大半は自動化が可能です。自動化は、コストの削減と時間の節約だけでなく、リスクの軽減にも役立ちます。同じ作業を繰り返し行う必要がないため、チームの作業効率も向上します。 GCP での自動化の例としては、Cloud Composer によるインフラストラクチャの自動化Spinnaker を使用した Google Kubernetes Engine でのカナリア分析の自動化などがあります。

すべてをコード化する

GCP でターゲット環境をプロビジョニングする場合は、コード内でできるだけ多くの側面をキャプチャするようにします。infrastructure-as-codepolicy-as-code などのプロセスを実装することで、環境を完全に監査可能で、再現可能な状態にできます。コード以外の部分にもテストドリブンな開発方法を適用すると、環境に予定している変更についてすぐにフィードバックを得ることができます。

セルフマネージドではなく、マネージド サービスを使用する

GCP には、基盤となるサーバーやインフラストラクチャを管理することなく使用できるサービスとプロダクトが用意されています。最適化フェーズでは、こうしたサービスを使用するようにワークロードを拡張するか、既存のワークロードの一部をこれらのサービスで置き換えることができます。

マネージド サービスの例としては、次のようなものがあります。

  • 独自の MySQL クラスタを管理する代わりに、Cloud SQL for MySQL を使用する。
  • 独自の機械学習モデルをデプロイして維持するのではなく、Cloud AutoML を使用して画像のタグ付けと分類を行う。
  • 独自のセルフマネージド Kubernetes クラスタを使用せずに GKE にワークロードをデプロイするが、VM をコンテナに移行して GKE で実行する。
  • サーバーレスのウェブ ホスティングに App Engine を使用する。

パフォーマンスとスケーラビリティを最適化する

クラウドに移行するメリットの 1 つはリソースへのアクセスです。既存のリソースを強化するだけでなく、必要に応じてリソースを追加できます。また、不要なリソースをスケーラブルに削除できます。

オンプレミス環境に比べると、より多くのパフォーマンス最適化オプションを使用できます。

コストを削減する

GCP には、コストの削減に役立つさまざまなツールと料金オプションが用意されています。

たとえば、Compute Engine インスタンスをプロビジョニングした場合、これらのインスタンスの推奨サイズを適用できます。

請求額を減らすには、請求レポートを分析して支出傾向を調べ、最も頻繁に使用している GCP プロダクトを特定します。また、BigQueryファイルに課金データをエクスポートすることもできます。

GCP には、Compute Engine の請求に対して自動的に割引を適用する継続利用割引などの機能があります。これにより、さらにコストを抑えることができます。Compute Engine インスタンスの割引価格ではなく、確約利用契約を購入することもできます。BigQuery の場合、定額料金で登録することもできます。GCP の自動スケーリング機能は、クライアントのリクエスト要求に応じてリソースを縮小します。また、請求額の削減にも役立ちます。Stackdriver の使用量を最適化することで、モニタリングとロギングのコストを抑えることができます。

サポート

GCP では、GCP サービスを最大限に活用していただくため、必要なヘルプやサポート情報を検索するオプションとリソースを提供しています。

セルフサービス リソース

専用サポートが不要な場合、次のリソースを使用できます。

  • ドキュメントをご覧ください。GCP では、そのプロダクトとサービス、API に関するドキュメントを用意しています。移行の詳細については、GCP 移行センターをご覧ください。
  • ツール。GCP では、移行を支援するためにいくつかのプロダクトとサービスを提供しています。次に例を示します。
    • Migrate for Compute Engine は、物理サーバーと仮想マシンをオンプレミス環境やクラウド環境から GCP に移行するためのプロダクトです。Compute Engine に移行すると、GCP に数分で仮想マシンを移行できます。データはバックグラウンドでコピーされますが、仮想マシンは完全に機能しています。
    • gsutil コマンドライン ツールCloud Storage JSON API または GCP Console を使用した Cloud Storage へのオンライン転送。
    • Storage Transfer Service を使用すると、他のクラウド プロバイダ、オンライン リソースまたはローカルデータから Cloud Storage にデータを転送できます。
    • Transfer Appliance は、業務を中断することなく、大量のデータ(数百テラバイトから 1 ペタバイトまで)を GCP に移行できるハードウェア アプライアンスです。
    • BigQuery Data Transfer Service は、スケジュールに基づく管理された方法で、Software-as-a-Service アプリから BigQuery へのデータ移動を自動化します。
  • ホワイトペーパー。これらのドキュメントには、リファレンス アーキテクチャ、事例紹介、ベスト プラクティス、高度なチュートリアルが含まれています。
  • メディア コンテンツ。GCP ポッドキャストを視聴できます。GCP YouTube チャンネルの動画も閲覧できます。商品説明から開発戦略まで、幅広いトピックを取り上げています。
  • オンライン コースとハンズオンラボ。GCP では、動画コンテンツ、読みもの、ハンズオンラボなどの Coursera に関するコースに登録できます。Qwiklabs を使用するか、ハンズオンラボに参加して、ハンズオンラボを利用することもできます。

技術パートナー

GCP は、複数の企業と提携し、お客様の製品を使用できるようにします。一部のサービスは無料でご利用いただけますので、GCP アカウント マネージャーまでお問い合わせください。

これらのプロダクトには、次のものが含まれています。

システム インテグレータ

GCP では、プロダクトやテクノロジ企業だけでなく、キーボード操作を説明できるシステム インテグレータとも提携しています。パートナー リストには、クラウドへの移行に特化したシステム インテグレータも含まれています。

GCP Professional Services

Google のプロフェッショナル サービスチームは、GCP への投資を十分に活用できるようにサポートします。

Cloud Plan and Foundations: 移行を支援

プロフェッショナル サービスでは、Cloud Plan and Foundations サービスを使用して、移行計画を作成し、本番環境にワークロードのデプロイできます。ワークロードの本番環境への移行が完了するまで、GCP 基盤の設定、独自のワークロード要件によるプラットフォームの最適化、ワークロードのデプロイなどのガイダンスがプロセスの各フェーズで提供されます。

Cloud Plan and Foundations の目的は次のとおりです。

  • GCP の基盤を設定する
  • 設計ドキュメントを作成する
  • デプロイと移行の作業を計画する
  • ワークロードを本番環境にデプロイする
  • 問題とリスクを追跡する

プロフェッショナル サービスは、次のアクティビティの結果と成果物をチームに提供します。

  1. 技術的なキックオフ ワークショップを実施する
  2. 技術設計書を作成する
  3. 移行計画を作成する
  4. プログラム チャーターを作成する
  5. プロジェクト管理を行う
  6. 技術的な専門情報を提供する。

Cloud Sprint: GCP への移行を加速化

Cloud Sprint は、GCP への移行を加速化させる集中型のハンズオン ワークショップです。このワークショップで、GCP プロフェッショナル サービスは対話型ディスカッション、ホワイトボード セッション、GCP に移行するターゲット アプリを見直します。Cloud Sprint の実行時に、プロフェッショナル サービスはチームメンバーをサポートしてクラウド ソリューションの利用方法を紹介します。また、今後の GCP 移行の次の手順も確認できます。

トレーニング: チームのスキルを磨く

GCP プロフェッショナル サービスでは、チームのニーズに基づいた分野でトレーニングを行います。

次のステップ