こんにちは、ひろかずです。
社内でt2.smallを使いたい話が出たので、一筆書きます。
AWSインスタンスファミリーにT2インスタンスが追加されました。
smallインスタンスについては、メモリが1GB(t1.small)から2GB(t2.small)へと倍増されたため、ワークロードの少ないサーバについては、t2.smallの利用が選択肢に入ってくると思います。
T2インスタンスの特色として、CPUクレジットが目を引きます。
公式リリースから引用しますと、
t2.smallインスタンスは、2.5 GHz(ターボモードで最大3.3GHz)のIntel Xeonプロセッサのシングルコアの20%へアクセスすることができます。
とあり、
CPUクレジット
上記の表に示すように、各T2インスタンスは、インスタンスのサイズによって決定される速度でCPUクレジットを受け取ります。 1CPUクレジットは1分間の完全なCPUコアのパフォーマンスを提供します。
とあります。
公式リリースを読む限り、CPU利用率のベースライン(t2.smallは20%)を超過すると、CPUクレジットを使用してバーストするようです。
#検証目的とスコープ
t2.smallを使用した場合、Deep Securityの動作によりCPUクレジットをどれくらい使用するかを明らかにする。
Deep Security Agent側でCPUを主に使用すると言われている機能のうち、定常的に動作させることが想定される、以下機能を使用した時のCPUクレジット使用状況の確認する。
- 不正プログラム検索機能のスケジュールスキャン
- 予約タスクで実行する変更検索タスク
#環境情報
- Deep Securityは、9.5sp1を使用しました。
- Deep Security ManagerとAgentは、同一VPC内に配置します。
- Deep Security Agentを導入するインスタンスは、Ubuntu(3.13.0-53-generic)を使用しています。
- Deep Security Agentを導入するインスタンスには、nginxが導入されていますが、サービスリクエストは流入していません。
- Deep Security Agentを導入するインスタンスのストレージはEBS(Standard)で、サイズは8GBにしています。
- 不正プログラム検索設定は、
Default Schedule Scan Configrationを使用します。 - 変更検索タスクの対象は、「Trend Micro Deep Security 9.0 変更監視ルール スターターガイド」掲載のディレクトリを対象とします。(URL確認中)
#検証手法
- 毎時20分に不正プログラム検索を実行する。
- 毎時45分に予約タスクにて変更検索を実行する。
- 試験期間は24時間とする。
#結果
右肩上がりの青い線がCPUクレジットです。
オレンジのスパイクしている線がCPUクレジットの使用を示しています。
大きいスパイクが不正プログラム検索を実行した時点のもので、1回あたり1.4クレジット程度を消費しています。
小さいスパイクは、変更検索タスクを実行した時点のものです。
CPUクレジットが粛々と蓄積されていることから、本検証の条件下では、Deep Securityの動作単体でのCPUクレジット消費はあまりない事が分かります。
2時間程度にズームすると以下のようになります。
CPU利用率を見てみると、t2.smallのベースライン(20%)を超過していることがわかります。
#最後に
今回の検証では、Deep Securityの動作がCPUクレジットをそれほど消費しないことが分かりました。
一方で、CPU利用率が20%を超えた時点でCPUクレジットを使用することも分かりました。
CPU利用率を常時20%を超えるワークロードが発生する環境では、CPUクレジット枯渇によるパフォーマンス劣化が予想されます。
t2.smallを利用する際は、CPUクレジットの残高推移をウォッチして、適切なインスタンスサイズに変更できる余地を残しておくのがいいと思われます。
本日はここまでです。
お疲れ様でした。