今回は、先日書籍（Amazon Web Servicesクラウドデザインパターン設計ガイド）が発売された
Cloud Design Pattern（CDP）の記事になります。
今回の対象は「Snapshotパターン」です。
実はV2(次バージョン)へのアップデートとして、下記の「注意点」が追記されています。
ブート領域とデータ領域をひとつのディスクで構築するか、 分けるかについてはメリット・デメリットのトレードオフがある。 一つで構築した場合、スナップショットの取得やEC2インスタンスの起動が 用意である。一方で、ブートディスクのデータサイズは小さい方が 仮想サーバーの起動は早い。また、定期的に行わるディスクチェック （Linuxの場合はfsck）の際に時間もかからない。
特に下記についてですが
「一つで構築した場合、スナップショットの取得やEC2インスタンスの起動が用意である。」
現在、今までAPIでしかできなかったEC2起動時でのEBS(ルートディスクも)の サイズ変更が、AWSマネジメントコンソールでもできるようになりました。
ディスクサイズの小さなAMIから、同じEBSの数(だいたいが一つでしょう)で ディスクサイズの大きなEC2を起動することが容易にできるようになり、 下記のような構築/運用時の課題を減らすことができるはずです。
- データ用EBSへのデータの移動のし忘れ
- データ用EBSへのシンボリックリンクの張り忘れ
- 構築時にどのファイルをデータ用EBSに配置するのかの検討
以下、サイズの小さい(6G)ブートディスク(EBS)を大きく(100G)して、 EC2を起動する方法を紹介します。
まず下記のAWSマネジメントコンソールから、起動時のディスクの調整が 可能となっています。
そして、ブートディスクもデフォルトのサイズ(6G)より大きく(100G)した状態で 起動することができます。
しかし、このままでは下記のように実際の(ファイルシステム上の)サイズは増えていません。
# df -h
Filesystem Size Used Avail Use% マウント位置
/dev/xvde1 6.0G 2.2G 3.5G 38% /
none 296M 0 296M 0% /dev/shm
ファイルシステム上のサイズも増やすには、Linuxなどなら下記のコマンドを 実行する必要があります。
# resize2fs /dev/xvde1
resize2fs 1.41.12 (17-May-2010)
Filesystem at /dev/xvde1 is mounted on /; on-line resizing required
old desc_blocks = 1, new_desc_blocks = 7
Performing an on-line resize of /dev/xvde1 to 26214400 (4k) blocks.
The filesystem on /dev/xvde1 is now 26214400 blocks long.
すると無事、ファイルシステムレベルでもサイズが増えていることが確認できます。
# df -h
Filesystem Size Used Avail Use% マウント位置
/dev/xvde1 99G 2.2G 92G 3% /
none 296M 0 296M 0% /dev/shm
ファイルシステムレベルでサイズを増やす方法は、以前、中身をそのままにEBSのサイズを増やす方法のまとめでまとめています。
当然、ブートディスクも含めたサイズの大きなEBS一本で運用するか、 ブートディスクのEBSはサイズを小さくし、他のデータは別EBSに移して運用するかは、 トレードオフなので、メリット・デメリットを確認して選択する必要があるでしょう。
