アプリ用サーバーは、月額料金だけでは比較できません。
デプロイ、OS更新、データ保存、監視、バックアップのどこまでを提供者が担うかで、必要な作業が変わります。
アプリが止まったときの復旧目標を決め、それを守れる構成から候補を絞ります。
アプリ開発の目的に合う相談先は、外注と学習を目的別に分けた相談ガイドにまとめています。
| 候補 | 開発側の主な作業 | 向くケース |
|---|---|---|
| 共用レンタルサーバー | 提供範囲内の配置と設定 | 制限内で動く小さなWeb機能 |
| PaaS、管理実行環境 | コード、設定、アプリ監視 | 独自APIと早い配布を両立する |
| BaaS | データ設計、権限、端末側の連携 | 認証とDBが中心のアプリ |
| VPS、IaaS | OSより上の構築、更新、監視 | 独自構成とミドルウェアが必要 |
四つのサーバー方式で運用範囲を比べる
共用レンタルサーバーは固定料金で始めやすい一方、常駐プロセス、利用できるランタイム、自動拡張などの条件を個別に確認する必要があります。
「レンタルサーバーである」だけでスマホアプリのAPIへ向くとは判断できません。
PaaSはOSや実行環境の管理を狭められるため、専任のインフラ担当者がいないチームでも候補になります。
BaaSは、認証、DB、API、ファイル保存などの標準機能でサーバー側を組み立てます。
Supabaseのアーキテクチャを見ると、一つの「サーバー」ではなく、DBや認証などの要素が接続されていることが分かります。
VPSやIaaSは設定の自由度が高い反面、OSパッチ、通信制御、監視、復旧の責任も広がります。
AWS Well-Architectedフレームワークが運用、安全性、信頼性、性能、費用、持続可能性を分けているように、性能だけでは選べません。
| 方式 | OS更新 | 拡張設定 | バックアップ復元の確認 |
|---|---|---|---|
| 共用レンタル | 提供者中心 | 契約条件の範囲 | 提供範囲と自分の復元を分ける |
| PaaS | 提供者中心 | 設定で行う | アプリとDBを別々に確認する |
| BaaS | 提供者中心 | プランと上限に依存 | データ出力と復元方法を確認する |
| VPS、IaaS | 利用者側 | 自分で構成 | 作成と復元を自分で検証する |
停止時間と復元データ量から候補を絞る
スペック表より先に、障害時の業務を言葉にします。
例えば「30分止まっても受付を紙で継続できる」のか、「一分の停止で決済の取り消しが生じる」のかで必要構成は異なるでしょう。
次の五つを選定表へ入れます。
- 許容する停止時間を業務の影響から決める
- どの時点までデータを戻せばよいかを決める
- 通常と突発増加のリクエスト数を出す
- 実行環境、DB、ファイルの復元手順を比べる
- 復元テストを行い、目標時間に収まる候補を残す
バックアップが「ある」だけでは不十分です。
権限を持つ担当者が、手順書だけを見て別環境へ復元できるかを試してください。
月額に運用工数を加える費用計算例
次の数字は、サーバー料だけで比べないための仮定です。
月額サーバー料6,000円、バックアップに2,000円、監視に1,000円の構成を考えます。
運用担当者の作業を月5時間、社内評価単価を4,000円と仮定すると、運用人件費は5時間×4,000円で2万円です。
サーバー関連費9,000円と合わせた実質月額は2万9,000円になるでしょう。
| 項目 | 仮定 | 月額 |
|---|---|---|
| サーバー | 1契約 | 6,000円 |
| バックアップと監視 | 2,000円＋1,000円 | 3,000円 |
| 運用人件費 | 5時間×4,000円 | 20,000円 |
| 実質合計 | 全項目 | 29,000円 |
IaaSの表面価格が安くても、自社でパッチと障害対応を行えば工数は増えます。
AWSのコスト最適化資料が示すように、費用は一度の見積もりで終わらせず継続的に測定します。
候補の最新単価は公式の料金試算手段と各製品の価格表で入れ直してください。
監視通知を対応手順とセットで作る
CPU使用率などの技術指標は原因調査に役立ちますが、利用者が操作できないことを直接表すとは限りません。
ログイン成功率、APIエラー率、データ登録の遅延など、利用者の操作に近い指標を選びます。
通知には、担当者、確認順、一時対応、エスカレーション先をひも付けます。
Google SREの実践的なアラート資料でも、人へ通知する状態は直ちに行動が必要なものに絞る原則が示されています。
アプリ用サーバーのよくある質問
レンタルサーバーでスマホアプリのAPIを動かせますか？
利用する言語、常駐プロセス、外部通信、DB接続、バックグラウンド処理が契約条件内なら動かせる場合があります。
製品の一般名で決めず、最小のAPIと定時処理を一度配置して制限を確認してください。
BaaSを使えばサーバーは完全になくなりますか？
自分でOSを管理しない構成にできますが、DB、認証、API、ストレージといったサーバー側の機能は残ります。
Supabase公式の構成図でも複数のサーバー側コンポーネントを確認できるため、権限と復旧の設計は必要です。
サーバーのアラートは多いほど安全ですか？
作業に結び付かない通知が多いと、重要な障害が埋もれます。
Google SREのアラート原則に沿い、人がすぐ対応すべき状態だけを緊急通知にし、その他はチケットや日次レビューへ分けます。
復元できる時間と運用工数でサーバーを選ぶ
サーバー選定の成果物は、製品名だけでなく責任分担、月額試算、復元記録です。
平常時が安い構成と、障害時に目標へ戻せる構成が同じとは限らないため、復元テストを選定に含めます。
- 共用レンタル、PaaS、BaaS、IaaSで異なるOS更新と監視の責任
- サーバーの必要性能を決める条件は平常時の速度と障害時の復旧目標
- 実質費用の構成はサーバー料、付加機能、運用人件費
- 有効な緊急通知の条件は担当者がすぐ実行できる対応手順
サーバー側の分担が決まったら、XcodeでiOSアプリを公開する手順など対象OSの開発環境と接続し、通信失敗時の動作を試してください。
