Skip to main content
Square Cloud は、分離性、安定性、そしてアプリケーション間でのインフラストラクチャの公平な分配を確保するために、コンテナベースのリソース制限を実装しています。

​
最小リソース要件

Square Cloud プラットフォーム上でホストされる各プロジェクトには、最適なパフォーマンスを確保するための特定の最小リソース要件があります。
  • ボット: 最小 256 MB の RAM が必要です。
  • ウェブサイト: 最小 512 MB の RAM が必要です。
  • キャッシュデータベース: 最小 512 MB の RAM が必要です。
  • 一般データベース: 最小 1 GB の RAM が必要です。

​
なぜ RAM の最小値が存在するのか？

コンテナには必須の運用オーバーヘッドがあります。言語ランタイム、OS ライブラリ、そしてネットワークバッファです。256 MB を下回ると、カーネルの OOM Killer が起動時やガベージコレクション中にプロセスを終了させる傾向があり、アプリケーションが実行不可能になります。 技術的な影響:
  • 各コンテナは 1 つの動的 IPv4 と NVMe ストレージの IOPS を消費します
  • 最小割り当てはリソースの断片化（ノイジーネイバー効果）を防止します
  • 日次 snapshot の計算式: (Total RAM / 256) * 2（概算。上位プランでは、プランごとの正確な許容数がこれより少ない場合があります）
影響データ: 256 MB の最小制限を実装した後、アプリケーションの安定性が劇的に向上し、OOM（Out of Memory）によるクラッシュ率が 97.7% 削減されました。

​
CPU の割り当て

簡単に言うと、CPU は設定された RAM に基づいて割り当てられます。RAM を増やすと、通常はより多くの vCPU が付与されます。

​
ルール

​
シングル vCPU プラン

1 vCPU プランのアプリケーションは、スロットリングなしでフルキャパシティを受け取ります。

​
マルチコアプラン（≥2 vCPU）

  • パフォーマンスの下限: ≥512 MB の RAM を持つアプリケーションは、少なくとも 2 vCPU を受け取ります。
  • 比例スケーリング:
    • Hobby（≤2 vCPU）: 512 MB の RAM ごとに +1 vCPU
    • Standard / Pro / Enterprise: 1 GB（1024 MB）の RAM ごとに +1 vCPU

​
例

​
スロットリングと安全制限

システムはプランの vCPU 制限を強制し、分配を公平に保つためにレベリングを適用します。短期的な弾力性により、スパイク時に追加の vCPU が付与されることがありますが、保証されるものではありません。 禁止されている CPU の使用:
  • 暗号通貨のマイニング
  • 許可のない、無制限で集約的な ML ワークロード
  • 意図的なリソースの悪用
これらの使用は、不正利用、暗号通貨マイニング、スパムに関するポリシーに違反します。これとは別に、すべての vCPU を使い続けるアプリケーションは LACK_OF_CPU で停止されます。

​
ネットワークの制限

すべてのアプリケーションには、アップロードとダウンロードで同じ専用帯域幅が割り当てられ、割り当てられた RAM に比例してスケールします: 256 MB ごとに +50 Mbps。帯域幅はコンテナ専用に確保され、他のユーザーと共有されることはなく、トラフィックが計測・課金されることもありません。 いくつかの例: 継続的に高トラフィックなワークロードには、サポートが専用クラスターを用意できます。 起動ターボ。 起動のたびに、プランの帯域幅を大きく上回るブーストがかかります。依存関係のインストール、モデルのダウンロード、キャッシュの再構築は、割り当てに関係なく高速です。 データベースには、RAM に応じた専用の帯域幅が双方向で割り当てられます。

​
ストレージの制限

すべてのプロジェクトには、デフォルトで 10 GB の NVMe ストレージが付与されます。 特徴:
  • エンタープライズグレードの NVMe
  • デプロイと再起動をまたいで永続化
  • 高い IOPS とスループット

​
制限超過ステータス

アプリケーションがリソースを超えると、Square Cloud はアプリケーションを停止し、理由を示す [SQUARE-SHIELD] の行をログに書き込み、メールでお知らせします。この表はほかのページからリンクされる参照先です。解決方法は表の下にあります。 アラートメールについては、ヘルプセンターのダウンタイムアラート: RAM、CPU、リクエストのブロックで説明しています。

​
LACK_OF_RAM

アプリケーションが割り当てられた RAM に達したため、ホストを保護するためにプロセスが停止されました。 修正方法:
  1. プロファイラでメモリリークを見つける（Node.js: --inspect、Python: memory_profiler）。Node.js のメモリリークを参照してください。
  2. メモリ内キャッシュを削減するか、キャッシュを Redis に移動する。
  3. ダッシュボードでアプリケーションの RAM を増やすか、設定ファイルの MEMORY を引き上げる。

​
LACK_OF_CPU

アプリケーションがすべての vCPU を長時間使い続けたため、プロセスが停止されました。 修正方法:
  1. CPU のホットスポットをプロファイルする（Node.js: 0x、Python: cProfile）。CPU 使用率 100%: 最適化のヒントを参照してください。
  2. ホットループ、DB クエリ、I/O バウンドの処理を最適化する。
  3. RAM を増やしてより多くの vCPU を得る（CPU の割り当てを参照）。
  4. 重い処理を非同期ワーカーやバッチジョブにオフロードする。
トレードオフ: CPU を得るために RAM を増やすとコストが上がります。コードの最適化がスケールアップよりも安価かどうかを見極めましょう。

​
CONTAINER_TEMPORARILY_SUSPENDED

ログに [SQUARE-SHIELD] ABUSE_REQUESTS が表示されました。アプリケーションが Discord や squareweb.app のサイトに、不正な頻度でリクエストを送り続けたことを意味します。原因はほとんどの場合、実際の人気ではなく、無限ループ、待ち時間のないリトライ、キャッシュの欠如です。アプリケーションは停止され、ブロックが解除されるまでは、起動しようとすると CONTAINER_TEMPORARILY_SUSPENDED で失敗します。 修正方法:
  1. メールと直近のログを読み、リクエストを送っているコードを特定します。
  2. 取得したデータをキャッシュし、リトライの間に待ち時間を入れ、呼び出す API のレート制限ヘッダーに従います。Discord API のレート制限を参照してください。
  3. 少し待ってから、アプリケーションをもう一度起動します。