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 等のチャットにも簡単に通知できて運用メンバーがすぐ気づけていいかもしれませんね。

転職して 1 年経ったので振り返ってみる

今年は飼っているカブトムシの幼虫が 2 匹まで減ってしまった那須です。 原因はわかりません。。

今の会社(BeeX)に転職して早 1 年が過ぎました。 あっという間でしたね。 最近自分の脳みそからいろんなものが漏れ出てるのを実感しているので、記録に残すためにも振り返ってみます。 昨年末にも振り返りをしましたが、振り返ることって個人的には本当に大事だと思っています。 単純に振り返っても仕方ないので、昨年末に書いてないことを書いてみますね。

 

なんでリモートワークになったのか?

話を聞きに行く前には当然募集要項的な情報は仕入れていたんですが、その時は勤務地は東京だけでした。 「あーやっぱ東京だけかー」ってその時は思いましたね。 東京で仕事してると、いろんな人に会えるしいろんなチャンスが巡ってくるしいろんな仕事ができる。 それは否定しません。

「でも仕事場所を固定する必要ってあるんかな?」って 2 年くらい前から思うようになってからは、本当に仕事場所って概念が変わりましたね。 IT 関連の仕事って PC とネットワークさえあればだいたいのことはできるようになっています。 なので、無理して電車に乗って、特に用事もないのに決まった時間にオフィスに行って、何事もなかったかのように同じ時間に帰っていくっていうのがだんだん理解できなくなっていく。 で、これが意外と話しても共感してもらえることのほうが少なかったり。 まだまだリモートで仕事するってのがマイナーなんだな、って思いました。 (でも自分の周りにはそういう人がたくさんいるんですけどね。

いざ面接で「関西で仕事したいんですけど」って言ったらあっさり OK でたのが拍子抜けでしたね。 あー言ってみるもんやな、って。 社長が醸し出すカルチャーというか雰囲気がなんとなく自分とあってそうで安心したのを覚えています。

というわけで、これから転職したい人で好きな場所で仕事したいのであれば、やりたい仕事や入りたい会社が特定の場所にしかなくても勇気を持って聞いてみるといいんじゃないかなと思いますね。 アカン!って言われても死ぬわけじゃないし。 怒られたりバカにされたり恥かいたりする場面もあるかもしれませんが、勇気を持って行動した結果は自分自身をいい方向に導いてくれますよ。

 

AWS の認定資格を取得できた!

アソシエイトは持っていましたが、個人的には「やっと Pro 取れたわ…」って感じです。 下記の 2 つを今年に入ってから合格しました。

  • AWS 認定ソリューションアーキテクト - プロフェッショナル
  • AWS 認定 DevOps エンジニア - プロフェッショナル

前職(cloudpack)で身につけた AWS の基本と、転職してから身につけた自動化関連のスキルが見事に合わさって、1 ヶ月ほど真剣に毎晩勉強したら合格できました。 次はセキュリティあたりを目指そうか。 AWS はなんだかんだ言ってセキュリティの話ができないといけないと実感してるので。 でも本当に幅広く AWS のことを知れた 1 年でした。

 

チャット文化が出来上がった!

昨年末の振り返りでも少し Slack 導入の話題を書きましたが、BeeX でもついに Slack が本番運用に乗りました! プランはスタンダードですが、フリーより全然マシどころかいい感じすぎます。 マジめでたいです!

メールや Facebook Messenger などでのコミュニケーションから社内コミュニケーションは Slack となったことで、明らかに公開/共有される情報量が増えた気がします。 気軽に誰かが書いたことに対してどんどんスレッドが長くなってて、覗いてみたら議論してたり好きなことについて思ってることを伝え合ったりしていて、明らかにいい雰囲気が出てきました。

この人はこういうのが好きなのか、みたいな情報も見えてきましたし、毎日 Slack を見るのが楽しいですねw
あの日、勇気を出して Slack 使いませんか?!って自分の思いと Slack のメリットをあわせて長文メールにして招待リンクを送ってよかったと思っています。

チャット文化になってきたので、次のステップに進んでいきますよ! Slack はインフラでありオフィスでもあります! チャットだけで使うなんてもったいない!

 

振り返った感想

この 1 年での変化がいろいろありすぎて自分の人生がちょっと変わったなって思いました。 生活スタイルも仕事の仕方も自分の役割というか立ち位置も、何もかもが初めての状態です。 これからも初めてのことだらけでしょう。 ま、それがいいんですけどね。道なき道を突き進んでいくのって楽しいよw
あと、文章を書くのは苦にならなくなったなって思いました。

 

クラウドの仕事したい人来て!

会社の公式採用ページからでもいいですし、私に DM とかを送ってもらってもいいです。 クラウド見たことも触ったこともなくてもいいです。みんな最初は初めてです。IT インフラの知識があればなんとかなります。私はクラウドの世界で仕事したいって思ってるエンジニアと仕事したいです!

www.beex-inc.com

マジで待ってる!