Next.jsアプリケーションをセルフホストする方法

Next.jsアプリをデプロイする際に、インフラストラクチャに基づいてさまざまな機能の処理方法を設定することができます。

🎥 動画を見る： Next.jsのセルフホスティングについて詳しく学ぶ → YouTube（45分）。

画像最適化

next/imageを通じた画像最適化は、next startを使用してデプロイする際にゼロ設定でセルフホスト環境で動作します。画像を最適化するための別のサービスを用意したい場合は、画像ローダーを設定できます。

画像最適化は、next.config.jsでカスタム画像ローダーを定義することで静的エクスポートと共に使用できます。画像はビルド時ではなく、実行時に最適化されることに注意してください。

補足：

glibcベースのLinuxシステムでは、画像最適化により過剰なメモリ使用を防ぐために追加設定が必要な場合があります。

最適化された画像のキャッシング動作とTTLの設定方法について詳しく学習してください。

必要に応じて画像最適化を無効化して、next/imageを使用する他の利点を保持することもできます。例えば、画像を別途自分で最適化している場合です。

Proxy

Proxyは、next startを使用してデプロイする際にゼロ設定でセルフホスト環境で動作します。受信リクエストへのアクセスが必要なため、静的エクスポートを使用する場合はサポートされていません。

ProxyはEdge runtimeを使用します。これはすべての利用可能なNode.js APIのサブセットで、アプリケーションの全ルートまたはアセットの前で実行される可能性があるため、低レイテンシーを保証するのに役立ちます。これが不要な場合は、完全なNode.js runtimeを使用してProxyを実行できます。

すべてのNode.js APIが必要なロジック（または外部パッケージの使用）を追加したい場合は、このロジックをServer Componentとしてレイアウトに移動できる可能性があります。例えば、ヘッダーを確認してリダイレクトするなど。また、next.config.jsを通じてヘッダー、Cookie、またはクエリパラメーターを使用してリダイレクトまたはリライトすることもできます。それでもうまくいかない場合は、カスタムサーバーを使用することもできます。

環境変数

Next.jsはビルド時と実行時の両方の環境変数をサポートできます。

デフォルトでは、環境変数はサーバーのみで利用可能です。環境変数をブラウザに公開するには、NEXT_PUBLIC_の接頭辞を付ける必要があります。ただし、これらの公開環境変数はnext build中にJavaScriptバンドルにインライン化されます。

動的レンダリング中にサーバー上の環境変数を安全に読み込むことができます。

app/page.ts

TypeScript

import { connection } from 'next/server'
 
export default async function Component() {
  await connection()
  // cookies、headers、およびその他のDynamic APIは
  // 動的レンダリングにもオプトインします。つまり、
  // この環境変数は実行時に評価されます
  const value = process.env.MY_VALUE
  // ...
}

これにより、異なる値を持つ複数の環境を通じて昇格できる単一のDockerイメージを使用できます。

補足：

register関数を使用してサーバー起動時にコードを実行できます。

キャッシングとISR

Next.jsはレスポンス、生成された静的ページ、ビルド出力、および画像、フォント、スクリプトなどの他の静的アセットをキャッシュできます。

ページのキャッシングとリバリデーション（増分静的再生成を使用）は、同じ共有キャッシュを使用します。デフォルトでは、このキャッシュはNext.jsサーバー上の（ディスク上の）ファイルシステムに保存されます。これはセルフホスティング時に自動的に動作します。Pages RouterとApp Routerの両方を使用する場合です。

キャッシュされたページとデータを永続的なストレージに保持したり、Next.jsアプリケーションの複数のコンテナまたはインスタンス間でキャッシュを共有したりする場合は、Next.jsキャッシュの場所を設定できます。

自動キャッシング

Next.jsは、真に不変のアセットに対してCache-Controlヘッダーをpublic, max-age=31536000, immutableに設定します。これはオーバーライドできません。これらの不変ファイルには、ファイル名にSHAハッシュが含まれているため、無期限に安全にキャッシュできます。例えば、静的画像インポート。画像のTTLを設定できます。
増分静的再生成（ISR）はCache-Controlヘッダーをs-maxage: <getStaticPropsで再検証>, stale-while-revalidateに設定します。この再検証時間は、秒単位でgetStaticProps関数で定義されます。revalidate: falseを設定した場合、デフォルトで1年のキャッシュ期間になります。
動的にレンダリングされたページはCache-Controlヘッダーをprivate, no-cache, no-store, max-age=0, must-revalidateに設定して、ユーザー固有のデータがキャッシュされるのを防ぎます。これはApp RouterとPages Routerの両方に適用されます。これにはドラフトモードも含まれます。

静的アセット

静的アセットを別のドメインまたはCDNでホストしたい場合は、next.config.jsのassetPrefix設定を使用できます。Next.jsはJavaScriptまたはCSSファイルを取得する際にこのアセットプレフィックスを使用します。アセットを別のドメインに分離すると、DNS とTLS解決に追加の時間が費やされるという欠点があります。

assetPrefixについてさらに詳しく学ぶ。

キャッシングの設定

デフォルトでは、生成されたキャッシュアセットはメモリ（デフォルト50MB）およびディスクに保存されます。Kubernetesなどのコンテナオーケストレーションプラットフォームを使用してNext.jsをホストしている場合、各ポッドはキャッシュのコピーを持ちます。デフォルトではポッド間でキャッシュが共有されないため、古いデータが表示されるのを防ぐために、Next.jsキャッシュを設定してキャッシュハンドラーを提供し、メモリ内キャッシングを無効化できます。

セルフホスティング時にISR/Data Cacheの場所を設定するには、next.config.jsファイルでカスタムハンドラーを設定できます：

next.config.js

module.exports = {
  cacheHandler: require.resolve('./cache-handler.js'),
  cacheMaxMemorySize: 0, // デフォルトのメモリ内キャッシングを無効化
}

次に、プロジェクトのルートにcache-handler.jsを作成します（例：）：

cache-handler.js

const cache = new Map()
 
module.exports = class CacheHandler {
  constructor(options) {
    this.options = options
  }
 
  async get(key) {
    // これは永続的なストレージなど、どこにでも保存できます
    return cache.get(key)
  }
 
  async set(key, data, ctx) {
    // これは永続的なストレージなど、どこにでも保存できます
    cache.set(key, {
      value: data,
      lastModified: Date.now(),
      tags: ctx.tags,
    })
  }
 
  async revalidateTag(tags) {
    // tagsは文字列または文字列の配列のいずれかです
    tags = [tags].flat()
    // キャッシュ内のすべてのエントリを反復処理します
    for (let [key, value] of cache) {
      // 値のタグに指定されたタグが含まれている場合は、このエントリを削除します
      if (value.tags.some((tag) => tags.includes(tag))) {
        cache.delete(key)
      }
    }
  }
 
  // 単一のリクエスト用のメモリ内の一時キャッシュを持ちたい場合、
  // 次のリクエストの前にリセットされます。このメソッドを活用できます
  resetRequestCache() {}
}

カスタムキャッシュハンドラーを使用することで、Next.jsアプリケーションをホストするすべてのポッド間で一貫性を確保できます。例えば、キャッシュされた値をRedisやAWS S3などの任意の場所に保存できます。

補足：

revalidatePathはキャッシュタグの上の便利なレイヤーです。revalidatePathを呼び出すと、提供されたページの特別なデフォルトタグを使用してrevalidateTag関数を呼び出します。

ビルドキャッシュ

Next.jsはnext build中にIDを生成して、提供されているアプリケーションのバージョンを識別します。同じビルドが使用され、複数のコンテナでブートアップされるべきです。

環境のステージごとにリビルドしている場合、コンテナ間で使用する一貫したビルドIDを生成する必要があります。next.config.jsのgenerateBuildIdコマンドを使用してください：

next.config.js

module.exports = {
  generateBuildId: async () => {
    // これは何でもかまいません。最新のgitハッシュを使用しています
    return process.env.GIT_HASH
  },
}

バージョンスキュー

Next.jsはバージョンスキューのほとんどのインスタンスを自動的に軽減し、検出時に自動的にアプリケーションをリロードして新しいアセットを取得します。例えば、deploymentIdに不一致がある場合、ページ間の遷移はプリフェッチされた値を使用するのではなく、ハードナビゲーションを実行します。

アプリケーションがリロードされる場合、ページナビゲーション間で永続化するように設計されていない場合、アプリケーション状態が失われる可能性があります。例えば、URLの状態またはローカルストレージを使用すると、ページ更新後に状態が永続化されます。ただし、useStateのようなコンポーネント状態は、そのようなナビゲーションで失われます。

ストリーミングとSuspense

Next.js App Routerはセルフホスティング時にストリーミングレスポンスをサポートします。Nginxまたは類似のプロキシを使用している場合、ストリーミングを有効にするためにバッファリングを無効化するように設定する必要があります。

例えば、Nginxでバッファリングを無効化するには、X-Accel-Bufferingをnoに設定します：

next.config.js

module.exports = {
  async headers() {
    return [
      {
        source: '/:path*{/}?',
        headers: [
          {
            key: 'X-Accel-Buffering',
            value: 'no',
          },
        ],
      },
    ]
  },
}

キャッシュコンポーネント

キャッシュコンポーネントはNext.jsでデフォルトで動作し、CDN専用機能ではありません。これには、Node.jsサーバー（next startを通じて）でのデプロイおよびDockerコンテナで使用する場合が含まれます。

CDNとの使用

Next.jsアプリケーションの前にCDNを使用している場合、動的APIがアクセスされると、ページにCache-Control: privateレスポンスヘッダーが含まれます。これにより、結果のHTMLページがキャッシュ不可としてマークされることが保証されます。ページが静的に完全に事前レンダリングされている場合、ページをCDNでキャッシュできるようにするためにCache-Control: publicが含まれます。

静的コンポーネントと動的コンポーネントの両方の混合が不要な場合は、ルート全体を静的にして、出力HTMLをCDNにキャッシュできます。この自動静的最適化は、動的APIが使用されていない場合、next buildを実行するときのデフォルト動作です。

部分的な事前レンダリングが安定版になるにつれて、Deployment Adapters APIを通じてサポートを提供します。

`after`

afterはnext startでセルフホスティングする場合に完全にサポートされています。

サーバーを停止するときは、SIGINTまたはSIGTERMシグナルを送信してグレースフルシャットダウンを実行し、待機します。これにより、Next.jsサーバーがafter内で使用される保留中のコールバック関数またはプロミスが完了するまで待機できます。