📚 さくらのクラウドで作るモダンアーキテクチャ（全5回）
- 第1回：さくらのクラウドで作るモダンアーキテクチャ入門
- 第2回：さくらのクラウドVPC設計（イマココ）
- 第3回：GitHub ActionsとSelf-hosted RunnerでVPC内DBにmigrateを実行する方法
- 第4回：AppRun専有型と共用型の違いを徹底解説
- 第5回：Terraformで再現するさくらのモダンアーキテクチャ
はじめに
モダンアーキテクチャの成否は、ネットワーク設計で8割決まります。
特に、さくらのクラウドはAWSとは設計思想が異なります。
- AWS：L3（VPC）中心の抽象化された設計
- さくら：L2（スイッチ）を自分で組む前提の設計
この違いを理解しないままAppRunやDBを配置すると、
- VPC連携がうまくいかない
- 専有型が起動しない
- 稼働コンテナ数が0になる
- 意図せずDBが公開される
といった事故が起きます。
今回は、
- L2（スイッチ）
- L3（VPCルータ）
- SEG（サービスエンドポイント）
この3つを軸に、正しいVPC設計を整理します。
1. L2（スイッチ）とは何か？
L2スイッチは、同一セグメント内の通信を担うレイヤーです。
特徴：
- 同一IPレンジ内で直接通信
- ブロードキャストドメインを形成
- ルーティングはしない
さくらのクラウドでは、セグメントを自分で作るのが前提です。
AWSのように「VPCを作れば終わり」ではありません。
まずは どの役割をどのセグメントに分けるか を決めることから始まります。
2. L3（VPCルータ）の役割
VPCルータは、異なるセグメント間を接続するL3層です。
主な機能：
- ルーティング
- NAT
- パケットフィルタ
- VPN接続
AWSで例えると：
- NAT Gateway
- Internet Gateway
- Route Table
をまとめた存在です。
原則はシンプル。
L2で分ける
L3で繋ぐ
3. SEG（サービスエンドポイント）を忘れるな
ここが最重要ポイントです。
SEGとは？
SEG（Service Endpoint Gateway）は、
VPC内からさくらのマネージドサービスへ
インターネットを経由せずに接続する仕組み
です。
対象例：
- コンテナレジストリ
- AppRun Dedicatedコントロールプレーン
- オブジェクトストレージ
なぜSEGが重要なのか？
AppRun専有型では、
- ワーカーノードがVPC内に存在
- 外部に直接出られない構成も多い
そのためSEGを設定しないと、
- Dockerイメージがpullできない
- デプロイが失敗する
- activeNodeCount=0 のまま止まる
という状態になります。
「ネットワークは正しいのに動かない」場合、
まずSEGを疑うべきです。
4. 推奨セグメント構成
今回のシリーズで採用する基本構成は以下です。
Internet
↓
Cloudflare
↓
AppRun（Frontend）
[VPC内]
├─ public-app-seg
├─ private-db-seg
├─ runner-seg
└─ SEG（サービス接続）
設計原則：
- DBはprivate-db-segのみ
- DBにグローバルIPを持たせない
- RunnerのみDBアクセス許可
- AppRun専有型はSEG経由でサービス接続
5. Terraformでのネットワーク表現例
ここまでの設計は、Terraformでは次のように表現できます。
L2（セグメント）
resource "sakuracloud_switch" "public_app" {
name = "public-app-seg"
}
resource "sakuracloud_switch" "private_db" {
name = "private-db-seg"
}
resource "sakuracloud_switch" "runner" {
name = "runner-seg"
}
L3（VPCルータ）
resource "sakuracloud_vpc_router" "vpc" {
name = "vpc-router"
plan = "standard"
interface {
switch_id = sakuracloud_switch.public_app.id
ipaddress = ["192.168.10.1"]
netmask = 24
}
interface {
switch_id = sakuracloud_switch.private_db.id
ipaddress = ["192.168.20.1"]
netmask = 24
}
interface {
switch_id = sakuracloud_switch.runner.id
ipaddress = ["192.168.30.1"]
netmask = 24
}
}
ここで重要なのは、
Terraform上でも
「L2で分け、L3で束ねる」という思想がそのまま表現される
という点です。
SEG（概念例）
resource "sakuracloud_service_endpoint" "seg" {
name = "seg-main"
switch_id = sakuracloud_switch.public_app.id
services = [
"container-registry",
"object-storage",
"apprun-dedicated-control-plane",
]
}
※実際の属性はproviderバージョンにより変更される可能性があります。
6. AWSとの違い
| 観点 | AWS | さくら |
|---|---|---|
| セグメント | 自動生成 | 手動L2作成 |
| サービス接続 | VPC Endpoint | SEG |
| NAT | 専用 | VPCルータ内蔵 |
| 思想 | 抽象化 | 明示的設計 |
さくらは「分かりやすい」代わりに、
自分で理解して組む責任がある。
しかし一度理解すれば、
構造は極めてシンプルです。
設計原則まとめ
- L2で役割ごとに分離する
- L3で境界を制御する
- SEGでマネージドサービスへ閉域接続する
- DBは絶対にグローバル公開しない
- AppRun専有型はSEG前提で設計する
よくある質問（FAQ）
Q. SEGは必須ですか？
AppRun専有型で閉域構成を組むなら必須です。
Q. SEGとNATの違いは？
NATはインターネット経由。
SEGは閉域接続。
Q. L2とL3の違いが曖昧です。
L2は同一セグメント内通信。
L3は異なるセグメント間のルーティングです。
まとめ
さくらのクラウドでモダンアーキテクチャを組むなら、
L2・L3・SEG
この3点を理解することが最重要。
ここを押さえれば、
AppRun × VPC構成で迷うことはありません。
次回は、
GitHub Actions × Self-hosted Runnerで
VPC内DBにmigrateを実行する方法
を解説します。
閉域ネットワークとCI/CDをどう両立させるか。
ここが実運用の核心です。