あすたぴのブログ

astap(あすたぴ)のブログ

Meltdown,Spectreの対応

をした。AWSです。

やったこと、方法をまとめておく。

前提条件

対応方法

AWSの対応

https://aws.amazon.com/jp/blogs/news/processor_speculative_execution_research_disclosure/

新しいAMIを起動する or sudo yum update kernel を実行すると対応が出来る。

対応方法

launch configのAMIを変更できないため、作り直しになる。 autoscaling groupに紐付けていると、作り直すことが出来ないため、一旦他のlaunch configに付け替えることになる。

A config を最初に紐付けていた場合、この設定を元にB configを作成し、このときAMIの設定を更新する。

具体的には今回は以下のように更新した。

使用していたAMI

- ECSクラスターインスタンス
  - amzn-ami-2016.09.g-amazon-ecs-optimized (ami-f63f6f91)
- EC2インスタンス
  - amzn-ami-hvm-2017.09.1.20171103-x86_64-gp2 (ami-2803ac4e)

最新のAMI

- ECSクラスターインスタンス
  - amzn-ami-2017.09.f-amazon-ecs-optimized(ami-72f36a14)
- EC2インスタンス
  - amzn-ami-hvm-2017.09.1.20180108-x86_64-gp2(ami-33c25b55)

autoscaling groupに設定しているlaunch configをB configに付け替える。 この状態で、最小台数を増やすことで新しいAMIでインスタンスが起動する。 このとき、AZで均等になるようにインスタンス数は倍にする。(AZにそれぞれ1台ずつの2台だったら4台にする)

以降はECSクラスタインスタンスとEC2でやり方が分かれる。

ECSクラスタインスタンス

新しいインスタンスクラスターに増えたことを確認したら、クラスターのインスタンスリストから古いインスタンスを選択し、dorainingをする。 drainingをすると、このインスタンスは廃棄予定ということがECSのagentに伝えられタスクを別のクラスターに安全に移してくれる。 一気にやってもいいと思うが一気にやった場合に、一時的にサービス数が倍になるためメモリが足りなくなりタスクを配置できなくなる可能性があるため、そこを気にしつつ行う。 すべての入れ替え予定のインスタンスをdrainingしてタスクがなくなったら、autoscaling groupに設定したインスタンス台数を元に戻す。 このとき、インスタンスの削除ポリシーがdefault or OldestInstanceになっていないと新しいインスタンスが削除されるかもしれないので確認しておく。 削除ポリシーは変更可能なので、このときだけ変えてもOK。

EC2インスタンス

インスタンスが起動したら、そのインスタンスが正常に機能しているかを確認する。 起動しただけでは機能していないなら、機能するように何かする。 既存のインスタンスと同じように稼働していることが確認できたら、autoscaling groupのインスタンス台数を元に戻す。

正常の機能しているかどうかは、ELB,ALB,NLBに紐付いているインスタンスがヘルシーになっており、サービス(Webアプリ)にアクセスできるかを見ればよいと思う。 確認方法は各サービスなり、動いているものによって変わるのでいい感じに見る。

ECSクラスタインスタンス同様に削除ポリシーは気にしておく。

まとめ

インスタンス起動時に、設定がすべて完了していて起動後のサービスへの入りも自動化されていれば簡単にインスタンスを入れ替えられる。 AMIも最新にして、ECSの場合はagent,Dockerのversionも最新に出来たのでちょうどよかった。

AWSが用意しているAMIに色々設定を入れて、イメージを保存してそれをlaunch configに指定しているとちょっと面倒だな。という感じ。

1台1台再起動、もしくはいくつかずつ再起動みたいなのは辛いのであまり選択したくない。