Git連携型ホスティング

Webホスティングの変遷をたどりながら、従来型アーキテクチャの課題と、それを解決する「Git連携型ホスティング」について解説します。

Webホスティングの変遷

Webサイトの公開方法は、技術の進歩とともに大きく変わってきました。それぞれの時代で直面した課題と解決策を振り返ります。

第1世代：静的ファイルの手動アップロード

初期のWebサイトは、HTMLやCSS、画像などのファイルをFTPで手動アップロードする方式が主流でした。

---
title: 初期のWebサイト
config:
  layout: dagre
---

flowchart TD
    Browser@{ label: "Webブラウザ", icon: "nimbus:browser", form: "rounded" }
    Server@{ label: "Webサーバー", icon: "heroicons:server", form: "circle", pos: "b", h: 80 }

    Browser <--> Server

シンプルな構成ですが、複数人で更新する際には深刻な問題がありました。

複数人が同時に編集すると、古いファイルで上書きされ、他の人の変更が消える
誰がいつ何を変更したか、履歴が残らない
誤ってファイルを削除しても復元できない
本番サーバーへ直接アップロードするため、テスト環境との差分管理が困難

---
title: FTPでサイトを更新する
config:
  layout: dagre
---

flowchart LR
    Developer@{ label: "開発者", icon: "streamline-ultimate:programming-hold-code-2", form: "rounded"}
    Server@{ label: "Webサーバー", icon: "heroicons:server", form: "circle" }
    FTP([FTPアップロード])

    Developer  -.- FTP -.-> Server

第2世代：動的サイトとサーバーサイド処理

PHPなどの登場により、サーバーサイドでHTMLを動的に生成する方式が主流になりました。WordPressもこの構成に該当します。

---
title: サーバーサイドで動的にページを生成する構成
config:
  layout: elk
  elk:
    nodePlacementStrategy: "SIMPLE"
---

flowchart TD
    Browser@{ label: "Webブラウザ", icon: "nimbus:browser", form: "rounded" }
    WebServer@{ label: "Webサーバー", icon: "heroicons:server", form: "circle", pos: "b", h: 80 }
    AppServer@{ label: "プログラム", icon: "heroicons:cpu-chip", form: "rounded" }
    DataBase@{ label: "データベース", icon: "carbon:db2-database", form: "rounded" }

    Browser <--> WebServer
    WebServer <--> AppServer
    AppServer <--> DataBase

データベースと連携することで、大量のコンテンツを効率的に管理できるようになりました。一方で、WordPressを運用している方なら心当たりのある課題も生まれます。

アクセス集中時に、サイトが重くなったり落ちたりする（リクエストごとにページを生成するため）
プラグインやPHP・WordPressのアップデートを放置すると、セキュリティリスクが高まる
「更新したのに反映されない」キャッシュ起因のトラブル
サーバー移行やPHPバージョンアップで、突然サイトが動かなくなる

第3世代：スケールアウトと構成の複雑化

アクセスの多いサイトでは、負荷対策として複数台のサーバーで処理を分散させる構成が一般的になりました。画像などの静的アセットにはCDNが導入されるようになります。

---
title: 複数台のサーバーで処理を分散させる構成
config:
  layout: elk
  elk:
    nodePlacementStrategy: "SIMPLE"
---

flowchart TD
    Browser@{ label: "Webブラウザ", icon: "nimbus:browser", form: "rounded" }
    LoadBalancer@{ label: "ロードバランサー", icon: "carbon:load-balancer-pool", form: "circle", pos: "b", h: 80 }
    WebServerA@{ label: "Webサーバー", icon: "heroicons:server", form: "rounded" }
    WebServerB@{ label: "Webサーバー", icon: "heroicons:server", form: "rounded" }
    AppCache@{ label: "キャッシュ", icon: "lineicons:refresh-circle-1-clockwise", form: "rounded" }
    AppServerA@{ label: "プログラム", icon: "heroicons:cpu-chip", form: "rounded" }
    AppServerB@{ label: "プログラム", icon: "heroicons:cpu-chip", form: "rounded" }
    DatabaseCache@{ label: "キャッシュ", icon: "lineicons:refresh-circle-1-clockwise", form: "rounded" }
    DataBase@{ label: "データベース", icon: "carbon:db2-database", form: "rounded" }

    CDN@{ label: "CDN", icon: "carbon:content-delivery-network", form: "circle", pos: "b", h: 80 }
    OriginStatic@{ label: "静的アセット\nオリジン", icon: "carbon:object-storage", form: "rounded" }

    Browser <--> CDN
    Browser <--> LoadBalancer

    subgraph BackEnd["アプリケーション<br />構成"]

      WebServerA <--> AppCache
      WebServerB <--> AppCache

      AppCache <--> AppServerA
      AppCache <--> AppServerB

      AppServerA <--> DatabaseCache
      AppServerB <--> DatabaseCache
      DatabaseCache <--> DataBase
    end

    CDN <--> OriginStatic

    LoadBalancer <--> WebServerA
    LoadBalancer <--> WebServerB

スケーラビリティは向上しましたが、運用の難易度とコストも大幅に増加しました。

インフラ専門のエンジニアが必要になり、人件費・外注費が増大
サーバー台数に比例して月額費用も膨らむ
障害発生時に原因の特定に時間がかかる
ボタンの色を変えるだけでも、バックエンドエンジニアとの調整が必要になることも

CDNとは？

CDN（Content Delivery Network）とは、Webコンテンツを世界中の「エッジサーバー」にあらかじめ配置し、ユーザーに地理的に近いサーバーから配信する仕組みです。ユーザーはレスポンスの高速化という恩恵を受けられます。

運営側にとっては、オリジンサーバーへのアクセス集中を回避でき、可用性の向上やインフラコストの削減につながります。

Git連携型ホスティングの登場

これらの課題を解決するために登場したのが、Git連携型ホスティングです。

---
title: Git連携型ホスティング
config:
  layout: dagre
---

flowchart TD
    Browser@{ label: "Webブラウザ", icon: "nimbus:browser", form: "rounded" }
    Cloud@{ label: "Git連携型<br/>ホスティング", icon: "carbon:content-delivery-network", form: "circle", pos: "b", h: 80 }

    Browser <--> Cloud

GitリポジトリへのpushをトリガーにWebサイトを自動でビルド・デプロイし、世界中のCDNから配信します。

---
title: Gitリポジトリへのpushをトリガーにサイトを更新する
config:
  layout: dagre
---

flowchart LR
    Developer@{ label: "開発者", icon: "streamline-ultimate:programming-hold-code-2", form: "rounded" }
    GitHub@{ label: "GitHub", icon: "carbon:logo-github", form: "rounded" }

    Developer[開発者]  .-PUSH([git push]).-> GitHub

    GitHub .-Webhook([連携]).->  CI@{ label: "ビルド", icon: "ion:build-outline", form: "rounded" }

    subgraph Hosting["Git連携型ホスティング"]
      CI@{ label: "ビルド", icon: "ion:build-outline", form: "rounded" }
      Cloud@{ label: "ホスティング", icon: "carbon:content-delivery-network", form: "rounded" }

      CI --> Cloud
    end

代表的なサービスとして「Cloudflare Workers/Pages」「Vercel」「Netlify」「AWS Amplify ホスティング」「Azure Static Web Apps」などがあります。

Git連携型ホスティングが解決する課題

これまで見てきた第1〜3世代の課題は、Git連携型ホスティングによって次のように解決されます。

従来の課題	Git連携型ホスティングによる解決
複数人の編集で変更が消える・履歴なし	Gitによるバージョン管理と変更履歴の保持
テスト環境なしで本番に直接アップロード	プルリクエストごとにプレビュー環境を自動生成
アクセス集中でサイトが重くなる・落ちる	事前ビルド＋CDN配信で高負荷に対応
プラグインやCMSのセキュリティリスク	動的なサーバー処理がなく攻撃対象が減少
インフラの複雑化と運用コストの増大	マネージドサービスで構成を簡素化
フロントエンドとバックエンドの密結合	フロントエンドを独立してデプロイ可能