「クラウドへの移行」には、2つの異なるモデルが登場しています。1つ目は、最も分かりやすいクラウドネイティブのアプローチです。ここでいうネイティブとは、グリーンフィールドで新規開発するか、既存のアプリケーションを書き直すことを意味します。このアプローチでは、クラウド向けに最適化すれば、パフォーマンスとセキュリティはクラウド上で適切なサービスをプロビジョニングすることで確保できるという前提のもと、アプリケーションに焦点を絞ることが推奨されます。これは完全に正しいわけではありませんが、ひとまずここではその前提で話を進めます。
2つ目のアプローチは「リフト＆シフト」です。その名のとおり、既存のアプリケーションをデータセンター基盤から持ち上げ、クラウドへ移行してクラウド基盤上に配置することに重点を置きます。ただし、このモデルではアプリケーションだけに注目することはできません。アプリケーションが依存する要素にも対応する必要があるためです。これには、アプリケーションサービスとインフラストラクチャサービスの両方にまたがる、その他のアーキテクチャコンポーネントも含まれます。
この点は最近、クラウドをセカンダリデータセンターとして活用することに焦点を当てたCloud Veloxのレポートでも取り上げられました。興味深いことに、同レポートでは次の調査結果が示されています。
“セキュリティやネットワークへの懸念から、IT部門はクラウドに圧倒的に否定的だという固定観念が根強く残っています。しかし、回答者の55%は、オンプレミスのネットワークおよびセキュリティ制御をクラウドにも拡張できるのであれば、クラウドDRを導入したいと回答しました。この結果から、IT担当者はクラウドそのものに反対しているのではなく、クラウドでも同等の制御を求めていることがうかがえます。 ”
Cloud Veloxはディザスタリカバリに焦点を当てていましたが、この課題はより広い範囲にも当てはまるようです。アプリケーションをクラウドへリフト＆シフトする際に、ネットワークとセキュリティの制御（サービス）も併せて移行できれば、導入しやすくなります。
基本的に、ネットワーク上でホストされるアプリケーションサービスを利用して長年にわたり最適化してきたアプリケーションを、それらのサービスなしで移行すると、これまでの最適化の効果が失われます。クラウドはインターネットバックボーンや利用者に物理的に近いため、クラウドに移すだけでパフォーマンスが向上するという誤解があります。これはある程度は事実ですが、すべてではありません。アプリケーションのパフォーマンスの多くは、ネットワーク遅延だけで決まるものではないからです。実際、パフォーマンス低下につながるアプリケーションの非効率性の多くは、コンテンツのサイズと構成、不適切な接続管理、アプリケーション固有のニーズに合わせてネットワークスタックを適切に調整できないことに関係しています。
アプリをクラウドにリフト＆シフトしても、セキュリティ上の懸念が突然なくなるわけではありません。データセンターでXSSやSQLiに対して脆弱だったアプリは、クラウドに移行しても脆弱なままと考えるべきです*。データセンターでWebアプリケーションファイアウォールや、プログラマブルプロキシに導入したセキュリティアーティファクトを使用してこうした懸念に対処していた場合は、アプリとともに、そのWebアプリケーションファイアウォールとプロキシもリフト＆シフトすることを推奨します。
アプリケーションだけでなく、アーキテクチャを「リフト＆シフト」できることが、コロケーション型クラウドという選択肢の人気が高まっている理由の1つです。オンプレミスよりもコストを削減でき、クラウドよりも優れた制御が可能だという見方もありますが、コロケーション型クラウドの特に魅力的な特長の1つは、アーキテクチャ全体をリフト＆シフトし、「隣接するクラウド」を活用できることです。企業によっては、企業のデータセンターまで通信することで生じる、パフォーマンスを大きく損なうレイテンシーを回避するため、データソースをクラウドにデプロイされたアプリケーションの近くへ移したい場合があります。また、バックエンドに影響を与えずにフロントエンドをスケールアウトし、同様にレイテンシーを回避したい場合もあります。コロケーション型クラウドプロバイダーへ移行すれば、非常に高速なデータセンターグレードの相互接続を介してクラウドがすぐ近くにあるため、これらを実現できます。
クラウドへのアプローチがコロケーションかパブリッククラウドかを問わず、クラウドへのリフト＆シフトを成功させる鍵は、可能な限り多くのアーキテクチャをそのまま移行することです。クラウドサービスの選択肢にかかわらず、移行によってパフォーマンスとセキュリティが損なわれないよう、移行中も重要なアプリケーションサービスを対象のアプリケーションとともに維持することが重要です。
*別名「Hoffの法則」とも呼ばれます。これは厳密には法則ではありませんが、2009年に初めて提唱された当時と同様、現在でも的確な見解です
著者について
Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事
F5 Application Study Tool：OpenTelemetryによるF5 BIG-IP環境の監視
F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。
F5 BIG-IPでAI防御を実現
F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。
F5 Advanced WAFによるGraphQL APIの保護
ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。
アプリケーションサービスの現状 通信業界版：リーダーとしての台頭
通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。
デジタルトランスフォーメーションは、単なるペーパーレス化ではない
デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。
やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。