仕事の備忘録

IT系技術とか、カスタマーサービスとか

meltdownのパッチでAWSのPostgreSQLがやられた

セキュリティ

今年は仕事はじめから今日までずっと「meltdown」と呼ばれるCPUの脆弱性対応で休みがほぼない状況だった。忘れないうちに記録する。会社に怒られたら消すけど数値は出さずとりあえず書く。

www.publickey1.jp

この脆弱性によって担当していたシステムがハッキングされたわけではない。この脆弱性が緊急度が高く、Azure、AWSなど一部クラウド環境には事前にパッチが適用されたのだが、そのパッチが担当システムにて影響がでてサーバ自体がダメになってしまったのだ。やっと今日すべて事業が通常に戻ったので久方ぶりにビール飲みつつこれを書いている。

原因と結果を端的に書くとこれだけ。ただ仕事とセキュリティと事業継続性などから色々な勉強にもなった。

まずクラウドを使う場合、クラウド環境自体は常にベンダーによって脆弱性は解消され最新に保たれるため、オンプレではありがちなパッチ適用を見送るという方法はできない。今回のパッチも、年末のうちにアナウンスが出ていたので事前に受け入れ準備して対応していた。（メンテナンス時間の通告があってそれまでに自分で再起動的なことをしないと通告時間に強制再起動となる。）

クラウドを使っている限り最新が適用されることは前提なのだが、私の担当システムは２０１３年から稼働しており、AWSでも古いタイプのPVを利用していた。他にHVMというものがあるが違いはこちらがわかりやすかった。

kanny.hateblo.jp

そして今回１月３日に適用されたAWSのパッチは、PVの場合のみ大幅なCPUの稼働ダウンを引き起こした。

実はシステムは今年終了が決定しているため延長サポートモードで1年近くPG変更をしてない。変更点はパッチのみである。この場合変更点は明らかである。あからさまにAWSのパッチしか変更がなかった。

しかし、当初全く何が起きているのか理解できなかった。利用開始の朝、システムが問題ない稼働状況で、特定のDBサーバのみCPU100%とシステムダウンを繰り返した。これを利用者による問題として調査を開始したが問題が出てこない。担当者間で悩んでいるうち夕方となった。そしてシステム利用率がさらに上がるとき、同一機能の全サーバが一斉にCPU100%からのダウンを記録した。これでAWSの問題の可能性に初めて気づきググって問題に気づいた。

qiita.com

今回の問題点はAWSのパッチの不具合とパッチ自体の内容が利用してたDBであるPostgreSQLと相性最悪だったことが大きい。他にもパッチが適用されたサーバ群があったが、DBまでの機能低下はなかったのだ。実測値でその日自社DBは負荷テストや実績の２５％程度しか稼働できなかった。システム利用率が年初で高いこともあり、事業影響は大きかった。

対応として最初スケールアップは最大まで引き上げた。が、CPUが100%になると反応しなくなるという状況で必要な性能に到達しない。通常はCPU100%でも処理は継続できたのに（実績ではL/AがCPU1つにつき2.5くらいまでOKだった）。これより対応策をシステムオーナーと打ち合わせ、AWS以外でサーバを準備し切り替える策をとった。ハイブリッドクラウドと呼んでいいと思う。サーバ作成とかネットワーク設定とかテストに追われた。

準備中の1月13日にAWSは再度パッチ提供を行いブログが更新された。 

プロセッサの投機的実行に関する公開調査について | Amazon Web Services ブログ

1/13にさらにアップデートされたパッチがリリースされた模様

2018/01/11 20:15

ずっとブログで報告してくださっていた方の検証結果も確認し、ツイッターでも解消の報告が多数みられることをメンバーに共有した。しかし公式で再度パッチを適用すると記載があり、再発が０ではない状況でAWSのままにする選択はなかった。

「AWS、またパッチ当てたってよ」と聞いたので3度目のAurora（MySQL互換）R4テスト（mysqlslap） - Qiita

結果を公表してくれてありがたいです。今から自分のシステム確認します。

2018/01/13 20:14

AWS発表では「性能低下はなかった」という文書がでており、上記ブログの追記で「それはどうなの？」とメンバーでも話題となった。が、私以外のメンバーは優秀なので 皆業務遂行し、検証リリースを実施。効果測定も終わり今日やっと元の性能が出る状態になった。

正直PVインタンスを利用して問題が発生した方々は大変だったはずだ。チューニングしたシステムが勝手に悪くなるのだから。しかしそれも考慮して対応できるようにするのがクラウドを使うためのルールなのだと強く感じた。

そして昔自分も実装担当したサーバ切り替え機能が、今回大いに役立ち「よく考えられてるシステムだなあ」と終わりが近いシステムの大騒ぎでちょっとだけ自分たちを褒めた瞬間もあったことを書いておく。