最近発表されたストレージサービスAmazon EBS(Elastic Block Store)をEC2から利用する

by Christopher Chan

先日、ご紹介した「Amazon EC2で利用できるストレージサービスAmazon EBS(Elastic Block Store)が利用可能に！」のエントリの通り、Amazon Web Servicesにて新しいストレージサービスAmazon EBS(Elastic Block Store)が使えるようになりました。

これらの詳細については「Amazon EC2で利用できるストレージサービスAmazon EBS(Elastic Block Store)が利用可能に！」をご覧ください。

今日は、この新しく追加されたサービスであるAmazon EBSの具体的な使い方やパフォーマンスについてご紹介します。
# 色々やってみたので、ちょっとボリュームあります

今回ご紹介する手順の流れは、おおまかに↓のような感じです。

ボリューム(仮想ディスク)を作成してみる
動いているEC2インスタンス(仮想マシン)にAttach(取り付け)してみる
パフォーマンスを計測してみる
スナップショット機能を使ってボリュームのバックアップを取ってみる
上記で作成したスナップショットより、ボリュームを復元(リストア)してみる
ボリュームやスナップショットを削除してみる
最後にまとめ

では、早速使ってみたいと思います。

ボリュームを作成してみる

前提として、基本的なセットアップやEC2インスタンス(仮想マシン)は起動しているものとします。
セットアップやEC2でのインスタンス起動については、「Amazon EC2/S3を使ってみた - 1.AWSへの登録〜S3を使う」や、「Amazon EC2/S3を使ってみた - 2.EC2が起こすイノベーション」を参考にしてください。
尚、下記例では私が実際に行ったログを貼り付けていますので、各IDやパラメータは、適宜読みかえるようにして下さい。

ちなみに、今回使用した「Amazon EC2 Command-Line Tools」のバージョンは以下となります。

$ ec2ver
1.3-24159 2008-05-05

では、まず起動しているインスタンスを確認します。
ここでは、インスタンスが稼動しているロケーションやインスタンスIDをメモしておきます。
# 参考：Amazon EC2/S3を使ってみた - 7.Availability Zoneサービスで稼動ロケーションを指定する

$ ec2-describe-instances
RESERVATION     r-0c16c265      xxxxxxxxxxxx    default
INSTANCE        i-e5fa208c      ami-2b5fba42    ec2-75-101-198-177.compute-1.amazonaws.com      domU-12-31-39-00-A9-73.compute-1.internal       running rx7_server     0               m1.small        2008-08-24T11:28:24+0000        us-east-1b      aki-a71cf9ce    ari-a51cf9cc

上記の例では、インスタンスの稼動ロケーションは「us-east-1b」となります。

$ ec2-create-volume -z us-east-1b -s 5
VOLUME  vol-5026c339    5               us-east-1b      creating        2008-08-24T11:29:52+0000

EBSボリューム(仮想ディスク)の作成を行います。
"-z"オプションで、先程メモした稼動ロケーション(上記例だと"us-east-1b")を入力、"-s"でディスクのサイズ(単位はギガバイト[GB]、上記例では5GB)を入力します。

作成後、ボリュームID(上記例だと"vol-5026c339"の部分。"ec2-describe-volumes"コマンドでも確認できます)をメモしておきます。

動いているEC2インスタンスにAttachしてみる

次に、先程作成したEBSボリュームを、既に稼動しているEC2インスタンス(仮想マシン)にAttach(取り付け)します。

$ ec2-attach-volume -d /dev/sdc -i i-e5fa208c vol-5026c339
ATTACHMENT      vol-5026c339    i-e5fa208c      /dev/sdc        attaching       2008-08-24T11:31:27+0000

上記例では、"-d"オプションでインスタンスで認識するデバイス名を指定、"-i"オプションで、どのマシンに接続するかを識別するインスタンスID(先程メモしたもの)、最後に先程作ったボリュームを示すボリュームIDを指定します。

Attachが正常終了すると、"attached"と表示されます。("ec2-describe-volumes"コマンドで確認できます)

Client.InvalidVolume.ZoneMismatch: The volume 'vol-5026c339' is not in the same availability zone as instance 'i-25c3194c'

尚、EC2インスタンスにAttachするEBSボリュームは、稼動ロケーションを揃えておく必要があります。
揃っていない場合は、上記のようなエラーが発生します。

インスタンス上でボリュームを確認してみる

では、ボリュームをAttachできたところで、インスタンスに接続(SSHログイン)してみます。

$ ssh -i rx7_server.id root@ec2-75-101-198-177.compute-1.amazonaws.com

まず、デバイスが認識できているかですが、、、

ec2# ll /dev/sd*
brw-r----- 1 root disk 8,  1 2008-08-24 07:29 /dev/sda1
brw-r----- 1 root disk 8,  2 2008-08-24 07:29 /dev/sda2
brw-r----- 1 root disk 8,  3 2008-08-24 07:29 /dev/sda3
brw-r----- 1 root disk 8, 32 2008-08-24 07:31 /dev/sdc

↑きちんと、Attachするときに指定した"/dev/sdc"で認識できていますね。
では、接続したボリュームにファイルシステムを作成します。

ec2# yes | mkfs -t ext3 /dev/sdc
mke2fs 1.40.4 (31-Dec-2007)
/dev/sdc is entire device, not just one partition!
Proceed anyway? (y,n) Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
655360 inodes, 1310720 blocks
65536 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=1342177280
40 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736

Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 30 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

普通にmkfsコマンドで作成しましょう。
種類は何でも良いと思いますが、上記例では普通にext3で作ってみました。

ec2# mkdir /vol
ec2# mount /dev/sdc /vol

ファイルシステムも作成したところで、マウントしてみます。

ec2# df
Filesystem           1K-ブロック    使用   使用可 使用% マウント位置
/dev/sda1             10321208   1136444   8660476  12% /
/dev/sda2            153899044    192072 145889348   1% /mnt
none                    873880         0    873880   0% /dev/shm
/dev/sdc               5160576    141440   4756992   3% /vol

この通り、作成した5GBのボリュームが、問題なく認識できています！

パフォーマンスを計測してみる

少し好奇心を出して、パフォーマンスを測定してみます。
今回は、IOzoneを使ってみました。

ec2# yum install iozone

私は、AmazonEC2の公式イメージ(Fedora8)を使っているので、yumでiozoneをインストールします。

次に、実際に以下3種類のパーティションにファイルサイズ[100KB|10MB|1GB]のそれぞれでiozoneコマンドを実行してみました。

EC2ローカルボリューム
- /dev/sda1(/)
EC2ローカルボリューム
- /dev/sda2(/mnt)
EBSボリューム
- /dev/sdc(/vol)

コマンドは以下の通りですが、"-s"オプションの部分は、それぞれのファイルサイズに置き換えて1回ずつ実行しています。

EC2ローカル(/)

ec2# iozone -i 0 -i 1 -f /root/test -s [100k|10m|1g]

              KB  reclen   write rewrite    read    reread
             100       4  378719  552386   855080   900820
           10240       4  407657  631903   672265   670729
         1048576       4  102304  138443   329611   327563

EC2ローカル(/mnt)

ec2# iozone -i 0 -i 1 -f /mnt/test -s [100k|10m|1g]

              KB  reclen   write rewrite    read    reread
             100       4  383089  555842   891947   943890
           10240       4  397869  610503   659280   649082
         1048576       4   75766   73106   321124   327093

EBSボリューム(/vol)

ec2# iozone -i 0 -i 1 -f /vol/test -s [100k|10m|1g]

              KB  reclen   write rewrite    read    reread
             100       4  404910  552812   861268   910042
           10240       4  392217  591225   684536   684128
         1048576       4   74660   77864   314698   322977

上記は、それほど厳密に計測した数字ではありませんが、"/"(ルートディレクトリ)でマウントしているデバイスの書き込み速度が一番速いものの、大きな差があるわけではなく、実用の範囲ではないかと思います。
この結果は、もっとしっかり測定すれば違う結果となる可能性もあるので、参考程度でお願いします。

スナップショット機能を使ってボリュームのバックアップをとってみる

Amazon EBSでは、作成したボリュームのスナップショットをAmazon S3に保存することが出来ます。

ec2# dd if=/dev/zero of=/vol/test.dump bs=1k count=102400

ec2# ll /vol/
合計 102520
drwx------ 2 root root     16384 2008-08-24 07:33 lost+found
-rw-r--r-- 1 root root 104857600 2008-08-24 07:42 test.dump

↑とりあえず、雀の涙ほどですが、動作確認のため100Mほどのテストファイルを作成します。

EC2インスタンスからログアウトして、、、

$ ec2-describe-volumes
VOLUME  vol-5026c339    5               us-east-1b      in-use  2008-08-24T11:29:52+0000
ATTACHMENT      vol-5026c339    i-e5fa208c      /dev/sdc        attached        2008-08-24T11:31:27+0000

お約束で、ボリュームの状態を確認します。先程使っていたID"vol-5026c339"のボリュームのスナップショットを今から作成します。

$ ec2-create-snapshot vol-5026c339
SNAPSHOT        snap-edf41384   vol-5026c339    pending 2008-08-24T11:44:13+0000

↑のような感じで、"ec2-create-snapshot"コマンドで、ボリュームID("ec2-describe-volumes"コマンドで確認できます)を指定するのみです。

$ ec2-describe-snapshots
SNAPSHOT        snap-edf41384   vol-5026c339    completed       2008-08-24T11:44:13+0000        100%

しばらく待って、スナップショットの状態を見ると、スナップショットが終了(100%と表示)していることが確認できます。
以上で、ボリュームのバックアップは完了です。超簡単。
ちなみに、上記スナップショットの作成元のボリュームは、EC2インスタンスにAttach、そしてマウントしたままの状態ですので、サービスを稼動したままスナップショットを作成することが可能です。

ただし、ボリュームへファイルの書き込みを行っている最中に、取得したスナップショットをリストアした際に整合性を保っているかどうかの確認はしていないので、注意が必要です。
# どうなんだろ？やっぱりダメかな？

尚、スナップショットID(上記例では"snap-edf41384")は復元(リストア)する際に必要となります。(この次に紹介しますので^^;)メモしておきます。

作成したスナップショットより、ボリュームを復元(リストア)してみる

では、先程作成したスナップショット(バックアップ)から、復元(リストア)する形でボリュームを作成します。

$ ec2-create-volume --snapshot snap-edf41384 -z us-east-1b
VOLUME  vol-5226c33b    5       snap-edf41384   us-east-1b      creating        2008-08-24T11:46:58+0000

↑のように、ボリュームを作成するコマンドと同じ"ec2-create-volume"コマンドに、"--snapshot"オプションを付けて、スナップショットID("ec2-describe-snapshots"コマンドで確認できます)を指定します。

尚、ボリューム作成時と同様に、稼動ロケーションも指定する必要があります。
上記の例では、今回作成(復元)したボリュームIDは"vol-5226c33b"となります。

$ ec2-attach-volume -d /dev/sdd -i i-e5fa208c vol-5226c33b
ATTACHMENT      vol-5226c33b    i-e5fa208c      /dev/sdd        attaching       2008-08-24T11:48:15+0000

では、作成(復元)したボリュームをEC2インスタンスにAttachさせます。この辺は、前半のほうで紹介した手順と同じです。
まだ、EC2インスタンスのOS内で使用されていないデバイスを指定するようにしましょう。

$ ssh -i rx7_server.id root@ec2-75-101-198-177.compute-1.amazonaws.com

では、動作確認のため接続して、、、

ec2# mkdir /vol2
ec2# mount /dev/sdd /vol2

Attachしたボリュームをマウントします。

ec2# ll /vol
合計 102520
drwx------ 2 root root     16384 2008-08-24 07:33 lost+found
-rw-r--r-- 1 root root 104857600 2008-08-24 07:42 test.dump

ec2# ll /vol2
合計 102520
drwx------ 2 root root     16384 2008-08-24 07:33 lost+found
-rw-r--r-- 1 root root 104857600 2008-08-24 07:42 test.dump

すると、今回の例で言うと、バックアップ元のボリュームをマウントしている"/vol"と、先程バックアップを復元(リストア)したボリュームをマウントしている"/vol2"の内容が(一応、簡単だけど)同じであることが確認できます。

ボリュームやスナップショットを削除してみる

ここまで、ボリュームを作成したり、スナップショットを作成したりなど、動作確認をしてきました。

最後に、掃除の意味を込めて、ボリュームやスナップショットの作成方法を紹介します。

ec2# umount /vol
ec2# umount /vol2

まず、EC2インスタンスのOS上でマウントしているデバイスをアンマウントします。

今回の例では、スナップショットの分も含めて、2つのボリュームをマウントしていたので、以降それぞれのボリュームに対してコマンドを実行していますのでご注意ください。

EC2インスタンスからログアウトして、、、

$ ec2-describe-volumes
VOLUME  vol-5226c33b    5       snap-edf41384   us-east-1b      in-use  2008-08-24T11:46:58+0000
ATTACHMENT      vol-5226c33b    i-e5fa208c      /dev/sdd        attached        2008-08-24T11:48:15+0000
VOLUME  vol-5026c339    5               us-east-1b      in-use  2008-08-24T11:29:52+0000
ATTACHMENT      vol-5026c339    i-e5fa208c      /dev/sdc        attached        2008-08-24T11:31:27+0000

ボリュームの状況を確認します。
↑では、2つのボリュームがAttachされているのが確認できます。
(左端に"ATTACHMENT"と表示される)

$ ec2-detach-volume vol-5226c33b
ATTACHMENT      vol-5226c33b    i-e5fa208c      /dev/sdd        detaching       2008-08-24T11:48:15+0000
$ ec2-detach-volume vol-5026c339
ATTACHMENT      vol-5026c339    i-e5fa208c      /dev/sdc        detaching       2008-08-24T11:31:27+0000

Attachしている2つのボリュームをそれぞれDetach(取り外し)します。

$ ec2-describe-volumes
VOLUME  vol-5226c33b    5       snap-edf41384   us-east-1b      available       2008-08-24T11:46:58+0000
VOLUME  vol-5026c339    5               us-east-1b      available       2008-08-24T11:29:52+0000

再び、ボリュームの状況を確認すると、2つともEC2インスタンスにAttachされていない状況が確認できます。
(左端に"VOLUME"と表示される)

$ ec2-delete-volume vol-5226c33b
VOLUME  vol-5226c33b
$ ec2-delete-volume vol-5026c339
VOLUME  vol-5026c339

次に、2つのボリュームをそれぞれ削除します。

$ ec2-describe-volumes
VOLUME  vol-5226c33b    5       snap-edf41384   us-east-1b      deleting        2008-08-24T11:46:58+0000
VOLUME  vol-5026c339    5               us-east-1b      deleting        2008-08-24T11:29:52+0000

再び、ボリュームの状況を確認すると、2つとも"deleting"となっています。
時間が経てば削除が完了し、上記コマンドで表示されなくなります。

$ ec2-describe-snapshots
SNAPSHOT        snap-edf41384   vol-5026c339    completed       2008-08-24T11:44:13+0000        100%

最後にスナップショットです。
上記コマンドで、スナップショットの状況を確認します。
↑では、先程作成した1つのスナップショットが確認できます。

$ ec2-delete-snapshot snap-edf41384
SNAPSHOT        snap-edf41384

上記コマンドでスナップショットが作成できます。

まとめ

ということで、Amazon EBSについても、Amazon EC2上の延長上で、非常に分かりやすい概念および操作方法で使用することが可能でした。APIが提供されているので、基本的に何でもコマンド一発で操作できます。

コマンド1つで、1GB〜1TBもの大容量の仮想ディスク(ボリューム)を即座に準備できて、即座に使うことができる。しかも、料金は使った分だけ請求される従量制でかなり安価となっています。

公式サイトのAmazon EBSの説明文を読む限りは、作成したボリュームは稼動ロケーションとは異なるロケーションにレプリカを作成している模様で、信頼性という点でも十分にありそうです。(サービスの継続性という意味での可用性は分かりませんでした)

それでもって、料金はというと、容量が1ヶ月あたり$0.1/1GBでかつ、100万のI/Oリクエスト毎に$0.1請求されますが、かなり安価な部類でしょう。

この前も書きましたが、このレベルのインフラを作ろうとすれば巨大な初期投資が必要となり、小さい企業や個人のレベルでは実現できません。
ですが、個人でも払えるレベルの料金体系から使うことが出来る、このAmazonのクラウド環境はかなり魅力です。

あとは、少しずつ日本でも普及が進んで、EC2やS3、そしてEBSの稼動ロケーションで日本が選択できる日が来れば、日本発のWebサービスでも当たり前のように使われる時代になるのではないでしょうか。

参考

まとめ

Amazon EC2/S3を使ってみた - まとめ (Amazon Web Services関連エントリ目次)

クラウドAMAZON EC2/S3のすべて (ITpro BOOKs)

作者: 並河祐貴,安達輝雄,ITpro/日経SYSTEMS
出版社/メーカー: 日経BP社
発売日: 2009/11/05
メディア: 単行本
購入: 4人クリック: 372回
この商品を含むブログ (18件) を見る