少し前から、ODCのコンピュータリソース制約について、公式サイトに公開されていた。
制約の情報はあるものの、自分の環境でどれだけ使っているかはわからなかったが、今日リリースされた機能で確認可能になったようだ。
まずは、情報ソースへのリンクをまとめ、次にドキュメントを追っていき、気になるところをメモしていく。以下、全て2025/03/12時点の情報に基づく。
情報ソース
リソース制約について（Evaluation Guide）
Vertical and Horizontal Scalability for Apps > ODC Resource Capacity Fair Use Limits | OutSystems
リリース情報
Product Releases and Updates:
ODC Resource Monitoring | OutSystems
Release Notes:
OutSystems Developer Cloud - OutSystems Support
ドキュメント：リソース制約のモニタリング機能
Monitor ODC resource capacity - ODC Documentation
モニタリング機能の位置
ODC Portalを開き、画面左上のドロップダウンを展開。
「Manage subscription」を開く。
Overviewタブ内に、リソース種類ごとに現在の使用量と契約上の上限が表示される。
リソース種類をクリックすると、その内訳をStageごとに表示できる。
Compute instances
Evaluation Guideから
Comput Instance数=AppのContainer数 + Timer数 + Workflow数
これがデフォルトでは15まで。HA (High Availability) を契約していたら2倍の30。
150 AO Packを買うごとに上限は5 (HAなら10増える）。
メモ
以下、ドキュメントから。
Each app, workflow, or timer consumes at least one container when running. In subscriptions with high availability, apps consume at least two containers.
この記述から、HAを契約していると上限が倍になるのは、どのAppも最低2つのコンテナで動作するためと推測できる（つまり同時に動かせるAppの数はHAを契約しても増えない）。
Remember that multiple instances of the same workflow revision share the same resources, but different revisions may consume different resources.
Workflowについては、Revisionごとに1 Computer Instance。つまり違うRevisionで終了していないWorkflow Instanceが滞留していると、Compute Instance消費も大幅に増えてしまう。
As demand increases, additional containers are added dynamically. When demand decreases, ODC scales down the containers accordingly. To learn more, refer to auto-scaling in cloud-native architecture.
完全に明確とは言えないが、おそらくあるAppの負荷が増える→オートスケールしてPod数が増える→全Podがそれぞれ1 Compute Instanceとしてカウントされる、という意味と思われる。
Workflows and timers consume resources only when running.
WorkflowとTimerがリソースを消費するのは、実行中のみ。
とはいえ、Timerは長時間実行することがある（＝その間は消費したまま）し、Workflowは待っている間はどうなるだろうか、等懸念はある。
この書き方をするということは、もしかして、Appのコンテナは実行中以外もリソースを消費するんだろうか。
Database Storage
Evaluation Guideから
Stage全体で500GB。だいぶ少ない印象。
（ODCはマイクロサービスとはいうが、バックエンドのDBは１インスタンスで、全Appが1つのDBを見ている）
Custom Code Execution Duration
Evaluation Guideから
C#で作成するExternal Logicの1日毎の実行時間合計の制約。
1日に30,000秒。
メモ
30,000秒 = 500分 > 8時間、なのでそう簡単にオーバーしないだろうと思ったが、実際に計測された値を見ると結構危ない。
大容量、もしくは高頻度の処理をExternal Logicで作るときはここをよく見ておく必要がある。
リソース上限に達すると何が起こるのか
Compute instances: If you reach the container limit, you cannot
Publish new apps
Update existing ones with new revisions,
Run workflows and timers.
Compute Instanceが上限に達している状態では、Publish、WorkflowやTimerの実行ができなくなる。結構クリティカル。
Custom code execution duration: Calls to custom code libraries can cause errors and fail until the next day. This can lead to runtime errors in consumer apps.
External Logicは翌日までエラーになる。これもクリティカル。
Database compute and database storage: Apps can experience performance issues, such as slower response times or timeout errors when accessing the database if there is insufficient capacity to accommodate all of the requests.
DB系はパフォーマンスが落ちるだけ。その結果としてエラーになることはある。
感想
TimerとWorkflowは設計時の考慮事項が増える。
気軽に作っていると、Compute Instanceの消費量が増え過ぎてしまう。
Timerについてはスケジューリングが、Workflowについては世代管理が重要になりそう。
TimerとWorkflowもカウントされることを考えると、割り当て数（初期15、AO150毎に+5）は少ない印象。スケールアウトされたAppは、スケールアウトされたApp数分だけカウントされるのだろうが（それ自体は最も話）、その場合、どのAppがどの程度の負荷でどこまでスケールアウトされるか事前にわからないと、都合が悪い。