クラウド移行戦略とは?
クラウド移行戦略とは?
クラウドへの移行には、パフォーマンスとスケーラビリティの向上、運用コストの削減、耐障害性の向上など、多くの利点があります。クラウドは、ガバナンスとセキュリティを改善することでビジネスリスクを軽減しながら、より多くのビジネスチャンスをもたらし、技術的成果を高めます。
ただし、クラウドへの移行は単純な「移行してスイッチオン」するプロセスではありません。一般的なクラウド移行の課題には以下が含まれます。
- 経営陣のサポートやその他の利害関係者の賛同を得る
- インフラストラクチャタイプ間の相違
- クラウドプロバイダーの設定上の課題
- 新しいシステムの学習
- 転送と設定におけるセキュリティとコスト管理の考慮事項
- オンプレミスリソースとクラウドリソース間のハイブリッドニーズの判断
クラウド移行戦略は、組織が文書として作成した計画であって、現在のインフラストラクチャから新しいクラウドバージョンに移行するためのロードマップを示します。継続的な事業運営を確保するには、クラウド移行戦略を成功させることが不可欠です。さらに、将来のスケーリングと統合を可能にするために、低コストで効率の高いクラウドアーキテクチャを実装するための計画が必要です。
クラウド移行戦略の主な考慮事項は何ですか?
堅実なクラウド移行戦略は、業務の中断を可能な限り最小限に抑え、予期しない課題を発生させることなく、業務を立ち上げて運用するのに役立ちます。まず、選択したクラウドインフラストラクチャにおいて適切なクラウド機能と設定を特定することから始めます。また、次の点を考慮してください。
セキュリティとコンプライアンスの要件
移行前にセキュリティ評価を実施して、潜在的なリスクと脆弱性を特定します。ガバナンスの枠組みを明確に定義しておけば、移行中のポリシーの適用とコンプライアンスの確保に役立ちます。
オートメーションと移行ツール
オートメーションを活用することで、手作業が減り、移行リスクが最小限に抑えられます。また、Infrastructure as Code (IaC) を助け、環境全体で設定の一貫性を確保します。組織は、移行速度と信頼性を最適化するために適切なツールを評価する必要があります。AWS Migration Hub は、クラウド移行を見据えたジャーニーを始めるのに適した場所です。
移行および移行後の操作に関するトレーニング
クラウドへの移行が成功するかどうかは、IT チームとエンドユーザーの準備状況にかかっています。トレーニングプログラムでは、新しいクラウドテクノロジー、セキュリティプロトコル、運用上のベストプラクティスを網羅する必要があります。また、ナレッジベースを確立し、サポートと文書化を継続的に行うようにする必要があります。
スケジュールとタイムライン
段階的な移行アプローチは、業務の中断を最小限に抑えるのに役立ちます。まず、運用の継続性を維持しながら、重要なワークロードに優先順位を付ける移行タイムラインを作成してもよいでしょう。クラウド移行計画では、レガシーインフラストラクチャを廃止する予定を立てることも必要です。これには、未使用のサーバーの廃棄、冗長ライセンスのキャンセル、データを安全にアーカイブまたは削除したことの確認が含まれます。全員が新しいインフラストラクチャに慣れるまで、移行と廃止の間に十分な時間をとる必要があるかもしれません。
段階的な変革と継続的な最適化
クラウドの採用には、一回限りのシフトではなく、段階的な変革戦略が必要です。アプリケーションを徐々にモダナイズすることでリスクが軽減され、チームが新しいクラウド環境に適応できるようになります。時間が経つにつれて、自動スケーリング、リザーブドインスタンス、および適切なサイジング手法を活用して、費用を最小限に抑えることができます。定期的に監視することで、クラウドリソースの効率的な使用が確保されます。
主なクラウド移行戦略にはどのようなものがあるでしょうか?
リソースが異なれば、移行に必要なアプローチも異なります。アプリケーションをクラウドに移行するための移行戦略は 7 つあり、7 つの R と呼ばれています。
廃止
この戦略は、リソースが不要になったときに使用します。この場合、リソースの使用を停止するか、アーカイブするかを選択できます。これは単に、不要になったアプリケーションに対してサーバーをオフにすることを意味します。アプリケーションをクラウドに移行してもビジネス価値がなく、サポートされなくなったレガシーテクノロジーが使用されていて、オフにした方がコスト効率が高い場合は、廃止しましょう。
このようなアプリケーションは、CPU とメモリの平均消費量を分析することで特定できます。使用量が 5% 未満のアプリケーションは、すぐに廃止できます。消費量が 5〜20％のアプリケーションについても、特に 90 日以上インバウンドリクエストがない場合は検討してもよいでしょう。
保持
この戦略には、クラウドに移行せずにリソースを現状のまま維持することが含まれます。これは、セキュリティ上の理由、付加価値の欠如、物理的な依存関係、またはその他の複雑な考慮事項が原因である可能性があります。例えば、最近多額の投資を行ってインフラストラクチャをアップグレードしたアプリケーションの移行を延期してもよいでしょう。または、ベンダーが SaaS バージョンをリリースするまでサードパーティアプリケーションをそのまま使用することもできます。
リホスト
クラウド移行戦略のリホストは「リフトアンドシフト」アプローチを取ります。例えば、物理サーバーの設定とワークロードをクラウド環境の同じサーバーに移行できます。パフォーマンスの低下、互換性、長距離データレプリケーション、または長いカットオーバー期間を気にすることなく、複数のソースから AWS クラウドにマシンを移行できます。
再配置
再配置戦略では、インフラストラクチャをある環境から別の環境に移動します。クラウドインフラストラクチャに既存のリソースと同等のマッピングがある場合に使用されます。例えば、VMware SDDC を VMware Cloud on AWS に移行する場合などです。また、既存のクラウドインフラストラクチャを再設定するためにも使用できます。AWS 内では、インスタンスまたはオブジェクトを別の AWS アカウント、リージョン、または仮想プライベートクラウド (VPC) に移動することを意味することがあります。例えば、Amazon RDS DB インスタンスを別の AWS アカウントに転送する場合です。
再購入
再購入、つまり「ドロップアンドショップ」には、現在のアプリケーションやインフラストラクチャから別の製品への移行が含まれます。ユースケースには、オンプレミスライセンスから SaaS ライセンスへ移行する、アプリケーションを同様のクラウド製品に置き換える、カスタムアプリケーションをすぐに使えるクラウドソリューションに置き換える場合などがあります。購入する前に、ビジネス要件、特にセキュリティとコンプライアンスの要件に従って新しいアプリケーションを評価しましょう。
リプラットフォーム
リプラットフォーム戦略は、「リフト、ティンカー、シフト」または「リフトアンドリシェイプ」です。 これには、アプリケーションまたはインフラストラクチャコンポーネントを再設定し、何らかの方法でクラウド向けに最適化することが含まれます。セキュリティを損なうことなく、レガシーアプリケーションを実行し続けられます。同時に、仮想マシンをコンテナに移動したり、マネージドサービスまたはサーバーレスサービスに移行したり、あるオペレーティングシステムから別のオペレーティングシステムに移行したりすることで、コストを削減し、パフォーマンスを向上させることができます。
例えば、Microsoft SQL Server データベースを Amazon RDS for SQL Server にリプラットフォームしたり、ML ワークロードを Amazon SageMaker に移行したりすることができます。
リアーキテクト
リアーキテクト戦略は、アプリケーションまたはインフラストラクチャのアーキテクチャを変更してクラウドネイティブ機能を活用し、プラットフォーム変更にとどまりません。モノリシックなデザインのレガシーアプリケーション、テストカバレッジが不十分、または保守が難しくなっている古いコードを持ったレガシーアプリケーションがある場合は、リファクタリングを検討してください。アプリケーションによっては、一部のコード領域を再利用しながら、他のコード領域を変更したり、ゼロから再設計したりすることを検討してもよいでしょう。リアーキテクトは、クラウドとエンジニアリングの専門知識の両方を必要とする長いプロセスになる可能性があります。
クラウド移行プロセスとは?
クラウド移行プロセスは、現在のテクノロジーやターゲットテクノロジーにとどまらず、組織の変更管理のあらゆる側面をカバーしています。これには次の 3 つのステップが含まれます。
ステップ 1 – 評価
クラウド環境に移行する前に、変革を成功させる可能性を最大限に高めるための準備状況を評価する必要があります。AWS Cloud Adopment Framework (CAF) では、ビジネス、人、ガバナンス、プラットフォーム、セキュリティ、運用という 6 つの観点からクラウド移行の準備状況を勘案します。
また、組織のアプリケーションポートフォリオを評価して、アプリケーションを移行およびモダナイズする方法を理解する必要があります。複雑なインフラストラクチャ、統合、セキュリティ、ID に関する考慮事項が既存のアプリケーションの検討に役立ちます。アプリケーションポートフォリオ評価は、主要な利害関係者とデータソースを特定し、アプリケーション移行の優先順位を決めるのに役立ちます。
AWS クラウド準備状況評価を使用して、組織のクラウドの準備状況を自己評価できます。AWS では無料の移行評価も行っています。この評価では、詳細なビジネスケース、運用、セキュリティ、人材など、複数の側面にわたってお客様の組織を評価し、採点します。
組織の準備状況に落とし穴がある特定の領域を発見するのをサポートします。このような落とし穴を埋めることで、移行プログラムが成功する可能性を高めることができます。
ステップ 2 – 準備
準備段階では、移行計画を立て、クラウドプロバイダーのターゲットアーキテクチャに基づいて現在の環境に最適な移行戦略を選択します。タスクには以下が含まれますが、これらに限定されません。
- 移行リソースの優先順位付け。
- スピード、ダウンタイム、運用能力などの移行目標の詰め作業。
- 移行および移行後のサービス管理と運用に関するスタッフトレーニング。
- ターゲットアーキテクチャとサービスの作成
- 小規模または重要度の低いアプリケーションやサービスによる移行環境のテスト
準備段階ではアーキテクチャ決定レコード (ADR) を使用することを強くお勧めします。このライブドキュメントには、それぞれのアーキテクチャ上の決定と、その選択の背景にある理由が記録されています。
例えば、多くの組織では、レガシーソフトウェアシステムをリファクタリングするか、そのまま使用することを選択しています。リファクタリングは時間と費用がかかる場合がありますが、通常は数年後に ROI をもたらされます。アプリケーションがどのようにリファクタリングされるかも、このような計算に影響します。ADR は、リファクタリングされた構造、依存関係、インターフェイス、および構築手法がどのように同等の (またはより優れた) パフォーマンスを実現し、時間の経過とともに所有コストを削減したかを説明できます。
ステップ 3 – 移行とモダナイズ
移行プロセス自体は、組織シフトの規模と要件によって異なります。小規模または単純な移行は、繰り返し可能なパターンや自動化可能な共通性がない、すぐに利用できるツールを使用して 1 つずつ展開できます。大規模またはより複雑な移行には、複数のアプリケーション、インフラストラクチャ要素、組織領域、またはプロジェクトにまたがる新たなパターンが必要です。
AWS では、複雑な移行をサポートするために、AWS Application Discovery Service や AWS Database Migration Service など、いくつかの移行ツールを提供しています。また、大規模なクラウド移行アクティビティを実施するための移行ファクトリの構築を検討することもできます。移行ファクトリは、複数のチームが同時に作業を行い、特定のチームが移行のリホスト、リプラットフォーム、リファクタリングを行う集まりです。リファクタリングチームは通常、ソフトウェア開発チームと同様に作業し、DevOps の様なサポートを受けます。
初期移行に基づいてオートメーション計画、プロセス、ツールを開発することで、組織全体のクラウド移行プロセスを高速化できます。
AWS はクラウド移行戦略をどのようにサポートできますか?
AWS クラウドサービスでは、既存のデータやアプリケーションを活用して、強力な基盤となるクラウドプロバイダーが提供する AI やその他の機能を利用してスケールや拡大を図ることができます。適切なクラウド移行戦略を選択することは、プログラムの成功に不可欠です。クラウド移行を検討している場合でも、リソースをクラウドに移行する準備ができている場合でも、AWS では開始するためのガイダンスや評価ツールが用意され、さまざまなパートナーを利用できます。
AWS Migration Acceleration Program (MAP) は、実績のある包括的クラウド移行プログラムであり、何千ものエンタープライズのお客様をクラウドに移行した AWS の経験に基づいています。MAP は、ツール、カスタマイズされたトレーニングアプローチとコンテンツ、AWS パートナーネットワークのパートナーの専門知識、グローバルなパートナーコミュニティ、AWS の投資を提供します。予算内で実行を自動化および加速するには、MAP をパートナーとして捉えてみてはいかがでしょうか。
AWS クラウド移行にアクセスして、今すぐ AWS に移行してモダナイズしましょう。