Cloud infrastructure
コーポレートサイトのクラウド構成
問い合わせはD1へ保存してから受付を返し、通知処理へはQueuesで受付IDを渡します。
配信と運用を一つの基盤にまとめる
このコーポレートサイトは静的なページを中心に構成し、Workers Static Assetsで配信しています。配信の分散はCloudflareのネットワークを利用し、記事の公開・更新はGitで管理しています。
会社情報や記事の更新が中心なので、常時稼働するアプリケーションサーバーや記事配信用のDBは設けていません。ページの配信、HTTPS、問い合わせ処理を同じ基盤へまとめ、更新や障害調査で確認する場所を増やさない設計にしています。
HTTPS接続と標準のDDoS対策もCloudflare側で扱います。サイトの配信と問い合わせAPIは同じドメインで受け付け、問い合わせの処理が必要なリクエストだけをWorkerへ渡す構成です。
D1とQueuesによる問い合わせ処理
問い合わせはWorkerで入力とTurnstileを検証し、受付内容と通知状態をD1へ保存してから成功を返します。メール配送の一時的な失敗で、受け付けた内容が失われないようにするためです。
フォームの応答がメール配送の待ち時間や一時障害に左右されないよう、通知はQueues経由で別に処理します。Queueに渡すのは保存済みレコードのIDだけで、同じWorkerの通知処理がD1から内容を読み、固定宛先へメールを送ります。失敗時は再試行し、未通知のまま残った受付は定期処理で回収します。
受付と通知の送信は別の状態として管理します。アプリケーションログには処理結果を記録し、本文・メールアドレス・検証トークンは出しません。
CIとPreviewによる公開確認
GitHub Actionsでテスト・ビルドを実行し、Cloudflare Accessで保護したPreviewへ配信します。Previewの保存先や通知設定は本番から分離しています。
原稿とコードを同じPRで確認し、公開前に日英のリンクやスマホのレイアウトを実際の画面でレビューするためです。自動テストで構造の不整合を確認し、画面の見え方はPreviewで確認する役割分担にしています。
公開するファイルはビルド時の許可リストで限定し、内部文書や認証情報を配信に含めません。デプロイ後はHTTP応答と配信コミットを照合し、確認した変更が公開されているかを検証します。
