AWS EBSの拡張（Ubuntu 16.04 LTS）ディスク容量の不足
コンテンツ
ディスク容量の不足
このブログはAWS（Amazon Web Services）上のUbuntu 16.04 LTSにWordPressをインストールして書いている。
当初はちょっとお試しのつもりでブログを書き始めたのでTypeはt2.microの最小構成、ディスク容量もOSも含めて8GByteと最低限しか割り当てていなかった。
しかしなんだかんだで2年近く書いていたら段々とディスク容量も不足して来てしまっていた。
また以前apt-get autoremoveコマンドで不要なパッケージを削除した所（過去記事参照）、4GByte空いたので「まぁいいか」と放置して置いた所、いよいよ残りが1.8GByte（77%使用）になってしまったので一杯になってしまう前にディスクを拡張することにした。
環境
現在の環境は以下の通り
サーバー | AWS（Amazon Web Services） EC2（Elastic Compute Cloud） |
Type | t2.micro（1CPU、メモリ1GByte、ストレージはEBSのみ） |
OS | Ubuntu Server 16.04 LTS(HVM)64 bit |
ディスク | 8.0 GByte |
CMS | WordPress Ver 5.3Ja（2019年11月16日現在） |
現状の確認
まずは以下のコマンドで現在のディスクの状態を把握する。
df -h
lsblk
77%を使用中。
xvdaドライブにxvda1パーティションが切られている。
本来はOSとWordPressとは別のパーティション（xvda2等）に作成した方が良いのだが既に同一パーティションに作成してしまっているので今回はこのままxvda1パーティションを拡張する事にした。
拡張手順
以下の手順で拡張する。
- AWS上でEBSの拡張を行う
- ターミナル（Ubuntu）でパーティションの拡張
- ターミナル（Ubuntu）でファイルシステムの拡張
AWSでEBSの拡張
以前（2016年頃）はオンライン中のEBS（Elastic Block Store）は出来なかった。
現在はオンライン中でOS、WordPressが稼働中でもEBSの拡張は可能だがなるべくアクセス数の少ない曜日、時間帯で作業を行った。
尚、万が一に備えてUpdraftPlusプラグイン（過去記事参照）で事前にWordPressのバックアップは取得しておいた。
まずAWSのメニューからEC2サービスの該当のインスタンスを呼び出してボリュームメニューを選択する。
そして上部メニューのアクションー＞ボリュームの変更を選択する。
ボリュームタイプは”汎用SSD（gp2）”が選択されているのでそのままにする。
汎用SSDの料金は一ヶ月辺り0.12USD／GByte（東京リージョン）なので8GByte追加すると0.96USD（105円程度）になる見込み。
選択可能なボリュームタイプは以下の通り（料金は2020/02/27 東京リージョンでの価格）
汎用SSD | 汎用的なSSD
|
プロビジョンドIOPS SSD | 高速なSSD
※さらに IOPS あたり 0.074USD／月 |
マグネティック | 低速（アクセス頻度の低いボリューム）
|
サイズを8Gbyteから16GByteに変更する。
変更確認メッセージが表示されるので「はい」をクリックする。
「ボリュームの変更リクエストが成功しました」とメッセージが表示されるので「閉じる」をクリックする。
サイズが8GBから16GBに変更されたかどうか状態を確認するとまだ「in-use-optimaizing 0%」と最適化中なのでしばらく放置することにした。
しばらく待っていると状態がin-useに変更されたのでAWS側の作業はこれで終了。
パーティションの拡張
lsblkコマンドで確認をするとドライブ（xvda）は16GByteに拡張されているがパーティション（xvda1）が8GByteのまま。
以下のコマンドでOS（Ubuntu）上でパーティションxvda1の拡張を行う。
sudo growpart /dev/xvda 1
lsblkでサイズを確認するとxvda1のサイズが8GByteから16GByteに拡張されている。
しかしdf -hコマンドで確認するとファイルシステム上はまだ7.7Gのまま。
ファイルシステムの拡張
以下のコマンドでファイルシステムの拡張を行う
sudo resize2fs /dev/xvda1/dev/xvda1が16Gに拡張されて使用率も39％まで下がった。
これで当面大丈夫だと思う。
最近のコメント