ホスティング・ドメイン・キャッシュを本番環境につなぐ

ホスティングと実行環境をデータ更新方式に合わせる

サーバーコードが正しくても、クローラーがドメインに接続できなかったり、CDNから古い原稿を受け取ったりすれば新しい案内を読めない。検索・AIは実際のURLで受け取ったレスポンスを処理する。ホスティング・ドメイン・キャッシュの設定は、そのURLが現在の公開文書を継続して届けるための作業につながる。

ホスティングは、ファイルやアプリケーションをインターネットで使えるように実行・提供するサービスだ。静的ホスティングは事前に作成したファイルを提供する。Node.jsはサーバーでJavaScriptを実行する環境だ。リクエストごとにDBを読みHTMLを作るには、その機能に対応するサーバーランタイムかマネージドプラットフォームが必要になる。

サーバーレス関数はリクエスト到着時にコードを実行し、サーバー運用をプラットフォームが管理する方式だ。コンテナーはコードと実行に必要なファイルをまとめてデプロイする方式だ。VMは仮想マシンで、OSとサーバーを直接管理できる。どの方式でも実行時間・メモリー・同時リクエスト・DB接続数の制限を確認する。

コールドスタートは、新しい実行環境を準備するため最初のリクエストが遅れる現象だ。リージョンはサーバーを配置する地域を指す。サーバーとDBが離れると、クエリの往復時間が長くなることがある。ページのHTML生成時間とDBクエリ時間を別々に記録し、実行地域・接続の再利用・キャッシュを調整する。

複数のサーバーを運用するなら、同じ公開原稿とキャッシュ更新状態を読むように構成する。各サーバーのローカルディスクに異なるキャッシュが残ると、同じURLでもリクエストごとに違う記事を返す場合がある。複数インスタンスのキャッシュ共有と再検証の伝達方式は、Next.jsのセルフホスティングガイドとデプロイ先の対応範囲に合わせる。インスタンスとは、実行中のサーバープログラム1つを指す。

DNSとHTTPSで本番URLを接続する

DNSは、ドメイン名から接続先のアドレスを調べる仕組みだ。AレコードはIPv4アドレス、AAAAはIPv6アドレスを対応させ、CNAMEは別のホスト名を指す。TXTには所有権確認などに使うテキスト値を入れる。DNS提供元の管理画面で、ホスティングサービスが要求するレコードを設定する。ドメインのルートでCNAME相当の接続を提供する方法は提供元によって異なる。ドメインとDNSの説明を参照する。

TTLはDNS応答を再利用できる期間を表す。アドレスを変更しても、古いレコードを保存したクライアントはTTLが残る間、旧サーバーに接続することがある。切り替え前に新サーバーで代表ドメインを受ける準備をし、切り替え後は旧・新の接続がどちらも意図したページを提供するか確認する。AAAAを登録したならIPv6経路も確認する。

HTTPSはTLSで保護するHTTP通信だ。証明書は接続したドメインの身元確認に使う。本番ドメインとwwwなど実際の接続名が証明書に含まれ、有効期限と自動更新が正常か確認する。証明書エラーがあると、ブラウザーやクローラーが本文を受け取る前に接続を中止することがある。TLSの説明に接続保護と証明書の役割がまとめられている。

代表URLはHTTPSにし、HTTP・wwwの別形式は決めたURLへ恒久転送する。DNSは接続先サーバーを指定し、HTTPリダイレクトは訪問者の移動先URLを指定する。ホスティングのドメイン設定とリダイレクト設定をそれぞれ確認する。画像・CSS・スクリプトのURLもHTTPSにそろえ、安全な接続内でHTTPリソースを読み込む混在コンテンツの問題を減らす。

CDN・プロキシ・WAFが公開文書を通すようにする

リバースプロキシはサーバーの手前でリクエストを受け、内部サーバーへ転送する中継サーバーだ。ロードバランサーはリクエストを複数サーバーに分配する。CDNのエッジはユーザーの近くでリクエストを処理する拠点だ。プラットフォームがこれらをまとめて提供する場合もあるため、まず現在のリクエストが通るサービスを図にする。

WAFはHTTPリクエストを検査し、攻撃と判断したものを遮断するファイアウォールだ。レート制限は一定時間内のリクエスト数を制限する。ボットチャレンジは、人によるクリックやブラウザーコードの実行を求める確認画面だ。公開記事の前にこの画面が出ると、クローラーは記事の代わりに確認案内を受け取る場合がある。

CDN・WAFのリクエストログから、遮断されたパス・時刻・ルール・ステータスコードを探す。公開記事とrobots.txt・サイトマップ・必要な画像が正常に届くよう該当ルールを調整する。管理者・下書きへの認証と攻撃遮断は維持する。検索ボットを許可する場合は、名前の文字列だけを信用せず、運用元のIP範囲や検証方法を適用する。

Googleのリクエストは公式IP一覧と照合できる。または逆引きDNSで名前を調べ、正引きDNSの結果が元のIPと一致するか確認する。Googleクローラーの検証方法にボットの種類ごとの確認方法がある。User-Agentはリクエスト元プログラムが送る識別文字列なので、他のプログラムも同じ名前を送れる。

プロキシが渡すホスト・プロトコル情報を使う場合は、信頼するプロキシの値だけを処理する。代表URLは確定した本番ドメイン設定から作る。CDNやプロキシがエラー応答を200に変えたり、存在しないパスをすべてホームに送ったりする設定も確認する。オリジンサーバーと前段の応答が異なる場合は、どの段階でステータスコード・ヘッダー・本文が変わったか比較する。

例えばブラウザーでは確認ボタンを押すと記事が開いても、自動クロールには確認画面だけが返ることがある。この場合、SSRで本文を作っていてもクローラーには届かない。オリジンの200とCDN経由の403または確認用HTMLを比較すれば、本文生成コードとアクセス遮断のどちらを直すべきか区別できる。

文書・移動・エラーを正しいステータスコードで返す

ステータスコードはHTTPリクエストの結果を3桁の数字で伝える。正常な記事は本文とともに200、恒久移転は301または308、存在しない文書は404を使う。410はリソースが恒久的に失われたことを示す。サービスの削除方針とフレームワークの対応に合わせて選ぶ。

ソフト404は、ステータスが200なのに空の文書やエラー案内に見える状態だ。存在しないslugをホーム画面に置き換えたり、DBエラーを空の記事として扱ったりすると発生し得る。実際に文書がない場合と一時的なクエリ失敗を区別して応答する。Googleのステータスコード処理は各コードがクロールに与える影響を説明している。

一時的なサーバー障害は5xx系で伝え、原因を復旧する。リクエスト数制限には429、一時的なサービス停止には状況に合った503を使える。Retry-Afterヘッダーは再リクエストまでの待ち時間や時刻を伝える。制限が繰り返されると正常なクロールも減る場合があるため、エラー率と処理容量を併せて確認する。

キャッシュの保存場所と更新条件を決める

キャッシュはブラウザー、CDN、アプリケーションのデータ取得結果、ページ生成結果にそれぞれ存在し得る。キャッシュキーは保存結果を探す基準だ。URL以外に言語・ユーザー・クエリで応答が変わるなら、その違いをキーに含めるか共有保存を避ける。Cache-ControlはHTTPキャッシュを制御し、フレームワーク内部のデータキャッシュは別の設定で更新する。

max-ageは応答を新鮮なものとして再利用できる秒数、s-maxageはCDNなどの共有キャッシュに適用する期間だ。privateはユーザー別キャッシュだけに保存させ、no-storeは応答の保存を禁止する。no-cacheは保存を許すが、再利用前にサーバーで有効性を確認させる。似た名前でも動作が異なるため、HTTPキャッシュの説明に従ってレスポンスヘッダーを選ぶ。

ETagはレスポンスの版を識別する検証値で、Last-Modifiedは更新時刻だ。保存値による条件付きリクエストで内容が同じなら、サーバーは304を返せる。Varyは、どのリクエストヘッダーによって応答が変わるかをキャッシュに伝える。プラットフォームが必要とするVary値を勝手に消すと、異なるリクエストの応答が混ざることがある。HTTPキャッシュ標準で検証と保存の条件を確認する。

stale-while-revalidateは、一定範囲で古い応答を返しながら裏で更新する条件だ。immutableは有効期間中に内容が変わらないリソースに使う指示だ。ファイル名に内容ハッシュがある公開CSS・JavaScriptには長いキャッシュが適する場合がある。修正・撤回が必要な本文や写真では、許容する残存時間と無効化方法を先に決める。

再検証は保存内容がまだ有効かを確認したり、新しい結果を作ったりする作業だ。無効化・パージは古いキャッシュを使わせない処理を指す。CMSでの公開後、詳細・一覧・サイトマップのデータとページキャッシュを更新する。外部CDNが別途保存するなら、その更新もつなぐ。Next.jsのキャッシュガイドをインストール済みバージョンに合わせて適用する。

撤回直後にアクセスを止める必要がある資料は、キャッシュが残っていても公開判定を経るよう設計する。ブラウザーが既にダウンロードしたファイルまでサーバーが回収することはできない。サーバーとCDNが新しいリクエストに返す内容と遮断時点を決め、複数地域、最初のリクエスト、再リクエストで確認する。

閉館時刻が17時から16時に変わっても、CDNが古いHTMLを返せば変更後に訪れたクローラーも17時と読む。サイトのdateModifiedだけを今日に変えても、届ける事実は古い値のままかもしれない。そのため保存後にキャッシュを更新し、実際の応答の時刻とrevisionを確認する。その後、外部検索の最新クロール時刻と引用された原文を比較する。

環境変数・デプロイ・ログを本番URLに合わせる

環境変数はコードの外から注入する設定値だ。本番ドメイン、DB接続先、ストレージキーなどを開発・プレビュー・本番で分ける。Next.jsのNEXT_PUBLIC_で始まる値はブラウザーコードに含まれる場合があり、ビルド時に固定される。秘密鍵はサーバー専用値にする。公開URLを生成する設定は本番ドメインに合わせる。

CIは変更統合時に検査・ビルドを自動実行する過程で、CDは成果物をデプロイ可能にする、またはデプロイする過程だ。アーティファクトはビルドで作ったデプロイ用ファイルを指す。検査した成果物と実際にデプロイした成果物が同じであることをバージョン識別子で結び付ける。

プレビュー・ステージングは本番前の確認環境だ。本番データと秘密値の使用範囲を決め、認証でアクセスを制限する。この環境の検索除外設定が本番にコピーされていないか確認する。本番ドメインの接続を変更したら、そのドメインで本文・ヘッダー・アセットを再リクエストする。

ログはリクエストと処理結果の記録だ。ステータスコード・パス・処理時間・応答量・デプロイ版を記録し、リクエストIDでCDN・アプリケーション・DB処理を結び付ける。タイムアウトは指定時間内に終わらず作業を中止した状態だ。本文生成が遅い場合、DBクエリ・外部API・画像処理の時間を分けて調べる。

監視はエラー率や遅延などを継続して観測する作業で、アラートは定めた条件を超えたとき担当者に知らせる機能だ。正常な公開記事の5xx増加、証明書期限切れ、公開後のキャッシュ更新失敗を監視する。障害時に使う以前のデプロイとDBバックアップを決め、復旧後に実際の公開URLを再確認する。

公開文書とユーザー別応答のキャッシュを分ける

誰に対しても応答が同じで一定の遅延を許容できるなら、共有キャッシュを使える。ログイン状態で変わる応答や即時撤回が必要な資料では、共有保存を避けるか、返す前に権限を確認する構造を選ぶ。フレームワークのヘッダーを前段で上書きする場合は、その動作も検討する。

例えばユーザーの非公開資料はCache-Control: private, no-storeで保存を防げる。内容変更時にURLも変わる公開アセットには、長いmax-ageとimmutableを使える。公開HTMLのキャッシュ期間は許容する更新遅延と無効化手段を決めてから選ぶ。HTTPヘッダーを変えても、内部のDBクエリキャッシュが自動更新されるわけではない。

公開完了後にキャッシュを更新する

実習の現在の記事ルートはforce-dynamicでリクエストごとにレンダリングする。CMSクエリをキャッシュする場合や静的・ISRルートを運用する場合は、保存完了後に再検証を呼ぶ。以下の関数は認証と権限検査を終えたサーバーの公開処理で使う。

// lib/refresh-guide.ts — cacheComponents: false 構成 import { revalidatePath } from 'next/cache' export function refreshGuide(slug: string) { if (!/^[a-z0-9]+(?:-[a-z0-9]+)*$/.test(slug)) { throw new Error('Invalid slug') } revalidatePath(`/guides/${slug}`) revalidatePath('/') revalidatePath('/sitemap.xml') } // 順序：ユーザー権限を確認 → 公開DB保存を完了 → refreshGuide(slug)

revalidatePathは指定パスの再検証を要求する。呼び出し位置とキャッシュ構成によっては、次回訪問で更新される。別のCDNにはそのプラットフォームの無効化経路を使う。複数ページが同じタグのデータを読む場合、タグ単位の更新も検討する。revalidatePathのガイドの適用範囲と、実際の最初の再リクエストを比較する。

Cache Componentsを有効にした構成では、cacheLife・cacheTag・revalidateTag・updateTagの寿命と呼び出し位置を別途選ぶ。古い内容を先に返す再検証と即時期限切れは動作が異なる。撤回時には、オリジンに届く前にCDNが古い文書を返していないかも確認する。再検証ガイドは使用中のキャッシュモデルを区別して読む。

この関数をサーバー公開処理のDB保存完了後に呼ぶ。slugを検査してから詳細・ホーム・サイトマップのキャッシュを更新する。DB保存前に呼ぶと、まだ変わっていない内容を再びキャッシュすることがある。保存後の再リクエストで旧revisionが見えるなら、Next.jsキャッシュと外部CDNを別々に確認する。DB接続サービスでは公開・撤回後に詳細・一覧・サイトマップを再リクエストし、公開状態と内容を比較する。

詳細だけを再検証すると、ホームの要約やサイトマップの日付は古いままかもしれない。refreshGuideが詳細・ホーム・サイトマップをまとめて対象にするのは、1回の公開で変わる公開出力を一緒に更新するためだ。各ルートが読む資料やキャッシュが増えたら、そのルートもこの更新関係に含める。

元データと公開応答からキャッシュ障害を切り分ける

公開データ実習の2つ目のテストは、同時点の元データ取得とキャッシュ取得を比較する。元データの開館時間が10–16時でキャッシュが10–17時なら、原稿保存は成功したが配信更新が失敗している。この場合、編集者に再保存を求めず、失敗したパスのキャッシュを無効化する。

撤回後に詳細が404を返しても、一覧とサイトマップのキャッシュに記事が残る場合がある。メモリーキャッシュはclearCacheで消去する。CDNも使う場合は、公開作業に文書ID・revision・更新対象パスを記録し、CDNの無効化APIを呼ぶ。失敗したリクエストは再試行する。撤回直後にCDNのURLでも404またはアクセス遮断が返るか確認する。

HTTPの保存禁止とサーバーの画像再利用を併せて読む

画像を受け取るたびに変換すると、同じ元画像を繰り返しデコード・エンコードする。変換結果をサーバー内部に保存すれば、この負荷を減らせる。HTTPレスポンスのno-storeは、受信側のキャッシュに保存しないよう指示するものだ。サーバーが自身の非公開ストレージで同じ派生ファイルを再利用する場合とは、保存場所とアクセス経路が異なる。Cache-Control

画像実習で/media/photo?w=640を2回リクエストすると、両方の応答にprivate, no-store, max-age=0がある。サーバーのtransforms値は1だ。2回目も画像バイトを受け取るが、サーバーは再変換しない。転送量の削減は小さなWebPを送る効果で、サーバー作業の削減は変換結果を再利用する効果だ。

撤回可能な資料には、リクエストごとに現在の公開状態を確認する経路が必要だ。既に公開CDNへ保存したファイルは、オリジンの公開判定を経ず配信される場合がある。一方、永久公開のロゴのように内容ハッシュでURLを固定したアセットでは、長期キャッシュが転送削減に適する場合がある。ファイルの変更・撤回要件を決め、応答キャッシュとストレージを選ぶ。

実習ストレージのsetPublishedはプロセス内部の状態を変える。DB使用環境では、公開トランザクション完了後に新しいリクエストがその状態を読むか確認する。外部CDNを追加したなら、撤回後に元画像・派生画像のURLをCDN経由でもリクエストし、残存ファイルと無効化結果を確認する。