概要
さくらのクラウド AppRun Dedicated （専有型）において、
frontend / backend を同一クラスタに配置して運用していたところ、
- 稼働コンテナ数が 0 になる
- LB が
no available serverを返す - backend が 想定外の ASG に配置される
といった 原因が非常に分かりづらい不具合が連鎖的に発生しました。
調査の結果、根本原因は
👉 AppRun Dedicated における ASG とクラスタの仕様理解不足。
本記事では、
- なぜこの問題が起きたのか
- なぜ「クラスタ分割」が唯一の解決策だったのか
- 今後同じ構成を組まないための設計指針
を 実例ベースでまとめます。
発生した事象
実際に起きていた状態は以下です。
ss-backend-prdがss-frontend-asg上で起動- backend 用 ASG は ワーカが起動しているのにアプリ数が 0
- 結果として Load Balancer が
no available serverを返却
GUI 上では一見問題が分かりづらく、
**「起動しているのに通信できない」**状態が続きました。
原因：ASG は「専用実行先」ではない
ここが最大の落とし穴です。
AppRun Dedicated における ASG（Auto Scaling Group）は、
同一クラスタ内のワーカープール
として扱われます。
つまり、
- ASG = アプリ専用の実行先
- この ASG にはこのアプリだけが載る
という保証は 一切ありません。
実際に起きた内部状態
- frontend 用 shared ワーカに backend がスケジューリングされる
- backend 用 private ワーカが空く
- 想定していたネットワーク要件（FW / 公開範囲）が崩壊
- ヘルスチェック不整合 → コンテナ 0 扱い
という 設計上の前提崩れが発生しました。
対応：やるべきことは「クラスタ分割」一択
1) クラスタを用途別に完全分割
用途が異なるアプリは 必ずクラスタを分ける。
- Front 用クラスタ
ss-dedicated-front - Back 用クラスタ
ss-dedicated-back
これにより、
- ASG 混在
- 想定外スケジューリング
を 物理的に排除できます。
2) Terraform / デプロイ構成の見直し
以下の変更を実施しました。
- AppRun Dedicated モジュールに
infra_componentsを追加 - production 環境で frontend / backend を完全に別モジュール化
- dedicated deploy を front / back で個別実行
👉
**「同一 apply で一緒に作らない」**のがポイントです。
3) Let’s Encrypt（HTTP-01）の落とし穴
クラスタ作成時の注意点です。
- 80 / 443 両方を開けないと HTTP-01 が通らない
- 80 を閉じた状態だと クラスタ作成自体が 400 エラーで失敗
「本番は 443 しか使わない」
でも 作成時だけは 80 が必須 です。
重要な学び（設計指針）
- ASG はアプリ専用実行先ではない
- 用途が違うならクラスタは必ず分ける
- AppRun Dedicated は
「クラスタが境界」 - Let’s Encrypt を使うなら
80 / 443 の両開放が必須 - LB 再作成により IP が変わるため DNS 更新が必要
現在の構成方針（推奨）
- Frontend
ss-dedicated-front - Backend
ss-dedicated-back - backend は 443 のみ公開
- DNS は Cloudflare（DNS only）運用
よくある質問（AppRun Dedicated / クラスタ設計）
Q1. AppRun Dedicated で稼働コンテナ数が 0 になる原因は何ですか？
A. 多くの場合、ASG とクラスタ設計の前提ズレが原因です。
AppRun Dedicated の ASG はアプリ専用の実行先ではなく、同一クラスタ内のワーカープールとして扱われます。そのため、Front / Back を同一クラスタに配置すると、想定外の ASG にアプリが配置され、結果として「稼働コンテナ数 0」と判定されることがあります。
Q2. AppRun Dedicated の ASG はアプリごとに固定されますか？
A. いいえ、固定されません。
ASG は「アプリ専用」ではなく、同一クラスタ内で共有される実行リソースです。用途の異なるアプリを同居させると、意図しない ASG にスケジューリングされる可能性があります。
Q3. AppRun Dedicated で no available server が出るのはなぜですか？
A. バックエンドアプリが ネットワーク要件を満たさない ASG に配置された場合に発生します。
コンテナ自体は起動していても、ヘルスチェックが通らず、Load Balancer 側では「利用可能なサーバーが存在しない」と判定されます。
Q4. Frontend と Backend は同一クラスタに配置してはいけませんか？
A. 原則として分けるべきです。
AppRun Dedicated においては、クラスタが最小の隔離単位です。Front / Back のようにネットワーク要件や公開範囲が異なるアプリは、クラスタ分割しないと不安定化リスクが高いです。
Q5. ASG を分ければクラスタ分割は不要ですか？
A. 不要ではありません。
ASG を分けても、同一クラスタ内であれば混在は起きます。
用途が異なる場合は ASG 分離ではなくクラスタ分割が必須です。
Q6. AppRun Dedicated で Let’s Encrypt が取得できない原因は？
A. クラスタ作成時に 80 / 443 の両方が開いていない可能性があります。
HTTP-01 チャレンジでは 80 番ポートが必須で、80 を閉じたままだと クラスタ作成が 400 エラーで失敗します。
Q7. クラスタを作り直すと DNS 設定は必要ですか？
A. はい、必須です。
クラスタ再作成により Load Balancer の IP が変更されるため、DNS レコードの更新を忘れると疎通しません。Cloudflare 利用時は DNS only 設定を推奨します。
Q8. AWS ECS と同じ感覚で設計しても大丈夫ですか？
A. 危険です。
ECS の Service / Task 分離の感覚で AppRun Dedicated を設計すると、ASG・クラスタ周りで事故りやすいです。AppRun Dedicated では **「クラスタが境界」**という前提で設計する必要があります。
AppRun Dedicated では **「クラスタが境界」**という前提で設計する必要があります。
まとめ
AppRun Dedicated は便利ですが、
ASG / クラスタの設計思想を AWS 感覚で扱うと事故ります。
- ECS の Service 分離 ≠ AppRun Dedicated
- ASG 分離 ≠ 安全
👉 クラスタが最小の隔離単位
この前提で設計すると、
今回のような「見えない不具合」は避けられます。