クラウド移行とは何ですか?クラウドへの移行に関する必須ガイド

クラウド移行とは、データ、アプリケーション、またはその他のビジネス要素をクラウド コンピューティング環境に移動するプロセスです。

組織が実行できるクラウド移行にはさまざまな種類があります。一般的なモデルは、オンプレミスのデータセンターからパブリッククラウドにデータとアプリケーションを転送することです。ただし、クラウド移行には、データとアプリケーションをあるクラウド プラットフォームまたはプロバイダーから別のクラウド プラットフォームまたはプロバイダーに移動することが必要になる場合もあります。このモデルはクラウド間 (C2C) 移行と呼ばれます。 3 番目のタイプの移行は、リバース クラウド移行、クラウド復帰、またはクラウド終了であり、データまたはアプリケーションがクラウドからオンプレミスのデータ センターに戻されます。

クラウド移行が重要なのはなぜですか?

クラウド移行は、移行または変更のプロセスです。組織がクラウド サービスを使用することを決定する場合、その目標は、コンピューティングを電気、水道、天然ガスなどの公共サービスとして扱うことです。パブリック クラウドは、拡張性に優れ、従量課金制であるため、企業は必要なリソースだけを必要な期間だけ使用し、実際に消費したリソースに対してのみ料金を支払うという柔軟性が得られます。これは、あらゆる規模や業種の企業にとって魅力的なパラダイムシフトです。

ただし、ビジネス ワークロードを実行し、ビジネス データをクラウドでホストすることを選択するのは、見た目よりも複雑になる可能性があります。すべてのワークロードがクラウドに適しているわけではありません。これは、パフォーマンス要件、依存関係、またはワークロード自体の設計が原因である可能性があります。また、データ主権に関する要件の増大など、企業がコンピューティング タスクを実行する方法や場所に影響を与えるコンプライアンス、セキュリティ、その他の規制ガイドラインによって複雑になることもあります。

クラウド移行を成功させるには、ビジネス プロセスと技術プロセスの両方が重要です。あらゆるクラウド移行は、明確なビジネスユースケースと目標から始める必要があります。そうして初めて、技術者はクラウド アーキテクチャの組み合わせを通じて難しい道筋を描くことができるようになります。仮想マシン、ストレージ ボリューム、コンテナーなどのデータおよびワークロード キャリアを選択します。ファイアウォール、ロードバランサ、さらにはデータベースなどのクラウド サービスに接続します。クラウドで目的のワークロードを実行するために必要な実際の移行を実行します。その後、必要なテストと継続的な監視を実行して、クラウド内のワークロードが安全であり、時間の経過とともに必要に応じて実行されることを確認します。

その結果、一部のアプリケーションではクラウド移行が困難になる可能性があり、移行プロジェクトが失敗することもあり、クラウドへの復帰などの修復措置が必要になることがよくあります。ここで重要なのは、クラウドへの移行は「すべてかゼロか」の問題ではないということです。個々のワークロードに基づいてクラウド移行を評価し、アプローチするビジネスでは、組織にとって最も有益な方法でクラウドの利用について情報に基づいた意思決定を行うことができます。たとえ 1 つのワークロードがクラウド移行に失敗したとしても、無数の他のワークロードがクラウドを正常かつ有益に使用することを妨げるものではありません。

クラウド移行の主なメリットは何ですか?

多くの組織は、より高い弾力性、セルフサービス プロビジョニング、冗長性、柔軟な従量課金モデルを活用するために、ローカル アプリケーションとデータをオンプレミス データ センターからパブリック クラウド インフラストラクチャに移行しています。

クラウド移行の全体的な目標または利点は、クラウド自体を使用する理由と本質的に同じです。つまり、コスト、パフォーマンス、セキュリティなどの要素に基づいて、最も効果的な IT 環境でアプリケーションとデータをホストすることです。クラウド移行のより包括的な具体的なメリットは次のとおりです。

敏捷性と柔軟性が向上します。クラウドは、ほぼあらゆる量のリソース (コンピューティングとストレージ) とサービスをオンデマンドで提供できるように設計されています。これにより、組織はインフラストラクチャの購入を待たずにワークロードを即座に展開および拡張し、必要に応じてリソースを使用し、実際に消費したリソースに対してのみ料金を支払うことができます。

スケーラビリティの向上。ワークロードがパフォーマンスを維持および強化するためにさらに多くのリソースを必要とする場合、これらのリソースは既にパブリック クラウドに存在し、利用可能であるため、クラウドは新しいハードウェアとプラットフォームを調達して展開する必要なく、これらの追加リソースを即座に提供できます。

イノベーション能力。クラウドにより、企業はオンプレミスのインフラストラクチャに投資したりリスクを負ったりすることなく、新しいアーキテクチャ設計を試したり、ワークロードをテストしたりできるようになります。これにより、企業はインフラストラクチャへの投資とそれに伴うリスクを削減しながら、新しいワークロードと方法論を試すことができます。

ローカル リソース要件を軽減します。クラウドは、高価なオンプレミス データ センターの利用と拡張要件のプレッシャーを軽減できます。オンプレミスのデータセンターは重要なワークロードを引き続き処理しながら、その他の日常的なワークロードや重要でないワークロードはクラウドでホストできます。企業は、データセンターの建設や拡張を事前に防止またはキャンセルすることができ、場合によっては、ローカルデータセンターの占有面積を削減することさえできます。

長期的なコスト管理。クラウドは長期的にはオンプレミスのデータセンターよりも必ずしも安価になるわけではありませんが、オンプレミスのデータセンターの多額の設備投資からクラウドの控えめな月次定期運用費に移行することで、企業はプロジェクト予算とコスト予測をより適切に管理できるようになります。

ワークロードのパフォーマンスが向上します。グローバル ワークロードは、単一のデータ センターから提供される場合、遅延やその他のパフォーマンス制限の影響を受ける可能性があります。パブリック クラウドは、世界中のさまざまな地政学的地域に多数の地域データ センターを提供します。これにより、企業はさまざまな地域のデータ主権やその他の規制要件に準拠しながら、それぞれのユーザーの近くでワークロードをホストしてパフォーマンスを向上させることができます。

クラウド移行戦略の種類

ワークロードをクラウドに移行するには、管理と技術の課題の複雑な組み合わせ、および人材とリソースの再調整を伴う、よく考えられた戦略が必要です。実行する移行の種類と移動するデータの種類を選択できます。思い切って移行する前に、次のクラウド移行チェックリストを必ず検討してください。

エンタープライズ ワークロードをオンプレミス データ センターからクラウド プロバイダー インフラストラクチャに移行するための基本的な戦略は 3 つあります。

持ち上げて移動します。再ホスティングとも呼ばれるこの戦略は、オンプレミスのワークロードとそのデータが基本的にクラウド プロバイダーのインフラストラクチャ内の対応するコンピューティング リソースとストレージ リソースに移動 (再ホスト) される、最も簡単なアプローチです。たとえば、依存関係が少なくビジネスへの影響が低い場合、仮想マシン (VM) 内のワークロードとそのストレージ ボリュームは、比較的簡単かつ迅速にクラウドに再デプロイできます。

再プラットフォーム化。すべてのワークロードが単純な再ホスティングに適しているわけではありません。多くのエンタープライズ ワークロードは複雑で、多数の依存関係があるため、パブリック クラウド環境でのパフォーマンスを向上させるために、エンタープライズはワークロードのデプロイメント アーキテクチャに何らかの変更を加えることを選択する場合があります。たとえば、ワークロードにデータベースが必要な場合、企業は対応するデータベースのコピーを展開するのではなく、クラウド プロバイダーを通じて既にホストされ、利用可能な互換性のあるデータベース サービスを使用できます。ワークロードの再プラットフォーム化は、再ホスティングよりも困難で時間がかかり、より多くのテストと検証が必要になります。

リファクタリング。このタイプのクラウド移行では、クラウド リソースの使用を最適化し、クラウドでのパフォーマンスを向上させるために、ワークロード自体を根本的に再設計する必要があります。たとえば、単一のモノリシック ワークロードを、スケーリングが困難な大規模で扱いにくい仮想マシンとして展開することを検討します。ワークロードは、コンテナベースの Kubernetes を利用したマイクロサービス アプリケーションとして再設計することができ、クラウド サービスの使用を最小限に抑えながら、さまざまなマイクロサービス コンポーネントを自動的にスケーリングしてパフォーマンスを向上させることができます。ワークロードのリファクタリングは、多くの場合、最も時間がかかり、最も複雑なタイプのクラウド移行プロジェクトであり、通常はクラウドファーストのワークロード設計と展開戦略を採用している企業向けに予約されています。

実際の移行アプローチやプロセスに関しては、ワークロードをクラウドに移行する理由は企業ごとに異なり、組織の目標もそれぞれ異なります。最初のステップは、クラウドに移行するアプリケーションまたはワークロードを特定することです。次に、移動する必要があるデータの量、作業をどのくらいの速さで完了する必要があるか、およびそのデータを移行する方法を把握します。データとアプリケーションのインベントリを作成し、依存関係を調べ、それらの依存関係をクラウドに複製する方法、または多くのクラウド サービス オプションに対応するために再設計する方法を検討します。

すべてのアプリケーションが企業のデータセンターから出る必要はないことに留意してください。残しておくべきアプリケーションには、ビジネスクリティカルなもの、スループットが高いもの、低レイテンシが必要なもの、GDPR などの厳格な地理的ガバナンス要件があるものなどがあります。

最後にコストを考慮します。組織は、ハードウェア インフラストラクチャとソフトウェア ライセンスに多額の投資を行っている場合があります。もしそうなら、ワークロードを移行する価値があるかどうかを検討する必要があります。クラウドへの移行後、IT 部門はデータのパフォーマンス、使用状況、安定性について懸念することになるため、これらの機能をサポートするツールに予算を組み込むようにしてください。

クラウド移行の展開モデル

今日の企業には、複数のクラウド モデルから選択できるものがあります。

• 公共。パブリック クラウドを使用すると、多くのユーザーがインターネット経由または専用接続を通じてコン​​ピューティング リソースにアクセスできます。
• プライベート。プライベート クラウドはデータ センターにデータを保存し、独自のアーキテクチャを使用します。
• ミックス。ハイブリッド クラウド モデルは、パブリック クラウド モデルとプライベート クラウド モデルを組み合わせ、2 つのモデル間でデータを転送します。
• 所により曇り。マルチクラウド シナリオでは、企業は複数のパブリック クラウド プロバイダーの IaaS オプションを使用します。

クラウド モデルの初期選択に加えて、クラウドの展開で考慮すべき 3 つの主要なクラウド カテゴリがあります。

サービスとしてのインフラストラクチャ。 IaaS は、コンピューティング、ストレージ、ファイアウォールやロード バランサなどのサービスがユーザーに提供される、典型的な「ユーティリティ コンピューティング」モデルです。ユーザーは、クラウドに展開されるワークロードに最適な方法でクラウド インフラストラクチャを選択して構築できます。

サービスとしてのプラットフォーム。プラットフォームは、特定の機能または高度に統合された機能を提供するように設計されたクラウド製品であり、ユーザーがそのような機能を自ら展開および保守する必要性を軽減します。 PaaS の例には、クラウドベースのソフトウェア開発プラットフォームやコンテナの展開/管理プラットフォームなどがあります。

サービスとしてのソフトウェア。 SaaS カテゴリでは、クラウド サービスは、Microsoft Office 365 や従業員の経費報告および払い戻しのための Concur などの生産性向上アプリなど、1 つ以上の特定のワークロードへのアクセスをユーザーに提供します。 SaaS を使用すると、企業がアプリケーションを展開して保守する必要がなくなり、アプリケーションの開発、運用、保守がプロバイダーに任されるようになります。

3 つのクラウド カテゴリはすべて、特定のビジネス ニーズに合わせて任意の組み合わせで同時に使用できることに注意することが重要です。

アプリケーションを配置する場所を決定するときは、移行後のパフォーマンスを考慮してください。最適なアプリケーション パフォーマンスを実現するために十分な帯域幅があることを確認します。また、アプリケーションの依存関係が移行を複雑にするかどうかを判断します。

アプリケーション スタック内で何が移動されるかを確認します。ネイティブ アプリには未使用の機能が多数含まれている可能性があり、これらの重要でない項目の移行とサポートに費用をかけるのは無駄です。古くなったデータはクラウド移行におけるもう一つの問題です。正当な理由なく履歴データをクラウドに移動するのは、多くの場合、取得コストが発生するため、賢明ではない可能性があります。

アプリケーションを検査する際には、その寿命を延ばすために戦略的なアーキテクチャを再考することが賢明です。ハイブリッドおよびマルチクラウド環境をサポートするプラットフォームは、次のとおりです。

• マイクロソフト Azure スタック
• Google Cloud の Anthos
• AWS アウトポスト
• VMwareクラウド
• Cloud FoundryやRed Hat OpenShiftなどのコンテナベースのPaaS

クラウド移行プロセスはどのように機能しますか?

組織が従うクラウド移行の手順またはプロセスは、実行する移行の種類や移動する特定のリソースなどの要因によって異なります。とはいえ、クラウド移行戦略の一般的な要素には次のものが含まれます。

目的を理解する。これが、あらゆるクラウド移行の「理由」です。すべてのクラウド移行は、移行の具体的なビジネス目的を定義し、移行プロジェクトに対する明確な期待を設定することから始める必要があります。企業が移行の具体的または測定可能な理由を少なくとも 1 つ特定できない場合は、プロジェクトを早期に一時停止することが最善です。

対象アプリケーションを特定します。これは、ビジネス、テクノロジー、コンプライアンスのリーダーがオンプレミス環境を評価し、クラウド移行の潜在的な候補を特定する、クラウド移行プロジェクトの「内容」です。パフォーマンス、セキュリティ、コンプライアンスなどの問題により、すべてのワークロードがクラウドに適しているわけではありません。そのため、移行に含めるワークロードを決定することは重要なステップです。さらに、移行は「すべてか無か」のプロセスではありません。一般的には、大規模で包括的な変換を行うのではなく、ワークロードを個別のプロジェクトとして移行することをお勧めします。依存関係の少ない単純で優先度の低いワークロードから始めて、より複雑または重要なワークロードに取り組む前に、移行プロセスと落とし穴についての経験を積んでください。移行には、関連するデータベースなど、移行プロジェクト内のすべての依存関係を含める必要があります。

クラウド ターゲットを選択します。これがクラウド移行プロジェクトの「場所」です。クラウド移行対象のアプリケーションを選択すると、企業はパブリック クラウド、プライベート クラウド、ハイブリッド クラウド、マルチクラウド、IaaS、PaaS、SaaS など、ターゲットに最適なクラウド展開モデルを選択できます。たとえば、老朽化し​​たオンプレミスのワークロードを SaaS サービスに置き換える単純な移行には、大手 SaaS プロバイダーが関与する可能性がありますが、高度なビジネス変革戦略には、プライベート クラウドの作成、ハイブリッド クラウドの確立、そして移行が含まれる可能性があります。

検証済みのクラウド パートナーを選択します。プロバイダーが優れた実績を持ち、近い将来もビジネスを継続できることを確認するために、クラウドの目標を慎重に検討することが重要です。これは過剰な予防策のように思えるかもしれませんが、クラウド コンピューティングでは、出所がすべてです。企業にとって最も混乱を招く出来事は、主要なサプライヤーが廃業したことが判明し、企業が慌てて代わりのサプライヤーを探さなければならなくなり、多くの場合、不利な結果を招くことです。

移行コストとニーズを評価します。クラウドにはコストがかかるため、移行プロジェクトでは移行コストを考慮する必要があります。これには通常、SaaS の月額料金、PaaS のユーザーごとの料金、IaaS リソースおよびサービスのさまざまなコストが含まれます。クラウド コストは継続的に発生するため、組織は移行と継続的なサポートに適切な予算を組む必要があります。同様に、移行が完了したら、ワークロードのパフォーマンス要件と期待を理解し、継続的なワークロード パフォーマンスの監視とレポートのためのメトリックと KPI を確立する準備をします。

適切なアーキテクチャを選択してください。 PaaS および SaaS アーキテクチャは大部分が設定されており、コストを比較的簡単に判断できますが、IaaS クラウド環境でのワークロードの設計は、特にスケーラビリティの高いアーキテクチャの場合、困難になる可能性があります。これには、ワークロードのニーズを満たす信頼性、セキュリティ、監視、パフォーマンスを備えた環境を構築するために、選択したクラウド ターゲットに関する専門知識を持つ熟練したクラウド アーキテクトの努力が必要です。 IaaS アーキテクチャ設計からのコスト データは、ワークロード コスト分析と予算編成を改善するためにループバックする必要があります。

移行計画を作成します。これはクラウド移行の「時期」と「方法」を示しており、企業が実際の移行のアプローチとタイムラインを概説できるようにします。計画には詳細なデータ移行に関する規定を含める必要があります。まず、必要なデータベースなどの依存関係をテストして検証します。意図したターゲットワークロードを移動する。その後、すべての最終テストと検証を実行します。そうして初めて、オンプレミスのワークロードをシャットダウンし、新しく移行したクラウド ワークロードをオンにするための明確な切り替えプロセスが必要になります。最後に、移行が失敗した場合や問題がある場合は、フォールバック プロセスを検討する必要があります。移行テストでは、アクセスとセキュリティに細心の注意を払う必要があります。

移行を実行します。すべての要素と計画が整ったら、組織は移行計画に従ってデータとワークロードを移行できます。ここですべての動作と詳細なテストが行​​われます。ビジネス リーダーと技術リーダー (通常はワークロード所有者) は、初期パフォーマンス レポートを確認して、フル負荷状態で適切なパフォーマンスとセキュリティを確保する必要があります。慎重な移行計画では、クラウド展開が完全に検証され、切り替えられるまで、クラウドとオンプレミスのワークロードを短期間同時に実行し、データを同期して、クラウド ワークロードを体系的により多くのユーザーに開放することができます。

追跡、監視、レポート。クラウド ワークロードには、クラウドで実行中のワークロードの可用性、アクセス、健全性、パフォーマンスを追跡するためのパフォーマンス監視サービスが装備されていることがよくあります。利害関係者は、レポートが使用可能であり、KPI が期待どおりであることを確認する必要があります。

フォローアップと組織変更。クラウドへの移行にはいくつかの結果が伴う可能性があります。技術的なレベルでは、以前はローカル ワークロードで使用されていたサーバーやストレージなどのローカル リソースを解放して再利用したり、廃止したりして、企業の電力および冷却コストを節約できます。ビジネスまたは組織レベルでは、ワークロードをクラウドに移行すると、従業員の再配置が必要になる場合があります。たとえば、カスタム ワークロードを SaaS 製品に移行すると、開発者は他のプロジェクトに取り組むことができるようになります。

その間、クラウド移行中によくあるいくつかの課題に備えてください。

• 相互運用性
• データとアプリケーションの移植性
• データの整合性とセキュリティ
• 事業継続性

適切な計画がなければ、移行によってワークロードのパフォーマンスが低下し、IT コストが増加し、クラウド コンピューティングの主な利点の一部が無効になる可能性があります。

モバイル ワークロード。移行の詳細に応じて、企業はオンプレミス サーバーからクラウド内の新しいホスティング環境にアプリケーションを一切変更せずに直接移動することを選択する場合があります。このモデルは、リフトアンドシフト移行と呼ばれることもあります。これは本質的には 1 対 1 の動きであり、主にインフラ コストを節約するための短期的な解決策として意図されています。

場合によっては、アプリケーションのコードやアーキテクチャを変更する方が効果的なこともあります。このプロセスは、アプリケーションのリファクタリングまたはコードのリファクタリングと呼ばれます。これは、クラウド移行前に実行することも、移行によってアプリケーションのパフォーマンスが低下したことが明らかになった後に遡って実行することもできます。

IT 管理者は、アプリケーションのリファクタリングが経済的に合理的かどうかを検討する必要があります。 ROI を分析する際に、コスト、パフォーマンス、セキュリティを計算します。変換が最小限であるか包括的であるかにかかわらず、アプリケーションでは少なくとも何らかのリファクタリングが必要になる可能性があります。

モバイルデータ。企業がオンプレミスのデータセンターからパブリック クラウドにデータを転送する場合、いくつかのオプションがあります。組織が選択するデータ移行のタイプは、移動するデータの量とタイプ、および移行を完了するために必要な速度によって異なります。

データとアプリケーションをクラウドに移行する方法の 1 つは、パブリック インターネットまたはプライベート/専用ネットワーク接続を使用することです。この方法を使用する場合は、必要な帯域幅を必ず計算して提供してください。大量のデータの場合、インターネットから切断することは現実的ではない可能性があるため、クラウド移行中に長時間のダウンタイムを回避するために、必ず適切な計画を立ててください。

もう 1 つのオプションはオフライン転送です。この方法では、組織はローカル データをデバイスにアップロードし、そのデバイスをパブリック クラウド プロバイダーに物理的に発送し、プロバイダーがデータをクラウドにアップロードします。

場合によっては、大量のデータに対して物理的な転送を使用する方が合理的である可能性があります。 Microsoft、AWS、Google、IBM などの主要ベンダーはすべて、オフライン データ転送サービスを提供しています。物理的な転送では追加の同期の必要性がなくなるわけではありませんが、データの移動に必要な時間と費用を削減できます。

クラウド移行テスト。ワークロードを本番環境に移行する前に、ストレス テストを実施し、許容できるパフォーマンスが得られるように最適化する必要があります。障害状態や冗長システムをテストすることも重要です。考えられるすべてのアプリケーション機能をテストする必要はありませんが、アプリケーションをクラウドに移行する前と移行後のアプリケーション パフォーマンスのさまざまな側面を深く理解しておく必要があります。クラウド移行テスト戦略を策定し、移行前と移行後のベースライン アプリケーション パフォーマンス (アプリケーションの起動時間と応答時間を含む) を確認し、適切なセキュリティとアクセス権限を確立して、他のサービスとの統合を成功させます。適切なテストには、適切なツールと、よく考えられたテストおよび検証の戦略と実践が必要です。

クラウド移行のセキュリティ。クラウド移行中は、新たなセキュリティの現実に特別な考慮が必要になります。ネットワーク経由でデータやアプリケーションを移行すると、資格情報や仮想マシンのスナップショットの盗難、マルウェアのインストール、繰り返しの移行を強制してシステム リソースを消費する永続的なサービス拒否攻撃など、さまざまな種類の攻撃を受ける可能性があります。

まず、組織は、組織とプロバイダーが責任を負う領域を概説したクラウド プロバイダーの共有責任モデルを理解する必要があります。ユーザーにとって、これは通常、データ、アクセス、ガバナンスなど、基盤となるインフラストラクチャの上にあるすべてのものを意味します。ガバナンス、アクセス管理、監視に関するルールと構造を確立することが重要です。法務およびコンプライアンス チームは、ワークロードとデータのコンプライアンス要件が適切に遵守されるように、クラウド移行の決定において役割を果たす必要があります。

IT スタッフの役割の変化。クラウドへの移行が完了すると、スタッフはデータのパフォーマンス、使用状況、安定性に重点を移します。全体的なハードウェア サポートが削減されました。ただし、クラウド ワークロードを管理する必要があるため、チームにクラウド管理トレーニング コースを追加することを検討してください。

クラウド移行を成功させるためのベストプラクティス

組織がアプリケーションやワークロードをクラウドに移行することを選択する理由は多数あり、各プロジェクトはリソースの割り当て、他のサービスとの統合、およびその他の複数の要因に応じて異なります。プロセスを簡素化し、成功に向けて変更を改善するための一般的なクラウド移行ガイドラインを次に示します。

組織からのサポートを得ましょう。経営陣から技術者、エンドユーザーまで、すべての関係者が関与し、それぞれの役割を理解していれば、移行はよりスムーズになります。

クラウドの役割と所有権を定義します。クラウド ワークロードの各側面を管理する責任者を事前に決定します。これは共有環境ですか?本人確認とアクセスの許可または制限はどのように行われますか?問題が発生した場合、サポートとトラブルシューティングの責任者は誰ですか?これには、設定とプロセスの適切なドキュメント化が含まれます。

適切なクラウド サービスを選択してください。クラウドプロバイダーには、選択できる幅広いサービスがあります。ワークロードがどのサービスを活用するかを明確にしてください。そうしないと、関連のないサービスを実行するリスクがあり、その一部はコストがかかり、相互に依存し、管理が困難になる可能性があります。

セキュリティリスクを理解してください。クラウド環境はインターネット攻撃によって簡単に侵害されます。クラウド環境の複雑さを考えると、誤った構成はおそらくより大きな問題です。クラウド展開のセキュリティ ポリシーを開発し、ポリシーが遵守されていることを確認し、包括的なセキュリティ テストを実行して潜在的な脆弱性を特定します。

クラウドコストを計算します。大規模なインフラストラクチャ投資に慣れている組織にとって、クラウドの従量課金モデルは魅力的でシンプルに思えるかもしれません。しかし、これは諸刃の剣です。サービスの選択と使用には細心の注意を払わなければ、月末にショックを受けることになります。クラウドスプロールと呼ばれる未使用のリソースとサービスを探し、不必要なコストを削減するように努めます。

長期的なクラウド ロードマップを策定します。クラウド移行が成功した場合、組織はおそらくその成功を他のワークロードでも再現したいと考えるでしょう。プロジェクトのタイムラインからハイブリッド クラウドのセットアップなどのさまざまな展開オプションまで、従うべき標準を決定します。

クラウド移行の課題は何ですか?

他の主要なテクノロジーの取り組みと同様に、組織はアプリケーションの移行プロセス中および移行後に潜在的な問題や課題に直面します。堅実な戦略を立てても、クラウド移行に伴うすべての障害や潜在的な問題を完全に排除することはできません。これらの課題には次のようなものがあります。

不確実かつ過剰なクラウドコスト。従来のデータ センターは、企業にとって主に固定コストを表し、高いコスト信頼性でワークロードを実行できます。クラウドは他のユーティリティに似ており、従量課金制のコスト モデルによって、ワークロードの実行にかかるコストが大きく異なる可能性があります。 API 呼び出しなどのサービスの予期しない高い使用率、またはスケーラビリティを使用してワークロードのリソースを増やすことによる計画外のアプリケーションの増加により、企業が準備していない予期しないクラウド コストが発生する可能性があります。コスト計画はクラウド アーキテクチャの中核部分であり、プロのクラウド アーキテクトの経験を活用することで、適切な設計を実装し、スケーラビリティにガードレールを設けて、クラウドのコストの高騰を防ぐことができます。

クラウド戦略の欠如。クラウド移行は変革をもたらす活動であると誤解され、ビジネス リーダーが単に宣伝文句に従っているため、クラウド移行を選択する組織が多すぎます。単にクラウドへの移行を選択するだけでは、ビジネス変革にはなりません。変革とは、クラウドを使用することではなく、クラウドをどのように使用してビジネスの有効性を高め、ビジネスを改善するかということです。すべてはクラウド戦略次第です。クラウド戦略が十分に検討されていなかったり、クラウド戦略が欠如していると、クラウド移行が失敗する可能性があります。優れたクラウド戦略では、現在のインフラストラクチャとターゲット クラウドを理解し、移行のボトルネックを予測し、修復のための偶発的事態を予測することなどに重点を置く必要があります。目標とは、なぜそれを実行するのか、何を実行するのか、どのように実行するのか、何が問題になる可能性があるのか​​、問題が発生した場合にどう対処するのかといった計画です。

クラウドでのアプリケーション パフォーマンス。 IT リーダーは、アプリケーションがオンプレミスの場合ほどクラウドではうまく動作しないことに気付くことがあります。クラウド移行が失敗した理由を特定する必要があります。低レイテンシ、セキュリティに関する懸念、コンプライアンス上の課題などが考えられます。多くの場合、クラウドに展開されたアプリケーションのコストは予想よりも高かったり、当初の予想どおりに動作しなかったりします。これは通常、アプリケーションやクラウドのせいではなく、従来のアプリケーション アーキテクチャの一部が、パブリック クラウドのコンピューティング、ストレージ、ネットワーク、および補助サービス向けに最適化されていないという現実によるものです。

アプリケーションのクラウドへの適用可能性。認識する必要があるもう一つの現実があります。それは、すべてのアプリケーションがクラウドに適しているわけではないということです。管理者は、どのアプリケーションをクラウドに移行するかを決定する際に、オンプレミスのアプリケーションを慎重に検討する必要があります。移行候補の選択はさまざまであり、ビジネス基準と技術基準の両方に基づいて行うことができます。たとえば、機密データを含むミッションクリティカルなワークロードは、コンプライアンスやデータ主権などのビジネス上の懸念に対処するための第一の選択肢であるため、オンプレミスのままにしておくことができます。

クラウド出口戦略はありません。クラウド移行計画で見落とされがちな側面は、アプリケーションとデータをクラウドから移動し、オンプレミスまたはプライベート クラウドの元の状態に戻す、堅実なクラウド終了 (または復帰) 戦略を策定することです。 IT マネージャーは、データの保存場所、テクノロジの変革の管理方法、発生する可能性のあるビジネス上または法的問題への対処方法を考慮する必要があります。最初の移行と同様に、復帰の前後に必ずアプリをテストしてください。水平スケーリングなどの特定のクラウドの利点に対応するためにアプリケーションに変更を加えた場合、アプリケーションがオンプレミスに戻ると、それらの利点は失われます。

失敗は永久的なものではありません。クラウド移行の失敗の多くは一時的な逆転に過ぎません。これを再評価し、場合によっては再設計して、リフトアンドシフトによる再ホストを行うのではなく、より高い成功確率でクラウドに戻すことができます。アプリケーションをクラウドに移行する前に行った変更を検討してください。アプリを元のプラットフォームに戻すことも選択肢の 1 つです。また、クラウド専用に再プラットフォーム化またはリファクタリングされたアプリケーションは、従来のオンプレミス インフラストラクチャに戻すときに問題が発生する場合もあります。おそらく最善策は、後で移行を試みる前に、別のクラウドに移行するか、パッチ/アップデートを適用して問題を解決してみることです。

インフラストラクチャの設計または構成が不十分です。最適なアプリケーション パフォーマンスと可用性を実現するには、仮想コンピューティング インスタンス、ストレージ ボリューム、ネットワーク要素、サポート サービスなど、ワークロードに適したリソースとサービスの最適なクラウド インフラストラクチャ設計とプロビジョニングが必要です。設計が欠落していたり​​不十分だったりすると、クラウド内のワークロードに悪影響が及び、移行が失敗する可能性があります。たとえば、クラウド管理者が犯す一般的な間違いは、間違ったインスタンス タイプを設定することです。選択したストレージとアプリケーション データ転送に十分なネットワーク接続だけでなく、適切な量の CPU およびメモリ リソースも選択してください。クラウド移行には通常、ワークロードの要件を理解し、移行されたワークロードをホストするための最適なクラウド コンポーネントを構築できる、十分に訓練された経験豊富なクラウド アーキテクトとエンジニアの作業が必要です。

スタッフが不十分、または十分に訓練されていない。適切な従業員トレーニングを軽視しないでください。クラウドでのアプリケーションの管理は、オンプレミスのデータ センターや従来の仮想化リソースの使用とは異なるため、異なる IT スキルと管理スキルが必要です。特に、クラウドではデータ セキュリティに関してオンプレミスとは異なるアプローチが必要です。スタッフのトレーニングを優先する必要があります。スタッフのスキルセットを考慮し、問題となっているサービスの制御と管理方法について全員が適切にトレーニングされていることを確認します。クラウド移行前にスタッフをトレーニングできない場合は、経験豊富な AWS パートナーを雇ってプロジェクトを管理するのが合理的です。

クラウド移行のトレンド

アプリケーションまたはワークロードをクラウドに移行するという組織の決定には、多くの要因が影響します。

大まかに言えば、クラウドはほとんどのデジタル変革イニシアチブにおいて中心的な役割を果たします。ビッグデータ分析は、ほとんどのオンプレミス システムでは実現できない規模とコンピューティング リソースを提供するクラウド プラットフォームの大きな魅力です。これは、今日の機械学習および人工知能プラットフォームほど明白ではありません。企業はクラウドネイティブテクノロジーの使用を拡大するにつれて、仮定や開発者や建築家の小さなグループに依存するのではなく、より標準のテンプレート駆動型プロセスを求めています。

Covid-19のパンデミックは、特にリモート作業の需要が増加するため、多くの企業がクラウドに移動する計画を加速するよう促しました。同時に、従業員と消費者は、デジタル生活のあらゆる面でより良いユーザーエクスペリエンスを期待しています。パブリッククラウドのスケーラビリティとグローバルな可用性は、ワークロードのパフォーマンスを向上させ、ユーザーエクスペリエンスの向上において中心的な役割を果たすことができます。単一のクラウドの展開は、特定のビジネスニーズに対処しながら、企業がさまざまなプロバイダーの独自の強みから利益を得られるように設計されたハイブリッドおよびマルチクラウド戦略に向けてシフトしています。

視聴する価値のあるその他の新興クラウド移動の傾向には、クラウドコストの考慮事項を理解するための金融運営（FINOPS）の採用、および消費者や従業員にますます人気があるクラウドプロバイダーの再生可能性またはグリーンまたは低炭素フットプリントエネルギーの使用など、持続可能性イニシアチブや社会問題の受け入れが含まれます。