gp2を使用したインスタンス(8GB)でDeep Security Agentを動かしてみた

こんにちは、ひろかずです。

EBS(gp2)を使用したインスタンスで問題が出た話があったので、一筆書きます。

約一年前の2014/6/17にAWSインスタンスに使用できるEBSにGeneral Purpose (SSD)ボリュームタイプが追加されました。
【AWS発表】新しいSSDベースのElastic Block Storage

詳細は上記リンクを見ていただくとして、要約すると、メリットは以下のとおりです。

• サイズ(GB)x3 IOPSのベースラインが保証される
• バーストクレジットを使用して最大3000IOPSのパフォーマンスが提供される
• EBSの利用量に対して課金
• EBS毎に540万I/Oクレジットが割り当てられる

暫く前からインスタンス起動時のStorage選択画面でデフォルトでgp2が選択され、最後の確認画面でもgp2を推奨する確認画面が表示されます。

一方で以下の様な問題に遭遇することが起こっています。

• 2015/7/4現在、I/Oクレジットの使用状況を確認することができない。
• Linuxは、rootボリュームがデフォルト8GBであるため、そのままgp2を選択するとベースラインが24IPOPSになる。
• ベースラインが24IOPSの環境では、バーストクレジットを使い切ると極端にDisk I/Oが遅くなり、サービスへの影響が発生する。

rootボリュームのサイズを100GB程度にしていれば良いのですが、なんとなく作ったインスタンスは意外と問題があるかもしれません。

検証目的とスコープ

EBS(gp2)を使用したインスタンス場合、Deep Securityの動作によりI/Oクレジットを使いきってしなわないかを明らかにする。

Deep Security Agent側でディスクI/Oを主に使用する機能のうち、定常的に動作させることが想定される、以下の機能を使用する。

• 不正プログラム検索機能のスケジュールスキャン
• 予約タスクで実行する変更検索タスク

結果の判定は、開始時刻と終了時刻が明確に確認できる 不正プログラム検索機能のスケジュールスキャン の実行時間の差異を用いる。

環境情報

• Deep Securityは、9.5sp1を使用しました。
• Deep Security ManagerとAgentは、同一VPC内に配置します。
• Deep Security Agentを導入するインスタンスは、Ubuntu(3.13.0-53-generic)を使用しています。
• その他の機能による影響を排除するため、起動後のインスタンスにDeep Security Agentのみを導入しています。
• Deep Security Agentを導入するインスタンスは、EBS(Standard)とEBS(gp2)それぞれを用いたものを用意します。
• ストレージのサイズは8GBにします。
• 不正プログラム検索設定は、Default Schedule Scan Configrationを使用します。
• 変更検索タスクの対象は、「Trend Micro Deep Security 9.0 変更監視ルール スターターガイド」掲載のディレクトリを対象とします。(URL確認中)

検証手法

• 毎時20分に不正プログラム検索を実行する。
• 毎時45分に予約タスクにて変更検索を実行する。
• EBS(gp2)と(Magnetic)のインスタンスにて実行する
• 試験期間は24時間とする。

結果

時間帯	m3.medium-gp2	m3.medium-mag
14時台	0:02:09			0:02:09
13時台	0:02:09			0:02:09
12時台	0:02:09			0:02:09
11時台	0:02:09			0:02:09
10時台	0:02:09			0:02:09
09時台	0:02:08			0:02:09
08時台	0:02:09			0:02:09
07時台	0:02:09			0:02:08
06時台	0:02:09			0:02:09
05時台	0:02:08			0:02:09
04時台	0:02:09			0:02:08
03時台	0:02:09			0:02:09
02時台	0:02:09			0:02:08
01時台	0:02:09			0:02:08
00時台	0:02:09			0:02:08
23時台	0:02:09			0:02:08
22時台	0:02:09			0:02:08
21時台	0:02:08			0:02:09
20時台	0:02:09			0:02:08
19時台	0:02:09			0:02:09
18時台	0:02:09			0:02:09
17時台	0:02:24			0:02:25
16時台	0:02:09			0:02:09
15時台	0:02:21			0:02:31

値は実行にかかった時間です。(終了時刻-開始時刻)
24時間では有意な差は見られませんでした。
検証で使用したインスタンスは、Deep Security以外の動作を殆ど行っていません。
純粋なDeep Securityの動作ではI/Oクレジットを使い切るようなことはないようです。

終わりに

少々予想外の結果でした。
Windows OSでは結果が異なるかもしれませんので、同じ検証やってみたいと思います。
この検証は、あくまでDeep SecurityだけでI/Oクレジットを使い切るかを確認したに過ぎません。
インスタンスを作成する時は、サイズとストレージタイプに注意して、障害の芽は摘んでおきましょう。

本日はここまでにします。
お疲れ様でした。