このLinuxトリックでNext.jsのクラッシュを防ぐ

新しいUbuntuドロップレットで`next build`を実行すると、最初の10秒間はすべてが順調に見えます。しかし、その後すぐに負荷平均が急上昇し、CPUが100%に達し、SSHセッションはまるで悪いZoomコールのように文字を落としてしまいます。1分後、ターミナルが戻ると、1つの苛立たしい言葉が表示されます：「Killed.」

スタックトレースも、整然としたエラーコードもなく、ただビルドが死んでいる。再度実行すると、同じパターンが繰り返される：ファンが回り始め、上部にはノードとCPUをむさぼり食う作業員の群れが表示され、その後静寂が訪れる。プロバイダーのグラフを確認すると、CPUとメモリの急上昇が見られ、その後プロセスが消えた崖が続いている。

この障害モードは、クラウドの安価なプランに最も影響を与えます。DigitalOcean、Vultr、Linode、またはLightsailの月額$5〜$7の1 GB RAMインスタンスは、基本的なNodeアプリには最適ですが、現代のNext.jsビルドを実行させようとすると問題が発生します。そのビルドウィンドウ中、あなたの「小さくて力強い」ドロップレットは、まるでChromeをコンパイルしようとしているRaspberry Piのように動作します。

開発者は通常、クラウドコンピューティングで最も高価な反射でこれに対応します：ハードウェアが問題だと仮定することです。話の展開は毎回同じです。ビルドが失敗し、サーバーは凍ったように感じ、直感的な反応は「このボックスではNext.jsを扱えない。2GB、もしくは4GBが必要だ。」となります。

クラウドダッシュボードは、あなたをそこに導きます。メモリがいっぱいになり、CPUが最大限に達し、ログには赤い「メモリ不足」のイベントが表示されます。アップグレードボタンはワンクリックで、より大きなインスタンスタイプがその問題を解決する約束をしています。多くのチームにとって、そのクリックはデプロイメントの手順の一部となります。

現実はより華やかではなく、ずっと安価です。これらのクラッシュは通常、あなたのアプリが恒久的により大きなマシンを必要としていることを意味するのではなく、ビルドステップが一時的にあなたのドロップレットが利用できるメモリよりも多くを必要としていることを意味します。そして、スワップが無効になっているデフォルトのUbuntuイメージでは、カーネルがそのスパイクに対処するための信頼できる方法は一つだけです：あなたのビルドを終了させることです。

Next.jsは`htop`上では単一の`node`プロセスのように見えますが、`next build`はむしろ1つのバイナリに詰め込まれた小さな分散システムのように振る舞います。内部では、Next.jsは複数のNodeワーカー、TypeScriptツールチェーン、バンドラー、アセットパイプラインを調整しており、すべてが同じ狭い1GBのRAMを競い合っています。

Node自体から始めましょう。メインプロセスは、ページコンパイルを並列化するために、いくつかのワーカースレッドまたは子プロセスを起動します。各ワーカーは、自身の依存関係グラフのチャンク、V8ヒープ、およびビルドメタデータをロードします。200〜300 MBのプロセスが1つだけではなく、いくつかが一時的に立ち上がり、それぞれのピークが積み重なります。

次に、TypeScriptの話です。TypeScriptプロジェクトで`next build`を実行すると、ツールチェーンはTypeScriptコンパイラをロードし、コードベース全体を解析して型チェックを行います。これは、複数の大きなAST、シンボルテーブル、およびキャッシュが同時にメモリに存在し、中規模のプロジェクトではしばしば数百メガバイトを消費することを意味します。

さらに、Next.jsはバンドラー（WebpackまたはTurbopack）を呼び出して、クライアントとサーバーのバンドルを生成します。各ターゲットには独自の依存関係グラフ、最適化処理、ソースマップが必要です。大規模なコンポーネントライブラリ、UIフレームワーク、デザインシステムはこれらのグラフを膨らませるため、300〜400 MBで本番動作するプロジェクトが、ビルド中に800〜900 MB以上に達することがあります。

次に、画像と静的アセットについてです。next/imageを有効にしたり、大きなメディアを処理したりすると、ビルドパイプラインがファイルをデコード、リサイズ、再圧縮します。画像操作はメモリを多く消費します：数枚の4Kヒーロー画像やスプライトシートが、ディスクに書き戻される前に、ワーカーごとに一時的に数十MBから数百MBを占有することがあります。

すべては数秒から数分の短い時間に発生します。20席のコーヒーショップが突然60人のフラッシュモブを迎えることを想像してください。通常の客の流れは問題ありませんが、その短く混沌とした爆発的な動きは出入口を塞ぎ、スタッフを圧倒し、常連客を外に閉じ込めてしまいます。`next build`は、1 GBのドロップレット上でちょうどそのような時間的過負荷を生み出します。

1 GBのUbuntuサーバーでスワップが無い状態では、そのフラッシュモブがメモリ使用量を物理的な限界を超えて押し上げます。カーネルは積極的にメモリを再利用し始め、キャッシュは消え、まだ十分なRAMを見つけられない場合は、OOMキラーが介入し、最も重いプロセスを終了させます。あなたの`次のビルド`は、一言の墓碑銘とともに死にます：`Killed`。

OOMキラーという名称は、その名の通り劇的です。Linuxシステムが物理RAMを使い果たすと、カーネルのアウトオブメモリー（OOM）キラーが最後の手段として登場し、すべての実行中プロセスをスキャンして、マシン全体がフリーズしないように犠牲にするプロセスを決定します。これがなければ、メモリ圧迫下の1GBのUbuntuドロップレットは単にフリーズし、SSHセッションが切断され、無反応のターミナルと強制再起動を余儀なくされるでしょう。

Next.jsのビルドは完璧なターゲットになります。`next build`中、Nodeは複数のワーカープロセスを生成し、TypeScriptのようなコンパイラを読み込み、バンドルを圧縮し、時には画像を処理し、短時間で基準を数百メガバイト上回るメモリ使用を簡単に引き起こします。カーネルにとって、それは大きく、最近の、そして重要でないプロセスのように見え、最小限の「システム全体」への影響で終了させることができます。

Linuxは、被害者をランク付けするためにoom_score（およびoom_score_adj）というヒューリスティックを使用します。最近大量のメモリを割り当てた大きなプロセスで、rootとして実行されず、コアシステムサービスに属さないものが上位に浮上します。1 GBのドロップレットでのNext.jsのビルドは、nginx、sshd、そしておそらく小さなデータベースの隣にあることが多く、RAM内で最も大きく、最も廃棄可能なものとなります。

スワップなしでは状況が完全に変わります。RAMが100%に達し、スワップが全く設定されていない場合、カーネルはページを必死に回収しながら待機するか、OOMキラーを呼び出すかの二択しかありません。この2つの選択肢が、あなたのターミナルが少しハングしてから「Killed」という一言を吐き出し、スタックトレースも、Next.jsエラーも、Nodeからの有益なヒントもない理由を説明しています。

その「Killed」ラインはnpmが失礼なわけではなく、カーネルのシグネチャです。これは、OOMキラーがプロセスを途中で終了させる際に、失敗した`pnpm install`、`npm install`、または`next build`の実行で見ることができます。システムログ（`dmesg`や`journalctl -k`）には、「Out of memory: Kill process 1234 (node) score 900 or sacrifice child.」といったエントリが含まれており、原因を示しています。

スワップはカーネルに別の動作を提供します。1～2GBのスワップファイルがあれば、システムはコールドページ（アイドル状態のデーモン、キャッシュページ、あまり使用されないライブラリ）をディスクに移動させることができ、RAMを解放してビルドを完了させることができます。ビルドが切り捨てられるのを防ぎます。ステップバイステップのガイダンスについては、How to create swap file to deploy NextJS and Docker app on Ubuntu VPSのようなリソースが生産向けの設定を説明しています。

スワップスペースは、小さなサーバーのメモリに対する圧力弁のような役割を果たします。RAMが100%に達した際にすぐに`next build`を終了させるのではなく、Linuxカーネルは余分なデータを専用のディスクの一部に流し込み、処理を続けることができます。その部分があなたのスワップファイルです。

スワップを「ストレージ上に存在するオーバーフローRAM」と考えてください。Linuxはディスク上にファイルまたはパーティションを作成し、これを物理メモリの拡張として扱います。この際、通常のRAMが使用するのと同じ4KBのページ単位で測定されます。

1 GBのDropletがNext.jsのビルド中にRAMが不足すると、カーネルはトリアージを開始します。アイドル状態のデーモン、古いキャッシュ、またはバックグラウンドサービスに属するページはRAMからスワップファイルに移動し、ビルドのホットコードパスのために実メモリを解放します。

カーネルは、仮想メモリマネージャーを通じてこれを自動的に行います。アプリを再構築したり、Nodeフラグを触ったりする必要はありません。スワップが存在し、アクティブになると、システムはあまり使用されていないページを静かに移動させ、最も多くの作業を行っているタスクのために最速のメモリを確保します。

ディスクはRAMと比べて遅く、ミリ秒単位で動作し、ナノ秒単位ではありません。そのため、スワップを使用すると常に遅延が発生します。しかし、短命のビルドの場合、安定性が速度を上回ります。スワッピングサーバーで90秒で完了する `next build` は、20秒後に「Killed」という単語だけで終了するものよりも遥かに優れています。

スワップが設定されたサーバーでは、その同じ厳しいメモリスパイクが退屈に見えます。CPUは依然として上昇し、ファンは回転し続けますが、SSHセッションは応答し続け、`top`はスワップ使用量が増加しているのを示し、ビルドはプロセステーブルが爆発する代わりに進行します。

スワップのないサーバーでは、カーネルに逃げ道がありません。RAMが満杯になると、再利用可能なページを探すためにスローダウンするか、OOMキラーを起動して、Nodeやパッケージマネージャー、あるいは他の expendable と見なされるものを終了させて生き延びることになります。

その対比は鮮明です：スワップを使用すると、ビルドは重く感じますが信頼性があります。一方、スワップなしでは、同じ作業負荷がシェルをフリーズさせ、デプロイを壊し、再起動されたドロップレットを監視しなければならなくなります。

まず、あなたのUbuntuボックスにスワップがすでにあるか確認します。`sudo swapon --show`を実行してください。結果が空の場合、アクティブなスワップデバイスはありません。次に、`free -h`を実行して、総RAMと現在のスワップを確認し、`df -h`でディスク使用量をチェックします。一般的な25GBのドロップレットでは、通常20%未満の使用率が見られるため、2GBのスワップファイルを作成するための余裕があります。

ディスクスペースが確認できたら、スワップファイルを割り当てます。1GBのRAMサーバーには、2GBのファイルを用意することで、Next.jsのビルドに十分な余裕を持たせ、ディスクのスラッシングを防ぎます。`sudo fallocate -l 2G /swapfile`を使用します。これにより、0を書き込むことなく瞬時に2GBを予約します。`ls -lh /swapfile`で確認し、サイズの列に`2.0G`が表示されることを確認してください。

現在、`/swapfile` は誰でも触れられる一般的なファイルです。管理者だけが読み書きできるように制限しましょう。`sudo chmod 600 /swapfile` を実行します。その後、`ls -lh /swapfile` で再度権限を確認すると、行の先頭に `-rw-------` と表示され、ファイルが管理者専用であることが確認できます。

次に、そのプレーンファイルを実際のスワップスペースに変換します。`sudo mkswap /swapfile`を入力してください。Ubuntuは「スワップスペースバージョン1を設定中、サイズ = 2 GiB」といったメッセージで応答します。このメッセージは、カーネルが現在`/swapfile`を有効なスワップ領域として認識したことを意味しますが、明示的に有効にするまでまだ非アクティブです。

単一のコマンドでスワップを有効にします： `sudo swapon /swapfile`。再度 `sudo swapon --show` を実行すると、`/swapfile`、そのサイズ（約 `2G`）、およびその優先度を示すテーブルが表示されるはずです。`free -h` でも要約に `Swap: 2.0Gi` が表示され、Next.js のビルドが急増した際にカーネルがメモリページをオフロードできることが確認されます。

現在、この設定は再起動後も持続するためには永続的にする必要があります。`/etc/fstab`を`sudo nano /etc/fstab`で編集し、下部に1行追加してください:

- `/swapfile none swap sw 0 0`

保存して終了すれば完了です。次回の再起動時には、Ubuntuが自動的に `/swapfile` を有効にするので、カーネルのアップデート、再起動、または予期しないクラッシュ後もNext.jsのビルドが正常に動作し続けます。

作成したスワップは、現在のブートの間だけ存在します。`swapon /swapfile` コマンドはランタイムスイッチを切り替えます。カーネルが再起動すると、その状態は消失し、あなたの Next.js ビルドは再び `Killed` で失敗します。

再起動時にもスワップをオンラインのまま維持するには、`/etc/fstab`に登録する必要があります。これはLinuxがブート時に読み込むファイルシステムテーブルです。このファイルはカーネルに対して、どのディスク、パーティション、そしてスワップ領域を自動的にマウントするかを指示します。

触る前にバックアップを取ってください。壊れた `/etc/fstab` はサーバーの起動を完全に妨げる可能性があり、クラウドダッシュボードで復旧コンソールを探し回る羽目になるかもしれません。

走る:

- `sudo cp /etc/fstab /etc/fstab.bak`

ルート権限のあるエディタでファイルを開いてください。例えば：

- `sudo nano /etc/fstab`

ページの一番下までスクロールして、次の行を正確に追加してください：

- `/swapfile none スワップ sw 0 0`

すべてのフィールドは重要です。`/swapfile`はあなたのスワップファイルのパスです。`none`はマウントポイントを表します。なぜなら、スワップはディレクトリツリーにマウントされないからです。

`swap`はファイルシステムタイプを宣言し、これによりカーネルはこのエントリが仮想メモリであり、ext4やxfsではないことを認識します。`sw`はマウントオプションで、デフォルトの動作でこれをスワップとして扱うことを示す略語です。

最後の2つのゼロは、`dump` と `fsck` の動作を制御します。`0 0` は、このファイルに対してダンプやファイルシステムチェックを試みないことを意味し、これがスワップにとって望ましい設定です。

保存後、以下のコマンドで構文を検証してください：

- `sudo mount -a`

出力がない場合、通常は成功を意味します。`sudo reboot` で再起動し、その後 `free -h` または `swapon --show` を使用して持続性を確認してください。スワップパフォーマンスの詳細な調整や背景については、スワップ領域でLinuxシステムを加速する - Kite Metricをご覧ください。

スワップはメモリの圧力弁のように機能し、無料のパフォーマンスアップグレードではありません。慎重に使うことで、Next.jsのビルドが完了するまで、わずか1GBのドロップレットを生かしておくことができますが、無造作に使用すると、プロダクションアプリを疲弊させてしまう可能性があります。

swapを使用するタイミング: 短期間で急激なメモリのスパイクがあります。2〜5分間実行される`next build`は、700〜800 MBから1.3〜1.5 GBに一時的に使用量を押し上げるのに最適です。カーネルは古いページをディスクに追放し、数百メガバイトを解放できるため、ビルドが「Killed」となることなく完了します。

同じルールは、稀に実行されるがリアルタイムトラフィックに供されない他のバーストタスクにも適用されます。良い候補には以下が含まれます： - `npm install`、`pnpm install`、または `yarn install` - データベースのマイグレーションや一時的なデータインポート - 時折実行される管理やメンテナンス用のスクリプト - コンテナやCIエージェントでのデプロイ時のステップ

これらのケースでは、アプリは物理RAMのはるか下にアイドル状態で、1GBのサーバーでは約300〜500MBで動作し、ビルドやインストール中にのみ追加の余裕が必要です。信頼性のために少し速度を犠牲にします：ビルドはスワップを使用すると20〜40%遅れる可能性がありますが、実際には完了します。多くのチームにとって、小さなドロップレットに留まることはそのコストをすぐに相殺します。

スワップを使用しないべき時：コアアプリからの定常状態のメモリ圧迫。もしあなたのNext.jsサーバーとデータベースが、1GBのインスタンス上で常に1.4GBを要求しているなら、カーネルは常にRAMとディスクの間でメモリページをシャッフルしています。このスラッシングはパフォーマンスを破壊します。なぜなら、ディスクはSSDであってもRAMに比べて桁違いに遅いためです。

有害なスワッピングをいくつかの具体的な症状で見分けることができます： - 低リクエストボリュームでも高いディスクI/O（`iostat`、`iotop`） - ごく少数のユーザーだけでのHTTPレスポンスが遅いまたはタイムアウト - `free -h` で数百メガバイトのスワップが使用されており、アイドル時にはほとんど減少しない - CPU使用率は奇妙に控えめなままで、負荷平均が急上昇する

その赤信号が現れた場合、スワップは弾丸の傷にバンデージを巻くようなものです。本当の解決策はより多くのRAMか、より厳しいメモリ予算です：Nodeワーカーを削減し、キャッシュサイズを減少させ、サービスを分割するか、データベースをオフボックスに移動してください。スワップはまれなスパイクに対応すべきであり、あなたのアプリを24時間365日運営すべきではありません。

スワップはあなたに余裕をもたらしますが、もう一人の静かな破壊者があなたのビルドを崩壊させる可能性があります。それはNode.js自体です。Nodeが1GBのサーバーで8GBのヒープを「必要」と判断した場合、どんなにスワップの妙技を駆使してもOOMキラーからは逃れられません。そこで、1つの obscure フラグがすべてを変えるのです。

Nodeの`--max-old-space-size`フラグは、V8エンジンが使用できるメインJavaScriptヒープのメモリ量をメガバイト単位で制御します。この制限が高すぎると、Nodeはあなたのマシンには存在しないメモリを積極的に予約し、RAMとスワップが枯渇するとカーネルはプロセスを終了させます。

Next.jsプロジェクトは、しばしば`package.json`内にこの落とし穴を隠しています。`scripts`セクションに埋もれていると、次のようなビルドコマンドが見つかるかもしれません： - `"build": "NODE_OPTIONS='--max-old-space-size=8192' next build"`

1 GBのドロップレットでは、その8192 MBのヒープ目標は幻想です。Nodeは喜んでそこまで登ろうとしますが、あなたの1 GBのRAMとおそらく1～2 GBのスワップは消えてしまい、ビルドは最初に見たのと同じ単純な`Killed`メッセージで終了します。

最初のステップ：プロジェクトの `package.json` を開き、すべての build 関連のスクリプトを確認します。 `NODE_OPTIONS` を設定したり、直接 `--max-old-space-size` を `node` または `next` に渡すものを探してください。例えば： - `"build": "NODE_OPTIONS='--max-old-space-size=4096' next build"` - `"build": "node --max-old-space-size=6144 node_modules/next/dist/bin/next build"`

その数字を実際の予算に合わせます：物理RAM + スワップ、OS、データベース、バックグラウンドサービスのオーバーヘッドを引いてください。1 GBのサーバーに2 GBのスワップファイルがある場合（合計約3 GB）、`--max-old-space-size=2048` の制限は通常理にかなっており、他のすべてに余裕を残します。

スクリプトを更新し、再インストールまたは再配備し、再度 `next build` を実行してください。スワップが有効になり、Nodeのヒープが現実的な値に制限されると、ビルドは64GBのワークステーションで実行されているふりをやめ、狭くて安価なドロップレットで動作しているようになります。

Swapは、不安定なNext.jsのビルドだけでなく、多くの問題を静かに解決します。小さなVPSや開発ボックスで時々メモリがスパイクするようなワークロードは、OOMキラーに直面する代わりに、数ギガバイトの仮想メモリをバックアップとして持つことで利益を得ます。

パッケージマネージャーはここで繰り返し問題を引き起こします。現代のモノレポでの単一の `npm install`、`pnpm install`、または `yarn install` は、数十のNodeワーカーを立ち上げ、何千ものtarballを展開し、メモリ内で依存関係ツリーを計算することができます。1GBのサーバーでは、数分間にわたり使用率が簡単に90〜100%のRAMを超えることがあります。

重いデータインポートおよびマイグレーションスクリプトは同じように動作します。数百メガバイトのJSONやCSVをメモリに読み込むETLジョブ、大規模なスキーマを水分補給するPrismaやTypeORMのマイグレーション、またはユーザーレコードをバッチ処理する臨時の管理スクリプトは、すべて短期間で厳しいメモリのスパイクを引き起こします。スワップが有効になっている場合、これらのスパイクはSSHセッションを爆発させるのではなく、遅くなります。

データベースツールもRAMに依存しています。数ギガバイトのPostgreSQLダンプに対して`pg_restore`を実行したり、MySQLスナップショットをインポートしたり、Elasticsearchの再インデックス処理を実行すると、一時的に数百メガバイトのバッファやキャッシュを割り当てることがあります。1〜2GBのスワップファイルは、カーネルが非アクティブなページを保持するための余裕を持たせ、ホットコードパスは実際のRAMに留まることができます。

コンテナ化された環境は、さらなる脆弱性を加えます。Next.jsアプリをビルドするDockerコンテナ、ネイティブモジュールをコンパイルする場合、またはテストを実行する場合、ホストが制限に達する前にcgroupメモリ制限に達することがあります。ホストレベルのスワップスペースは、カーネルがビルドの途中でコンテナを殺さないようにする最後のバッファとして機能することが多いです。

ローカル開発も免疫があるわけではありません。8 GBのノートパソコンで `next dev`、Storybook、データベース、そしてタブがいっぱいのブラウザーを同時に動かすと、すぐにメモリを消費してしまいます。ローカル開発環境を最適化する方法 - Next.js の実践を取り入れて、小さなスワップファイルを組み合わせることで、すべてがコンパイルされている間もマシンを応答性のある状態に保つことができます。

小さなサーバーのメモリ問題は、通常より大きなクレジットカードを必要としません。必要なのは診断です。月額5ドルの1GBドロップレットから月額20ドルのインスタンスに飛びつく前に、Next.jsのビルドが短期的なスパイクによるメモリ使用量の急増なのか、それとも常に緩やかなメモリの減少なのかを確認してください。

シンプルなメンタルフローチャートがあなたを正直に保つ：

- クラッシュは短時間で稀なタスク（Next.js ビルド、`npm install`、マイグレーション）中のみ発生しますか？ → まずスワップを追加し、その後タスクを再実行してください。 - 通常のトラフィック中にサーバーが遅く感じ、スワップ使用量が高く、遅延が増加していますか？ → メモリをプロファイリングし、クエリやキャッシュを最適化するか、RAMをアップグレードしてください。 - アプリが「アイドル」状態でもスワップ使用量が高いままですか？ → あなたは本当の容量の問題を隠しているだけで、それを解決していません。

バースト型のワークロードに対して、1GBのRAMボックスに1～2GBのスワップファイルを配置することで、OOMキラーがビルドを破壊するのを防ぐことができます。実際にビルドが完了するために、ビルド時間が数秒または数分長くなることを受け入れる価値があります。これは、デプロイが1日数回行われる場合にとっては良い選択肢です。何千回も毎秒行われる場合とは異なります。

コスト計算は論点を厳しく明確にします。月額$5のインスタンスを維持することで、$15に切り替えずに月$10、年間でサーバーごとに$120を節約できます。これを5つの小規模サービスに拡大すれば、たった一度の`fallocate`と`/etc/fstab`への行追加の代わりに、年間$600を手元に残すことができます。

スマートスケーリングとは、 reflexively 大きなボックスを購入するのではなく、ツールをスタックすることを意味します。稀なスパイクには swap を活用し、ビルドがまだ問題を起こす場合は Node.js のメモリフラグを調整して、安定した使用状況が実際に必要であることが証明されたときにのみ、ティアを上げてください。

あなたは恐れるのではなく、理解できるインフラを手に入れます。「Killed」と表示されたビルドが死んだとき、クラウドプロバイダーの料金ページを開く前に、メモリ、スワップ、Node.jsの制限を確認することを知っています。その知識により、スケーリングはパニック的な行動から意図的でコスト効果のある選択へと変わります。

なぜNext.jsのビルドはこれほど多くのメモリを使用するのですか？

Next.jsのビルドはメモリ集約型であり、TypeScriptのコンパイル、クライアントとサーバーコードのバンドル、画像などのアセットの処理を同時に行うために複数のワーカープロセスを生成します。この短期的ですが強烈なアクティビティのピークは、1GBのクラウドドロップレットのような限られたRAMを持つサーバーを簡単に圧倒してしまう可能性があります。

Linuxのスワップファイルを使用することはパフォーマンスに悪影響を与えるのでしょうか？

スワップはRAMよりも著しく遅いため、アプリケーションが日常的な操作で常にそれに依存していると、パフォーマンスに悪影響を及ぼす可能性があります。しかし、ビルドプロセスのような短時間の、まれなメモリのスパイクに対しては、わずかな遅延は安定性のために価値ある妥協であり、ビルドをクラッシュさせるのではなく成功裏に完了させることができます。

Next.jsのビルドのために、どのくらいのスワップスペースを追加するべきですか？

小型サーバー（1-2GB RAM）の良い目安は、物理RAMと同等またはその2倍のスワップスペースを追加することです。1GBのドロップレットの場合、1-2GBのスワップファイルを作成することで、Next.jsのビルド中に発生するメモリの急増に対処するのに十分です。

サーバーのRAMをアップグレードする代わりにスワップを使用できますか？

メモリの問題が一時的なスパイク（ビルドやパッケージのインストールなど）によるものであれば、スワップを使用してアップグレードを回避することができます。しかし、アプリケーションの日常的なメモリ使用量がサーバーのRAMを一貫して超える場合は、RAMをアップグレードする必要があります。生産トラフィックでスワップに依存すると、パフォーマンスが低下するためです。