【ITニュース解説】What is scale-to-zero and how does it change cloud cost?

クラウドコンピューティングは、システム開発において非常に重要な役割を担っている。仮想サーバーなどのコンピューティングリソースを必要な時に必要なだけ利用できる便利な仕組みだが、その課金モデルを理解していなければ、予期せぬコスト発生につながることもある。ここで解説する「スケール・トゥ・ゼロ」という考え方は、このクラウドコストの課題を解決し、特にシステムエンジニアを目指す初心者にとって、これからのクラウド利用の常識になる可能性を秘めているため、ぜひ押さえておきたい概念だ。

従来のクラウドの課金モデルでは、仮想マシン（VM）と呼ばれる仮想サーバーを一度起動すると、そのVMが存在し続けている間は、たとえ何の処理も行っていなくても課金が発生するのが一般的だった。これは、物理的なサーバーをレンタルしている状態に似ており、サーバーが稼働している間は常に電気代や管理費用がかかるのと同じ考え方だ。例えば、ある仮想マシンを1ヶ月間（約730時間）起動しっぱなしにすると、それが1 vCPUと1GBのメモリを持つマシンだった場合、月額で約29ドル、2 vCPUと2GBのメモリだと約58ドル、4 vCPUと8GBのメモリだと約141ドルといったコストが、実際にそのマシンが何かの処理をしたかどうかに関わらず発生する。これは、マシンが存在するだけでかかる「存在コスト」と言える。

実際の例を挙げると、ある顧客の16日間のクラウド利用データを見ると、全体の費用のうち約84%が、ほとんど利用されていない仮想CPUの時間に起因していたという。この仮想マシンは期間中ずっと稼働し続けていたが、実際の処理量は平均で1 vCPUにも満たないほど少なかったにもかかわらず、稼働している時間はすべて「仕事をしている」とみなされ、課金されてしまっていたのだ。データベースに数メガバイトのデータしかなく、オブジェクトストレージも1ギガバイト未満だったにもかかわらず、計算リソースの費用がその他のストレージ費用の5倍以上にも膨らんでおり、その大半はアイドル時間だった。これは特定のクラウドサービスに限った話ではなく、過去20年間で「とりあえず起動して、そのままにしておく」というクラウド利用の習慣が定着した結果、多くの企業で発生している問題だ。

これに対して「スケール・トゥ・ゼロ」は、この従来の課金モデルを根本から覆すものだ。このモデルでは、あなたのプログラムやサービスが実際にリクエストを処理している「アクティブな時間」に対してのみ課金が発生する。トラフィックが途絶え、サービスがアイドル状態になると、プラットフォームは自動的にインスタンス（仮想サーバーやコンテナなど、処理を実行する単位）を一時停止させ、その間は計算リソースに対する課金がゼロになる。そして、次にリクエストが来た時に、インスタンスは自動的に起動し、リクエストを処理する。処理が完了し、設定されたアイドルタイムアウトが過ぎると、再び一時停止状態に戻るのだ。これにより、アイドル時間は一切コストを発生させず、アクティブな時間だけが実際に処理された作業量に応じて正確に課金されるようになる。

Scalixというクラウドサービスでは、このスケール・トゥ・ゼロのモデルをいくつかのサービスで提供している。例えば、「Functions」と呼ばれるサービスでは、関数が呼び出されるたびに課金され、呼び出しがない間は自動的にスケール・トゥ・ゼロとなる。何も実行されていなければ、何も課金されないというわけだ。「Run services」というサービスでは、トラフィックに応じてインスタンス数が自動的に増減するが、最小インスタンス数をゼロに設定することで、アイドル時にインスタンスが一時停止し、リクエストが来た時に起動するようにできる。また、「ScalixNova shared Postgres」という共有データベースサービスでも、使用されていない間は自動的に停止し、ストレージの料金と、クエリ処理に必要なごくわずかな計算バーストに対してのみ課金される仕組みになっている。

ただし、スケール・トゥ・ゼロには一つのトレードオフが存在する。それは、アイドル状態から初めてリクエストが来た際の「起動待ち時間（Wake latency）」だ。インスタンスが一時停止状態から起動してリクエストを処理できるようになるまでには、わずかながら時間がかかる。Scalixのベンチマークでは、一時停止状態のサービスがTCPリクエストを処理できるようになるまでの中央値は約200ミリ秒、TLS経由で完全な最初のリクエストを処理できるようになるまでの中央値は約600ミリ秒だったという。APIや管理画面、社内ツールなどでは、この程度の遅延はほとんど気にならないことが多い。しかし、例えば非常にリアルタイム性が求められるシステムや、10ミリ秒以下の応答速度が求められるようなケースでは、この起動待ち時間が問題となる可能性がある。そのような場合は、常にインスタンスを稼働させておく「常に稼働」モデルを選ぶか、最小インスタンス数をゼロよりも高く設定して、常にいくつかのインスタンスが稼働している状態を保つ必要があるだろう。

では、どのような場合に「常に稼働」モデルを選択すべきなのだろうか。まず、システムへのトラフィックが一日中安定しており、アイドル時間がほとんどないような場合だ。このような状況では、スケール・トゥ・ゼロによるコスト削減効果は小さく、むしろ起動待ち時間の発生がデメリットとなる可能性がある。次に、WebSocketのような永続的な接続を使用するアプリケーションや、長時間のデータベースセッションを維持する必要があるワークロードも、「常に稼働」モデルに適している。これらの接続は、インスタンスが一時停止すると切断されてしまうため、スケール・トゥ・ゼロとは相性が悪い。最後に、システムの状態を維持する必要がある（ステートフルな）ワークロードや、数百ミリ秒の起動時間でさえサービスレベル目標（SLO）を達成できないほどレイテンシに敏感なシステムも、「常に稼働」モデルを選択するべきだ。

自分のクラウド利用状況がスケール・トゥ・ゼロに適しているかどうかを判断する簡単な方法として、実際に課金された計算時間と、システムが処理したリクエストの量を比較してみると良い。もしリクエストがないにもかかわらず課金されている時間が多いのであれば、その部分はスケール・トゥ・ゼロによってコストを削減できる可能性がある部分だと言える。

Scalixのサービスでは、先ほど挙げたFunctions、Run services、ScalixNova Postgresがスケール・トゥ・ゼロをサポートしている。もしスケール・トゥ・ゼロの動作を体験してみたい場合は、Scalixのドキュメントに沿って関数をデプロイするか、最小インスタンス数をゼロに設定したRun serviceを始めてみることをお勧めする。これらのサービスは無料枠が提供されているため、費用の心配なく実験を始めることができる。利用量が増えれば、必要に応じて有料プランに移行することも可能だ。スケール・トゥ・ゼロは、これからのクラウドコスト最適化において非常に重要な技術であり、システムエンジニアを目指す上で理解しておくべき必須の概念と言えるだろう。