はじめに
立命館大学経済学部3年の向谷木です。
ディップ株式会社で、2026年7月27日〜8月7日の約2週間のインターンシップに参加しました。配属先はインフラ部門で、SREとしてバイトルの500系エラーの調査と改善に取り組みました。
この記事では、インターン中に行った業務と、調査を通じて学んだことを振り返ります。
今回のインターンシップの目的とゴール
目的： 大規模環境において、アウトプットする経験を通して、問題を解決できるようになること
ゴール： 問題の根本原因を調べる過程を再現できるようになること
取り組んだこと
インターンシップは、次の流れで進みました。
1. AWS上のシステム構成を理解する
2. 500系レスポンスの発生件数を調査する
3. 500エラーの原因を特定し、修正する
4. 調査方法と修正内容をドキュメントにまとめる
5. 大量に発生していた502エラーの原因を調査する
6. 調査結果と成果を発表する
バイトルのシステム構成
バイトルには新旧2つのシステムがあり、CloudFrontを起点として、それぞれのフロントやAPIへリクエストが送られます。また、新バイトルから旧バイトルのAPIやデータベースへリクエストを送る経路もあります。
ユーザーからのリクエストは、CloudFrontやALBを経由して各サーバーへ送られます。そのため、エラーの原因を特定するには、リクエストが通る経路に沿って各レイヤーを確認する必要がありました。
500系エラーの調査
対象サービスでは500系エラーが増加傾向にあり、原因を明らかにして改善する必要がありました。そこで、まずCloudFrontのログを使い、500、502、503、504などのステータスコードがそれぞれ何件発生しているかを集計しました。さらに、ステータスコードごとに発生件数の多いリクエストパスを調べ、影響の大きいエラーから原因を追いました。
調査した2つの問題
調査の結果、大きく2つの問題が見つかりました。
- 新バイトル：不正なパスに対して404を返すべきだが500を返してしまっている問題
- 旧バイトル：特定のパスで502が大量に発生する問題
新バイトル：不正なパスに対して500を返していた
新バイトルでは、特定のURLに不正なパスを指定すると、サーバーが500を返すケースがありました。
しかし、不正なパスを含むリクエストはサーバー内部の障害ではありません。本来は、リクエストが不正であることや対象ページが存在しないことを示す4xx系のステータスコードで応答するべきです。
該当処理のログを調査した上で、不正なパスが入力チェックを通過してデータベースまで渡され、データベースエラーが発生していることが分かりました。そこで、フロント側でパスの形式を検証し、不正なパスの場合は404を返すように修正しました。
この修正は本番環境まで適用し、適用後には不正なパスを原因とする500が発生しなくなったことを確認できました。
旧バイトル：特定のパスで502が大量に発生していた
旧バイトルでは、特定のパスに502が集中していました。
関係するサーバーのログを順番に確認し、リクエストがどこまで到達し、どの処理でエラーが発生しているかを調査しました。
複数のログを照合した結果、インフラ障害ではなく、アプリケーション側の処理に原因があることを特定できました。
学んだこと
大規模な環境でのAWSとNew Relicの使われ方
インターンに参加する前から、AWSの各サービスが持つ基本的な役割は理解していました。しかし、大規模なサービスの中で、それらが実際にどのように組み合わされ、運用されているかを見る機会はありませんでした。
実際のシステム構成やリクエストの経路を確認したことで、AWSに対する理解が大きく深まりました。個々のサービスを知るだけでなく、サービス同士のつながりを理解することの重要性を実感しました。
また、ログ解析の進め方について学びました。対象サービスではさまざまなレイヤーでログを記録しており、調査には主にAmazon AthenaとNew Relicを使用しました。
大規模なサービスでは、出力されるログの量も非常に多くなります。そのため、ログを一件ずつ目視で確認することは現実的ではありません。AthenaやNew Relicでクエリを実行し、対象期間、ステータスコード、パスなどの条件から必要なログを絞り込みました。
ここで難しかったのは、クエリを書くことだけではありません。「何を確認すれば原因に近づけるのか」を考え、取得した結果が何を表すのかを正しく解釈する必要がありました。
ログ調査では、次の流れが重要だと学びました。
- 確認したい仮説を立てる
- 仮説を検証できるログと項目を選ぶ
- クエリで必要な情報を抽出する
- 結果から確実に言えることと、まだ推測にすぎないことを分ける
- 次に確認するレイヤーを決める
AIを調査のパートナーとして使う
今回のインターンでは、AIを活用しながら原因調査を進めました。AWSやNew Relicと連携するMCPを利用し、ログの検索や分析にもAIを取り入れました。
特に意識したのは、AIが示した結論をそのまま受け入れないことです。
AIが「この部分が原因です」と回答した場合も、なぜそう判断できるのか、どのログが根拠になっているのか、ほかの可能性を除外できているのかを繰り返し確認しました。説明に飛躍があれば追加で質問し、自分でもコードやログを確認しました。
この進め方には、次のメリットがありました。
- AIの単なる推測を事実として扱うことを防げる
- 自分自身が処理やシステム構成を理解できる
- 根拠の弱い部分に早く気づける
- 調査の手戻りを減らせる
- 調査結果を自信を持ってチームへ説明できる
AIに答えを出してもらうのではなく、AIの解釈を理解し、根拠を一緒に確認していくことが重要だと感じました。
チームで修正を進める大切さ
不正なパスによる500エラーについては、原因調査だけでなく、修正を本番環境へ適用するところまで経験できました。一方で、作業を進める中で反省点もありました。
当初は、自分一人で調査と実装を進めすぎてしまうことがありました。しかし、既存のコードにはそれぞれの設計意図があり、どのレイヤーで何を処理するべきかという責務も決められています。
技術的に実装できることと、そのシステムにとって適切な修正であることは同じではありません。修正前に方向性を相談し、フロントとAPIのどちらで対応するのか、既存仕様との整合性は取れているのかをチームで共有する必要があります。
今回の経験から、調査結果を早めに共有し、実装へ進む前に認識を合わせることも、エンジニアリングの重要な仕事だと学びました。
結果
500エラーと502エラーについて、それぞれの原因を明らかにし、一つは修正案の適用、もう一つは修正案の考案まで進めることができました。
原因を特定する作業には難しい印象を持っていましたが、システムの構成や処理の流れを一つずつ理解し、自分なりに噛み砕きながら調査することで、原因へたどり着くことができました。
今回の経験を通じて、目標としていた「課題の原因を明らかにするまでの過程を再現すること」に対して、自信を持てるようになりました。
おわりに
2週間のインターンシップを通じて、500系エラーの集計から原因調査、修正、本番適用、効果検証までを経験しました。また、大量の502エラーについても、複数のログをつなぎ合わせてアプリケーションの実装まで原因を追うことができました。
特に印象に残ったのは、問題の原因となり得る要素の多さです。AIを活用して調査を進めましたが、それだけでは考慮しきれない点が数多くありました。
調査の過程でフィードバックをもらう機会は何度もあり、その中で、考慮すべき点や追加で調べるべき箇所を教えてもらい、自分だけでは得られなかった新しい視点を持つことができました。
これは、大規模なサービスの開発ならではの経験だったと思います。例えば、エラーの原因をソースコードだけに限定せず、Webサーバーの設定など、サービスを構成するさまざまな要素まで調査対象に含める必要がありました。
これまで知らなかったシステムの構成要素を学び、影響範囲をより広い視点で捉えられるようになりました。
今回得た経験を、今後の開発や問題調査にも生かしていきたいと思います。
