EBS上にスワップ領域を作成したいが、コスト面などの懸念点について

Question

実現したいこと

EBS上にスワップ領域を作成したい。

前提

引き継ぎ案件で、
既存システム上でEBSがアタッチされているEC2上にswapfileを持っているのですが、ディスクの容量が100%になりシステムが動かなく（ファイルがアップロードできなく）なったのでswapfileをEBS上に移動させたいです。
今回はじめてswap領域の展開を行うのですが、現状自分しかシステムに関する知識を持っておらず、頼れる人がいない状態です。
また、AWSのコンソールに関して、依頼主側で管理しているのでコンソールで必要な操作は都度依頼する形です。SSHでサーバーにはアクセスできます。

発生している問題・エラーメッセージ

ネットで検索してやり方としては、
スワップファイルの削除

sudo swapoff /swapfile
sudo rm  /swapfile

スワップファイルの追加

sudo dd if=/dev/zero of=/var/{EBSにマウントされているディレクトリ}/swapfile bs=1M count=4096
sudo chmod 600 /var/{略}//swapfile
sudo mkswap /var/{略}/swapfile
sudo swapon /var/{略}/swapfile
sudo vim /etc/fstab　パスの書き換え

上記で考えているのですが、
以下の点が懸念点として
・現状のメモリに保存しているデータは消えてしまうが仕方がないものなのか？
・EBSをスワップ領域として使うと　スループットのコストが膨大になるかどうか？
・そもそも他に問題点や良い解決方法がないか？
※別のやり方を質問していますが、依頼企業の上長にすでに了承済みのため大きな懸念点がなければ変更しずらい状態です。

補足情報（FW/ツールのバージョンなど）

・OS:AmazonLinux
・phpで動いているWebサービスがある
※Webサービスが一時的に停止するのは了承済み

Comments

[TaichiYanagiya]

OS 仮想メモリ用のスワップファイルって作成時に上限が決まっているのではないでしたっけ？
スワップファイルのファイルサイズと free の出力はどうなっていますか？
OS ではなく、別の何らかのプログラムが使用する「スワップファイル」の可能性はないでしょうか？

Answer 1

状況を読み違えたかもしれません。
メモリ使用状況に関わらず、ディスク容量が不足していてスワップファイルが邪魔ということですね。

先に、ディスク使用量を減らせるところはないですか？
古いログファイルとか。
journald のデータ、audit ログなどは何もしないと GB 単位になっているかもしれません。

次に、スワップファイルですが、
メモリが十分あるならスワップファイルを使わない運用にする(swapoff してファイルを削除)。
スワップが必要なら、先に追加のディスクにスワップパーティションを作成して mkswap, swapon した後に既存のスワップファイルを swapoff して削除すればデータは消えないはず。
(スワップパーティション : ファイルシステム上にスワップファイルを作成するのではなく、ブロックデバイスをそのまま使う)
また、インスタンスタイプによっては インスタンスストア をスワップ用に使うことができます。

Comments

[tairana_shima]

ありがとうございます。
おそらくご理解していただいている通りの状況です。

>古いログファイルとか。
>journald のデータ、audit ログなどは何もしないと GB 単位になっているかもしれません。
auditログ、今回はじめて存在を知りました。
確認したのですが、0Bでした。
journald ログのデータ500MB貯まっているので次にどうしようもなくなったらjournaldログを消すことにしていました。
※引き継いだばっかなので、なんとなく消すの怖くて…。

>次に、スワップファイルですが、
>メモリが十分あるならスワップファイルを使わない運用にする(swapoff してファイルを削除)。
>スワップが必要なら、先に追加のディスクにスワップパーティションを作成して mkswap, swapon した後に既>存のスワップファイルを swapoff して削除すればデータは消えないはず。
>(スワップパーティション : ファイルシステム上にスワップファイルを作成するのではなく、ブロックデバイス>をそのまま使う)
>また、インスタンスタイプによっては インスタンスストア をスワップ用に使うことができます。
ありがとうございます。
先方と相談した結果、メモリのデータ消えてもいいし、
費用も多少かかってもいいから取り合えず動くようにしてくれとのことだったので、
追加ディスクにスワップ領域をつくることになりました。

ご回答ありがとうございました。

Answer 2

まずはじめに、こちらの回答では業務上の責任は一切負えません。
上長に了承済みだとか、そういった事情は内々で処理してください。

現状のメモリに保存しているデータは消えてしまう

前提として、消えたら困るデータをメモリ上に保存しているのがおかしいですし通常気にすることはありません。

EBSをスワップ領域として使うと　スループットのコストが膨大になるかどうか？

ここで言うコストとは料金のことでしょうか。
まずはEBSの料金体系を確認してみてください。

スループットについてはまずgp3のストレージを使っていることと、ボリュームの設定で無料枠以上の値を割り当てたら追加で料金がかかりますが、ボリュームの使い方が理由で勝手にそれが変わることはありません。

そもそも他に問題点や良い解決方法がないか？

swap領域については根本的にはこの問題に関係ないと思います。

そもそもの問題点として考えられるのはディスクがいっぱいになるような使い方をしていることです。
書いてある容量通りにswap領域を作成しているならせいぜい4GBですが、その程度で容量が圧迫されるならそもそもEBSの容量がそれなりに小さいのでは。
一番簡単な対処はEBSを拡張することですが、ファイルが増え続けるならそれは暫定対処にしかなりません。
swap領域を他のディスクに移動するというのも、同様に暫定対処でしかありません。

EBSでないところにファイルを保存するか、不要なファイルを何らかの方法で削除や退避するなどして容量が増えすぎないようにするのが根本的なアプローチかと思います。
保存先・退避先をS3にできるならそれが一番いいですが、仕組みを大きく変えるのが難しいなら一時的に大きなEBSを作成してそこに増え続けるファイルを保存するようにするか、EFSを使うというのも考えられます。
ただ、それらはS3に比べると容量に対する金額が結構高いのでやるならきちんとコストを計算してください。

もしswap領域が不要ならそもそもswap領域を消すのも一つの判断です。
swap領域がないことによってメモリが不足するようであれば、インスタンスのタイプを変えてメモリを増やすのもいいでしょう。

Comments

[tairana_shima]

ありがとうございます。
追加されているボリュームが汎用 SSD (gp2)だったので、
スループットの費用が発生しないと考えて、そこにswap領域を作成することになりました。
ご回答ありがとうございました。

[yu_1985]

一点注意をしておくと、そもそもスループットの費用云々は自分でディスクに対して無料枠以上の設定を割り当てなければ発生しないので特に懸念することはありません(gp2の場合は設定できないので関係なし）

使い方にもよりますが、多くの場合ディスク容量が足りないのはそもそもディスク容量が小さすぎるか、ログや古いファイルをローテーションせずに延々と出力して容量を圧迫していることがほとんどなので、対処後に容量を食っているファイルがなにかを調べて対策を考えることをおすすめします。