CDP:Ondemand Diskパターン
提供:AWS-CloudDesignPattern
動的なディスク容量の増減
目次 |
解決したい課題
システムで利用するディスク容量を事前に見積もるのは難しい。よってシステム稼働時には、安全係数を掛けて数年後に想定される容量のディスクを準備するケースが多い。そのディスクはすぐに使わないばかりか、実際には何年経っても使わないかもしれない。そんなディスクに費用を支払うことになる。
また、ディスクI/Oの性能を向上させたい場合、ディスクストライピングを行うことが有効である。しかしストライピングをテストする場合もニーズにマッチしたディスク数を見積もることが難しく、またテストを行うにもハードウエアの初期投資が必要となる。
クラウドでの解決/パターンの説明
クラウドでは仮想ディスクを利用できる。仮想ディスクは、いつでも好きなタイミングで必要なだけの容量を確保可能である。
仮想ディスクを利用すれば、前もって精緻に見積もらなくてもよい。システムを稼働させた後に利用量を見ながら必要な容量のディスクをオンデマンド(OnDemand)に確保すればよい。
ディスクは年々容量単価が下がる傾向にあるので、必要になったときに確保するというのは費用面のメリットが大きい。また、一時的に大容量のディスクが必要になった場合、従来なら大容量のディスクを調達するしかなかったが、仮想ディスクなら必要なときに調達して使い終わればすぐに破棄できる。
実装
AWSの仮想ディスクEBSを持ちいれば、いつでも好きなタイミングで必要な容量を確保できる。
(手順)
- EBSを使用する際、最初は必要最低限のサイズのボリュームを確保しておく。
- より大きなディスク容量が必要になった場合、EBSスナップショットを取り、そのスナップショットを基に新しいEBSを作成する。
- 新たなEBSを作成する際、元のボリュームより大きなボリュームサイズを指定する。
- 新しいEBSをEC2インスタンスにアタッチする。
- アタッチ後、使用しているファイルシステムのリサイズコマンド(例えばresize2fs)で新しい容量まで領域を拡張する。[関連ブログ 1]
- ストライピングを行う際は、複数のEBSをアタッチし、mdadmやOSの機能を使用してソフトウエアRAIDのディスク構成にする。
- また安定して高いスループットを求める場合にはプロビジョンドIOPSとEBS最適化オプションを利用することが望ましい。指定できる最大IOPSは20,000IOPSである(2015年4月時点)。
構造
利点
- 後からボリュームサイズを変更できるので、見積もり時の負担を軽減できる。
- 必要なときにディスク容量を確保することで、費用面のメリットがある。
- ストライピングを行うことで、ディスクI/Oの性能を向上できる。
注意点
- EBSはS3とは異なり、確保したディスク容量に対して課金する。例えば、100Gバイトの領域を確保して実際には5Gバイトしか使用していなくも100Gバイト分課金される。
- 一つのEBSに設定できるディスク容量の上限は16Tバイトである(2015年4月時点)。このため、単一のパーティションで16Tバイト以上の容量が必要な場合は、複数のEBSをアタッチし、mdadmなどのソフトウエアで単一のボリュームとしてまとめて使用する。
- 20,000IOPS以上のスループットが必要である場合には複数のEBSを使ってストライピングする。
その他
EBSはネットワーク経由でアクセスするディスクボリュームであるため、よりサイズの大きいEC2インスタンスを利用する方がI/O性能が高くなる。特にストライピングを行う場合は、EC2インスタンスサイズに注意する。
関連ブログ
- ↑ suz-lab - blog の「"中身をそのままにEBSのサイズを増やす方法のまとめ」( http://blog.suz-lab.com/2012/06/ebs.html )
- ↑ Amazon Web Services ブログ の「"【AWS発表】16TB、20K IOPSのAmazon Elastic Block Store(EBS)ボリューム」( http://aws.typepad.com/aws_japan/2015/03/faster-and-larger-ebs-release.html )