アプリケーションをリプラットフォームする方法

リプラットフォームとは？

リプラットフォームは、多くの場合、部分的に、あるコンピューティング環境から別のコンピューティング環境にアプリケーションを移行するためのクラウド移行戦略です。完全な再構築やリホストとは異なり、リプラットフォームは、コアアプリケーションの機能を変更せずに、多くの場合インフラストラクチャレベルで、選択的な拡張を行うことに重点を置いています。その目標は通常、セキュリティの強化、アプリケーションインフラの統合、新機能の追加の簡素化、将来の開発に向けたより効率的な基盤を作ることになります。

企業がリプラットフォームを選択する理由

多くの企業が、レガシークラウド環境、 ハイブリッドクラウド環境、および断片化されたクラウド環境におけるパフォーマンスの維持および管理の複雑さの増加に直面し、リプラットフォームの必要性に至ります。その複雑さの多くは、現実的な運用の中で自ら生み出したものです。

• 分散型クラウドの採用：各チームが自分たちのアプリケーションのみを重視し、クラウドソリューションを完全な裁量で選択してきた場合、初期導入は迅速化されますが、結果としてアーキテクチャが統一されず、ビジネス全体で重複作業が発生します。
• M&A：M&Aによる事業の拡大は、はさらに複雑さを増します。新しく統合されたアプリケーションは、異なるアーキテクチャやクラウドプロバイダー上で動作することが多く、統合や一貫性のある管理が難しくなります。
• 部分的なクラウドの導入：多くの企業は、クラウドネイティブのパフォーマンス、スケーラビリティ、または耐障害性を確保するためにアプリケーションを再構築することなく、アプリケーションをクラウドに引き上げるなどの基本的なリホストからクラウドへの移行を始めました。そして、クラウド投資の価値が限定的となり、運用上のギャップが残ります。

こうした構造的な要因に加えて、複数のクラウドにまたがってアプリケーションが拡張するにつれて、インフラストラクチャコストは増大し続けています。従来のデータセンター戦略や場当たり的なクラウド採用は、肥大化した断片的なエコシステムを生み出しました。

また、セキュリティ面のプレッシャーも増大しています。通常、企業は困難な2つの道のいずれかを選びます。各パブリッククラウド内にネイティブのセキュリティ制御を構築する道か、またはサードパーティのセキュリティオーバーレイを適用する道です。前者には一貫性のないポリシー、UI、APIの間をチームが乗り越える必要があるという課題があり、後者には運用負担が増し、可視性にギャップが生まれるというデメリットがあります。

さらに、パフォーマンスとコンテンツ配信の要求も大きな負担です。チームは、メディア最適化やコンテンツパイプライン、マルチデバイス配信のために複数のツールや専用のワークフローを管理しなければなりません。開発者は、イノベーションを進めるよりも、遅延やプラットフォーム制約のトラブルシューティングに多くの時間を費やしてしまいます。

こうした課題が収束すれば、リプラットフォームが成長の要因になり得ます。これにより、企業は環境を合理化し、運用の無秩序な増加を抑え、マルチクラウドやハイブリッドアーキテクチャのコントロールを回復することができ、チームはより高い俊敏性と自信をもって将来のイノベーションをサポートできるようになります。

リプラットフォームの仕組み

リプラットフォームは、単にインフラを変更するだけの作業ではなく、その前段階から始まる構造化されたプロセスです。

現在のアプリケーションの評価

プラットフォームの変更を決定する前に、組織は既存のアプリケーションを評価する必要があります。これには、各アプリケーションのアーキテクチャ、依存関係、インフラフットプリントを理解することも含まれます。このような可視性がなければ、互換性のないサービスを移行したり、新しい環境に引き継がれる可能性のあるパフォーマンスの主要なボトルネックを見逃す危険性があります。

評価すべき重要分野：

• プラットフォーム互換性：現在のアプリケーションコンポーネントは、ターゲットプラットフォーム（ Kubernetes、 サーバーレス、 コンテナ など）で安全に実行できるか？独自のサービスやハードウェアへの依存が柔軟性を阻害する要因になっていないか？
• スケーラビリティの制限：アプリケーションを水平に拡張できないようなアーキテクチャの制約はあるか？ワークロードはクラウドや地域に効率的に分散できるか？
• パフォーマンスと遅延：遅延やスループットの問題に影響を受けやすいのはどのコンポーネントか？画像配信、動画レンダリング、キャッシングを最適化する機会はあるか？
• セキュリティとコンプライアンス：現在、どのようなクラウドネイティブセキュリティコントロールが導入されているか？また、それらはどのように移植可能か？環境を横断してこれらのポリシーを再適用することのリスクはあるか？
• 運用上のオーバーヘッド：アプリケーションを現状の状態に維持し、監視するために必要なツールと手動プロセスはいくつあるか？

この評価は、どのアプリケーションがリプラットフォームの有力な候補であるかを優先する機会でもあります。完全なリファクタリングや、単純な「リフトアンドシフト」（リホスト）に適したものもあるため、すべてのアプリケーションをリプラットフォームする必要はありません。目標は、コスト削減、パフォーマンス向上、運用簡素化の観点から、リプラットフォームが最も価値をもたらすところを特定することです。

プロセスの早い段階でプラットフォームの互換性とスケーラビリティを徹底的に評価することにより、アプリケーション移行の際に発生するコストのかかる問題を回避することができます。この計画段階は、理論上のアーキテクチャ図ではなく、実際の制約やビジネス優先度に基づいた移行経路を確保するためのものです。

既存のスタックを置き換えるのではなく、改善する

リプラットフォームとは、まったく新しいプラットフォームを選択して、有効なプラットフォームを放棄することではありません。ほとんどの企業は、白紙の状態から始めるわけではなく、段階的なアプローチを取ります。つまり、既存のスタックを改善し、スケーラビリティ、レジリエンス、パフォーマンスを強化しながら、現在のIaaS（Infrastructure-as-a-Service）やSaaS（Software-as-a-Service）の戦略を補完する形で、PaaS（Platform-as-a-Service）機能を徐々に導入していきます。

PaaSは、置き換えではなく、アクセラレーターとして機能します。既存の環境上にPaaSソリューションを重ねることにより、企業はアーキテクチャの再構築を中断することなく、自動スケーリング、管理されたサービス、より迅速なデプロイなど、クラウドネイティブのメリットを活かすことができます。このアプローチにより、チームはコアシステムを安定させながら、重要なコンポーネントを最新化することができます。

既存スタックにPaaSを導入する際、成功を確実にするための主な要素：

• スケーラビリティと弾力性：現行アーキテクチャとスムーズに統合し、水平スケーリングや自動プロビジョニング、トラフィックスパイク吸収機能をシームレスに提供するソリューションを採用する。
• クラウドネイティブサービス：マネージドデータベース、サーバーレスコンピューティング、統合型コンテンツ配信を使用して、運用の複雑さを軽減し、開発サイクルを短縮する。
• エコシステムとサポート：既存のDevOpsツールやCI/CDパイプラインとの互換性を確保し、強力なドキュメント、コミュニティサポート、エンタープライズグレードのサービスでコミットしているプロバイダーを選択する。
• コンプライアンスとデータ主権：データプライバシー、地域的ホスティング、コンプライアンスに関する規制基準を満たし、スケーリング時にもガバナンスが維持できるサービスを選択する。
• 透明性のある料金設定モデル：予測可能な使用量ベースの料金設定のプラットフォームを優先し、長期的にコストコントロールを維持する。

たいていの企業は、パフォーマンス、コスト最適化、リスク管理のバランスをとるために、ハイブリッド戦略やマルチクラウド戦略に依存し続けています。段階的リプラットフォームはこの現実に適しており、企業は単一のベンダーやアーキテクチャに縛られることなく、信頼性と俊敏性を高めることができます。

互換性を確保するためのアプリケーション更新

移行先が定まったら、開発チームはアプリケーションが新しい環境で効果的に稼働するよう準備を進める必要があります。そのため、プラットフォームの互換性を確保し、パフォーマンスを最適化するための技術的な調整が必要になることが多くあります。

円滑な移行を実現するための主なステップ：

• コードと依存関係の更新：ハードコードされた設定のリファクタリング、非推奨のライブラリの置き換え、ポータビリティを妨げるモノリシック制約を削除する。
• データベース移行：レプリケーション、バックアップ＆リストア、ライブマイグレーションなど、適切な戦略を選択して、環境間を移動しながらデータの整合性を維持する。
• APIの互換性：外部および内部のAPI依存関係を評価して、バージョンの整合性を確保し、移行中または移行後の破壊的な変更を回避する。
• コンテナ化：多くのワークロードでは、アプリケーションコンポーネントをコンテナ化することで、環境間のポータビリティとスムーズなオーケストレーションが可能になる。
• コードとしての構成管理：インフラストラクチャとサービスの設定を宣言的に管理し、ドリフトのリスクを低減する。

これらの更新は、本番環境と密接に連携したステージング環境で反復およびテストし、本格規模の展開前にチームが問題を解決できるようにする必要があります。

移行と検証

リプラットフォームの最終段階では、アプリケーションを移行し、新しい環境でそのパフォーマンス、安定性、整合性を検証することに焦点を当てます。この段階では、綿密なアプリケーション移行計画と明確な移行戦略の価値が発揮されます。移行作業中は、特にリアルタイム取引や分散データベースを伴うシステムでは、データ整合性の維持が重要です。

このため、組織はよく、暗号ハッシュやチェックサムを使用して、転送中のデータが変更されていないことを確認します。暗号化は、転送中のデータの機密性と完全性を保証し、デジタル署名は改ざんの検出や追跡の可能性を提供するために使用されることがあります。移行後には、ハッシュ値の比較、一貫性チェック、あるいはデータベースネイティブツールを用いて、すべてのデータが正確に複製されたことを検証します。

ブルーグリーンデプロイメント、カナリアリリース、トラフィックミラーリングなどのテクニックを使用して、ダウンタイムを最小限に抑える必要があります。それにより、チームは完全なカットオーバーなしにアプリケーションの動作を検証できます。

• ブルーグリーンデプロイメントでは、2つの同一の環境（ブルーとグリーン）を用意し、トラフィックを切り替えることで、最小限の中断で展開を実行します。
• カナリアリリースは、変更を小規模なユーザー群に段階的に展開し、問題がないことを確認してから拡大します。
• トラフィックミラーリングは、本番環境のライブトラフィックのコピーをステージング環境に送信し、エンドユーザーに影響を与えずにリアルタイムテストを実行します。

アプリケーションが公開されると、焦点は検証に移ります。機能テストでは、コアロジック、ワークフロー、ユーザーエクスペリエンスが意図したとおりに動作することを確認します。パフォーマンステストでは、再プラットフォーム化されたアプリケーションを以前の状態と比較し、改善点を確認したり、遅延やエラー、速度と信頼性の問題を発見したりすることができます。セキュリティ検証では、アクセス制御、監視ツール、セキュリティポリシーが新しいスタック全体に正確に再適用されたことが確認されます。さらに、オブザーバビリティも不可欠です。ランタイムの挙動を可視化し、問題を早期に特定するためには、メトリクス、ログ、トレースを整備する必要があります。

検証に成功することで、最終的にはアプリケーションの動作が確認できるだけでなく、より良く、より安全に動作し、将来の開発ニーズに応じて拡張および進化できるようになります。

Cloudflareによるアプリケーションのモダナイゼーション支援

Cloudflareは、最適化されたコンテンツ配信、ローカライズされたデータストレージ、動的なトラフィックステアリング、統合されたZero Trustセキュリティによって既存のスタックを拡張することで、リプラットフォームをサポートします。生成AIの脅威、悪意のあるコンポーネント、API攻撃を阻止しつつ、コンプライアンスを可視化します。Cloudflareは、サーバーレスコンピューティングとエッジキャッシングによってアプリケーションを段階的に最新化し、マルチクラウドおよびハイブリッド環境のスケーラビリティ、パフォーマンス、およびコントロールを改善します。

アプリケーションモダナイゼーションの詳細はこちら。