cloudpack night #7 ã«å‚åŠ ã—ã¾ã—ãŸ / EC2 における AES-NI の話

先日行われた cloudpack night #7 に参加しました。 http://www.zusaar.com/event/978005
主催された cloudpack の id:yoshidashingo さんのまとめはこちら。 http://d.hatena.ne.jp/yoshidashingo/20130826/1377527798

新卒入社5ヶ月目、社会人なりたてのぺーぺーではあるのですが、 僭越ながら若手 LT 枠で発表させていただきました。

EC2 環境における AES-NI の性能について紹介しました。
AES 暗号化するならインスタンスをよく見たほうが良いですよ、という話です。
LT の資料だとうまくまとまらない気がしたので記事という形でまとめておきます。

AES-NI とは

詳細はここで説明するよりググったほうが良いです。
一言で言うと AES 暗号の CPU サポートで、Intel CPU の Westmere (2010年前半) 世代から載るようになったのでそれなりに日が経ってはいます。
OpenSSL(たぶん 1.0.0e~) では既に利用できるようになっています。

EC2 における AES-NI

結論から言うと、EC2 においても AES-NI を利用することができますが、1点だけ落とし穴が存在します。
ヘビーに AWS を利用されている方には既知の問題かと思いますが、 同じインスタンスタイプにおいても割り当てられる CPU が違うことがあります。
(この詳細は con_mame さんのエントリに分かりやすくまとめてあります)
もちろん AWS 側でも世代間の差が少なくなるよう、CPU によってインスタンスへの割当時間調整をしていたりするとは思いますが、
ハードウェアサポートについては如何ともしがたいところでしょう。
同じインスタンスタイプのインスタンスで、AES-NI がサポートされているものとそうでないものがあります。

AES-NI の有無によるパフォーマンスの違い

というわけで、どのくらいのパフォーマンス差が存在するのか検証を行いました。
m2.2xlarge (13 ECU) のインスタンス2台、CentOS6 の環境で、 OpenSSL はディストリビューション標準のパッケージを利用しています。
※計算速度の比較にどうして m2.2xlarge? という声もありそうですが、諸事情です
2台のマシンにははそれぞれ knight, padawan という名前をつけておきます。
フェニックス一号にしようかと思ったのですがやめました。

CPU の確認

まず2台の CPU を確認します。/proc/cpuinfo から得られる情報のうち関係ありそうな部分を抜粋してみます。

knight

processor : 0
model name  : Intel(R) Xeon(R) CPU E5-2665 0 @ 2.40GHz
cpu MHz     : 2399.998
flags       : fpu de tsc msr pae cx8 cmov pat clflush mmx fxsr sse sse2 ss ht syscall nx lm rep_good unfair_spinlock pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes avx hypervisor lahf_lm

padawan

processor : 0
model name  : Intel(R) Xeon(R) CPU           X5550  @ 2.67GHz
cpu MHz     : 2666.760
flags       : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse sse2 ss ht syscall nx lm rep_good unfair_spinlock pni ssse3 cx16 sse4_1 sse4_2 popcnt hypervisor lahf_lm

上記のように knight の flags には aes の文字が見えますが padawan にはありません。
このため、padawan (X5550) では AES-NI がサポートされていないものと考えられます。
※ Intel の Web サイトからも探せるようになっています

OpenSSL での確認

次に OpenSSL 側での状態を確認します。

knight

$ openssl engine -c -t
(aesni) Intel AES-NI engine
 [AES-128-ECB, AES-128-CBC, AES-128-CFB, AES-128-OFB, AES-192-ECB, AES-192-CBC, AES-192-CFB, AES-192-OFB, AES-256-ECB, AES-256-CBC, AES-256-CFB, AES-256-OFB]
     [ available ]

padawan

$ openssl engine -c -t
(aesni) Intel AES-NI engine (no-aesni)
     [ available ]

というわけで、AES-NI が搭載された knight 側でのみ aesni モジュールでサポートできる 暗号化モードが表示されています。 これで、knight が AES-NI を利用でき、padawan はそうではない、ということが分かります。

OpenSSL ベンチマークオプションでの計測

openssl には speed オプションという暗号化モードのスループットを計測できるオプションがあります。
これを knight, padawan でそれぞれ実行しました。
暗号化モードとして AES256 (CBC モード) を利用して計測し、 同時に、AES-NI の有無以外での差がないか調べるため 3DES のスループットも計測しました。

結果

下記グラフのような結果が出ました。

グラフに載せ忘れてしまったのですが、単位は kbytes/s です。
256 bytes の暗号化スループット値を抜粋していますが、どのサイズでも開きは大体同じでした。
AES-256-CBC では knight が padawan に約5倍以上の性能差をつけています。
逆に 3DES では padawan のほうが knight のスループットを若干上回っています。
上に書いた CPU 情報を見ると padawan のほうがクロック周波数は若干高いので、 ハードウェアサポート無しでは単純にクロック周波数の高い padawan が速かったということでしょうか。
3DES を使ったときの性能を見る限り CPU 自体の処理性能として knight と padawan に それほど差はなさそうなので、AES-NI の有無による効果と言ってよさそうです。

ファイルの暗号化

ではこれが実用上どのくらいの差になるのかということで、 ほんの軽い程度ではありますが、ディスクI/Oを伴う暗号化速度を計測してみました。
80MB くらいの圧縮済みログを使います。
(暗号化したログを S3 に置いておくとかよくあるパターンだと思うので)
EBS ではなく ephemeral disk にファイルを置いて計測しました。

結果

下記グラフのような結果が出ました。

またしてもグラフに載せ忘れているのですが単位は sec です。
1ファイルの暗号化に5秒くらいの差がつくとなると、 大量のファイルを暗号化しながら処理するような環境では全体の処理時間に かなりの影響を与えるのではないでしょうか。

まとめ

EC2 でも AES-NI の恩恵は受けられることが無事確認できました。
実際測定してみると、無視できないレベルで違いがあることが分かります。

AWS をはじめとしたクラウド環境は確かに物理マシンのことを考えなくて便利〜となりがちなのですが、 仮想マシン側から見える、"その向こう"の環境に思いを馳せておくと、 こういう細かい点で得できるんじゃないかなと思います。
AWS 側の物理環境もどんどん更新されているでしょうし、 使う側としてはぜひハードウェアサポートも含めた全力を引き出したいところです。

会そのものも、発表は正直だいぶ緊張したのですが、興味を持っていただけた方もいたようで良かったです。その後の懇親会も楽しかったです。
というわけで、楽しい場を提供してくださった cloudpack さん、ありがとうございました:)

追伸: 社会人になりました

学業を共にした Macbook を破壊してから早いもので半年が過ぎました。
冒頭で触れましたが昨年度で大学生を終えて社会人にクラスチェンジしました。
今のところサーバを dd で破壊したりはしていません。
社会人として、うっかりでマシンを破壊しない慎重さを身につけるべく日々がんばっています。
今後ともよろしくお願い致します。