t3.microで困りがちなメモリ不足はSwapファイルで解消！簡単にできる対策

はじめに

こんにちは、クラウドインフラを生業としているDTUHブログ編集部です。

AWS をはじめて触るとき、開発・検証用に「とりあえず無料なので t2.micro, t3.micro を立ててみた」という方は多いのではないでしょうか？私がそうです。

低コストで手軽に使える反面、メモリは「1 GiB」しかありません。そのため、ちょっとした常駐プロセスを増やしただけで「いつの間にかメモリが枯渇していた……」という状況に陥りがちです。

メモリが足りないときはswapファイルを使ってみよう

そんなときに役立つのが「swapファイル」の設定です。数コマンドで仮想メモリ領域を確保でき、追加のEC2インスタンス料金は不要です。ただし、swapファイルはEBSボリューム上のディスク容量とI/Oを消費するため、その分のストレージ料金やI/Oコストは発生します。

本記事では、次の4点について順を追って解説します。

• swapファイルとは何か
• t3.micro でメモリ不足が起こる典型パターン
• 実際の設定手順（コピペ OK のコマンド付き）
• 運用時の注意点と代替策

「メモリ不足でプロセスが落ちる」「OOM Killer に泣かされた」経験がある方は、ぜひ最後までお付き合いください。

ところでOOM Killerって？

システム全体を守るために行う、OSによる苦渋の「トカゲの尻尾切り」です。

OOM Killer は、Linux カーネルが新たなメモリアロケーション要求を満たせず、kswapd 等によるページ回収やスワップアウトでも十分なメモリを確保できなくなったタイミングで自動発動し、システム全体の停止を避けるためにメモリ消費の大きいプロセスを優先的に強制終了する仕組みです。

dmesg や /var/log/messages に、次のようなログが出ていれば、OOM Killer が作動した証拠です。

"Out of memory: Kill process 12345 (mysqld) score 842 or sacrifice child"
"Killed process 12345 (mysqld) total-vm: 1024000kB"

メモリ不足という問題

サーバーの安定稼働において、メモリ管理は非常に重要です。メモリが不足すると、パフォーマンスの低下や予期せぬプロセスの停止など、様々なトラブルの引き金となります。では、そもそも技術的に「メモリが不足している」とは、具体的にどのような状態を指すのでしょうか。

そもそもメモリが不足するとは？

例えるなら、物理メモリは「作業机」、スワップ領域は「机の引き出し」です。
サーバーは、実行中のプロセスやキャッシュ、バッファなどを物理メモリ（RAM）に保持しています。

割り当てられた物理メモリを超えてデータを抱え込もうとすると、Linux ではスワップ領域（ディスク上の仮想メモリ）が利用されるか、最悪の場合 OOM Killer が発動してプロセスが強制終了します。
つまり「メモリ不足」とは、次の通りに定義できます。

1. 物理メモリが使い切られ、
2. スワップ領域も逼迫するか、そもそも設定されておらず、
3. システムが安定動作できない状態

t3.microの制約

t3.microはAWSを無料で試せる手軽なインスタンスですが、その分性能はかなり控えめです。特にメモリ容量の少なさが、後々の思わぬトラブルの火種になりがちです。

t3.micro は “無料利用枠” の対象で気軽に選ばれる反面、以下のような制約があります。

• vCPU 2 コア相当（バースト型）
• メモリ 1 GiB
• EBS のネットワーク帯域もインスタンスサイズに依存し、t3.microでは高くはありません（詳細な数値はAWS公式ドキュメントの最新仕様を参照）。

「とりあえず WordPress を試したい」「API のプロトタイプを動かしたい」といった軽量用途なら十分ですが、常駐プロセスを複数入れたり、ログ収集エージェントを動かしたりすると、簡単にメモリが枯渇します。結果として、ポートが開かない・処理が遅い・プロセスが落ちる──といったトラブルが頻発します。

スワップは「昔からある手法」だが、クラウドでも有効

スワップ（swap）は、オンプレミス時代からある非常に古典的な仕組みです。物理メモリが足りなくなったときに、一部のデータをディスク上に退避させて「とりあえず落ちないようにする」ための安全弁として、長年使われてきました。

一方で、AWS などのクラウドからインフラに入ったエンジニアにとっては、

• 「メモリが足りなくなったら、インスタンスタイプを上げればいい」
• 「スワップは遅くなるから使わない方がいい」

といったイメージが先行し、スワップを意識する機会があまりないかもしれません。

しかし、クラウド環境でもスワップは依然として有効な手段です。

• いきなりインスタンスタイプを変更せずに、低コストで「とりあえず落ちない状態」を作れる
• 一時的なピークや想定外のメモリ増加に対して、猶予時間を稼げる
• 検証環境でスワップの使われ方を観察することで、本番に必要なメモリ量の目安を立てられる

といったメリットがあります。

もちろん、スワップはあくまで「保険」であり、常用するものではありません。
それでも、t3.micro のようなメモリが限られたインスタンスでは、

「スワップをまったく用意しない」
よりも
「少量でもスワップを用意しておき、スラッシングやOOMの兆候を監視する」

というスタンスの方が、クラウド時代の現実的な運用と言えるでしょう。

メモリが不足するとどのような問題が生じるか？

メモリ不足は、単に「少し動作が遅くなる」だけで済む問題ではありません。放置すると、サーバーダウンに直結する様々な深刻な事態を引き起こします。

パフォーマンスの極端な低下（スラッシング）

物理メモリに空きがなくなると、OSは使用頻度の低いデータを一時的にディスク（スワップ領域）に退避させ、空きを作ろうとします。しかし、退避させたデータがすぐに必要になると、今度は別のデータを退避させてディスクから読み込み直す…という動作を繰り返します。これはディスクI/Oが頻発する「スラッシング」という状態で、サーバー全体の応答が極端に遅くなります。

サービスの不安定化・応答不能

Webサーバーがリクエストを返さなくなったり、データベースへの接続がタイムアウトしたりと、提供しているサービスが正常に動作しなくなります。ユーザーから見れば「サイトが表示されない」「アプリが動かない」という直接的な障害につながります。

予期せぬプロセスの強制終了（OOM Killer発動）

スワップ領域すら使い果たしてしまうと、最終手段としてOOM Killerが発動します。これにより、メモリを大量に消費しているプロセス（それがWebサーバーやデータベースであってもお構いなし）が強制終了させられ、サービスが突然停止します。

サーバー操作不能（フリーズ）

最悪の場合、システムを維持するための基本プロセスすら動作できなくなり、SSHでのログインも受け付けない「フリーズ」状態に陥ります。こうなると、強制再起動以外に復旧の手段はありません。

以上のように、メモリ不足はシステム全体の安定性を根底から揺るがす致命的な問題です。このメモリ枯渇という崖っぷちからシステムを救う、最初のセーフティネットとなるのが「スワップ(swap)」という仕組みです。

swapファイルを作成し、メモリ枯渇に備える

メモリ不足への最も手軽で効果的な対策が、swapファイル（スワップファイル）の作成です。これは、ディスク上の一つのファイルを「仮想的なメモリ領域」としてOSに認識させる仕組みです。

物理メモリが「作業机」なら、スワップは「緊急用の予備の机」と言えます。普段は使いませんが、メインの机が書類で溢れかえったとき、一時的に書類を退避させることで、作業スペースを確保し、システムの完全な破綻を防ぎます。

スワップファイルを設定するメリット

スワップファイルを設定する最大のメリットは、システムの可用性（Availability）を低コストで高められる点にあります。

OOM Killerの発動を回避し、サーバーを守る

物理メモリを使い切っても、次にswapファイルが利用されるため、即座にOOM Killerが発動する事態を避けられます。これにより、いきなりプロセスが強制終了される最悪の状況を回避し、パフォーマンス低下という「猶予期間」を得ることができます。この間に原因調査や恒久対策を検討する時間が生まれます。

低コストかつ手軽に実装できる応急処置

メモリ不足の根本解決策はインスタンスタイプの変更（スケールアップ）ですが、それにはコスト増加やサービス停止が伴う場合があります。

一方、swapファイルの作成は、数分程度のコマンド実行で完了し、追加のEC2料金は発生しません。EBSの容量・I/Oは課金対象となるものの、インスタンスタイプのスケールアップと比べれば低コストな応急処置です。

スワップファイルの限界と注意点

ただし、swapファイルは万能薬ではありません。その限界を正しく理解し、過信しないことが重要です。

パフォーマンス低下は避けられない

ディスク（EBS）の読み書き速度は、物理メモリに比べて桁違いに低速です。スワップが多用される（スラッシングが発生する）状態になると、システム全体の応答性は著しく悪化します。swapファイルはあくまで「即死」を免れるための仕組みであり、快適な動作を保証するものではないと認識しましょう。

根本原因を見えにくくする副作用も

swapファイルがあることで、メモリリーク（アプリケーションがメモリを解放し忘れるバグ）などの問題が表面化しにくくなる可能性があります。「なんとなくサーバーが重い」という状態が続く場合は、スワップに頼るだけでなく、freeコマンドや監視ツールでメモリ使用状況を確認し、根本原因を調査することが不可欠です。

swapファイルは必須の「保険」として設定すべき

結論として、特に t3.micro のようなメモリが少ない環境では、swapファイルは必須の「保険」と考えるべきです。

適切なメモリ設計が理想であることは言うまでもありません。しかし、予期せぬアクセスの急増や、OS・ミドルウェアのアップデートに伴うメモリ消費量の増加など、不測の事態は起こり得ます。そんなとき、システム全体をダウンから守ってくれるセーフティネットとして、swapファイルは極めて有効な一手となります。

swapファイルの具体的な作成手順

ここからは、実際にLinuxサーバーでswapファイルを作成し、有効化するまでの手順を解説します。コマンドを一つずつ実行すれば、誰でも設定できるように構成しました。

今回は、メモリ1GiBの t3.micro を想定し、2GiB のswapファイルを作成します。かつては「スワップサイズは物理メモリの1〜2倍」という一般的な目安がよく使われていましたが、現在はワークロードやストレージI/O特性によって最適値が変わります。本記事では分かりやすさのために2GiBとしていますが、実際の環境では監視結果を見ながら適宜調整してください。

手順1. 現状の確認（事前準備）

まず、swapファイルを作成するための準備として、以下の2点を確認します。

1. ディスクに十分な空き容量があるか
2. 既存のスワップが設定されていないか

dfコマンドでディスクの空き容量を確認しましょう。今回は2GiBのファイルを作成するため、ルートディレクトリ（/）のAvail（利用可能領域）にそれ以上の空きが必要です。

# ディスクの空き容量を確認
df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p1  8.0G  2.0G  6.0G  25% /
...

次に、freeコマンドで既存スワップがないことを確認します。Swapの行がすべて0になっていればOKです。

# メモリとスワップの使用状況を確認
free -h
              total        used        free      shared  buff/cache   available
Mem:          951Mi       807Mi        38Mi       0.0Ki       105Mi        64Mi
Swap:           0Bi         0Bi         0Bi   # ←ここが0ならOK

準備が整ったら、次の手順でswapファイルを作成していきましょう！

手順2. swapファイルを作成し、有効化する

ここからが本番です。4つのステップでswapファイルを有効化します。

1. swap用のファイルを作成する

fallocate コマンドで、指定したサイズのファイル（ここでは /swapfile）を一瞬で作成します。

# 2GBのswapfileを作成
sudo fallocate -l 2G /swapfile

補足: fallocate が使えない古い環境では sudo dd if=/dev/zero of=/swapfile bs=1G count=2 というコマンドを使います。

なお、XFS や ext4 など一般的なファイルシステムでは fallocate を使う方法が推奨されますが、btrfs などのコピーオンライト（CoW）ファイルシステムでは swapファイルの制約があるため、dd を使うか、ファイルに穴やCoW属性がないことを確認してから利用してください。

項目	fallocate	dd
速度	◎ 非常に速い（一瞬）	△ 遅い（実書き込みのため）
SSD寿命への影響	○ 作成時の無駄書き込みが少ない	△ 作成時に大きな書き込みが発生
断片化	○ しにくい（連続領域を確保）	△ する可能性がある
信頼性	○（ファイルシステムに依存）	◎ 確実（どんな環境でも動作）
推奨度	◎ 第一選択肢	○（互換性のための代替手段）

2. ファイルのパーミッションを設定する

作成した /swapfile は、セキュリティのためrootユーザーしか読み書きできないように設定します。

# パーミッションを600に変更
sudo chmod 600 /swapfile

3. ファイルをスワップ領域としてフォーマットする

mkswap コマンドで、ただのファイルだった /swapfile を、OSがスワップ領域として認識できる形式に変換します。

sudo mkswap /swapfile

4. swapを有効にする

最後に swapon コマンドで、準備したswapファイルをシステムにマウントし、有効化します。

sudo swapon /swapfile

これでswapが有効になりました。手順1で使った swapon --show や free -h を再度実行し、Swap領域が確保されていることを確認してください。

free -h
              total        used        free      shared  buff/cache   available
Mem:          951Mi       807Mi        38Mi       0.0Ki       105Mi        64Mi
Swap:         2.0Gi         0Bi       2.0Gi   # ←ここが増えてる！

手順3. 再起動後も設定を有効にする（永続化）

ここまでの設定は一時的なもので、サーバーを再起動すると消えてしまいます。
/etc/fstab ファイルに設定を追記し、OS起動時に自動でswapが有効になるようにします。

（重要！）fstabの編集は非常にデリケートな作業です。必ずバックアップを取ってから実行してください。

# fstabのバックアップを作成
sudo cp /etc/fstab /etc/fstab.bak

# fstabの末尾にswapファイルの設定を追記
echo '/swapfile none swap defaults 0 0' | sudo tee -a /etc/fstab

【オプション】swappinessを調整してパフォーマンスを最適化する

ここが安定稼働の分かれ道です。 swapファイルを設定したら、もう一つだけ「おまじない」を加えましょう。

swappiness とは、「どの程度積極的に匿名メモリをスワップアウトするか」を調整するカーネルパラメータ（0〜100）です。デフォルト値は 60 になっていることが多く、これはスワップを比較的積極的に利用する設定です。

ただし、swappiness は「物理メモリが◯%を超えたらスワップ開始」という固定の閾値ではありません。匿名メモリとファイルキャッシュのバランスや再取得コストなど、複数の要因をもとにしたヒューリスティックです。

しかし、ディスクI/Oはメモリに比べて非常に遅いため、安易にスワップを使うとすぐにパフォーマンスが低下します。そこで、「物理メモリを限界まで使い切ってから、やむを得ずスワップを使う」ように設定を変更します。

# 現在のswappiness値を確認 (おそらく60)
cat /proc/sys/vm/swappiness

# swappinessを10に設定（スワップをあまり積極的に使わないようにする）
sudo sysctl vm.swappiness=10

# OS再起動後もこの設定を維持するため、sysctlの設定ファイルを作成
echo 'vm.swappiness=10' | sudo tee /etc/sysctl.d/99-swappiness.conf

この swappiness=10 という設定は、多くのWebサーバーやアプリケーションサーバーでよく採用されるバランスの良い値です。これにより、swapのメリット（サーバーダウンの回避）を享受しつつ、デメリット（パフォーマンス低下）を最小限に抑えることができます。

【実践編】swapファイルは実務でどう役立つのか？

「スワップは単なる応急処置」と思われがちですが、実は実務において、もっと戦略的に活用できる場面が多くあります。ここでは、エンジニアが実際にswapファイルを使う具体的な4つのシーンを紹介します。

シーン1. 低スペックサーバーを「とりあえず」安定稼働させたい

対象：開発・検証環境、個人プロジェクトなど

t3.micro のようなメモリの少ないサーバーで、複数のミドルウェアやアプリケーションを動かすと、メモリは常に枯渇寸前です。このような環境でswapファイルを設定しておけば、予期せぬメモリ不足によるフリーズやプロセス停止を防ぎ、開発や検証作業をスムーズに進めることができます。「とりあえず動く環境」を素早く、低コストで用意したい場合に極めて有効です。

シーン2. 一時的にメモリ消費が跳ね上がる処理がある

対象：バッチ処理、データ集計、バックアップなどを実行するサーバー

普段のメモリ使用率は低いものの、夜間のバッチ処理や月末の集計時だけメモリ消費が急増する、というケースは少なくありません。この一時的なピークのためにハイスペックなサーバーを用意するのはコスト効率が悪いでしょう。swapファイルを「一時的なバッファ」として利用すれば、ピーク時のメモリ需要を吸収し、コストを抑えながら処理を完遂させることができます。

シーン3. 最適なメモリサイズを見積もりたい（サイジング目的）

対象：本番投入前の負荷試験、性能検証など

これは少し高度な使い方ですが、swapの利用状況を逆算して、アプリケーションに必要なメモリ量を見積もるという活用法です。

本番投入前の検証環境であえてswapファイルを設定し、負荷試験を実施します。

その後、どれくらいスワップが使われたか（free コマンドの Swap 使用量や、vmstat の si/so、sar -W や /proc/vmstat の pswpin/pswpout など）を監視することで、「あとどれくらいの物理メモリがあればスワップアウトせずに済んだか」を推測できます。

単なるスワップ残量だけでなく、スワップの入出力レートや major page fault（pgmajfault）も併せて見ると、スラッシングの有無をより正確に判断できます。

シーン4. コストと安定性のバランスを取りたい

対象：小〜中規模の本番環境

「本番環境でスワップを使うのはNG」という意見もありますが、一概には言えません。

もちろん、平常時からスワップが多用されるような状態はパフォーマンス低下を招くため避けるべきです。しかし、「不測の事態に備える保険」としてswapファイルを設定しておくことは、システムの堅牢性を高める賢明な判断です。

例えば、予期せぬアクセス急増やマイナーバージョンのアップデートによるメモリ消費量増加など、予測困難な事態が起きても、スワップがあれば即座のサーバーダウンを回避できます。コストを抑えたインスタンスを選びつつ、スワップで可用性を担保する。これは、実務における現実的なリスク管理の一つと言えるでしょう。

まとめ

本記事では、AWSの無料利用枠で人気の t3.micro を代表とする、メモリが限られたインスタンスで直面しがちな「メモリ不足」問題に焦点を当てました。

そして、その最も現実的で効果的な対策として、swapファイルの作成と設定方法、さらには実務での具体的な活用シーンまでを深掘りしてきました。

改めて、この記事の結論

t3.micro のようなメモリが限られた環境において、swapファイルはもはや「設定した方が良い」ものではなく、「必須の保険」です。

メモリ不足によるサーバーダウンは、ある日突然やってきます。その「万が一」に備える一手間が、あなたのサービスや開発環境を予期せぬ停止から守ります。

そして、ただ設定するだけでなく、swappinessの値を調整するところまでがワンセットです。この一手間を加えることで、swapのデメリットであるパフォーマンス低下を最小限に抑え、システムの安定性を最大限に高めることができます。

参考資料

より深く学びたい方のために、AWS公式のドキュメントを紹介します。

1. Linux インスタンスのスワップ領域として機能するようにスワップファイルを割り当てる方法を教えてください。
   
   https://aws.amazon.com/jp/premiumsupport/knowledge-center/ec2-memory-swap-file/