はじめに
私が勤務するIT系専門学校では、学生がLinuxやPythonを学ぶための環境として、AWSのEC2インスタンスを利用しています。
学生はそれぞれのユーザーアカウントでLinuxサーバーにログインし、VS CodeのRemote SSH機能を使ってプログラムを作成しています。
手元のWindows PCからLinux上のファイルを編集し、そのまま実行できる。学生にとっても教員にとっても便利な環境です。
ところが、ある日、この共用サーバーでディスク容量が不足する問題が発生しました。
調べてみると、VS Code Remote SSHを利用するために配置されたファイルが、想像以上に容量を消費していました。
今回は、この問題について調べたことと、実際に行った対応を記録しておきます。
共用Linuxサーバーでディスク容量不足が発生
今回の環境は、Amazon Linux系のEC2インスタンスです。
学生ごとにLinuxのユーザーアカウントを作成し、VS Code Remote SSHで接続できるようにしていました。
利用する学生は約28人です。
あるとき、サーバーの動作が重くなり、ディスク使用量を調べたところ、ルートファイルシステムの使用率が100%になっていました。
df -hdfはファイルシステムの空き容量を確認するコマンドです。
ディスクの空き容量がなくなると、新しいファイルを保存できなくなるだけでなく、アプリケーションが正常に動作しなくなることもあります。
学生が授業で利用するサーバーなので、まずは利用できる状態に戻す必要がありました。
VS Code Remote SSHは接続先にもファイルを配置する
VS Code Remote SSHは、手元のPCにインストールしたVS Codeだけで動いているわけではありません。
SSHで接続した先のLinuxサーバーにも、VS Code Serverというコンポーネントが配置されます。
通常は、接続したユーザーのホームディレクトリ内にある、次のディレクトリに保存されます。
~/.vscode-server実際に、容量を確認するには次のコマンドを利用できます。
du -sh ~/.vscode-serverduはファイルやディレクトリの使用容量を調べるコマンドです。
-s：合計容量だけを表示する-h：KB、MB、GBなど読みやすい単位で表示する
別の環境で確認したところ、私自身のホームディレクトリだけでも約1.3GBを使用していました。
1.3G /home/siwuser/.vscode-serverもちろん、すべてのユーザーが同じ容量を使うわけではありません。
しかし、共用サーバーでは利用人数分のファイルがそれぞれのホームディレクトリに配置されます。
仮に1人あたり1GBを使用すると、28人で28GBです。
個人で利用していると気づきにくい容量の増加も、共用環境では無視できない規模になります。
なぜVS Code Serverの容量が増えるのか
原因の一つとして考えられるのが、VS Code Serverのバージョン管理です。
VS Codeは定期的に更新されます。
Remote SSHでは、クライアント側のVS Codeに対応したサーバー側コンポーネントが必要になります。
そのため、更新によって新しいバージョンが配置され、古いバージョンのファイルが残る場合があります。
私の環境でも、次のディレクトリに複数のバージョンが存在していました。
ls -ld ~/.vscode-server/cli/servers/*例えば、次のようなディレクトリです。
Stable-520fb30b...
Stable-645f29cc...このStable-から始まるディレクトリは、VS Code Serverのバージョンに対応するものです。
複数存在すること自体が異常というわけではありません。
ただし、古いバージョンが利用されなくなっても残っている場合、容量を消費し続ける可能性があります。
また、拡張機能やキャッシュなども、ディスク使用量に影響します。
注意したいのは、.vscode-serverの容量が大きいからといって、そのすべてが不要なファイルとは限らないことです。
まずはEBSの容量を拡張した
今回は授業で利用しているサーバーだったため、不要ファイルを一つずつ調査する前に、まずディスク容量を確保することにしました。
EC2では、ストレージとしてAmazon EBSを利用できます。
EBSは、EC2インスタンスに接続して利用するブロックストレージです。
AWSマネジメントコンソールからEBSボリュームの容量を増やすことができます。
ただし、EBSの容量を増やしただけでは、Linuxが利用できるファイルシステムの容量が自動的に増えるとは限りません。
OS側でも、パーティションやファイルシステムを拡張する必要があります。
まず、現在の構成を確認します。
lsblk
df -hTlsblkではディスクとパーティションの構成を、df -hTではファイルシステムの種類と使用量を確認できます。
一般的な構成では、必要に応じてgrowpartでパーティションを拡張し、その後、ファイルシステムを拡張します。
例えばXFSなら、次のようなコマンドを使用します。
sudo xfs_growfs /ext4の場合はresize2fsを使用します。
ただし、これらのコマンドはディスク構成によって指定方法が異なります。LVMを利用している場合には、論理ボリュームの拡張も必要です。
実際に作業する際は、対象のデバイス、パーティション、ファイルシステムを確認することが重要です。
今回も、EBSの容量拡張後にOS側の領域を調整し、一次対応を行いました。
容量を増やすことと、原因を解消することは別
EBSを拡張すれば、ひとまずディスク容量不足は解消できます。
しかし、それだけでは根本的な解決になりません。
同じ使い方を続ければ、また容量が不足する可能性があるからです。
そこで、容量を確保した後、ホームディレクトリ内のファイルを調査し、不要なものを整理する作業を進めました。
容量の大きなディレクトリを確認するには、例えば次のコマンドが使えます。
du -h --max-depth=1 ~VS Code Serverの内部を調べる場合は、次のようにします。
du -h --max-depth=2 ~/.vscode-serverこうして、どのディレクトリが容量を消費しているのかを調べます。
古いVS Code Serverのファイルを削除する場合には、現在利用中のプロセスがないかを確認する必要があります。
ps auxww | grep '[.]vscode-server'VS Code Serverは通常、必要に応じて再配置されますが、使用中のファイルを不用意に削除すると、学生の接続や作業に影響する可能性があります。
特に共用サーバーでは、管理者の判断だけで一括削除する前に、利用状況を確認することが大切です。
共用サーバーでは、人数分の運用コストが発生する
今回の経験から改めて感じたのは、便利な開発環境にも運用コストがあるということです。
VS Code Remote SSHは、学生にとって非常に便利な仕組みです。
手元のPCのOSが違っていても、同じLinuxサーバーでプログラムを実行できます。
授業で利用する環境をそろえやすいというメリットもあります。
一方で、ユーザーごとにVS Code Serverが配置され、拡張機能やキャッシュも保存されます。
個人利用では問題にならないことが、数十人で利用すると問題になる場合があります。
今後は、ディスク使用量を定期的に確認することや、不要なファイルを整理する仕組みも考えていく必要がありそうです。
まとめ
今回の問題を通じて、VS Code Remote SSHの便利さと、その裏側で動いている仕組みについて、改めて考える機会になりました。
普段は意識しませんが、Remote SSHで接続すると、接続先のサーバーにもソフトウェアが配置されます。
そして、共用サーバーでは、その容量が利用人数に応じて積み重なっていきます。
今回行ったのは、EBSの拡張による一次対応と、不要ファイルの調査・整理でした。
ところが、この対応を進める中で、さらに大きな問題が発生しました。
EC2インスタンスそのものが、終了（Terminate）状態になってしまったのです。
学生が利用するサーバーを失ったとき、何が残っていて、何を復旧できたのか。
次の記事では、GitHubに残していた学生の成果物と、環境構築用のシェルスクリプトが役立った経験について書いてみたいと思います。
コメント