ディスクが足りなくなったので、後から大きくする

手順に迷ったときや、用語の意味を確かめたいときに開きましょう。

※ リンク切れの場合は、ページタイトルで検索してください。

「ディスクの空きが少ない状態」から、「ボリュームを拡張し、OS 側でも認識させた状態」になるまでの変化を比べます。この変化を自分の手で再現するのが、このハンズオンの中心です。

※ 図のサイズ・使用率は一例です。実際の値は自分の環境で確認した値になります。

以下の流れで、「容量が厳しい状態を作る」→「ボリュームを拡張する」→「OS側でも使えるようにする」を順に行ってください。

「先に容量不足の状態を作ってから、それを解消する」という順番で進めます。コンソールでの変更と OS 側での拡張、両方が必要だという感覚を、実際の数値の変化で確かめましょう。

1. マネジメントコンソールにサインインし、リージョンを合わせる

   ブラウザで AWS マネジメントコンソールにサインインし、画面右上のリージョンが「アジアパシフィック（東京）ap-northeast-1」になっていることを確認します。

2. 確認用の EC2 インスタンスを1台起動する

   EC2 コンソールで「インスタンスを起動」を押し、名前に resize-demo、AMI に Amazon Linux 2023、インスタンスタイプに無料利用枠の対象（例：t3.micro）を選びます。キーペアを新規作成し、.pem ファイルをダウンロードしておきます。ストレージ設定のルートボリュームは、サイズを変えずデフォルト（例：8 GiB）のまま起動します。

   セキュリティグループは SSH のみ許可でよい

   インバウンドルールで SSH（ポート22）を、自分の IP からのみ許可しておきます。Web サーバーなどは今回立てないため、それ以外のポートは開けなくて構いません。

3. Windows の OpenSSH で接続する

   PowerShell を開き、ダウンロードした鍵ファイルの権限を絞った上で接続します（<インスタンスのパブリックIP> は実際の値に置き換えてください）。

   PowerShell

   # 鍵ファイルの権限を自分のみ読み取り可に絞る
   icacls .\resize-demo-key.pem /inheritance:r
   icacls .\resize-demo-key.pem /grant:r "$($env:USERNAME):(R)"
   
   # SSH接続
   ssh -i .\resize-demo-key.pem ec2-user@<インスタンスのパブリックIP>

4. いまのディスク使用状況を確認する

   接続できたら、現在のディスクの使用状況を確認します。

   EC2 インスタンス内

   df -h /
   lsblk

   lsblk で実際のデバイス名を確認しておく

   lsblk の結果に表示されるディスク名（例：nvme0n1 とその下の nvme0n1p1）を、あとの手順で使います。最近の世代のインスタンスでは /dev/xvda ではなく NVMe 形式の名前になっていることが多いので、ここで必ず実際の値を確認してください。

5. ダミーファイルを作って、容量が厳しい状態を再現する

   fallocate コマンドで大きなファイルを1つ作り、空き容量が少ない状態を意図的に作ります。ボリュームの空き容量に合わせて、サイズは適宜調整してください。

   EC2 インスタンス内

   # 例：5GBのダミーファイルを作成
   fallocate -l 5G ~/dummy.img
   df -h /

   使用率が9割前後になっていればOK

   df -h / の Use% の列が9割前後になっていれば、「容量が厳しい状態」の再現は十分です。ディスクを使い切ってインスタンスが不安定にならないよう、使用率100%にはしないようにしましょう。

6. EC2 コンソールから、ボリュームのサイズを変更する

   EC2 コンソールの左メニュー「Elastic Block Store」→「ボリューム」を開き、resize-demo インスタンスのルートボリュームを選びます。「アクション」→「ボリュームの変更」を押し、新しいサイズ（例：20 GiB）を入力して保存します。

   縮小はできない・変更には少し時間がかかる

   EBS ボリュームのサイズは大きくすることしかできません（小さくはできません）。また、変更が完了するまで数分かかることがあります。ボリュームの状態が「in-use」のまま「最適化中」のような表示になっていれば、しばらく待ちましょう。

7. サーバーの中でパーティションを拡張する

   もう一度 SSH 接続し、growpart コマンドでパーティションを拡張します（デバイス名は手順4で確認したものに置き換えてください）。

   EC2 インスタンス内

   # 例：lsblkで /dev/nvme0n1 と /dev/nvme0n1p1 だった場合
   sudo growpart /dev/nvme0n1 1
   lsblk

   パーティション番号は「1」が一般的

   growpart の2つ目の引数はパーティション番号です。lsblk でデバイス名の末尾に p1 のように付いている場合、その「1」を指定します。

8. ファイルシステムを拡張する

   Amazon Linux 2023 のルートファイルシステムは標準で XFS です。xfs_growfs でファイルシステムを拡張します。

   EC2 インスタンス内

   sudo xfs_growfs -d /
   df -h /

   ファイルシステムの種類によってコマンドが違う

   ファイルシステムが ext4 の場合は、代わりに sudo resize2fs /dev/nvme0n1p1（デバイス名は自分の環境のものに置き換え）を使います。df -T / や lsblk -f で、自分の環境のファイルシステムの種類を確認できます。

9. 容量が増えたことを確認し、ダミーファイルを削除する

   df -h / を実行し、Size の列が新しいボリュームサイズに近い値（例：約20GB）になっていること、Use% が下がっていることを確認します。確認できたら、手順5で作ったダミーファイルを削除しておきます。

   EC2 インスタンス内

   rm ~/dummy.img
   df -h /

初学者がよく引っかかる箇所を先回りでまとめました。答えそのものは載せていませんが、「どこを見直せばよいか」の手がかりとして使ってください。

要件の再確認ではなく、画面・コマンドのどこを見れば達成を確認できるかをまとめました。次を順に確かめましょう。

• EC2 コンソールの「ボリューム」一覧で、対象ボリュームのサイズが新しい値（例：20 GiB）になっている。
• そのボリュームの状態が、変更処理を終えて「in-use」に戻っている。
• サーバー内で lsblk を実行すると、パーティションのサイズも新しい値に近くなっている。
• df -h / の Size 列が、新しいボリュームサイズに近い値になっている。
• df -h / の Use% 列が、ダミーファイル削除後に十分低い値（10〜40%程度）になっている。

手を動かすことに加えて、次の問いに自分の言葉で答えられるようにしておくと、理解がより深まります。

1. EBS ボリュームのサイズを増やしただけでは、サーバーの中で使える容量がすぐに増えなかったのはなぜでしょうか。「ボリューム」「パーティション」「ファイルシステム」という3つの言葉を使って説明してみましょう。
   ヒント

   3つはそれぞれ別の階層の情報です。ボリュームは物理的な箱の大きさ、パーティションはその箱の中の区画、ファイルシステムはその区画の上でファイルを管理する仕組みです。上の階層を変えても、下の階層は自分で更新するまで古い情報を持ち続けます。
2. EBS ボリュームのサイズは「大きくすることしかできない（縮小できない）」という制約があります。これはなぜそうなっていると考えられるでしょうか。
   ヒント

   ファイルシステムは、ボリューム全体にデータを分散して配置しています。縮小するには「後ろの領域にあるデータを安全に前方へ移動してから切り詰める」という複雑な処理が必要になります。データを壊さずに縮小する難しさという観点から考えてみましょう。
3. 本番で稼働しているサーバーが、今回のように「容量がぎりぎりになって初めて気づく」という状態になるのは避けたいものです。容量不足を事前に察知するには、どのような仕組みを用意しておくとよいでしょうか。
   ヒント

   ディスク使用率などのメトリクスを定期的に収集し、ある割合を超えたら通知する仕組みを考えてみましょう。サーバーの監視や、しきい値を超えたときに知らせる仕組みは、他のハンズオンでも扱われている考え方です。

作成したインスタンスを終了し、リソースを整理しましょう。

1. インスタンスを終了する：EC2 コンソールの「インスタンス」で resize-demo を選び、「インスタンスの状態」→「インスタンスを終了（Terminate）」を選びます。
2. ボリュームが残っていないか確認する：左メニュー「ボリューム」を開き、インスタンス終了後にこのボリュームが一覧から消えている（または「利用不可」になっていない）ことを確認します。通常はルートボリュームの「終了時に削除」が既定で有効なため、インスタンスの終了と同時に削除されます。