🚀 Workloadとは
Workloadは、Bubbleプラットフォーム上でアプリをホスト、実行、スケールするために必要なサーバーリソースを表します。これはWorkload Units（WU）という単位で測定されます。
🎯 従来の複雑な指標を統一
CPU使用率、負荷分散、帯域幅消費など、従来のソフトウェア開発で管理すべき複数の技術指標を、Workloadという単一の指標に統合しました。
⚡ パフォーマンス監視を簡素化
単一の指標に集中することで、優れたアプリ作成に専念でき、残りはBubbleが処理します。
📈 最適化機会の特定
どのプロセスがリソースを消費しているかがわかるため、必要に応じて最適化できます。
💡 Capacityとの違い
以前のCapacityは「高速道路の制限速度」のようなもので、アプリが最も必要な時にスロットリングされていました。Workloadは「車の燃料」のように機能し、アプリが必要な速度で動作するためのリソースを測定します。
📊 Workload管理の3ステップ
Understanding
（理解）
Workloadの基本概念、計算方法、アクティビティタイプを把握する
Tracking
（追跡）
App MetricsとServer Logsを使用してWorkload使用量を測定・監視する
Optimizing
（最適化）
データを分析してページロード、ワークフロー、検索を最適化する
⚙️ Activity Types（アクティビティタイプ）
Bubbleでは12種類の異なるアクティビティタイプを追跡し、それぞれが月間総Workloadに貢献します。これらは複雑な操作の構成要素として機能します。
🏗️ 構成要素の概念
アクティビティタイプはアプリ機能の基本構成要素です。特定の操作の総コストは、それを実行するために必要な全ての基盤アクティビティタイプの合計になります。
| カテゴリ | アクティビティ | WU | 説明 |
|---|---|---|---|
| フロントエンド | ページ読み込み | 0.15 | ページHTMLの読み込み |
| プラグイン呼び出し | 0.2 | サーバーサイドプラグインアクションへの各呼び出し | |
| データベース | データベース検索 | 0.3 | 基本検索操作 |
| データ取得（文字単位） | 0.000003 | データベースから返される各文字 | |
| データ取得（アイテム単位） | 0.015 | データベースから返される各アイテム | |
| 集約クエリ | 0.2 | count、sum、averageなどの集約操作 | |
| アイテム作成・変更 | 0.5 | データベースへの書き込み・変更 | |
| アイテム削除 | 0.1 | データベースからの削除 | |
| バックエンド・API | サーバーサイドワークフロー | 0.6 | バックエンドワークフローアクションの実行 |
| 外部API呼び出し | 0.1 | 外部APIへの呼び出し | |
| インバウンドAPI | 0.01 | アプリのData and Workflow APIへの呼び出し | |
| APIデータ送受信 | 0.000003 | APIを介して送受信されるバイト数 |
🧮 Workload計算方法
🎫 テーマパークのメタファー
Workloadテーブルの値を「テーマパークの入場券」として考えてください。チケットでパークに入れますが、パーク内の各アトラクションには追加料金がかかる場合があります。操作の複雑さによって最終的な価値が決まります。
📝 例：データベースアイテムの変更
基本コスト： 0.5 WU（入場券）
追加コスト： 検索操作、データ取得など、実際の作業内容に応じて加算
🔍 例：集約クエリ
基本コスト： 0.2 WU（集約処理）
追加コスト： データ検索 0.3 WU + データ送信コスト
🖥️ クライアントサイド vs サーバーサイド処理
Workloadは基本的にサーバーでの作業を測定します。クライアントサイド（ユーザーのデバイス）で実行される操作は、サーバーとの通信が発生しない限りWorkloadを消費しません。
🖱️ クライアントサイド操作（無料）
- カスタム状態の設定
- 要素の表示/非表示
- フォーム入力の処理
- アニメーションと遷移
- 要素へのスクロール
- アラートとメッセージの表示
- 入力フィールドのリセット
🏗️ サーバーサイド操作（WU消費）
- ユーザー認証（ログイン/サインアップ）
- データベース検索とクエリ
- メール送信
- データの作成、変更、削除
- 外部API呼び出し
- ファイルのアップロードと削除
- スケジュールされたワークフロー
⚠️ 注意：混合操作
クライアントサイド操作でも、条件やアクションがサーバーサイドデータを参照する場合はWorkloadが発生します。例：要素の表示/非表示アクションに、サーバーをチェックする条件が含まれている場合
📈 Workloadの追跡とモニタリング
App Metrics
（履歴データ）
特定期間の全データを表示し、Development環境とLive環境を分けて追跡
Server Logs
（リアルタイム）
操作発生から数秒後の個別操作のWorkload消費をリアルタイムで確認
Workload通知
異常な高WU消費の自動検出とカスタム基準による通知設定
🎯 App Metricsの活用
App Metricsダッシュボードでは、円グラフで各アクティビティタイプの消費割合を確認し、クリックして詳細なワークフローや式まで掘り下げることができます。これにより、最も多くのWorkloadを消費している箇所を特定できます。
🎯 Workload最適化
⚖️ UXとのバランス
Workload最適化は重要ですが、ユーザーエクスペリエンスを犠牲にしてはいけません。「燃料効率」と「スムーズな運転体験」のバランスを取ることが重要です。
🔧 最適化フレームワーク
🔄 Complexity（複雑さ）
プロセスの複雑度を評価します。ネストされた検索、高度なフィルター、複数のサブ式を避けることが重要です。
🔁 Repetition（繰り返し）
プロセスの実行頻度を評価します。ページロード時の実行、タイマーイベント、頻繁に呼び出される検索を注意深く管理します。
📊 Volume（データ量）
データベースから返されるデータ量を評価します。構造化データと非構造化データ、大量のテキストデータに注意が必要です。
✅ 最適化チェックリスト
📄 ページロード最適化
- Go to pageアクション： 同じページ内での使用でも「Page is loaded」イベントが発生します
- データロード： ページロード時ではなく、ユーザーインタラクション後に読み込みを検討
- 条件付きロード： 見えない要素がデータを読み込まないよう条件を設定
🔍 検索最適化
- ネスト検索回避： 一つの検索に別の検索を含める設計を避ける
- 高度フィルター制限： :filteredや:advancedオペレーターの使用を慎重に
- データ量管理： 構造化データ（短いデータ）を優先し、非構造化データ（長いテキスト）を制限
⚙️ ワークフロー最適化
- アクション数削減： サーバーとやり取りするアクションの数を最小限に
- 頻度管理： 「Page is loaded」「Do every X seconds」イベントを慎重に使用
- リスト操作： 頻繁なリスト変更を避け、必要時は「Make changes to a list」を優先
🔧 バックエンドワークフロー最適化
- バルク操作： 再帰ワークフローより「Schedule API workflow on a list」を優先
- データベーストリガー： 頻繁な発動を避ける条件設定
- API認証： 不正アクセス防止のため認証を必須に
🎯 まとめ
Workloadは複雑なインフラ指標を単一の管理しやすい指標に統合したBubbleの革新的なアプローチです。理解→追跡→最適化の3ステップを通じて、効率的で高性能なアプリケーションを構築できます。
🚀 アプリの成長に対応
Workloadベースの価格設定により、アプリの成長に合わせて柔軟にリソースを追加できます。
🎯 開発の焦点
複雑なインフラ管理ではなく、優れたアプリケーション作成に集中できます。
⚖️ バランスの重要性
Workload効率とユーザーエクスペリエンスの適切なバランスを維持することが成功の鍵です。
株式会社Spovisorではノーコード・ローコードツールを使ったシステム開発、アプリ開発を実施しています。
要件定義から伴走して支援し、安価・スピーディー・柔軟な開発を行います。無料でご相談もお受けしております。