企業のクラウド導入に不可欠な要素: 10 ステップのクラウド移行チェックリスト

クラウド コンピューティング業界の急速な発展により、多くの企業が重要なエンタープライズ アプリケーションをパブリック クラウドに移行することに取り組んでいます。場合によっては、企業チームはクラウド移行に苦労し、成功が限られていることがあります。しかし、その後の試行で得られた教訓を活かして、結果を改善することは可能です。

組織がミッションクリティカルなアプリケーションの最新化を検討しており、このプロセスの一環としてクラウド移行を計画している場合、他者の経験から学ぶことで、より少ない労力でより多くの成果を達成できるようになります。

したがって、この記事では、この知識を活用して、クラウド移行の成功の可能性を最大化するために企業の管理者が考慮して対処する必要がある主な領域に関する 10 のステップを構築します。

1. 移行アーキテクトの役割を確立する

クラウド移行を開始する前に、移行作業を主導する移行アーキテクトの役割を確立する必要があります。移行アーキテクトは、移行のすべてのワークフローの計画と完了を担当するシステム アーキテクト レベルの役職です。彼らの主な責任には、移行を成功させるために必要なリファクタリングの定義、データ移行戦略の設計、クラウド ソリューションの要件の定義、移行の優先順位と運用切り替えメカニズムの決定が含まれます。

大規模な移行プロジェクトの過程では、多くの決定と技術計画を立てる必要があり、移行のあらゆる側面を担当する移行アーキテクトを配置することがプロジェクトの成功に不可欠です。

2. クラウド統合レベルを選択する

企業がオンプレミスのデータ センターからクラウドにアプリケーションを移行する場合、アプリケーションを移行する方法には、浅いクラウド統合と深いクラウド統合の 2 つがあります。

浅いクラウド統合 (「リフト アンド シフト」と呼ばれることもあります) では、企業はオンプレミスのアプリケーションをクラウドに移行し、そこで実行します。クラウド固有のサービスを使用することなく、アプリケーションを変更するだけで、新しい環境でアプリケーションを実行できます。このモデルは、アプリケーションが「そのまま」クラウドにリフトされ、移動またはシフトされるため、リフト アンド シフトとも呼ばれます。

クラウドの緊密な統合では、企業は移行プロセス中にアプリケーションを変更して、主要なクラウド機能を活用できます。高度な自動スケーリングと動的負荷分散を使用することも、アプリケーションの一部に AWS Lambda などのサーバーレス コンピューティング機能を使用するなど、高度な機能を使用することもできます。 Amazon S3 や DynamoDB などのクラウド固有のデータ ストアを使用する場合もあります。

3. 単一のクラウドを選択するか、複数のクラウドを使用するか

クラウド移行を開始する前に、次の質問について考えてください。1 つのクラウド プロバイダーを選択し、アプリケーションをその単一の環境に最適化して実行するように移行しますか、それともアプリケーションを複数のクラウド プロバイダーで実行しますか。

特定のクラウド プロバイダーで動作するようにアプリケーションを最適化するのは比較的簡単です。開発チームはクラウド API の 1 セットを学習するだけで済み、アプリケーションはクラウド プロバイダーが提供するすべての機能を活用できます。

このアプローチの欠点はベンダーロックインです。企業がアプリケーションを 1 つのプロバイダーのみで動作するように更新した場合、そのアプリケーションを別のプロバイダーに移行するには、元のクラウド移行と同じくらい面倒なプロセスが必要になる可能性があります。さらに、クラウド プロバイダーが 1 つしかないと、価格や SLA などの重要な条件をクラウド プロバイダーと交渉する企業の能力に悪影響を与える可能性があります。

そして、さらに複雑になります。複数のクラウド プロバイダーを使用するには、いくつかの異なるモデルがあります。

（１）１つのクラウド、１つのアプリケーション。別のクラウド内の別のアプリケーション。おそらく最も単純なマルチクラウド アプローチは、1 つのクラウド プロバイダーで 1 セットのアプリケーションを実行し、別のクラウド プロバイダーで別のセットのアプリケーションを実行することです。このアプローチにより、企業は複数のプロバイダーとのビジネス活用を拡大できるだけでなく、将来的にアプリケーションを配置する場所の柔軟性も向上できます。また、企業は各アプリケーションを、それを実行するプロバイダーに合わせて最適化することもできます。

（2）アプリケーションを複数のクラウドプロバイダーに分割する。企業によっては、アプリケーションの一部を 1 つのクラウド プロバイダーで実行し、他の部分を別のクラウド プロバイダーで実行することを選択する場合もあります。このアプローチにより、企業は各プロバイダーが提供する主要な強みを活用できます (たとえば、あるプロバイダーは AI 機能が優れており、別のプロバイダーはデータベースの速度で知られているなど)。ここでのリスクは、アプリケーションが両方のプロバイダーのパフォーマンスに結びついており、どちらかのプロバイダーに問題が発生すると、アプリケーションの顧客エクスペリエンスに影響を及ぼす可能性があることです。

（3）クラウドに依存しないアプリケーションを設計する。このアプローチを使用すると、企業は複数のプロバイダーで同時にアプリケーションを実行したり、アプリケーションの負荷をプロバイダー間で分散したりできます。このモデルにより、企業はワークロードをあるクラウド プロバイダーから別のクラウド プロバイダーに簡単に移動できるため、ベンダーとの交渉において最大限の柔軟性が得られます。欠点は、各クラウド プロバイダーの主要機能の使用が困難になり、クラウドでアプリケーションをホストするメリットが減ることです。

4. クラウドKPIを確立する

主要業績評価指標 (KPI) は、アプリケーションまたはサービスが期待どおりに動作しているかどうかを測定するために企業が収集する指標です。クラウド移行に最適な KPI は、組織の進行中の移行の進捗状況を示し、アプリケーションに潜んでいる可能性のある目に見える問題や目に見えない問題を明らかにします。おそらく最も重要なのは、クラウド移行 KPI によって、組織は移行がいつ完了し成功したかを判断することができることです。

クラウド移行 KPI にはいくつかの主要なカテゴリがあります。

各カテゴリについて、ビジネスにとって最も重要な指標と、クラウドへの移行によって最も影響を受ける指標を特定します。

5. パフォーマンスベンチマークを確立する

ベースライン設定は、アプリケーションまたはサービスの現在の (移行前) パフォーマンスを測定して、将来の (移行後) パフォーマンスが許容できるかどうかを判断するプロセスです。ベースラインは、チームが移行がいつ完了するかを判断し、移行後の予想されるパフォーマンスの向上を検証するのに役立ちます。クラウド移行中にベースラインを参照して、発生した問題を診断することもできます。

マネージャーは、測定する各 KPI のベースライン メトリックを設定することを決定する必要があります。ベースラインを確立するためにデータを収集する期間を決定します。より短いベースライン期間 (1 日など) を選択すると、チームはより迅速に行動できますが、パフォーマンスの代表的なサンプルを収集できない可能性があります。より長いベースライン期間 (例: 1 か月) を選択すると、当然ながらより多くの時間が必要になりますが、より代表的なデータが提供される可能性があります。

チーム マネージャーは、平均または代表的なベースライン データのみを収集するのか、それとも「ピーク」期間または「重要な」期間に収集されたデータも含めるのかを決定する必要もあります。どのデータ収集モデルが業界に適しているかにかかわらず、収集するデータの種類と期間を明確に定義してください。

6. 移行コンポーネントの優先順位付け

ビジネス マネージャーは、アプリケーション全体を一度に移行するか、コンポーネントごと、またはサービスごとにクラウドに移行するかを決定する必要もあります。

まず、サービス間の接続と、どのサービスが他のどのサービスに依存しているかを特定します。依存関係グラフを使用して、どのコンポーネントをどの順序で移行するかを決定します。多くの場合、依存関係が最も少ないサービスから始めるのが理にかなっています。

この場合、最初に最も内側のサービスを移行し、次に最も外側のサービス (通常は顧客に最も近いサービス) を移行する必要があります。もう 1 つのアプローチは、顧客に最も近いサービス (最も外部的なサービス) から開始して、顧客に対するすべての影響を制御することです。

7. 必要なリファクタリングを実行する

企業は、アプリケーションやサービスをクラウドで可能な限り効果的かつ効率的に動作させるために、移行する前に、それらに対して追加の作業を行うことを望む場合があります。たとえば、アプリケーションを次のようにリファクタリングしたい場合があります。

したがって、実行中のインスタンスの数を可変にして効果的に動作し、動的なスケーリングを可能にして、クラウド サービスのコストを節約できる可能性があります。

これにより、企業は、事前にリソースを静的に割り当てるのではなく、必要に応じてリソースを動的に割り当てたり割り当て解除したりする機能など、動的なクラウド機能を活用して、リソースをより有効に活用できるようになります。

移行前に、よりサービス指向のアーキテクチャに移行して、企業が個々のサービスをクラウドに簡単に移行できるようにします。

8. データ移行計画を作成する

データの移行は、クラウド移行の最も難しい部分の 1 つです。データの場所は、アプリケーションのパフォーマンスに大きな影響を与える可能性があります。データ アクセス方法が主にオンプレミスのままである場合にデータをクラウドに移動すると、パフォーマンスに大きな影響を与える可能性があります。データはオンプレミスのままだが、それにアクセスするサービスはクラウドに存在する場合も同様です。

データ移行のオプションは次のとおりです。

• ローカル データベースとクラウド データベース間の双方向同期メカニズムを使用します。すべてのデータ コンシューマーをクラウドに移動した後、ローカル データベースを削除します。
• クラウドベースのデータベースと一方向に同期されるローカル データベースを使用し、コンシューマーがローカル バージョンにのみ接続できるようにします。準備ができたら、ローカル バージョンへのアクセスを無効にして、クラウド ベースのバージョンがプライマリ データベースになるようにし、クラウド ベースのコンシューマーによる新しいデータベースへのアクセスを有効にします。

9. スイッチ生産

企業は、いつ、どのように本番システムを古いオンプレミス ソリューションから新しいクラウド バージョンに切り替えるべきでしょうか?答えは、アプリケーションの複雑さとアーキテクチャ、特にデータとデータ ストレージのアーキテクチャによって異なります。

一般的なアプローチは 2 つあります。

• 一気に完成しました。アプリケーションまたはサービス全体をクラウドに移動し、そこで動作することを確認してから、トラフィックをローカル スタックからクラウド スタックに切り替えます。
• 少しずつやってください。いくつかのクライアントを移動し、すべてがまだ機能することをテストしてから、さらにいくつかのクライアントを移動します。すべての顧客がクラウドベースのアプリケーションに移行されるまで、このプロセスを続けます。

10. アプリケーションリソースの割り当てを表示する

すべてをクラウドに移行した後でも、考慮すべき点がいくつかあります。最も重要なのはリソースの最適化です。クラウドは動的なリソース割り当てに最適化されており、リソース (サーバーなど) が静的に割り当てられると、企業はクラウドの利点を活用できません。

クラウドに移行するときは、チームがアプリケーションにリソースを割り当てる計画を立てていることを確認してください。クラウド内のアプリケーションに追加のリソースを割り当てる必要がある場合、通常、プロバイダーからほぼ任意の量のリソースがすぐに入手できます。

この記事の 10 のステップは広範囲をカバーしていますが、クラウド移行中に考慮すべき他の事項もあります。たとえば、安全で信頼性の高いクラウド環境を構築することは、あらゆるクラウド移行において明らかに重要な部分です。幸いなことに、主要なクラウド プロバイダーは、企業が安全なシステムを構築および維持するのに役立つ重要なツールとリソースを提供しています。