Amazon Elastic Block Store (EBS) を使用すると、ブロックストレージボリュームを作成し、作成したボリュームをEC2インスタンスにアタッチすることができます。 EBSボリュームは1GBから1TBの間でサイズを自由に選択でき、スナップショットバックアップを作成したり、数クリックでスナップショットからボリュームを作成したりでき、ボリュームの暗号化を無料で行えるオプションも用意されています。
EBSは2008年の夏にサービスを開始し、2012年にプロビジョンドIOPS (PIOPS)ボリュームを追加いたしました。 簡単に復習しますと、IOPSはInput/Output Operations per Secondを省略したものです。単一のEBSボリュームあたり、最大4,000IOPSまでプロビジョンすることができ、RAIDを組むなどして、複数のPIOPSボリュームをつなげて使うことで、最大48,000IOPSまで性能を発揮することができます。(詳しくはEBS RAID Configurationのドキュメントをご覧ください。)
本日、新しく、General Purpose (SSD)ボリュームタイプをデフォルトで提供するブロックストレージとして追加することで、EBSを強化いたしました。 この新しいボリュームタイプは、様々な種類のワークロード(中小規模のデータベース、開発およびテスト、ブートボリュームなどなど)のために料金と性能のバランスがとれたボリュームを提供するよう設計されており、新しいボリュームを作成する際の、第一候補となるものです。 また、この新しいボリュームはプロビジョンドIOPSをサポートするために構築した技術スタックを活用し、既存のEBSボリュームタイプと同様に99.999%の可用性を提供するよう設計されています。
General Purpose (SSD)ボリュームは、磁気ストレージをベースとするボリュームに比べて、10倍以上のIOPS、10分の1のレイテンシー、より太い帯域幅と一貫した性能をお客様に提供するために、費用対効果が高くなってきているSSDストレージを利用します。 料金体系もシンプルになっています。1GBあたり、1ヶ月あたり$0.10の料金がストレージの容量に対してのみかかります。(プロビジョンしたIOPSに対して料金がかかりませんし、ディスクI/Oにも料金がかかりません。)
General Purpose (SSD)ボリュームは、低コストで、多くのワークロードに対する性能を満たせるように設計されています。 最大3,000IPOSまでバーストし、設定されたストレージ1GBあたり、最低3IOPSの性能が出るようになっています。 言い換えると、10GBのボリュームであれば、30IOPS、100GBであれば、300IOPSが最低ラインとして保証されます。 後でバーストモデルのメカニズムの詳細をお話しますが、ほとんどのアプリケーションは、バーストを超えるようなことはなく、実際の性能は通常ベースラインより高くなります。 ボリュームは、設定したIOPSの性能に対して、一貫して、99%の性能を発揮するよう設計されています。
この新しいボリュームタイプは、よりスループットと一貫性を高めるために、EBS最適化インスタンスと併用することができます。
起動のブースト
新しいGeneral Purpose (SSD)ボリュームは、多くの点で、アプリケーションの性能と応答性を向上させることができます。 例えば、EC2インスタンスのOSを起動時に、目に見えるインパクトを与えます。
新しく作成されたSSDベースのボリュームは、起動時の30分間、最大3,000IOPSのバーストが割り当てられます。この初期割当により、LinuxであろうとWindowsであろうと、起動が非常に高速になりますし、EC2上で使用するオペレーティングシステムに関係なく、複数のブートサイクルを行うにも十分です。
我々のテストでは、典型的なLinuxの起動にはだいたい7,000 I/O操作が必要で、Windowsの起動には、だいたい70,000のI/O操作が必要でした。Magneticボリュームから同じ容量のGeneral Purpose (SSD)ボリュームにスイッチすることで、Windows 2008 R2の典型的な起動時間はおよそ50%短縮されます。
AWSをすでにご利用いただいているお客様であれば、各EC2のAMIはデフォルトのEBSボリュームタイプを指定することを知っているかもしれません。 異なるボリュームタイプを指定したい場合は、インタンスの起動時に指定することができます。 EC2のコンソールでは、簡単に、General Purpose (SSD)ボリュームをデフォルトの選択肢にすることができ、コンソールから起動されるインスタンス全てを、その設定にすることもできます。
インスタンスを起動するのにコンソールを使用する場合、ボリュームを起動する際のデフォルトのボリュームを変更することができます。 次のように、今回限りか、今後コンソールから起動する全てのインスタンスに対してこの設定を適用するのかを選択できます。(Magneticストレージを選択することもできます。)
コマンドラインもしくはEC2のAPIを使ってEC2インスタンスを起動する場合、新しいボリュームタイプを使うために、異なるブロックデバイスマッピングを指定する必要があります。AWS CLIをつかって、コマンドラインから実行する例は次のとおりです。:
$ aws ec2 run-instances \
--key-name mykey \
--security-groups default \
--instance-type m3.xlarge \
--image-id ami-60f69f50 \
--block-device-mappings '[{"DeviceName":"/dev/xvda","Ebs":{"VolumeType":"gp2"}}]' \
--region us-west-2
コマンドラインやEC2のAPIを使う際、もっと簡単にGeneral Purpose (SSD)を起動ボリュームとして使えるようにするために、General Purpose (SSD)がデフォルトになっている最新のAmazon Linux AMIおよび、英語版のWindows Server 2012 RsベースのAMIが利用可能になっています。 ご希望のリージョンで最新の公開されたGeneral Purpose (SSD) Windows AMIのIDを取得するには、次のように、Get-EC2ImageByNameコマンドレットを使用します:
C:\> Get-EC2ImageByName -Names Windows_Server-2012-R2_RTM-English-64Bit-GP2*
Amazon Linux AMIの名前とIDは次のとおりです。:
| リージョン |
AMI ID |
フルネーム |
| us-east-1 |
ami-aaf408c2 |
amazon/amzn-ami-hvm-2014.03.2.x86_64-gp2 |
| us-west-2 |
ami-8f6815bf |
amazon/amzn-ami-hvm-2014.03.2.x86_64-gp2 |
| us-west-1 |
ami-e48b8ca1 |
amazon/amzn-ami-hvm-2014.03.2.x86_64-gp2 |
| eu-west-1 |
ami-dd925baa |
amazon/amzn-ami-hvm-2014.03.2.x86_64-gp2 |
| ap-southeast-1 |
ami-82d78bd0 |
amazon/amzn-ami-hvm-2014.03.2.x86_64-gp2 |
| ap-southeast-2 |
ami-91d9bcab |
amazon/amzn-ami-hvm-2014.03.2.x86_64-gp2 |
| ap-northeast-1 |
ami-df470ede |
amazon/amzn-ami-hvm-2014.03.2.x86_64-gp2 |
| sa-east-1 |
ami-09cf6014 |
amazon/amzn-ami-hvm-2014.03.2.x86_64-gp2 |
現在、既存のEBSベースのAMIのストレージオプションを簡単に選択できるよう、さらにシンプルにインスタンスのストレージを設定できるように作業を進めています。(アップデートにご期待ください)
EBSボリュームタイプの選択
本日の発表により、3つの異なるタイプのEBSボリュームを選択することができるようになりましたが、どのタイプを選択するのがベストなのか悩んでしまうかもしれません。ここではいくつかの考え方とガイドラインを紹介いたします。:
- General Purpose (SSD) - この新しいボリュームタイプは、中小規模のデータベース(NoSQLでもリレーショナルでも)、開発およびテスト環境、(上述したように)起動ボリュームに非常に適しています。 一般的には、このボリュームタイプから始め、必要に応じて、他のタイプに変更していくのが良いでしょう。RAIDを使って、複数のボリュームを接続することにより、最大48,000IOPSを達成することができます。
- Provisioned IOPS (SSD) - このタイプのボリュームは、最も要求の厳しいI/O集中型のトランザクションのワークロードや大規模なリレーショナルまたはNoSQLデータベースに最適です。 このボリュームタイプは最も安定した性能を提供し、必要とする性能を、最も予測可能で一貫した性能とともに正確にプロビジョンすることができます。 このボリュームタイプを選択すると、正確に必要な分だけプロビジョンし、プロビジョンした分にだけお金を支払うことになります。このタイプも、RAIDを使って、複数のボリュームを接続することにより、最大48,000IOPSを達成することができます。
- Magnetic - Magneticボリューム(旧Standardボリューム)は、全てのEBSボリュームタイプの中で1ギガバイトあたりのコストが最も安いので、アクセスがそれほど頻繁に行われず、コスト管理が主目的であるようなワークロードに最適です。
既存のボリュームのスナップショットを作成し、スナップショットから希望のタイプの新しいボリュームを作成することにより、他のボリュームタイプにいつでもスイッチすることができます。 また、tar、dd、 Robocopyといったマイグレーションコマンドやツールを使用することもできます。
フードの下 - 性能バーストの詳細
各ボリュームは、ボリュームのサイズに関係なく、バースト時に最大30分間にわたって、最大3,000IOPSを提供することができます。 IOPSのバーストは、上記のユースケースに最適であることはおわかりでしょう。 例えば、典型的なリレーショナルデータベースにより生成されるIOPSのロードはとてもスパイキーであることがわかっています。 データベースのロードおよびテーブルのスキャン操作はスループットのバーストを必要とする一方、その他の操作については、一貫した低いレイテンシーで行うことができます。 General Purpose (SSD) ボリュームは費用対効果の高い方法で全ての要件を満たすことができます。 私たちは、この普段はほとんどIOPSのバーストを浪費しないで、スパイキーな振る舞いにのみバーストを利用できるように、非常に多種多様なアプリケーションのワークロードを幅広く分析し、慎重に、General Purpose (SSD)を設計してきました。
General Purpose (SSD)の実装は以下のように、トークンバケットモデルです。: 
- 各トークンは1回の読み取りまたは書き込みのために支払う"I/O credit"を表します。
- バケットは、各General Purpose (SSD)ボリュームに関連づけられ、最大540万トークンを保持することができます。
- トークンはバケットの容量が一杯になるまで、1GBあたり、1秒あたり3の割合で蓄積します。
- トークンはボリュームあたり、秒間最大3,000まで消費することができます。
- ボリュームのパフォーマンスのベースラインは、トークンが蓄積される速度と等しく、1GBあたり、1秒あたり、3 IOPSです。
舞台裏で行われているこの仕事の全てが意味するところは、お客様が、希望のサイズのEBSボリュームを作成し、アプリケーションを起動するだけで、ボリュームに対するI/Oは、可能な限り高速かつ効率的に処理されるということです。
OpsWorks と CloudFormationのサポート
このタイプのボリュームをAWS OpsWorksのレイヤーの一部として作成することができます。:
次のようにCloudFormationのテンプレート内で作成することもできます。:
...
{
"Type":"AWS::EC2::Volume",
"Properties" : {
"AvailabilityZone" : "us-east-1a",
"Size" : 100,
"VolumeType" : "gp2"
}
}
...
料金
新しい、General Purpose (SSD)ボリュームは、アジアパシフィック(東京)リージョンで、プロビジョニングされたストレージ1GBあたり 1ヶ月 $0.12 でご利用いただけます。I/O操作に関する追加の料金はかかりません。他のAWSリージョンの料金については、EBSの料金ページをご覧ください。
また、今回の発表に合わせて、プロビジョンドIOPSボリュームのIOPSにかかる料金を35%値下げいたしました。 例えば、プロビジョンドIOPSボリュームを作成し、1,000IOPSを指定した場合の月額費用は、アジアパシフィック(東京)リージョンでは、$114から$74.1に下がります。 プロビジョンされたストレージに対する料金はいままでと変わらず、プロビジョニングされたストレージ1GBあたり 1ヶ月 $0.142 です。
-- Jeff;
この記事はAWSシニアエバンジェリスト Jeff BarrのAmazon Web Services Blogの記事、 を 堀内康弘 (Facebook, Twitter)が翻訳したものです。
このブログ記事を書くために、キャプションについて、かなり勉強しました。 用語「クローズドキャプション」は、閲覧者によって、有効にされた際にキャプションを参照します。 他のキャプション(「オープン」、「バーンイン」、または「ハードコーディングされた」キャプション)は全てのユーザーに表示されます。 1973年にクローズドキャプションが公式に登場して以来、いくつかの異なる規格が登場しています。 元々、テレビ番組のためのキャプション情報は放送信号の一部(
このブログをご愛読いただいている皆様であれば、
このような方達がAWSをより利用しやくするために、本日、新しい
