AWS クラウドへの移行: 考慮すべき事項

ある日、AWS/GCP/Azure/その他のクラウドプロバイダーに移行するように言われたらどうしますか?控えめに言っても、それは少しストレスになるかもしれませんね。

私はこれまでのキャリアで数多くの移行を経験してきましたが、この投稿では、DevOps エンジニア、アーキテクト、マネージャー、またはそのような移行に関与する可能性のあるその他の人々に役立つアイデアをいくつか共有したいと思います。私が AWS への移行に重点を置いたのは、主にこのテーマに関する専門知識があり、それがかなり一般的であるためですが、そこから得られる教訓は他のクラウド プロバイダーにも当てはまると思います。このシナリオでは、オンプレミスからクラウドへの移行について説明します。このタイプの移行は (私の意見では) クラウド間の移行よりもはるかに難しいためです。また、移住の際のすべきこと、すべきでないことに関して私自身の考えも共有したいと思います。しかし、批判的思考を通してそれらをフィルタリングし、誰もが独自の背景と経験を持っていることを忘れないでください。ある人にとって良いことが、別の人にとって良いとは限りません。

クラウド移行とは何ですか?

まず、移行とは何かを定義することから始めましょう。それが移行であるかどうかはどうやってわかるのでしょうか?私は次の定義が好きです:

クラウド移行とは、データセンターの機能を IaaS プロバイダーに移管するプロセスです。

「能力」がキーワードです。サーバー/VM/ハードウェア/データなどは移行しません。企業は機能を移行します。

移行戦略には、再配置、再ホスト (リフト アンド シフト)、再プラットフォーム化、再購入、再設計/リファクタリング、保持、廃止の 7 つの R があります。

たとえば、既存のオンプレミス ホスティング製品に代わる新しい製品を開発している会社を見たことがあります。この製品は最初から適切に設計され、クラウドネイティブになるように設計されており、クラウドでホストされます。移行またはグリーンフィールド プロジェクト タイプですか?上記の定義から、これは移行であると言えます。これは移行のためのリファクタリング戦略です。

オンプレミスでホストしているソフトウェアの代わりに、新しい SaaS サブスクリプションを購入した場合はどうなりますか?これもまた移行であり、自社株買い戦略です。

次の 7 つの移行戦略を詳しく見てみましょう。

場所を移動する。一部のワークロードをオンプレミスでホストし、そのままクラウドに移行します。これは限られたケースで可能です。クラウドに依存しないワークロードを移行する場合、またはプラットフォームがクラウドネイティブである可能性がある場合。例: Kubernetes クラスターをオンプレミスからクラウドに移行するか、VMware Cloud を使用して VMware マシンを移行します。

再ホスティング。これはリフトアンドシフトとも呼ばれます。ローカル VM/サーバーをクラウド内の VM に変換します。例: CloudEndure を使用してオンプレミスの仮想マシンを EC2 インスタンスに移行するか、EC2 インスタンスを作成し、ソフトウェアをインストールして、オンプレミスと同じ構成を適用します。

再プラットフォーム化。システムを再設計することなく、ワークロードをクラウドネイティブ プラットフォームに移行します。例: PostgreSQL を AWS RDS に移行するか、Docker コンテナを ECS に移行します。

買い戻し。一部のカスタム/レガシー システムを SaaS に置き換えました。例: カスタムのオンプレミス電子メール システムを SendGrid に置き換える、または CRM を Salesforce に置き換える。

再設計されました。アプリケーション アーキテクチャをクラウド ネイティブに変更し、マネージド クラウド サービスを使用します。これには、ゼロからの再構築も含まれます。例: アプリケーションのコードを変更して、ローカル ストレージではなく S3 にファイルをアップロードするか、アプリケーションをコンテナ化して ECS に移行します。

引退する。必要ない場合は、作業負荷の一部を削減することにしました。例: 移行されたアプリケーションは CloudWatch を使用するため、ログ サーバーは不要になります。

予約する。私たちはそれを地元に留めます。通常、これは一時的なものです。例: 多くの機能とカスタマイズを備えた巨大な Oracle データベースは、コストが莫大なため AWS に移行されませんでした。同社は、近代化フェーズ中に別のソリューションに置き換えられるまで、オンプレミスのままにしておくことを決定しました。

各移行タイプの大まかな段階を示す以下の図が気に入っています。移行に対処するための便利なチートシートになるかもしれません。

移住タブー

移行を実行するときは、次の操作はお勧めしません。

移行が速すぎます。 「クラウドに早く移行する必要がある。今すぐリフト アンド シフトを実行しましょう」と考えているかもしれません。すぐに始めないほうがいいです。再ホスト戦略が他の戦略よりも本当に速くなると確信していますか?ある例では、オンプレミスの VM を移行しようとしましたが、マシン上の OS が古かったため移行できませんでした。特定の OS レベルの依存関係は AWS のハードウェアでは機能しませんでした。これには多くの構成作業、カスタム コード、テストが必要であり、当初の見積りは完全に間違っていました。最終的にはプラットフォームの再構築となりました。

自分が持っているものを評価し、分析し、ビジネスケースを分析して考えます。このエンジニアリング作業では、行動する前に落ち着いてよく考える必要があります。

明確な目標のない移住。なぜ移住したいのですか?質問に答えられない場合は、答えを見つけるか、移行をまったく行わない必要があるかもしれません。コスト削減のために企業がクラウドに移行したいと考えている状況を目にしたことがあります。彼らは総コスト分析を行わずにリフトアンドシフト移行を実行しました。後になって初めて、ホスティング センターでかかった費用よりもさらにコストがかかることに気付きます。この移行は失敗したとみなされる可能性があります。

これを回避するには、明確な目標を定義し、その目標を達成するための目標状態を定義します。コストが主な要因である場合は、適切な計算を行い、それに応じて計画を立てます。目標状態を計画する際、コストの最適化が主な懸念事項になります。可用性が理由である場合は、それを測定し、SLO を定義して、目標状態での可用性に重点を置きます。

ブラックボックス移行。移行されたワークロードをブラック ボックスとして扱わないでください。移行対象、その技術要件、依存関係、およびその動作を正確に理解することが非常に重要です。この情報により、適切なワークロード移行戦略を選択できるようになります。そうしないと、間違った道を選んでしまい、結果が失われる可能性が高くなります。システムに関する情報を取得することは、計画時に最も重要なタスクです。

しっかりとした設計を忘れないでください。移住はストレスが伴います。そのため、人々は、すべてをできるだけ早くクラウドで実行することだけに焦点を当て、できるだけ短時間で迅速に実行しようとする傾向があります。構造的に健全なフレームワークの柱を別に設けました。これは間違いです。それは、さまざまな深刻度のさまざまな悪影響につながる可能性があります。適切に構成されたフレームワークの柱を無視しないでください。そうしないと、潜在的な問題やリスクが現実化するまで気付かないでしょう。

すべては 1 つの戦略を使用します。すべてのワークロードの全体的な計画を立てるのはいつでも簡単です。たとえば、リフトアンドシフト移行を実行し、すべてをクラウドに再ホストすることを決定します。しかし、もし何かを廃止できるとしたらどうなるでしょうか?最小限の労力で特定のコンポーネントをリプラットフォームできるとしたらどうなるでしょうか?ワークロードのすべてのコンポーネントを分析し、それぞれに固有の戦略を決定することで、大幅なリソースを節約できます。データを収集し、適切に計画します。

クラウド移行完了

クラウド準備状況評価を実行します。新しい場所に移転する場合は、次の点を考慮する必要があります。

• 気候は変わるだろう
• この場所で使用されている言語は異なる場合があります
• 生活費は異なり、より高くなる可能性があります

企業がクラウドに移行する場合、次のような質問をする必要があります。

• すべてのリスクを考慮しましたか?
• ワークロードを実際に機能させるには、何を変える必要がありますか?
• 仕事を遂行するために必要な人材は全員揃っていますか?
• すべてを完了するための予算はありますか?

クラウド準備状況評価は、企業がクラウド導入の準備ができているかどうかを判断するために、企業内のさまざまなプロセスについて長時間インタビューするものです。これは、クラウド導入フレームワーク (CAF) に基づいており、移行を成功させるために何を変更する必要があるかを示します。 AWS には、これらすべてをカバーするクラウド準備評価ツールがあります。移行を検討しているすべてのワークロードにこのプロセスを使用することを強くお勧めします。

ビジネスケースを作成します。ビジネスケースを説明します。移住の原動力は何でしょうか?移行によってどのような問題が解決されましたか?移民はどのような目標を達成すべきでしょうか?具体的に考えましょう。コストを削減したい場合は、合計を計算します。可用性を向上させる予定の場合は、明確な SLO を定義します。これは移行に向けた最初のプッシュとなります。他のすべてのアーティファクトはこれに基づいている必要があります。

自動検出とデータ収集。自動化されたデータ収集と分析を使用して、移行ポートフォリオを作成します。手動で作成されたスプレッドシートや口頭でのコミュニケーションに基づいて分析を行わないでください。マシンに在庫と使用状況の統計に関するデータを収集させます。収集するデータの精度が高ければ高いほど、より良い結果が得られます。ほとんどの場合、AWS Migration Evaluator サービスがこれに役立ちます。

ポートフォリオ管理。移行するワークロードのポートフォリオを作成し、分析し、各ワークロードの移行戦略を選択し、パイロット/第 1 波の移行用にいくつか選択し、タイムラインを見積もって計画を準備します。次に移行を実行します。移行セットが空になるまで繰り返します。データを共有します。専門家によるレビューを受けてください。

CCoE が見つかりました。これは前述の CAF の一部です。移行を実行する前に、戦略の設定とクラウドでの良好な動作の標準の定義を担当するチーム、つまりクラウド センター オブ エクセレンスを作成します。管理、運用、プラットフォーム、人材、財務、クラウドでサービスを使用または提供するその他すべての部門など、さまざまな分野の専門知識を持つ人材を含める必要があります。これらは、移行のための着陸ゾーンを準備し、着陸ゾーンのハード ポリシーとソフト ポリシーを準備する人々です。クラウドでの生活に向けて会社を準備します。あらゆるポリシーを再検討することを恐れないでください。新しい要因が出現したら、変更を加えます。

Well-Architected Framework レビュー (WAFR)。移行ウェーブ中および移行ウェーブ後に Well-Architected Framework レビュー (WAFR) を実施します。これにより、愚かなミスを防ぐことができ、技術的な観点から自分が行っている作業の概要を把握できるようになります。

近代化計画。近代化計画と移行計画を準備します。移住は物語の終わりではありません。クラウドで効果を上げるには、適切に設計されたレビューと最新化を実施する必要があります。最初の近代化は非常に大規模なものになる可能性があります。そのため、事前に予算とリソースを計画して割り当てることが重要です。そうしないと、コストが削減されるのではなく、運用コストが増加することになります。

まとめ

移住に伴うリスクとストレスを軽減したいのであれば、何も急ぐ必要はありません。物事を急ぐことで時間を節約でき、他の問題は後で解決できると考えるかもしれませんが、経験上、これは間違いです。最も可能性の高い結果は、最もストレスの多い状況、つまり新しいクラウドベースの運用環境に切り替えるときに遭遇するすべての問題を解決することになるでしょう。物事をじっくり考え、事前に問題を解決するのではなく、プレッシャーの下で選択が行われます。ここでは適切なエンジニアリング原則を適用する必要があります。橋を持ち上げて、ある川から別の川に移動させるのはうまくいきません。移行を成功させるための鍵は、測定、分析、設計、計画です。ワークロードをクラウドに移行するのは困難ですが、ここで紹介する「すべきこと」と「すべきでないこと」によって移行が容易になることを願っています。