【社内資料公開】AWSトラブルシューティングページまとめ／より早い原因把握のために心がけること

はじめに

こんにちは植木和樹です。オンプレで10年近くサーバーの保守運用をやっていた経験からいいますと、AWSの障害発生率は非常に低くて驚きます。数百台規模のサーバーを扱ってますと、毎日どこかでのサーバーでディスク、CPUファン、メモリーパリティエラーなんかの故障が起きていて日々対応に駆けまわってた覚えがあります。

さてAWSの障害発生率が低いといってもゼロというわけではありません。仮に0.1%だとしても1000日つまり3年運用していれば1回くらい障害に遭遇するものです。0.01%だったとしてもサーバーが1万台あれば1日1回なにかしらのトラブルに遭遇しても不思議ではありません。

トラブルに遭遇すると、当然サービスや処理に影響をきたしてしまうわけで早期の暫定処置と、その後に恒久的な対策が求められます。その時に重要なのは早く正しく原因を特定することです。トラブルシューティング力が重要です。

AWSでは各サービスのドキュメントに「トラブルシューティング」のページを設けています。毎回Googleで検索してもいいのですが、いくつかのページは検索ワードを工夫しないと検索トップにでてこないので、今回は各サービスのトラブルシューティングページをまとめてみました。

サービス別トラブルシューティング

問い合わせが多い代表的なサービスについてトラブルシューティングページヘのリンクをまとめました。特にEC2やS3、WorkSpacesについては問い合わせが多いサービスですので一通り読んでおきましょう。

• インスタンスのトラブルシューティング - Amazon Elastic Compute Cloud
• Windows インスタンスのトラブルシューティング - Amazon Elastic Compute Cloud
• ロードバランサーのトラブルシューティングを行う - Elastic Load Balancing
• Amazon S3 のトラブルシューティング - Amazon Simple Storage Service
• RDS トラブルシューティング - Amazon Relational Database Service
• ElastiCache アプリケーションのトラブルシューティング - Amazon ElastiCache
• Amazon WorkSpaces の管理の問題のトラブルシューティング - Amazon WorkSpaces
• Amazon WorkSpaces クライアントの問題のトラブルシューティング - Amazon WorkSpaces
• Beanstalk トラブルシューティング - Elastic Beanstalk
• AWS OpsWorks のトラブルシューティング - AWS OpsWorks
• AWS CloudFormation のトラブルシューティング - AWS CloudFormation

トラブル時のヒアリングのコツ

ここでは特定のサービスに限った話でなく、うまく状況を把握するためのヒアリングのコツについてまとめてみました。 やっぱりベースになるのは5W1Hです。

いつ

いつ発生したのか、いまも継続中なのか確認しましょう。

• 障害の発生日時（ログを絞り込みやすくなるので、できれば何時何分（何秒）まで）
• 障害が現在も継続しているか
• 発生は1度きりか、何度も発生したか

だれが

特定のユーザーでのみ発生しているのか確認しましょう。

• 実行したIAMユーザー名
• WorkSpaces ユーザー名
• そのユーザーでだけ発生するのか、別のユーザーが行っても発生するのか

どこで

お客様は本番、ステージング、開発で複数のAWSアカウントを持っている場合があります。どの環境で発生したのか確認しましょう。

• AWSアカウントID
• リージョン
• WorkSpaces ディレクトリ名
• 処理を実行している場所（EC2上ならインスタンスID、お客様環境なら利用OSとバージョン）

なにを

どのリソースで発生したのか確認しましょう。

• EC2インスタンスID
• ELB名
• RDS名
• S3バケット名やオブジェクト名
• Beanstalk アプリケーション名、Environment
• Opsworks スタック名
• WorkSpaces スペース名

どのように

問題が再現できれば、原因調査も早くなります。どのような操作を行って発生したのかなるべく具体的に把握しましょう。またエラーメッセージや実行時ログがあるとベストです。

• sshを冗長メッセージで接続した時の出力（ssh -vvvv ec2-user@server.example.com）
• awscliのコマンドライン と --debug オプションつきの出力
• マネージメントコンソール等の画面スナップショット
• ログファイル（ログファイルの出力方法や出力先は各サービスページを参照）
  • ELBのアクセスログ
  • CloudFrontのアクセスログ（x-edge-request-id）
• CloudFront遅延の場合はリクエスト／レスポンスヘッダー情報
• AWS Diagnostics for Microsoft Windows Server
• ネットワーク通信障害の場合はtcpdumpやWiresharkを使ってのパケットキャプチャー結果

特にWorkSpacesのログはフォルダの深い場所に複数あります。ZIPで固めて送ってもらいましょう。

• %LOCALAPPDATA%\Amazon Web Services\Amazon Workspaces\1.0\Logs
• %LOCALAPPDATA%\Teradici\PCoIPClient\logs
• C:\Users\<USERNAME>\AppData\Local\Temp\workspaces.DMP （存在しない場合も）

なぜ

問い合わせの緊急度を検討するために、障害が業務やサービスに与える影響を確認しましょう。

AWSサポート（Businessプラン以上）では下記の観点で緊急度を選べるようになっています。（よくある質問）

非常事態（Enterpriseプランのみ）

本番環境において回避方法の無い問題が発生し、お客様のビジネスが危機的な状況にさらされている。お客様のアプリケーションの最重要な機能が利用出来ない状況が発生している場合。

緊急

問題を一時回避する方法がない、且つお客様のビジネスが深刻な影響を受けている。アプリケーションの重要な機能が利用できない。

高

問題を一時回避する方法がない。アプリケーションの極めて重要な機能が損なわれている、または低下している。

普通

問題の一時回避が可能である。アプリケーションにて致命的ではない機能の挙動に異常が見られる。急を要する開発の質問がある。

低

一般的な開発のご質問、または機能追加のご要望がある。

まとめ

最も確実な原因特定の手段は「再現させること」です。事細かくヒアリングするのは大変かもしれませんが、このページをご覧いただいて、わかる範囲で回答をいただくのも良いでしょう。

また上記に含めませんでしたが「最近の変化点」を確認するのも大切です。多くの場合、問題は変化後に発生します。これまで問題なく動いていたものが突然動かなくなった場合は、直近でリリースをしていないか、設定を変更した箇所はないかもあわせて確認するようにしましょう。