企業はクラウドコスト最適化のパラドックスをどのように解決すべきでしょうか?

「クラウドのコスト、1兆ドルのパラドックス」と題された最近の分析が大きな注目を集めています。この記事では、クラウド インフラストラクチャ コストの影響 (そして、それが企業の評価にどのように影響するか) について考えるよう求めることで、クラウド変革に関する従来の考え方とクラウド移行をめぐる熱狂に異を唱えます。

SaaS 企業にとっては、クラウド コンピューティングのコストが市場価値を引き下げるという見方もあります。

このパラドックスは、クラウド コンピューティングは企業の成長の初期段階では安価ですが、企業の規模が大きくなるにつれて高価になることを示唆しています。彼らは簡単にこう言いました。「クラウドから始めないのはおかしいし、クラウドに固執するのも同じようにおかしい。」

逆説的ですが、クラウド インフラストラクチャは小規模なビジネス モデルを可能にしますが、企業がクラウド コンピューティングに深く関与するようになって初めて、それが大きな価値破壊の原因となることが明白になります。

純粋なクラウド モデルからプライベート インフラストラクチャまたはハイブリッド インフラストラクチャにワークロードを戻すこと (リパトリエーション) は、インフラストラクチャ コストを最適化するための主要な戦略として機能します。たとえば、ある非公開の 10 億ドル規模のソフトウェア会社では、パブリック クラウドの支出が会社の売上原価 (COR) の 81% を占めていました。上場ソフトウェア企業上位 50 社では、クラウド コンピューティングの支出総額が 80 億ドルを超えました (クラウド支出を示す手数料を含む)。

クラウド回帰が今ほど普及していないのは不思議です。再本国送金によりクラウド支出を大幅に削減でき、よく引用される数字としては 50% の節約があります。このアプローチを使用してこの点を説明すると、場合によっては、本国送金によって本国送金利益が 40 億ドル節約されることになります。パブリック クラウド インフラストラクチャを使用している大規模なソフトウェア企業の広大な世界を考慮すると、この 40 億ドルの未実現利益はおそらくはるかに大きいことがすぐにわかります。

企業が 1 兆ドルのパラドックスを克服するための役立つアドバイスとしては、クラウド支出を KPI にすること、エンジニアにリソース消費を最適化するよう奨励すること、開始点としてリソース集約型のワークロードのサブセットを選択すること、慣性とロックインによって本国復帰の選択肢が奪われる前に本国復帰について考えることなどが挙げられます。

インフラコストの増加は必ずしも収益の増加に比例するわけではありません。これにより、会社の規模が拡大するにつれて収益性が低下する可能性があります。

さらに調査を進めると、クラウドへの支出は時価総額に 25 倍の影響を及ぼす可能性があることがわかりました。こうすることで、粗利益が 40 億ドル増えると時価総額が 1,000 億ドル増加すると見積もれることがすぐにわかります。

監視サービスプロバイダーであるデータドッグは、最近2021年の推定粗利益の約40倍で取引された上場企業であり、S-1文書でアマゾンウェブサービスへの3年間で総額2億2500万ドルのコミットメントを明らかにした。

コミットされた支出を年間 AWS コスト 7,500 万ドルと計算し、さらにその 50% にあたる 3,750 万ドルがクラウドの回帰によって回収できると仮定します。つまり、支出削減だけで同社の時価総額は約15億ドル増加したことになる。

エンタープライズ ソフトウェア企業や消費者向けインターネット企業にさらに広く拡大すると、クラウド支出全体の 50% が大規模なテクノロジー企業によって消費されると仮定すると、これらの企業はクラウド回帰の恩恵を受けることになります。

効率性が企業の評価に与える影響の例を考えてみましょう。 MongoDBとElasticは、2021年度の年間収益がほぼ同等（それぞれ5億9,000万ドルと6億800万ドル）であると報告した。 MongoDB の時価総額が Elastic のほぼ 2 倍 (それぞれ 234 億ドル対 136 億ドル) なのはなぜですか?理由の 1 つは、Mongo のインフラストラクチャの効率的な使用方法の違いである可能性があります。 Mongo は SaaS 製品にきめ細かいマルチテナントを採用していますが、Elastic はテナントごとに個別のクラスターを採用しています。リソース消費の違いは非常に大きいです。

サービスをインフラストラクチャから分離することで、各ワークロードに対応するために高度に最適化された定義済みのインフラストラクチャ ゾーンを作成できます。

ここで考えられる違いは、SaaS モデルの力です。 「市場ではクラウドの収益はオンプレミスのオープンソースの約3倍と評価されており、その理由は主に純収益の保持によるものだ」と彼は指摘した。オンプレミスのオープンソース インフラストラクチャは、解約率が高くなる傾向があります (通常 18%)。

もう 1 つの例は Atlassian です。同社はサービスを AWS のマルチテナント クラウド モデルに移行し、コストを 3 分の 1 に削減しました。しかし、これは AWS の方が安いからではありません。むしろ、再設計されたマルチテナント モデルによってサービスがより軽量化されるためです。

1. インフラではなくサービスに重点を置く

ここでの仕事は、クラウド支出を最適化することです。したがって、クラウドの最適化については実用的な観点から考える必要があります。最適化は困難であり、成功するには、機能開発の速度と効率性の観点から考えるのをやめる必要があります。代わりに、効率性は、バックログで優先順位を付ける必要があり、他の機能と同様に経営陣の注意を払う必要がある、もう 1 つの重要な機能として捉える必要があります。

2. 問題を自動化すると悪化する

自動化は適切に実行すればコストを大幅に削減できますが、自動化の副作用として、開発者がクラウド リソースを簡単に起動して、必要のないときでも実行し続けることができるようになることがよくあります。これにより、同社のクラウドコストが増加する可能性もあります。

• 自動化には魔法はありません。多くの企業は手動のプロセスを自動化することで利益を増やそうとしています。これは技術的に難しい場合があり、成長への意欲により優先順位付けが難しくなります。
• 最適化されていないクラウド: プライベート市場が成長を促進するため、クラウド実装の効率は桁違いに低くなる可能性があります。

モノリシック アプリケーションを Kubernetes に移行する企業は多く、その段階で効率性の向上を実感しています。しかし、すぐにクラウド インフラストラクチャのコストが急騰し始めました。開発者がインスタンスを起動し始めるのは、必ずしも正しい理由からではなく、単に簡単だからという理由で起動するだけです。

3. 仕事量をコントロールする

自動化に関しては、インフラストラクチャの自動化に重点が置かれすぎて、サービス自体の自動化にはあまり焦点が当てられていないことがよくあります。サービス層にはインフラストラクチャ層よりも最適化の余地があります。

4. ワークロードとインフラストラクチャの選択を切り離す

サービス層で最適化を実現するには、サービスとインフラストラクチャの選択を切り離す必要があります。こうすることで、仕事に適したインフラストラクチャやクラウドをより柔軟に選択できるようになり、また、成長に合わせて将来的に段階的に最適化を行う余地も十分に残されます。

5. Kubernetes、Terraform、Ansibleだけでは不十分

Kubernetes、Terraform、Ansible はすべて優れたツールです。インフラストラクチャ管理を抽象化し、簡素化するのに役立ちます。しかし、それだけでは十分ではありません。

• インフラストラクチャの管理と、そのインフラストラクチャ上のサービスの管理は、異なるものです。これは、継続的な更新などの翌日の運用を考慮する場合に特に当てはまります。
• 分散サービス、複数の Kubernetes クラスター、複数のデータセンター、または複数のクラウドの管理は依然として非常に複雑であり、これらのツールが提供できる支援は限られています。
• 企業がインフラストラクチャを管理するためのテンプレートやスクリプトを大量に持っていて、そのすべてをサービスにマッピングするものが何もない場合、簡単に迷子になってしまいます。
• サービスの制御を取り戻す: IaC と Kubernetes を超えてスタックを上位へ移行します。

これらの問題を克服し、独自のアプリケーションの制御を取り戻すための最大の可能性は、サービスを実行するインフラストラクチャだけでなく、サービスの管理方法についても上位に考えていくことです。

サービスをインフラストラクチャから分離することで、各ワークロード (テスト、本番環境、ML、ネットワークなど) に対応するために高度に最適化された定義済みのインフラストラクチャ ゾーンを作成できます。

これらの最適化領域はクラウドの外部にある必要はありません。同じクラウド内でも、そしてもちろんクラウド間でも、最適化の余地は十分にあります。この場合、クラウドを離れることは、インフラストラクチャの最適化の領域における別のケースになります。これは、Environment as a Service (EaaS) と呼ぶことができます。

次の例は、これらのアイデアが実際の例にどのように当てはまるかを示しています。この場合、本番環境用に最適化されたインフラストラクチャ スタックと開発用に最適化されたインフラストラクチャ スタックの 2 つの異なるインフラストラクチャ スタックで同じワークロードを実行する方法について説明します。この考え方は他の分野にも応用できます。

6. クラウドコストの最適化にはまだ希望がある

成功しているソフトウェア企業にとって、「1兆ドルのパラドックス」は必ずしも価値を破壊する罠になるわけではありません。スタックにさらに重点を置き、サービスを適切なインフラストラクチャの選択に一致させ、最適化された動作を奨励し、反射的ではなく思慮深く自動化し、規模が拡大する前に本国への帰還戦略を開発することで、コストをより適切に管理し、価値を維持できます。

クラウド移行、自動化、コスト最適化のサイクルは継続的なプロセスであり、継続的な反復、失敗の克服と学習、そ​​して最も重要なチームワークが必要です。

企業がこれを達成するのに役立つツールは数多くありますが、結局のところ、適切な規律とパートナーがなければ、ビジネス上の意思決定に逆行する可能性があります。歴史家ユヴァル・ノア・ハラリはこう述べています。「ナイフは野菜を切ったり、おいしい料理を作ったりするのに使えますが、人を殺すのにも使えます。すべては使い方次第です。」

まず、このパラドックスを解決するには期待を再設定する必要があります。私たちは、スタックのさらに上、バリューチェーンのさらに上まで考え始め、インフラストラクチャではなくサービス自体に焦点を当て、サービスがインフラストラクチャに一致するのではなく、サービスがインフラストラクチャに一致する方法を検討する必要があります。