富豪プログラミングの終焉：Cloudflare Workers移行でエンジニアが直面する現実

「富豪プログラミング」という言葉に、我々エンジニアはどこか甘美な響きを感じてきたのではないだろうか。メモリを潤沢に使い、SDKを深く考えずに導入し、DBへのクエリを直列で投げても、AWSのEC2やRDSといった強力なインフラがその非効率をすべて飲み込んでくれていた。しかし、Cloudflare Workersという「V8 isolate」ベースの極めてシビアな実行環境へ移行した瞬間、その甘い夢は霧散する。榊原昌彦氏が指摘するように、これまで月額料金という名の「ブラックボックス」に溶けていた実装の重さが、バンドルサイズ、CPU時間、メモリ消費量という形で、突如として可視化されるのだ。

我々がこれまで「普通」だと思っていた実装――例えば、巨大なSDKを何も考えずにnpm installし、レスポンスをすべてメモリに展開し、ElastiCacheのキーを無造作に何度も叩くといった行為――は、実はプラットフォームの余裕に甘えた「浪費」に過ぎなかった。Workersへの移行は、単なるインフラの引っ越しではない。それは、エンジニアが自らのコードの「重さ」と「責務」を再定義する、極めて痛みを伴うリファクタリングのプロセスである。例えば、Firebase Admin SDKをそのままWorkersに持ち込もうとすれば、そのバンドルサイズは肥大化し、デプロイの制限に抵触する。ここで初めて、我々は「SDKを外す」という選択肢を突きつけられる。これは単なるコスト削減ではなく、依存関係を最小化し、本当に必要な機能だけを抽出するという、本来あるべきソフトウェア設計への回帰なのだ。

実際に、IDトークン検証という単一のタスクにおいても、実装の選択によってこれほどの差が生まれることは、我々がこれまでいかに「思考停止」していたかを物語っている。

この数値を見て「小さければ正義」と短絡的に考えるのは早計だ。重要なのは、そのパッケージが負うべき責務と、Workersという環境で保守可能かという点である。SDKを剥がして自前で実装するということは、リトライロジックや仕様追従を自ら背負うという覚悟を意味する。我々は、便利さと引き換えに「ブラックボックス」を許容してきたが、これからは「自分たちが制御できる範囲」を明確に定義しなければならない。これは、シニアエンジニアとして避けては通れない、設計の美学そのものなのである。

Workersにおけるメモリ管理は、従来のNode.jsサーバーとは根本的に異なる。128MBという上限は、isolate単位で共有されるため、グローバルスコープに安易にオブジェクトを置くことは、即座にメモリリークや予期せぬ競合を引き起こす。かつてEC2で「メモリが余っているから」とキャッシュを詰め込んでいた場所は、今や「通過点」として機能させなければならない。ストリーム処理への転換は、単なるパフォーマンスチューニングではなく、メモリという有限資源に対する敬意の表れである。すべてを読み込んでから処理するのではなく、必要な分だけを流す。この意識改革こそが、現代のサーバーレスアーキテクチャを生き抜くための必須スキルだ。

また、実行時間に対する考え方も劇的に変わる。EC2では「処理が完了すればよい」という時間軸で動いていたが、WorkersではCPU時間と経過時間を峻別する必要がある。特に、DBへのクエリを直列で待つという実装は、ネットワークレイテンシが無視できない分散環境では致命的だ。Promise.allによる並列化や、SQLの最適化は、もはや「あれば良い」機能ではなく、必須の生存戦略である。さらに、Cronジョブの設計も英雄的な「全件処理」から、Queueを用いた「バッチ処理」へとシフトさせる必要がある。途中で失敗しても、その影響範囲を最小限に抑える。この「失敗を前提とした設計」こそが、堅牢なシステムを構築するための鍵となる。

コネクション管理についても同様だ。SSE（Server-Sent Events）をつなぎっぱなしにするという手法は、常時起動しているサーバーではコスト意識が働きにくいが、WorkersではDurable ObjectsとWebSocket Hibernationを組み合わせることで、接続を維持しつつもリソースを解放するという高度な制御が求められる。ElastiCacheの「読み放題」も、KVやCache API、Durable Objectsといったストレージの特性を理解し、適材適所に配置し直す必要がある。これは、単なるコスト削減の努力ではない。プラットフォームが提供する機能を正しく理解し、アーキテクチャを最適化するという、エンジニアとしての「知的な誠実さ」が問われているのだ。

結局のところ、我々がCloudflare Workersへの移行で学んだのは、「富豪プログラミング」が単なる悪ではなく、プラットフォームの恩恵を享受するための戦略の一つであったという事実だ。しかし、その恩恵がなくなったとき、我々は裸のコードを晒すことになる。そこで問われるのは、SDKの裏側にあるプロトコルを理解しているか、メモリのライフサイクルを制御できているか、そして何より「不必要な仕事をしていないか」という、極めて本質的な問いである。環境が変われば、これまで正解だった実装が、一転して技術的負債へと変貌する。この変化の速さに適応できるかどうかが、これからのエンジニアのキャリアを左右するだろう。

我々は明日から、どのようなコードを書くべきか。まずは、自分が使っているライブラリのバンドルサイズを計測することから始めてほしい。そして、そのライブラリが本当に必要なのか、自前で実装した方が保守コストと実行コストのバランスが良いのではないか、という疑念を常に抱くことだ。また、非同期処理の並列化や、ストリーム処理への転換を、単なる最適化ではなく「設計の基本」として組み込むべきだ。サーバーレスという制約の多い環境は、我々に「無駄を削ぎ落とす」という、最もクリエイティブで困難な作業を強いる。しかし、その先には、極めて軽量で、かつ堅牢なシステムが待っている。

最後に、読者であるあなたに問いかけたい。あなたの現在のコードは、プラットフォームの「富」に依存しているだけではないか？ もし明日、そのインフラが従量課金の厳しい世界に変わったとして、あなたのコードは生き残れるだろうか。技術の進化は、我々から「思考の怠慢」を奪い去る。その変化を恐れるのではなく、自らの設計能力を磨くための絶好の機会と捉えるべきだ。富豪プログラミングの時代は終わった。これからは、一つひとつの処理に責任を持ち、計算資源を慈しむ「賢明なプログラミング」の時代である。あなたは、その準備ができているだろうか。