ビジネスが最初からクラウド上で作られていない限り、自社で所有、ホスト、または管理しているITアプリケーションやレガシーインフラなどに頼っている可能性が高いと思います。これらのシステムは、今までは成長の原動力となっていたかもしれません。しかし、AI、機械学習、自動化などの新しいテクノロジーに移行すると、クラウドベースではない従来のシステムは、クラウドネイティブな技術を利用する前提で作られていないため、成長の妨げとなる可能性があります。

この記事では、ワークロード、アプリケーション、プロセスをクラウドに移行するための道のりを解説します。ワークロードをクラウドに移行するための基本事項と、従来のレガシーシステムからも価値を引き出す方法について解説します。また、必要なときに支援を受ける方法についても説明します。最終的には、ビジネス変革に一歩近づくことを目標とします。

クラウド移行とは?

クラウド移行とは、ワークロード、データ、アプリケーションなどのデジタル資産をパブリック、またはプライベートクラウド環境に移行するプロセスを指します。また、移行完了後、クラウドをどのように使用、維持、最適化、および管理するかの計画決定も含みます。

クラウド移行のメリットは何か?

クラウド移行の具体的なメリットは、選択したプラットフォームのメリットと密接に関連します。たとえば、マネージドプライベートクラウドプラットフォームに移行すると、セキュリティとパフォーマンスが大幅に向上するでしょう。また、クラウドプラットフォームに移行すると、マイクロサービスと柔軟性がメリットとなるでしょう。どのプラットフォームを選択するにしても、オンプレミス環境からホスト環境に移行すると、通常は次のような結果になります。

• コスト効率

  高価なレガシーインフラから移行することで、設備投資（CAPEX）モデルから運用（OPEX）モデルに移行するため、IT運用のコストを即座に削減できます。これにより、より多くの資産を保持したり、設備投資予算をビジネス・クリティカルなイニシアティブに再投資したりできるようになります。

• 生産性の向上

  クラウドを利用することで、IT部門は運用上の負担から解放され、自社のコア部分に専門知識を向けることができます。エンドユーザーには、クラウドによって強化された機能が提供され、業務をより迅速かつ効率的に行うことができます。

• 技術革新の強化

  クラウド基盤をモダンにすることで、ITチームのアジリティが高まり、新しい機能をユーザーにより迅速に提供できるようになります。また、クラウドを活用することで、機会学習など、イノベーションを推進する最先端技術を実装することもできます。このようなリソースを大量に消費するテクノロジーをレガシーハードウェア上で実行しようとすると、コストがかかるだけでなく、場合によっては不可能なこともあります。

移行前のアプリケーションの査定

クラウド移行の最初のステップは、ワークロードの選択です。プロジェクトが大きすぎると、スコープが徐々に狭まって時間がかかる可能性があります。そのため、小さくて影響の大きいワークロードから始めて、クラウドへの移行をある程度経験した後、複雑なワークロードに移行するとよいでしょう。

アプリケーションプロファイリングを使用し、ワークロードとアプリケーションに関する情報を収集、整理します。クラウド移行のワークロードを査定し、優先順位を付けるには、次の手順に従います。

1. 既存環境の指標を監査します。ビジネスオペレーションに重要なコンピューティングニーズ、パフォーマンス出力、応答時間などです。これによりベースラインを確立し、プラットフォームのKPIを開発を行うのに役立ちます。
2. ワークロードに関する重要な情報を整理して収集します。物理サーバと仮想サーバの構成、ネットワークトポロジ、コンプライアンス要件、データとアプリケーションの依存関係、地理的な考慮事項、ユーザーのニーズなどです。これにより、自社の環境をサポートする適切なクラウドプラットフォームを選択するための要件を設定できます。
3. 監査と情報収集に基づき、移行の複雑さに応じたワークロードを分類します。プラットフォームの変更やリファクタリングを行うことなく、容易に移行できるワークロードを特定します。これらの移行しやすいワークロードの優先順位を高くします。

適切なクラウド導入モデルとは?

ワークロードの候補を選別したら、最適なクラウドプラットフォームに合わせて要件を調整します。考慮すべきクラウドのタイプは複数あるため、アプリケーションとワークロードの査定は非常に重要です。この査定により、あなたのニーズ、そしてプラットフォームが提供できることについて、十分な情報を得た上でクラウドプラットフォームを選択することができます。

• パブリッククラウド: パブリッククラウドでは、複数の企業がインフラストラクチャを共有し、サービスプロバイダーが所有、運用します。需要に合わせてリソースを簡単に増減でき、従量課金制であるため、予測不可能なトラフィックに対処し、コスト削減を最大化する優れたオプションとなります。
• プライベートクラウド: プライベートクラウドでは、インフラストラクチャは完全に自社ビジネス専用のものとなります。コンピューティング、ストレージ、およびネットワークがカスタマイズできるため、より高度な制御とセキュリティを実現します。また、ワークロード要件やリソース使用率によっては、プライベートクラウドの方がパブリッククラウドよりもコストを削減できる場合もあります。
• ハイブリッドクラウド: 一部のワークロードでは、パブリッククラウドとプライベートクラウド環境の両方を組み合わせたハイブリッドクラウドが必要になります。ハイブリッドクラウドは、機密性が高くビジネスに不可欠な資産をプライベートクラウド上で制御でき、かつ外部向けの運用はパブリッククラウドの柔軟性とコスト削減を活かすことが可能です。
• マルチクラウド: マルチクラウドとは、その名の通り複数のクラウド基盤を意味します。オンプレミスのデータセンターやプライベートクラウドから、Amazon Web Sesrvices (AWS) 、Microsoft Azure®とGoogle Cloud Patform™(GCP) のようなハイパースケールクラウド、クラウドベースのSaaSアプリケーション、さらにはコロケーション環境まで、すべてが連携して独自のマルチクラウドを構築します。

さらに、上に表記した定義の境界があいまいになり始めています。AWS Outpostsのようなソリューションを使えば、パブリックな 「ハイパースケール」 クラウドを独自のデータセンターの専用ハードウェア上に持ち込むことができます。また、プライベート VMware Cloud を AWSで実行することもできます。これは、クラウド移行に適したプラットフォームを探す際に、選択肢が増えてきたといえます。

クラウド移行戦略の選択

各ワークロードがどのクラウドに属するかを決定したら、移行を実現するための最適なパスを選択する必要があります。すべてをまかなうアプローチはないため、ワークロード間で複数の移行戦略を使用する必要があるでしょう。たとえば、組織のモノリシックなERPシステムでは、技術的な理由やライセンスの理由からリフト・アンド・シフト戦略を使用する可能性がありますが、HRシステムは完全にSaaSオプションに置き換えることができます。

クラウド移行には、一般的に次の6つの戦略があります。

1. Replace – リプレイス

   この方法は、既存のレガシーコンポーネントを完全に廃止し、クラウドベースの代替コンポーネントに置き換えます。これにより、クラウドへの迅速なルートが作成されますが、多くの計画が必要となります。また、旧システムから新システムへのデータ移行作業や、データを残す決断などを行う必要もあります。

2. Rebuild – 再構築

   レガシー要素を完全に再構築して、完全にモダンなクラウドネイティブなソリューションを作成することもできます。これは最も時間とコストのかかる移行タイプと考えられていますが、結果的には最も大きなメリットをもたらします。クラウド上で、クラウドのために構築されているため、コンテナ、サービスメッシュ、マイクロサービス、不変インフラストラクチャ、宣言型APIなどの最新技術を統合することができます。その結果、より高い柔軟性、優れたパフォーマンス、および低運用コストを長期的に実現できるのです。

3. Replatform – リプラットフォーム

   最小限のコード変更でワークロードをクラウドに移行するソリューションをお探しの場合、リプラットフォームを検討しましょう。これは、アプリケーションのコンポーネントを新しいランタイム・プラットフォームにポートすることを含みます。たとえば、COBOLベースのシステムを、UNIXまたはメインフレーム・システムから、LINUXまやWindows環境に移行するケースなどです。アプリケーションの機能はそのまま維持されるため、最小限の作業でクラウド固有のコスト削減とスケーラビリティを活用できます。さらに、従来のソリューションから引き続き価値を引き出すこともできます。

4. Rehost – リホスト

   リホストすると、コード変更や機能の調整をすることなく、デジタル資産を新しい環境(物理、仮想、またはクラウドインフラストラクチャ)に「リフトアンドシフト」することができます。このアプローチではクラウドへの移行が高速化されますが、クラウドネイティブなツール、パフォーマンス、コストのメリットを十分に活用できません。また、Windows用COBOLメインフレームエミュレータのようなものを使えば、基本的にレガシー環境を最新のインフラで再現することができます。

5. Refactor & rearchitect – リファクタリング&再設計

   このオプションでは、アプリケーションの一部をクラウドに移行しながら、他の要素をレガシー環境に残すことができます。たとえば、モノリシックなアプリケーションを社内でホストしながら、データベースをクラウドに移行し、パフォーマンスを向上させ、クラウドベースの分析ツールを活用することができます。レガシー要素のバックエンドの調整が必要な場合もありますが、このアプローチはモノリシックなアプリケーションを1つずつクラウドに移行するのに役立ちます。

6. Retain – 保持

   現状を維持し、変更や更新を行わないことが理にかなっている場合もあります。たとえば、今後の合併または販売終了の発表を予想している場合、モダン化する理由がないこともあります。あるいは、組織内の他のモダンな要素への 「コネクター」 または 「ブリッジ」 として機能する特定要素を維持する必要があるかもしれません。しかし、非効率で大量のリソースを必要とするインフラストラクチャを長く維持すればするほど、革新の準備が整った時に利用できる予算とリソースが少なくなるため、長期的な戦略が必要です。

7. Retire – 廃止

   レガシーシステムを廃棄して、ユーザーを別の既存システムに移動するのが最善の方法となることもあります。この場合、一部のプロセスを再設計する必要があるかもしれませんが、このプロセスの改善と最適化を行う機会にもなります。

4段階のクラウド移行プロセス

すべてのクラウド移行は、アプリケーションの成熟度、インフラストラクチャの複雑さ、ITチームのスキルレベルなど、さまざまな要因によって異なります。一般的なガイドとして、すべての移行には次の4つのステップのいずれかが含まれます。移行プロセス中に誤ったテクノロジーや方法を選択したり、予期しない事態に遭遇したりしないように、これらの手順を実行することが重要です。

ステップ1:計画と査定

依存関係、サービス、アプリケーション、物理サーバおよび仮想サーバの構成など、環境全体をマッピングします。適切に考慮しないと移行が複雑になる可能性があるシャドウのIT実装やサードパーティのリソースなど、すべてを把握します。

ステップ2:設計

クラウド対応のアプリケーション、データベース、ストレージ、物理サーバおよび仮想サーバの候補を特定します。SLA、依存関係、ユーザーのニーズ、コンプライアンスおよびセキュリティ要件をまとめます。最悪のシナリオに対応するため、また必要に応じて移行をやり直すため、緊急時対応計画とロールバック計画を作成します。移行と継続的なメンテナンスのためにリソースを集めます。候補要素の予備的な移行パスをドキュメント化します。

ステップ3:パイロット移行

設計中に顕在化した問題をまず解決します。技術側とビジネス側の両メンバーを含む移行チームを組織し、コミュニケーションとトレーニングに関するアクティビティを確立します。本番ではない環境で、設計に基づいてパイロット移行のスケジュールを作り、パイロット中に発生した問題を対処します。このドライ・ランから、プロセスをドキュメント化してランブックを作成します(移行前の要件、本番環境の要件、移行後のテスト・プロトコル、およびいつサービスを停止し、いつサービスを開始するかを決定するルールなど)。

ステップ4:移行

移行のスケジュールを設定します。移行中にシステム停止やパフォーマンスの問題が発生した場合に、影響が最小限に抑えられるように、週末、夜間、休日などの時間帯にスケジュールを設定することを検討しましょう。ランブックに従って移行を実行します。本番環境で稼働したら、アプリケーション、データ、ネットワークの移行後の検証を実行します。障害、サービスの停止、データの異常、またはパフォーマンスの問題をトラブルシューティングします。重大な問題を迅速に解決できない場合は、問題の原因を調査するためにロールバックを導入し、スケジュール変更をして影響を最小限に抑えます。

クラウド移行時の主な課題

全ての移行は異なるため、各ビジネスがさまざまな課題に直面します。クラウド移行プロジェクトで直面する一般的な課題とは以下のようなものです。

• 文化的シフト: クラウド移行は、組織全体に新たな効率とプロセスをもたらします。これらの新しい効率化には、ユーザーが適応しなければならないプロセスが伴います。ビジネスを変革するということは、新しいビジネスプロセスや手法を組織に再認識させることを意味するため、反発を受ける可能性もあります。クラウドへの移行によって生じる変化をユーザーが理解できるように準備し、適切なトレーニングを提供しましょう。また、慣れるまで時間がかかることを認識しておく必要があります。
• レガシー資産: 従来のIT資産、不動産、データセンターとの契約は廃止する必要があります。移行を計画する際、契約上の罰則、建物のリース、またはハードウェアの取り外しにかかる費用を必ず計画に含めてください。クラウドに完全に移行できないレガシー要素の場合は、コアシステムを維持し、クラウドでストレージとコンピューティングを補完できるハイブリッド環境を検討する必要があります。
• スキルのギャップ:　クラウド環境の管理には、オンプレミス環境やデータセンター環境の管理とは異なるスキルが必要です。理想としては、既存のチームでスキルを新たに習得することでしょう。これが実現できない場合は、新たに採用するか、マネージドサービスプロバイダーと連携して日常業務を運用する必要があります。また、ユーザーにも新しいツールやプロセスで仕事をするために必要なスキルを提供する必要があります。
• 混乱: 最善の計画を立てても、移行がうまくいかないことがあります。一般的な落とし穴としては、データの消失、システム停止、パフォーマンスの低下などがあります。トラフィックが少ない時間帯に移行を計画しましょう。ビジネス担当者と連絡を取り、移行期間と予期しない動作が発生する可能性についてユーザーに事前通知をしましょう。

Rackspace を利用してクラウドに移行する理由

クラウド移行を進める際には、さまざまな業界や地域で移行実績のある専門家と進めることをおすすめします。20年以上にわたるクラウドの専門知識により、Rackspace Technologyは移行だけでなく、IT運用の変革やビジネスプロセスの改善にもお役に立てます。

移行するワークロードの選択から、新しいクラウドプラットフォームでの継続的な運用管理と最適化まで、あらゆるフェーズでお客様を支援いたします。お客様の課題をともに把握し、協力してビジネス成果につながるロードマップを構築します。お気軽にお問い合わせください。

本記事の翻訳編集は、アイレット株式会社Rackspace 事業部ビルドエンジニアの知念梨果が担当いたしました。