Allex

Cloudflareに全力投球中
中小企業のシステムを中心に１年間で100 Worker以上を作成

[Allex @allex_jp]

Cloudflareの制約は足枷じゃない。
教科書だ。

「Cloudflareではできない」は思い込みだ。
制限にぶつかったときこそ、
まだ最適化できるという合図。

全てはここから始まる。

[Allex @allex_jp]

間違ってるかもですが、自分の理解ではこんな感じではないかと。

D1/R2/KVはアカウント単位のリソースなので、Preview を作っても自動では分かれず、そのままだと本番と同じ DB・バケットを共有。
「bind to a separate resource」
= wrangler configのpreviewsブロックで、
本番とは別のdatabase_id / bucket_nameを指定してね、という意味。
自動でPreviewごとに分離されるのはDurable Objects とContainersだけ。
Preview同士でも同じIDを指せば共有になる。

[Allex @allex_jp]

Cake、Zend、Laravel、Struts、Django、Express、Next、Nuxt 等、20年フレームワークを触った経験を元に記事を書きました。
層を分けることより、1本のリクエストの全体像が見えることの方が重要だ、という話です。
AI開発でのリファクタの考え方の参考にもなると思うので、ぜひ読んでみてください。

[Allex @allex_jp]

https://t.co/q0FNYYUBpR

[Allex @allex_jp]

これはそのとおりかも。

自分の場合は、Nuxt + Cloudflareでの開発をメインにしており、実装の際は基本的にその２つに関するスキルを読ませるだけで済んでいる。
～のプロジェクトを参照して、～をつくってとかで済む事が多い。
プロジェクトが増える度に、むしろ資産化していることを実感できている。

[pospome@カミナシのVPoE @pospome]

AIにコード書かせて分かったのが、設計方針、実装方針が一貫していると、Skillのボリュームが少なくなるので、出力に対する精度が安定する気がする。言い換えると負債の多いシステムは、モジュール単位で実装方針が違ったりするので、Skillに定義するルールが多くなり、Skillを育てるコストがかかる。

[Allex @allex_jp]

https://t.co/q0FNYYUBpR

[Allex @allex_jp]

これは既存PythonコードをWorkerで動かしたい人向け。
新規に実装するなら処理速度でJSが有利。

JSの起動はV8のisolate生成そのもので、これがWorkersの最小単位。
PythonはそのisolateのなかにWasm版CPythonを立てて、さらにPythonコードを読み込む。

Code Modeで使う場合もJSの方が明確に有利。
AIはPythonと同様にJSも書けるし、Code Modeで書くのはバインディングやツールを呼び出すだけのコードなのでPython固有のライブラリは要らない。

Pythonにしかないライブラリを使いたい場合はデプロイ済みのPython Workerで使う。
ただし動くのはpure PythonかWasm向けにビルドされたwheelがあるものだけで、C拡張ありのライブラリは対応状況次第。

参照（公式）
"your code is interpreted directly by Pyodide, within a V8 isolate."
"we perform the expensive initialization work at deploy time, rather than at runtime."
https://t.co/LCo7Kt2sQJ

"Python Workers are currently much slower to start than JavaScript Workers. For one-off AI-generated code, we strongly recommend using JavaScript. AI can write either language equally well."
https://t.co/WLfaEJlib3

"any packages with native C/C++/Rust extensions must be cross-compiled to WebAssembly"
https://t.co/mkJil7WLN3

[Cloudflare @Cloudflare]

We're excited to announce that today Python Workers are generally available (GA).
It means Python is now a first-class, fully supported language on the Cloudflare Developer Platform. Read everything about it: https://t.co/ZwQe6IPd93

[Allex @allex_jp]

@romi_hoshino こんなこともあろうかと、完全無料で読めるニュースサイトを試運転しています
ニュースアプリ含めて広告だらけで使い物にならないので、自分用につくりました

https://t.co/2TipYFQgTw

[Allex @allex_jp]

クラウドを提供する側でないなら、この一覧はもう古い。

Cloudflareはサーバーという概念そのものを構造で消している。
ロードバランス、スケーリング、OS更新、証明書。
プロダクトを作る側にはもう存在しない仕事が、この一覧には並んでいる。

残るのはネットワークと構成だ。
ただし運用の仕事としてではなく、アプリの設計として残る。
どのサービスがどのサービスを呼べるかを絞れば、それがそのままセキュリティになる。
データをどこに置き、どの経路で読むかを決めれば、それがそのまま速度とコストになる。
だからインフラはもうアプリから切り離せない。
ここまで来れば、AIがカバーできる範囲はかなり広い。

自分は20年近く前、データセンターで業務用サーバーを組み、VMwareや仮想ネットワークを構築していた。だからCloudflareの思想はよく分かる。
当時、物理配線が宣言に変わった。
今はサーバーもデータベースもキューも証明書も、インフラ丸ごとが宣言に変わっている。

フロントエンドエンジニア、インフラエンジニアという区分がもう古い。
Cloudflareのような環境でAIを使えば、一人で全体を見ることも難しくない。
全体を見据えて、パターン化し、自動化する。
それが仕事になる。

[まるこめ@AWS GCP SRE（3年） @aws202211maru]

インフラはAIでできるっていってる人がごく僅かにいるんだけど

どうやら Vercel や Clouflare にデプロイしたレベルくらいでインフラできると思っているようです

参考までに実務レベルのインフラエンジニアの業務を載せておきます

・AWS/GCP/Azureのアカウント・Organization設計、IAM、権限分離

・VPC、Subnet、Routing、Firewall、VPN、PrivateLink等のネットワーク

・Kubernetes/ECS/VM/Serverlessなどの実行基盤

・DB、Redis、Kafka等の状態を持つシステム

・Terraform等によるIaC、CI/CD、変更管理

・Secret/KMS、証明書、セキュリティ

・Logging / Metrics / Tracing / Alerting

・キャパシティ設計、スケーリング、パフォーマンス

・Backup / Restore / Disaster Recovery

・SLO、可用性設計、障害対応、オンコール

・コスト管理

・Compliance、監査、脆弱性対応

・本番障害時の原因切り分けと復旧判断

[Allex @allex_jp]

CloudflareのWorkerから何かを呼ぶとき、ネットワークに出るか出ないかでレイテンシが変わる。
整理するとこうなる。

■ネットワークに出ない
・ServiceBinding（Worker→Worker）
同じサーバーの同じスレッドで動く。
公式の記述は「zero overhead or added latency」。

・DOの中のSQLite
computeとdataが同じプロセス。
公式の記述は「effectively zero-latency」。

■ネットワークに出る
・DOのstub
そのDOが置かれたデータセンターへ転送される。
同じDCなら1〜3ms、別リージョンなら数十ms以上。
DOは初回get()の場所で作られ、以後は移動しない。
つまり、DOをどこで最初に触るかが、そのDOの一生のレイテンシを決める。
ユーザーごとのDOなら、そのユーザー本人の最初のリクエストで作らせるのが正解。

・BrowserRun
ブラウザはWorkerの外の別プロセスで、CDPをWebSocketで接続する。
launch()は秒単位、以後はPuppeteerのawait1つが1往復で数ms〜数十ms。

・Container
Worker→DO→LinuxVMの2ホップ。
コールドスタートは秒単位、以後は1リクエストで2往復ぶん。
公式に「DOとContainerは同じ場所で動く保証はない」とある。

・公開URLへのfetch
一度外に出てCloudflareのフロントに入り直す。
TLSとエッジ処理が乗るので同じDCでも数十ms。

[Allex @allex_jp]

こういう意味でもWeb標準の価値があがっている。

PythonライブラリをAIに読ませて、JavaScriptでつくりかえるとかも簡単だしね。

Cloudflareで動かすために、JSにないライブラリや重いライブラリは自プロジェクト用にJSで作り変えてる。

[Taku Kudo @taku910]

AIでコーディングコストが激減した今、機能過多なfatライブラリの価値は低下している。小綺麗なGlueコードやボイラープレートはAIが書けるし、不要なコードを抱えること自体がリスク。AI時代のOSSには「高速・安定・セキュア・コンパクト」が重要かも。SentencePiece Liteはその方向性で開発した

[Allex @allex_jp]

本当にCloudflareの最大の強みは「サーバーがない」ことだと思う。
それにより、考えるべきセキュリティ事項・運用事項が激減している。

Cloudflareの料金体系や制約は、物理消費に対して課せられていることを認識することも重要。
それがCloudflareが安く提供できる理由でもあり、それにそってシステムを作ると最適化されるということにもつながる。

[connect24h @connect24h]

Cloudflare Workers、一強時代。このアーキテクチャは覇権を取った。相変わらず商売下手で市場はまだ取れてないのがもったいない。強さの本体は“安さ”じゃない。

V8 isolateで実行単位を極限まで軽くし、
すでに世界中へ張り巡らせたCloudflareのネットワーク上で動かす。

しかもその上に
D1 / R2 / Durable Objects / Queues / Workflows / AI
まで積み上がっている。

つまり安いのは値下げ競争の結果ではなく、
構造的に原価を下げられる設計だから。

この記事で一番刺さったのは、
Workersはサーバーレスというより「プロセスレス」に近い、という整理。

ここまで来ると、
「どのクラウドを使うか」ではなく
“そもそもサーバーという単位を持つ必要があるのか”
から考え直したくなる。

かなり面白い。

https://t.co/qnlRGOMp2q

[Allex @allex_jp]

https://t.co/ki1V6J8NHi

[Allex @allex_jp]

@R0u9h なるほど、ようやく腑に落ちました。

ThinkならR2におけますが、その構成だとDO SQLiteに置くしかないですね、ありがとうございます。

[Allex @allex_jp]

これは処理が最適化されていない可能性が高いかも

Workers でファイルを扱う時は、
・ファイル本体を変数に入れない
・送り元と受け先をストリームで直結する
が基本。
これで基本的にメモリ不足にはならない

あと画像処理をWASMでisolate内でやっているなら、それ自体が「変数に画像を載せる」行為なので、Browser Run に出すのがおすすめ。
処理はブラウザ側で走るので isolate のメモリを食わないし、canvas＋JS でほとんどの加工ができる

[LaPh @R0u9h]

Cloudflare Workersマジで256MBメモリの環境くれ~~~~~
画像扱うとすぐに枯渇する

[Allex @allex_jp]

構成を完全に理解できていないと思うので、齟齬があったらすみません。

まず「Workersを経由する＝Workerのメモリにのる」ではないです。
Workerはrequest.body/response.bodyのReadableStreamを素通しするだけでContainerと直結でき、経由点ではOOMしません。
OOMするのは経由点でバッファしたときだけで、最初から言っているのはその話です。
Worker/DO層とContainerのメモリはそもそも別勘定です。

また、実行環境がContainersなら重い処理はすでに外に出ていて、ラウンドトリップも払っていると思いますが、ここについては自分と同じ考えだと思うので、議論することはないと思います。

DOに置くと読みが速いのはストレージ配置の話で、処理をどこでやるかとは独立です。モデルに渡すバイトはどこに保存していても外へ出ていくので、保存場所の近さは処理を中に置く理由にはならないと思います。中で加工すれば128MBの話に戻るだけなので。

ここからは推測ですが、モデルに画像を渡すとき、base64をJSONに同梱していませんか？渡し方でメモリ使用はこれだけ変わります。

①署名URLを渡す（providerがURL取得対応の場合）
→0バイト（URL文字列だけ）

②送信時にR2のストリームをbase64変換しながら本文へ継ぎ足す方式（inline必須のprovider向け）
→チャンク192KBのみ

③JSON.stringify(body)にdata URL同梱→全量×2〜3が同時にのる

③になっているなら、他をどれだけ最適化してもメモリは足りなくなります。

自分もThinkでエージェントを組んでいるので、これも予想ですが、エージェントのツールで画像を扱っているなら、ツール結果にinlineで画像を返すと履歴再送のたびに全量がのり直します。ツール間は参照（URL）で受け渡して、送信時だけ実体化する形にするとそこも消えます。

[Allex @allex_jp]

言葉不足ですいません。

処理を外（Browser Run / Images)に出して isolate をパイプに徹させるのが、ここで言っている「最適化」です。
この構造なら、ストリーム直結で isolate を通過するのは常に小さなチャンクだけなので、ファイルサイズとメモリ消費が切り離され、メモリ不足は起きません。
（page.screenshot()を使う場合は、その分だけ1回メモリにのる）

処理をWorker内でやるか、外でやるかというのは別の論点ですね。
自分はメモリを大量に使う処理をWorker内でやるなという立場なので。

[Allex @allex_jp]

Cloudflare WorkersでWasmを最初から使おうとする思想はよくないとおもう。
なぜなら、Workersの最適化は重い処理を外にだすことで実現するからだ。
Wasmは重い処理を中に持ち込む行為なので、逆の発想になる。

また、Workers環境において、JSの実行速度をWasmが上回る場面はほぼないと思ってよい。
Wasmの速さは、起動コストを長寿命プロセスで償却し、境界を跨がずに大きな計算を回して初めて出る。isolateが短命で、仕事がリクエスト単位で小さく、bindingへのアクセスに毎回JSを挟むWorkersでは、その条件が全部欠けている。

[Allex @allex_jp]

Geminiのいいところが徐々にばれてきているな

1.日本語のうまさ（だいぶ浸透してる）
2.コミット、簡易スクリプト等の処理の速さ（バレてきた）
3.デザインセンスのよさ（わりとバレてない）

[Allex @allex_jp]

Cloudflare Queuesを処理に組み込めば、もっとシンプルになりそうな気がしないでもない

[TAKAPON @takapom_engin]

cloudflare Durable ObjectのDBについて

https://t.co/c3WO7bvDQo

[Allex @allex_jp]

Next.jsでできることは、Nuxtでできるからな

そして、Nuxtの方がWeb標準に近くて軽い

Next.jsだけでなくて、
Reactが必要か？
TypeScriptが必要か？
も見直すべき。

AIがコードを書いてほぼ読まない時代に、人間がIDEを使って、チームでコードを書いていた頃の常識をひきずるのはもうおわりにしたほうがいい。

[asahi @ashunar0]

何度でも言いたい

そのプロジェクト、本当にNext.js必要？ https://t.co/XksJPVHG2l