クラウド元SEママの情シスなりきりAWS奮闘記

【Windows】「AWSは、AWS上のWindows環境はサポートしてくれない」は誤解だった！

2019年8月30日掲載

こんにちは。シイノキです。
連日の猛暑でクーラーをかけないとやっていけない、でもずっとクーラーも冷えすぎてつらい、そんなお年頃。保育園のお迎えをして自宅につくと息も絶え絶えなので、そこから「公園で遊びたい」は勘弁していただきたい。子どもたちの体力って無尽蔵ですよね……。

さて、AWS Summit Tokyo 2019のレポートをお届けしている本コラム。基本的には私が参加したセッションの内容をまとめていますが、実際に行けるセッションには限りがあり、それ以外にもたくさんのセッションが開催されています。そして、これらのセッション資料はダウンロードできる！

というわけで、今回は気になるセッションの資料を読み解いて、内容を紹介したいと思います。テーマはずばり「Windowsのサポート」。
AWSでもWindows環境は作れる！使える！ということはこのコラムでも何度か取り上げました。

でも運用は全部自分でやらなきゃいけないんだよね？うまく動かなくても自分で頑張るしかないんだよね？それってほかのクラウドだったらもしかして……という気持ちがまったくないとは言えません。

そこで注目したのが「Windows on AWS～AWSサポートエンジニアによる技術サポート事例紹介」というセッション。AWS上に構築したWindows環境をAWSがどこまでサポートしてくれるのか、実際に技術サポートを担当しているエンジニアの方が、実事例をベースに紹介するセッションです。AWSのサポートは具体的になにをしてくれるのか、早速資料を見ていきましょう。

AWSによるWindowsサポートは“ベストエフォート”

このセッション資料を紐解くにあたって、まずは「AWSってWindowsもサポートしてくれるんだ……」という気づきからです。WindowsはどちらかというとAWS環境上に“ユーザが”構築して、“ユーザが”運用するもの。OSはユーザの責任範囲、という認識でした。

とはいえもちろん、Windowsのことなんでも聞いていい、ということではありません。サードパーティ製ソフトウェアのサポートについては、インストール・構成・基本的なトラブルシューティングについて「ベストエフォート」で、「最大限」お手伝い、というスタンスのようです。

一方で、細かいチューニングやカスタムコードのトラブルシューティング、セキュリティについてはAWSのサポートは対象外。直接自分でベンダに問い合わせるしかありません。そしてその中間にあるのが、「ソフトウェアプロバイダーへの不具合の報告・調査依頼」と「修正パッチの要求」。この2つは「特定の条件を満たせば」AWSがマイクロソフトと協力して問題解決にあたってくれる、ということ！ちなみに条件は下記の4つ。

AWSサポートのBusiness / Enterprise サポートプランに加入していること
License-Includedな正規のAMIを利用していること
対象のマイクロソフト製品がマイクロソフトの定めたサポート期限（EOS）内であること
AWSサポートが必要と判断した場合

肝心なのは上から2つ目でしょうか。つまり、BYOLではなく、AWS経由でライセンスを購入したものですよ、ということ。そりゃそうですが、ライセンスの状況次第でサポート対象外になりそうなので、もしも本格的にエンタープライズ系・基幹系を移行するとなったら、この点もきちんと確認しておきましょう。

具体的すぎる事例、1つ目は「.NET Frameworkがインストールできない」

続いていよいよ事例です。マイクロソフトと協力して解決したものと、AWSサポートのみで解決したものの2つが紹介されていますが、どちらもかなり具体的。まず1つ目のトラブルがこちら。

「Windows 2012 R2において、.NET Framework 3.5をインストールすると失敗する」

いかにもありそうです。なぜかこの環境だけインストールできない……はるか昔に悩んだ私が亡霊となって出てきそう。
さて、このトラブルですが、AWSがログを解析した結果、「Windows Updateのエンドポイントへアクセスできない」というエラーが出ていることが判明しました。一時的な回避策としてインストールメディアの利用を提示しつつ、事象が発生する条件を特定すべく、再現検証を実施。ところが、エラーコードはネットワーク障害に見えるのに、ネットワークを調査してもパケットロスや遅延は確認できません。

そこで、マイクロソフトにエスカレーション。マイクロソフトからの依頼にもとづき、AWS固有の問題がないか、AMIに依存しているかの切り分けを実施し、環境に依存せず障害が発生することまでAWSサポート側で確認しました。マイクロソフトによる調査の結果、マイクロソフト側の一部ネットワークにおいて接続障害が発生したことが特定され、無事に復旧に至ったそう。まさに、AWSとマイクロソフトの連携により解決した事例ですね。

2つ目の事例は「WindowsからAmazon RDSを使うと処理が遅い！」

2つ目はAWSサポートのみで解決したケースです。問い合わせ内容はこちら！

「Amazon EC2 WindowsインスタンスからAmazon RDS DBインスタンス（SQL Server）へアクセスしデータ処理を行うと想定より時間がかかった。処理性能向上を期待して、DBインスタンスクラスをスペックアップしたところ、変更前の小さなDBインスタンスクラスよりも時間がかかるようになった」

なるほど。WindowsからAmazon RDSのSQL Serverにアクセスすると処理が遅いと。さらにDBのスペックをあげたらもっと遅くなったというワケです。数秒程度だった遅延が、スペックを上げたら5分近くに延びたというからこれは困ります。

AWSサポートで、公式ドキュメントや過去の事例、マイクロソフトのKnowledge Baseなどをあたっても有力な手掛かりは得られません。そこで、正常な環境とユーザから提供のあったパケットキャプチャの比較し、TCPのACKが200ms遅延していることが判明。「遅延ACK」^※が原因では、と推察しますが、AWSサポート側で事象を再現できず行き詰まります。

※複数のACK応答をひとつにまとめることで、パフォーマンス改善を目指すTCPの実装技術

ここで、ユーザから事象再現用のスクリプトが提供され、さらに深く調査を進められることに。SQL Serverに接続するコンポーネントである「SQL Native Client」の別バージョンを試したところ事象が解消することが分かりました。
結論から言うと、通信効率を向上させるために送信パケット数を減らす「Nagleアルゴリズム」が原因のひとつ。受信側のTCPの遅延ACKが設定されている、小さなSQLクエリを大量に実行した、など複数の条件が重なって遅延が大きくなっていました。

これでもかなりざっくりとまとめたのですが、資料ではさらに詳細に原因究明までの流れが解説されており、かなり興味深く読みました。というかですね、WindowsとTCPの両方にかなり詳しくないと分からないですよ……。振り返りとして「AWSサポートの調査のみで原因を特定できたので、より早く解決できた」と書いてありましたが、本当にすごいの一言に尽きます。

AWSはマイクロソフトとも連携してくれるし、Windowsの技術もすごい

正直なところ、AWSがここまでWindowsのことをサポートしてくれるとは思っていませんでした。OSより上は自分でやってね、って言ってたじゃん？という気持ちでいっぱいです。2つ目のユースケースはAmazon RDSなのでサポート対象になるのも分かりますが、1つ目のケースでもここまでAWSのサポートが動いてくれるのは想定外でした。

Windows Server 2008のサポート終了もありますし、今後ますますWindowsのAWS移行も増えていくはず。こういったサポートがある分かったのは、大きな収穫と言えるのではないでしょうか。ちなみに、ソニービズネットワークスは「Amazon EC2 for Windows Server」のAWS SDP（サービスデリバリープログラム）パートナーに認定されていまして、WindowsのAWS移行サポートも提供しています。
AWS上のWindows環境構築や、ファイル移行などのサポートメニューも各種取り揃えていますので、「なにかあったらAWSがサポートしてくれるかもしれないけど、そもそもどこから移行をスタートすればいいか分からないよね……」という方はぜひ一度ご相談ください！
以上、シイノキでした！