客家エンジニアの生存戦略：serverless がいいかどうかは、試せばわかる

クラウドは魅力的。でも請求書が届いた瞬間は、本当に胃が痛くなる

最近、客家エンジニア（客家人は倹約家として有名です）として、手持ちのリソースをどうやって使い倒すかを考えています。会社員時代はクラウドを好きなだけ使えて快適でしたが、リソースの利用効率にこだわる私はずっと、削るべきところは削り、使うべきところには使い、クラウドサービスの価値は最後の一滴まで搾り取るべきだと思っていました。

会社を辞めたら、仕事で手に入れていた「クラウド使い放題」が突然なくなりました。贅沢に慣れると質素には戻れないもので、相変わらずクラウドツールを王の財宝（ゲート・オブ・バビロン）のように全開で展開していたら、請求書が届いた瞬間にイラッとしました。ブロックチェーンエンジニアだった頃は EC2 を一気に 5 台立ち上げ、K8S もフル活用。今振り返って計算してみると、毎月かなりの金額です。

教訓を得たのは前のプロジェクトでした。シンプルな RDB を動かしたいだけだったので GCP でマネージドサービスを立ち上げたら、クラウドベンダーが究極のおせっかいとは何かを見せつけてきました。自動バックアップ、監視、アイドル料金……これだけで月 2000 台湾ドルが吹き飛びました。まだ一円も稼いでいないし、トラフィックもないのに、この邪悪なクラウドの巨獣にまずしっかり持っていかれたわけです。名目だらけの請求書を眺めながら、心の中で毒づくしかなく、手にはクレジットカード。

痛いほど思い知らされました。クラウドベンダーの暴利は、たいてい百花繚乱の名目の中に隠れている。

トラフィックにお金がかかる、計算にお金がかかる、それは受け入れます。でも、一日に数人しか使わないサービスを維持するために、固定のインフラ月額を払わなければならないと気づいたとき、Serverless という選択肢が一気に重要になります。

なぜ今、スタック全体を Serverless に移し、しかも Cloudflare Workers 一択なのか？

# 使われなければタダ

答えはとても客家的です。アイドル中の請求額はゼロ。

従来のマネージド DB や VM は、使われていようがいまいがマシンは動きっぱなしで、メーターも回りっぱなし。Workers は request が来たときだけ課金され、無料プランでも 1 日 10 万リクエストあるので、個人プロジェクトではまず使い切れません。R2 はストレージに下り転送料もかからないので、画像を置くブログにとってはかなりありがたいです。

今あなたが読んでいるこのブログを例にすると、サイト全体は実質 3 つのパーツだけです：

• blog Worker：フロント（SvelteKit）担当
• blog-cms Worker：管理画面と API（Elysia）担当、前段に Cloudflare Access
• R2 bucket：index.json、各記事の Markdown、画像を格納

データベースなし。 そう、見間違いではありません。DB すら切りました。

# コネクションプールに注意：serverless から DB につなぐときの落とし穴

DB を切ったのは、以前 serverless から DB につなぐことで本当に痛い目を見たからです。ここでは要点だけ書いておきます。なぜ爆発するのか、そのままコピペできる書き方は、別記事「コネクションプールに注意：serverless でデータベースに接続するときの落とし穴」にまとめました。

従来のバックエンドのコネクションプール（connection pool）には大前提があります。プログラムが長時間生き続ける process であること。起動時に 10 本の接続を張っておけば、あとは 1 万件のリクエストがその 10 本を順番に使い回し、みんな平和に暮らせます。

ところが serverless は、まさにこの前提を壊します：

• isolate / function のインスタンスはそれぞれ独立していて、トラフィックが来ると一斉に大量のインスタンスが立ち上がり、インスタンスごとに自分で接続を張る
• インスタンスはいつ回収されるかわからず、接続がきちんと閉じられるとは限らないので、DB 側には半死半生の接続が大量に残る
• Postgres も MySQL も max_connections の上限があり、トラフィックのピークが来ると、先に落ちるのはあなたのプログラムではなく、DB が接続を拒否し始める

結果として、普段は何の問題もないのに、トラフィックが来た途端に爆発する。しかも、いちばん生きていてほしいタイミングで。

解決策はだいたい 3 つあります：

1. HTTP ベースのデータベース driver に替える：Turso（libSQL）や Neon の serverless driver のように、クエリ 1 本が HTTP リクエスト 1 本になるので、長時間の接続を管理する必要がない
2. 間にコネクションプールのプロキシを置く：Cloudflare の Hyperdrive がまさにこれ。Worker は Hyperdrive につなぎ、Postgres とのコネクションプールは Hyperdrive が維持してくれる
3. いっそデータベースを持たない：データ量が少なく書き込み頻度も低いなら、JSON のインデックスとファイルの山で十分

このブログは以前 PayloadCMS と Turso で動いていて、1 つ目の道に当たります。でも、月に 1〜2 本しか更新しないブログのために CMS と DB を養うのはさすがに贅沢すぎると気づいて、3 つ目の道に乗り換えました。記事一覧は R2 上の index.json、本文は content/.md、フロントの Worker には R2 の読み取り専用権限しか渡していません。最高のコネクションプールは、コネクションプールを使わないこと。

# とはいえ serverless もタダ飯ではない

いいことばかり書いてきましたが、代償も正直に書いておきます：

• 環境変数がグローバルではない：Workers の binding は request ごとに渡されるので、Elysia のようにモジュール層で設定を読む癖のあるフレームワークでは、AsyncLocalStorage で env をずっと下まで受け渡す必要がある
• コードを動的に生成できない：Workers は new Function のようなものを禁止しているので、Elysia は AOT をオフ（aot: false）にしないと動かない
• ローカル開発には慣れが必要：今は wrangler dev で本番の R2 に直接つないでいる。便利は便利だけど、手が滑ると本番データを書き換えてしまう

どれも深い穴ではありませんが、踏んでみないとわからないものばかりです。

# 試せばわかる

というわけで、タイトルの「いいかどうかは試せばわかる」に対する私の結論は、個人プロジェクトや低トラフィックのサービスにとって、serverless は客家人の良き友です。使われなければタダ、使われたら従量課金。最悪のケースはトラフィックで溢れることですが、そのころには請求書を払えるだけのお金がもうあるはずです。

あの 2000 台湾ドルは、授業料だと思うことにします。少なくとも今は、毎月 Cloudflare の請求書が届いても心穏やかです。