こんにちは、ホシイです。

近年、“オンプレ回帰” という言葉がよく聞かれるようになりました。
人々 (とシステム) は、クラウドからオンプレに帰ってきているのでしょうか?

オンプレ回帰という話題において、場合によって話題の中心が必ずしも合致していないこともあるように感じています。大きくは、実際にクラウドからオンプレに移行を実施する・した人の観点と、それを大きな現象として観察している人の観点の差でもあるように思います。

今日は、これをじぶんの考えとしてまとめるべく書き出してみます。
(見聞きした情報の影響が多分に含まれます。いくつか末尾に参考にさせていただいた情報への参照を置いておきます)

“オンプレ回帰” は増加している

まずここで言うオンプレについて、自前で管理するインフラのことを指しているとします。会社のフロアやサーバールーム、借用して専有管理するデータセンターの一角なども含まれるでしょう。

そのオンプレへ “回帰” ということですから、オンプレに帰ってきているということです。帰ってきた (くる) ということは、その前にどこかに行っていた (いる) ということです。その多くは、クラウド、より正確にはパブリッククラウドからの回帰でしょう。

現在のパブリッククラウド市場は年々成長し、利用者・利用量はまだまだ増加している途上です。数年も逆上ると、パブリッククラウドに行くシステムも今ほど多くはありませんでしたし、戻るにしてもまだ判断が早すぎるタイミングでした。
必然的に、クラウド移行が進行してある程度期間がたった今だからこそ回帰の数もまた増えているという見方もできるでしょう。それが目立って、オンプレ回帰が過剰に・想像以上に増加しているととらえられている面もあるのではないでしょうか。

ここで言うクラウドとは?

さてここで、回帰の元である、クラウドについて考えてみましょう。

それらの多くは、上に書いたようにパブリッククラウドだったと思われます。要するに、AWS や Google Cloud、Azure などです。他にもたくさんあります。

それとは別に、プライベートクラウドという区分もあります。これはパブリッククラウド同様に他所で間借りをするものもありますが、オンプレ (に区分される設備) に構築する場合も多く、区分的にはオンプレ側 (もしくはそのもの) と考えるべきでしょう。

ところで、最近はクラウドネイティブという言葉も多く用いられるようになりました。これはシステムの置き場所に関係なくクラウドらしい設計・運用をすることを指す言葉であり、インフラを指しての “クラウドからの移行” のような文脈で使われるものとは違います。後でも触れますが、オンプレ回帰するにあたってもクラウドネイティブは共存できるものです。

回帰の理由

多くがパブリッククラウドからの回帰を指しているとして、その理由は何でしょうか。
以下が多いと考えられます。(また、世間で言われているようです)

• 費用
• セキュリティ・ガバナンス
• 性能・品質

これらがクラウドへ移行する以前のほうが優れていた、またはクラウドで思ったような改善・効果が得られなかったから回帰するということでしょう。

ここで出てくる問題は、かなり複雑です。

上記はいずれも、クラウドへの移行を試みる際に試算したりプランニングしたりするものですが、移行元での利用方法とおなじような想定をしていなかったかというのがひとつ、重要な確認ポイントです。

たとえば、費用で言うと。オンプレ設備は減価償却期間を定めて、一定の期間で使用する前提の計算をします。その場合、使う量にかかわらず費用がかかっていますので、毎日 100% 使うような使い方がおトクです。しかしクラウドでこれをおなじように見積もってしまうと、数年間そのリソースを専有で使いっぱなしという想定になり、それではクラウドサービスでは非常に高額になってしまいます。
必要なときに必要なだけ使えるのがクラウドのよさなので、本来はそのように想定をつくって計算する必要があります。(とはいえそれが難しいのですが)

セキュリティについても同様で、元々が安全な場所からスタートしているオンプレとは違った安全確保の設計が必要になります。ゼロトラストのような考え方はそういったところから生まれたものでしょう。

回帰の結果

さて、どういった理由にせよ、オンプレに帰ってきたとします。
その結果は、クラウド移行の失敗、金銭・資源の喪失、時間の無駄だったのでしょうか? それでは悲しすぎます。

クラウド移行により、得られたものに目を向けてみましょう。それは、たとえば次のようなものでしょう。

• アプリケーションの柔軟な構成
• すばやいデプロイ
• 動的スケーリング対応
• ままならないインフラへの耐性と運用知見
• 使用するフレームワーク等のアップデートへの追従

すべてではなくても、クラウド移行のためにこういったことの対応を迫られたのではないでしょうか。そして、これらはパブリッククラウドでしか有効なものというわけではなく、モダンなアプリケーションには必須な機能であり、特徴です。

クラウドでこれらに対応できていれば、オンプレ回帰するときに、これらを持って帰ることができるのです。

クラウドから得られたもの

それでは、持って帰ってきたものを具体的なアイテムにして並べてみてみましょう。

• 柔軟なインフラ管理
  • IaC
  • CI/CD
• DevOps プラクティス
• 動的なインフラで動作するアプリケーション
  • ホストの不意な停止への対応
• 集中した監視・アラート
• より手軽な環境構築手順

こういったものには、先に軽く触れた、クラウドネイティブと言われる領域に重なる部分が多くあります。

もちろん、オンプレ一本でこれらを達成している現場もあります。ただ、オンプレ環境は構成が変わりにくく、もともとインフラとしての品質が高いため、こういったことに対応するコストが相対的に高くついてしまいがちで、そういった理由からあまり力が入れられないことが多い傾向があります。

クラウド移行を経験することで半強制的にこういった対応が必要になり、かつ実証もできる機会が得られるというわけです。オンプレに戻ったときにこれらが引き続き使えることで、それからのシステム運用がずっと心強く感じられるのではないでしょうか。
しかも、クラウド・オンプレ双方でおなじ方法が使えるようにしておくことで、また一時的に・一部でもクラウドにシステムを移したくなったときにも、今度は最初よりずっとかんたんに対応することができるでしょう。

オンプレ以外への回帰

日本語ではオンプレ回帰と言われることが多いようですが、英語では Cloud Repatriation というそうで、ここにオンプレの文字はありません。どちらかというと脱クラウドという意味合いに感じます。

それでは、クラウドからの回帰先がオンプレ以外だった場合には何が考えられるでしょうか。

• プライベートクラウド
• 別のパブリッククラウド

うーん、あまり思いつきません。

しかしどこへ行くにせよ、一度移動をしてしまえば、さらに次の移動はしやすくなるものです。Terraform や Ansible などの IaC ツールを整備しておくことで、必要なことや手順がずっと明確になり、予測もつきやすくなるでしょう。Kubernetes を採用するとインフラの抽象化がさらに進み、オンプレとパブリッククラウドなど複数の環境へおなじシステムをデプロイして同時に運用することも現実的になるでしょう。

ともあれ、オンプレに帰ってきた！

さて、長い旅を経て、心地よい我が家へ帰ってきました。

コンピューター、ネットワーク、ストレージ。オンプレ環境では (やろうと思えば) 実物を確認することもでき、稼働率や通信の品質もあなたのがんばり (とお金) 次第です。極秘データの保管も、物理的な安全確保ができていればずっと安心感があるでしょう。意図しない大量データ通信で思ってもみなかった費用がかかる心配ももうありません。

クラウドでの経験が、きっとこれからのシステム運用の糧となるでしょう。
この先もまだとうぶん、たどり着く場所なんて無くて、ただ先に進むだけなのです。

参考・補足

考えをまとめるにあたり、以下のような情報元や web 検索、Microsoft Copilot との chat での情報収集を参考にしました。 この記事は、収集した情報を含んで総合的に解釈をした著者個人の考察をまとめたものです。

• オンプレミス回帰の動きに備えよ～クラウドの手法をオンプレミスでも実現するには (CNCF2023)
  • CloudNative Days 福岡 にて拝聴しました。とても独特な観点で、今回の記事を書くきっかけになったものかもしれません。
• 常態化する“オンプレ回帰”　2023年の最新動向を追う (ITmedia NEWS)
  • 一年ほど前の記事ですが、回帰に関する考察をしています。また回帰の傾向について、はっきり増加と言えるかは不明確ながら様々な数値が示されています。
• オンプレミス回帰の要因と今後検討すべきハイブリッドクラウド (ニフクラ)
  • オンプレミス回帰の要因として主に考えられるものが解説されています。