2014年6月30日月曜日

OSv を AWS EC2 からアップロードしたメモ

先日どこかのもくもく会で取り上げられていましたが、OSvという OS があります。 designed for cloud と銘打っておりクラウド向けに最適化されたOSを目指しています。
OSv is designed from the ground up to execute a single application on top of a hypervisor, resulting in superior performance and effortless management
現代のOSは Linux を含めて、非常に高機能で複雑になっています。
これはオンプレミス上で多様な機器をサポートしたり、さまざまなワークロードに単体で対応する必要があるからです。

一方でクラウドをはじめとする仮想化環境ではハードウェア自体は仮想化され、もともとOSが担っていた多くの機能に関してはクラウドベンダやハイパーバイザが担っているため、ゲストOS側ではミドルウェアで必要とする最低限のインターフェイスだけを残しておけばいいという考え方でOSvは設計されています。

というわけで、実際にためしてみたいと思います。今回はまずOSのイメージを AWS 上に転送するところから始めて見たいと思います。

手順はここを参考にしました。

AMI の起動

AWS Linux では、いくつかのパッケージが不足しているので、Red Hat (Cent OS) もしくは、Fedora の AMI がお勧めだそうです。今回は私は、RHEL-6.5_GA-x86_64-7-Hourly2 (ami-aa8bfe9a)を利用しました。 普通に起動して、SSH 接続します。RHEL も時間課金で利用できるので、気楽に利用できます。

必要なパッケージ、ツールのインストール

パッケージのインストールから、github からのダウンロードまでやってしまいます。
sudo yum install git
sudo yum install ant autoconf automake boost-static gcc-c++ genromfs libvirt libtool flex bison
sudo yum install qemu-system-x86 qemu-img maven maven-shade-plugin python-dpkt tcpdump gdb
git clone https://github.com/cloudius-systems/osv.git
cd osv
git submodule update --init --recursive


AWS CLIのインストール

wget https://s3.amazonaws.com/aws-cli/awscli-bundle.zip
unzip awscli-bundle.zip
sudo ./awscli-bundle/install -i /usr/local/aws -b /usr/local/bin/aws


同じく AMI ツールのインストール

wget http://s3.amazonaws.com/ec2-downloads/ec2-api-tools.zip
sudo mkdir /usr/local/ec2
sudo unzip ec2-api-tools.zip -d /usr/local/ec2


環境変数の設定 

export AWS_ACCESS_KEY_ID=AKI.........................
export AWS_SECRET_ACCESS_KEY=XXX........................
export EC2_HOME=/usr/local/ec2/ec2-api-tools-1.7.1.0/
export JAVA_HOME="/usr/lib/jvm/jre-1.7.0-openjdk.x86_64/"

EC2_HOME のバージョンは各自確認してください。
AMI ツールは IAM ロール未対応 なので、IAMロールを設定した場合でもアクセスキー、シークレットキーの設定は必要なようです。


実行

ここまでで、環境の準備は終わりです。時間は30分もかからないでしょう。
vim 等のテキストエディタで以下の内容でテキストファイルを作成します。
ファイル名は例えば、"images_0.09.txt" などとします。

v0.09-small
http://downloads.osv.io.s3.amazonaws.com/cloudius/osv/osv-v0.09.qemu.qcow2
small

一行目が作成されるイメージの名前、2行目が元イメージがおいてある URL 3 行目がインスタンスサイズのようですが、内容は未確認です。

cd osv
./scripts/upload-ec2.sh < ~/images_0.09.txt

これでほおっておくと勝手に AMI が出来上がります。時間は結構かかります。
やっていることはおおよそ以下の通りです。
  1. イメージをダウンロード
  2. qcow2 のイメージを raw イメージに変換
  3. イメージを S3 にアップロード
  4. S3 上のイメージを EBS に変換
  5. 新しいインスタンスを作成して stop する
  6. インスタンスの EBS を差し替え
  7. AMI を作成する。
  8. インスタンスのTerminate

この手順を実施すると、N.Virginia (us-east-1) に public な AMI が作成されます。
きっとリリース手順をそのまま書いたのでしょう。紛らわしいので、私のAMIは削除しておきます。

OSv designed for cloud
http://osv.io/

Upload OSv AMI from EC2 instance
https://github.com/cloudius-systems/osv/wiki/Upload-OSv-AMI-from-EC2-instance

2014年6月25日水曜日

Amazon Elastic Block Store (EBS) General Purpose (SSD) volumes (gp2) の バースト特性

先週リリースされた EBS gp2 タイプですが、これまでのスタンダードタイプよりバースト性能が改善されています。 バーストの仕様についてはマニュアルや公式ブログにかなり詳しく記載されていますが、実際に動作確認を行ってみました。

まずはおさらい

この前の記事にも記載しましたがEBS gp2 のバースト仕様を簡単におさらいしておきます。
  • バースト時の最大出力は 3000 IOPS
  • バーストの制御方法は、Token Bucket 方式
  • Token は容量1GBあたり毎秒3個づつ補給される。
  • Token 一個は 1 I/Oに相当
  • Token はEBS 1 個あたり最大 5,400,000 個 保存できる。
  • EBS作成時は、5,400,000 個 Token が補充される。

今回のテスト環境

今回使用した環境は、m3.xlarge を使用しました。OS側の影響を少なくするために少し大きめのインスタンスを利用しています。I/O 処理する分と、dd が動作する分と、sar と ssh が動く分でCPU 4つぐらいあれば大丈夫かな? という程度の考え方です。

EBS は gp2 タイプ 100 GB 確保して、ブートディスクとは別にインスタンスにアタッチしました。

単純に IOPS がでればいいので、以下のコマンドラインで負荷をかけました。

while true ; do dd if=/dev/zero of=/dev/xvdb bs=4k ; done 

以前はIOPSでの課金があったので、ベンチマークを実施するときはお財布を気にしながらでしたが、EBS gp2 タイプでは従量課金がなくなったので安心して負荷をかけることができます。

プレウォームを実施

EBSは特性上、プレウォームを実施すると全体の特性が良くなります。
今回もプレウォームを実施しました。

実施結果

cloudwatch の VolumeWriteOps の結果です。
CloudWatch では、EBS の IO 数を 5 分間隔で取得できます。
5分間のIO数合計が出力されます。

左から一つ目の山がプレウォーム時のものです。プレウォーム時で5分間に 約 600,000 IO 出ています。60s × 5 = 300 s で割ると、 2,000 IOPS ぐらいです。プレウォームしないと、3,000 IOPS は出ません。 

二つ目の山が、プレウォーム後少しおいて再度負荷をかけた時のものです。大体 800,000 IO 出てますので、およそ 2,666 IOPS です。 3,000 ぴったりにはなっていないですが、大体いい値ではないでしょうか。

その後は大体 300 IOPS で安定しています。
バーストしている時間はプレウォームの期間も含めておよそ30分強でした。これも仕様と大きく離れていません。

復活するか

その後2時間ほど負荷を停止して token がたまるのを待って見ました。満タンになるのに5時間ほどかかってしまうので、2時間ほどでどれだけ復活するか見てみました。
最後の山が復活した時のものです。たしかに停止するとバーストは復活します。ただためている時間が短いので、10分程度しか持ちませんでした。

Token はいつ補充されるのか

Token がどのタイミングで補充されるかはマニュアルに明確な記載がありません。ここからは完全な推測です。

上のグラフは sar で取得した await の出力をEXCEL でグラフにしたものです。
OS 側で取得したのでかなりばらつきが大きくなっています。

間隔は1秒間隔で取得しています。最初の塊がプレウォーム時のもので大体 70-80 ms で推移しています。これは実ブロックの割り当て処理のオーバーヘッドでしょう。

その後暫く休憩して次にバースト時のものです。大体 50-80 ms ぐらいです。

最後に値が大きくなっているのはバースト終了後のもので、大体 480 ms ぐらいです。
バースト時とバースト終了時の差分が大体 400ms ぐらいです。

この差分は、Token が補充されるまでの時間だと予測できます。
おそらく1秒間に3個補充されるのではなく、300数十ms に1個補充されているのではないでしょうか。
それで1秒あたり3個補充されていることになるかと思います。

まとめ

EBS gp2 タイプのバースト特性はおおよそ以下の通りだと思います。
  • token がある限り IO を払いだす。
  • 3000 IOPS が、おおよその性能上限
  • バースト時は結構ばらつきが大そう
  • token は、300 数十 ms 毎に補充される 
おまけ
私は個人的には実はIOPSはあんまり気にしていません。

IOが不足しているかどうかの判断は VolumeQueueLength を参考にしています。
もし IO が要求に追い付いていないならば、キューの値が増加して減らなくなります。
もしキューにIOが無いならば、そもそもIO要求が来ていないことになります。

またキューがたまっている状態では IOPS は最高値になっているはずで、それ以上にIOが必要なっていることを示すだけで、余りサイジングの参考になりません。長期的にみて増加傾向ならばその傾向からある程度、サイジングの参考にはなると思います。

2014年6月18日水曜日

Amazon Elastic Block Store (EBS) で SSD がデフォルトになりました。


既にあちこちで取り上げられていますが、Amazon Web Service (AWS) のブロックストレージサービスである、Amazon Elastic Block Store (EBS) で SSD がデフォルトで利用できるようになりました。

マニュアルや料金表、SIMPLE MONTHLY CALCULATORも改版されています。

オンプレ環境と比較して速度的に劣るといわれていたEBSも、これで汚名を挽回できるでしょうか?

もちろんインスタンスのルートボリュームとしても利用できます。
(突然マネジメントコンソール上での、インスタンスウィザードからインスタンスを起動しようとしたら、SSDも選べるけどどうする?みたいなポップアップがでて大騒ぎしてしましました。)

もちろん30GB までの無料使用権も付いています。

EBSのタイプ

これまで "standard" ボリュームと表記されていたEBSタイプは、"Magnetic" と表記されるようになりましたが一覧表示等では、これまで通り "standard" と表示されるようです。

このアップデートでEBSのボリュームタイプは以下の3種類になります。
ボリュームタイプAPIと CLIのボリューム名
General Purpose (SSD)gp2
Provisioned IOPS (SSD)io1
Magneticstandard

さらに従来の standard ボリュームではわずかですが、IO量に応じた従量課金がありましたが、今回から廃止されました。プロビジョンしたディスク容量だけの課金となります。

EBSの性能

性能に関してはこれまでの standard ボリュームから大きく改善されています。最大 3000 IOPS のバースト性能を持ちます。これまでは Provisioned IOPS (PIOPS) を利用しない場合バーストでも数百 IOPS でしたから10倍以上の改善となります。バーストなので利用できるIOPSに制限がありますが、最低でもおよそ30分程度は継続して利用できます。

もっとも今時のSSD製品では数万IOPSを掲げる製品も出てきているので、今後の改善を期待したいところです。

IOPSの帯域制御は IO Credits という非常にユニークな方法を採用しています。

利用可能なIOPSは1GB あたり 3 IOPS が毎秒追加されます。例えば300GBのEBSを用意したとすると、毎秒 900 IOPS が追加されます。IOPSは一秒間にIOした回数なので、最低でも 900 IOPS は利用できるわけです。

一方利用しなかったIOPSは、最大 5,400,000 IOPS分まで蓄積できます。蓄積されたIOPSは最大3000IOPSまで一度に消費できます。

300 GBの EBS ならば、900 IOPS は最低利用できるので、3000 - 900 = 2100 IOPS が消費されるます。5,400,000 ÷ 2,100 = 2571.4... なので、およそ42分ぐらいは、バーストを継続できます。もちろん最大 1 TB = 1000 GB を確保すると、毎秒 3000 IOPSをずっと利用できるわけです。

このバースト性能が向上しているのは LINUX で ext4 のようなファイルシステムを利用している場合は非常に有利です。

ext4 は、基本的にはIOPSを可能な限り押さえるように動作します。そのためメモリ上にたくさんバッファしておいてあるときにまとめて書き出すようになっています。

メモリが不足してバッファを解放するような処理を実施したときに大量のIOPSが一時的にそれも間欠的に発生する場合があります。

このときプロセスはメモリ獲得待ちになりIOが完了するまで待たされます。

これはプロセスが直接メモリ獲得要求を実施した場合だけでなくシステムコールの延長線上で一時的なメモリ確保が発生した場合でもメモリ獲得待ちになり処理遅延につながります。最悪 OOM Killer の餌食になってしまいます。

そのような場合に一時的にでも多くのIOPSが使えると非常にシステム上は有利になります。

コスト

コスト的には、東京リージョンで 1GB あたり 1ヵ月 $0.12です。
100GB利用して月1000円ぐらいです。

120GBのSSDが8000円台で入手できることを考えると少し高い気がしますが、自分で設置したり、故障交換したりデータセンターに置いたりのコストを考慮すると、まぁ妥当な値段かと思います。

ただ注意しなければいけないのは PIOPS (io1) との使い分けです。

例えば、io1 で100GB で 1000 PIOPS プロビジョニングすると

容量  $0.142 × 100GB      = $14.2  
PIOPS $0.074 × 1000 PIOPS = $74 
合計                         $88.2 
(7月からの新料金で計算)

になります。一方で GP2 で 400 GB 相当確保した場合は容量課金だけなので

$0.12 × 400GB =$48 

です。これで 400GB × 3 IOPS/GB なので、1200 IOPS 確保できて、
容量も 4 倍なので非常にお得感があります。

もっとも PIOPSのようにIOPSを保証するとは言っていないのでその点は考慮する必要がありますが、3000 IOPS を超えるような IO 帯域が常時必要なユースケースは限られるので、名前の通り通常は GP2 を選択して問題ないのではないでしょうか。

また standard ボリュームからみると、値上がりしていますが 10 倍程度の性能差と 100 GB あたり $4 程度の差分なのでよほどコストにシビアでない限り GP2 を選択することになるとおもいます。

もしコスト重視ならば EBS ではなく S3 や Glacier の利用もできるので、standard ボリュームが選択される機会は減っていくのではないでしょうか。

また IOPS を重視するならば、いっそデータをファイルに置かずに、Dynamo DB に格納してしまうという方法もあります。

小さなデータを大量に読み書きする場合は、PIOPS を利用するよりも安くなるユースケースもあるとおもいます。何よりもストレージのサイズを気にしなくてよくなります。

Introducing the Amazon EBS General Purpose (SSD) volume type

【AWS発表】新しいSSDベースのElastic Block Storage

【超速報】Amazon EBSに「SSD」が追加されてるぞ!

Amazon Elastic Block Store (Amazon EBS) (マニュアル)

Amazon EBS Volume Types

Amazon EBS の価格

SIMPLE MONTHLY CALCULATOR

Intel SSD 320 Series (600GB, 2.5in SATA 3Gb/s, 25nm, MLC)