sorta kinda...

主にAWS関連ですが、これに限らずいろいろ勉強したことや思ったことを書いていきます。

Windows Server on AWS でディスクが遅いと思ったらやること

最近いろんな不具合を踏んでしまいます、那須です。

担当している案件で Windows Update すると適用完了まで数時間かかるとか、RDP の反応がむちゃくちゃ遅くなるとかの事象が出たので、そのことについてまとめて書いておきます。 同じ事象で苦しんでいる方の助けになれば幸いです。

 

事象が発生した環境

  • OS: Windows Server 2016
  • C ドライブ構成: 汎用 SSD (gp2) 40GB
  • 毎月決まった日時に Windows Update を実施
    • SSM ドキュメント「AWS-InstallWindowsUpdates」を利用

 

何が起こったのか?

AWS-InstallWindowsUpdates ドキュメントの実行が失敗したので、「何が起こってるんかな?」と思って対象インスタンスに RDP 接続したら、

  • RDP の操作がやたら遅い
  • アプリケーション自体は問題なく動いている(D ドライブ)
  • Windows Update ログ見たら KB のダウンロードがまだ続いていた

という状況でした。 今思えば、アプリケーションで問題が何も出ていないのが救いでしたね。

 

事象発生中にマニュアルで Windows Update 実施してみた

通常の Windows Update の手順だといくら待っても失敗したので、対象の KB スタンドアロンインストーラを準備して、それを実行する形で行いました。

 

うーん、終わらない…

と思ってたら 3 時間後に再起動を促されたので再起動しました。 再起動自体も 30 分くらいかかって、「あ、死んだな…」って思いました。 この時は本当に心臓に悪かったです。

 

原因は何だったのか?

全くわからんけどこの遅い状態のまま運用するのもちょっとまずい気がしたので、AWS サポートに問い合わせました。 結果、「BurstBalance が 0 になってんじゃね?」って回答だったんですが、BurstBalance って何よ?ってその時は思いましたね。 BurstBalance って何よ?って方は、↓この資料の 23 ページを見て下さい。

www.slideshare.net

簡単に言うと、C ドライブがベースラインの 120 IOPS で動いてて遅かったってことですね。

 

Windows Update ってそんなに IO かかるの?

よくわからないので、検証環境で確かめてみました。

 

検証環境

下記 3 AMI から起動したインスタンスを準備して比べてみました。

  • Windows_Server-2019-English-Full-Base-2019.02.09 (ami-04568cdbd4ceef482)
  • Windows_Server-2016-English-Full-Base-2019.02.09 (ami-0b6f27663776c2930)
  • Windows_Server-2016-Japanese-Full-Base-2019.02.09 (ami-00ca08896c37c01d0)

SSM で AWS-InstallWindowsUpdates ドキュメント実行

Windows Server 2019 は 10 分ちょっとで完了しましたが、Windows Server 2016 はざっくり 40 分くらいかかりました。 BurstBalance の推移は↓この通りです。

f:id:nasrinjp1:20190425222208p:plain
BurstBalance の推移

Windows Server 2019 はそんなに IO かかってるように見えませんが、Windows Server 2016 は 10% 近く減ってますね。 この差は一体…

 

なんとなく根本原因がわかってきた

S3 に溜まってる SSM のログを見てると、なんか Windows Server 2016 の Windows Update のサイズがでかいなーと気づきました。 もしかしてこれかな?と思って、 MS のカタログで対象の KB を検索すると…

Windows Server 2016:1374.5 MB
https://www.catalog.update.microsoft.com/Search.aspx?q=KB4493470
Windows Server 2019:163.7 MB
https://www.catalog.update.microsoft.com/Search.aspx?q=KB4493509

 

2016 の累積パッチデカすぎない!?

OS 間での差は KB のサイズが原因だったみたいです。 なんらかの要因で BurstBalance が減っている時にさらに KB のダウンロードが始まって適用しようとしたけど、EBS のバーストクレジットが足りずに牛歩で処理が進んでいた、という姿が見えてきました。

 

根本的に改善するにはどうすればいいか?

求めるディスクパフォーマンスがわかっていれば、gp2 のままサイズを増やすか、io1 で IOPS 指定したものに変更するかすればいいですね。 わからない場合は、io1 に変更して必要な IOPS を探ってから、その IOPS になるように gp2 でサイズ変更するか。 EBS (gp2) は大して料金かからないので、標準で 100GB って決めて運用するのもありですね(300 IOPS で十分なのかどうかはよくわかりません
ボリュームタイプ変更のやり方は、↓このドキュメントを見てください。

docs.aws.amazon.com

 

まとめ

今回はたまたま Windows Update でこのような事態に陥りましたが、Linux やアプリケーションでも同じようなことが起こる可能性は十分あります(ありますよね?きっと

なので、EBS の BurstBalance は CloudWatch でモニタリングするべきだと思いました。 傾向がつかめていれば事前になんとかできると思います。 Datadog や Mackerel でモニタリングすれば、Slack 等のチャットにも簡単に通知できて運用メンバーがすぐ気づけていいかもしれませんね。