🏢 物理ネットワークからGCP設計へ - 企業規模別移行パターン

概要

物理オフィスのネットワーク設計原則をGCPクラウドに適用することで、直感的で運用しやすいインフラを構築できます。本記事では、企業規模別の物理ネットワークとGCP VPC設計の対応関係、移行戦略について詳しく解説します。

企業規模別ネットワーク設計パターン

1. 小規模企業（50人以下）- 単一オフィス

物理ネットワーク構成

1
2
3
4
5
6
7
8
インターネット
    ↓
[ルーター] 192.168.1.1
    ↓
[L2スイッチ]
 ├─ 社員PC: 192.168.1.100-150
 ├─ サーバー: 192.168.1.10-20  
 └─ プリンター: 192.168.1.200-210

設計原則:

1つのセグメントで全て処理
シンプル・低コスト重視
管理負荷最小化

GCP対応設計

1
2
3
4
5
6
7
8
Project: company-main
VPC: main-vpc (10.0.0.0/16)
Subnets:
  - office-subnet: 10.0.1.0/24
    Resources:
      - GCE: 10.0.1.10-50
      - GKE: 10.0.1.100-150
      - Cloud SQL: 10.0.1.200

移行メリット:

物理機器保守不要
自動バックアップ・冗長化
スケールアップ容易

2. 中小企業（100-500人）- 部署別分離

物理ネットワーク構成（Layer3スイッチ使用）

1
2
3
4
5
6
7
8
9
インターネット
    ↓
[メインルーター]
    ↓
[Layer3スイッチ] (VLAN対応)
 ├─ VLAN10: 一般部門 (192.168.10.0/24)
 ├─ VLAN20: 経理部門 (192.168.20.0/24)
 ├─ VLAN30: 開発部門 (192.168.30.0/24)
 └─ VLAN99: サーバー (192.168.99.0/24)

Layer3スイッチの進化意義: 従来の「各部署にルーター+ハブ」→「1台で統合管理」

コスト削減（複数ルーター → 単一機器）
管理効率化（一元設定・監視）
部署間通信の柔軟化

GCP対応設計（マルチVPC推奨）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Project: company-main

VPCs:
  general-vpc:
    CIDR: 10.10.0.0/16
    Subnets:
      - general-subnet: 10.10.1.0/24
  
  accounting-vpc:
    CIDR: 10.20.0.0/16
    Subnets:
      - accounting-subnet: 10.20.1.0/24
  
  dev-vpc:
    CIDR: 10.30.0.0/16
    Subnets:
      - dev-subnet: 10.30.1.0/24
  
  shared-vpc:
    CIDR: 10.99.0.0/16
    Subnets:
      - shared-services: 10.99.1.0/24

Connections:
  - VPC Peering: general-vpc ↔ shared-vpc
  - VPC Peering: accounting-vpc ↔ shared-vpc
  - VPC Peering: dev-vpc ↔ shared-vpc

セキュリティ境界:

IAM + VPC分離でデータ保護
最小権限アクセス制御
監査ログ完全記録

3. 大企業（多拠点・海外展開）

物理ネットワーク構成

1
2
3
4
5
本社（東京）              支社（大阪）
[本社ルーター]            [支社ルーター]  
192.168.1.0/24           192.168.2.0/24
    ↓                        ↓
専用線/VPN ⟷ インターネット ⟷ 専用線/VPN

従来の接続選択肢:

専用線: 高コスト・高品質・低遅延
VPN: 低コスト・標準品質・遅延あり
MPLS: 中コスト・高品質・SLA保証

GCP対応設計（マルチリージョン）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
Global Architecture:

Project: company-global
VPC: global-vpc (グローバル)

Subnets:
  tokyo-subnet:
    Region: asia-northeast1
    CIDR: 10.1.0.0/24
  
  osaka-subnet:
    Region: asia-northeast2  
    CIDR: 10.2.0.0/24
  
  singapore-subnet:
    Region: asia-southeast1
    CIDR: 10.3.0.0/24

Connections:
  - Cloud Interconnect: 東京本社 ↔ GCP
  - Cloud VPN: 各拠点 ↔ GCP
  - Global Load Balancer: 世界的負荷分散

ハイブリッド接続例:

1
2
3
4
5
# Cloud Interconnect設定
gcloud compute interconnects create tokyo-interconnect \
    --customer-name="Company Tokyo" \
    --interconnect-type=DEDICATED \
    --location=asia-northeast1-a

設計判断フローチャート

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
flowchart TD
    A[要件分析] --> B{組織規模}
    
    B -->|~50人| C[単一VPC設計]
    B -->|50-500人| D[部署別分離必要?]
    B -->|500人以上| E[マルチプロジェクト設計]
    
    D -->|Yes| F[マルチVPC + Peering]
    D -->|No| C
    
    A --> G{地理的分散}
    G -->|単一拠点| H[シングルリージョン]
    G -->|複数拠点| I[マルチリージョン]
    
    A --> J{セキュリティ要件}
    J -->|高| K[厳密分離設計]
    J -->|標準| L[標準分離設計]

実践的な移行戦略

Phase 1: 現状把握・設計

物理ネットワーク調査:

1
2
3
4
# ネットワーク構成調査
ip route show table main
netstat -rn
nmap -sn 192.168.1.0/24

GCP設計方針決定:

1
2
3
4
5
6
7
8
9
Assessment:
  Current_Network: "192.168.1.0/24"
  Departments: ["general", "accounting", "dev"]
  Security_Requirements: "medium"
  
Target_Design:
  Architecture: "Multi-VPC"
  Primary_Region: "asia-northeast1"
  DR_Region: "asia-northeast2"

Phase 2: 並行運用（ハイブリッド）

Cloud VPN接続:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
# VPN Gateway作成
gcloud compute vpn-gateways create office-vpn-gw \
    --network=main-vpc \
    --region=asia-northeast1

# トンネル作成
gcloud compute vpn-tunnels create office-tunnel \
    --peer-address=office-public-ip \
    --shared-secret=secure-shared-secret \
    --target-vpn-gateway=office-vpn-gw

段階的移行:

開発環境 → GCP移行
非クリティカルシステム → 移行
コアシステム → 慎重に移行

Phase 3: 完全移行・最適化

Cloud Native化:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
Target_State:
  Physical_Office: "最小化（端末のみ）"
  Core_Systems: "GCP Managed Services"
  Backup: "Cross-region replication"
  
Optimization:
  - Cloud Load Balancing
  - Auto Scaling
  - Managed Database (Cloud SQL)
  - Container Orchestration (GKE)

IPアドレス設計ベストプラクティス

重複回避設計

階層的アドレス体系:

1
2
3
4
5
6
7
10.{リージョン}.{部署}.{ホスト}

例：
10.1.1.0/24: 東京・一般部門
10.1.2.0/24: 東京・経理部門  
10.2.1.0/24: 大阪・一般部門
10.2.2.0/24: 大阪・経理部門

RFC1918使い分け:

10.0.0.0/8: 大企業・多拠点・将来拡張予定
172.16.0.0/12: 中規模企業・複数拠点予定
192.168.0.0/16: 小規模企業・単一拠点

GCPでの予約アドレス考慮

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
Subnet: 10.0.1.0/24

Reserved_by_GCP:
  - 10.0.1.0: ネットワークアドレス
  - 10.0.1.1: デフォルトゲートウェイ
  - 10.0.1.2: DNS (Google)  
  - 10.0.1.3: 将来の利用
  - 10.0.1.255: ブロードキャスト

Available: 10.0.1.4 - 10.0.1.254 (251個)

コスト最適化

物理 vs GCP コスト比較

物理ネットワーク年間コスト（中小企業例）:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
初期投資:
- Layer3スイッチ: ¥500,000
- サーバー機器: ¥2,000,000
- UPS・ラック: ¥300,000

運用コスト（年間）:
- 電気代: ¥200,000
- 保守契約: ¥300,000  
- 人件費: ¥1,200,000

Total: ¥4,500,000 / year

GCP年間コスト（同規模）:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
Compute:
  - GCE instances: $800/month
  - Cloud SQL: $300/month
  
Network:
  - VPC: $0 (free)
  - Load Balancing: $50/month
  - VPN: $40/month

Total: $1,190/month = $14,280/year (¥1,950,000)

Savings: 約57%削減 + 運用負荷削減

監視・運用自動化

ネットワーク監視設定

1
2
3
4
5
6
7
8
# VPC Flow Logs有効化
gcloud compute networks subnets update main-subnet \
    --enable-flow-logs \
    --logging-flow-sampling=1.0

# カスタムメトリクス設定  
gcloud logging sinks create network-monitoring \
    bigquery.googleapis.com/projects/project-id/datasets/network_logs

自動復旧設定

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
# Cloud Functions自動復旧
apiVersion: v1
kind: ConfigMap
metadata:
  name: network-automation
data:
  auto_healing.py: |
    def heal_network_issue(event, context):
        # ネットワーク問題自動修復ロジック
        pass

まとめ

物理ネットワークからGCPへの移行は、企業規模と要件に応じた段階的アプローチが重要です：

設計原則:

小規模: 単一VPC・シンプル設計
中規模: マルチVPC・部署分離
大規模: マルチプロジェクト・地理分散

移行メリット:

57%のコスト削減
運用負荷大幅削減
自動スケール・高可用性
グローバル展開容易

Layer3スイッチが「複数ルーター+ハブの統合」であったように、GCPは「データセンター全体の統合」として理解すると、移行設計がより直感的になります。

📅 作成日: 2025年09月09日

参考リンク: