ForgeVision Engineer Blog

フォージビジョン エンジニア ブログ

AWS Summit Tokyo 2019 Day2体験記~Windows on AWS - AWS サポートエンジニアによる技術サポート事例紹介~

皆さん、こんばんは!クラウドインテグレーション事業部の尾谷です。

昨日に引き続き、AWS Summit 2019 の2日目であるDay2体験記を投稿したいと思います。

▼ AWS ウルトラクイズ準決勝まで進みました!

f:id:kitahara-fv:20190613230322j:plain

皆さま、re:Mix には参加されましたでしょうか?

参加された方はAWS ウルトラクイズ難しかったですよね!

私は、準決勝まで進みましたがap-south-1をシドニーと間違えるという失態を犯し決勝戦の登壇を逃しました。非常に悔しいです。

▼今日もAWS Summit Tokyo 2019 に行って参りました。

f:id:kitahara-fv:20190613231543j:plain 今日は特に 販売代理店契約を締結した Sumo Logicジャパン殿 のブースで午前、午後と二度にわたって Sumo Logicの利用方法についてユースケースを講演させていただいたこともあり、セッションの受講よりもSumo Logicのブースにお越し下さった方々とのコミュニケーションを重視するつもりで臨みました。

その甲斐もあってか非常に多くの方がブースでの発表を見学頂ける事に成功し、弊社も一丸となってコミュニケーションを図る事が出来ました! f:id:kitahara-fv:20190613232207j:plain

上記ブース運営の間となってしまいましたが、個人的にどうしても受講したかったセッションがありました。

そちらのセッション番号とタイトルがこちら、

  1. [E2-01] 10:00~10:40  Windows on AWS - AWSサポートエンジニアによる技術サポート事例紹介

▼ このセッションを受講したかった理由

弊社は開発やインフラ構築をメイン業務としながらも、運用管理というサービスを通じて数々の企業様が「安心して業務を行う」インフラ支援をさせていただいております。

またシステム構築させていただいたお客様は、引き続き運用管理サービスを利用いただく傾向がございます。

特にこの一年はWindows 2008 のサポート終了と消費税率アップの波を受け、Windows サーバをリプレースさせていただく機会が急激に増えてきた印象があります。

今回のセッションはWindows on AWS に特化した事例集と記載があったので、Summitの予約が始まったときに真っ先に選択したセッションでもありました。

そして、弊社もWindowsをオンプレからAWSに移行する知見が完璧に備わっているわけではないので、AWSサポート様に問い合わせさせていただくケースが多々あるわけで、本セッションは知見を深めるために是非とも受講したいテーマでありました。

では、実際にセミナーを受講して受け止めた所感と大まかな内容を簡単に記載させていただきます。

▼世界3か所のリージョンを利用した24時間365日対応

AWSサポートは、ネイティブの対応は当然日本国内で行って頂いていると考えておりました。

しかしながら、それを日本語でネイティブに対応してくださる部隊を1本化していると回らない事から、東京、ダブリン、シアトルの3か所に分けているとのこと。

これは、「フォロー・ザ・サン」という考えで、各地域の時差を利用して、担当者が日中の頭がクリアな状態でお客様の問い合わせに対応できるように、手薄な時間帯はなく対応できるようにしている。とのことでした。

この考えと体制には恐れ入りました。

▼AWSサポートが対応可能な範囲

AWSの責任共有モデルに当てはめると、オペレーティングシステムの部分は、ユーザが責任を負う範疇だと認識しております。

ましてやミドルウェアやアプリケーションに関してはその上モノなわけで確実にお客様の責任分界点にあたると思います。

しかしながら、AWSサポートでは「ベストエフォート」という名目で実に親身に相談に乗って下さいます。

その中でも、特に対応が難しいものとして、 ・チューニング ・カスタムコードのトラブルシューティング ・セキュリティに関する質問 を挙げていらっしゃいました。これらは直接ソフトウェアのプロバイダーへ問い合わせして欲しいとのことでした。

▼ ユースケースの紹介

主な問い合わせを分類すると以下になるとのことでした。

・不具合報告・調査依頼

・修正パッチの要求

この中でも、Windows に関してはEC2インスタンスにBYOL(Bring Your Own Lisence)で持ち込んだものに関しては、お客様とMicrosoft間にサポート契約が結ばれているためAWSサポートが直接 Microsoft に問い合わせするのは困難だということでした。

License-Includedな正規のAMIを利用していることが前提とのこと。

ただ、特定の条件を満たせばAWSからMicrosoftへ連携が可能であるとか、お客様とMicrosoftで一旦話を付けたのちにAWSサポートが介入するケースもあるとのことで、杓子定規で対応されない姿勢にも感銘を受けました。

事例1. .net Framework 3.5 をインストールすると失敗する

一つ目の事例では、お客様が ,net Framework3.5 のインストールに失敗し、お客様からMicrosoftに問い合わせされても解決せず「AWS側の問題ではないか確認して欲しい」と依頼された事例を話されていました。

このお問い合わせに対し、AWSサポートではリージョン内のCloudWatchメトリクスを統計的に分析して、同じバージョンのWindows Serverで .net Frametowk 3.5のインストールに失敗している頻度を洗い出し、そのエラーコードからMicrosoft側の一部のネットワークで障害が発生していたという判断に至ったとのことでした。またこの事例は非常にレアなケースともおっしゃっていました。

事例2. RDS for MySQLでレイテンシーが高くなる事象

あるお客様が開発されているシステムで、ある処理のレイテンシーが高いためRDSをスケールアップしたのに事象が解決しない、といった問い合わせを紹介されていました。

この事象の原因は、Nagleアルゴリズムによるバッファリングが有効なMySQL Clientを利用している場合で且つ、MTU(Maximum Transmission Unit)が高い場合にTCPのACKを待機してしまう仕様からデータを排出するまでに遅延が発生するといった内容でした。

どちらの事例も一般の方には若干複雑な内容ですし、もう少し細かく記載しないとご理解いただけないかも知れず恐縮です。

セッションでは順を追って図解して説明されていたので個人的には非常に分かりやすかったです。

最後に

以上、AWS Summit Tokyo 2019 Days2 に行ってきた感想でした。

明日は最終日であるDays3です!

最後まで全力で楽しんできて、アウトプットしたいと思います!