はじめに：
はじめまして。
名古屋工学院専門学校のAIイノベーション学科に所属している村上穂奈美です。
今回、9/7〜9/18の2週間、ディップ株式会社のプラットフォーム部にインターン生として参加して、大規模サービスを支えるインフラの改善業務を経験しました。
この記事では、インターン期間で取り組んだ課題とそこから得た学びについて書いていこうと思います。
インターンの目標
インターンの参加に際して、以下の理想像と目標を設定しました。
理想のエンジニア像：チームがノイズなくユーザへの価値提供に集中できる環境を作り、自分自身もユーザーの人生に良い変化を与えるサービスの創出に貢献できる、ユーザー目線でフルスタックなSRE
目標：
- 自分のタスクがどのように事業価値に繋がっているかを考えながら開発する
- 上記を考えながら進めることで、SREの立場からどのようにユーザーへ価値提供できるかをイメージできるようになる
これまでの経験を経て、SREの取り組みによってユーザーにより良い体験を届けることに挑戦したいと考えていました。
取り組んだこと
5xx系エラー改善 初めてのAI駆動なエラーログ調査
まず担当したのが、5xx系エラーの改善です。
プラットフォーム部では、エラーの原因を調査・改善し、サービスの信頼性を高める取り組みを行っています。私はその一環として、特定のパスで頻発していた502エラー（Bad Gateway）を解消し、ユーザー体験を向上させるタスクに取り組みました。
調査には、AWSとNewRelicのMCPを活用しました。MCPを通じたAIのログ分析により、共通項や特徴を抽出するという手順です。AIをフル活用してログ調査を行うのは初めての経験だったため、AI駆動ならではの失敗と学びがありました。
AI駆動でアクセスログを調査する中で、エラーになったリクエストは全て「ALB・サーバー間での接続失敗」に起因することが判明しました。こで私は、「ALB・サーバー間の接続を持続できる時間（keep-alive-timeout）を伸ばせば、今回の502エラーを改善できるのではないか」という仮説を立てました。
この仮説を裏付けるため、無通信時間を計測し、その最大値に合わせてkeep-alive-timeoutを大幅に延長することを提案しました。
しかし、上長からは「keep-alive-timeoutの短さが原因として有力であるものの、無通信時間の計測手法が正確か、また設定を大幅に伸ばすことで他の弊害が出ないかを慎重に考慮すべき」というフィードバックをいただきました。
指摘を受けて計測方法を再度確認したところ、ALB・サーバー間の無通信時間については正確な記録がなく、Cloudfront・ALB間の無通信時間と、ALBがサーバーをターゲットに通信したログを元に推定して計測していたことが分かりました。
また、keep-alive-timeoutを大幅に延長した場合、以下の影響が出ることにも気づきました。
・サーバーにTCP接続が長く残る
・同時に処理できるリクエスト数が減り、上限を超えてしまう
・結果として、別のタイムアウトエラーが増加する
これらの情報を踏まえ、他に影響が出ない「適度な値」を算出して再提案し、無事に修正まで進めることができました。
この経験から、AI駆動の調査であっても「根拠とするデータの計測範囲や算出方法を正確に裏付けすること」、そして「設定変更が及ぼす影響範囲を多角的に精査すること」の重要性を痛感しました
旧環境に紐づいているWAFルールを新環境に合わせて刷新
次に取り組んだのは、旧環境のWAFルールを新環境に合わせて刷新するタスクです
バイトルのユーザーサイトは7月に大規模なリニューアルを行い、最新のベストプラクティスに基づいた新環境を構築して、旧環境と並行運用しています。
私は、両環境のWAFルール設定を統一し、システム全体の堅牢性を向上させる役割を担いました。
まずはタスクの全体像を掴むため、各環境のルール設定の共通項や特徴を分析し、レポートとして共有することを試みました。
しかし、大規模サービスであるバイトルには膨大な数のルールが設定されており、複雑な情報の整理に難航しました。AIを活用して概要をまとめたものの、最初に完成したレポートは非常に分かりづらい内容になってしまっていました。
そこでメンターの方から、資料作成における2つの重要なポイントを教わりました。
- PREP法（結論・理由・具体例・結論）を意識した順序立てた構成
- 読み手を意識した視認性の高いデザイン
実際に、AIに対して「構成とレイアウトを意識したレポートの作成」を指示し直したところ、それまで把握しきれなかった複雑な設定や全体の傾向が、驚くほどスムーズに理解できるようになったのです。
複雑な情報について分かりやすく伝える資料を作成することは、コミュニケーションコストを下げるだけでなく、自分自身の認知負荷を下げ、迅速な判断に直結するという知見を得ました。この気づきのおかげで、旧環境のルール設定の設計も円滑に進めることができました。
設計が完成し、次にTerragruntを用いた設定ファイルの作成に取り掛かりました。
Terragruntとは、TerraformのコードをDRY（重複のない状態）に保ち、複数環境のインフラ管理を効率化するラッパーツールです。
作成した設定ファイルをPRで提出した際、メンターの方からコーディング規則について重要なフィードバックをいただきました。
私が最初に作成した設定ファイルの一部です：
aws = {
source = "hashicorp/aws"
version = "~> 6.64.0"
}一見すると普通の記述ですが、この ~>（ペシミスティック演算子）を用いた指定に課題があると指摘をいただきました。この演算子は指定したバージョン（6.64.0）のパッチアップデートを許容するため、自動的に最新版が適用されます。 しかし、実務の長期運用においては、意図しないパッチアップデートによって既存のインフラコードに影響が出るリスクもゼロではありません。そのため、無闇にアップデートを許容するのではなく、バージョンを 6.64.0 のように完全に固定して保守性と再現性を高める必要があると気がつきました。
ユーザーサイトの旧環境はWAFルールを刷新できましたが、スマホアプリの旧環境には最新のWAFルールが適用されていないという課題がありました。
そこで、スマホアプリのWAFルール刷新に向けて、アプリケーションチームへ連携依頼を行いました。
その際、今までの学びを総動員した連携を実践しました。
最も注力したのは「コミュニケーションコストを最小化する資料作成」です。Skillsやdraw.ioを活用し、視認性の高いレイアウトを構築しました。文章もPREP法を用いて、相手に必要な情報を過不足なく伝えるよう意識しました。 結果として、アプリケーションチームへ共有した際も不明点などの質問が出ず、非常にスムーズに連携を完了させることができました。
目標に対する結果と学び
最初に掲げた目標に対し、この2週間で得られた気づきを振り返ります。
- 自分のタスクがどのように事業価値に繋がっているかを考えながら開発する
- 上記を考えながら進めることで、SREの立場からどのようにユーザーへ価値提供できるかをイメージできるようになる
インターン全体を通して、「自分のタスクがユーザーに快適で信頼性の高いサービスを届けることに繋がっている」という目的意識を持ちながら開発を進めることができました。
また、
・サーバー負荷などの影響範囲を多角的に考慮した設計
・長期運用を前提とした設定ファイルのコーディング
これらを実践した結果、保守性を高めるという側面でチームでの事業開発に貢献することができると気づきました。
そして何より最大の学びは、「他者を意識した情報共有の重要性」です。
読み手の負担を軽減する構成やデザインは、結果的に自分の認知負荷をも緩和し、複雑で膨大な情報の中から適切な判断を下すための強力な武器になるという結論に至りました。
おわりに
2週間という短期間で、実務ならではの本質的な学びを数多く得ることができました。
今回のような複雑で膨大な情報から示唆を得て判断を行った経験は、自分がインフラエンジニアとしてキャリアを築いていく上で貴重な学びになったと感じています。
最後に、私が多くの気づきを得られるよう、意図を持ってタスクを任せてくださった社員・メンターの皆様に心から感謝いたします。ありがとうございました。
