クラウド移行とは

クラウドに移行する大きな理由の一つは、費用を削減し、インフラストラクチャのパフォーマンス、使用率、レジリエンス、セキュリティを最適化することです。クラウドへの移行により、組織は資本支出モデルから運用支出モデルに移行できるため、オンプレミスのデータセンターにおける高価な設備の所有、運用、保守、更新の必要性が軽減されます。

IT における資本的支出（CapEx）とは、通常、物理的資産に対する大規模な一括投資を指します。たとえば、新しいサーバーの購入、データセンターの構築、ソフトウェア ライセンスの購入は、資本的支出とみなされます。これは減価償却される資本支出であり、時間の経過とともに資産価値が低下します。

一方、運用支出（OpEx）は、ビジネスを運営するために継続的に発生する費用です。クラウド コンピューティングでは、OpEx にはクラウド サービスの柔軟なサブスクリプション料金が含まれます。このモデルでは、多額の先行投資を行うのではなく、予測しやすい継続的な費用が発生します。クラウドに移行することで、パフォーマンスの向上と稼働時間の増加を実現できます。クラウドはまた、ワークロードのモダナイズや、レガシー アプリケーションに伴う負担の大きいライセンス料の削減にも役立ちます。クラウドは、組織がデータを保護しながら、世界中の規制当局に対するガバナンスとコンプライアンスを強化するのに役立ちます。

組織がクラウドに移行する理由

• データ分析の活用: 既存のアプリをクラウドに移行することで、企業は CRM、SAP、マーケティング データベースなどの既存のツールからより多くの価値を生み出すことができます。これらのシステムをクラウドでモダナイズすることで、企業はデータを活用して新たなビジネス チャンスを見つけ、組織のアジリティを高めて問題に対処できるようになります。
• アジリティの向上: クラウドは、組織にオンデマンドの IT リソースを提供します。そのため、組織はアプリを構築したり、オンプレミスのハードウェアをインストールしたりするために数週間や数か月も待つ必要がありません。クラウドにより、組織は市場の変化や競合他社の行動により素早く適応し、市場開拓戦略の柔軟性を高めることができます。
• データの統合とモダナイズ: オンプレミスのデータセンターから移行することで、企業はデータを統合し、ユニバーサル データ プラットフォームで整理する機会を得られます。これにより、より堅牢で高度なデジタル トランスフォーメーションの可能性が広がります。
• AI の活用: 組織のデータとアプリケーションをクラウドに移行することで、企業は常に進化する新しい AI サービスやモデルを身近に利用できるようになり、新しい AI アプリケーションやエージェントの柔軟性、アジリティ、パフォーマンスを向上させることができます。

組織は目標と目的に応じて、さまざまなタイプのクラウド移行から選択できます。

データセンターの完全な終了の移行とは、すべてのアプリケーション、サービス、データセットを 1 つ以上のデータセンターからパブリック クラウドに移行するプロセスです。組織の規模によっては、データセンターの完全な終了は、1 年以上の計画、テスト、実行を必要とする長いプロセスになる可能性があります。

組織がクラウド ベンダーを変更する理由は多岐にわたります。たとえば、サービスレベル契約の変更、セキュリティ対策の改善、より優れた AI / ML ツールへのアクセスなどが挙げられます。このようなクラウド間の移行は、ベンダー ロックインを回避するためや、新しいプラットフォーム上の特定の機能を利用するためによく行われます。大手ベンダーは通常、あるパブリック・クラウド・プロバイダから別のパブリック・クラウド・プロバイダへの移行を支援できるツールセット、サービス、サードパーティ・ベンダーのリストを用意しています。

データセンターを完全に終了するのではなく、組織は、ソフトウェア、サービス、データセットの一部をオンプレミス サーバーから移行して、より効率的で管理しやすいクラウドに移行したいと考えるかもしれません。パブリック クラウドに移行されるアプリケーションの典型的なものとしては、ビジネス インテリジェンス、データ分析、顧客リソース管理（CRM）、ML および AI アプリケーション、データセットなどがあります。

より的を絞った移行では、クラウドで実行されるリソースで、コンピューティング能力やストレージ容量などなんらかのリソースを消費する特定のタイプのワークロードのみで構成することもできます。たとえば、開発環境、ドキュメントの作成や管理、分散データベース、3D モデリング、動画のエンコードなどがあります。

最も一般的な移行戦略は、アプリや仮想マシンにほとんど、またはまったく変更を加えない直接的な移行（再ホスト）から、デジタル インフラストラクチャ全体の完全な再考（再設計またはリプラットフォーム）まで、さまざまなタイプがあります。

• リホスティング クラウド移行戦略では、移行中の変更はできるだけ少なくし、構成を大幅に変更せずに、アプリケーションをクラウドに再デプロイすることを目指します。
• これは、管理者がアプリケーション、ワークロード、仮想マシン、サーバー オペレーティング システムを「リフト」して、パブリック クラウドの新しいオペレーティング モデルに「シフト」するだけの、最もわかりやすいクラウド移行戦略です。データセンターで実行されていたのと同じソフトウェアが、クラウドで実行されるようになります。
• リホスティング戦略の欠点は、パブリック クラウドを強力かつ有用なものにするクラウドネイティブの機能と効率性を十分に活用できない場合が多いことです。
• リホスティング移行戦略は、使用量のピークパターンが予測可能な組織（税務業界やフードデリバリーなど）に最適です。また、大規模なデジタル トランスフォーメーション プロジェクトの最初のステップとしてよく使用されます。

• リプラットフォーム戦略は、再ホスト戦略の次のステップです。既存のアプリケーション、ワークロード、仮想マシンをリフトして、新しいクラウド環境に合わせて最適化します。たとえば、クラウドベースのマイクロサービス アーキテクチャや Kubernetes のようなコンテナを活用するために、ワークロードをサービスによってクラウドにリプラットフォームできます。
• リプラットフォーム クラウド移行戦略のメリットは、クラウドで実行されるアプリケーションのパフォーマンスと効率性が高いことです。デメリットは、リプラットフォームは、単純なリフト＆シフトよりも多くの作業が必要になることです。新しいクラウド プラットフォームは基盤となるコードベースが異なるため、すべてが最適なレベルで実行されていることを確認するために、テストを数回行う必要があります。
• リプラットフォーム クラウド移行戦略は、弾力性のあるコンピューティング、冗長性、パフォーマンスの向上、セキュリティなど、クラウドのコア コンピテンシーをすべて利用したいと考えている組織に最適です。

• リファクタリング クラウド移行戦略とは、アプリケーションをクラウドネイティブになるように再設計することです。
• リファクタリングでは、フロントエンドの動作やエクスペリエンスを変更せずにアプリケーションのコードを変更するのが一般的です。たとえば、リファクタリングされたアプリケーションでは、コードの長い文字列が、クラウド機能をより有効に活用できるモジュール式に細分化され、コードのパフォーマンスが向上します。
• リファクタリング戦略で推進力となるのは多くの場合、拡張性の向上、ML や AI 機能の追加、より高速で直感的なデータ分析など、既存のアプリケーションに新しい機能を提供する必要性です。
• リファクタリングはリホスティングよりも複雑になる可能性がありますが、ビジネスニーズに基づいてどのアプリケーションを移行するか優先順位を付けることができるため、企業はより高い柔軟性を得て、競争の激しいエコシステムに遅れを取らないようにできます。

• 再設計によるクラウド移行戦略はリファクタリングに似ていますが、アプリケーションのコードの仕組みを再構築するのではなく、コードの機能を変更することでアプリケーションを最適化し、スケーラビリティ、セキュリティ、アジリティなど、クラウドネイティブの特性を活かせるようにします。
• アプリケーションの再設計の一例としては、1 つの大規模なモノリシック アプリケーションを複数の独立したマイクロサービスに分割することが挙げられます。
• 再設計はリファクタリングよりも時間と労力がかかり、複雑さが増すとともに、新しいアプリケーションにバグやセキュリティの問題が発生する可能性があります。

• 再構築によるクラウド移行戦略とは、組織がアプリケーションをクラウド用に完全に書き換えることです。多くの場合、アプリケーションをゼロから構築する方が、古いコードをクラウド環境で機能するようにリファクタリングするよりも簡単です。
• 再構築戦略を取ることで、どのクラウドネイティブ ツールや機能を最初から使用するかを選択でき、一からのプランニングが可能になります。
• 再構築戦略の欠点は、時間がかかることと、アプリの旧バージョンでは遭遇しなかったバグやその他のパフォーマンスの問題が発生する可能性があることです。

• 再購入によるクラウド移行戦略とは、組織が購入したオンプレミス アプリケーションから、クラウドでホストされる Software as a Service（SaaS）サービスに移行することです。たとえば、オンプレミスのコラボレーション ソフトウェアとローカル ストレージから、Google Workspace のクラウドホスト型アプリ（Google ドキュメント、スプレッドシート、スライド、Google ドライブなど）に移行できます。
• リソースの観点から見ると、再購入戦略は、リファクタリング、再構築、再設計よりもはるかに容易です。
• 再購入戦略の欠点は、費用が大幅に高くなる可能性があり、組織が独自のクラウド環境を制御するきめ細かい機能を利用できないことです。

AI / ML やデータ分析サービスを利用してアプリケーションを強化し、ユーザー エクスペリエンスを向上させ、データからより迅速かつ効率的に価値を引き出します。

本格的な移行は、数年にわたる複雑な作業になる可能性があります。組織は、移行を開始する前に、明確で達成可能なビジネス目標を立てておく必要があります。これには、最終的なクラウド環境がパブリック、プライベート、ハイブリッド、マルチクラウドのいずれになるのかを理解することも含まれます。また、サードパーティ ベンダーのツールを使用するか、クラウド プロバイダのツールを使用するか、どのアプリを SaaS にするか、新しい環境でデータをどのように整理するかなどを決める必要があります。

クラウド運用に必要なスキルは、オンプレミス環境に必要なスキルとは異なります。クラウド環境では、DevOps、自動化、Infrastructure as Code などの新しい運用モデルがよく使用されます。組織は、これらの機能を利用するために、新しい従業員を雇用したり、既存のスタッフを再教育したりする必要があります。移行期間中、従業員が新しいインフラストラクチャをサポートするためのトレーニングを受け、新しい認定資格を取得する時間を確保することが重要です。

オンプレミス環境からクラウドに移行する際には、セキュリティ対策が変わります。ID とアクセス管理は、より複雑で重要なものになります。データ損失防止（DLP）やゼロトラスト アーキテクチャなどの新しいセキュリティ ツールやベスト プラクティスを理解する必要があります。クラウド プロバイダは堅牢なセキュリティ ツールを提供しますが、データを移行する際のデータ ガバナンスやコンプライアンス ポリシーについては、最終的には組織が責任を負う必要があります。

運用モデルの変更に伴う新たな費用や支出をすべて把握するのは大変な作業です。新しい料金体系、請求サイクル、リソース消費など、費用管理は継続的な課題になります。初期の移行時にリソースを過剰にプロビジョニングしたために、支出が膨らむ場合もあります。幸いなことに、クラウド プロバイダの中には、予算調整や効果的な費用管理を支援するプロアクティブな推奨事項を提供するものもあります。

古いシステムやレガシー システムはクラウド環境と互換性がない場合があり、多くの場合、大幅な変更や置き換えが必要になります。これは主に、古いコードを使用したカスタムビルドのアプリケーションに当てはまります。これらは、大規模なリファクタリングや再構築を行わないとクラウドネイティブ機能を活用できません。アプリケーションの互換性を評価することは、移行計画における最初の重要なステップであり、予期しない技術的な障害を回避するために行います。

多くの組織は、数十年にわたって構築された複雑なネットワーキング トポロジを抱えています。また、組織によっては、リスクの低減や、アプリケーションの依存関係が正常に機能することを保証するために、既存の IP アドレスの保持が必要である場合もあります。

アプリケーションとデータセットは、多くの場合、複雑な相互依存関係を持っています。移行前にこれらの関係が適切にマッピングされていないと、データの損失や破損のリスクが大きくなります。データの完全性を確保するには、すべてのデータが正しく移行され、新しい環境でもアクセス可能で利用可能な状態を維持できるよう、綿密な計画とテストが必要です。これは、移行全体の成功を損なう可能性がある重要な課題であり、慎重に管理する必要があります。