Cloud infrastructure for beginners

RailwayとCloudflare
何が違う？

Terraform・Vercelも含めて、Webアプリを「どこで・どう動かすか」を一枚ずつ整理する超入門。

← → キーで操作
Railway × Cloudflare1
First answer

最初に、結論

🚂

Railway

アプリやDBを動かす場所

クラウド上の「設備の整った貸店舗」に近い。

☁️

Cloudflare

高速に配信・実行する世界規模の網

利用者の近くで処理する「世界中の支店網」に近い。

🧩

Terraform

クラウドの構成をコードで管理する道具

場所ではなく「設計図と手配係」。

役割は競合ではなく補完もする2
Mental model

たとえるなら「お店づくり」

Railway

貸店舗

電気・厨房・倉庫があり、持ち込んだアプリを動かせる。

Cloudflare

支店網＋警備＋配送

お客さんの近くで素早く届け、攻撃からも守る。

Terraform

設計図＋手配係

店舗の設備を、同じ仕様で何度でも用意する。

厳密な定義ではなく、理解のための比喩3
Railway

Railwayが得意なこと

🖥️ アプリを動かす

  • Webアプリ・API
  • Discord Bot
  • Pythonの自動処理
  • 長時間動くバックグラウンド処理

🗄️ データを支える

  • PostgreSQLなどのDB
  • 環境変数の管理
  • 定時実行（Cron）
  • ログ確認と再デプロイ
Macで動いたコードを、インターネット上で動かす流れが理解しやすい。
出典：Railway Services4
Important limit

Railwayは「機能を作る魔法」ではない

あなたが作る
予約・投稿・Bot処理
→
Railway
コードを動かす
→
利用者
Webから使う
Railwayに置いただけでは、予約機能やDiscord投稿機能は完成しない。アプリ側の実装が必要。
出典：Railway Quick Start5
Cloudflare

Cloudflareは「一つの製品」ではない

Workers

プログラム・APIを実行

D1

SQLite系のSQLデータベース

R2

画像・PDF・動画を保存

KV

高速なKey-Value保存

Durable Objects

状態を持つリアルタイム処理

Queues

非同期処理を順番に渡す

Workers AI

AIモデルを実行

CDN / WAF / DNS

高速配信・防御・住所案内

出典：Cloudflare Workers6
Edge computing

「利用者の近く」で処理する

JP

日本の利用者

近いCloudflare拠点でWorkerを実行。

US

米国の利用者

米国に近いCloudflare拠点でWorkerを実行。

Edge Computing：利用者から近い場所で処理し、待ち時間を短くする考え方。
出典：How Workers works7
Side by side

RailwayとCloudflareを比較

比較軸RailwayCloudflare
基本イメージサーバー・コンテナ寄りEdge・サーバーレス寄り
得意API、Bot、DB、長時間処理高速配信、軽量API、CDN、WAF
既存Node/Python比較的そのまま載せやすいWorkers向け調整が必要な場合あり
代表的DBPostgreSQLD1（SQLite系）
ファイル保存VolumeなどR2
学習の入口アプリを公開する配信・Edgeの設計を理解する
「どちらが上」ではなく、要件で選ぶ8
Database

PostgreSQLとD1は別物

Railway PostgreSQL

一般的なWebサービスで広く使われる、本格的なリレーショナルDB。

PostgreSQL

Cloudflare D1

Cloudflare Workersと組み合わせやすい、SQLite互換のサーバーレスSQL DB。

SQLite系
Cloudflareから外部PostgreSQLへ接続する構成も可能。Cloudflare＝D1限定ではない。
出典：Cloudflare D19
Object storage

画像・PDF・動画ならR2

利用者
→
Webアプリ
→
Cloudflare R2
画像 / PDF / 動画

DBに向くもの

ユーザー名、予約日時、投稿本文、設定値

R2に向くもの

アップロード画像、生成物、文書、音声・動画

出典：Cloudflare R210
Vercel joins

Vercelも並べると理解しやすい

▲

Vercel

Next.js・フロントエンド

画面を早く公開したいときの有力候補。

🚂

Railway

バックエンド・DB・Bot

サーバー型アプリの考え方に近い。

☁️

Cloudflare

Edge・配信・ストレージ

世界規模のネットワークを活用。

実際の機能は重なる。これは得意分野の整理11
Real architecture

実際は「どれか一つ」ではない

Cloudflare｜DNS・CDN・WAF
Vercel｜Next.js・画面
Railway｜API・バックエンド
Railway PostgreSQL｜データ

上は一例。小規模な段階で無理に分割する必要はない。

サービスは組み合わせて使える12
All in Cloudflare

Cloudflare中心で完結させる案

Workers
画面・API・処理
→
D1
SQLデータ
＋
R2
画像・文書
構成はまとまるが、既存コードやライブラリがWorkers環境にそのまま合うとは限らない。
要件と実装経験で選択13
Terraform

Terraformは何をする？

設定ファイル
「こうしたい」
→
Terraform
差分を確認・反映
→
Railway / Cloudflare
実際の環境

plan

何が変わるかを事前確認

apply

確認した変更を実際に反映

出典：Terraform overview14
When to use Terraform

最初から必要とは限らない

まだ不要になりやすい

  • 初めて1個だけ公開する
  • 構成がまだ頻繁に変わる
  • 管理画面の操作も未経験

価値が出やすい

  • 顧客ごとに同じ環境を作る
  • 本番とテストを揃える
  • 変更履歴をGitで残す
Terraformを覚えること自体を目的にしない。「同じ構成を安全に繰り返す」必要が出たら使う。
道具は課題が出てから選ぶ15
For Kota

こたさんが学ぶ順番

1

Railwayで公開

小さなWebアプリをURLで開く。

2

ログと料金

動かない原因とコストを見る。

3

Cloudflare

DNS・CDN・R2・Workersを知る。

4

Terraform

再現が必要になったら構成をコード化。

Railway → Cloudflare → Terraform16
Decision guide

迷ったら、この基準

作りたいもの・困りごと最初の候補
Discord Bot、Python処理、API＋PostgreSQLRailway
Next.jsの画面を素早く公開Vercel
画像・PDF・動画を保存Cloudflare R2
高速配信、防御、Edge APICloudflare
同じ環境を何度も再現Terraform
小さく始め、必要な部分だけ増やす17
Takeaway

Railway ＝ クラウド上の「サーバー」

Cloudflare ＝ 世界中の「高速な実行・配信網」

Terraform ＝ 環境を「コードで作る道具」

まずは小さなアプリをRailwayで1つ公開する。そこから先の課題に応じてCloudflareやTerraformを足す。
End18
1 / 18