クラウド移行チェックリスト:スムーズな (そして安全な) クラウドジャーニーを確保するための 8 つのステップ

ミッションクリティカルなアプリとデータをクラウドに移行することは大規模なプロジェクトであり、高い ROI を期待する場合は綿密な計画が必要です。適切な戦略がなければ、クラウドへの移行は、ビジネス上のメリットよりも多くの利益の損失と頭痛の種を引き起こす可能性があります。

この記事では、クラウド移行チェックリストを提供しますこれにより、クラウドへの移行がスムーズかつ安全に進み、不愉快な驚きがなくなります。以下の段階的な計画では、アプリをクラウドに移行する際の主要な側面をすべてカバーしているため、チェックリストを移行プロセスのベースラインとして使用できます。

クラウド移行チェックリスト

クラウドへの移行に苦労することは、企業にとって一般的な問題です。最近の調査によると、クラウド移行の 55% で大幅な遅延が発生するか、予算を超えています .

また、現在クラウドに移行している組織の 62% は、プロセスが 難しい と述べています。または失敗 .これらの企業のほとんどは、次のことを十分に考慮せずに移行を急いでいます。

総所有コスト (TCO)。
チームが大量のデータとミッションクリティカルなアプリをクラウドに移行する方法
クラウドの導入と統合のためのさまざまなオプション
潜在的な新しいサイバーセキュリティリスク
クラウドで運用するための社内チームの準備状況

以下のクラウド移行チェックリストにより、チームがアプリやサービスをクラウドに移行する前に、これらの要因を確実に検討できます。

頼りになる移行アーキテクトを選ぶ

クラウドへの移行には多数の技術的な決定と計画が含まれるため、1 人の専門家または専門家のチームを指定して取り組みを主導する必要があります。スタッフメンバーが 1 人でも複数人でも、移行アーキテクトの役割は次のとおりです。

サービスを評価して、オンプレミスまたはクラウドホスティングに適しているかどうかを確認する
移行のタイムラインとクラウドロードマップを作成する
データとアプリを移行するための最適な戦略を策定する
必要なアプリのリファクタリングを特定して監督する
移行の優先順位を決定する
必要なツールチェーンを定義する

専任のアーキテクトは、IT の全体像も提供する必要があります。このプロセスには、次の質問への回答が含まれます。

あなたはどんなアプリを持っていて、誰が (そしてどのくらいの頻度で) 使っていますか?
移行しようとしているアプリは、どの程度ビジネスに不可欠ですか?
プログラムはどのようなリソースを消費し、他のアプリに依存していますか?
現在実施されている SLA、事業継続対策、コンプライアンス対策は何ですか?
現在の運用に影響を与えるパフォーマンスの問題はありますか?

分析に応じて、移行アーキテクトは、現在の従業員が以下に必要なノウハウを持っているかどうかを評価する必要があります。

移行を実行します。
クラウド環境で運用する

チームが新しい環境で成功できると確信できない限り、クラウドへの移行を開始しないでください。

専任の移行チームは、総所有コスト (TCO) も決定する必要がありますクラウド移行の ROI を説明します。クラウド移行の TCO 評価には、次のような要素が含まれます。

移行の総費用
移行後のクラウドコスト (主に帯域幅とネットワークの価格)
スタッフのトレーニングの費用
定期的な移行後のメンテナンス
潜在的なダウンタイムのコスト
スペース、冷却、電気のコスト (オンプレミスプライベートクラウドの場合)

移行の目標と KPI を設定する

次のステップは、移行の主な目的を確立することです。一般的なハイエンドの目標は次のとおりです。

レガシーアプリのモダナイゼーション
特定のサービスの高速化
運用能力の向上
システムの回復力を高める
ユーザーエクスペリエンスの向上
サービスのスケーラビリティを向上させる
ランニングコストの削減
データセキュリティの向上

一般的な目標に加えて、チームはクラウド移行の主要業績評価指標 (KPI) を定義する必要があります。これらのメトリックは、移行されたアプリまたはサービスが期待に反してどのように機能するかを測定します。チームが追跡できる KPI の数に制限はありませんが、すべての指標は次の 2 つのカテゴリのいずれかに分類されます。

移行プロセス中に従う KPI
移行後の KPI。

移行プロセス中に企業が追跡できる最も一般的な KPI は次のとおりです。

移行期間 (全体とアプリごとの両方)
重要なサービスの可用性
サービスとデータセンターのダウンタイムの長さ
ダウンタイムによるサービスの低下
生成されたサービスチケットの数
移行費用

チームが追跡できる移行後の KPI をいくつか見てみましょう。

インフラストラクチャ KPI (CPU 使用率、サービスメモリフットプリント、ディスクパフォーマンス、負荷分散、レイテンシ、ネットワークスループットなど)。
アプリのパフォーマンス指標 (エラー率、タイムアウト数、平均応答時間 (ART)、ピーク応答時間 (PRT)、アップタイム、可用性など)。
ユーザーエクスペリエンスの KPI (リクエストの急増、HTTP ステータスコードエラー、スローおよびログに記録された例外、遅延、応答時間など)。
ビジネスインパクト指標 (チェックアウトプロセスの期間、購読および購読解除率、エンゲージメント率など)。
コスト KPI (毎月の請求、人件費、サードパーティツール、コンサルティングコストなど)

すべての KPI のベースライン値を設定する必要があります何を追跡するかを決める前に。ベースラインとは、アプリとサービスの現在の (移行前の) 状態を測定するプロセスです。これらの KPI により、移行後のパフォーマンスが許容できるかどうかを判断できます。

データとアプリの評価を行う

通常、データの移動はクラウドの採用において最も難しい部分であるため、データ評価はこのクラウド移行チェックリストの重要なステップです。データを慎重に評価することで、チームは以下を評価できます:

データのリスクレベル
移行する予定のデータの量と種類
全体的なデータ復元力
法的データプライバシー要件 (該当する場合)。
データの整合性に対する最も重大な脅威
潜在的な移行後のデータ侵害または漏洩のシナリオ

データが存在する場所は、またはサービスのパフォーマンスに影響を与える可能性があります。データアクセス方法がまだオンプレミスで動作しているときにデータをクラウドに移動すると、パフォーマンスに大きな影響を与える可能性があります。データベースがまだオンプレミスであるが、それにアクセスするサービスがクラウドにある場合も同様です。

データを評価するだけでなく、オンプレミスアプリも同じ扱いを受ける必要があります。移行する前に、チームはすべてのオンプレミスアプリとそのサーバーのインベントリを作成する必要があります。また、現在の仮想マシンを評価し、潜在的なアプリの依存関係を考慮する必要があります。

その結果、どのアプリをクラウドに移行する前にリファクタリングが必要かを判断できます。チームは、最初に移行するアプリの優先順位付けを開始することもできます。

クラウド移行オプションを評価する

クラウド移行チェックリストの次のステップは、どのアプリがどのタイプのクラウドとの統合を必要としているかを評価することです。 2 つのオプションがあります:

浅いクラウド統合 (別名リフトアンドシフト): アプリをリフトアンドシフトするときは、コードにほとんどまたはまったく変更を加えず、アプリをほぼ現在の形でクラウドにセットアップします。変更を加えずにアプリを移行することを再ホストと呼びます;アプリをクラウドに移行するときに小さな変更を加えることはリファクタリングです .
クラウドとの緊密な統合: 浅い対応物とは異なり、深いクラウド統合では、アプリを変更してクラウド機能を利用する必要があります。変更は、比較的単純な調整 (自動スケーリングや動的負荷分散の設定など) から、アプリをクラウドネイティブソリューションにする高度な更新 (サーバーレスコンピューティングの有効化など) までさまざまです。

浅いクラウド統合は、アプリの主要部分をリファクタリングするよりもはるかに高速なオプションです。一般に、ミッションクリティカルなアプリは通常、深い統合を行う価値があります。重要度の低いアプリやサービスは、クラウドへの移行後に時間をかけてリファクタリングできるため、浅いアプローチで対応できます。

また、企業は、どのサービスにどのような種類の統合が必要かを評価する際に、アプリの廃止または保持を決定することもよくあります。

廃止とは、クラウドにアップロードされても価値のない古いアプリやサービスを特定するプロセスです。
保持とは、通常、セキュリティまたはコンプライアンス上の懸念から、アプリをオンプレミスに保持するという決定です。

適切なクラウド導入モデルを選択する

クラウドへの移行を成功させるには、適切なクラウド展開モデルを選択することが不可欠です。さまざまなモデルがさまざまなユースケースに適合し、選択できる 5 つのオプションは次のとおりです。

パブリッククラウド (インターネットまたは専用の直接接続を介してコンピューティングリソースへのアクセスを提供するマルチテナント環境)。
プライベートクラウド (企業が独自のデータセンター内でクラウドリソースを実行するシングルテナントシステム)
ハイブリッドクラウド (自動化とオーケストレーションによってワークロードが環境間を移動する、オンプレミスシステム、パブリッククラウド、プライベートクラウドの組み合わせ)
マルチクラウド (2 つ以上のパブリッククラウド IaaS 環境の組み合わせ)
コミュニティクラウド (ニーズや懸念を共有する複数の企業間で共有されるインフラストラクチャ)

どの展開モデルを使用する必要があるかは、主にビジネス固有のニーズと目標によって異なります。ここにいくつかの指針があります:

パブリッククラウドは、従量課金制のスケーラブルな環境を提供します。パブリッククラウドは非常にスケーラブルですが、機密性の高いワークロードには適していない可能性があります。
プライベートクラウドは、ミッションクリティカルなワークロード用にカスタマイズされたオンプレミスクラウド環境を実行する予算のある企業に最適です。
ハイブリッドクラウドを使用すると、機密性の高いワークロードをオンプレミスで実行しながら、需要の急増時にパブリッククラウドのスケーラビリティを活用できます。
正しく行うと非常に有益ですが、ハイブリッドアーキテクチャを設計する前に知っておく必要があるハイブリッドクラウドの課題がいくつかあります。
マルチクラウドは、ベンダーロックインを懸念している企業や、複数のプロバイダのサービスを組み合わせて使用したいと考えている企業に最適です。

クラウドサービスプロバイダを選択

オンプレミスのプライベートクラウドをセットアップすることを選択した場合を除き、クラウド移行チェックリストの次の項目は、クラウドプロバイダーを見つけることです。ほとんどのベンダーは同様のサービスを提供していますが、すべてが同じというわけではありません。クラウドプロバイダーを選択する際の重要な考慮事項は次のとおりです。

価格。
サービスの選択
特定の地域での利用可能性
稼働時間の保証。
プロバイダの技術スタックに関する社内チームの知識
業界固有のコンプライアンス要件 (CCPA または GDPR に従ってユーザーデータを元の場所に保管するなど)
移行後のサポートとマネージド IT サービス

最も人気のあるサービスプロバイダーが常に最適であるとは限らないことに注意してください。著名なベンダーは、幅広いニーズを満たすことを目指しているため、特定の業種の企業と常にうまくマッチするとは限りません。

たとえば、ヘルスケアを運営する企業は、HIPAA への準拠をよりよく理解し、サポートするニッチなプロバイダーと提携する方がよい場合があります。

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

必要なクラウドデプロイとパートナーを決定したら、チームはアプリとサービスをクラウドに移行する前に必要な変更を開始する必要があります。

目標は、ソフトウェアをクラウドで可能な限り効果的かつ効率的に機能させることです .たとえば、チームは次のようにアプリをリファクタリングする場合があります:

可変数の実行中のインスタンスを操作して、ほぼ瞬時にスケーリングできるようにする
動的なクラウド機能 (現在のニーズに応じてリソースを割り当てたり割り当て解除したりする機能など) を利用する
よりサービス指向のアーキテクチャを作成して、個々のサービスをクラウドに迅速に移行します (今回と今後の両方)

今こそ、ガバナンスとセキュリティを再考する適切な時期でもあります。ガバナンス戦略を調整して、内部のセキュリティと制御への依存を減らし、プロバイダーのクラウドサービスへの依存を増やす必要がある可能性があります。クラウドセキュリティに関しては、次のことを行う必要があります。

移行によって新たな脆弱性が生じる可能性があるかどうかを評価する
クラウドアセットを安全に保つために、社内チームがプロバイダとどのように連携するかを理解する
現在のセキュリティ対策と慣行を調整 (および潜在的に改善) する
プロバイダーが提供する追加のセキュリティツールを利用できるかどうかを判断してください。
フェイルオーバーと障害復旧メカニズムを設定する

オンプレミスオペレーションからトラフィックを計画的に移行および切り替える

すべてを一度にクラウドに移行することはできますが、このアプローチは困難であり、成功させるにはリスクが伴います。代わりに、アプリとサービスを 1 つずつ移行する必要があります 、重要度の低いアプリから始めて、徐々に重要度の高いアプリに進みます。

この移行へのアプローチは次のようになります。

運用へのリスクを最小限に抑えてチームが移行できるアプリを優先します。適切な選択は、再ホストのみを必要とするか、最小限のリソース (低ストレージや計算など) を使用するアプリです。
次に、ビジネスにとって価値が高く、移行中のリスクが比較的低いアプリの移行を開始します。
最後に、ミッションクリティカルで破壊的なワークロードを移行の最終段階に残します。前のステップのアプリが最適に機能していない限り、これらのアプリの移行を開始しないでください。
手動または自動テスト (またはその両方) を使用して、移行が成功したかどうかを確認します。

アプリとデータストアのアーキテクチャに応じて、次の 2 つの方法でトラフィックをオンプレミスソリューションからクラウドに切り替えることができます。

一度に: アプリがクラウドで実行を開始するとすぐに、チームはすべてのオンプレミストラフィックを切り替えます。
少しずつ: チームがクラウドベースのアプリをセットアップしたら、数人の顧客を新しい環境に移動します。すべてが期待どおりに機能する場合は、すべてのエンドユーザーが新しいアプリに頼るまで、時間の経過とともに顧客をクラウドに切り替え続けます。