更新情報

こんにちはー。野田貴子です。

今月も海外のRailsコラムを意訳してご紹介します。ご参考になれば幸いです。

###

MeltdownとSpectreの脆弱性がIT界隈を騒がせているのをご存知でしょうか。この脆弱性はCPUのパフォーマンスを最適化している部分に存在するため、脆弱性を修正するパッチによってCPU最適化の効能が下がってしまうことが懸念されています。このパッチによるRailsアプリへの影響を調べたベンチマークがありましたので、ご紹介します。

How Much Does Meltdown/Spectre Patching Slow Down a Big Rails App?

http://engineering.appfolio.com/appfolio-engineering/2018/1/4/rails-ruby-bench-cruby-and-meltdownspectre

最近のほぼすべてのCPUに影響を与えてしまう「Meltdown」「Spectre」という脆弱性について、すでに耳にした方も多いと思います。それらを修正するためのパッチが、システムのパフォーマンスをいくらか下げてしまうという話(*1)もご存知かもしれません。どのベンチマークを参照するのかにもよりますが、だいたい5%から20%、あるいはそれ以上の代償があるといわれます。

それでは、高度な並行処理をもつRailsワークロードである、Rails Ruby Benchはどうでしょうか。UbuntuはすでにMeltdownとSpectreのパッチを(ほぼほぼ……下記参照)提供していますので、確認してみましょう。

(なぜRailsを検証するのがこれほど遅くなったのかというと、1月9日がMeltdownとSpectreが一般に公表される本来の予定日だったのに対し、Ubuntuは3つのCVE(*2)に対する完全なパッチをリリースするのに1月22日までかかったからです。つまり、我々はだいぶ前からこの脆弱性に関するニュースを知っていましたが、Ubuntuのパッチがまだできていなかったのです。)

■新旧の比較

去る1月22日、UbuntuはMeltdownとSpectreの亜種3つに対するパッチを公開しましたが、ハイパーバイザとハードウェアに対する重大な免責事項がありました(*3)。SpectreとMeltdownをこちらの脆弱性チェッカー(*4)で確認すると、パッチが適用されたAWS上のUbuntu Xenial AMI(*5)でも、昨日の時点ではまだ完全にパッチが当たっているわけではないように見えます(下記の出力を参照のこと)。ですので完全にパッチが当たった後は今よりもう少し遅くなる可能性があります。

今回は以前使用したAMI設定をベータ版のDiscourse 1.8.0とRuby 2.3.4/2.4.1に使用しました。パッチ適用前との比較を適切にできるようにするためです。バージョンアップ前のDiscourseとRubyは何パターンも持っていますし、MeltdownとSpectreのパフォーマンス低下はどのワークロードを使うのかにもよるのですが、上記の組み合わせは、Discourse 1.9とRuby 2.5の組み合わせとほぼ同じになるでしょう。

それぞれの計測結果はRuby、Discourse、パッチレベルの各組み合わせに対して6000のリクエストの20のバッチをベースにしています。30のロードテスタースレッドと10のサーバープロセスを、それぞれ6のサーバースレッドで定義しています。これらはすべてAWS m4.2xlargeによるインスタンスで実行されますが、network I/Oはありません。6000のリクエストを実行する前に、各プロセスで100のウォームアップを行いました。これらのすべては私の通常のRails Ruby Benchの設定であり、特別な理由がない限りいつもこの設定を使っています。つまり、この記事を読めば、みなさんも実際に計測できたも同じです。

それでは次の章でいくつかの数字を見てみましょう。

■グラフと数字

パッチ適用前のRails Ruby Benchの結果はすでに多数あるので再テストする必要はないのですが、みなさんの参考のために一部をここに含めました。「pre-patch」と書かれている項目です。さらに1月9日から1月22日の間のパッチも計測しました。それらは「partial patch」の項目で、Ubuntuの1月9日のパッチと、ハイパーバイザにパッチを当てるために再起動したAWSサーバーの結果があります。そして最後に「patched」の項目ですが、これは1月22日のパッチを含み、その日時点で最新のUbuntu公式のクラウドAMIをベースにしています。繰り返しますが、今後さらにパッチが配布される可能性があります。脆弱性チェックツールによるとまだ解決されていない問題があると出ていて、Ubuntuのアナウンス(*6)にも多くの免責事項が書かれています。

こちらに検証結果の簡単なグラフとテーブルを載せます(*7)。これには、少なくとも私は、驚きました。5%から20%のパフォーマンス低下は見られません。実は1月9日のパッチからは多少のパフォーマンスの打撃がありましたが、1月22日のパッチで元のパフォーマンスに完全に戻ったようです。ネットワークの入出力を行わない専用のAWSインスタンスがあるので、余計な問題を見ずにすみます。これらの数値は月を追うごとに驚くほど安定してきているので、もし5%の下降があれば、きっと分かるでしょう。これらの結果はとても僅差です。もしかしたら本当は違いはなく、計測にノイズが混ざっているだけなのかもしれません。

真ん中のグラフが少し減少していますが、大した値ではありません。そして正しい(パッチが適用された)結果はパッチ前とちょうど同速度でした。

Ruby Version    Patch Status    Throughput

2.3.4           Pre-patch       161.8

2.4.1           Pre-patch       166.4

2.3.4           Partial         159.8

2.4.1           Partial         164.6

2.3.4           Patched         164.5

2.4.1           Patched         167.0

■結論

これらのデータを踏まえた私の推考ですが、1月9日のMeltdownとSpectreの初期のパッチは、大きな並行Railsアプリでは、非常に小さな、0%から5%程度のパフォーマンスの代償がありました。ほんの少しの影響です。Ubuntuパッチ、Amazon AWSパッチ、あるいはその両方の影響であるかどうかを区別することはできませんでした。

しかし1月22日のものについていえば、並列Railsパフォーマンスでさえ、現在のMeltdownとSpectreのパッチ適用後も速度減少は見られませんでした。これらのパッチは完全ではない(上記参照)といえる根拠はあります。ですのでこれを長期的に見るのは時期尚早です。しかし今のところ心配する理由はないと考えています。

これはRailsがI/Oに縛られているからでしょうか?Rubyがすでにとても速く、CPUがボトルネックにならないため、CPUの速度減少は問題ではないのということなのでしょうか?その可能性もありますが、私はそうは考えていません。RubyのバージョンアップによってRailsの速度が上がらない理由と根拠は同じです。RailsはI/Oに重きを置いたワークロードで、推定上、ある時点でそれはとても最適化しずらくなります。しかしCRubyのRailsはいまでも他の多くのWebフレームワーク(DropwizardやTorqueboxなど)より遅くなっています。そしてRubyは毎年Railsのスピードアップを続けており(*8)、それは今後も続きます(*9)。ですので、Railsがその最適化しづらくなる時点に達したとは考えていませんし、SpectreのパッチによるCPU速度減少を気付けないほどだとも全く考えていません。

*1 https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=2

*2 https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2017-5754.html

*3 https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown

*4 https://github.com/speed47/spectre-meltdown-checker

*5 https://cloud-images.ubuntu.com/locator/ec2/

*6 https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown

*7 https://static1.squarespace.com/static/562ea223e4b0e0b9dab0b930/t/5a67d409f9619aeb41dfd535/1516753940938/Screen+Shot+2018-01-23+at+4.28.56+PM.png

*8 https://appfolio-engineering.squarespace.com/appfolio-engineering/2017/8/21/rails-and-discourse-startup-times

*9 https://appfolio-engineering.squarespace.com/appfolio-engineering/2017/12/26/ruby-3-and-jit-where-when-and-how-fast