AWS 環境での問題切り分けのポイントを考えてみた

Nakamura Makoto

2022.09.02

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。アノテーションの中村 (誠) です。
今回は AWS 環境での問題切り分けのポイントを自分なりに考えてみたものをアウトプットしようと思います。

きっかけ

私はアノテーションのテクニカルサポートとして、お客様の課題解決などのお手伝いをしており、現在入社半年が経過しました。
基本的な業務には慣れてきたものの、まだうまくできていないことがあります。

それが、「切り分け」です。

テクニカルサポート業務の中で、「問題の切り分け」という言葉をよく耳にしますが、まさしく問題の切り分けがうまくできず、解決まで時間がかかることがあります。
一方、問題の切り分けがうまい方は、解決までの時間が短かったり、お客様からも満足の評価を頂いていることが多いです。

そこで私は、問題の切り分けがうまい方の対応を見て、自分なりにまとめ、実践してみようと思いました。
現段階で、ある程度ポイントがまとまったので、今回アウトプットしようと思った次第です。

注意点

今回紹介する内容は、個人の意見ですので、組織としての考え方ではない点にはご注意下さい。
また、特定の問題に関するトラブルシューティングではなく、AWS 環境における様々なトラブルシューティングの基本的な考え方である点についても、あらかじめご承知おきください。

切り分けのポイント

ポイントの概要は以下の通りです。
各ポイントの詳細は後述します。

・機能の有効 (on) / 無効 (off)
・同じ手順かどうか
・エラー発生前に変更操作を行ったかどうか
・いつから発生するようになったのか
・事象の発生頻度
・エラーの具体的な内容
・AWS 側の不具合が疑われるログなどの確認

機能の有効 (on) / 無効 (off)

これは単純な内容で、ある機能の有効 (on) / 無効 (off) でエラーが解消されたり、挙動が変わったりしないかの確認です。

・有効 (on) / 無効 (off) の切り替えでエラーが解消されるか
・有効 (on) / 無効 (off) のどちらでも同じエラーになるか
・片方の時のみエラーが発生するか
・他方の時には別のエラーになるか
・有効 (on) / 無効 (off) が複数ある場合、どの組み合わせでエラーになるか、またはならないか

この切り分けは 1 か 0 かなので、わかりやすいと思います。
有効 (on) / 無効 (off) の切り替えで解決しなければ、また別の視点から考える必要がありますが、初期の切り分けとしてはわかりやすく、試しやすい内容だと思います。

同じ手順かどうか

エラー発生までの手順が、完全に同じ手順なのかどうかの確認です。

・完全に同じ手順
・一部違う手順
・違う手順の場合、どこがどう違うのか
・AWS 公式ドキュメントに沿っている場合、どの項目までできて、どの項目でエラーが発生するのか

開発環境と本番環境で完全に同じ手順にもかかわらず、片方の環境でのみエラーが発生する場合には、関連リソースの設定値など、別の差分を調査する必要があります。
もし、両環境で手順が違うのであれば、完全に同じ手順にした場合に、エラーが発生するかどうかをチェックし、エラーが発生しない手順に統一するという方法もあると思います。

スクリプトなどのプログラムでは、ソースコードを変更しない限りは同じ手順である可能性が高いと思いますが、マネジメントコンソールなどの GUI での作業の場合には、特に手順が重要だと思います。

エラー発生前に変更操作を行ったかどうか

エラー発生前に対象リソースの変更操作を行ったかどうかを確認します。

・変更操作は行っていない
・変更操作を行った
・どのリソースにどのような変更操作を行ったのか
・変更をもとに戻したらどうなるか
・CloudTrail や Config の確認

対象リソースの設定変更によるエラーですが、自分自身が変更を行った覚えがなくても、他の担当者が変更を行っていた可能性も考えられます。
そのため、対象リソースの変更履歴を、CloudTrail や Config から確認することが重要です。

また、OS などの自動アップグレードによる影響なども考えられますので、自動アップグレード設定についても確認し、バグレポートなども確認しましょう。

一時的な回避策として、変更をもとに戻したらエラーが解消されるかどうかも確認することで、特定の設定変更による影響かどうかを特定できます。

なお、AWS リソースの設定変更は、本番環境で実施する前に、開発環境などで行った方がよいというのはすでにご存知かと思いますが、リソースによっては特定の設定変更に関する注意があるので、本番環境での設定変更時には、必ず AWS 公式ドキュメントを確認しましょう。

一例ですが、Elastic Beanstalk の AWS 公式ドキュメントでは、設定変更を環境外で実施しないよう、注意書きがあります。

環境内にあるリソースを変更する場合は、必ず Elastic Beanstalk を使用してください。他のサービスのコンソール、CLI コマンド、または SDK を使用してリソースを変更した場合、Elastic Beanstalk ではこれらのリソースの状態を正確にモニタリングできなくなります。また、設定を保存することも、環境を確実に再現することもできなくなります。帯域外で変更を加えた場合は、環境を更新または終了する際も問題が発生することがあります。

いつから発生するようになったのか

発生日時に関する確認です。

・正常に動作していた日時
・エラーが発生するようになった日時
・現在も事象は継続しているのか
・事象が改善された場合には何か操作などを行ったか
・特定の時間帯にのみ発生するのか

いつまで正常に動作していて、いつからエラーが発生するようになったかを確認することで、AWS Health Dashboard から、AWS の広域障害の影響などを確認することができます。
また、エラーが発生するようになった日時と、先述の設定変更の日時の関連についても調査できるので、該当の時間における設定変更による影響も確認できます。

特定の時間帯にのみ発生する場合には、該当の時間におけるリクエスト量や負荷を、CloudWatch などで確認し、リソースの設定値を調整するという方法も考えられます。

注意点として、AWS 環境ではサービスによって、ログが UTC のサービスと、JST のサービスがあるので、対象サービスのタイムゾーンは確認しておきましょう。

事象の発生頻度

エラーなどの事象の発生頻度を確認します。

・常に発生するのか
・発生する時としない時があるのか
・発生するときの条件はあるのか
・発生するのがマネジメントコンソールなどの GUI かどうか

事象の発生頻度については、私たちテクニカルサポートからもお客様にヒアリングすることが多いです。
エラーの内容によっては、AWS 側の一時的な問題である可能性もあるため、発生頻度や再現性から、解決策をご案内することもあります。

また、AWS 側の一時的な問題である可能性が考えられる場合には、リトライについてご案内することもあります。
リトライについては、AWS 公式ドキュメントでもいくつか紹介されていますので、詳しくは以下の AWS 公式ドキュメントをご覧ください。

マネジメントコンソールなど、GUI での事象発生時には、HAR ファイルやコンソールログの共有をお願いすることもありますので、お問い合わせの際は、以下の弊社ブログを参考に、HAR ファイルやコンソールログを取得、共有頂ければ幸いです。
ただし、HAR ファイルやコンソールログに、認証情報などの機密情報が含まれる場合には、必ずマスクするようお願いします。

なお、障害の発生については AWS の技術的なお問い合わせに関するガイドラインに以下の記載があります。

・障害発生は予測不可能であり、また不可避です。AWS ではインフラの障害に対し要因分析および発生率の低減に努めておりますが、障害の発生を完全に防ぐことは困難です。
・このため AWS では「Design For Failure」(故障を前提とした設計)を推奨しています。また、監視サービスやリソースの提供、ベストプラクティスのご案内等を行っています。
・たとえば EC2 において、お客様が AWS 基盤の異常を検知した場合、不安定なリソースは廃棄していただき、新たに別の EC2 を調達していただく等、クラウドの特性を活かしたアクションが可能です。
・AWS では、障害内容の詳細なご説明は行っておりません。詳細な原因等をお伝えしても、お客様の回避策には影響がなく、お客様の課題解決において本質的ではないと考えているためです。むしろ監視サービスの適切な活用や、一次復旧を優先する方法をご案内することで、お客様の課題を迅速に解決することを目指します。

AWS 環境での設計・構築の際には、「Design For Failure」を意識しましょう。

エラーの具体的な内容

切り分けとは少し違う話になりますが、エラーの内容が曖昧なままだと解決が困難なので、エラーの具体的な内容も確認します。

・エラーログの全文
・エラー発生時のスクリーンショット
・何をしたときにどのようなエラーが発生するか

エラーの確認はトラブルシューティングの基本ですね。
よくあるエラーについては、AWS 公式ドキュメントやナレッジセンター、弊社ブログなどでも原因や解決策を記載していますが、ドキュメント調査にはエラーの具体的な内容が必要です。

そのため、「不具合が発生した」「エラーが出ている」「うまくいかない」などの曖昧な状態だと、どこに問題があるかの切り分けや、エラーの再現検証もできないので、エラーの具体的な内容は必ず確認します。

AWS 側の不具合が疑われるログなどの確認

先述の通り、AWS 側での障害は予測不可能であるため、一時的な障害や、数時間におよぶ広域障害が発生する可能性があります。
一方、アプリケーション側に起因する問題である可能性が高い場合には、調査や対応は責任共有モデルにより、お客様自身で行う必要があります。

もし、アプリケーション起因ではなく、AWS 側の不具合が疑われる場合には、以下の点を確認します。

・AWS Health Dashboard で広域障害の有無
・AWS 側の不具合が疑われるログやスクリーンショット
・お客様と同じ手順で同様の事象が再現するか

責任共有モデルについては、サービスごとに責任範囲が異なるので、対象サービスの AWS 公式ドキュメントで責任範囲を確認しましょう。
また、リトライの実装についても検討し、リトライで解決できるかどうかもお試しください。

弊社のお役立ちブログ集

弊社には過去にもトラブルシューティングなどのブログが書かれていますので、ぜひ併せてご覧ください。私自身、入社直後はもちろん、今でも非常に勉強になる内容ばかりです。

まとめ

今回は AWS 環境での問題切り分けのポイントを自分なりに考えてみたものをアウトプットしてみました。

まだまだテクニカルサポートしては未熟ですが、苦手なことでも情報を整理して対応することで、少しずつ成長できると思っています。
本ブログの内容には不足点もあるかと思いますが、トラブルシューティングの際に、少しでも参考になれば幸いです。

参考資料

アノテーション株式会社について

アノテーション株式会社は、クラスメソッド社のグループ企業として「オペレーション・エクセレンス」を担える企業を目指してチャレンジを続けています。「らしく働く、らしく生きる」のスローガンを掲げ、様々な背景をもつ多様なメンバーが自由度の高い働き方を通してお客様へサービスを提供し続けてきました。現在当社では一緒に会社を盛り上げていただけるメンバーを募集中です。少しでもご興味あれば、アノテーション株式会社 WEB サイトをご覧ください。

AWS 環境での問題切り分けのポイントを考えてみた

きっかけ

注意点