Container as a service: 仕組みとコスト

Container as a service、つまり CaaS とは、プロバイダーが運用するインフラ上でコンテナ化されたアプリケーションを実行することです。 あなたはイメージ、またはイメージになるソースコードを提供します。サービスは、スケジューリング、ネットワーキング、スケーリング、ホスト保守のいずれか、またはその組み合わせを処理します。一方で、アプリケーション本体、その設定、データ要件は引き続きあなたの責任です。

この用語には複数の運用モデルが含まれます。マネージド Kubernetes クラスター、サーバーレス HTTP コンテナ、常時稼働するアプリケーションサービスは、いずれも CaaS の比較対象として挙がりますが、チームに残る作業は大きく異なります。

このガイドは Lizard によるものです。製品に関する記載は 2026年9月9日時点で確認しています。

コンテナをデプロイすると何が起きるか

一般的なデプロイには 4 つの要素があります。イメージをビルドする、レジストリに保存する、インスタンスを起動する、そしてそこへトラフィックをルーティングする、の 4 つです。その後、プロバイダーはインスタンスを監視し、自身のルールに従って再起動やスケーリングを行います。

あなたのイメージは、正しいプロセスを起動し、想定されたインターフェースとポートで待ち受け、アプリケーションが理解できる形式で設定を提供する必要があります。HTTP レスポンスが成功したからといって、そのアプリケーションがデータベースに書き込めるかどうかをプラットフォームが推測することはできません。

worker の場合、ルーティング自体がまったく不要なこともあります。重要になる確認項目は、キューへのアクセス、プロセスの寿命、リトライ、そしてグレースフルシャットダウンです。Web と worker のランタイムは、別々の要件として扱ってください。

CaaS、PaaS、FaaS、IaaS の比較

これらのラベルは重なり合います。PaaS がコンテナをビルドしてくれることもあります。Function サービスがコンテナイメージを受け付けることもあります。イメージをサポートしているという事実だけでは、キューコンシューマーを継続実行できるかどうかは分かりません。完全なアプリケーションワークフローについては、PaaS guide を比較してください。

プロバイダーがあなたのイメージを実行する 3 つの方法

アプリケーションサービス

このモデルは、一般的な Web プロセスや worker を実行したいときに使います。Lizard はその選択肢の 1 つで、Railway や Render も他の選択肢です。すべての実装が同一だと決めつけるのではなく、ライフサイクル、デプロイ制御、データサービスを比較してください。

Lizard では、ソースからデプロイすることも、Dockerfile を提供することもできます。適した方法を選ぶには、deployment documentation を使ってください。HTTP ではないサービスを設定する場合は、worker guide を参照してください。

リクエスト駆動型コンテナ

このモデルでは、受信した処理に応じてインスタンスを起動またはスケールします。トラフィックに波がある API に向いていることがあります。並行性、リクエストタイムアウト、アイドル設定に加えて、プロバイダーが CPU だけでなくメモリをどのように課金するかも確認してください。

Cloud Run では サービス、Jobs、worker pools が分かれています。プロセスに合ったリソース種別を選んでください。終了するバッチプログラムと、リクエストを受け取る Web サーバーでは、同じデプロイ前提を使うべきではありません。

マネージドスケジューラまたはクラスター

ECS やマネージド Kubernetes は、複数のワークロードをどう動かすかについて、より多くの制御を提供します。その一方で、ネットワーキング、権限、デプロイポリシー、可観測性は依然として自分で設計する必要がある場合があります。

AWS では、Fargate によって、対応する ECS または EKS ワークロード向けのワーカーマシン管理が不要になります。ただし、周辺の AWS リソースを理解する必要まではなくなりません。避けたい問題がクラスター運用そのものであるなら、Kubernetes 代替案ガイド を読んでください。

コンテナホスティングでも自分に残るもの

データ: どのデータをデータベース、オブジェクトストレージ、またはアタッチされたボリュームに置くべきかを決めてください。書き込み可能なファイルシステムがあることは、インスタンスが置き換わってもファイルが残る証拠にはなりません。依存している永続性の挙動を正確にテストしてください。

シークレット: 各サービスには、そのサービスに必要な値だけを渡してください。アプリケーションがその値を確実に読み取り、値が 1 つ欠けているときに明確に失敗することを確認してください。

リリースの安全性: 新しいイメージでスキーママイグレーションが必要になる場合があります。ロールバックも含めて、アプリケーション変更とデータベース変更の順序と互換性を計画してください。

復旧: 再起動でプロセスは回復できることがあります。しかし、失われたデータベースを再構築したり、不正なマイグレーションを修復したりはできません。バックアップと復元は別々にテストしてください。

容量: リソース制限は、1 つのサービスが利用可能なすべてを消費することを防ぎますが、スループットを保証するものではありません。代表的な負荷の下で、レイテンシ、エラー、キュー深度を測定してください。

CaaS のコストを見積もる方法

課金対象となるすべての要素を列挙してください。ランタイム CPU とメモリ、イメージストレージ、ビルド、永続ストレージ、インターネット転送、ロードバランシング、ログ、データベースです。プラン料金やコントロールプレーン料金が適用される場合は、それも含めてください。

次に、何がメーターになるかを特定します。ある製品は、インスタンスの実行時間に対して割り当て済み容量を課金します。別の製品は、消費量や実際にリクエストを処理していた時間を測定します。公開されている CPU の時間単価は、何によって課金対象の 1 時間が発生するのかを知らない限り、比較できません。

たとえば、10 個のコンテナを 1 時間同時に実行すると、10 container-hours が発生します。1 時間の実行を 10 回順番に行った場合も、ランタイム合計は同じですが、必要な並行性制限は異なります。アプリケーションが受けるキュー遅延も異なる可能性があります。コスト見積もりには、ランタイムとピーク並行性の両方を明記すべきです。

該当するメーターについては、AWS Fargate の料金、Cloud Run の料金、Railway billing、Lizard pricing を使ってください。あるプロバイダーのメモリや転送量の無料枠を、別のプロバイダーの計算に流用しないでください。

短い評価プラン

実際の起動コマンドで、代表的なサービスをデプロイしてください。ヘルスエンドポイント、データベース接続、意味のある 1 つのユーザーフローを確認します。再起動し、一時ファイルと永続ファイルがどう振る舞うかを確認してください。リソース使用量とレイテンシを観測できるだけのトラフィックを流してください。

アプリに worker がある場合は、それについても同じ確認を繰り返します。その後、観測したメーターと、チームが利用できるプランに基づいて請求額を計算してください。ライフサイクル要件と復旧要件を満たし、かつ自分たちが理解できる運用プロセスで回せるモデルを選んでください。

FAQ

CaaS に Kubernetes は必須ですか？ いいえ。Kubernetes はコンテナをスケジュールする 1 つの方法です。アプリケーションプラットフォームや、ECS や Cloud Run のようなサービスでも、別のインターフェースを通じてコンテナを実行できます。

CaaS は Docker hosting と同じですか？ これらの用語はしばしば重なります。ラベルよりも、ランタイム契約を読んでください。イメージサポート、プロセス寿命、ネットワーキング、永続ストレージ、運用責任のほうが重要です。

コンテナはアップロードされたファイルを保持できますか？ 必要な耐久性をストレージ構成が提供している場合に限ります。データベース、オブジェクトストレージ、または適切なアタッチドボリュームを使い、再デプロイをまたいだ挙動を確認してください。

Dockerfile を書かずにデプロイできますか？ プロバイダーによっては、ソースからイメージをビルドできます。Lizard は lizardpack を通じてその方法をサポートしています。現在のドキュメントで、サポートされている言語とプロジェクトレイアウトを確認してください。