制限

現在、すべての組織は Free プランです。Pro 列は、セルフサーブ課金が始まった際にプランがどう変わるかを示しています。以下の制限はすべて実際にサービスによって強制されますが、1 つだけ例外があります。データベースサイズは計測・通知されますが、上限に達しても書き込みを拒否することはありません — 代わりに何が起こるかは以下で説明します。

データベースのサイズ制限はエンジンの制限ではなく、運用上の制限です。バックアップは直前のバックアップ以降のコミットのみを保持するため、バックアップのコストはデータベースの大きさではなく書き込み量に応じて決まります — これにより、上限を無料プランで 150 MB から 500 MiB に、Pro で 8 GiB に引き上げることができました。

現在のところ、上限に達しても書き込みがブロックされることはありません。90% に達すると db_near_cap 通知を送信します。詳細は サイズ上限 を参照してください。

スケジュール実行では、1 回の実行の実時間にも上限があり、その上限はプランではなくスケジュールから決まります。1 時間未満の場合は 30 秒、1 時間以上の場合は 5 分です。スケジュール実行 を参照してください。

ファイルストレージのクォータを超えた後も、読み取り・一覧取得・削除は引き続き機能します。 使用量を減らせるよう、制限されるのは書き込みのみです。

ワーカーのメモリはプロジェクトごとに上限があり、その上限はプロセスが同時に保持しているものすべて — お客様のコード、組み立て中のレスポンス本文、データベースエンジンの作業メモリ — を含みます。上限を超えるとプロセスは停止して起動し直します。その瞬間に処理中だったリクエストは失敗し、次のリクエストは新しいプロセスで実行されます。runlot logs に worker exceeded the memory cap (512 MiB) and was restarted の行が残るため、メモリが原因の再起動であることをクラッシュから推測する必要はありません。よくある原因は、ファイル全体やクエリ結果全体をメモリに載せたままにすることです。ストリーミングに変えてみてください。

プロジェクト数の上限に達した場合

Error [project_limit] the free plan allows up to 3 projects (currently 3)

レスポンスボディには現在の上限と使用量が含まれます。

{ "error": { "code": "project_limit", "message": "…", "details": { "limit": 3, "count": 3, "plan": "free" } } }

使わなくなったプロジェクトを整理するか、より多く必要な場合は [email protected] までお知らせください。

通知

制限に近づいたり超えたりした場合、組織の admin に通知します。

同じ種類の通知は24 時間に最大 1 回まで送信されます。これにより、超過が繰り返し発生しても受信トレイがあふれることはありません。

ダッシュボードの組織ページで、直近の通知を確認できます。メールアドレスを登録していないアカウントの場合、通知が表示されるのはダッシュボードのみです。

リクエストと CPU 時間

どちらもプロジェクト単位ではなく組織単位でカウントされ、どちらも強制されます。

• Free プランでは、1 日のリクエストまたは CPU の予算を超えると、その UTC 日の残り時間は配信が停止します — 課金に切り替わることはありません。リクエストには 429 budget_exhausted と、次の UTC 00:00 を指す Retry-After ヘッダーが返されます。
• Pro では、含まれる分を超えた使用量は課金され、月間の支出上限がデフォルトで有効になっています。その上限に達すると、同じ 429 が発生します。

意図的に例外としている点が 2 つあります。psql・runlot pg shell・各種ドライバーによるデータベース接続はこの制限でブロックされないため、データは常に取り出せます。また、静的アセットを配信するリクエストも他のリクエストと同じようにカウントされます — そのため、Free の割り当てでまかなえるページ読み込みは数字が示すより少なくなります。

強制は即時ではありません。使用量は 1 分ごとに報告され、その判定は次のマップポーリングでトラフィックのフロントエンドに反映されるため、制限を超えても2〜3 分間は配信が続くことがあります。この猶予は課金対象にはなりません。

runlot usage
runlot usage --hours 168

プロジェクト概要画面のグラフ

プロジェクトの最初の画面は、保存している値を1つの数字にまとめずにそのまま描きます。測定値1つにグラフ1つで6つ、期間は 24時間・7日・30日 から選びます。

描き方についていくつか知っておく価値があります。信頼できるグラフとそうでないグラフの違いがそこにあります。

• 7日と30日では、件数のグラフが1日単位にまとまります。 実際にある上限が1日単位なので、1日分の上限を時間別の棒の上に破線で引くと、棒が決して届かない線になります。データベースサイズはその日の最後の観測値を使い、決して加算しません。サイズを時間ごとに足すと、同じストアを1日に24回数えることになります。
• 欠けた時間帯は空白のままです。 報告が来なかった時間帯には行を書かず、グラフも埋めません。0が平らなことと「報告が来なかった」ことは別の事実であり、ノードが黙ったプロジェクトはそう見えるべきです。
• 縦の破線はデプロイです。 重ねるとどのバージョンかが出ます。応答時間グラフの段差が目印のちょうどそこから始まっていれば、たいていそのリリースです。目印を置く理由がそれです。
• 応答時間はまとめません。 パーセンタイルは加算できないため、1日の中央値はその日の各時間の中央値からは求まりません。このグラフはどの期間でも時間単位の点を保ち、上の代表値はサーバーが期間全体を一度に計算した値です。
• エラー率には分母が必要です。 期間内にリクエストがなければ 0.00% ではなくダッシュを表示します。

すべてのグラフの下に、同じ数字を文字で見せる「データ表を表示」があります。

どこまで前に復元できるか

バックアップは頻繁に取得され、それぞれ変更分のみを含むため、保持ウィンドウ内の任意の時点に復元できます。無料は7日、プロは30日です。保持期間がプランによって異なるのは、コピーをオフサイトに保管するコストによるものです。

復元は保持期間内の任意のコミットに着地します — バックアップ、コミット id、時刻のいずれかで指定します。バックアップと復元を参照してください。

リージョン

現在利用できるリージョンはソウルの1つのみです。アプリケーションとデータベースは同じマシン上で実行されるため、env.db の呼び出しにネットワークの往復は発生しません。