IT Labor Note: 5月 2014

2014年5月30日金曜日

EBS で暗号化がサポートされたのでベンチマークしてみた。

Amazon Web Service (AWS) のブロックストレージサービスEBSで暗号化がサポートされました。
使い方はとても簡単 EBS を作成するときに Encryption チェックボックスにチェックを入れるだけ。

一覧表示でもEncrypt の項目が追加されています。

残念ながら、ルートボリュームでは利用できないようです。

気になるのは暗号化による性能劣化です。マニュアルにも以下の記載があります。

you can expect the same provisioned IOPS performance on encrypted volumes as you would with unencrypted volumes with a minimal effect on latency.

暗号化ボリュームでも最小限のレイテンシで暗号化していないボリュームと同じプロビジョンドIOPS性能を期待できる。

実際に iozone で測定してみました。使用したインスタンスサイズは、m3.midium です。
まずは暗号化なしの場合。

こんな感じです。大きくへこんだところがあるのは多分の測定時に何か撹乱要因があったのでしょう。
次は暗号化ありの場合

ほとんど違いが分かりません。ちなみにこれは書き込みの場合をグラフ化したものです。
読み込みはほとんどIOPSが出ず、メモリに収まった感じだったので、省略します。

ファイルシステムを利用した場合は、ワークロードによっても影響度が変わってくると思いますが、暗号化のオーバーヘッドはほとんど無視できるようです。

2014年5月20日火曜日

Amazon Web Service (AWS) で一つの EC2 インスタンスにいくつ EBS がつけられるか試してみた。

EC2インスタンスに何個EBSがつけられるの？

Amazon Web Service (AWS) で一つのEC2インスタンスに何個 EBS がくっつけられるのかマニュアルを探してみたけれど、以下の記載しかなくどうもはっきりしたことが分からないので、実際にためしてみた。

Amazon Web Services General Reference

やってみる

Management Console からインスタンスウィザードを起動して、"Step 4: Add Storage"のところで、"Add New Volume" を連打した。"/dev/sdb" からはじまり、"/dev/sdz" を通り過ぎて "/dev/xvdz" が表示されたあたりで、このあたりで許してあげようと思い "Launch Instance"。

結果

一見インスタンス自体は問題なく起動しようとしているように見える。がいつまでたってもSSHログインできない。get system log をみると以下のように、Bug を踏んでいた。


4394230.182195] kernel BUG at fs/sysfs/group.c:65!

[4394230.182198] invalid opcode: 0000 [#1] SMP

[4394230.182203] Modules linked in:

[4394230.182207] CPU: 0 PID: 19 Comm: xenwatch Tainted: G        W    3.10.35-43.137.amzn1.x86_64 #1

[4394230.182215] task: ffff88002492c710 ti: ffff880024936000 task.ti: ffff880024936000

[4394230.182219] RIP: e030:[<ffffffff811eb772>]  [<ffffffff811eb772>] internal_create_group+0x202/0x230

[4394230.182228] RSP: e02b:ffff880024937c50  EFLAGS: 00010246

[4394230.182232] RAX: 0000000000000400 RBX: ffff880003544000 RCX: 0000000000000000

[4394230.182236] RDX: ffffffff8184dfc0 RSI: 0000000000000000 RDI: ffff880003544080

[4394230.182241] RBP: ffff880024937c88 R08: 00000000000163c0 R09: ffff8800260163c0

[4394230.182245] R10: ffffea0000927d00 R11: ffffffff81311bb2 R12: ffff880003590000

[4394230.182250] R13: ffffffff8184dfc0 R14: 0000000000000000 R15: ffff880003544070

[4394230.182259] FS:  0000000000000000(0000) GS:ffff880026000000(0000) knlGS:0000000000000000

[4394230.182264] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b

[4394230.182268] CR2: 0000000000000000 CR3: 000000000180c000 CR4: 0000000000002660

[4394230.182273] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000

[4394230.182277] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400

[4394230.182281] Stack:

[4394230.182284]  ffff880003544080 ffffffff81256951 ffff880003544000 ffff880003590000

[4394230.182291]  ffff880003544000 ffff880003544070 ffff880003544070 ffff880024937c98

[4394230.182298]  ffffffff811eb7b3 ffff880024937ca8 ffffffff810f84b4 ffff880024937ce8

[4394230.182305] Call Trace:

[4394230.182311]  [<ffffffff81256951>] ? kobj_kset_leave+0x51/0x60

[4394230.182316]  [<ffffffff811eb7b3>] sysfs_create_group+0x13/0x20

[4394230.182324]  [<ffffffff810f84b4>] blk_trace_init_sysfs+0x14/0x20

[4394230.182331]  [<ffffffff8123ecfd>] blk_register_queue+0x3d/0x110

[4394230.182336]  [<ffffffff81245a0d>] add_disk+0x1cd/0x4a0

[4394230.182341]  [<ffffffff81324a1d>] blkback_changed+0xd3d/0x1010

[4394230.294407]  [<ffffffff812da098>] xenbus_otherend_changed+0x98/0xa0

[4394230.294418]  [<ffffffff812dc083>] backend_changed+0x13/0x20

[4394230.294433]  [<ffffffff812d9436>] xenwatch_thread+0xb6/0x170

[4394230.294440]  [<ffffffff81070e10>] ? wake_up_bit+0x30/0x30

[4394230.294454]  [<ffffffff812d9380>] ? unregister_xenbus_watch+0x230/0x230

[4394230.294462]  [<ffffffff8106fee0>] kthread+0xc0/0xd0

[4394230.294477]  [<ffffffff8106fe20>] ? kthread_create_on_node+0x120/0x120

[4394230.294485]  [<ffffffff8144a12c>] ret_from_fork+0x7c/0xb0

[4394230.294498]  [<ffffffff8106fe20>] ? kthread_create_on_node+0x120/0x120

[4394230.294503] Code: 8b 7d d0 89 4d c8 e8 8e e7 ff ff 4c 8b 65 d0 8b 4d c8 e9 28 ff ff ff 4c 8b 65 d0 e9 1f ff ff ff 48 83 7f 30 00 0f 85 3e fe ff ff <0f> 0b b8 ea ff ff ff e9 29 ff ff ff be c3 00 00 00 48 c7 c7 ff

以下のようなログも出力していたので、多分デバイス名の付け方に問題があったのだろう。


[4394230.181916] WARNING: at fs/sysfs/dir.c:530 sysfs_add_one+0xa5/0xd0()

[4394230.181921] sysfs: cannot create duplicate filename '/class/block/xvdt'

[4394230.181925] Modules linked in:

[4394230.181931] CPU: 0 PID: 19 Comm: xenwatch Not tainted 3.10.35-43.137.amzn1.x86_64 #1

[4394230.181937]  0000000000000009 ffff880024937b50 ffffffff8143c559 ffff880024937b88

[4394230.181945]  ffffffff8104bac1 00000000ffffffef ffff88000358acb0 ffff880024937c38

[4394230.181961]  ffff880024aad000 0000000000000001 ffff880024937be8 ffffffff8104bb2c

[4394230.181969] Call Trace:

[4394230.181986]  [<ffffffff8143c559>] dump_stack+0x19/0x1b

[4394230.181995]  [<ffffffff8104bac1>] warn_slowpath_common+0x61/0x80

[4394230.182000]  [<ffffffff8104bb2c>] warn_slowpath_fmt+0x4c/0x50

[4394230.182015]  [<ffffffff811e9955>] sysfs_add_one+0xa5/0xd0

[4394230.182020]  [<ffffffff811ea5a5>] sysfs_do_create_link_sd+0x105/0x200

[4394230.182026]  [<ffffffff811ea6c1>] sysfs_create_link+0x21/0x40

[4394230.182041]  [<ffffffff81311de4>] device_add+0x3e4/0x6d0

[4394230.182047]  [<ffffffff81310517>] ? dev_set_name+0x47/0x50

[4394230.182061]  [<ffffffff812459fd>] add_disk+0x1bd/0x4a0

[4394230.182068]  [<ffffffff81324a1d>] blkback_changed+0xd3d/0x1010

[4394230.182084]  [<ffffffff812da098>] xenbus_otherend_changed+0x98/0xa0

[4394230.182091]  [<ffffffff812dc083>] backend_changed+0x13/0x20

[4394230.182097]  [<ffffffff812d9436>] xenwatch_thread+0xb6/0x170

[4394230.182110]  [<ffffffff81070e10>] ? wake_up_bit+0x30/0x30

[4394230.182117]  [<ffffffff812d9380>] ? unregister_xenbus_watch+0x230/0x230

[4394230.182124]  [<ffffffff8106fee0>] kthread+0xc0/0xd0

[4394230.182137]  [<ffffffff8106fe20>] ? kthread_create_on_node+0x120/0x120

[4394230.182145]  [<ffffffff8144a12c>] ret_from_fork+0x7c/0xb0

[4394230.182157]  [<ffffffff8106fe20>] ? kthread_create_on_node+0x120/0x120

まとめ

AWS 的には、EBSを何個つけても問題なさそうだが、実際にたくさんEBSを付ける場合にはいろいろ考慮が必要なようだ。

2014年5月12日月曜日

RDSのMySQL でリードレプリカを作成するときの3つのポイント

RDS-MySQL のリードレプリカ

MySQL には、多くの皆さんがご存じのとおり、リードレプリカという機能がある。

簡単に言うと DB のコピーを自動的にとってくれる機能なのだが、普通に設定すると結構煩雑でちょっと面倒臭い。

Amazon Web Service (以下AWS) で、提供している RDS というサービスで、MySQL を利用することができる。このサービスではリードレプリカも簡単に設定できるようになっている。

以下のようにメニューから選んで、必要項目を入力するだけでとっても簡単。

リードレプリカをたくさん作る

たくさんの参照があって書き込みが少ないデータベース、例えば Word Press のバックエンド等ではたくさん、リードレプリカを作って負荷分散することが効果的なケースがある。

このとき RDS を利用すると簡単にたくさんのリードレプリカを作成できて、非常に便利。だがいくつか制限がある。

一つのマスターに対して作成できるリードレプリカは5つまで

一つのマスターに対して作成できるリードレプリカは5つまで。この制限を超えると以下のようなエラーが出力される。

極端にリードレプリカをたくさん増やしても、マスターへのレプリケーションの負荷が増加するので、この制限もまぁ妥当なものだろう。

リードレプリカのリードレプリカ

ではもっとたくさん作りたい場合はどうすればいいかのか。答えはリードレプリカのリードレプリカを作成すればいい。

Automated Backups を Enabled にする

ただその場合、リードレプリカ側で Automated Backups が Enabled になっていなければいけない。

デフォルトでは Enabled になっていないので以下のようにレプリカを選択して右クリックから、 "modify" を選択して、"Backup Retention Period" を 1 以上に設定する。

これをしないとそもそも "Create Read Replica" をメニューから選択することもできない。

このときに "Apply Immediately" にチェックを入れておかないと次回のメンテナンスウィンドウか、手動で再起動されるまで、設定が反映されないので忘れずに。上の例では、ドロップダウンメニューの後ろに隠れている。

リードレプリカのリードレプリカは2段まで

ただし、リードレプリカは2段までしかできない。つまりリードレプリカのリードレプリカは作れるけれど、リードレプリカのリードレプリカのリードレプリカは作れない。作成しようとすると、以下のようなエラーが出力される。あんまり段数を増やしても今度はレプリケーションの遅延が大きくなるので、この制限はまぁ妥当なものだろう。

リードレプリカは全部で30個

マスターに対してリードレプリカは5個さらに5個のリードレプリカに対して5個ずつリードレプリカができるので2段目は 5 × 5 で、25 個。一つのマスターに対して合わせて30個のリードレプリカが作成できる。

ただし 30 個まで作れるものの実際のレプリケーションの負荷もばかにならないので、よっぽど書き込みが少ない場合も除いて実際の参照用として利用できるのは2段目の25個だけだと思っていい。

また2段目まで書き込みが反映されるまでのレイテンシーも2倍以上になるので、この点も考慮する必要がある。

まとめ

RDSのリードレプリカを作成する際は以下の3つに注意する必要がある。

一つのマスターに対して5個まで。
多段レプリカは2段まで。
Automated Backups を有効にする。

最後に

便利に見えるリードレプリカですが、コスト面や読み取り専用としてしか使えないなど不便なところもあるので、実際の運用としては先に以下の方法も検討した方がよい。

インスタンスのサイズ変更で対応できないか。
PIOPS を利用で改善できないか。

上記二つの方が、リードレプリカを作成するよりも簡単で効果が高い場合もあります。

登録: 投稿 (Atom)