「再ホスト、プラットフォーム再構築、再設計」の再考: 現実的なクラウド移行
Google Cloud Japan Team
※この投稿は米国時間 2021 年 3 月 26 日に、Google Cloud blog に投稿されたものの抄訳です。
プロフェッショナル サービス チームでは、クラウドへの大規模なアプリケーションの移行を計画するお客様を支援する際、膨大な時間を費やしてアプリケーション資産をトップダウンで評価し、各アプリケーションを「再ホスト（Rehost）」「プラットフォーム再構築（Replatform）」「リファクタリング（Refactor）」などの個別の移行戦略に分類しているお客様の姿を目にすることがあります。これは確立された業界慣行ではありますが、着眼点として、5 つの R1、6 つの R2、7 つの R3、それとも 8 つの R4のどれにするのか、としか注目されていないようです。
実際には、このよく使われる「〇つのR」移行戦略は、戦略と呼ぶべきものではありません。自社のアプリケーションについて理解していないことを示すプレースホルダにすぎません。移行パスを決定する際に何よりも大きな役割を果たすのは IT 組織のポリシーと機能であり、これらはアーキテクトによってどのようなトップダウンの計画が事前に策定されていても、最終的にはそれより優先されることがわかっています。
さらに、レイヤを問わず 1 つの移行戦略にそのまま当てはまるアプリケーションはほとんどないといってもいいでしょう。データベースを自己ホスト型の PostgreSQL からマネージド Cloud SQL にプラットフォーム再構築（Replatform）する一方で、アプリケーション レイヤは Compute Engine 上の同じ VM として再ホスト（Rehost）し、さらにロードバランサは Google のグローバル ロードバランサで置き換える（Replace）こともあります。
通常、ほとんどの組織に必要なのは、より包括的な移行アプローチです。このため、プロフェッショナル サービス チームは、お客様への対応時に、こうしたセマンティクスにはほとんど注意を払いません。この早期の計画段階では、テクノロジーに焦点を当てる前に、人材やプロセスにより注目します。まず、お客様に Google Cloud 導入フレームワークをおすすめし、クラウド移行のニーズが戦術的、戦略的、変革的のいずれであるかを判断します。その後、その情報に基づいて、以降でご説明する 3 つの基本的な移行アプローチを検討します。
移行ファクトリー
移行ファクトリーとは、仮想マシンまたはコンテナを一括してコピーまたはデプロイするアプローチです。このアプローチが有効なのは、対象のアプリケーションがシンプルで類似していて、移行を担当するチームが各アプリケーション チームとの調整作業をほとんど行わずに移行を自律的に実施できる場合です。この大規模なアプローチは、アプリケーション主体ではなくインフラストラクチャ主体の取り組み（特に、ホールセール型データセンターの廃止）に最適です。また、Google Cloud VMware Engine などのソリューションや、Migrate for Compute Engine または Database Migration Service などの専用ツールによって促進できます。
同様の理由で、移行ファクトリー アプローチは、各アプリケーションが個別に手動のレビューを受ける必要がある（社内ポリシーまたは外部の規制による）変更管理プロセスには適していません。避けられない変更をレビューし調整する作業の負担が、コードとデータの自動移行によって節約できる時間よりも大きくなります。これは、クラウド環境にデプロイする前に CI / CD ツールチェーンに重大な変更を加える必要がある場合も同じです。また、変更プロセスを考慮すると、現状のままクラウドへ移行するメリットは営利面で少なくなります。
まとめると、移行ファクトリー アプローチが最適なオプションである特定のシナリオもありますが、この条件に当てはまらないシナリオも多数あるということになります。
グリーンフィールド ソフトウェア開発
移行ファクトリー アプローチの対極にあるのが、既存のアプリケーションは一切移行せず、新しい「グリーンフィールド」（「クラウドネイティブ」）アプリケーションを開発するという方法です。このアプローチでは基本的に、教科書どおりのアジャイル ソフトウェア開発手法に沿って行います。このアプローチにはクラウドに固有の側面は特にありませんが、クラウドのマネージドおよびサーバーレス サービスは、こうしたソフトウェア ソリューションの開発を促進するうえで非常に役立ちます。
新しく開発されたアプリケーションはプロジェクトではなく製品として扱う必要があるため、チームは最後のマイルストーンに達した後も作業完了というわけにはいきません。むしろ、チームはそのアプリケーション専属となり、永久に（またはアプリケーションが非推奨になるまで）機能の改良と拡張を継続します。この点において、このアプローチは根本的にその他の移行とは異なります。あらかじめ決められたスケジュールはなく、アーキテクトが一方的に要件を指定することもありません。機能豊富で使いやすいソフトウェアを段階的に開発するためのスプリントがあるだけです。アプリケーションの開発を担当するチームは、小規模で部門の壁を超えた、長期的に存続できるものである必要があります。また、新しいアプリケーションを開発する場合、既存のアプリケーションを移行する場合より、はるかに多くの時間を要します。
モダナイゼーション ファクトリー
これまで拝見してきた中で、お客様が実施された移行の大半は、アプリケーション単位での一定のモダナイゼーションを伴うものでした。
ソフトウェアのモダナイゼーションには、さまざまな段階があります。多様な戦術とベスト プラクティスを利用して、アプリケーション自体のスケーラビリティ、可用性、セキュリティ、耐久性を改善する一方、アプリケーションのデプロイと運用に必要な労力を削減する必要もあります。
お客様は通常、こうした段階的なモダナイゼーションを介して、真の TCO 削減を実現します。これはまた、DevOps 機能の改善がクラウド導入と深く関連している理由でもあります。クラウドではすべてが API であるため、すべてを自動化できます。
たとえば、Infrastructure as Code の助けを借りた一貫性のあるプロジェクト環境のプロビジョニングは、注目に値するモダナイゼーションです。ステートレス ロジックからステートを切り離すことで、スケーリング上の大きなメリットを得られます。すべてのサーバーからシェルアクセスを取り除き、CI / CD パイプラインを介してのみ変更を push できるようにすることで、セキュリティ体制が大きく変革されます。段階的なソフトウェアのモダナイゼーションの事例は無数にあり、「〇つのR」の移行戦略にそのまま当てはまるものはありません。
ある程度のモダナイゼーションを加えたアプリケーションを Google Cloud に移行したいというお客様の対応にあたっては、その時点の資産に見つかった共通のアプリケーション レイヤ（「アーキタイプ」）について調べ、限定的なターゲット クラウド サービス、一連のモダナイゼーション戦術、CI / CD および Infrastructure as Code を介したプロセス自動化の程度について相互に合意します。この基準を超えたモダナイゼーション作業は、アプリケーションがクラウドに移行され、稼働を開始するまで延期すべきです。
モダナイゼーション ファクトリーの場合、個々のアプリケーションを熟知した小規模で部門の壁を超えたアプリチームと、すべてのアプリケーションで採用されるターゲット サービスのポートフォリオとモダナイゼーションの戦術を熟知した「ファクトリー」チームからなる、ハイブリッドなチーム構成が必要です。アプリチームはアプリケーションとともにファクトリーに出入りする一方、ファクトリー チームはその場で、一度に 1 つのアプリケーション（および 1 つのアプリチーム）を処理します。
重要な点は、ファクトリー チームに、移行の完了を妨げる権限をもつ意思決定者全員からの代表者を含める（そして、その人物に責任を割り当てる）ことです。ファクトリー チームは、マトリックス化されたビジネスの小宇宙のようなものです。組織の階層を越え、クラウドへのアプリケーションの移行を成功させるという共通の目標に向けて全員を結束させます。
そして最後になりますが、モダナイゼーション ファクトリーが、この新しいクラウド運用モデルについて担当者をトレーニングするための中心的なフォーラムとなるという点も重要です。これにより、IT 担当者に対して差し迫った必要性のないテクノロジーに関する時期尚早なトレーニングを行うのを回避できると同時に、アプリチームが移行の終了後も独力で作業するためのスキルと手法を確実に身に付けることができます。
最初の移行ファクトリーで着実に成功を積み重ねた後で、モダナイゼーション ファクトリーを追加し、その他のアプリケーションを並行して移行できます。
推奨アプローチ
では、貴社のアプリケーションにはどのアプローチを採用すべきでしょうか？真の移行戦略を策定するには、まずクラウドを導入する理由を考えてみる必要があります。そこからおのずとアプローチの手法が見えてくるでしょう。
たとえば、Google Cloud 導入フレームワークを思い出してみましょう。アプリケーションの変更を最小限に抑えて費用を削減することが目標（つまり戦術的）である場合は、移行ファクトリー アプローチをおすすめします。ソフトウェアから最大限のメリットを獲得することが目標（つまり戦略的）である場合は、モダナイゼーション ファクトリーまたはグリーンフィールド ソフトウェア開発アプローチをおすすめします。ビジネス上の新たな問題を解決する新しいアプリケーションでイノベーションを起こすことが目標（つまり変革的）である場合は、グリーンフィールド ソフトウェア開発アプローチをおすすめします。
組織がクラウドを導入する理由を明確にし、そのアプローチの手法について合意したら、「R」以外の事項も含め、その他すべてがうまく回り始めます。
Google Cloud への移行について詳しくは、クラウドへのデータセンター移行をご覧ください。または、クラウド移行費用評価（無料）にお申し込みください。
-プロフェッショナル サービス担当コンサルティングおよびエンジニアリング マネージャー Alex McWilliam
