リフト アンド シフト(Lift & Shift)とは?クラウド移行への手順や課題、違いを解説
【入場無料】TD SYNNEX主催のIT展示会「Inspire 2024」10/24(木)東京国際フォーラムにて開催!
近年、ITシステムはクラウド環境が主流となっています。これまでオンプレミスで稼働していた業務システムも、特殊な要件があるシステム以外はオンプレミスからクラウドへ移行する企業が増えています。運用やコスト面などでクラウドはオンプレミスよりメリットが多いと言われているのが理由です。そんなクラウドに移行する際に知っておきたい、「リフトアンドシフト」についてわかりやすく解説します。
リフト アンド シフトとは?
リフト アンド シフトとは、企業などの情報システムをクラウドへ移行するクラウドマイグレーション(クラウド移行)の手法の一つです。これまでオンプレミス環境で存在していた業務システムをそのままクラウド上に移行(Lift)し、そのうえで必要な部分のみ改修を行って、リフト完了後はクラウド環境に最適化(Shift)します。
このシフト(Shift)とは、クラウドへ持ち込んだ業務システムを徐々にクラウド環境に最適化していくこと。もともとオンプレミスで運用していたシステムは、そのままクラウド環境で利用することはできません。クラウドの特性を踏まえながら、自社の生産性向上や業務効率化に繋がるよう、少しずつシステムに修正を加えていきます。
クラウドリフトを行えばクラウド環境に移行できますが、クラウド上ではあまり効率的でない可能性があります。そのため、リフトを行った後でクラウドに最適化し、生産性の向上につながる改修を行うことも多いです。リフト アンド シフトを利用することで、移行先のクラウド環境でも同じアーキテクチャを利用でき、移行にかかる手間を最小限に抑えることが可能です。例えば、移行元と移行先の環境で同じ仮想化ソフトウェアを利用しており、仮想マシンイメージを利用することができる場合等が該当します。リフト アンド シフトはクラウドシフトほど大きな手間をかけず、これまでのシステムを活用しながらクラウド環境に移行できるのです。
クラウドへのリフトとシフトの違い
これまでオンプレミスだったシステムをクラウドにする際に取れる方法は、クラウドシフトとクラウドリフトの2つです。いずれもクラウドに移行するアプローチである点は同じですが、移行方法が異なります。
クラウドシフトとは、これまであった業務システムを活用せずに廃棄、もしくは保持にて引き続きオンプレミス環境を利用しながら、クラウド用に新しくシステムを開発・導入する手法で、クラウドリフトは、これまで存在した業務システムを、できる限りそのままの状態でクラウドに移行する手法です。
クラウドシフトの場合、クラウドリフトと比べると、圧倒的に手間と時間がかかる方法です。しかしその分、本質的な業務整理や要件定義ができ、本格的にクラウドに移行するのに向いています。クラウドシフトを行うときに、最新の技術と豊富な経験を持っており、積極的に活用方法を提案してくれるコンサルティングサービスのあるSIerやベンダーを活用すると良いでしょう。
クラウドリフトは、新たにシステムを作るのではなくクラウド用に最適化するだけなので、クラウドシフトより少ない手間で移行が完了します。しかしクラウドリフトでは、古いシステムをそのまま使うことになる点に注意が必要です。そのため、これまで行っていた保守や運用の業務は自動化されず、そのまま残ってしまうというデメリットがあります。クラウドリフトは簡単にできるものの、あくまで応急処置的な対応と考えておいた方が良いでしょう。現在ではクラウドリフトをするためのツールも充実しており、手間暇をかけずにクラウドリフトを実現することも可能です。
このように、クラウドシフトはクラウドリフトと比べて手間暇はかかるものの、より根本的でメリットも大きいクラウド移行手段と言えます。
オンプレミス環境をクラウド環境へ移行する注意点
オンプレミス環境からクラウド環境へ移行するにあたって、移行のプロジェクト開始前に覚えておきたいポイントや注意点を解説します。
1)セキュリティ
業務システムは企業の機密データを多く含むものです。そのため、クラウド移行を検討する段階から、セキュリティ対策についてしっかり調査する必要があります。仮に情報漏洩などのセキュリティ事故が発生すれば、企業の信用を損なう取り返しのつかない事態になりかねません。
安全な環境でシステムを運用するためには、一つのセキュリティ対策ではなく、さまざまな観点で複数の対策を講じることが大切です。例えばIPアドレス制限を始めとした「ネットワーク」から、「アプリケーション」「ユーザ」など多くの要素を考慮してセキュリティを強化してください。
2)使用者の意識変革
リフト アンド シフトで業務システムをクラウドへ移行した場合、日常業務の作業方法やシステムへのアクセス方法にも変化が生じます。仮にその変化に対してユーザが抵抗するようでは、クラウド移行の効果は半減するでしょう。そのため、リフト アンド シフトで実際に移行を進める前に、従業員を主体的にその取り組みに関わらせるよう促す方法が有効です。クラウド移行の重要性を説明することはもちろん、ユーザにどのようなメリットが出るのかという点も明確にしておきましょう。プロジェクトチームを発足して説明会を実施するなど、ユーザがクラウド移行へ主体的に取り組める環境作りがおすすめです。
3)移行先のクラウドサービスの選定
リフト アンド シフトにおいて、利用するクラウドサービスの選定は重要なポイントです。リフト アンド シフトでは既存環境の技術や運用方法を移行後もそのまま継承するため、必要に応じて構成変更や機能などの改修を行う場合があります。そうした際、柔軟性の低いサービスでは希望通りの運用を実現できません。
また、自社の状況に応じたスケーリング(自由に利用量を増減すること)は、柔軟な経営基盤を構築するうえで必要不可欠です。そのため、あらゆる状況に対応可能な機能性の高いクラウドサービスを選択することが大切になります。
4)既存システムの問題点の把握
クラウドへの移行は、現在のオンプレミス環境に以前から存在する、設計ミスや要件を満たしていない部分を修正するための大きな機会です。単純に現在のオンプレミス環境をクラウドへそのままリフト アンド シフトし、運用開始後にそうした問題点を改善しようとすると、より大きなコストと業務影響へのリスクが発生します。クラウドのメリットを最大限に引き出そうと考えるのであれば、クラウドへの移行作業に着手する前に既存システムの現状を把握し、見直すのが望ましいでしょう。
オンプレミス環境をクラウド環境へ移行する手順
最後に、どのようにクラウドリフト アンド シフトを行うか手順を解説します。手順を5つに分割し、詳しく見ていきましょう。
手順1 移行の評価と計画・クラウドプロバイダの選定
クラウドリフト アンド シフトを行うためには、まず現在のオンプレミス環境を評価し、クラウド移行の要件を明確化します。移行のスコープ、目標、予算、スケジュールなどを含めた移行計画を策定します。あわせて、移行先のクラウドプロバイダを選定し、クラウド環境を設計します。パブリッククラウド(AWS、Azure、Google Cloudなど)やプライベートクラウド(OpenStack、VMwareなど)など、ニーズや技術要件に合ったサービスを選定しましょう。
手順2 クラウド環境をテスト利用
次に、クラウド環境をテスト的に利用してみましょう。クラウド環境が自社にどのようなメリット・デメリットをもたらすのかは、実際にやってみて初めて分かる場合もあるはずです。そのため、まずは停止しても影響度が低いサーバーをクラウド化してみます。実際の業務利用において改修してほしい点や、運用要件に合っているのかなどをチェックしてください。
なお、クラウド環境と自社のサーバーの相性が致命的だった場合は大きな影響が出ます。そのため、最初からすべてのシステムをクラウドに移行するのは避けましょう。
手順3 クラウド移行を進める
テスト利用で問題なくクラウドを導入できることが分かったら、次は他のサーバーをクラウド移行していきます。全サーバーを一度に移行するのではなく、影響が少ない単位で分けて順次移行していくことが必要です。クラウドに移行するときには、どうしてもサーバーを一度止めなくてはいけません。そのため、サーバー停止が業務に大きな影響を与えないよう配慮して実施しましょう。
手順4 クラウド環境での運用と効率化
サーバーをクラウドへ移行できたら、次はクラウドを運用していきます。どう運用していくかは最初に決めておくことが望ましいですが、移行の段階で気づいたことがあれば運用を改善すると良いでしょう。また、クラウドならではの特徴を活かして効率化できるのであれば、この機会に自動化・省力化して生産性を向上させられるでしょう。
手順5 クラウドネイティブなシステム基盤の構築
クラウドへの移行が完全に終わったら、今後作るシステム基盤はクラウドで運用することを前提とするのがおすすめです(クラウドネイティブ)。クラウドと相性が良いシステムを作ることで、よりDXを加速させて生産性の向上が期待できます。
まとめ
リフト アンド シフトは、既存のオンプレミス環境をクラウドにそのまま移行する手法です。そのため、リプレイスや新規導入に比べると、手間をかけずにクラウド移行を実現することが可能です。新規スキルの学習コストを抑えられますが、既存環境における設計や業務要件の見直しの機会でもあります。ここで解説した内容を参考にポイントをしっかり検討したうえで、プロジェクト体制を作って実施しましょう。
[筆者プロフィール]
後藤 聡和
ネットワークからサーバエンジニアを経て、コンタクトセンター基盤のシステム開発、保守からプロジェクトマネジメントまで経験。IT技術に関する記事も執筆中。現在はSaaSベンダーにてプリセールスエンジニアとして従事。