- サーバーレスは手軽に見えるが、実際には 複雑さ、制約、高コスト を招く構造である
- コンテナは 移植性、状態保持、明確な制御 を提供し、ほとんどのユースケースにより適している
- サーバーレスは コスト構造が不透明 で予測しにくく、構成要素間に 不要な複雑性 をもたらす
- サーバーレスのスケーラビリティと手軽さは 限定的なユースケース にしか適していない
- 実運用環境では コンテナベースのデプロイ のほうが単純で、スケーラブルで、コスト効率が高い
Serverless Is a Scam. Just Use a Container.
サーバーレスとは何か?
- サーバーレスは 個々の関数単位でコードをデプロイ し、クラウドプラットフォームが実行とスケーリングを自動処理する方式である
- しかし実際には次のような問題がある
- 実行時間制限 （例: AWS Lambda は 15 分制限）
- 状態保持不可 （実行のたびに初期化）
- コールドスタート問題
- デバッグしづらい環境
- プラットフォームごとの設定と構成
- 過剰な YAML の使用
- シンプルに見えても、複雑な作業には不向き
コンテナ: シンプルで強力、そして良い意味で退屈
- コンテナには次のような利点がある
- 起動が速い
- どの環境でも実行できる
- 状態を保持できる （
Docker volume を使用）
- 実行時間制限がない
- デバッグ、ローカル開発、本番環境への移行が自由
- 例示コード:
docker run -v my-data:/data my-app
- 結果として 状態を持つワークロード をどこでも一貫して実行できる
- ベンダーロックインがなく、隠れたコストもなく、不要な構造変更もない
サーバーレスの価格設定: ユーザーを混乱させる
- サーバーレスのコストは非常に複雑に構成されている
- 呼び出しごとの料金
- メモリ使用量
- 実行時間
- 転送データ量
- リージョンごとの差
- シークレットキーへのアクセス料金 など
- 混乱を招く用語の例:
- Provisioned Concurrency Units
- GB-seconds
- Requests Tier 1/2/3
- 予測しにくい課金構造により、想定外の請求書 が発生しうる
- 比較すると、月額 $5 の VPS は 予測可能な定額料金 であらゆるリソースを制御できる
「サーバーレスはスケールできる」への反論
- サーバーレスは 技術的にはスケール可能 だが、実際にはほとんどのアプリでそこまで必要ない
- 多くのアプリケーションが必要としているのは次のようなもの
- 予測可能性
- 監視しやすさ
- 適切なリソース制限
- 開発環境とステージング環境
- コンテナベースならスケールも簡単
replicas: 5
- あるいはロードバランサーを使って水平スケールも可能
ステートレス設計は人為的な問題を生む
- サーバーレスは 無条件にステートレス設計 を強いる
- キャッシュ、セッション、一時ファイル、永続接続が使えない
- その結果、必要になる要素は次のとおり
- 外部データベース
- 分散キャッシュ
- ファイルストレージ
- イベントバス
- ステートマシン
- 結局、「シンプルな」サーバーレスアプリが 6 個以上の SaaS 依存 を抱えることになる
- 一方、コンテナでは次のことが可能
- インメモリキャッシュ
- ディスク書き込み
- セッション保持
- 無制限実行
「サーバーを管理したくない」への回答
- サーバー管理なしでコンテナベースのプラットフォームを使う方法はある
- Sliplane、Railway、Coolify などのプラットフォームを使う
- 単純に VPS 上で Docker + systemd だけでも可能
- Git ベースのデプロイ、ロールバック、ログ、メトリクスなど 運用のしやすさを確保 できる
- システム全体に対する 理解と制御が可能
「サーバーレスのほうが安い」への反論
- 呼び出し頻度が極めて低い場合は安くなることもある
- しかし次の状況ではコストが急増する
- トラフィックが一定以上になった場合
- メモリ増加が必要な場合
- 実質的な計算量が多い場合
- データ転送が多い場合
- サーバーレスはプラットフォームがすべてを隠すため、最適化が難しい
- 一方、コンテナは
- 安価なハードウェアでも継続実行できる
- キャッシュやストレージと統合できる
- ベンチマークやチューニングがしやすい
- ミリ秒単位の課金がない
サーバーレスが実際に適しているケース
- 次のような断続的でステートレスな作業に適している
- イベント駆動関数 （例: 画像リサイズ）
- めったに実行されない処理や Webhook
- 内部ツール
- POC
- 素早いスケールアップ/ダウンが必要な場合
- しかし 実際のアプリケーション では限界にぶつかり、
- 時間、コスト、複雑さの面で 大きな代償 を払うことになる
コンテナがより良い選択である理由
- コンテナは次を提供する
- 単一または複数コンテナでのデプロイ、スケーリング、状態保持、バックグラウンド処理、DB 連携まで対応できる
- コードを書き直さずにプラットフォーム移行も可能
要約 （TL;DR）
- サーバーレスは理論上は魅力的に見える
- 現実には:
- 不透明
- 高コスト
- 過剰な複雑性
- 過大宣伝
> 始める前に自分に問いかけよう:
> 「これ、ただコンテナで作れないだろうか?」
- 答えが「はい」なら、コンテナから始めるほうがより良い選択
後続アクションの推奨
- サーバーレスによって 想定外のコストや非効率なワークフロー を経験した事例の共有を勧める
- 単純な問題を過度に複雑にしないこと
19件のコメント
xfaasもありますし、Cloudflare Workersもありますよね。少し偏った記事のように思います。
GPUをレンタルするとき、サーバーレス関数で少しだけ実行することを考えていたのですが、
コンテナでもそれはできますか
昔のPHPウェブホスティングサービスで、PHPを抜いてベンダーロック満載のJSを入れたら……
代表的なサーバーレスFaaSプラットフォームと見分けがつきにくい気がしてなりません。
もちろんPHPやJS/TSを主に使うクソ食い道楽の私は満足して活用していますが、
だからといって多くの人がこれをおいしいと評価する理由は、正直よくわかりません。
個人的な考えでは、ベンダーのサーバーレスサービスを利用するのは危険ですが、コンテナを使って会社独自にサーバーレス環境を提供するのは良いと思います。サーバーレスをサービスではなく一つの概念として活用すると良さそうですね。
しばらく前に、Vercel が Edge rendering を断念したというツイートと動画[1]、そして serverless server（笑）[2] に関する記事が話題でしたよね。そのときに出た記事群と似た見解を持っている気がします。
個人的な意見ですが、フロントエンド開発者の立場からすると、ユーザーのリクエストに serverless function をぶら下げるのは、まだ先の話だと思います（作ろうとしているアプリケーションが MVP でないならなおさら）。
[1] https://youtu.be/lAGE-k1Zfrg
[2] https://vercel.com/blog/…
[2-1] https://bobaekang.com/blog/…
もちろん、この投稿にも付いているように、かなり過激な釣り目的の文章っぽくはありますね :(
コンテナベースの環境（ECS Fargate中心、Kubernetesクラスター）とサーバーレス環境（AWS）の両方を経験した立場としては、そこまで強くは共感しませんね。
コンテナベース環境の長所として挙げられている点は、長所であると同時に短所にもなり得る部分です。
「直接制御できて状態を持てる」と言及されている部分は、いずれも管理ポイントになって運用難易度が高くなるとも言えるでしょうか。
私は、小規模な組織や、専門的なサーバー管理チームがない組織であるほど、サーバーレスを強く勧めますね。
ああ、コスト計算が複雑だったり予測しにくかったりする点、そしてベンダーロックインの問題については同意します。
開発体験とオブザーバビリティについて言及している方がいるので付け加えると、
初期の統合環境さえしっかり構築しておけば、コンテナベースに劣らない、あるいはコンテナベースよりもさらにネイティブに近い開発体験を実現できます。（そのためのさまざまなツールもあります）
オブザーバビリティについても、深くやろうとするなら、サーバーレスでもコンテナベースでも同じように簡単な問題ではありません。ログの集中管理、各種メトリクスの可視化、APM、CPU/メモリ使用率の可視化、そしてそれに応じたスケーリング戦略の策定など……
そこまでの段階でなければ、クラウドベンダーが基本的に提供するメトリクス/ログ統合が強力なので、大差ありません。
強めに言うなら、「サーバーレスをどこまでちゃんとやってみたんですか？」と聞きたくなりますね……😅
必要なエンドポイントの一部だけを Lambda で動かすほうがいいのでは、という気もします。そもそも私はサーバーレス開発の経験がないので何とも言えませんが、特殊ないくつかのケースでは良さそうにも見えるので。
この記事を書いた会社はコンテナホスティングプラットフォームの会社ですし、偏った視点で書いたのではないでしょうか（笑）
以前もフロントエンド界隈で、nextjs（vercel）について懸念を示す netlify（競合他社）の開発者の文章を疑う方がいましたよね。コメントを見る限り、そこまで偏ってはいないようです。
私はフロントエンド側なので……こちらの分野にはあまり詳しくないのですが、「サーバーレス（サーバーはある）」というミームはよく見かける気がします（笑）
ネイティブと比べて開発体験が著しく劣ることが大きすぎる pain point であり、ソフトウェア自体がインフラ提供者に依存するようになるので、一度定着すると抜け出しにくくなります。リファレンスが明らかに少ないのはもちろん、可観測性もあまりに低いです。
Cloudflare は、少なくとも他社と比べればサーバーレスをうまくやろうとしているように思います。データベースもサーバーレス、Key-Value ストレージもサーバーレス、さらにはメッセージキューまでサーバーレスのものがあり……
（もちろん、こうなってくるとプラットフォームに完全に従属・拘束されるようで、抵抗感を覚えることもあります）
それでも、デバッグ、可観測性、そして開発体験が改善されないのであれば、依然として足踏み状態のままでしょう。
Cloud Run でGO
サーバーレスでサービスを運用するのは、間違ったツールを選ぶことだ。
サーバーレスが必要な特定の問題はある。断続的に使われる用途には適している。
サーバーレスコンテナサービスでも同じ意見なんでしょうか
従来のサーバーレスサービス（lambdaのようなもの）の問題のために、AWSがFargateを作り、さらにもっと簡単なApp Runnerまで作ったのに 🤔
しかも Google Cloud には、scale to zero の超優秀なサーバーレスコンテナサービスである Cloud Run まであるわけで
この中では個人的に Cloud Run がいちばん開発体験が良かったです
サーバーレス（サーバーはある）
Hacker Newsの意見
そもそもSeverlessではなく、Serverleaseだった。
wwwww