パートナー企業のテクニカルサポートエンジニアとして気になる、より良い AWS サポートの利活用について

by kazzpapa3

Slide 1

Slide 1 text

パートナー企業のテクニカルサポートエンジニアとして気になるより良い AWS サポートの利活⽤について [JAWS FESTA 2024 in 広島] 株式会社サーバーワークス市野和明（JAWS-UG 神⼾） 2024-10-12

Slide 2

Slide 2 text

⽬次 1. ⾃⼰紹介 2. はじめに 3. 本題 4. 余談

Slide 3

Slide 3 text

⾃⼰紹介

Slide 4

Slide 4 text

4 はじめまして名前︓市野和明（いちのかずあき）所属︓株式会社サーバーワークス MS 部テクニカルサポート１課好きな AWS サービス︓ AWS CLI （テクサポとして）嫌いな AWS サービス︓ Amazon FSx for Windows AWS Deadline Cloud 趣味︓ミクが好き、酒を飲む @kazzpapa3

Slide 5

Slide 5 text

5 はじめまして名前︓市野和明（いちのかずあき）所属︓株式会社サーバーワークス MS 部テクニカルサポート１課好きな AWS サービス︓ AWS CLI （テクサポとして）嫌いな AWS サービス︓ Amazon FSx for Windows AWS Deadline Cloud 趣味︓ミクが好き、酒を飲む @kazzpapa3 気になった⽅はお気軽に懇親会などでお声かけください

Slide 6

Slide 6 text

6 ©Misora Ryo 酒まつりも気になるものの…

Slide 7

Slide 7 text

7 ©Misora Ryo 14⽇に⼤阪で開催されるとあるライブの千秋楽で SS 席 3列⽬を引き当てたので少々気もそぞろです。

Slide 8

Slide 8 text

はじめに

Slide 9

Slide 9 text

9 2024年、テクサポの中の⼈としていくつか登壇してみました 2024年4⽉に福井で⾏われた JAWS-UG 北陸新幹線で初めて賑やかし以外の登壇機会をいただき、普段の業務を通じて感じている「もっとこうすればいいのに」と思っている観点から話をしました。

Slide 10

Slide 10 text

10 2024年、テクサポの中の⼈としていくつか登壇してみました 2024年4⽉に福井で⾏われた JAWS-UG 北陸新幹線で初めて賑やかし以外の登壇機会をいただき、普段の業務を通じて感じている「もっとこうすればいいのに」と思っている観点から話をしました。この登壇時の反応から、技術やセキュリティなど構築の側⾯の話が多い中、より良いサポートを受けるための Tips などの裏話を聞いたことのない⽅が⼀定数いらっしゃることに気づきました。

Slide 11

Slide 11 text

11 2024年、テクサポの中の⼈としていくつか登壇してみました 2024年4⽉に福井で⾏われた JAWS-UG 北陸新幹線で初めて賑やかし以外の登壇機会をいただき、普段の業務を通じて感じている「もっとこうすればいいのに」と思っている観点から話をしました。この登壇時の反応から、技術やセキュリティなど構築の側⾯の話が多い中、より良いサポートを受けるための Tips などの裏話を聞いたことのない⽅が⼀定数いらっしゃることに気づきました。 > 今朝から AWS につながりません。 > 障害など起きていないでしょうか。

Slide 12

Slide 12 text

12 2024年、テクサポの中の⼈としていくつか登壇してみました 2024年4⽉に福井で⾏われた JAWS-UG 北陸新幹線で初めて賑やかし以外の登壇機会をいただき、普段の業務を通じて感じている「もっとこうすればいいのに」と思っている観点から話をしました。この登壇時の反応から、技術やセキュリティなど構築の側⾯の話が多い中、より良いサポートを受けるための Tips などの裏話を聞いたことのない⽅が⼀定数いらっしゃることに気づきました。 > 今朝から AWS につながりません。 > 障害など起きていないでしょうか。ありえないだろう︖と思われるかもしれませんが、本質的に同様なお問い合わせが、実は多いことを引き合いに、問い合わせ⽂⾯を組み⽴てる上で、相⼿が何を⾒られるかや意識齟齬を防ぐための⽂書構成の観点について話をしました。これは私が夢でみかけた⽂章特定のお客様からいただいた⽂⾯そのままではない

Slide 13

Slide 13 text

JAWS-UG 北陸新幹線での登壇資料から

Slide 14

Slide 14 text

14 それぞれがどの情報にアクセスできるか、知りうるか対象 AWS 利⽤者（お客様）（私の所属企業のような） APN パートナー企業 AWS テクニカルサポート設計背景や実装 ○ 知っている × 知り得ない × 知り得ない障害や事象の影響度 ○ 知っている × 知り得ない × 知り得ない AWS マネジメントコンソール ○ 閲覧可能 ○ 閲覧可能 ※⼀部例外あり1 × 閲覧不可能（閲覧しない） AWS で構築されたサーバ内部のデータやログ ○ 閲覧可能 × 閲覧不可（ログインしない） × 閲覧不可（ログインしない） AWS 物理基盤 × 閲覧不可 × 閲覧不可 ○ 閲覧可能 1. サービスのポータルや操作画⾯の閲覧のために、IAM Identity Center によるユーザー管理となっているサービスの場合、その発⽣事象の閲覧ができない AWS サービスもある

Slide 15

Slide 15 text

15 それぞれがどの情報にアクセスできるか、知りうるか対象 AWS 利⽤者（お客様）（私の所属企業のような） APN パートナー企業 AWS テクニカルサポート設計背景や実装 ○ 知っている × 知り得ない × 知り得ない障害や事象の影響度 ○ 知っている × 知り得ない × 知り得ない AWS マネジメントコンソール ○ 閲覧可能 ○ 閲覧可能 ※⼀部例外あり1 × 閲覧不可能（閲覧しない） AWS で構築されたサーバ内部のデータやログ ○ 閲覧可能 × 閲覧不可（ログインしない） × 閲覧不可（ログインしない） AWS 物理基盤 × 閲覧不可 × 閲覧不可 ○ 閲覧可能 1. サービスのポータルや操作画⾯の閲覧のために、IAM Identity Center によるユーザー管理となっているサービスの場合、その発⽣事象の閲覧ができない AWS サービスもある

Slide 16

Slide 16 text

16 解決スピードを上げるには︖ AWS Support として顧客に望むことはすでに公式⽂書に書いてある少なくとも AWS に対して問い合わせをするロールの⼈は、まずは⽬を通しておくべき技術的なお問い合わせに関するガイドライン https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines 問い合わせ⽂章は 5W2H を意識する担当しているプロジェクトの全容について、簡単なモノで良いので、説明できる資料があればベター複数のアカウントを Transit Gateway などで連携させた、⼤きいネットワーク空間があるマイクロサービスアーキテクチャで登場⼈物（サービス）が多いなど結局、急がば回れ

Slide 17

Slide 17 text

17 JAWS-UG 北陸新幹線での登壇のまとめ Ø AWS が公開しているドキュメント [1] を紹介し、 AWS サポートからの回答をより適切に得たり、解決スピードを上げるためにより良い問い合わせ⽂⾯を組み⽴てる際の⽂書構成や記載内容について問い合わせ⽂⾯にもう⼀⼯夫できそうな観点からお話ししました [2] Ø [1] AWS プレミアムサポート / 技術的なお問い合わせに関するガイドライン https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/ Ø [2] AWS パートナー企業でテクニカルサポートに従事して2年経ったので思うところをまとめてみた https://speakerdeck.com/kazzpapa3/aws-patonaqi-ye-detekunikarusapotonicong-shi- site2nian-jing-tutanodesi-utokorowomatometemita Ø この資料も後⽇アップしますので、上記も合わせてご⼀読いただけると幸いです。

Slide 18

Slide 18 text

本題

Slide 19

Slide 19 text

19 前提として弊社のようなリセラーが提供する AWS アカウントでは、お客様のサポートをリセラーが担うことになっています。

Slide 20

Slide 20 text

20 前提として弊社のようなリセラーが提供する AWS アカウントでは、お客様のサポートをリセラーが担うことになっています。そのため、リセラー内の知⾒や調査による回答が基本となりますが、 AWS 基盤側の問題が疑われるような場合などには、AWS サポートへエスカレーションし、お客様 ←→ AWS テクニカルサポートの仲介役として⽴ち回る場⾯があります。

Slide 21

Slide 21 text

21 前提として弊社のようなリセラーが提供する AWS アカウントでは、お客様のサポートをリセラーが担うことになっています。そのため、リセラー内の知⾒や調査による回答が基本となりますが、 AWS 基盤側の問題が疑われるような場合などには、AWS サポートへエスカレーションし、お客様 ←→ AWS テクニカルサポートの仲介役として⽴ち回る場⾯があります。リセラーを通すことで解決が遅くなった、とならないように、 AWS の初動よりも早く対応しようと個⼈的には思いながら仕事をしていますが、間に⼊っているから余計感じるのかもしれませんが、スタンスや考え⽅の違いからくると思われる、微妙な「話が噛み合わない感」を感じる時があります。

Slide 22

Slide 22 text

サポート業務をしていて感じる、ちょっとした違和感

Slide 23

Slide 23 text

23 ⼀例として明確な原因の追求や AWS に対して改善策をご要望される場⾯意図せず発⽣した再起動の理由を教えてほしいインスタンスの retirement について、今後発⽣しないように改善してほしい今回発⽣した事象に対して AWS として今後どのように対策するつもりなのか︖ 開⽰されていない情報をご要望される場⾯メンテナンスの頻度や傾向を教えてほしい S3 の静的ウェブホスティングでは Apache を使っているか︖ AWS から、何らかの提案があった場⾯スナップショットから新しいインスタンスとして起動してみてほしい調査のために停⽌中になっているリソースを起動してもらえないか

Slide 24

Slide 24 text

24 ⼀例として明確な原因の追求や AWS に対して改善策をご要望される場⾯意図せず発⽣した再起動の理由を教えてほしいインスタンスの retirement について、今後発⽣しないように改善してほしい今回発⽣した事象に対して、AWS としてどう考えているのか︖（何なら書⾯で出してほしい）開⽰されていない情報をご要望される場⾯メンテナンスの頻度や傾向を教えてほしい S3 の静的ウェブホスティングでは Apache を使っているか︖ AWS から、何らかの提案があった場⾯スナップショットから新しいインスタンスとして起動してみてほしい調査のために停⽌中になっているリソースを起動してもらえないか

Slide 25

Slide 25 text

25 ⼀例として明確な原因の追求や AWS に対して改善策をご要望される場⾯意図せず発⽣した再起動の理由を教えてほしいインスタンスの retirement について、今後発⽣しないように改善してほしい今回発⽣した事象に対して、AWS としてどう考えているのか︖（何なら書⾯で出してほしい）開⽰されていない情報をご要望される場⾯メンテナンスの頻度や傾向を教えてほしい S3 の静的ウェブホスティングでは Apache を使っているか︖ AWS から、何らかの提案があった場⾯スナップショットから新しいインスタンスとして起動してみてほしい調査のために停⽌中になっているリソースを起動してもらえないか

Slide 26

Slide 26 text

26 ⼀例として明確な原因の追求や AWS に対して改善策をご要望される場⾯意図せず発⽣した再起動の理由を教えてほしいインスタンスの retirement について、今後発⽣しないように改善してほしい今回発⽣した事象に対して、AWS としてどう考えているのか︖（何なら書⾯で出してほしい）開⽰されていない情報をご要望される場⾯メンテナンスの頻度や傾向を教えてほしい S3 の静的ウェブホスティングでは Apache を使っているか︖ AWS から、何らかの提案があった場⾯スナップショットから新しいインスタンスとして起動してみてほしい調査のために停⽌中になっているリソースを起動してもらえないか

Slide 27

Slide 27 text

27 今回はこの観点に着⽬してみます明確な原因の追求や AWS に対して改善策をご要望される場⾯意図せず発⽣した再起動の理由を教えてほしいインスタンスの retirement について、今後発⽣しないように改善してほしい今回発⽣した事象に対して、AWS としてどう考えているのか︖（何なら書⾯で出してほしい）開⽰されていない情報をご要望される場⾯メンテナンスの頻度や傾向を教えてほしい S3 の静的ウェブホスティングでは Apache を使っているか︖ AWS から、何らかの提案があった場⾯スナップショットから新しいインスタンスとして起動してみてほしい調査のために停⽌中になっているリソースを起動してもらえないか

Slide 28

Slide 28 text

28 明確な原因の追求や AWS に対して改善策をご要望される場⾯明確な原因の追求や AWS に対して改善策をご要望される場⾯意図せず発⽣した再起動の理由を教えてほしいインスタンスの retirement について、今後発⽣しないように改善してほしい今回発⽣した事象に対して、AWS としてどう考えているのか︖（何なら書⾯で出してほしい）

Slide 29

Slide 29 text

29 明確な原因の追求や AWS に対して改善策をご要望される場⾯明確な原因の追求や AWS に対して改善策をご要望される場⾯意図せず発⽣した再起動の理由を教えてほしいインスタンスの retirement について、今後発⽣しないように改善してほしい今回発⽣した事象に対して、AWS としてどう考えているのか︖（何なら書⾯で出してほしい）おそらく、以下のような背景があるんだろうな︖とは思っています「なぜなぜ分析」などの考え⽅が定着している顧客や発注元への説明責任が発⽣する

Slide 30

Slide 30 text

30 明確な原因の追求や AWS に対して改善策をご要望される場⾯明確な原因の追求や AWS に対して改善策をご要望される場⾯意図せず発⽣した再起動の理由を教えてほしいインスタンスの retirement について、今後発⽣しないように改善してほしい今回発⽣した事象に対して、AWS としてどう考えているのか︖（何なら書⾯で出してほしい）おそらく、以下のような背景があるんだろうな︖とは思っています「なぜなぜ分析」などの考え⽅が定着している顧客や発注元への説明責任が発⽣する「責任共有モデル | AWS」より抜粋 https://aws.amazon.com/jp/compliance/shared-responsibility-model/ AWS がセキュリティに対する責任を負っている

Slide 31

Slide 31 text

31 明確な原因の追求や AWS に対して改善策をご要望される場⾯明確な原因の追求や AWS に対して改善策をご要望される場⾯意図せず発⽣した再起動の理由を教えてほしいインスタンスの retirement について、今後発⽣しないように改善してほしい今回発⽣した事象に対して、AWS としてどう考えているのか︖（何なら書⾯で出してほしい）おそらく、以下のような背景があるんだろうな︖とは思っています「なぜなぜ分析」などの考え⽅が定着している顧客や発注元への説明責任が発⽣する「責任共有モデル | AWS」より抜粋 https://aws.amazon.com/jp/compliance/shared-responsibility-model/ AWS がセキュリティに対する責任を負っている説明責任も求めているのではないかと推察（特に⽇本⼈が責任感が強いことも背景にある︖）

Slide 32

Slide 32 text

32 AWS がすでに公開しているスタンス「技術的なお問い合わせに関するガイドライン」で以下のように書かれています障害の原因についてのお問い合わせ〜中略〜 AWS では、障害内容の詳細なご説明は⾏っておりません。詳細な原因等をお伝えしても、お客様の回避策には影響がなく、お客様の課題解決において本質的ではないと考えているためです。むしろ監視サービスの適切な活⽤や、⼀次復旧を優先する⽅法をご案内することで、お客様の課題を迅速に解決することを⽬指します。「技術的なお問い合わせに関するガイドライン | AWS サポート / 障害の原因についてのお問い合わせ」より抜粋 https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/

Slide 33

Slide 33 text

33 AWS がすでに公開しているスタンス「技術的なお問い合わせに関するガイドライン」で以下のように書かれています障害の原因についてのお問い合わせ〜中略〜 AWS では、障害内容の詳細なご説明は⾏っておりません。詳細な原因等をお伝えしても、お客様の回避策には影響がなく、お客様の課題解決において本質的ではないと考えているためです。むしろ監視サービスの適切な活⽤や、⼀次復旧を優先する⽅法をご案内することで、お客様の課題を迅速に解決することを⽬指します。 AWS では障害の内容の詳細な説明をしていない「技術的なお問い合わせに関するガイドライン | AWS サポート / 障害の原因についてのお問い合わせ」より抜粋 https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/

Slide 34

Slide 34 text

34 AWS がすでに公開しているスタンス「技術的なお問い合わせに関するガイドライン」で以下のように書かれています障害の原因についてのお問い合わせ〜中略〜 AWS では、障害内容の詳細なご説明は⾏っておりません。詳細な原因等をお伝えしても、お客様の回避策には影響がなく、お客様の課題解決において本質的ではないと考えているためです。むしろ監視サービスの適切な活⽤や、⼀次復旧を優先する⽅法をご案内することで、お客様の課題を迅速に解決することを⽬指します。 AWS では障害の内容の詳細な説明をしていないなぜなら、利⽤者がコントロールできない範囲となり、利⽤者へ伝えても利⽤者として取りうる回避策に影響を及ぼすものではないと考えているから「技術的なお問い合わせに関するガイドライン | AWS サポート / 障害の原因についてのお問い合わせ」より抜粋 https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/

Slide 35

Slide 35 text

35 AWS がすでに公開しているスタンス「技術的なお問い合わせに関するガイドライン」で以下のように書かれています障害の原因についてのお問い合わせ〜中略〜 AWS では、障害内容の詳細なご説明は⾏っておりません。詳細な原因等をお伝えしても、お客様の回避策には影響がなく、お客様の課題解決において本質的ではないと考えているためです。むしろ監視サービスの適切な活⽤や、⼀次復旧を優先する⽅法をご案内することで、お客様の課題を迅速に解決することを⽬指します。 AWS では障害の内容の詳細な説明をしていないなぜなら、利⽤者がコントロールできない範囲となり、利⽤者へ伝えても利⽤者として取りうる回避策に影響を及ぼすものではないと考えているからつまり利⽤者が抱える課題解決に対して本質的ではないから「技術的なお問い合わせに関するガイドライン | AWS サポート / 障害の原因についてのお問い合わせ」より抜粋 https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/

Slide 36

Slide 36 text

36 意図せず再起動した対象が EC2 だったと仮定すると︖ CloudWatch メトリクスを確認してみるステータスチェックエラーが出ているか StatusCheckFailed_System︖ StatusCheckFailed_Instance︖ エラーの種別︖ AWS 基盤障害 OS レイヤー以上の問題 Yes No Amazon EC2 インスタンスのステータスチェック https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html

Slide 37

Slide 37 text

37 意図せず再起動した対象が EC2 だったと仮定すると︖ CloudWatch メトリクスを確認してみるステータスチェックエラーが出ているか StatusCheckFailed_System︖ StatusCheckFailed_Instance︖ エラーの種別︖ AWS 基盤障害 OS レイヤー以上の問題 Yes No Amazon EC2 インスタンスのステータスチェック https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html ステータスチェックについては、本⽇時点で StatusCheckFailed_AttachedEBS が追加されていますが、今⽇のところは上記 2 観点に絞って、以降続けます。

Slide 38

Slide 38 text

38 エラー記録があり StatusCheckFailed_System であった場合 CloudWatch メトリクスを確認してみるステータスチェックエラーが出ているか StatusCheckFailed_System︖ StatusCheckFailed_Instance︖ エラーの種別︖ AWS 基盤障害 OS レイヤー以上の問題 Yes No Amazon EC2 インスタンスのステータスチェック https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html StatusCheckFailed_System が記録される場合、修復には AWS の関与が必要なインスタンスの基盤の問題と明記されている

Slide 39

Slide 39 text

39 AWS 基盤側の問題と結論づけられる CloudWatch メトリクスを確認してみるステータスチェックエラーが出ているか StatusCheckFailed_System︖ StatusCheckFailed_Instance︖ エラーの種別︖ AWS 基盤障害 OS レイヤー以上の問題 Yes No Amazon EC2 インスタンスのステータスチェック https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html StatusCheckFailed_System が記録される場合、修復には AWS の関与が必要なインスタンスの基盤の問題と明記されている AWS 基盤側の問題ではあるものの、前述までお話ししたようにお客様の課題解決の本質に影響しないため詳細な原因は開⽰しない

Slide 40

Slide 40 text

40 前述までの通り詳細な原因の説明はしない CloudWatch メトリクスを確認してみるステータスチェックエラーが出ているか StatusCheckFailed_System︖ StatusCheckFailed_Instance︖ エラーの種別︖ AWS 基盤障害 OS レイヤー以上の問題 Yes No Amazon EC2 インスタンスのステータスチェック https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html StatusCheckFailed_System が記録される場合、修復には AWS の関与が必要なインスタンスの基盤の問題と明記されている AWS 基盤側の問題ではあるものの、前述までお話ししたようにお客様の課題解決の本質に影響しないため詳細な原因は開⽰しないただ、考えられる可能性の例は挙げてくれている・ネットワーク接続の喪失・システム電源の喪失・物理ホストのソフトウェアの問題・ネットワーク到達可能性に影響する、物理ホスト上のハードウェアの問題

Slide 41

Slide 41 text

41 ドキュメント以上の回答が得られないため問い合わせ不要 CloudWatch メトリクスを確認してみるステータスチェックエラーが出ているか StatusCheckFailed_System︖ StatusCheckFailed_Instance︖ エラーの種別︖ AWS 基盤障害 OS レイヤー以上の問題 Yes No Amazon EC2 インスタンスのステータスチェック https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html StatusCheckFailed_System が記録される場合、修復には AWS の関与が必要なインスタンスの基盤の問題と明記されている AWS 基盤側の問題ではあるものの、前述までお話ししたようにお客様の課題解決の本質に影響しないため詳細な原因は開⽰しない結果、問い合わせは不要（問い合わせても本ページに書かれていること以上の提⽰がない）ただ、考えられる可能性の例は挙げてくれている・ネットワーク接続の喪失・システム電源の喪失・物理ホストのソフトウェアの問題・ネットワーク到達可能性に影響する、物理ホスト上のハードウェアの問題

Slide 42

Slide 42 text

42 StatusCheckFailed_System が記録されていたということは︖ Amazon EC2 インスタンスのステータスチェック https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html 利⽤者の⽴場としてはユーザー側で Uncontrollable なエラーが出ていたその結果、再起動が実施されたユーザー側が提供しているサービスとして設計通り、ダウンタイムの発⽣をさせなかったサービスのダウンタイムを発⽣させてしまったこの場合、アーキテクチャの⾒直しをする AWS で基盤障害が起きたのね︖ という切り分けができただけで良しとするのが⭕

Slide 43

Slide 43 text

43 より気にすべき観点は︖ Amazon EC2 インスタンスのステータスチェック https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html 利⽤者の⽴場としてはユーザー側で Uncontrollable なエラーが出ていたその結果、再起動が実施されたユーザー側が提供しているサービスとして設計通り、ダウンタイムの発⽣をさせなかったサービスのダウンタイムを発⽣させてしまったこの場合、アーキテクチャの⾒直しをする気にすべき本質は、提供しているサービスに影響が出たか出ていないか、ではないか︖ 影響が出ていたらアーキテクチャの再設計が必要

Slide 44

Slide 44 text

44 エラー記録があり StatusCheckFailed_Instance であった場合 CloudWatch メトリクスを確認してみるステータスチェックエラーが出ているか StatusCheckFailed_System︖ StatusCheckFailed_Instance︖ エラーの種別︖ AWS 基盤障害 OS レイヤー以上の問題 Yes No Amazon EC2 インスタンスのステータスチェック https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html StatusCheckFailed_Instance が記録される場合、ユーザーが関与して修復する必要のある問題と明記されている

Slide 45

Slide 45 text

45 AWS が関与しない OS レイヤー以上の問題と⾔える CloudWatch メトリクスを確認してみるステータスチェックエラーが出ているか StatusCheckFailed_System︖ StatusCheckFailed_Instance︖ エラーの種別︖ AWS 基盤障害 OS レイヤー以上の問題 Yes No Amazon EC2 インスタンスのステータスチェック https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html StatusCheckFailed_Instance が記録される場合、ユーザーが関与して修復する必要のある問題と明記されているつまり、AWS が直接関与しない範囲（OS レイヤー以上）での問題を探る必要がある

Slide 46

Slide 46 text

46 AWS が関与しないため、結局問い合わせは不要 CloudWatch メトリクスを確認してみるステータスチェックエラーが出ているか StatusCheckFailed_System︖ StatusCheckFailed_Instance︖ エラーの種別︖ AWS 基盤障害 OS レイヤー以上の問題 Yes No Amazon EC2 インスタンスのステータスチェック https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html StatusCheckFailed_Instance が記録される場合、ユーザーが関与して修復する必要のある問題と明記されているつまり、AWS が直接関与しない範囲（OS レイヤー以上）での問題を探る必要がある結果、初動対応として AWS への問い合わせは不要

Slide 47

Slide 47 text

47 AWS が関与しないため、結局問い合わせは不要 CloudWatch メトリクスを確認してみるステータスチェックエラーが出ているか StatusCheckFailed_System︖ StatusCheckFailed_Instance︖ エラーの種別︖ AWS 基盤障害 OS レイヤー以上の問題 Yes No Amazon EC2 インスタンスのステータスチェック https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html StatusCheckFailed_Instance が記録される場合、ユーザーが関与して修復する必要のある問題と明記されているつまり、AWS が直接関与しない範囲（OS レイヤー以上）での問題を探る必要がある結果、初動対応として AWS への問い合わせは不要もちろん、内部調査の結果 AWS の提供モジュールやエージェントの問題が疑われる︕ このような場合は問い合わせすべきですが、「初動ですぐに AWS へ問い合わせ」とはならないはず、という観点です

Slide 48

Slide 48 text

48 意図しない再起動で問い合わせが不要なケース明確な原因の追求や AWS に対して改善策をご要望される場⾯意図せず発⽣した再起動の理由を教えてほしいインスタンスの retirement について、今後発⽣しないように改善してほしい今回発⽣した事象に対して、AWS としてどう考えているのか︖（何なら書⾯で出してほしい）意図しない再起動が発⽣したとしても意図しない再起動稼働状態

Slide 49

Slide 49 text

49 意図しない再起動で問い合わせが不要なケース明確な原因の追求や AWS に対して改善策をご要望される場⾯意図せず発⽣した再起動の理由を教えてほしいインスタンスの retirement について、今後発⽣しないように改善してほしい今回発⽣した事象に対して、AWS としてどう考えているのか︖（何なら書⾯で出してほしい）意図しない再起動が発⽣したとしてもその後、EC2 インスタンスが問題なく再開されて稼働し続けている場合は正常な稼働状態に戻っている意図しない再起動稼働状態提供サービスへの影響なし

Slide 50

Slide 50 text

50 意図しない再起動で問い合わせが不要なケース明確な原因の追求や AWS に対して改善策をご要望される場⾯意図せず発⽣した再起動の理由を教えてほしいインスタンスの retirement について、今後発⽣しないように改善してほしい今回発⽣した事象に対して、AWS としてどう考えているのか︖（何なら書⾯で出してほしい）意図しない再起動が発⽣したとしてもその後、EC2 インスタンスが問題なく再開されて稼働し続けている場合は再起動の発⽣要因を AWS に問い合わせる必要がない、と分類可能正常な稼働状態に戻っている意図しない再起動稼働状態提供サービスへの影響なし

Slide 51

Slide 51 text

51 意図しない再起動で問い合わせが必要と考えられるケース明確な原因の追求や AWS に対して改善策をご要望される場⾯意図せず発⽣した再起動の理由を教えてほしいインスタンスの retirement について、今後発⽣しないように改善してほしい今回発⽣した事象に対して、AWS としてどう考えているのか︖（何なら書⾯で出してほしい）意図しない再起動が発⽣した後に意図しない再起動稼働状態

Slide 52

Slide 52 text

52 意図しない再起動で問い合わせが必要と考えられるケース明確な原因の追求や AWS に対して改善策をご要望される場⾯意図せず発⽣した再起動の理由を教えてほしいインスタンスの retirement について、今後発⽣しないように改善してほしい今回発⽣した事象に対して、AWS としてどう考えているのか︖（何なら書⾯で出してほしい）意図しない再起動が発⽣した後に正常な EC2 インスタンスの稼働につながっていない場合正常な稼働状態でない意図しない再起動稼働状態提供サービスへの影響あり

Slide 53

Slide 53 text

53 意図しない再起動で問い合わせが必要と考えられるケース明確な原因の追求や AWS に対して改善策をご要望される場⾯意図せず発⽣した再起動の理由を教えてほしいインスタンスの retirement について、今後発⽣しないように改善してほしい今回発⽣した事象に対して、AWS としてどう考えているのか︖（何なら書⾯で出してほしい）意図しない再起動が発⽣した後に正常な EC2 インスタンスの稼働につながっていない場合この時初めて AWS サポートへ問い合わせし、原因の特定と復旧を模索する正常な稼働状態でない意図しない再起動稼働状態提供サービスへの影響あり

Slide 54

Slide 54 text

54 意図しない再起動で問い合わせが必要と考えられるケース明確な原因の追求や AWS に対して改善策をご要望される場⾯意図せず発⽣した再起動の理由を教えてほしいインスタンスの retirement について、今後発⽣しないように改善してほしい今回発⽣した事象に対して、AWS としてどう考えているのか︖（何なら書⾯で出してほしい）意図しない再起動が発⽣した後に正常な EC2 インスタンスの稼働につながっていない場合この時初めて AWS サポートへ問い合わせし、原因の特定と復旧を模索するただし、InsufficientInstanceCapacity が記録されており⼀時的な EC2 のキャパシティの不⾜の場合は、リトライの実施の必要性がすでに案内されており、問い合わせてもその⽂書提⽰で終わる可能性がある。そのような場合は、問い合わせは不要と位置付けられる。正常な稼働状態でない意図しない再起動稼働状態提供サービスへの影響あり

Slide 55

Slide 55 text

55 明確な原因の追求や AWS に対して改善策をご要望される場⾯明確な原因の追求や AWS に対して改善策をご要望される場⾯意図せず発⽣した再起動の理由を教えてほしいインスタンスの retirement について、今後発⽣しないように改善してほしい今回発⽣した事象に対して、AWS としてどう考えているのか︖（何なら書⾯で出してほしい）

Slide 56

Slide 56 text

56 AWS がすでに公開しているスタンス「技術的なお問い合わせに関するガイドライン」で以下のように書かれています障害の原因についてのお問い合わせ〜中略〜障害発⽣は予測不可能であり、また不可避です。AWS ではインフラの障害に対し要因分析および発⽣率の低減に努めておりますが、障害の発⽣を完全に防ぐことは困難です。「技術的なお問い合わせに関するガイドライン | AWS サポート / 障害の原因についてのお問い合わせ」より抜粋 https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/

Slide 57

Slide 57 text

57 AWS がすでに公開しているスタンス「技術的なお問い合わせに関するガイドライン」で以下のように書かれています障害の原因についてのお問い合わせ〜中略〜障害発⽣は予測不可能であり、また不可避です。AWS ではインフラの障害に対し要因分析および発⽣率の低減に努めておりますが、障害の発⽣を完全に防ぐことは困難です。このため AWS では「Design For Failure」(故障を前提とした設計)を推奨しています。また、監視サービスやリソースの提供、ベストプラクティスのご案内等を⾏っています。「技術的なお問い合わせに関するガイドライン | AWS サポート / 障害の原因についてのお問い合わせ」より抜粋 https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/

Slide 58

Slide 58 text

Design For Failure (故障を前提とした設計)

Slide 59

Slide 59 text

59 Design for failure とは︖ ホワイトペーパー「Running Containerized Microservices on AWS」のいちセクションとして設けられているページで解説されています。「Design for failure - Running Containerized Microservices on AWS」より抜粋 https://docs.aws.amazon.com/ja_jp/whitepapers/latest/running-containerized-microservices/design-for-failure.html

Slide 60

Slide 60 text

60 Design for failure とは︖ ホワイトペーパー「Running Containerized Microservices on AWS」のいちセクションとして設けられているページで解説されています。⼤元のホワイトペーパーのタイトルを直訳すると「AWS 上でコンテナ化されたマイクロサービスを実⾏する」となりますが、コンテナの利⽤有無に関わらず、 Well-Architected Framework の中でも引き合いに出されることもあり、 AWS が基本と考えていると⾒られる設計原則の⼀つです。「Design for failure - Running Containerized Microservices on AWS」より抜粋 https://docs.aws.amazon.com/ja_jp/whitepapers/latest/running-containerized-microservices/design-for-failure.html

Slide 61

Slide 61 text

61 Design for failure とは︖ ホワイトペーパー「Running Containerized Microservices on AWS」のいちセクションとして設けられているページで解説されています。⼤元のホワイトペーパーのタイトルを直訳すると「AWS 上でコンテナ化されたマイクロサービスを実⾏する」となりますが、コンテナの利⽤有無に関わらず、 Well-Architected Framework の中でも引き合いに出されることもあり、 AWS が基本と考えていると⾒られる設計原則の⼀つです。 > “Everything fails all the time.” – Werner Vogels ページ冒頭で上記のように述べられており、「完全状態で動作し続ける」前提ではなく、「すべては常に失敗する」ことを想定した設計であることが推奨されている、という理解が必要です。「Design for failure - Running Containerized Microservices on AWS」より抜粋 https://docs.aws.amazon.com/ja_jp/whitepapers/latest/running-containerized-microservices/design-for-failure.html

Slide 62

Slide 62 text

62 明確な原因の追求や AWS に対して改善策をご要望される場⾯明確な原因の追求や AWS に対して改善策をご要望される場⾯意図せず発⽣した再起動の理由を教えてほしいインスタンスの retirement について、今後発⽣しないように改善してほしい今回発⽣した事象に対して、AWS としてどう考えているのか︖（何なら書⾯で出してほしい）上記のような考えに⾄るということは︖

Slide 63

Slide 63 text

63 明確な原因の追求や AWS に対して改善策をご要望される場⾯明確な原因の追求や AWS に対して改善策をご要望される場⾯意図せず発⽣した再起動の理由を教えてほしいインスタンスの retirement について、今後発⽣しないように改善してほしい今回発⽣した事象に対して、AWS としてどう考えているのか︖（何なら書⾯で出してほしい）上記のような考えに⾄るということは︖ 「完全状態で稼働し続ける」ことを前提としている or 期待していると⾔える

Slide 64

Slide 64 text

64 明確な原因の追求や AWS に対して改善策をご要望される場⾯明確な原因の追求や AWS に対して改善策をご要望される場⾯意図せず発⽣した再起動の理由を教えてほしいインスタンスの retirement について、今後発⽣しないように改善してほしい今回発⽣した事象に対して、AWS としてどう考えているのか︖（何なら書⾯で出してほしい）

Slide 65

Slide 65 text

65 明確な原因の追求や AWS に対して改善策をご要望される場⾯明確な原因の追求や AWS に対して改善策をご要望される場⾯意図せず発⽣した再起動の理由を教えてほしいインスタンスの retirement について、今後発⽣しないように改善してほしい今回発⽣した事象に対して、AWS としてどう考えているのか︖（何なら書⾯で出してほしい）上記観点については、⼀つ⽬、および⼆つ⽬と若⼲重なる部分もありますが AWS に対する説明責任を求めているものかと思われます。

Slide 66

Slide 66 text

66 明確な原因の追求や AWS に対して改善策をご要望される場⾯明確な原因の追求や AWS に対して改善策をご要望される場⾯意図せず発⽣した再起動の理由を教えてほしいインスタンスの retirement について、今後発⽣しないように改善してほしい今回発⽣した事象に対して、AWS としてどう考えているのか︖（何なら書⾯で出してほしい）上記観点については、⼀つ⽬、および⼆つ⽬と若⼲重なる部分もありますが AWS に対する説明責任を求めているものかと思われます。お客様の課題解決に対して本質的でない情報は開⽰しないスタンスがある以上、どのように改善するつもりかについても開⽰されない可能性が⼤きいです。

Slide 67

Slide 67 text

67 明確な原因の追求や AWS に対して改善策をご要望される場⾯明確な原因の追求や AWS に対して改善策をご要望される場⾯意図せず発⽣した再起動の理由を教えてほしいインスタンスの retirement について、今後発⽣しないように改善してほしい今回発⽣した事象に対して、AWS としてどう考えているのか︖（何なら書⾯で出してほしい）上記観点については、⼀つ⽬、および⼆つ⽬と若⼲重なる部分もありますが AWS に対する説明責任を求めているものかと思われます。お客様の課題解決に対して本質的でない情報は開⽰しないスタンスがある以上、どのように改善するつもりかについても開⽰されない可能性が⼤きいです。また、書⾯が出てくることはありません。

Slide 68

Slide 68 text

68 すでに公開されている情報を総合して管理の責任と説明や、情報開⽰については、ここまでで⾒た「技術的なお問い合わせに関するガイドライン」に記載の通り

Slide 69

Slide 69 text

69 すでに公開されている情報を総合して管理の責任と説明や、情報開⽰については、ここまでで⾒た「技術的なお問い合わせに関するガイドライン」に記載の通り基盤の状態がどのようになっているかを⽰す CloudWatch メトリクスも各々の AWS サービスに対して⽤意されているこれらを活⽤して状態の切り分け⼿段が⽤意されている

Slide 70

Slide 70 text

70 すでに公開されている情報を総合して管理の責任と説明や、情報開⽰については、ここまでで⾒た「技術的なお問い合わせに関するガイドライン」に記載の通り基盤の状態がどのようになっているかを⽰す CloudWatch メトリクスも各々の AWS サービスに対して⽤意されているこれらを活⽤して状態の切り分け⼿段が⽤意されている設計思想として推奨するホワイトペーパーなどの指針が⽤意されている

Slide 71

Slide 71 text

71 すでに公開されている情報を総合して管理の責任と説明や、情報開⽰については、ここまでで⾒た「技術的なお問い合わせに関するガイドライン」に記載の通り基盤の状態がどのようになっているかを⽰す CloudWatch メトリクスも各々の AWS サービスに対して⽤意されているこれらを活⽤して状態の切り分け⼿段が⽤意されている設計思想として推奨するホワイトペーパーなどの指針が⽤意されているこれらさまざまな情報提供により… 状況判断・切り分けのためのメトリクスの提供、ガイドラインや、公式ドキュメントの提⽰ですでに説明責任を果たしている、とも考えられます。

Slide 72

Slide 72 text

AWS もスポンサーになっているイベントで⼤きな声では⾔えないが… なるべくサポートに頼らなくても済む⽅法（超主観）

Slide 73

Slide 73 text

73 クラウドに合わせた設計をそもそもホワイトペーパーで Design for failure と⾔っている “Everything fails all the time.” – Werner Vogels Design for failure - Running Containerized Microservices on AWS https://docs.aws.amazon.com/whitepapers/latest/running-containerized-microservices/design-for-failure.html

Slide 74

Slide 74 text

74 クラウドに合わせた設計をそもそもホワイトペーパーで Design for failure と⾔っている “Everything fails all the time.” – Werner Vogels 障害が起こり得ない、起こるはずはない、起こってもらっては困るという考えを捨てる Design for failure - Running Containerized Microservices on AWS https://docs.aws.amazon.com/whitepapers/latest/running-containerized-microservices/design-for-failure.html

Slide 75

Slide 75 text

75 クラウドに合わせた設計をそもそもホワイトペーパーで Design for failure と⾔っている “Everything fails all the time.” – Werner Vogels 障害が起こり得ない、起こるはずはない、起こってもらっては困るという考えを捨てる事象発⽣時、影響を受けているリソースを捨て、新たなリソースを作ることで速やかな復旧ができる設計をする。 Design for failure - Running Containerized Microservices on AWS https://docs.aws.amazon.com/whitepapers/latest/running-containerized-microservices/design-for-failure.html

Slide 76

Slide 76 text

76 ⼀定数いただくお問い合わせインスタンスステータスチェックで、「StatusCheckFailed_System」が起こったのはなぜか︖ AWS として、この問題を引き起こさない具体的な改善策を提⽰してほしい Status checks for Amazon EC2 instances https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html

Slide 77

Slide 77 text

77 ⼀定数いただくお問い合わせインスタンスステータスチェックで、「StatusCheckFailed_System」が起こったのはなぜか︖ AWS として、この問題を引き起こさない具体的な改善策を提⽰してほしいインスタンスの retirement を知らせる通知が来た期⽇の延期をしてほしいそもそも、retirement が起きないようにしてほしい Status checks for Amazon EC2 instances https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html Instance retirement https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-retirement.html

Slide 78

Slide 78 text

78 このような質問の背景には… 障害が起こるはずがない、起こってもらっては困るという考えが根底にあるのでは︖ 正常な状態が保持され続けることを前提にしている可能性がある技術的なお問い合わせに関するガイドライン https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/

Slide 79

Slide 79 text

79 まとめ AWS のベストプラクティス（設計原則）に沿っている、かつ、AWS 公式ドキュメントで解説されているものがあれば、「即問い合わせ︕」としなくても良い運⽤に落とし込むことができる

Slide 80

Slide 80 text

80 まとめ AWS のベストプラクティス（設計原則）に沿っている、かつ、AWS 公式ドキュメントで解説されているものがあれば、「即問い合わせ︕」としなくても良い運⽤に落とし込むことができるエラー記録 → 正常復旧 → サービス影響なし︓この場合は「事象」発⽣と⽚付けられるエラー記録 → 想定通り復旧しない → サービス影響発⽣︓この場合を「障害」とみなす

Slide 81

Slide 81 text

81 まとめ AWS のベストプラクティス（設計原則）に沿っている、かつ、AWS 公式ドキュメントで解説されているものがあれば、「即問い合わせ︕」としなくても良い運⽤に落とし込むことができるエラー記録 → 正常復旧 → サービス影響なし︓この場合は「事象」発⽣と⽚付けられるエラー記録 → 想定通り復旧しない → サービス影響発⽣︓この場合を「障害」とみなすマネージドサービスと銘打った AWS サービスでもない EC2 の採⽤ですら、基盤の運⽤・管理を AWS に委ねていると⾔える

Slide 82

Slide 82 text

82 まとめ AWS のベストプラクティス（設計原則）に沿っている、かつ、AWS 公式ドキュメントで解説されているものがあれば、「即問い合わせ︕」としなくても良い運⽤に落とし込むことができるエラー記録 → 正常復旧 → サービス影響なし︓この場合は「事象」発⽣と⽚付けられるエラー記録 → 想定通り復旧しない → サービス影響発⽣︓この場合を「障害」とみなすマネージドサービスと銘打った AWS サービスでもない EC2 の採⽤ですら、基盤の運⽤・管理を AWS に委ねていると⾔えるそのため、基盤のことで発⽣すること全てをオンプレ的に捉える必要もない

Slide 83

Slide 83 text

83 まとめ AWS のベストプラクティス（設計原則）に沿っている、かつ、AWS 公式ドキュメントで解説されているものがあれば、「即問い合わせ︕」としなくても良い運⽤に落とし込むことができるエラー記録 → 正常復旧 → サービス影響なし︓この場合は「事象」発⽣と⽚付けられるエラー記録 → 想定通り復旧しない → サービス影響発⽣︓この場合を「障害」とみなすマネージドサービスと銘打った AWS サービスでもない EC2 の採⽤ですら、基盤の運⽤・管理を AWS に委ねていると⾔えるそのため、基盤のことで発⽣すること全てをオンプレ的に捉える必要もないインフラ基盤観点ではなく、提供サービス観点で事象を捉えることにより、よりビジネスに即した問い合わせにすることができる

Slide 84

Slide 84 text

84 まとめ AWS のベストプラクティス（設計原則）に沿っている、かつ、AWS 公式ドキュメントで解説されているものがあれば、「即問い合わせ︕」としなくても良い運⽤に落とし込むことができるエラー記録 → 正常復旧 → サービス影響なし︓この場合は「事象」発⽣と⽚付けられるエラー記録 → 想定通り復旧しない → サービス影響発⽣︓この場合を「障害」とみなすマネージドサービスと銘打った AWS サービスでもない EC2 の採⽤ですら、基盤の運⽤・管理を AWS に委ねていると⾔えるそのため、基盤のことで発⽣すること全てをオンプレ的に捉える必要もないインフラ基盤観点ではなく、提供サービス観点で事象を捉えることにより、よりビジネスに即した問い合わせにすることができるひいては、細々した問い合わせ頻度の低減に寄与すると考えられる（運⽤で疲弊しない）

Slide 85

Slide 85 text

85 おわりにクラウドならではの設計思想に基づいて

Slide 86

Slide 86 text

86 おわりにクラウドならではの設計思想に基づいて提供サービスで採⽤しているアーキテクチャとビジネス影響の観点で事象を判断して

Slide 87

Slide 87 text

87 おわりにクラウドならではの設計思想に基づいて提供サービスで採⽤しているアーキテクチャとビジネス影響の観点で事象を判断して適切な問い合わせを⼼がけることで（する or しない含めて）

Slide 88

Slide 88 text

88 おわりにクラウドならではの設計思想に基づいて提供サービスで採⽤しているアーキテクチャとビジネス影響の観点で事象を判断して適切な問い合わせを⼼がけることで（する or しない含めて）事象発⽣時の問い合わせ負担を軽減できると考えられます

Slide 89

Slide 89 text

89 おわりにクラウドならではの設計思想に基づいて提供サービスで採⽤しているアーキテクチャとビジネス影響の観点で事象を判断して適切な問い合わせを⼼がけることで（する or しない含めて）事象発⽣時の問い合わせ負担を軽減できると考えられます登壇タイトルに対して逆説的になりましたが、「問い合わせをしなくても済む」という考え⽅もありうると捉えてより良いクラウドジャーニーを︕

Slide 90

Slide 90 text

余談

Slide 91

Slide 91 text

91 個⼈的な思いよくあるイベント参加アンケート

Slide 92

Slide 92 text

92 運⽤でもないし、結局いつも「その他」よくあるイベント参加アンケートサポートエンジニアも追加してほしい︕ もちろん別で追加してほしいロールの⽅はいらっしゃるでしょうが…

Slide 93

Slide 93 text

93 ぜひご検討を︕ よくあるイベント参加アンケートサポートエンジニアも追加してほしい︕ もちろん別で追加してほしいロールの⽅はいらっしゃるでしょうが… IT 系イベントの企画・運営のみなさまぜひ、ご検討ください。

Slide 94

Slide 94 text

94 そんな中 JAWS-UG 神⼾のアンケートではもちろんデプロイ済私が共同運営している JAWS-UG 神⼾の参加者アンケートのロールには「サポートエンジニア」が当然のように⼊っています 10⽉18⽇（⾦）にイベント開催がありますお近くの⽅、ぜひご参加ください

Slide 95

Slide 95 text

No content