そうです。すでに始まっています。プロセスの負担を軽減するため、包括的なクラウド戦略に組み込むことをご検討ください。
次に挙げるものの共通点は何でしょうか。サケ、カナダガン、オオカバマダラ、そしてアプリケーションです。
これらはすべて、ある場所から別の場所へ移動するものだと答えた方は、お見事です。
通常、クラウド移行といえば、オンプレミスからクラウドへの移行を指します。それには十分な理由があります。パブリッククラウドの利用が拡大していることを示すデータは数多くあり(F5のデータも含まれます)、その一方で、逆方向の移行が話題になることはほとんどありません。「そんなのは邪道だ!」という声が聞こえてきそうですが、現実を見てみましょう。実際に起きており、しかも皆さまが思う以上に頻繁に発生しています。
たとえば:
本番環境でパブリックIaaSを導入した回答者の42%が、「今後4年以内に、または継続的なプロセスとして、現在の戦略から移行する意向がある」と回答しました。そのうち70%は、「プライベートクラウドソリューションへ全面的に切り替えるのではなく、ハイブリッドクラウドへ移行する見込みである」と回答しました。
その理由は何でしょうか。最も多かった要因はコスト削減(67%)で、次いでセキュリティと安定性でした。これは、次のような事例からも裏付けられます。Pubmaticのパブリッククラウドからプライベートクラウドへの移行について。コストが移行を大きく後押ししました。
しかし、よく耳にするように、逆方向へ移行する企業もあります。それも少なくありません。プライベートIaaSプラットフォームを利用している企業の57%が「パブリッククラウドまたはハイブリッドクラウドへの移行を予定しており、そのうち77%がハイブリッドアプローチを採用する計画だと回答しています。」
その理由は何でしょうか。最も多かったのはスケーラビリティ(71%)で、柔軟性が僅差で続きました。コストは回答者の50%で3位でした。
スケーラビリティを求めてパブリッククラウドへ移行する一方、長期的なコストを考慮してプライベートクラウドへ回帰する傾向が見られます。
実際のところ、ほとんどの組織は「パブリッククラウド」だけを利用しているわけでも、「プライベートクラウドのみ」を利用しているわけでもありません。アプリを行き来させた後も、マルチクラウドを利用しています。この実態は、Cap Geminiのレポート「Cloud Native Comes of Age」で報告されているような開発動向からも確認できます。同レポートでは、「回答企業で現在新たに構築されているアプリケーションの6分の1(15%)は、クラウドネイティブ環境で構築されている」と指摘しています。
15%がクラウドネイティブであるなら、残りの85%はそうではないことになります。そこにはおそらく、メインフレーム、クライアントサーバー、3層構造のWebアプリケーション、さらにはコンテナ化された環境のマイクロサービスも含まれます。
現代の企業組織は、マルチクラウドであるだけでなく、アプリケーションアーキテクチャも複数の世代にまたがっています。
つまり、クラウドネイティブアプリよりもそれ以外のアプリの方が多いため、何らかのアプリをオンプレミス(プライベート)からオフプレミス(パブリック)へ、またはその逆方向へ移行する可能性はかなり高いということです。したがって重要なのは、この前提をクラウド戦略に組み込むことです。言い換えれば、おそらく避けられないこのプロセスの負担を軽減するために、事前に何ができるかを把握しておく必要があります。
クラウド間移行に向けた準備
まず検討すべきことの1つは、移行するアプリの想定利用期間です。長期にわたって利用する場合は、将来的なクラウド間移行の候補となります。プロモーション、マーケティング、イベント向けなど、短期間の利用に限られる場合は、このリストの最後まで進み、デプロイできます。
アプリを長期的に運用すると判断したら、次に、アプリをどのようにスケーリングし、保護するかを検討します。
セキュリティ 主張のためのサイドバー アプリが入力を受け付けず、データを扱わない場合でも、何らかのセキュリティ対策は必要です。アプリのセキュリティは複数の層で構成されており、プラットフォームとプロトコルの両方を保護しなければ、侵害を許すおそれがあります。メタデータ操作攻撃(HTTPヘッダーを標的とする攻撃)は、カスタムコードに起因する脆弱性と同等、あるいはそれ以上に危険です。 セキュリティの観点では、すべてのアプリが重要です。 |
アプリがクラウドネイティブであれば、手っ取り早く簡単な答えは「クラウドプロバイダーのサービスを利用する」です。これは妥当な選択肢です。同様に、アプリをオンプレミスのプライベートクラウドで運用するのであれば、「これまで使ってきたものを引き続き利用する」ことも妥当です。しかし、どちらを選んでも、将来的にサービスやポリシーを別のクラウドへ円滑に移行できなくなる可能性があります。現在、拡張性とセキュリティのために利用しているものを改めて精査し、それらのアプリケーションサービスをアプリとともに双方向に移行できるかどうかを見極める必要があります。

企業がアプリケーションの配信とセキュリティ確保に平均16種類のアプリケーションサービスを使用していることを考えると、この領域は、マルチクラウド環境でのアプリケーションのサポートはもちろん、移行する可能性のあるアプリケーションをサポートする能力を大きく妨げる要因になり得ます。なお、この16種類のサービスのうち、一部はクラウドネイティブサービスである必要があります。基本的に、データパスが全社共通の共有アプリケーションサービスとアプリケーションごとのサービスで構成されていると捉えると、そのアーキテクチャ上の区分が、パブリッククラウドプロバイダーがインフラストラクチャ層に設けている境界とほぼ一致していることがわかります。完全な区分ではありませんが、論理的な分離が可能になり、どのサービスを「マルチクラウド」対応にする必要があるのか、また、どのサービスをクラウドネイティブサービスや従来のデータセンターサービスに任せられるのかを判断する指針となります。
クラウド間で使用するアプリケーションサービスの一貫性が高いほど、制約が少なくなるため、2つ(あるいは3つ、4つ、またはそれ以上)のクラウド間での移行が容易になります。このアプローチには、自動化の取り組みをパブリッククラウドまで拡張できるという利点もあり、少なくとも、個別の運用担当者や手順の維持に伴う運用コストを削減できます。
クラウドの普及は必然でした。マルチクラウドも同様です。そして最終的には、クラウド間の移行が発生します。アプリのデプロイ先を最初に決定する前に、依存関係に注意を払い、クラウド横断型のアプリケーションサービスを利用することで、移行に伴う負担を軽減できます。
少なくとも、クラウド間移行という考え方をクラウド戦略の最上位に組み込んでください。事前に備えておくことで、将来の困難な(そしてコストのかかる)移行を回避できます。
著者について

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ブログをご覧ください。