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

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

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

⾃⼰紹介

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

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

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

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

はじめに

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

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

Tips などの裏話を聞いたことのない⽅が⼀定数いらっしゃることに気づきました。 > 今朝から AWS につながりません。 > 障害など起きていないでしょうか。

Tips などの裏話を聞いたことのない⽅が⼀定数いらっしゃることに気づきました。 > 今朝から AWS につながりません。 > 障害など起きていないでしょうか。ありえないだろう︖と思われるかもしれませんが、本質的に同様なお問い合わせが、実は多いことを引き合いに、問い合わせ⽂⾯を組み⽴てる上で、相⼿が何を⾒られるかや意識齟齬を防ぐための⽂書構成の観点について話をしました。これは私が夢でみかけた⽂章特定のお客様からいただいた⽂⾯そのままではない

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

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

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

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

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 Ø この資料も後⽇アップしますので、上記も合わせてご⼀読いただけると幸いです。

本題

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

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

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

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

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

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

27 今回はこの観点に着⽬してみます明確な原因の追求や AWS に対して改善策をご要望される場⾯意図せず発⽣した再起動の理由を教えてほしいインスタンスの retirement について、今後発⽣しないように改善してほしい今回発⽣した事象に対して、AWS

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

について、今後発⽣しないように改善してほしい今回発⽣した事象に対して、AWS としてどう考えているのか︖（何なら書⾯で出してほしい）おそらく、以下のような背景があるんだろうな︖とは思っています「なぜなぜ分析」などの考え⽅が定着している顧客や発注元への説明責任が発⽣する

について、今後発⽣しないように改善してほしい今回発⽣した事象に対して、AWS としてどう考えているのか︖（何なら書⾯で出してほしい）おそらく、以下のような背景があるんだろうな︖とは思っています「なぜなぜ分析」などの考え⽅が定着している顧客や発注元への説明責任が発⽣する「責任共有モデル | AWS」より抜粋 https://aws.amazon.com/jp/compliance/shared-responsibility-model/ AWS がセキュリティに対する責任を負っている

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

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

に解決することを⽬指します。 AWS では障害の内容の詳細な説明をしていない「技術的なお問い合わせに関するガイドライン | AWS サポート / 障害の原因についてのお問い合わせ」より抜粋 https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/

に解決することを⽬指します。 AWS では障害の内容の詳細な説明をしていないなぜなら、利⽤者がコントロールできない範囲となり、利⽤者へ伝えても利⽤者として取りうる回避策に影響を及ぼすものではないと考えているから「技術的なお問い合わせに関するガイドライン | AWS サポート / 障害の原因についてのお問い合わせ」より抜粋 https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/

に解決することを⽬指します。 AWS では障害の内容の詳細な説明をしていないなぜなら、利⽤者がコントロールできない範囲となり、利⽤者へ伝えても利⽤者として取りうる回避策に影響を及ぼすものではないと考えているからつまり利⽤者が抱える課題解決に対して本質的ではないから「技術的なお問い合わせに関するガイドライン | AWS サポート / 障害の原因についてのお問い合わせ」より抜粋 https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/

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

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 観点に絞って、以降続けます。

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 の関与が必要なインスタンスの基盤の問題と明記されている

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 基盤側の問題ではあるものの、前述までお話ししたようにお客様の課題解決の本質に影響しないため詳細な原因は開⽰しない

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 基盤側の問題ではあるものの、前述までお話ししたようにお客様の課題解決の本質に影響しないため詳細な原因は開⽰しないただ、考えられる可能性の例は挙げてくれている・ネットワーク接続の喪失・システム電源の喪失・物理ホストのソフトウェアの問題・ネットワーク到達可能性に影響する、物理ホスト上のハードウェアの問題

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 基盤側の問題ではあるものの、前述までお話ししたようにお客様の課題解決の本質に影響しないため詳細な原因は開⽰しない結果、問い合わせは不要（問い合わせても本ページに書かれていること以上の提⽰がない）ただ、考えられる可能性の例は挙げてくれている・ネットワーク接続の喪失・システム電源の喪失・物理ホストのソフトウェアの問題・ネットワーク到達可能性に影響する、物理ホスト上のハードウェアの問題

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

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

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 が記録される場合、ユーザーが関与して修復する必要のある問題と明記されている

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 レイヤー以上）での問題を探る必要がある

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 への問い合わせは不要

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 へ問い合わせ」とはならないはず、という観点です

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

としてどう考えているのか︖（何なら書⾯で出してほしい）意図しない再起動が発⽣したとしてもその後、EC2 インスタンスが問題なく再開されて稼働し続けている場合は正常な稼働状態に戻っている意図しない再起動稼働状態提供サービスへの影響なし

としてどう考えているのか︖（何なら書⾯で出してほしい）意図しない再起動が発⽣したとしてもその後、EC2 インスタンスが問題なく再開されて稼働し続けている場合は再起動の発⽣要因を AWS に問い合わせる必要がない、と分類可能正常な稼働状態に戻っている意図しない再起動稼働状態提供サービスへの影響なし

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

としてどう考えているのか︖（何なら書⾯で出してほしい）意図しない再起動が発⽣した後に正常な EC2 インスタンスの稼働につながっていない場合正常な稼働状態でない意図しない再起動稼働状態提供サービスへの影響あり

としてどう考えているのか︖（何なら書⾯で出してほしい）意図しない再起動が発⽣した後に正常な EC2 インスタンスの稼働につながっていない場合この時初めて AWS サポートへ問い合わせし、原因の特定と復旧を模索する正常な稼働状態でない意図しない再起動稼働状態提供サービスへの影響あり

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

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

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

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

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

いちセクションとして設けられているページで解説されています。⼤元のホワイトペーパーのタイトルを直訳すると「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

いちセクションとして設けられているページで解説されています。⼤元のホワイトペーパーのタイトルを直訳すると「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

について、今後発⽣しないように改善してほしい今回発⽣した事象に対して、AWS としてどう考えているのか︖（何なら書⾯で出してほしい）上記のような考えに⾄るということは︖

について、今後発⽣しないように改善してほしい今回発⽣した事象に対して、AWS としてどう考えているのか︖（何なら書⾯で出してほしい）上記のような考えに⾄るということは︖ 「完全状態で稼働し続ける」ことを前提としている or 期待していると⾔える

について、今後発⽣しないように改善してほしい今回発⽣した事象に対して、AWS としてどう考えているのか︖（何なら書⾯で出してほしい）上記観点については、⼀つ⽬、および⼆つ⽬と若⼲重なる部分もありますが AWS に対する説明責任を求めているものかと思われます。

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

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

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

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

これらを活⽤して状態の切り分け⼿段が⽤意されている設計思想として推奨するホワイトペーパーなどの指針が⽤意されている

これらを活⽤して状態の切り分け⼿段が⽤意されている設計思想として推奨するホワイトペーパーなどの指針が⽤意されているこれらさまざまな情報提供により… 状況判断・切り分けのためのメトリクスの提供、ガイドラインや、公式ドキュメントの提⽰ですでに説明責任を果たしている、とも考えられます。

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

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

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

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

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

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

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

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

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

→ サービス影響なし︓この場合は「事象」発⽣と⽚付けられるエラー記録 → 想定通り復旧しない → サービス影響発⽣︓この場合を「障害」とみなすマネージドサービスと銘打った AWS サービスでもない EC2 の採⽤ですら、基盤の運⽤・管理を AWS に委ねていると⾔える

→ サービス影響なし︓この場合は「事象」発⽣と⽚付けられるエラー記録 → 想定通り復旧しない → サービス影響発⽣︓この場合を「障害」とみなすマネージドサービスと銘打った AWS サービスでもない EC2 の採⽤ですら、基盤の運⽤・管理を AWS に委ねていると⾔えるそのため、基盤のことで発⽣すること全てをオンプレ的に捉える必要もない

→ サービス影響なし︓この場合は「事象」発⽣と⽚付けられるエラー記録 → 想定通り復旧しない → サービス影響発⽣︓この場合を「障害」とみなすマネージドサービスと銘打った AWS サービスでもない EC2 の採⽤ですら、基盤の運⽤・管理を AWS に委ねていると⾔えるそのため、基盤のことで発⽣すること全てをオンプレ的に捉える必要もないインフラ基盤観点ではなく、提供サービス観点で事象を捉えることにより、よりビジネスに即した問い合わせにすることができる

→ サービス影響なし︓この場合は「事象」発⽣と⽚付けられるエラー記録 → 想定通り復旧しない → サービス影響発⽣︓この場合を「障害」とみなすマネージドサービスと銘打った AWS サービスでもない EC2 の採⽤ですら、基盤の運⽤・管理を AWS に委ねていると⾔えるそのため、基盤のことで発⽣すること全てをオンプレ的に捉える必要もないインフラ基盤観点ではなく、提供サービス観点で事象を捉えることにより、よりビジネスに即した問い合わせにすることができるひいては、細々した問い合わせ頻度の低減に寄与すると考えられる（運⽤で疲弊しない）

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

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

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

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

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

余談

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

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

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

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

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

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

More Decks by kazzpapa3

Other Decks in Technology

Featured

Transcript