2019 年に堅実なクラウド移行戦略を構築する方法

組織のオンプレミス IT インフラストラクチャをクラウドに移行することは、多くの企業が行う最も重要な決定です。しかし、この目的に向けた歩みはまだ小さいままです。人々が理解する必要がある重要なことは、移行プロセス全体が組織の IT スタッフにとって最も重要な仕事になるということです。

[[261334]]

移行プロセスは、既存のインフラストラクチャ、環境、およびアプリケーションに関連するデータの収集から始まります。次に、組織は、ネットワーク接続、ワークロード アーキテクチャ、運用コスト、実現可能性、移行による潜在的な影響など、さまざまな側面にわたるさまざまな分析方法を使用する必要があります。分析の結果は、組織のビジネス目標を実行可能なソリューションに変換するために使用され、組織の利害関係者が理解できる明確な価値提案が提供されます。

移行アーキテクトロールを作成する

組織がクラウド移行プロセスを開始する前に、その取り組みを主導する移行アーキテクトの役割を作成する必要があります。移行アーキテクトは、移行のあらゆる側面を完了する責任を負うシステム アーキテクト レベルのスタッフ メンバーです。

組織が大規模な移行を実施する場合、いくつかの決定と技術計画を作成し、実行する必要があります。ここで、移行アーキテクトが関与し、移行プロセスのあらゆる側面を担当します。これは、プロジェクトの成功にとって非常に重要です。

単一のクラウドを選択するか、マルチクラウドに移行するか

クラウド移行プロセスを開始する前に、組織はいくつかの質問に答える必要があります - 「インフラストラクチャを移行するために単一のクラウド サービス プロバイダーを選択する必要がありますか? 単一の環境で実行するように最適化する必要がありますか? 複数のクラウド プロバイダーからクラウド サービスを採用する方がよい選択肢ですか?」

組織にとって、選択したクラウド コンピューティング プロバイダーと提携するのは比較的簡単な作業です。組織の開発チームが理解する必要があるのは 1 セットのクラウド API のみで、そのアプリケーションは、選択したクラウド コンピューティング プロバイダーが提供するすべての機能を自由に活用できます。

とはいえ、このアプローチの欠点は、クラウド コンピューティング ベンダーのロックイン条項です。アプリケーションが単一のプロバイダーで動作するように更新されると、アプリケーションを単一のプロバイダーに移動するタスクには、多くの場合、最初のクラウド移行とほぼ同じくらいの作業が必要になります。第二に、独立したクラウド移行は、組織がクラウド サービス プロバイダーと重要な条件、サービス レベル契約 (SLA)、価格について話し合う能力にも悪影響を及ぼす可能性があります。

クラウドプラットフォームによって使用するアプリケーションは異なる

これはおそらく最も単純なマルチクラウド アプローチであり、1 つのアプリケーション セットを単一のクラウド プロバイダーで実行し、別のアプリケーション セットを別のクラウド プロバイダーで実行します。

このアプローチの利点は、複数のサービス プロバイダーによってもたらされる追加のビジネス利用を組織またはユーザーに提供し、各アプリケーションをどこで入手するかを柔軟に決定できることです。また、ユーザーは、実行されるサービスに基づいて各アプリケーションを最適化することもできます。

複数のクラウドプロバイダーでアプリケーションを実行する

組織は、アプリケーションの一部を特定のクラウド コンピューティング プロバイダーのクラウドで実行し、別の部分を別のプロバイダーのクラウドで実行することもできます。このアプローチの利点は、各アプローチが提供する主な利点 (高度な AI 機能と優れたデータベース速度など) を活用できることです。ただし、アプリケーションのパフォーマンスが制限される可能性があり、いずれかのサービス プロバイダーのクラウド プラットフォームに問題が発生すると、アプリケーションのパフォーマンスと顧客エクスペリエンスに影響が及ぶというリスクがあります。

たとえば、組織は Microsoft Azure の Compute Engine を使用できます。これは比較的安価であり、オブジェクト ストレージには Firebase、スケーラブルなファイル ストレージには AWS Elastic File System など、ストレージにはまったく異なるクラウド プラットフォームを使用するためです。さらに、組織は Google Cloud のエコシステムに完全に参入することなく、Google Cloud の AI を使用できます。

アプリケーションを構築する

多くの組織は、どこでも実行できるアプリケーションを開発しています。このアプローチの利点は、組織が複数のサービス プロバイダーにわたってクラウド プラットフォームを選択し、アプリケーションを同時に実行したり、各クラウド コンピューティング サービス プロバイダー間でアプリケーションの負荷を分散したりできることです。このモデルによって提供される柔軟性は、クラウド サービス プロバイダー間でワークロードを移行できるため、ベンダー交渉を行う組織にとって不可欠です。

しかし、欠点としては、組織が関与する各クラウド サービス プロバイダーのコア機能を活用することが困難になる可能性があることが挙げられます。これにより、アプリケーションをクラウド上でホストすることで得られるメリットが大幅に減少します。このアプローチでは、アプリケーションの開発と検証のプロセスも複雑になる可能性があります。

クラウド コンピューティング ソリューション プロバイダーの選択

組織がクラウド コンピューティング テクノロジーを初めて使用する場合は、組織が必要とする分野で幅広い専門知識を培ってきたクラウド コンピューティングの専門家とのパートナーシップを検討することが重要です。これらの専門家は、組織と対応するクラウド コンピューティング ソリューション プロバイダー間のつながりの構築に注力できます。また、クラウド コンピューティングを通じて組織の IT インフラストラクチャを作成、展開し、場合によっては運用することもできます。

移行プロセスをサポートするために選ばれたチームは、組織がビジネス目標を達成するために適切なパブリック クラウド ソリューションを選択できるよう支援できる必要があります。

このチームは、クラウド移行プロセスにおける機会を特定し、以下の内容を含む詳細な移行計画の策定を支援します。

• （１）ビジネスケース
• （２）作業負荷の優先順位
• （３）コスト分析
• （4）移行されたワークロード

これは、移行の範囲を定義し、利害関係者向けのビジネスケースを構築する際に非常に重要になります。

移行の範囲を定義する

クラウドへの移行の初期段階では、組織はプロセスから目標を特定し、取り組みの範囲を明確に定義する必要があります。これにより、組織は望ましい成果を定義し、クラウドへの移行の評価の開発に集中できるようになります。

移行チームには、リソース要件、データ収集方法、クラウド コンピューティングを評価するプロセスの概要を示す任務が与えられました。クラウド評価には、既存のオンプレミス IT インフラストラクチャの検出と評価、および移行の優先順位の確立が含まれます。

重要なインフラデータの収集

組織がクラウド コンピューティング プロバイダーの専門家と連携している場合、データ収集には専門家チームと社内の IT チームの両方との直接的なコラボレーションが含まれる可能性が高くなります。 2 つのチームが協力して包括的なデータ収集作業を実施し、詳細なアプリケーション インベントリを作成します。

組織は、エージェントレス データ収集ツールから始めて、既存のサーバーの基本スキャンを実行する必要があります。スキャンが完了すると、移行プロセスを開始する前に、障害を特定し、対処する必要がある可能性のある問題を評価するためのレビューが実行されます。

ほとんどの場合、これにはコンピューティング、ストレージ、およびネットワークに使用されるリソースのパフォーマンス評価が含まれます。分析が進むにつれて、組織またはワークグループは容量プロビジョニングのケースを構築できるようになり、提案されたソリューションが効率的で費用対効果が高いことが保証されます。

移行計画の詳細な分析を実施する

データ収集プロセスが完了したら、次のステップは、提案された移行計画の詳細な分析を実施することです。これには、次のようなものが含まれます。

• （１）中核となる組織目標
• （２）アプリケーションの識別、分類、ワークロード
• （３）ハードウェアインフラ、ストレージ、設備、保守費用
• （4）災害復旧要件

ここでは、ワークロードの準備状況の分析から開始できる実行可能な移行計画が特定されます。特に、ワ​​ークロードの優先順位付けは、組織が評価で概説された主要な目標を達成するのに役立ちます。

ビジネスケースとソリューションを提供する

最後に、ビジネスケースと提案されたソリューションを提示します。データ収集の初期ステップは、アプリケーションのインベントリを作成することです。クラウド コンピューティングの専門家は、ビジネス ケースの開発、ワークロードの優先順位リストの理解、各ワークロードに対応する移行コストの提供においてチームを支援できる必要があります。

最初のフェーズには、体系的なワークロード移行計画の作成も含まれます。移行プロセスが明確に説明され、提示されると、関係するすべてのチームが詳細なアーキテクチャを明確に把握できるようになり、組織の移行チームは重要な本番アプリケーションを新しいクラウド環境に移行できるようになります。

結論は

クラウドへの移行に関しては、最初から正しく行うことが不可欠です。後から是正措置を講じることはできません。組織と移行チームは、この広範なロードマップを活用して、設計と展開の時点で適切なレベルの専門知識が特定され、確保されることを保証しながら、クラウド移行タスクを達成できます。