クラウドへの移行とは？意味や仕組みをわかりやすく解説！
はじめに
企業の間では、もともと目新しい存在ではなかったクラウドコンピューティングですが、リモートワークが当たり前になりつつある昨今、さらに浸透した感があります。
クラウドコンピューティングは、ビジネスの世界では決して目新しいものではありません。すべての企業がクラウドを利用する日はまだ先のことですが、特にリモートワークが当たり前になりつつある昨今では、導入する企業の数は急速に増えています。
クラウドへの移行は、どこからでもデータに安全にアクセスできるだけでなく、コスト削減やプロセスの合理化を可能にします。多くの企業がレガシーデータのクラウド環境への移行を検討しているにもかかわらず、多くの企業がクラウドへの移行が実際にどのように機能するのかを十分に把握していません。
この記事では、クラウドへの移行がどのように行われるのか意味や仕組みについて解説していきます。
クラウドへの移行には何が必要か
クラウドへの移行を成功させるには、戦略が必要です。クラウド移行戦略とは、企業がオンプレミスのデータやアプリケーションをクラウドに移行するための詳細な計画のことです。
クラウドへのデータ移行は、物をある場所から別の場所に移動させるように簡単な作業だと思うかもしれませんが、クラウド移行プロジェクトは、社内での多くの理解と準備を必要とする大変な作業です。
クラウド移行戦略の最終目標は、データをクラウドに移行するための最も効率的で効果的な方法を見つけることです。つまり、多くの可能性のある移行戦略の利点と課題を考慮して、自社のビジネス固有のニーズに最も適した戦略を決定する必要があります。
クラウドへの移行を成功させるための4つのステップ
ここからはクラウドへの移行を成功させるための4つのステップについて解説します。
ステップ１：既存のデジタル資産を把握する
これは、クラウド移行プロセスの最初で基本的な部分です。コスト、パフォーマンス、サイズ、複雑性、内部依存性などの観点から、既存のデータやアプリケーションを詳しく調査し、最適なクラウド移行モデルと戦略を決定します。
このステップでは、まずデジタル資産のアセスメントを行います。
- 既存のアプリをリストアップ
- どのアプリがもはや価値を生まないのかを特定
- クラウドに移行することで、より価値のあるアプリを検査
ステップ2：目標（KPI）を設定する
明確なKPIを設定することで、クラウド移行の成功を評価できるだけでなく、チームの全員が同じ方向を向くことができます。移行が成功したかどうかを知るためには、「前」と「後」の比率を比較する必要があります。ここでは、注目すべき重要な指標のリストを紹介します。
- 平均応答時間：通常の動作状態で、クラウドサーバーが特定の結果をどれだけ早く返すか
- 最大応答時間：非標準的な条件下で、サーバーからの応答が最も長かった時間。
- 合計アップタイム：システムの全作業時間に占める、特定のアプリが稼働している時間の割合
- エラー率：リクエストの総数に対する、返されたエラーの割合
- エラーの種類：発生した検出エラー、警告、例外の種類
- ネットワーク遅延：特定のリクエストからサーバーからのレスポンスまでの時間
ワークロードの移行を成功させるには、クラウド版の新しいデータが、オンプレミスのオリジナル版と同等以上のパフォーマンスを発揮し、かつ低コストで稼働する必要があります。そうでなければ、移行作業全体が無駄になってしまいます。
ステップ3：クラウドプロバイダーの選択
既存のデジタル資産を調査し、目標を設定した後、目標を達成するためのクラウド移行モデル（パブリック、プライベート、ハイブリッド、マルチクラウド）を選びます。
ステップ4：最適な移行戦略を選択する
6つの「R」ともよばれる、最も一般的な6つの移行戦略があります。
自社のニーズや目標に応じて、最も適したものを選択することが必要です。
クラウドへの移行戦略パターン、6つの「R」
下の6つのRは、クラウドに移行する際に最もよく使われる戦略です。
それぞれの戦略には、メリットとデメリットがあり、複雑さと投資額も異なります。
それぞれの戦略に期待できることを理解することで、自社のニーズに合った移行戦略を選べるようになります。
Rehost（リホスト）
リホスト戦略は「リフト＆シフト」ともよばれ、既存のコードを変更することなく、オンプレミスのデータを持ってきて、クラウド環境に配置するものです。
メリット
リホストは、クラウドに移行するための最も安価でシンプルな方法です。既存のコードを変更しないため、不具合を起こすリスクを軽減し、最小限の時間と専門知識で済みます。また、既存のビジネスをクラウド上で再現するだけなので、通常の業務を行う上での混乱や専門知識を修得する負担が少なくて済みます。
デメリット
リホストはシンプルなアプローチですが、複雑なアプリケーションの依存関係や長い停止期間による障害が発生する可能性があります。仮想サーバーがダウンすると、アプリケーションも一緒にダウンします。これは、従来のオンプレミスサーバーの動作に似ています。
さらに、リホスト・クラウドの移行が成功したとしても、レガシー・アプリケーションはクラウド・ネイティブ・アプリケーションのように分散ワークロードを可能にするようにクラウドに最適化されていないため、クラウド・ネイティブの機能をすべて活用することはできません。
「リホスト」が採用される例
- 初めてのクラウドを利用
- 大規模システムでの移行
- 期限付きの移行
- 既製アプリケーションの移行
その後、自分に合ったクラウドプロバイダーを選びます。最も人気のあるプロバイダーは、Amazon Web Services（市場シェア32％）、Microsoft Azure（市場シェア18.6％）、Google Cloud Platform（市場シェア8.5％）です。これらのプロバイダーは、必要と思われるすべてのクラウド・モデルを提供しているだけでなく、サービスのコストを見積もるための便利な価格計算機を備えています。
Replatform（リプラットフォーム）
リプラットフォームは、クラウドリホースティングの1つ上のレベルにあたります。この戦略では、アプリケーションは基本的に同じままですが、クラウドに移行する前に、クラウド環境に合わせてある程度最適化されます。
リプラットフォームでは、アプリケーションの特定のコンポーネントを変更、アップグレードすることが多いです。このような変更により、アプリケーションはクラウド上でより効率的に機能するようになり、多くの場合、スケーラビリティ、ユーザーエクスペリエンス、セキュリティが向上します。このように、クラウドに移行する前に少し手を加えることから、リプラットフォームは「リフト・ティンカー・アンド・シフト」とも呼ばれています。
しかし、この修正ステップは、リプラットフォームがリホストよりも本質的に優れていることを意味するものではありません。企業のインフラがすでにクラウドに対応している場合は、リホストするだけで済むこともあります。
メリット
リプラットフォームには、時間やお金の大きな投資は必要ありません。リプラットフォーム戦略では、アプリケーションの一部を改善しながら、残りの部分はクラウドで運用することができます。
デメリット
アプリケーションのリプラットフォームは、時に手に負えなくなることがあります。アプリケーションやサービスに小さな変更を加えるだけのものから、一部のコンポーネントを完全に再構築するものまで様々で、レプラットフォームを行う際には、コードや構成にエラーが発生するなどのリスクを抱えなければなりません。したがって、クラウドへの移行にこの方法が適しているのであれば、変更する必要のある機能について事前に綿密な計画を立て、それらの変更を慎重に実施する必要があります。
「リプラットフォーム」が採用される例
- 時間に余裕がない状態での移行
- 洗練されたオンプレミスのアプリを、クラウドの利点を活かして微調整しながら移行する場合
- アプリをリファクタリングすることなく、クラウドのメリットを享受したい場合
Refactoring/Re-architect (リファクタリング／リアーキテクト)
リファクタリング／リアーキテクトは、リプラットフォームの1つ先のレベルです。つまり、リファクタリングでは、基本的なコードに大きな破壊的な変更を加えることができます。この戦略は、アプリケーションのコードに大きな変更があっても、アプリケーションの外部インターフェイスは（ユーザーの体験の乱れを最小限に抑えるために）同じままにする必要がある場合が多いため、より複雑なものとなります。
企業がこの戦略を選択するのは、機能、パフォーマンス、スケールなど多くの面で変更が必要であり、既存のアーキテクチャへのわずかな変更では実現できない場合です。
リファクタリングは、既存のアプリケーションがリソース集約型であったり、時代遅れのレガシーシステム上で動作していたり、集中的なデータ処理を行っている場合に有効です。アプリケーションをクラウド用にリファクタリングすることで、パフォーマンスが向上し、リホストやリプラットフォームを行うよりも課金コストを削減することができます。
メリット
リファクタリングによって、アプリケーションはクラウド・ネイティブな機能（マイクロサービス・アーキテクチャ、サーバーレス、コンテナ、サービス機能、ロードバランサー）を利用できるようになります。長期的な視点で見ると、他の戦略を使うよりもアプリケーションをリファクタリングする方がはるかに費用対効果が高いです。
デメリット
リファクタリングは、他の戦略に比べて初期費用が高く、時間もかかります。また、リファクタリングは初心者向けではありません。この戦略を正しく実行するには、高度なコーディング、自動化、およびDevOps（デブオプス）のスキルが必要です。
「リファクタリング／リアーキテクト」が採用される例
- スケーラビリティ、スピード、パフォーマンスを向上させたいという強いビジネスインセンティブがある場合
- オンプレミスのアプリがクラウドに対応していない場合
Re-purchasing（リプレイス・再購入）
リプレイス（再購入または「ドロップ・アンド・ショップ」ともよばれる）とは、レガシーアプリケーションを、同一または類似の機能を提供するSaaSソリューションに完全に置き換える戦略のことです。リプレイスの典型的な例は、古くなったオンプレミスのCRMソフトウェアをSalesForceやHubSpotなどのSaaSソリューションで置き換えることです。
リプレイスの複雑さは、自社が求める要件やオプションに大きく依存します。同じベンダーのオンプレミス製品をSaaSで置き換えることで、最小限の労力で、あるいは自動的にデータを素早く移行することができます。しかし、異なるベンダーの製品に乗り換える場合はそうはいかないかもしれません。
メリット
レガシーアプリケーションを置き換えるSaaS製品は、すでにクラウド用に設定されているため、自分で設定するためにリソースを費やす必要がありません。そのため、リファクタリングよりもリプレイスの方が安く済む場合があります。
デメリット
リホスト／リプラットフォーム／リファクタリングに必要な投資を節約できる一方で、SaaSの代替品が不慣れなツールである場合には、そのリソースをスタッフのトレーニングに割り当てる必要があります。また、SaaSの代替品にはレガシーアプリケーションの一部の機能が搭載されていない可能性があり、それらの機能が必要不可欠である場合には、再購入はもはや実行可能な選択肢ではないかもしれません。
「リプレイス」が採用される例
- 財務、会計、CRM、HRM、ERP、電子メール、CMSなどのSaaSソリューションが、現在使用しているソフトウェアよりも有益であると感じている場合
- レガシーアプリケーションがクラウドに対応していない場合
Retaining（リテイン）
再検討ともよばれる「Retaining（リテイン」とは、クラウドに移行する前に、高度なリファクタリングが必要な重要なアプリケーションやレガシーデータの一部を見直すことです。最終的には、クラウドに移行するよりもオンプレミスに留める方が適しているアプリケーションを見つけ、それらをオンプレミスのインフラに残すことになります。ほかのケースでは、レイテンシー要件や規制上の制約、あるいは単にコスト効率が悪いという理由で、アプリケーションを維持することがあります。
メリット
アプリケーションをクラウドに移行するための費用が必要ありません。
デメリット
オンプレミスのサーバにアプリケーションを保持する場合、これらのアプリケーションがクラウドベースのアプリケーションと支障なく通信できるように、APIを設定する必要があります。アプリケーションの複雑さによっては、このプロセスにコストと時間がかかる場合があります。
「リテイン」が採用される例
- オンプレミスのアプリケーションに多額の投資をしている場合
- 移行時にハイブリッドクラウドモデルを採用する場合
- 後日、アプリケーションを再検討したい場合
- レガシーアプリケーションがオンプレミスでうまく機能しており、クラウドとの互換性がない場合
Retire（リタイア）
リタイアとは、IT機器の中で不要になったアプリケーションを排除することです。クラウドに移行する価値のないアプリケーションであれば、廃止するかダウンサイジングします。このような場合には、用途、依存関係、企業にとってのコストなどの観点から、すべてのアプリケーションを調査する必要があります。
アプリをリタイアさせるのは簡単ですが、どのアプリを必要とするかを決めるのは複雑なプロセスになります。これは計画の初期段階で行うべきことで、移行するアプリケーションの範囲を減らし、コストを節約することができます。
メリット
リタイア戦略により、オンプレミス・サーバーのスペースを確保し、コストを削減することができます。また、アプリケーションのメンテナンスには多額の予算が必要になることが多いため、古くなったビジネスアプリケーションを廃棄することで、大幅なコスト削減が可能になります。
デメリット
廃止されたアプリケーションの代わりに、新しいアプリケーションを構築する費用が必要になる場合があります。
「リタイア」が採用される例
- アプリが余剰または陳腐化した場合
- アプリのリファクタリングやリプレイスを決定した場合
- レガシーアプリは、もはや真の価値を提供しておらず、クラウドとの互換性もない場合
まとめ
自社でクラウド移行プロジェクトを実行するための体制がない場合は、外部のクラウド移行支援パートナーを探すのが一般的です。
弊社は、ベトナムでトップ3に入るクラウド移行サービスプロバイダーです。Amazon AWS、Microsoft Azure、Google Cloudを専門とするクラウドエンジニアの大規模な認定チームを運営しており、お客様のレガシーシステムを最も費用対効果の高い方法で、最短時間でクラウドに移行することができます。
クラウド移行に関することでご不明点やご質問がありましたら、お問い合わせフォームから、お気軽にご連絡ください。
他にも、オフショア開発に役立つ資料は無料公開しています！
【ブログ】サーバーレスとは？クラウドコンピューティングに欠かせないサーバーレスについて解説！
「サーバーレス」により、企業はクラウドインフラを気にせず、アプリケーションの構築に集中することができます。このブログでは、サーバーレスの概要やメリット・デメリット、実際の事例について解説します。
オフショアのメリットを最大限に活用した
AWS クラウド ・サービス
当社はAWSのクラウド技術と、ベトナムオフショア開発を利用し、低コストかつ高品質な企業の競争力を高めるためのソリューションをご提供しています。
【動画】【2022年版】2分でわかる！オフショア開発とは？
本動画では、日本のIT開発プロジェクトと深く関係がある「オフショア開発」の概要とメリットについて、サクッとで解説しています。
