AWS EC2で動いるシステムが、1月4日のMeltdown/Spectreパッチ適用以降すごくパフォーマンスが落ち、その影響でシステム障害が発生しました。
そのとき、twitterやFaceBookで情報いただいた件を簡単にまとめます。
EC2(m1.medium)上で動いている非常にDBヘビーな商用CMSがあり、年明け後そのCMSがMySQLへのセッション数が溢れてしまうことが原因でシステム障害が発生していました。
調査すると1月4日以降、MySQLで域値を0.1sに設定してあるslow-queryの発生数が何倍にも増えていることがわかり、少なくともMySQLのパフォーマンス低下があることがわかりました。
1月4日にはEC2の計画再起動が行われており、これはMeltdown/Spectreパッチ適用によるものでした。
そのため、パッチ適用前と後のDB処理速度を数値的に比較できるものがないか探してみました。
MySQLのslow-queryのログに、毎日定期で重いバッチクエリのものが出ていたため、この処理時間の変動である程度比較できるのではと考えました。
そこで以下のように、4つの重いバッチクエリに対して、パッチ適用前後5日のクエリ処理時間平均を算出しました。
適用前 適用後 倍率 A 226.26s 375.06s 1.66倍 B 110.09s 210.94s 1.92倍 C 30.68s 56.83s 1.85倍 D 23.18s 74.56s 3.21倍
1.6から3.2倍となっており、少なくともこれらのクエリについては2倍弱は遅くなっている感じがわかりました。
この結果から、twitterやFaceBookで同様の状況になっている方がいないか聞いたところ、何人もの方から同じような状況だったり、そのためにインスタンスタイプを変更されているとのお話をうかがいました。
どうもEC2の旧世代PV方式インスタンスのものだと、特に今回のMeltdownパッチの影響を大きく受けるようで、少なくとも20%程度、RDBだとそれ以上の速度低下があるようです。
Auroraでは6割から7割程度までにパフォーマンスが下がっているというレポートもあり、それはこの障害で出ている状況とも感覚的に一致していました。
ただt2インスタンスなど、新しいHVM方式のものだと性能も上がっているうえ、パッチの影響によるパフォーマンス低下も少ないため、問題が起きないようです。
(参考)
MeltdownとかSpectreとか騒ぎがあったので、Amazon Aurora(MySQL互換)R4インスタンス再テスト(mysqlslap) - Qiita
Auroraでのパフォーマンスが63%〜73%程度に落ちていることがレポートされています。
投機実行の脆弱性修正、Haswell世代以前では性能への影響大 〜I/O集中型アプリケーションを利用するサーバーは慎重な選択を。AMDはほぼ影響受けず - PC Watch
Haswell世代以前の古いCPUのほうが影響を受けることが指摘されています。
ただし、AWSの公式見解としてはMeltdown/Spectreでの性能低下はほとんどなかった、という立場のようです。
AWSもSpectreとMeltdownの対策完了を報告。対策後、Amazon EC2で性能の低下は見られないと − Publickey
そのため、インスタンスタイプを
m1.medium → t2.medium
に載せなおすのが最善策ではないかという結論になりました。
PV方式のインスタンスからHVM方式のインスタンスへの載せ替えについて、下記エントリ
AWS EC2のインスタンスが新年早々各地で起動しなくなる可能性がある件 - 株式会社アクシア
に、EBSをほぼそのまま付けなおして移行する手法が、ある程度詳しく書かれていました。
HVM方式が始まったあたりにPV→HVMへの移行について書いてあるものは、変換が必要だったりともっと手数が掛かって大変なものが多いので、この手法が良さそうに思います。
ただ、bootのコピーなどの詳細までは書かれていないので、多少実験して経験を積んでから行ったほうが安全そうです。