サーバを運用していると、
・だんだんデータが増えてきて、ボリュームの残りが減ってきた
・思ったよりもデータが小さくて、無駄に空きが余っている
という事があります。

一から構築するシステムなどは、どのくらいデータが増えていくのか緻密に計算するのは困難ですから
えいやっ！とある程度決め打ちで領域を切っていく事はよくあります。

そんなときは、領域のサイズを変更しましょう。

AWSでEBSのサイズを変更する

EBSボリュームは、一度作成してしまうとサイズの変更はできません。
では、どうやってサイズを変更するかというと、EBSボリュームのコピーボリュームを作成します。
このコピーボリュームを作成するときに、好きなサイズを指定することができるのです。

※今回紹介する手順は、ルートボリューム(/)以外を対象としています。
　ルートボリュームのサイズ変更手順とは異なりますので、ご注意ください。

==========

AWSのEBSのサイズを拡張する

■拡張

ボリュームを拡張する場合、EBSボリュームのコピーは「スナップショット」という機能を使用します。
スナップショットは、ある時点の状態を取得します。
例えばバックアップ中にデータが更新されても不整合が発生しないように、取得した瞬間の状態を記録しておくことができます。
スナップショットはストレージの大変便利な機能で、後述の余談に詳しく記載していますので興味のある方は参照ください。

領域のサイズ拡張手順

◇領域のサイズ拡張手順

STEP-1.　変更したいEBSボリューム(元ボリューム)への更新を停止
STEP-2.　元ボリュームのスナップショットを取得する
STEP-3.　STEP-2で取得したスナップショットから、任意のサイズでEBSボリューム(新ボリューム)を作成する
STEP-4.　STEP-3で作成した新ボリュームをEC2にアタッチする
STEP-5.　元ボリュームをアンマウントし、アタッチした新ボリュームをマウントする
STEP-6.　新ボリュームへの更新開始

ここで注意しなければならないのは、スナップショットを取得した時点までのデータしか新ボリュームには存在しない、ということです。
その為、スナップショット取得時点から新ボリュームをマウントするまでは、更新が発生しないようにしなければなりません。
しかし、スナップショットの取得やボリュームの作成は、データのI/Oよりもストレージ内の処理優先度が低いため、案外時間がかかることがあり、STEP2～5に要する時間はタイミングにより長かったり短かったりします。

ダウンタイムを少なくしたい場合は、rsyncを利用した次の手順がオススメです。

ダウンタイムを考慮したサイズ拡張手順

◇ダウンタイムを考慮したサイズ拡張手順

STEP-1.　変更したいEBSボリューム(元ボリューム)のスナップショットを取得する
STEP-2.　STEP-1で取得したスナップショットから、任意のサイズでEBSボリューム(新ボリューム)を作成する
STEP-3.　STEP-2で作成した新ボリュームをEC2にアタッチする
STEP-4.　アタッチした新ボリュームを、一時的に適当なマウントポイントにマウントする
STEP-5.　元ボリュームと新ボリュームを差分同期する
※STEP-7の時間短縮の為、更新停止直前にいったん同期
⇒ここまで実行しておけば、以降の作業は5分とかからず完了するはず。
STEP-6.　変更したいEBSボリューム(元ボリューム)への更新を停止
STEP-7.　元ボリュームと新ボリュームを差分同期する
STEP-8.　元ボリュームと新ボリュームをアンマウントし、新ボリュームをマウントする
STEP-9.　新ボリュームへの更新開始

==========

AWSのEBSのサイズを縮小する

■縮小

ちょっと悩ましいのは
・思ったよりもデータが小さくて、無駄に空きが余っている
とき。

縮小する場合は、任意のサイズで新たにボリュームを作成してマウントし、rsyncなどでデータをコピーします。
データサイズが数十GB以上で大きいと、数時間～要することを覚悟してした方がよいでしょう。

STEP-1.　任意のサイズでEBSボリューム(新ボリューム)を作成する
STEP-2.　STEP-1で作成した新ボリュームをEC2にアタッチする
STEP-3.　アタッチした新ボリュームを、一時的に適当なマウントポイントにマウントする
STEP-4.　元ボリュームと新ボリュームを同期する
※データサイズにより、数時間～時間を要する
⇒ここまで実行しておけば、以降の作業は5分とかからず完了するはず。
STEP-5.　変更したいEBSボリューム(元ボリューム)への更新を停止
STEP-6.　元ボリュームと新ボリュームを差分同期する
STEP-7.　元ボリュームと新ボリュームをアンマウントし、新ボリュームをマウントする
STEP-8.　新ボリュームへの更新開始

拡張、縮小、それぞれの作業の流れはつかめたでしょうか。
ボリュームサイズ変更の詳細手順については、後日記述します。

——————————————————————————-

AWS EC2のEBS変更する際のメモ

用語メモ

◇用語メモ
アタッチ･･･ボリュームをサーバにくっつける
デタッチ･･･ボリュームをサーバからはがす

—-以下の内容はAWSのスナップショットではなく、一般的なスナップショットについてです—-

スナップショットとは

◇余談：スナップショットとは
インフラーな方々には言わずもがなだと思いますが、ストレージ界で言うスナップショットというのは「ある瞬間の状態の記録」です。

ファイルシステムにおけるスナップショットとは、ストレージ中に過去のある一時点で存在したファイルとディレクトリの集合、またはその記録処理を実現する仕組みである。
引用元：wikipedia

スナップショットを取得した瞬間の状態を維持するために、以降に更新が発生すると、前の状態を記録します。
※「前の」という所が特徴です。アーカイブログ、ジャーナルログ等は更新内容を蓄積して記録していきますが、スナップショットは更新前の状態をメモしておくだけ、というイメージです。

データx=1に3を足す、2を引く、という2回の更新を加えた場合、それぞれに記録される内容は
　アーカイブログ
　　　　データXに3を足す
　　　　データXから2を引く
　スナップショット
　　　　データX=1

スナップショットのデータを参照すると、変わっていないデータは、スナップショット取得元ボリュームのデータを参照し、
変更された箇所は、記録しておいた前の状態を参照します。
よって、ボリュームのコピーではない為、実体はありませんが、差分データを記録する領域が必要になります。

AWSのEBSのスナップショットの注意事項

◇さらに余談：スナップショットの注意事項
ボリュームのコピーではないので、参照元=スナップショット取得元データを必要とします。
(某ソフトウェアのスナップショットが古すぎます。なんてメッセージにも通じますね。)
参照元データを必要とするので、スナップショットをバックアップとしてはいけません。

ディスクが壊れてバックアップから戻そうとしても、そのバックアップが壊れたディスクを参照していた･･･では、バックアップとしての役割を果たせません。
スナップショットから取得した時点のデータを参照して、バックアップデータを生成します。
また、差分の記録ですので、適切に削除されなかった場合、スナップショットデータが肥大化する事に注意しましょう。

AWSでは、ボリュームを削除しても自動的に上手いことやってくれます。