ホーム
お役立ち
Google Service
クラウド移行のやり方とは？具体的な手順を 4 ステップで徹底解説！

クラウド移行のやり方とは？具体的な手順を 4 ステップで徹底解説！

Cloud
GCP
オンプレミス
移行

公開年月日: 2023.06.09

更新年月日: 2024.11.01

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

そこで本記事では、オンプレミスやホスティングなどの環境からクラウド環境へ移行する際のやり方や考え方に加えて、具体的な手順を 4 ステップで詳しくご紹介します。

クラウド特有の考え方とは？

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

責任分界点

クラウドの責任分界点

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

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

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

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

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

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

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

クラウド移行のやり方とは？

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

Lift & Shift
Improve & Move
Rip & Replace

ここからは 3 種類の移行方法の特徴とその選定基準について解説します。なぜなら、クラウド移行の様々なパターンを理解しておくことで、移行中に発生し得る問題を事前に回避できるためです。

なお、説明に使用する画像の中に「 Google Cloud 」という表記がありますが、以下でご紹介する移行方法は他のクラウドサービスでも基本的には同じ流れになりますので、その点はあらかじめご承知おきください。

Lift & Shift

Lift_and_Shift

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

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

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

Improve & Move

Improve_and_Move

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

Rip & Replace

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

クラウドへの移行手順を 4 ステップで解説

クラウドへの移行手順

本章では、クラウド環境へ移行するための具体的な手順について、 4 つのステップに分けてご説明します。なお、ここでは Google Cloud （GCP）に焦点を当てた内容になっていますが、 AWS や Microsoft Azure などの他クラウドでも大枠の流れは同じです。

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

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

ここからは各プロセスを明確に理解できるよう、詳細を解説していきます。

不要な時間をかけずにスムーズかつ計画的なクラウド移行を実現し、自社の作業工数や手間を削減して業務効率化を図るためにも、ぜひ内容を理解しておきましょう。

1. Assess

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

一覧の作成

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

移行対象の選定

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

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

PoC の実施

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

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

PoC に関心のある方は以下の記事が参考になります。

PoC とは何か？概要やメリット、成功させるためのポイントまで徹底解説！

コスト計算

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

既存環境のサーバーとクラウドの環境を正確に比較する場合、サーバーの機器コストだけを比較するのではなく、サーバーを設置する際の電気代、冷房代、メンテナンス費用、運用費などを含めて比較する必要があります。自社だけでコスト計算をするのが難しい場合は、クラウド事業者に依頼することも可能です。

例えば、 Google Cloud （GCP）の各サービスの価格はこちらの記事を参考にして算出することが可能です。また、 Google Cloud （GCP）のパートナー企業に依頼することも可能です。

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

2. Plan

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

リソース階層の設計

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

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

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

接続方式の検討

既存の環境と Google Cloud （GCP）とのネットワークトポロジーを検討します。

なお、 Google Cloud （GCP）との接続には下記の選択肢が存在します。

GCP接続の選択肢

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

3. Deploy

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

4. Optimize

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

トレーニングの実施

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

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

モニタリング

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

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

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

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

マネージドサービスに関心のある方は以下の記事が参考になります。

マネージドサービスとフルマネージドサービスの違いとは？メリット・デメリットまで徹底解説！

Google Kubernetes Engine （GKE）に関心のある方は以下の記事が参考になります。

コスト最適化

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

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

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