本記事は
2022年度 新人卒業記念Week
1日目の記事です。
🌸
イベント告知
▶▶ 本記事 ▶▶
2日目
📚
はじめに
こんにちは、梅原です。12月にNRIグループ社内向けAWS GameDayに参加してきました。
今回のブログでは、新卒1年目のインフラエンジニアである私がAWS GameDayに参加して得たトラブルシュートの気づきについて書こうと思います。
この内容は初学者の方や普段トラブルシュートが苦手だと感じてる方に読んでいただきたいです。
AWS GameDayとは？
AWS GameDayは簡単に言うと、システムをデプロイして、度重なるシステム障害を解決し、ビジネスを成功させるというシステムのデプロイから運用をゲーム感覚で楽しむことができるハンズオン学習です。
チームを組んで、システムをデプロイしたり、トラブルシュートで得点を稼ぎ、1番得点が高かったチームが優勝となります。
ビジネスチックな部分もあるので、お客さんからお金（得点）が入ってきたり、逆に使用するインフラはコストを払わないといけません。
AWS GameDayはAWS SummitやAWS re:Inventでも開催されています。
ゲーム感覚ででき、いろんなトラブルが発生するので、非常に楽しかったです。 12月にNRI主催の第二回GameDayが開催され、NRIネットコムからもチームを組んで出場しました。
順位はなんと、、「3位」！！！！
私自身初心者ながらGameDayを楽しむことができたので、チームを組んでくれた先輩方には感謝しかありません。
トラブルシュートの方法
さて、本題に入りましょう。GameDayはシステムに障害が発生し、それをトラブルシュートする必要があるとお伝えしました。
今回GameDayに参加して、トラブルシュートは筋道を立てて実施していくことがいかに大事であるか認識できました。
今まではエラーが起こったときに、勘で原因を考えてしまい、余計な時間がかかってしまいました。
また、勘だけで考えていくと思いつく案がなくなった途端手が止まってしまいます。
問題が起こったときのトラブルシュートの方法について自分なりに考えて、調べたのでまとめようと思います。
結論から言うと、トラブルシュートの方法は「状況を把握し、そこから仮設を立てて検証を繰り返す」です。
まずは起こってる状況から事実を収集し、そこから仮説を立てて、それを検証していきます。 検証で仮説が間違ってた際は、再度仮説を立てて検証を繰り返していき、解消できるまで実施していきます。 これから具体的に見ていきましょう。
①状況把握
問題が出たときは、まず現状を正しく把握することが必要です。 このときに自分の考えは含めずに5W1Hに沿って考えることで必要な情報を得ることができます。
- いつ発生したかや発生頻度（When）
- だれがその問題に直面するか（Who）
- どこで発生したかやどのリソースで発生したか（Where）
- 発生した事象は何か（What）
- どのような操作で問題が発生するか（How）
この５点に沿って状況の整理をしていきます。なぜ発生したか（Why）を考えていくのは、状況を把握したあとです。
技術的なお問い合わせに関するガイドラインを見ても、AWSサポートが効果的にトラブルシュートするためは、正しい状況把握が必要であることがわかります。
解決したい課題を明確にする
状況を正確に共有する
経緯を共有する
②仮説検証
集めた事実を基に仮説を立てて、検証していきます。
仮説を立てるときには、接続元から接続先への通信の流れに沿って考えていくことが有効です。
通信の流れに沿って考えることで、どこからどこまでの処理は正常に動作し、どこでリクエストが失敗するかを整理しながら見ていくことができます。
仮説を立ててから、必要なログなどの具体的な情報を集めながら検証していきます。
立てた仮説が間違ってた際は、再度別の仮説を立てて検証を繰り返していきます。
例えば
ここで一つ例を出したいと思います。
開発中に上記の構成で「EC2インスタンスにインストールされたWebサーバーにhttpアクセスしたときに504(Gateway Time-out)エラーが出る」という状況を考えてみます。
状況の把握
まずはここから5W1Hに沿って状況の整理を実施していきます。
- いつ発生したかや発生頻度（When）
→インフラデプロイの時間（○月○日○時○分）〜現在 - だれがその問題に直面するか（Who）
→ブラウザからアクセスする人 - どこで発生したかやどのリソースで発生したか（Where）
→東京リージョンのVPC内のパブリックサブネットに設置したロードバランサーとプライベートサブネットに設置されたEC2インスタンス - 発生した事象は何か（What）
→ブラウザにhttpリクエストのレスポンスが帰ってこず、504エラーが表示される - どのような操作で問題が発生するか（How）
→ブラウザからドメインに対してhttpアクセス。サーバーへのアクセスはパブリックサブネットに設置したロードバランサー経由。
このように5W1Hに沿って考えることで、状況を説明できる十分な情報を得ることができます。発生頻度に関しては一回限りでその後発生していない場合は、AWS側の問題も考えられます。AWSリソースに関してのトラブルシュートを実施する際は、権限周りの問題も考えられます。なのでその問題に直接関係しない部分に関しても、情報をもれなく集めておきます。
仮説検証
ここから通信経路に沿って考え、仮説を立てていきます。
通信経路は、リクエスト元→Internet Gateway→ロードバランサー→EC2インスタンス→ロードバランサー→リクエスト元へ接続する流れです。
その流れでVPCに入る前のネットワークACLは許可されているか、Internet Gatewayはアタッチできてるか、ルートテーブルの設定、ロードバランサーやインスタンスのセキュリティグループ、リソースの設定など個々のポイントに分解してリクエストがどこで止まっているかを考えていきます。
今回の例では504エラーが出ているので、ロードバランサーにはアクセスできるということがわかります。次にロードバランサー以降のアクセスを順に見ていきます。
EC2インスタンスにアクセスするためのセキュリティグループが空いていないという仮説を立てます。 コンソールでEC2に設定しているセキュリティグループを見ると、ロードバランサーからのアクセスを許可していませんでした。 許可していなかったために、ロードバランサーからアクセスできずタイムアウトされていました。EC2インスタンスのセキュリティグループに、ロードバランサーからのアクセスを許可してあげることで解決します。
もしセキュリティグループが問題ない場合は、次にEC2インスンスのサーバーのアクセスログやエラーログを見て、サーバー内で処理できていないと言う仮説を立てて検証していきます。
このように実際の通信の流れに沿って考えることで、漏れなく考えられる要因を洗い出し、根本原因とそれ以外の切り分けができます。
おわりに
自分自身トラブル発生時の原因を考えるのがまだまだ苦手だと感じました。今回は単純な例で考えていましたが、これが複雑な構成のシステムだとより知識が必要になってきます。
自分だけで考えて検証してわからなかったら、まずは周りの有識者に相談すると、自分が知らなかっただけでサクッと解決することもあります。それでもわからない場合やAWSの公式ページ、ドキュメントを読んでも解決しない場合は、AWSサポートに問い合わせるという手もあります。
仮説を立てるためには、AWSのサービス知識やインフラの知識、システム構成の理解が必要で、検証段階でもどこのログやメトリクスを見たら良いかなど、まだまだ自分自身理解していない部分があります。 2年目以降では、AWSやインフラ、システム構成について、一歩一歩理解を深めていくことを目標に頑張ろうと思います。
