コンテナとサーバーレスはどう使い分けるか

コンテナとサーバーレスは、どちらが優れているかではなく、動かす処理の性質と、運用する体制に合わせて使い分けます。短い処理やイベントに反応する処理は関数型のサーバーレス、長く動くアプリケーションや、いまのアプリケーションをそのまま動かしたい場合はコンテナ、と考えると出発点を決めやすくなります。

コンテナは、アプリケーションと動かすのに要るものを一つにまとめて、どこでも同じように動かす仕組みです。サーバーレスは、サーバーの用意や台数の調整をクラウドの事業者に任せ、処理を書くことに集中する使い方です。最近は、両者の間にある「サーバーの管理が要らないコンテナの実行の仕組み」も広く使われており、選択肢は3つに分けて考えると整理しやすくなります。

3つの選択肢

どの選択肢でも、アプリケーションの中身、データの扱い、アクセスの権限の設定は利用者の責任です。誰が何を守るかの考え方は、責任共有モデルをご覧ください。

関数型のサーバーレスの特徴と上限

関数型のサーバーレスは、処理を関数として登録し、呼び出されたときだけ動かす仕組みです。動いていない間の計算の料金がかからず、呼び出しが増えればクラウドの側で並べて動かします。

その代わり、処理の時間や大きさに上限があります。AWS Lambda では、2026年11月時点で、1回の処理の時間の上限は900秒（15分）、メモリは128MBから10,240MBまで、同期の呼び出しで受け渡せるデータは要求・応答ともそれぞれ6MBまで、とされています。

出典：Lambda quotas（AWS）

この上限から、何時間もかかる集計や、大きなファイルを一度に扱う処理は、関数型のサーバーレスに収まらないことがあります。上限に合わせて処理を細かく分けるか、別の選択肢を使います。

Microsoft は、Azure Functions を、イベントで動くアプリケーションを関数の書き方で作る場合に向く選択肢と説明しています。

出典：Comparing container apps with other Azure container options（Microsoft Learn）

サーバーの管理が要らないコンテナ

いまのアプリケーションをコンテナにして動かしたい場合や、処理の時間の上限に縛られたくない場合は、サーバーの管理が要らないコンテナの実行の仕組みが候補になります。

AWS Fargate は、Amazon ECS と組み合わせて、サーバーや EC2 の集まりを管理せずにコンテナを動かす仕組みです。仮想マシンの集まりの用意・設定・台数の調整が要らず、サーバーの種類を選ぶ必要もない、と AWS は説明しています。Fargate で新しく起動する処理は、常にプラットフォームの最新の版の上で動きます。

出典：Architect for AWS Fargate for Amazon ECS（AWS）

Google Cloud の Cloud Run は、コードや関数やコンテナを動かす管理型のアプリケーションの基盤です。要求がなくなると、最後の1台まで止めて計算の料金をゼロにでき、その代わり、止まっていた後の最初の要求は応答が遅れることがあります。HTTP の要求を受けるサービスのほかに、処理を終えたら止まる「ジョブ」も動かせます。

出典：What is Cloud Run（Google Cloud）

Azure Container Apps は、多くのマイクロサービスをコンテナで動かすアプリケーションに向くとされ、Kubernetes を土台にしながら、Kubernetes の API を直接は使わせない作りです。Webアプリケーションや Web の API には Azure App Service も向く、と Microsoft は案内しています。

出典：Comparing container apps with other Azure container options（Microsoft Learn）

Kubernetes を選ぶのは、理由がはっきりしている場合

Kubernetes は、多数のコンテナを組み合わせて動かすための仕組みで、細かな制御ができる一方、覚えることと運用の手間が大きくなります。Microsoft は、Kubernetes の API を直接使いたい場合や、どんな Kubernetes の処理でも動かしたい場合に Azure Kubernetes Service を選ぶ、と整理しています。クラスターの設定と運用を利用者が担う形と、Azure が多くを担う形があります。

出典：Comparing container apps with other Azure container options（Microsoft Learn）

社内に Kubernetes を運用できる人がいない場合、はじめから Kubernetes を選ぶと、アプリケーションより基盤の手入れに時間を取られがちです。まずサーバーの管理が要らないコンテナの仕組みで始め、制御の細かさが本当に必要になった時点で検討する、という順番が無理のない進め方です。

選ぶときの考え方

選ぶときは、処理の性質、動く時間帯、運用の体制の3つから考えます。

処理の性質では、1回の処理が短く、イベントで動くなら関数型のサーバーレス、長く動く・いまのアプリケーションをそのまま動かしたいならコンテナを考えます。

動く時間帯では、使われる時間が限られ、夜間はほとんど要求がないなら、止まっている間の料金がかからない仕組みが向きます。一方で、止まっていた後の最初の応答の遅れが許されない処理では、常に動かしておく設定を選び、その分の料金を見込みます。

運用の体制では、コンテナのイメージの更新や、Kubernetes の版の更新を誰が担うかを決めます。サーバーの管理を任せられる仕組みでも、アプリケーションが使う部品の更新や、監視の設定は利用者の仕事として残ります。監視で見るものは、クラウドの監視は何を見るのか。死活・リソース・アプリで説明しています。

一つのシステムの中で使い分けることもできます。Web の画面と API はコンテナで動かし、ファイルの受け取りをきっかけにした変換や、夜間の決まった時刻の処理は関数型のサーバーレスに任せる、といった組み合わせです。

当社のご支援

当社は、動かす処理の性質と社内の運用の体制に合わせて、関数型のサーバーレス、サーバーの管理が要らないコンテナ、Kubernetes のどれを使うかを整理し、構築と移した後の運用管理までクラウドの構築と運用管理でお手伝いしています。アプリケーションそのものの開発から考えたい場合は、Webシステム開発でもご相談いただけます。