The optimal solution between serverless cold start and cost

もしかすると、皆さんも同じような技術選定を経験されたことがあるのではないでしょうか。

小王さんはプログラマーで、同社のアプリケーションは自社サーバー室のサーバーで稼働しています。基盤サービスの構築や運用保守はすべて自社で行う必要があり、アップグレードやサーバー増設のたびに大きな運用負荷がかかります。同時に、タイムリーなスケールアップに対応するため、多くのアイドル状態のサーバーを保有せざるを得ず、サーバーコストも嵩んでいます。最近、同社では 2 つの新しいアプリケーションシステムを開発しました。小王さんは技術選定を進めており、クラウドコンピューティングを取り入れて新しいアプリケーションをクラウドにデプロイし、高い弾力性、低コスト、シンプルな運用保守を実現するアーキテクチャソリューションを設計する計画です。これにより、ビジネストラフィックの急増にも柔軟に対応でき、ビジネス開発により多くのエネルギーを注ぎながら、運用保守の負担を軽減できます。

これら 2 つのアプリケーションにはいくつかの共通点があります。

• 両アプリケーションともオンラインアプリケーションであり、呼び出しレイテンシとサービスの安定性に対する要件が比較的高い

• アプリケーショントラフィックはビジネス状況によって大きく変動し、ビジネスボリュームの増加を事前に予測するのが難しく、高い柔軟性が求められる

• ビジネスに明確なローピーク期間があり、ローピーク時のトラフィックは比較的少ない。ローピークは主に夜間帯と想定されている

• アプリケーションの起動時間が長い。Java SpringBoot の受注システムと、大規模画像を扱う AI 画像認識システムの 2 つがあり、起動時間は約 1 分かかります

小王さんのニーズは 3 つの側面にまとめられます。

• 1 つ目は、運用保守の時間と手間を省きたいこと。jar パッケージやイメージを納品した後、簡単な設定だけでアプリケーションを実行でき、運用保守やモニタリング、アラート機能に特別な労力を割きたくない

• 2 つ目は、優れた柔軟性。ビジネストラフィックが増加すると自動的かつタイムリーにスケールアップし、トラフィックが減少すると自動的にスケールダウンできること

• 3 つ目は、クラウドコンピューティングの活用によりリソース使用率を向上させ、コスト面での優位性を得ること

これらの要件を踏まえ、小王さんがどのように技術選定を段階的に進めていくかを見ていきましょう。

高統合サービスで、運用保守フリー、高い弾力性

技術選定にあたり、小王さんは SLB とクラウドサーバーに弾性スケーリングを組み合わせた従来のアーキテクチャ、K8s アーキテクチャ、そして Function Compute（FC）アーキテクチャという 3 つの技術アーキテクチャを検討しました。

従来のアーキテクチャでは、SLB の負荷分散を自社で構築し、弾性スケーリングサービスを設定して適切なスケーリングポリシーを見つけるために継続的なデバッグが必要です。また、ログ収集や大容量ディスクの監視のためのアラート機能も自前で構築する必要があります。この一連のシステムの運用保守とデプロイのコストは、実際にはそれほど低くありません。もっと便利な方法はないでしょうか。

小王さんはさらに K8s アーキテクチャを調査しました。K8s の Service と Ingress ルールを使えばアプリケーション層へのアクセスを管理でき、SLB の負荷分散を自社で構築する必要がなくなります。同時に、HPA を使ってアプリケーションの負荷に応じた水平スケーリングが可能です。一見良いアイデアに見えますが、実際のテストでは HPA のスケーリングが分単位で行われることが判明しました。スケーリングが少し遅れる程度は問題ありませんが、トラフィックが急速に増加する場面では、スケーリングが常に数分遅れ、リクエストの増加や失敗を招き、サービス可用性に影響を与える可能性があります。スケールアウトの指標しきい値を下げればこの問題を解決できますが、同時にリソース使用率が低下し、コストが大幅に増加します。さらに、ログ収集、アラート、全体的なモニタリングも自社で行う必要があり、運用保守のコストもかかります。加えて、小王はこれまで K8s に触れたことがなく、K8s の多様な概念を理解するには大きな学習コストがかかります。

FC ベースのアーキテクチャは、上記の課題を十分に解決できます。まず、FC は予約モードとインスタンス指標に基づく自動スケーリングをサポートしています。このモードにより、より敏感で迅速なスケーリングを実現でき、スケーリング中もリクエストレイテンシを安定した状態に保てます。次に、FC は HTTP トリガーなど、多くのすぐに使える機能と高度に統合されており、ゲートウェイや SLB との連携作業が不要になります。コンソールには完全な可観測機能が備わっており、リクエスト状況、インスタンスステータス、操作ログを簡単に確認できます。最後に、FC は呼び出し中に使用したアクティブなリソースに対してのみ課金され、呼び出しがない場合は料金が発生しないため、リソース使用率を最大限に向上させてコストを削減できます。

以下では、予約モードの使い方と、アイドル課金による予約のコスト削減方法について詳しく紹介します。

予約モード、コールドスタートの完璧なソリューション

FC にはオンデマンドモードと予約モードの 2 つの使い方があります。オンデマンドモードは、リクエストが自動的にインスタンスの作成と拡張をトリガーし、呼び出し量の増加時にインスタンスを作成し、リクエストの減少後にインスタンスを破棄します。「オンデマンドモードはリソース使用率を最大限に向上させますが、小王さんのアプリケーションのように起動時間が比較的長い場合、オンデマンドモードでのインスタンス作成時に顕著なコールドスタート現象が発生します」。このコールドスタートの課題に対処するため、FC は予約利用モードを提供しています。ユーザーが予約を設定すると、FC は指定された数の予約インスタンスを作成してシステムに常駐させ、ユーザーが予約設定を更新してリリースするまで維持します。リクエストがある場合は予約インスタンスが優先的にスケジュールされます。予約インスタンスが上限に達すると、新しいリクエストがオンデマンドインスタンスの作成をトリガーします。同時に、予約インスタンスの台数をビジネス曲線に合わせて最適化できるよう、予約タイミングスケーリングや指標に基づくスケーリング機能も提供され、予約インスタンスの使用率を向上させます。詳細はこちらをご参照ください。

このアプローチにより、アプリケーションのコールドスタート時間が長いという課題が解決されるだけでなく、予約インスタンスが比較的高い使用率を維持できます。時折大きなトラフィック変動が発生した場合でも、オンデマンドインスタンスを一時的にスケールアウトしてリクエストに対応でき、トラフィック急増時にもサービス品質を確保できます。

アイドル課金、コスト削減の切り札

実際の使用シーンでは、アプリケーションリクエストの低レイテンシを保証するため、リクエストがない時でもある程度の予約インスタンスを維持する必要があり、コストの増加につながっています。低レイテンシと低コストを両立する方法はないでしょうか。Function Compute は、このシナリオでの使用コストを削減するため、予約インスタンス向けのアイドル課金機能を導入しました。この機能について詳しく見ていきましょう。

アイドル課金

予約インスタンスがリクエストを処理しているかどうかに基づき、インスタンスをアイドル状態とアクティブ状態に区別し、各状態に対して課金単価を設定します。アクティブな課金単価は元のリソース使用単価と同じです。アイドル課金単価はアクティブ課金単価の 20% です。アイドル課金を有効にすると、大幅なコスト削減が可能です。

デフォルトでは、アイドル課金機能はオフになっています。このとき、予約モードのインスタンスがリクエストを処理しているかどうかにかかわらず、FC はそのインスタンスに CPU を割り当て、常にアクティブな状態を維持します。これにより、リクエストがない時でもバックグラウンドタスクが正常に実行されます。アイドル課金機能を有効にすると、予約モードのインスタンスにリクエストがない時、FC はそのインスタンスの CPU をフリーズし、インスタンスをアイドル状態に移行させます。

アイドル課金を導入することで、予約インスタンスも実際に使用された CPU リソースに対してのみ課金されます。予約インスタンスがアイドル状態の時は、20% の料金だけでコールドスタートの課題に対応できます。これにより、ユーザーは予約インスタンスの使用コストを大幅に削減できます。同時に、予約インスタンスの使用率をあまり気にせず、安心して予約インスタンスを活用できます。

例として、予約インスタンスの使用率が 60% で、元の使用コストが 1 だとします。アイドル課金を使用すると、コストは 60% * 1 + 40% * 20% * 1 = 0.68 となり、32% のコスト削減につながります。

設定方法

予約インスタンスとアイドル課金は、コンソールと SDK から設定できます。

Function Compute コンソールにログインし、ホームページから [ルールの作成] > [弾性管理] ページを選択して、アイドル課金を設定します。同時に、SDK を使った設定も可能で、Java、Go、Node.js など複数の言語に対応しています。詳細は API オンラインデバッグをご参照ください。

アイドル課金を有効にした後、アイドルリソースの使用料は、費用センター > [請求明細] > [詳細請求] で確認できます（請求データは通常 3 〜 6 時間遅れて出力されます）。

おわりに

Function Compute（FC）は、ユーザーに高弾力性、運用保守フリー、低コストのフルマネージド型コンピューティングサービスを提供することに取り組んでいます。アイドル課金機能のリリースにより、ユーザーは実際に使用する予約リソースに対してのみ支払うことで、予約インスタンスの使用コストをさらに削減できます。Function Compute は、今後もサーバーレスの技術的メリットを段階的に解放し、ユーザーにさらなるパフォーマンス、コスト効率、そして体験の向上を提供していきます。