安全なクラウド移行：失敗しないための8つの必須ステップ

ミッションクリティカルなアプリとデータをクラウドに移行することは、高いROIを期待するなら綿密な計画を必要とする大規模プロジェクトです。健全な戦略なしでは、クラウド移行はビジネスメリットよりも、損失と頭痛の種をもたらす可能性が高いです。

本記事では、クラウド移行チェックリストを提供し、あなたのクラウド移行がスムーズ、安全、かつ不測の事態なく進むことを保証します。以下のステップバイステッププランは、アプリをクラウドに移行するすべての主要側面をカバーしているため、移行プロセスのベースラインとして活用できます。

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

クラウド移行の苦戦はビジネスにとって一般的な問題です。最近の調査では、クラウド移行の55%が大幅な遅延または予算超過に見舞われることが明らかになっています。

また、現在クラウドへ移行中の組織の62%が、プロセスを「困難」または「失敗」と評しています。これらの企業の多くは、以下を十分に検討せずに移行に突入しています。

• 総所有コスト（TCO）
• 膨大なデータとミッションクリティカルアプリをどうクラウドへ移行するか
• クラウドデプロイメントと統合のさまざまなオプション
• 潜在的な新たなサイバーセキュリティリスク
• 社内チームがクラウド環境で運用する準備ができているか

以下のクラウド移行チェックリストは、チームがアプリとサービスをクラウドへ移動し始める前に、これらの要素を考慮することを保証します。

移行アーキテクトを指名する

クラウド移行には多数の技術的意思決定と計画が伴うため、単一のスペシャリストまたは専門家チームを指名し、取り組みを主導させる必要があります。一人か複数人かに関わらず、移行アーキテクトの役割は以下の通りです。

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

専任のアーキテクトは、あなたの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準拠をより深く理解しサポートするニッチなプロバイダーと提携する方が適しているかもしれません。

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

必要なクラウドデプロイメントと提携プロバイダーが決まったら、チームはアプリとサービスに必要な変更を、クラウドへ移行する前に開始すべきです。

目標は、ソフトウェアをクラウドで可能な限り効果的かつ効率的に動作させることです。例えば、チームはアプリをリファクタリングして以下を実現するかもしれません。

• 可変数の実行インスタンスで動作し、ニアインスタントなスケーリングを可能にする
• 動的クラウド機能（現在のニーズに応じたリソースの割り当てと解放）を活用する
• よりサービス指向のアーキテクチャを構築し、個々のサービスをクラウドへ迅速に移動可能にする（今回および将来的に）

このタイミングで、ガバナンスとセキュリティを見直すのも適切です。社内のセキュリティと制御への依存を減らし、プロバイダーのクラウドサービスにより依存するよう、ガバナンス戦略を調整する必要があるでしょう。クラウドセキュリティの観点では、以下が必要です。

• 移行が新たな脆弱性を生む可能性があるか評価
• 社内チームがプロバイダーとどう連携してクラウド資産を守るか理解
• 現在のセキュリティ対策とプラクティスを調整（および潜在的に改善）
• プロバイダーが提供する追加セキュリティツールの恩恵を受けられるか判断
• フェイルオーバーと災害復旧メカニズムを構築

体系的に移行し、トラフィックをオンプレミス運用から切り替える

すべてを一度にクラウドへ移行することも可能ですが、このアプローチは困難でリスクが高いです。代わりに、アプリとサービスを一つずつ移行すべきです。リスクの低い重要でないアプリから始め、徐々にクリティカルなものへ進みます。

このアプローチでの移行は以下のように進めるべきです。

• チームが最小リスクで移行できるアプリを優先。リホスティングのみ必要、または最小リソース（低ストレージ、低演算）を使用するアプリが良い候補
• 次に、ビジネスに高い価値をもたらすが、移行リスクが比較的低いアプリを移行
• 最後に、ミッションクリティカルで破壊的なワークロードを移行の最終段階で実施。前のステップのアプリが最適に動作するまで、これらを移行し始めてはいけない
• 手動または自動テスト（または両方）を使用し、移行が成功したかどうかを確認

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

• 一括切り替え：アプリがクラウドで稼働し始めたら、チームがすべてのオンプレミストラフィックを即座に切り替える
• 段階的切り替え：チームがクラウドベースアプリをセットアップしたら、少数の顧客を新環境へ移行。期待通りに動作すれば、時間をかけて徐々にすべてのエンドユーザーを新アプリへ移行

クラウド移行チェックリストで自信を持って移行しよう

クラウドへの移行はしばしば「やらない理由がない」決断ですが、多くのビジネスがアプリをクラウドに移行する際に苦戦し、限定的な成功に留まっています。上記のクラウド移行チェックリストを遵守すれば、すべての一般的な落とし穴を回避でき、高コストなミスを恐れずにクラウド採用の計画を開始できます。