複数サイトのホスティング
200以上のサイトを、一つのデプロイ・証明書・復旧手順で管理
分散していたサイト公開作業を、検証・自動化・バージョン管理を備えた共通基盤へまとめました。
課題
サイトが増えるにつれ、ファイルのアップロード、ドメイン設定、証明書発行を個別に行う作業が遅くなり、監査も難しくなりました。手動で上書きすると復旧も不確実になります。新規公開と更新に、履歴を確認できる反復可能な共通手順が必要でした。
制約
- 多数の独立ドメインと静的サイトを、サイトごとに常時コンテナを維持せずに配信する必要がありました。
- ドメインと証明書の変更を自動化する間も、既存サイトの稼働を維持する必要がありました。
- 顧客名、アクセス数、コスト、内部の運用データは非公開です。
取り組んだこと
実行基盤を共有し、サイト成果物を分ける
Cloud Run上のNginxで共通の配信層をつくり、サイトのパッケージとバージョンはGoogle Cloud Storageに保存。計算資源を独立して拡張できます。
見送った選択肢 サイトごとの常時コンテナは、イメージ、デプロイ、運用作業が一緒に増えるため採用しませんでした。
検証を含むデプロイ手順にする
アップロード時にパッケージ構造を確認し、展開、バージョン作成、配信切り替えの順に処理します。
見送った選択肢 部分的な書き込みや不正なパッケージは復旧しにくい状態を生むため、本番ファイルへの直接上書きは許可しませんでした。
ドメインとTLSを自動化する
Cloudflare DNS、TLS、サイト設定を一つの準備手順で扱い、DNS-01検証で移行中の既存サイトへの影響を抑えます。
見送った選択肢 サイトごとの手動発行を残すと、規模の拡大に伴い漏れや更新失敗を発見しにくくなるため自動化しました。
最新ファイルだけでなく、バージョンを残す
デプロイごとに指定可能なバージョンを作成し、古いパッケージを再構築せずに戻せるようにしました。
見送った選択肢 最新アップロードだけを残すと、別途バックアップがあるかどうかに復旧が左右されるためです。
成果
- 200以上のサイトを一つの基盤で管理しています。
- パッケージのアップロード、検証、デプロイが一つの自動手順になりました。
- デプロイごとに、復旧先として選択できるバージョンが残ります。
技術
- Google Cloud Run
- Nginx
- Google Cloud Storage
- Cloudflare
振り返り
やり直すなら、障害の状態、操作監査、テナントの境界をもっと早く設計の中心に置きます。数サイトなら管理機能に見えても、一定の規模を超えると、それ自体がアーキテクチャになるからです。