ODCのリソース制約

少し前から、ODCのコンピュータリソース制約について、公式サイトに公開されていた。
制約の情報はあるものの、自分の環境でどれだけ使っているかはわからなかったが、今日リリースされた機能で確認可能になったようだ。

まずは、情報ソースへのリンクをまとめ、次にドキュメントを追っていき、気になるところをメモしていく。以下、全て2025/03/12時点の情報に基づく。

# 情報ソース
## リソース制約について（Evaluation Guide）
[Vertical and Horizontal Scalability for Apps > ODC Resource Capacity Fair Use Limits | OutSystems](https://www.outsystems.com/evaluation-guide/scalability/architecture/#capacity-fair-use-limits)

## リリース情報
Product Releases and Updates: 
[ODC Resource Monitoring | OutSystems](https://www.outsystems.com/product-updates/odc-compute-addons/)

Release Notes: 
[OutSystems Developer Cloud - OutSystems Support](https://success.outsystems.com/support/release_notes/outsystems_developer_cloud_releases/outsystems_developer_cloud/#outsystems_developer_cloud_2025-03-12)

## ドキュメント：リソース制約のモニタリング機能
[Monitor ODC resource capacity - ODC Documentation](https://success.outsystems.com/documentation/outsystems_developer_cloud/getting_started/monitor_odc_resource_capacity/)

# モニタリング機能の位置
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がどの程度の負荷でどこまでスケールアウトされるか事前にわからないと、都合が悪い。