ホーム
お役立ち
Google Service
Google Cloudへの移行方法と手順をご紹介！移行を考える際に知っておくべきこと

Google Cloudへの移行方法と手順をご紹介！移行を考える際に知っておくべきこと

Cloud
クラウド移行
移行方法

公開年月日: 2020.09.08

更新年月日: 2024.09.26

Google Cloudへの移行方法と手順をご紹介！移行を考える際に知っておくべきこと

一般的に既存の環境からクラウド環境への移行は考慮事項が多く、容易なことではありません。今までオンプレミスで何度もデータセンター移行を経験したエンジニアであっても、クラウド固有のアーキテクチャへの変更は非常に困難だと思います。

そこでこの記事では、オンプレミス環境やホスティング、または他クラウドの環境からGoogle Cloudにワークロードを移行する際の様々な考え方やプロセスについて紹介します。ぜひ最後までご覧ください。

クラウド特有の考え方

クラウド環境に移行するにあたり、システムの構成に対して、いままでの環境とは全く異なる考え方を適用する必要があります。ここではいくつかの概念についてご紹介します。

責任分界点

責任分界点
オンプレミス環境は、自社で全ての管理を行い、あらゆるレイヤーにおいて責任を担います。例えばネットワーク機器の敷設やサーバーのケーブリング、ハードウェアのメンテナンス等、環境の全てを自社で管理します。

GCPを初めとしたパブリッククラウドでは、システム全体を管理するのではなく、責任範囲を理解し、自社の管理範囲のみ運用を行います。Google Compute Engineの場合、物理的なレイヤーから仮想化ソフトウェアまではクラウド事業者であるGoogle側で管理を行います。これにより運用負荷を軽減し、アプリケーションの構築に専念することができます。

しかし、全てのレイヤーをクラウド事業者が管理するわけではないことに注意が必要です。クラウド事業者の責任範囲外であるOSやVM上のミドルウェア等に関しては自社で責任を負うため、セキュリティ対策や監視などを実施する必要があります。責任範囲の分界点はサービスによっても異なるため、利用するサービスの責任分界点を理解し、運用のプロセスについて考慮しましょう。

アプリケーションのアーキテクチャ

クラウド環境への移行を想定した場合、アプリケーションの構成についても考慮する必要があります。アプリケーションは、従来型のレガシーなアプリケーションと、クラウド環境に最適化されたクラウドネイティブなアプリケーションの2種類に大別されます。

レガシーなアプリケーションはモノリシックに構成されており、一般にパフォーマンスや運用性、データの一貫性などの面で優れています。一方、クラウドネイティブなアプリケーションのアーキテクチャはマイクロサービス化されており、複雑になる傾向にありますが、耐障害性が高く、スケーリングやデプロイを容易に実施することができます。

アプリケーションの用途や要件によって最適な構成は異なってきます。また、アプリケーションの設計変更にはある程度のワークロードが必要となります。クラウド環境に移行する場合には事前に移行期間や目的、コスト等様々な面から考慮し、最適なアーキテクチャを選定しましょう。

移行方法

上述した点を踏まえ、移行方法は下記の3種類に分類することができます。

Lift & Shift
Improve & Move
Rip & Replace

ここからは、3種類の移行方法の特徴とその選定基準について解説します。

Lift & Shift

Lift_and_Shift
Lift & Shiftでは、アプリケーションの構成変更を実施することなくクラウド環境に移行し、必要な場合にのみ改修を実施する方式です。移行先のクラウド環境でも同じアーキテクチャを利用することができ、移行のワークロードを最小限に抑えることができます。例えば移行元と移行先の環境で同じ仮想化ソフトウェアを利用しており、仮想マシンイメージを利用することができる場合等が該当します。

この移行方法を利用する場合、既存の環境で既に利用している技術や運用手法をクラウド環境でもそのまま継承することができます。そのため、新しい環境でありながら新規スキルの習得コストを最小限に抑え、既存の環境で蓄積されたスキルやノウハウ活用することが可能です。また、構成管理、監視やバックアップといった運用手法についても既存環境の手法を踏襲することができます。

【参考記事】
クラウド移行の王道はLift & Shift！概念からGCP における3つのやり方をご紹介

Improve & Move

Improve_and_Move
Improve & Moveでは、クラウド環境に最適なアーキテクチャとなるようにアプリケーションの構成変更を実施し、移行を行う方式です。アプリケーションの構造はもちろん、実現するための技術やサービス、運用方法も大幅に変更が必要となります。アプリケーションのクラウドネイティブ化を実現することでGoogle Cloudの様々な機能との連携が可能となり、柔軟性や可用性が向上します。

Rip & Replace

Rip_and_Replace
Rip & Replaceでは、既存のアプリケーションのイメージは利用せず、新しい環境にクラウドネイティブアプリケーションを作成し、置き換えを行う方式です。現在利用しているアプリケーションが要件を達成していない場合に課題解決を実施したり、クラウド環境への移行を契機にシステム全体を刷新することが可能です。また、既存アプリケーションのOSやミドルウェアなど、各ソフトウェアスタックのバージョンによっては新規作成を実施した方がコストが抑えられる場合もあります。

移行手順

移行手順
クラウド環境への移行には下記の4つのプロセスが必要です。

1. Assess	アプリケーションと環境の把握のため、既存環境を様々な面から評価します。また、アプリケーションの依存関係を把握し、パフォーマンスを測定することで必要なリソースを計算します。
2. Plan	ワークロードに必要なインフラストラクチャを構築し、アプリケーションの移行戦略を策定します。
3. Deploy	アプリケーションワークロードの移行プロセスを実行します。
4. Optimize	パフォーマンスや柔軟性、障害への復旧など、各種非機能要件を考慮し、環境を最適化します。また、クラウド上のサービスを活用して機械学習や人工知能といった新しい機能をアプリケーションに統合します。

ここからは各プロセスについて詳細を解説していきます。

1. Assess

Assessでは、移行予定のアプリケーションを評価します。

一覧の作成

現在のアプリケーションの依存関係や機能を網羅的に把握するために一覧を作成します。各サーバーが持つハードウェアリソースやその上で実行されているOS、ミドルウェア、ソフトウェアを調査し、リスト化します。

移行対象の選定

必ずしも全てのワークロードがクラウド環境に適しているとは限りません。作成したリストに基づいてアプリケーションのアーキテクチャやその特性を考慮し、移行の難易度を設定します。コストやプロジェクトのスケジュールなどの外部的要因も加味しながら移行対象となるアプリケーションを選定します。

例えばコンプライアンスの観点からクラウド上に出すことのできないデータや、仮想化されていない物理サーバー、ネットワークのアプライアンス機器などはクラウドへの移行が困難である場合があります。

PoCの実施

PoC(Proof of Concept)とは概念実証のことで、新しい概念やアイディアの検証を行うことを指します。

クラウド環境への移行を考える場合、PoCを行うことは非常に重要です。PoCでは簡単なユースケースを想定し、アプリケーションのパフォーマンスや各機能、ネットワークのレイテンシーや帯域など、全体の使用感を含めてクラウド上で実装したい概念を実現可否を確認します。検証の結果によって、移行予定のワークロードの見直しや、移行先のリソースの調整を行います。

コスト計算

クラウドに移行した場合のコストを計算します。コスト計算において最も注意すべきなのは、総コストで計算する必要がある点です。

既存環境のサーバーとクラウドの環境を正確に比較する場合、サーバーの機器コストだけを比較するのではなく、サーバーを設置する際の電気代、冷房代、メンテナンス費用、運用費などを含めて比較する必要があります。Google Cloudの各サービスの価格はこちらの記事を参考にして算出することが可能です。また、Google Cloudのパートナーに依頼することも可能です。

弊社トップゲートもGoogle Cloudのプレミアパートナーですので、ぜひお気軽にお問い合わせください。

2. Plan

Planでは、クラウド上の各サービスとインフラストラクチャを設計し、構成します。

リソース階層の設計

リソース階層
Google Cloudではリソースが階層構造となっています。リソースの最上位は組織と呼ばれる単位で、通常は会社単位で作成します。その下にフォルダを分け、部署やグループ単位などで組織の構造を細分化します。また、そのフォルダの中にプロジェクトを作り、リソースを割り当てます。リソースはの権限設定は上位の階層から継承されるため、組織構造に基づいた権限設定を容易に実現することができます。

リソースアクセスのグループとロールの定義

各リソースに対してアクセス権限を設定します。グループを作成し、ロールを紐付けておくことで、新しくユーザーを追加した場合に権限の設定を容易に行うことができます。

接続方式の検討

既存の環境とGoogle Cloudとのネットワークトポロジーを検討します。Google Cloudとの接続には下記の選択肢が存在します。
接続方式

Direct Peering	外部IPアドレスへの接続を確立します。オンプレミスのネットワークとGoogle エッジネットワークとの間に直接的なピアリングを構成します。SLAの規定はありません。
Carrier Peering	外部IPアドレスとの接続を確立します。サービスプロバイダが提供するネットワークを使用してGoogleのネットワークに接続します。同じくSLAはありません。
Cloud VPN	IPSec VPNを経由してアクセスします。インターネット経由での通信となりますが、暗号化が行われ、比較的低コストで構成することができます。
Dedicated Interconnect	GoogleのいずれかのPOP(接続拠点)にルーターを設置し、専用線を経由してGoogle Cloudとの直接接続を確立します。End to EndでのSLAを提供します。
Partner Interconnect	Googleのコロケーション施設内に敷設済みのサービスプロバイダが管理する回線を利用し、専用線接続を行います。End to EndでのSLAを提供します。

3. Deploy

環境構築が完了し、既存環境との接続を確立した後はアプリケーションをデプロイします。全て手動で実施するのではなく、CI/CDパイプラインやInfrastracture as Codeを活用し、デプロイをできるだけ自動化します。再現性や冪等性が向上し、環境の構築や運用を容易に行うことができます。

4. Optimize

移行先のワークロードを最適化します。

トレーニングの実施

Google Cloudを最大限に活用できるようにエンジニアのトレーニングを行います。トレーニングにより構成を最適化し、適切なサービスを利用できるようになります。

弊社トップゲートも様々なトレーニングを提供しておりますので、ぜひご検討ください。

「Google Cloud Platform トレーニング」提供サービス一覧

モニタリング

環境の監視を行い、システム全体が正常に稼働していることを確認します。Google CloudではCloud LoggingやCloud Monitoringといった環境全体の監視ツールがネイティブで提供されています。パフォーマンスやログを定常的に監視することでシステムの構成やアーキテクチャの最適化を行います。

マネージドサービスの利用

Google Cloudでは、基盤となるインフラストラクチャを管理することなく、機能のみを利用することのできるマネージドサービスが数多く提供されています。ビジネスとしてエンドユーザーに対する価値の提供を考えた場合、インフラストラクチャの管理はできるだけアウトソースし、アプリケーションの開発に注力することが重要です。

例えばコンテナ基盤では、マネージドのKubernetesプラットフォームであるGoogle Kubernetes Engineへの移行を実施することで基盤部分の運用をサービスとして置き換えることができます。

コスト最適化

Google Cloudでは、コスト削減に有用なツールやオプションが数多く用意されています。例えばCompute EngineではCloud Monitoringが収集したパフォーマンスデータに基づいて最適な仮想マシンサイズを提案する機能を利用することができます。さらに、サービスを長期間利用する場合には、継続利用割引により自動的に割引が適用されます。

また、BigQueryでは定額料金制での登録も可能です。以上のように、サービスごとに構成や利用法を検討することでよりランニングコストを抑えてシステムを運用していくことが可能です。

【参考記事】
ランニングコスト削減も可能？開発者が知っておきたいインフラ設計のポイント10選