パブリック クラウドの弾力性を活用するのが難しいのはなぜですか?

AutoMQ 共同創設者兼 CEO、王暁瑞氏

クラウド コンピューティングは、リソース プーリングを通じて単位リソース コストの削減を実現し、企業が IDC 構築、基本ソフトウェア開発、運用と保守をクラウド ベンダーにアウトソーシングできるようにすることで、ビジネス イノベーションにさらに注力できるようにします。リソース プールには、サーバーだけでなく人材も含まれます。クラウドベンダーは優秀なエンジニアを集め、専門的な事項を最も専門的な人々に任せ、クラウドサービスを通じて多くの企業に専門的なサービスを提供しています。

クラウド コンピューティングは長年にわたって開発が進められており、弾力性はクラウド コンピューティングの実践者が最も注目する技術的機能の 1 つです。しかし、具体的なケースになると、弾力性をうまく活用できる顧客はほとんどいません。代わりに、弾力性がスローガンとなり、理想的なアーキテクチャになりました。この記事では、なぜ現実と理想の間にこれほど大きなギャップがあるのか​​、そして、低投資で高収益をもたらす柔軟な解決策は何かを説明します。

クラウドベンダーは、年間および月間パッケージの割引を提供することで顧客を維持していますが、これは弾力性のシナリオに反しています。

次の表は、一般的な EC2 料金パッケージと従量課金制料金の比較であり、ゲームのルールをまとめたものです。

• 年間および月間パッケージは従量制パッケージに比べてコストを約50%節約します このため、ほとんどの企業は EC2 リソースを年間または月単位で使用することを選択します。クラウド ベンダーの観点から見ると、この設計は非常に合理的です。クラウド ベンダーは、ネットワーク全体の顧客の使用状況を予測して、リージョンにどれだけのアイドル水位を予約するかを決定するためです。オンデマンドインスタンスとリザーブドインスタンスの価格が同じであると仮定すると、クラウドベンダーがリージョンの水位を予測することは困難になり、昼と夜で大きな差が生じる可能性があり、サプライチェーンの調達決定に直接影響を及ぼします。クラウドベンダーは典型的な小売業のようなビジネスモデルを持っています。各リージョンのアイドル状態のマシンの数は在庫に似ています。在庫比率が高くなるほど、利益率は低くなります。
• スポットインスタンスは安価で、時間単位で支払います また、アプリケーションがスポット インスタンスの強制リサイクルの影響を処理できることも必要です。ステートレス アプリケーションの場合、これは比較的簡単です。スポットインスタンスはリサイクル前にアプリケーションに通知します。ほとんどのクラウドベンダーは、数分間のリサイクルウィンドウを提供します。アプリケーションが正常にオフラインになる限り、ビジネスに影響はありません。スポットインスタンス[1]をベースにコンピューティングリソースの管理を専門とする海外のスタートアップ企業は、ユーザーがスポットインスタンスを有効活用できるようにするための機能を多数製品化している。 AutoMQはスポットインスタンスの使用においても豊富な経験を積んでいます[2]。しかし、ステートフルアプリケーションの場合、スポットインスタンスを使用するためのしきい値が非常に高くなり、インスタンスが強制的にリサイクルされる前に状態を転送する必要があります。たとえば、Kafka、Redis、MySQL などのアプリケーション。通常、ユーザーがこのタイプのデータベースの基本ソフトウェアを Spot インスタンスに直接デプロイすることは推奨されません。

このゲームルールには、合理的な側面と最適化する価値のある側面の両方があります。少なくとも以下の点では改善できると思います。

• スポット リサイクル メカニズムは、より多くのユーザーがスポット インスタンスを使用するように促すために SLA を提供する必要があります。したがって、スポットリサイクルメカニズムのメッセージ通知は、一部の主要企業がスポットインスタンスを大規模に使用できるように、一定の SLA を提供できる必要があります。
• 新しいインスタンス API を作成し、SLA を提供します。スポットが回収された後、アプリケーションのフォールバック ソリューションは、新しいリソース (新しいスポット インスタンスや新しいオンデマンド インスタンスなど) を開き続けることです。現時点では、新しいインスタンスを開くための API にも一定の SLA が必要であり、これはアプリケーションの可用性に直接影響します。
• SLA を提供するためにクラウド ディスクからEBS を切り離す場合も、明確な SLA が必要です。これは、スポット インスタンスが強制的にリサイクルされると、ユーザーがアプリケーション ステータスのアンインストールを自動的に処理できるようにする必要があるためです。

AWS 米国東部 m6g.large

プログラマーがリソースのリサイクルをうまく行うのは難しい

C/C++ プログラマーはメモリとの戦いに多大な労力を費やしていますが、それでもメモリ リソースが漏洩しないという保証はありません。その理由は、正確な資源リサイクルが非常に困難な作業だからです。たとえば、関数がポインターを返す場合、このオブジェクトをリサイクルする責任は誰にあるのでしょうか? C/C++ ではこの点に関して合意が得られていません。マルチスレッドが関係する場合は、さらに悪夢になります。この目的のために、C++ はスレッドセーフな参照カウントを通じてオブジェクトを管理するスマート ポインターを発明しました。 Java は組み込みの GC メカニズムを使用して実行時にオブジェクトのリサイクルを検出します。これにより、オブジェクトのリサイクルの問題は完全に解決されますが、実行時に一定のオーバーヘッドも発生します。最近非常に人気が高まっている Rust 言語は、本質的には C++ に似たスマートなポインターリサイクル方式です。メモリリサイクルチェックメカニズムをコンパイル段階に革新的に統合することで、メモリリサイクルの効率が大幅に向上し、C/C++ プログラマーが一般的に遭遇するメモリの問題を回避します。著者は、Rust が C/C++ の完璧な代替品になると信じています。

クラウド オペレーティング システムの分野に戻ると、プログラマーは API を通じて ECS、Kafka インスタンス、S3 オブジェクトを作成できます。この API は請求書に変更をもたらします。作成するのは簡単ですが、リサイクルするのは非常に困難です。最大仕様は通常、Kafka インスタンスを作成するときに指定されます。たとえば、Kafka インスタンスを作成する場合、最初に 20 台のマシンが使用されます。将来的に容量を拡大したり縮小したりすることが困難になるため、一度にすべて行う方がよいでしょう。

クラウド コンピューティングは弾力性を提供しますが、プログラマーがオンデマンドでリソースを効果的に管理することが難しく、リソースのリサイクルが困難になります。これにより、企業は従来の IDC のリソース管理方法と同様に、クラウド リソースを作成するときに面倒な承認プロセスを設定する必要があります。最終的には、プログラマーがクラウド上のリソースを使用する方法は IDC と似たものになり、CMDB を通じてリソースを管理し、リソースの無駄を避けるために手動の承認プロセスに依存する必要があります。

また、回復力を発揮する優れた例もいくつか見ました。たとえば、大企業が EC2 を使用する場合、各 EC2 インスタンス ID のライフサイクルは 1 か月を超えません。この期間を超えると、「祖父の EC2」としてリストされ、チームのブラックリストに追加されます。これは、エンジニアがサーバー上の構成やデータなどの状態を保持することを効果的に防止できる優れた不変インフラストラクチャのプラクティスであり、アプリケーションを回復力のあるアーキテクチャに移行できるようにします。

クラウド コンピューティングの現在の段階はまだ C/C++ 段階にあり、優れたリソース回復ソリューションはまだ存在しないため、企業は依然としてプロセス承認メカニズムを広範に使用しており、実質的にクラウドの最大の利点である弾力性を活用できていません。これは、企業のクラウド支出が高額になる主な理由の 1 つでもあります。

問題がある限り、より良い解決策があると信じています。クラウド リソースのリサイクルに対する Java/Rust のようなソリューションは、近い将来に確実に利用可能になるでしょう。

基本ソフトウェアからアプリケーション層まで、回復力の準備ができていない

2018年に、私は何千ものTaobaoとTmallアプリケーション向けの柔軟なソリューションの設計を始めました[3]。当時、Taobao と Tmall アプリケーションはすでにオフラインとオンラインの共同展開を実現し、展開密度を向上させていましたが、オンライン アプリケーションはまだ予約モードであり、オンデマンドの弾力性を実現できませんでした。根本的な問題は、スケーリング時にアプリケーションが予期しない動作を起こす可能性があることです。 Kubernetes 上で実行したとしても、この問題は完全に解決できません。例えば、アプリケーションはさまざまなミドルウェア SDK (データベース、キャッシュ、MQ、ビジネス キャッシュなど) を呼び出すため、アプリケーション自体の起動に時間がかかります。一見ステートレスなアプリケーションには、実際には単位ラベル、グレースケール ラベルなどのさまざまな状態が含まれており、アプリケーション全体を効果的にスケーリングするには、多くの手動操作と監視が必要になります。

Javaアプリケーションのコールドスタート時間を数分から数ミリ秒に短縮するために、当時Docker向けにスナップショット機能が開発されました[3]。この機能の実稼働アプリケーションはAWSより4年先行していました（AWSは2022年のRe:inventカンファレンスでLambda SnapStart[4][5]機能をリリースしました）。スナップショット方式でアプリケーションを起動することで、数百ミリ秒で即時稼働可能なコンピューティングノードを追加できます。この機能により、アプリケーションは Lambda 関数に変換することなく、Lambda などのトラフィックに基づいてコンピューティング リソースを増減できます。これは、Lambda が提供する従量課金機能です。

アプリケーション層で弾力性を実装することはすでに非常に複雑ですが、データベース、キャッシュ、MQ、ビッグデータ、その他の製品などの基本ソフトウェア レベルで弾力性を実装することはさらに困難です。分散型の高可用性と高信頼性の要件により、これらの製品ではデータの複数のコピーを保存する必要があります。データ量が大きくなると、弾力性が非常に難しくなり、データの移行がビジネスの可用性に影響を及ぼします。クラウド環境でこの問題を解決するには、クラウド ネイティブ アプローチを使用する必要があります。 AutoMQ (Kafka を有効にするクラウドネイティブ ソリューション) を設計する際は、弾力性を優先します。主な課題は、独自のストレージ システムを構築するのではなく、従量課金制のサービスである S3 などのクラウド サービスにストレージをオフロードすることです。次の図は、AutoMQ ライン上のトラフィックとノードの変更を示しています。 AutoMQ がトラフィックに基づいてマシンを自動的に増減していることがわかります。これらのマシンがスポットインスタンスを使用すると、企業のコストが大幅に削減され、実際に従量課金制が実現します。

AutoMQはトラフィックに基づいてノードを自動的に増減します

企業は柔軟性を活用してコストを削減し、効率を高めるにはどうすればよいのでしょうか?

2018年にGoogleは、完全に管理されたコンピューティングプラットフォームであるCloud Run[6]を立ち上げました。 HTTP 通信に基づくアプリケーションは、Cloud Run にリスニング ポートとコンテナ イメージを提供するだけで、インフラストラクチャの管理はすべて Cloud Run によって自動的に実行されます。 AWS Lambda と比較したこの方法の最大の利点は、単一のクラウドベンダーに縛られる必要がなく、将来的に他のコンピューティング プラットフォームに移行しやすいことです。 AWSとAzureもすぐにこれに追随し、Azure Container Apps[7]とAWS App Runner[8]という同様の製品を発売しました。

専門的なことは専門家に任せましょう。弾力性は非常に難しい課題です。アプリケーションによって消費されるコンピューティング リソースをリクエストに応じて支払うことができるように、クラウド アプリケーションでは、Cloud Run などのコードレス バインディング ホスティング フレームワークを可能な限り利用することをお勧めします。

データベース、キャッシュ、ビッグデータ、MQ などの基本ソフトウェアの問題を、統一されたホスティング フレームワークで解決することは困難です。このタイプのアプリケーションの進化の傾向は、Amazon Aurora ServerlessやMongodb Serverless[9]などのように、各カテゴリが弾力性のあるアーキテクチャに向かって進化していることです。クラウド ベンダーからサードパーティのオープン ソース ソフトウェア ベンダーまで、完全に柔軟なアーキテクチャを実現する必要があるという点でコンセンサスが得られています。

企業が同様のオープンソース基本ソフトウェアを選択する場合、弾力性のある製品を選択するように努めるべきです。判断基準は、スポットインスタンスで実行できるかどうか、そしてコスト効率が非常に優れているかどうかです。同時に、そのような製品が複数のクラウド上でより適切に実行できるかどうかにも注意を払う必要があります。これは、将来マルチクラウド アーキテクチャ、さらにはハイブリッド クラウド アーキテクチャに移行する際に、企業が移植可能かどうかを決定します。