実行基盤・ホスティング
書いたコードを、自分のパソコンの外で動かし続ける場所
画面・サーバー・データベースを「載せる」土台。ここに載せて初めて、他人が使える。
最初に触るなら
GitHub Pages :GitHubリポジトリから静的サイトを無料で公開するホスティング
静的サイトを無料で公開でき、「公開する」とはファイルを誰かのサーバーに置くことだと最短で分かる。サーバーが必要になったら Render や AWS Lambda に進む。
隣の分野とのつながり
| 分野 | どうつながるか |
|---|---|
| 開発基盤・CI/CD | 変更をここへ届けるのが開発基盤(CI/CD)の仕事 |
| 監視・可観測性 | 載せたものが正しく動いているかを見るのが監視の仕事 |
| サーバー・API | 常時動くサーバーか、呼ばれたときだけ動く関数かで、置き方と料金が変わる |
| 自動化・連携 | 定期的に動かす処理も、どこかの基盤の上で動く |
| 画面・フロントエンド (から見ると) | 作った画面は HTML・CSS・JavaScript のファイルになる。それを配信場所に置いて初めて他人が見られる |
| サーバー・API (から見ると) | サーバーは動かし続ける場所が要る。自前で持つか、BaaS に任せるかを選ぶ |
| データの保存 (から見ると) | データベースを自分で運用するか、運用込みで借りる(マネージド)かを選ぶ |
| 開発基盤・CI/CD (から見ると) | 届け先。検証(CI)に通った変更を、実行基盤へ配信(CD)する |
| 監視・可観測性 (から見ると) | 監視の対象は、実行基盤の上で動いているもの |
| 認証・セキュリティ (から見ると) | 公開面への攻撃(大量アクセス、ボット)は基盤の手前で止める |
| 自動化・連携 (から見ると) | 定期的に動かす処理も、どこかの基盤の上で動く。実行時間の上限はそこで決まる |
| AI・機械学習 (から見ると) | 手元でモデルを動かすなら、GPU とメモリという基盤の制約が先に立つ |
この分野を理解する
自分のパソコンで動くだけでは、誰も使えない。 作ったものを他人に使ってもらうには、常に電源が入っていて、インターネットから届く場所に置く必要がある。その場所を提供するのが実行基盤(ホスティング)である。
置くものによって種類が違う。 HTML などのファイルを置くだけなら「静的ホスティング」(GitHub Pages、Vercel)。サーバーのプログラムを動かし続けるなら「常駐型」(Render)。「リクエストが来たときだけ関数を動かす」のが「サーバーレス」(AWS Lambda、Cloudflare Workers)で、待機中は料金がかからない代わりに、1回の実行時間に上限がある。
コンテナという箱。 Docker は「プログラムと、それを動かすのに必要な環境」をひとつの箱にまとめる道具である。箱にしておくと、自分のパソコンでも Render でも同じように動く。「自分の環境では動くのに」という問題を減らす。
隣の分野との境界。 基盤は「動かす場所」であり、そこへ変更を届ける仕組み(CI/CD)と、動いているかを見る仕組み(監視)は別の分野である。この3つはいつも組で使う。
最初の一歩。 静的サイトを GitHub Pages で公開する。次に、小さな関数を Cloudflare Workers か AWS Lambda で動かして、「実行時間の上限」に触れてみる。
この分野のツール(7件)
種別(自分で書く土台か、借りて使うサービスか)で分けている。「主要制約」は各ツールで最も先に当たる限界。
ツール(1件)自分の環境にインストールして使うソフトウェア。無料のものが多いが、運用は自分で持つ
| ツール | 学習 | 料金 | 成熟 | 主要制約 | 検証 |
|---|---|---|---|---|---|
| Docker アプリと実行環境をイメージに固め、どこでも同じに動かすコンテナ基盤 | 中 | 無料枠あり | 安定 | Docker Desktop の無償利用の条件:従業員 250 人未満かつ年商 1,000 万ドル未満の企業、個人利用、教育、非商用 OSS のみ無償。超える企業は Pro / Team / Business の有償サブスクリプションが必要。Docker Engine(Linux の CLI・デーモン)は対象外 |
マネージドサービス(6件)事業者が運用していて、借りて使うサービス。運用を任せられる代わりに、プランの上限が乗る
| ツール | 学習 | 料金 | 成熟 | 主要制約 | 検証 |
|---|---|---|---|---|---|
| GitHub Pages GitHubリポジトリから静的サイトを無料で公開するホスティング | 低 | 無料 | 安定 | 帯域の上限(ソフトリミット):100 GB / 月 | |
| Render Git連携でWebサービス・常駐ワーカー・DBを運用するHeroku型のPaaS | 低 | 無料枠あり | 安定 | 無料インスタンスのスリープ:15分間リクエストがないと停止し、次のリクエストで再起動に約 1分かかる | |
| Vercel Gitに連携し、Next.jsなどのフロントエンドを自動デプロイするホスティング基盤 | 低 | 無料枠あり | 安定 | 帯域(Fast Data Transfer)の込み分:Hobby 100 GB / 月、Pro 1 TB / 月 | |
| AWS Lambda サーバー管理なしでコードをイベント駆動・従量課金で実行するAWSの基盤 | 中 | 従量課金 | 安定 | 1回の実行時間の上限:900秒(15分)/ 実行。Lambda Managed Instances の非同期・イベントソース呼び出しのみ 5,400秒(90分) | |
| Cloudflare Workers V8アイソレートで動く、Cloudflareのエッジサーバーレス実行基盤 | 中 | 無料枠あり | 安定 | CPU 時間の上限:無料プラン 10ms/リクエスト。有料プラン(Workers Paid)は既定30秒、設定で最大5分(300秒)。Cron Triggers・Queue コンシューマは間隔に応じ最大15分 | |
| Fly.io Dockerイメージを世界中のリージョンにVM(Machine)として配置するPaaS | 中 | 従量課金 | 成長中 | 支払い方法の登録:Linked Organizationsを除くすべての組織でクレジットカード登録が必須 |
どれを選ぶか
| ツール | 種別 | どういう時に選ぶか/避けるか |
|---|---|---|
| Docker | ツール | 「開発環境と本番環境を同じにしたい」「依存関係ごとパッケージして配布したい」場合の既定解。Web アプリの開発では最初から Dockerfile を置いてよい。避けるのは、Docker Desktop のライセンス費が問題になる企業で Linux 環境も用意できない場合と、単一の静的サイトや関数だけで済む場合(コンテナは過剰) |
| GitHub Pages | マネージドサービス | OSS のドキュメント、個人ブログ、ポートフォリオなど、完全に静的で非商用のサイトでは第一候補。サーバー側処理・非公開ソース・商用利用・100 GB / 月を超える配信のいずれかが要る時点で避け、Vercel か Render へ |
| Render | マネージドサービス | Heroku 型の「Git に push したらバックエンドごと動く」体験を安く手に入れる用途では第一候補。常駐ワーカー・WebSocket・Cron・Postgres を一つの画面で揃えられる。避けるのは、アクセスが散発的で固定月額が無駄になる場合(Lambda / Workers へ)と、無料枠で本番運用しようとする場合(スリープと 30日 DB 失効で破綻する) |
| Vercel | マネージドサービス | Next.js・Astro などのフロントエンドを Git 連携で公開する用途では第一候補。個人・非商用なら Hobby で十分に動く。商用サイトは Pro($20 / ユーザー / 月+従量)が前提で、常駐プロセス・永続ディスク・800秒を超える処理が要る場合は避け、Render 等の常駐型 PaaS へ |
| AWS Lambda | マネージドサービス | イベント駆動・散発的なトラフィックの処理では第一候補。Webhook 受信、S3 へのアップロードを契機とする変換、日次バッチの分割実行に向く。15分を超える処理、常時接続の保持、AWS 以外に閉じた構成が必要な場合は避け、常駐サービス(Render 等)かバッチ基盤へ |
| Cloudflare Workers | マネージドサービス | グローバルなエッジで低レイテンシに応答する軽量なAPIやWebhook処理、静的サイトに付随する薄いバックエンドでは第一候補。CPU時間の大きい計算処理、128 MBを超えるメモリが必要な処理、Node.js資産をそのまま持ち込みたい場合は避け、AWS LambdaやRenderのようなメモリ・実行時間に余裕のある基盤へ |
| Fly.io | マネージドサービス | Dockerイメージを複数リージョンに配置して低遅延で配信したい、WebSocketや常駐プロセスを動かしたい用途では第一候補。カード登録なしで無料に試したい場合や、アクセスが散発的でリクエスト単位課金が有利な場合は、それぞれRenderやLambda/Workers系を検討する |
この分野が担う目的
目的ごとのページでは、他の分野のツールも含めて横断比較できる。
- 定期的に処理を実行する (この分野から 4件)
- 静的ファイルを公開・配信する (この分野から 3件)
- サーバー付き Web アプリを公開する (この分野から 3件)
- 実行環境をコンテナで固定し、実行・運用する (この分野から 3件)
- 短時間の処理をオンデマンドで実行する (この分野から 3件)
- 変更を自動で本番へ配信する (この分野から 2件)
- 常時起動のプロセスを保持する (この分野から 2件)
- HTTP API を公開する (この分野から 2件)
- イベントや Webhook を受けて処理を起動する (この分野から 1件)
- 大量データを一括処理する (この分野から 1件)
- 処理をキューに入れて非同期に処理する (この分野から 1件)
- キーと値を高速に読み書き・一時保存する (この分野から 1件)