【AWS】EBS容量の拡張手順を通してストレージに関する知識を整理する！
どもども！最近物件を探すことが趣味になりつつある人です。
僕は普段インフラエンジニアとして会社のAWSインフラ周りの構築、運用、保守を担当しています。
しかし、お恥ずかしながらまだまだ経験が浅く、インフラの中でも理解し切れていない分野があります。そのうちの一つがファイルシステムなどのストレージ関連の領域です。
例えばストレージの拡張作業、AWSなどのクラウドの登場によりハード面を考慮せず作業できるようになった昨今、コンソール画面上でちょちょっと操作してコマンドを手順通りに入力するだけで完了してしまう分、その作業の本質はあまり理解せずに済んでしまいます。
エンジニアとして手順通りの作業ができることで満足するのはリスクなので、EBS拡張作業を通してストレージ周りの知識を整理しておきたいと思います。
今回参考にする拡張手順は下記のAWS公式ドキュメントのものです。また、AWSコンソール画面あるいはCLIによるEBS容量拡張はあらかじめ行なっているものとします。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html
本記事を読み進める前に、事前に上記ドキュメントを一読しておくことをお勧めいたします。
EBS拡張作業を一つずつ確認してみる
それでは、公式ドキュメントに倣い、それぞれの作業をしっかりと確認してみましょう。
はじめに、ご存知の方も多いと思いますが、EBSを含めHDDやSSDなどのブロックデバイス(ストレージとされるデバイス)はファイルの読み書きなどでプロセスから参照されるときは普通直接アクセスはされません。
プロセスとブロックデバイスの間にはファイルシステムが存在し、そのファイルシステムを介してアクセス、読み書きを行なっています。この前提が非常に重要です。
つまり今回の場合、EBSを拡張しただけではファイスシステムはまだその領域を認識していないため上記ドキュメントのような手順が必要となってくるわけですね。
よくストレージ容量の空きを確認する際dfコマンドを使用すると思いますが、こちらはファイスシステムを介して確認を行なっているためEBSの容量を拡張しただけでは意図した容量になっていないことが確認できるかと思います。
では、実際にブロックデバイス本体の情報はどのように確認するのか、それがドキュメントでも紹介されている"lsblk"コマンドです。こちらのコマンドを入力するとブロックデバイスそのものの容量と現在どれくらいの容量がどのパーティションに切られているかがわかります。ブロックデバイスはそれ自身を丸ごと使用せず、パーティションと呼ばれる単位で切り分けて使用する点も抑えておきましょう。
[ec2-user ~]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 16G 0 disk
└─xvda1 202:1 0 8G 0 part /
xvdf 202:80 0 30G 0 disk
└─xvdf1 202:81 0 8G 0 part /dataたとえば上記の例だとブロックデバイス自体は16GBあるいは30GBの容量がありますが各パーティションには8GBの容量で割り振られています。プロセスはファイルシステムを介してそれぞれのパーティションにアクセスしているわけですが、このままでは8GBしか使用することができません。
そこで既存のパーティションの容量を拡張しているのが下記の手順です。
[ec2-user ~]$ sudo growpart /dev/xvda 1
[ec2-user ~]$ sudo growpart /dev/xvdf 1これで各パーティションの容量が拡張されたことがlsblkコマンドで確認できると思います。
作業はこれで完了と思いきやそうではありません、実際dfコマンドでファイルシステムを確認してみると対象の領域が拡張された容量になっていないことが確認できるかと思います。
確かに先ほどの作業でブロックデバイス側におけるパーティションの容量は拡張されましたが、ファイルシステム側では変わらず8GBという設定になっているためです。
そこで次はファイルシステム側の認識容量の拡張を行いましょう。コマンドはファイルシステムによって異なりますのであらかじめdf -hTなどで確認しておきましょう。
[ec2-user ~]$ sudo xfs_growfs -d マウントポイント（ファイルシステムがXFSの場合）
[ec2-user ~]$ sudo resize2fs マウントポイント（ファイルシステムがext4の場合）これでファイルシステム側の拡張も完了し、晴れてEBS拡張作業は完了となります。
まとめ
知識を整理するまでは、ファイルシステムやブロックデバイスが何者かあまりよくわかっておらず、なぜこのような冗長に見える作業を行うのか分かりませんでしたが、理解してしまえばこの作業手順も納得です。(あまり大きな声では言えませんでしたがdfとlsblkの違いもよくわかっていませんでした…)
今回は割愛しますが、ブロックデバイスへのアクセスにファイルシステムを介している理由や新しいパーティションを作成しマウントする手順などを追ってみるとより理解が深まるのでお勧めです。2台目のEBSをアタッチする手順を見直すなども有効そうですね。
当たり前ですがストレージが死ぬとサービスも死ぬので、インフラエンジニアとしてより知識を深めたいですね！
最後まで読んでいただきありがとうございました！
↓オススメ教材
