リプラットフォームは、アプリケーションやインフラを効率的に最新化する方法です。アプリケーションを書き換えることなく、マルチクラウドおよびハイブリッド環境全体でパフォーマンス、スケーラビリティ、コントロールを向上させることができます。
この記事を読み終えると、以下のことができるようになります。
関連コンテンツ
是非、Cloudflareが毎月お届けする「theNET」を購読して、インターネットで最も人気のある洞察をまとめた情報を入手してください！
記事のリンクをコピーする
リプラットフォームは、多くの場合、部分的に、あるコンピューティング環境から別のコンピューティング環境にアプリケーションを移行するためのクラウド移行戦略です。完全な再構築やリホストとは異なり、リプラットフォームは、コアアプリケーションの機能を変更せずに、多くの場合インフラストラクチャレベルで、選択的な拡張を行うことに重点を置いています。その目標は通常、セキュリティの強化、アプリケーションインフラの統合、新機能の追加の簡素化、将来の開発に向けたより効率的な基盤を作ることになります。
多くの企業が、レガシークラウド環境、 ハイブリッドクラウド環境、および断片化されたクラウド環境におけるパフォーマンスの維持および管理の複雑さの増加に直面し、リプラットフォームの必要性に至ります。その複雑さの多くは、現実的な運用の中で自ら生み出したものです。
こうした構造的な要因に加えて、複数のクラウドにまたがってアプリケーションが拡張するにつれて、インフラストラクチャコストは増大し続けています。従来のデータセンター戦略や場当たり的なクラウド採用は、肥大化した断片的なエコシステムを生み出しました。
また、セキュリティ面のプレッシャーも増大しています。通常、企業は困難な2つの道のいずれかを選びます。各パブリッククラウド内にネイティブのセキュリティ制御を構築する道か、またはサードパーティのセキュリティオーバーレイを適用する道です。前者には一貫性のないポリシー、UI、APIの間をチームが乗り越える必要があるという課題があり、後者には運用負担が増し、可視性にギャップが生まれるというデメリットがあります。
さらに、パフォーマンスとコンテンツ配信の要求も大きな負担です。チームは、メディア最適化やコンテンツパイプライン、マルチデバイス配信のために複数のツールや専用のワークフローを管理しなければなりません。開発者は、イノベーションを進めるよりも、遅延やプラットフォーム制約のトラブルシューティングに多くの時間を費やしてしまいます。
こうした課題が収束すれば、リプラットフォームが成長の要因になり得ます。これにより、企業は環境を合理化し、運用の無秩序な増加を抑え、マルチクラウドやハイブリッドアーキテクチャのコントロールを回復することができ、チームはより高い俊敏性と自信をもって将来のイノベーションをサポートできるようになります。
リプラットフォームは、単にインフラを変更するだけの作業ではなく、その前段階から始まる構造化されたプロセスです。
プラットフォームの変更を決定する前に、組織は既存のアプリケーションを評価する必要があります。これには、各アプリケーションのアーキテクチャ、依存関係、インフラフットプリントを理解することも含まれます。このような可視性がなければ、互換性のないサービスを移行したり、新しい環境に引き継がれる可能性のあるパフォーマンスの主要なボトルネックを見逃す危険性があります。
評価すべき重要分野：
この評価は、どのアプリケーションがリプラットフォームの有力な候補であるかを優先する機会でもあります。完全なリファクタリングや、単純な「リフトアンドシフト」（リホスト）に適したものもあるため、すべてのアプリケーションをリプラットフォームする必要はありません。目標は、コスト削減、パフォーマンス向上、運用簡素化の観点から、リプラットフォームが最も価値をもたらすところを特定することです。
プロセスの早い段階でプラットフォームの互換性とスケーラビリティを徹底的に評価することにより、アプリケーション移行の際に発生するコストのかかる問題を回避することができます。この計画段階は、理論上のアーキテクチャ図ではなく、実際の制約やビジネス優先度に基づいた移行経路を確保するためのものです。
リプラットフォームとは、まったく新しいプラットフォームを選択して、有効なプラットフォームを放棄することではありません。ほとんどの企業は、白紙の状態から始めるわけではなく、段階的なアプローチを取ります。つまり、既存のスタックを改善し、スケーラビリティ、レジリエンス、パフォーマンスを強化しながら、現在のIaaS（Infrastructure-as-a-Service）やSaaS（Software-as-a-Service）の戦略を補完する形で、PaaS（Platform-as-a-Service）機能を徐々に導入していきます。
PaaSは、置き換えではなく、アクセラレーターとして機能します。既存の環境上にPaaSソリューションを重ねることにより、企業はアーキテクチャの再構築を中断することなく、自動スケーリング、管理されたサービス、より迅速なデプロイなど、クラウドネイティブのメリットを活かすことができます。このアプローチにより、チームはコアシステムを安定させながら、重要なコンポーネントを最新化することができます。
既存スタックにPaaSを導入する際、成功を確実にするための主な要素：
たいていの企業は、パフォーマンス、コスト最適化、リスク管理のバランスをとるために、ハイブリッド戦略やマルチクラウド戦略に依存し続けています。段階的リプラットフォームはこの現実に適しており、企業は単一のベンダーやアーキテクチャに縛られることなく、信頼性と俊敏性を高めることができます。
移行先が定まったら、開発チームはアプリケーションが新しい環境で効果的に稼働するよう準備を進める必要があります。そのため、プラットフォームの互換性を確保し、パフォーマンスを最適化するための技術的な調整が必要になることが多くあります。
円滑な移行を実現するための主なステップ：
これらの更新は、本番環境と密接に連携したステージング環境で反復およびテストし、本格規模の展開前にチームが問題を解決できるようにする必要があります。
リプラットフォームの最終段階では、アプリケーションを移行し、新しい環境でそのパフォーマンス、安定性、整合性を検証することに焦点を当てます。この段階では、綿密なアプリケーション移行計画と明確な移行戦略の価値が発揮されます。移行作業中は、特にリアルタイム取引や分散データベースを伴うシステムでは、データ整合性の維持が重要です。
このため、組織はよく、暗号ハッシュやチェックサムを使用して、転送中のデータが変更されていないことを確認します。暗号化は、転送中のデータの機密性と完全性を保証し、デジタル署名は改ざんの検出や追跡の可能性を提供するために使用されることがあります。移行後には、ハッシュ値の比較、一貫性チェック、あるいはデータベースネイティブツールを用いて、すべてのデータが正確に複製されたことを検証します。
ブルーグリーンデプロイメント、カナリアリリース、トラフィックミラーリングなどのテクニックを使用して、ダウンタイムを最小限に抑える必要があります。それにより、チームは完全なカットオーバーなしにアプリケーションの動作を検証できます。
アプリケーションが稼働すれば、焦点は検証に移ります。機能テストでは、コアロジック、ワークフロー、ユーザーエクスペリエンスが意図したとおりに動作することを確認します。パフォーマンステストでは、再プラットフォーム化されたアプリケーションを以前の状態と比較し、改善点を確認したり、遅延やエラー、速度と信頼性の問題を発見したりすることができます。セキュリティ検証では、アクセス制御、監視ツール、セキュリティポリシーが新しいスタック全体に正確に再適用されたことが確認されます。さらに、オブザーバビリティも不可欠です。ランタイムの挙動を可視化し、問題を早期に特定するためには、メトリクス、ログ、トレースを整備する必要があります。
検証に成功することで、最終的にはアプリケーションの動作が確認できるだけでなく、より良く、より安全に動作し、将来の開発ニーズに応じて拡張および進化できるようになります。
Cloudflareは、最適化されたコンテンツ配信、ローカライズされたデータストレージ、動的なトラフィックステアリング、SASEアーキテクチャ（ゼロトラストセキュリティを統合）によって既存スタックを拡張することで、リプラットフォームをサポートします。生成AIの脅威、悪性コンポーネント、API攻撃を阻止しつつ、可視化してコンプライアンスを維持します。Cloudflareは、サーバーレスコンピューティングとエッジキャッシングによって段階的なアプリケーションモダナイゼーションを支援し、マルチクラウド環境やハイブリッド環境の拡張性、パフォーマンス、制御を改善します。
アプリケーションモダナイゼーションとAIセキュリティの詳細はこちら。
「リプラットフォーム」とはクラウド移行戦略の一つで、組織がアプリケーションの一部を別のコンピューティング環境に移すことを指します。この場合、アプリの基本的なコードを書き換えることなく、インフラ部分の拡張的な書き換えのみが発生します。この戦略の主な目的は、セキュリティの強化、インフラの統合、機能追加の簡素化、そして将来の開発に向けてより効率的な基盤を確立することです。
組織がリプラットフォームを選択する多くの理由として、既存システムやハイブリッド環境、多様なクラウド環境でのパフォーマンス維持や管理の複雑さといった課題への対処が挙げられます。組織が複雑さを抱える理由として、「複数のチームがバラバラにクラウドを採用した」、「M&Aで新しいアプリケーションの統合が発生した」、「初期に部分的にクラウドを導入したもののクラウドの利点を十分に活かせないまま放置していた」などが考えられます。さらに、分散した環境でのインフラコストの増加や、セキュリティ対応へのプレッシャーの高まりも、リプラットフォームを行う大きな理由となります。
リホスト（最小限の変更でアプリケーションをクラウドに移行する方法）やフルリビルド（アプリケーションを完全に再開発する必要がある方法）とは異なり、リプラットフォームはインフラ部分に限定して改良を加える方法です。アプリケーション全体を書き換えることなく、アプリケーションとインフラストラクチャをモダナイズすることを目的としています。
リプラットフォームのプロセスの最初のステップは、既存のアプリケーションの詳細（アーキテクチャ、依存関係、インフラストラクチャのフットプリント）を評価・把握することです。この工程で、互換性のあるサービス、潜在的なパフォーマンスのボトルネック、移行の全体的な実現可能性を特定し、移行計画が現実の制約やビジネス目標に沿ったものであることを確認することができます。
PaaSモデルは、既存の環境をすべて作り直すのではなく、既存の環境上にクラウドネイティブな機能を追加することで、リプラットフォームを短期間で行うことができます。企業は、アーキテクチャの全面的な再構築による大きな混乱を経験せずに、クラウドのメリットである自動スケーリング、マネージドサービスを利用できるようになります。このような段階的な方法を取ることで、基幹システムを安定稼働させながら、重要なコンポーネントのモダナイゼーションを実現することができます。
大きな問題を生じさせることなく移行するためには、開発チームは通常、ハードコードされた設定のリファクタリング、古いライブラリの置き換え、コード内のモノリシックな制約を取り除く作業が必要です。その他の主なステップには、データの完全性を維持しながらのデータベースを移行すること、アプリケーションプログラミングインターフェース（API）の依存関係の互換性評価、アプリをコンテナ化して移動しやすくすること、Configuration as Code（CaC）を使用してインフラを管理することなどが含まれます。
アプリケーションの移行中および検証中のダウンタイムは、「ブルーグリーン」デプロイメント、カナリアリリース、トラフィックミラーリングなどの手法を活用することで最小限に抑えることができます。「ブルーグリーンデプロイメント」は、同じ構成の環境を2つ用意して、トラフィックをスムーズに切り替えます。「カナリアリリース」は、変更をいきなり全員に反映するのではなく、一部のユーザー群だけに段階的に提供します。「トラフィックミラーリング」は、本番環境の実際のトラフィックをステージング環境にも流し、利用者に影響を与えずに検証を行います。
移行中のデータ整合性に維持には、ハッシュ値やチェックサムを使用して、転送中のデータが変更されていないことを確認し、転送中のデータの機密性と完全性の確保には暗号化を施し、デジタル署名を使用して改ざんの検出や追跡の可能性を提供し、移行後にハッシュ値の比較や整合性チェックを実施したり、データベースネイティブツールでデータの整合性の検証を行い、正確に複製されていることを確認します。
Cloudflareはリプラットフォームを通じて、コンテンツ配信の最適化、地域ごとのデータストレージ、トラフィックの動的制御、ゼロトラストによる一元的なセキュリティなどを既存のアプリケーションスタックに追加します。さらに、生成AI（GenAI）の脅威、悪意のあるコンポーネント、API攻撃からの防御を支援し、コンプライアンスの可視化を提供します。Cloudflareのサーバーレスコンピューティングとエッジキャッシング機能により、段階的なアプリのモダナイゼーションを実現し、多様なクラウド環境およびハイブリッド環境全体でスケーラビリティ、パフォーマンス、コントロールを高めます。