EmDash は Workers の無料プランだと保存のたびに CPU 上限を超えた
Cloudflare Workers の無料プランでは、1回の起動で使える CPU 時間が 10ms までです。このプランで EmDash（Astro 製のオープンソースの CMS）を動かすと、管理画面の成功した保存 21回と公開 20回が、すべて 10ms を超えました。この実測から、新規の顧客は最初から有料プランで見積もり、既存の顧客は無料プランのまま移して問題が出たら払うと決めました。
受託で顧客のサイトを制作・保守している私は、別の CMS とホスティングで動いていた顧客のサイトを Workers の無料プランで動く EmDash へ移しています。
管理画面の保存と公開は、成功した回も含めて毎回 10ms を超えていた
管理画面の保存ボタンはコンテンツの更新 API を、公開ボタンは公開 API を呼びます。次の数字は、本番に切り替える前の URL で、この 2つの API を同じ Worker に対して呼んだときのものです。Workers のログに残る起動ごとの CPU 時間を、成功した起動だけ数えています。10ms と比べて読んでください。
- コンテンツの更新（保存と同じ API）: 22回、中央値 31ms。成功 21回中 21回が 10ms 超、打ち切り 1回
- 公開: 20回、中央値 23ms。20回中 20回が 10ms 超、打ち切り 0回
- 公開ページの表示: 13回、中央値 53ms。13回中 12回が 10ms 超、打ち切り 0回
10ms を超えても、毎回打ち切られるわけではありません。Cloudflare の Workers の上限の説明では、稀な超過には余裕があり、恒常的に超えると打ち切られます。そのため見るのは打ち切りの回数ではなく、成功した起動の CPU 時間です。
打ち切られると、下書きだけが書かれて公開されない
更新 22回のうち 1回は exceededCpu（CPU 上限で打ち切られた起動に Workers のログが付ける結果）になり、呼び出し側には 503 が返りました。このとき下書きの版だけが書かれ、公開されない状態が残りました。
公開を送り直すと解消してデータも失われませんが、送り直すまで保存した内容はサイトに出ないので、顧客から見ると「保存したのに反映されない」状態です。移行前の構成では起きなかったことです。
移行でできなくなることには、回避策を作らずに払う
無料で済むなら無料プランのままにし、移行前にできていたことが移行でできなくなるなら手間のかかる回避策を作らずに課金するのが私の線引きです。保存がときどき反映されないのは、移行でできなくなることに当たります。
捨てた回避策は 2つです。1つ目は、CPU 時間を 10ms 以下に抑える工夫です。公開ページの表示でも中央値は 53ms で、10ms の枠はサイトの見た目を作る処理と CMS 本体だけで超えています。テンプレートを直しても収まらず、時間のコストが高すぎます。
2つ目はキャッシュです。エッジキャッシュ（Cloudflare が公開ページの応答を、Worker を起動せずに手前で返す仕組み）に当たる間は、公開ページで Worker が起動しません。一方、管理画面の保存と公開は毎回 Worker に届くので、キャッシュでは Worker の起動を避けられません。詳しくはEmDash が真っ白になるのは Free プランの CPU 上限とCloudflare Workers 無料プランで 503 が出る原因は CPU 上限にあります。
払う先は有料プランの Workers Paid で、Cloudflare の Workers の料金は 1 アカウントあたり月 5ドルからです。CPU 上限は、無料プランの 10ms に対して既定 30秒（最大 5分）です。有料プランにしても描画は速くならず、打ち切られなくなるだけです。
常に超えるなら新規は有料で見積もり、既存は失敗が戻せるかで決める
判断の前に、無料プランの上限を「たまに超える」のか「常に超えている」のかを実測で確かめます。常に超える構成は、新規の顧客に無料で出しません。既存の顧客では、失敗が戻せる種類かどうかと、顧客との関係の事情で順番を決めます。この顧客のサイトの数字は、常に超える方に当たります。私が測ったのは EmDash だけで、他の CMS では測っていません。測った物は、管理画面の保存と公開と公開ページの表示で成功した起動の CPU 時間です。
前の節の線引きに当てはめると、既存の顧客も有料プランに上げることになります。それでも既存の顧客は無料プランのまま移します。理由は 2つです。1つ目は、移行の途中で追加の費用の話を持ち出さないという顧客との関係を優先したことです。2つ目は、打ち切りが公開の送り直しで戻せる種類の失敗で、データが失われないことです。既存の顧客も今すぐ有料プランにする案は捨てました。
払うきっかけにする「問題」は、本番で打ち切りが起き、顧客の保存が反映されないことです。打ち切りはログに exceededCpu として残ります。何回起きたら払うかの基準と、それに気付く仕組みはまだ決めておらず、本番を新しいサイトに切り替えた後に決めます。
新規の顧客は Workers Paid を前提にし、見積もりと提案の段階で費用に含めます。新規も無料で始めて問題が出たら上げる案は捨てました。保存が毎回上限を超えることはもう分かっていて、無料で始めると、分かっている失敗を顧客に先に経験させてから費用の話をする順番になります。