【現場で使える Bubble #1】WUって？課金仕様とプロダクトに合わせたプラン選択

やっはろー！

Webディレクター兼エンジニア兼アニメ担当兼社内の高田純(ry) etc 諸々やってます、

Tak です！

(ゲームも大抵この名前でやってるので見かけたら是非声掛けてください！タクorタックと呼ばれることが多いですが、外国人にはターキー”なんて呼ばれますが、まぁなんでも可です)

いや~去年も暑かったですが、今年の夏も暑いですねぇ…
毎日35℃(都内)を超える日が続いてますが、皆さん熱中症にはくれぐれもお気をつけてください( ;∀;)

さて、わたくしTakの1本目の会社Blogですが、

【現場で使える Bubble #1】ということで Bubble.ioのWU（ワークロードユニット）について書いていきます。

通常のプログラミングでは馴染みのない言葉ですよね。

ご安心ください！Webディレクターとしても馴染みはありません！

というよりBubble.io特有の要素なのでほぼ初見さんだと思います！

「WU(ワークロードユニット)ってなんぞや？」という方にもわかりやすく説明していきますので是非最後まで読んでいただけると幸いです！

それでは行ってみましょう～

目次

1. WU（ワークロードユニット）って何？
   • WUの構成要素
   • WUにかかる料金
   • WUをサブスクする場合の料金
2. WUで最も重要なこと。知らないと破産します
   • 超過料金について
   • 無限ループ時の対応と対策
3. どんなプランがおすすめ？
   • プロダクトの規模から必要なプランを選択 ⇒ WUを想定

WU（ワークロードユニット）って何？

少し概念的なお話です。

ℹ️ 公式の要約: WU=ワークロードユニット(以下WU)は、Bubbleがアプリケーションのリソース使用量を測定するために使用する単位で、従来のプランにおける「サーバーキャパシティ」や「APIワークフロー制限」などの複雑な要素を単一のメトリックに集約し、より直感的にリソース消費を管理できるようにすることを目的として2023年5月1日に追加された新しい課金モデルです。

…簡単に言うと

平成世代 → ガラケーの”パケット”

令和世代 → スマホの”通信料”

に近いもので、毎月使用できる「WU数」を契約し、使用した分だけWUが消費される単位です。

(ガラケーでパケットを気にしていたのが懐かしいですね。私はパケットがあまり使えなかったのでチャリ走ばかりやってました🚲💨)

そして、このWUはBubble上の様々な処理に使用されます。以下は一例です。

WUの構成要素

• ページの読み込み
• データベースの操作
• プラグイン呼び出し
• 外部API連携
• ワークフローの実行 etc

※より詳しい要素はBubble Docsを参照ください。

WUにかかる料金

Bubbleでは4つのプランが用意されおり、プランごとで以下の違いがあります。

WUをサブスクする場合の料金

Starter以上の有料プランであれば、WUをサブスクリプションすることが可能です！

またサブスクを購入しなくとも、「1Kあたり0.3ドル」で超過分を購入することができます。

ただし断然「1Kあたり0.15ドル」になるサブスクを購入する方がお得です！なんてたって50%OFFですから！

WUで最も重要なこと。知らないと破産します

ここまでWUの概念~料金について説明しました。

が、実はWUで最も大事なこと。それは…

従・量・課・金

…

もう一度言います。

従・量・課・金

はい、従量課金システムです。

前述した通り、契約したプラン + 追加購入したサブスク分のWUが毎月付与されますが、もし使い切ったらどうしましょう？

正解は ⇒「サービス停止！」…なんてことがあったらこの世のほとんどのサービスが止まっちゃいますよね。

BubbleではWUを使い切った後でもサービス・システムの状態を維持するため、従量課金性を採用しており、超過分はWUの消費量に応じて追加料金が発生します。

超過料金について

感の良い人は気付かれたと思います。

「あれ、もしかしてWUを消費し続けると無限に課金されるのでは？」と。

はい。その通りです。1Kあたり0.3ドルで請求されます。

Bubble公式もそのように明記しています。

You only pay for the actual consumption = “実際に消費した分だけお支払いいただきます”

勿論、これは公開されているサービスや実運用システムを停止させないため、Bubbleが用意した最上級の優しさ且つ柔軟なシステムだと思いますが、開発側は最も気をつけなければいけない事項です。

例えばBubbleでループ処理を実装したとしましょう。

明示的な終了条件がない、もしくは終了条件がない場合、プログラムは永遠に実行されます。

（界隈では”無限ループ”と呼ばれています)

Bubbleも同様です。無限ループが発生するとWUは上限無しに消費され続けます。

もし無限ループに気づかず放置してしまったら…

ジ エンド

です。

実際に1ヶ月で数百万もの超過請求を受けてしまった事例もあるようです。

サービスが落ちない → 安心 で終わらず、

サービスが落ちない = 安心 → 月額料金は想定内で収まっている ということまで思考を回すことが大事ですね。

※契約プランから超過しない設定にすること(Overages: Disabled)は可能です。 が、もし超過した場合、それ以上Bubbleアプリが動作しなくなるのでオススメしません…

無限ループ時の対応と対策

やることは3つです。

1. 冷静にスケジューラーを止める
2. 原因の特定と修正
3. 再発防止の対策

まずは冷静になりましょう。「無限ループ発生してる！やばい、200万の高額請求ががが！！！」と叫んでいるうちもWUは消費させ続けます。

冷静にschedulerを確認して”Pause tasks”でループ処理を止めます。

次に原因の特定です。 大抵「Backend Workflow」で「API workflow」の条件を設定が間違っている or 漏れが原因である可能性が高いので、ループ処理で止めたworkflowの条件をよく確認し適切に修正します。

最後に再発防止の対策です。

• Backend Workflowの慎重な設計、検証環境上でのダブルチェック
• リソース使用量の監視強化、定期的なWU使用量のチェックとアラート設定
• 「Setting up a notification」を活用して独自のWU制限を設定、超過時のメール通知

※無限ループが発生してしまった原因によって対策は異なりますが、上記3つの対策は必須です。

また偶発的に発生する無限ループに対して、Bubble公式より対策が施されました。こちらもぜひ活用しましょう！

Infinite recursion protection: The most common cause of accidental workload spikes is a runaway recursive workflow. Infinite recursion protection lets you set an app-level limit for recursive workflows in the API tab in your app settings, even if you forget to add a workflow-level constraint. As of July 1, 2024, all new Bubble apps will have this feature enabled with a default limit of 10. Apps created before July 1 won't have any limit applied automatically, but you can enable and customize the limit any time.

どんなプランがおすすめ？

適切な料金プランを選ぶためには、自分のアプリのWU量を理解することが重要です。

とてもありがたいことにBubbleにはWUの測定・分析するための「App Metrics」が設けられています。”WUの総量”や”日毎の数量”、”カテゴリごと(検索、API、　Data Trigger etc)の数量”といった具合で詳細な分析が可能です。

※WU数はライブ環境と開発環境の合計値になります。

• [A]棒グラフ: 総量および指定期間の消費量

  

• [A’]円グラフ: [A]で選択した総量をカテゴリ別で表示
  • さらに円グラフを該当範囲をタップするとより詳細なデータが表示され、最終的にはそのWUを消費したWFまで追うことがでます！素敵！

    

• [B]折れ線グラフ: 時間別の消費量
  • 最近のワークロードや時間がシビアなワークロードの状況を確認して、それぞれがどんな影響を与えているのか詳しく知ることができます。

    

• [C]棒グラフ: 月別のWU消費量(12ヶ月固定)

  

プロダクトの規模から必要なプランを選択 ⇒ WUを想定

こればかりはサービスやシステムの規模によって異なりますが、ある程度想定は可能です。 例えば、以下の指標を基にBtoCのマッチングサービスをリリースしたいとしましょう

• アプリの複雑さと機能要件:
  • 複雑さ: 中〜高
  • 機能要件:
    1. 求人情報の掲載機能
    2. 求職者と企業のプロフィール管理
    3. マッチングアルゴリズム（求職者と求人の自動マッチング）
    4. チャット機能（リアルタイム通信）
    5. 応募管理と進捗トラッキング機能
    6. 評価とレビューシステム
    7. ダッシュボード（企業向けと求職者向け）
• ユーザー数とトラフィック:
  • 予想ユーザー数: 初期で約10,000人（求職者と企業の合計）
  • 同時接続ユーザー: ピーク時で約1,000人
  • 月間PV: 約100,000ページビュー
• ストレージとデータ容量:
  • ストレージ必要量: 200GB（プロフィール画像、履歴書、求人情報など）
  • データベースエントリ: 20万件の求人情報とプロファイルデータ
  • ファイルサイズ: 履歴書や企業資料（平均5MB）
• パフォーマンスとスケーラビリティ:
  • 初期ロード時間: 2秒以下
  • スケーラビリティ: 年間で3倍のユーザー増加を見込む

前述の通り、Bubbleの処理にはWUを消費します。

どの処理にどのくらいのWUを消費するのかをBubble Docsから一部抜粋して以下にまとめました。

各種想定値とWUの消費数を超ざっくり出すと

1. ページロード: 100,000 WU
2. データベース操作: 14,000 WU
3. ワークフロー実行: 1,500,000 WU
4. API呼び出し: 600,000 WU
5. チャット機能: 1,500,000 WU
6. 検索機能: 600,000 WU

合計WU消費量: 4,314,000 WU/月 となり、最低でも “Growth”プラン(WU:250k) + TIER4 (WU: 6M)を選択する必要があると考えることができます。

またBubbleのプランは即日変更が可能なため、

1. 初期段階: 開発中心のため “Starter”プラン(WU:175)
2. リリース段階: TIER3 (WU: 2.5M)を追加
3. 保守段階: 大規模展開を想定して “Growth”プラン(WU:250k) + TIER4 (WU: 6M)の構成へ

といった段階的で柔軟な選択もできるため、まずは“Starter”で走り出し、その後の開発状況と将来的な成長を見据えたプラン選定を行うことが重要であると考えています。

まとめ

本記事では、WUの基本的な概念から、料金プラン、従量課金のリスク、最適なプランの選び方までご紹介しました。いかがでしたか？

Bubble.ioのWUについて基本的な理解を深め、アプリ運営における効率的なリソース管理を目指す方に少しでも役立つ情報が提供できればと思い6時間ほど練りながら書き殴りました( ｀ー´)ノ

Bubble.ioは、ローコードでありながら、非常に強力なツールです。正しく使えば、アイデアをすぐに形にし、迅速に市場に投入することができます。

もちろん、学ぶべきことや注意すべき点はたくさんあります。特にWUのようなリソース管理は、コストを抑えつつパフォーマンスを最大化するために重要です。新しい情報や技術が日々進化しているこの分野で、私たちも常にアップデートを続け、より良いアプリを作り上げていきましょう！

株式会社Biz Freak では、Bubbleやプロコードのハイブリッドで通常比3倍のスピードで新規事業開発を行っています。最新のテクノロジーを活用して事業の成長に直接貢献したい方、効率的なリソース管理とパフォーマンスの最適化を通じて、リスク管理分野で圧倒的な成長を感じたい方、ぜひ私たちのチームで一緒に働いてみませんか？

👉 https://bizfreak.co.jp/recruit