🍣

社内SEからインフラエンジニアへの転身と学び

に公開
テーマ「2025年の最も大きなチャレンジ」
AWS
SRE
idea

はじめに 👋

インフラエンジニアに転身してちょうど1年が経とうとしている元社内SEです。

前職は社内システムという限定された環境でしたが、転職後は不特定多数のユーザーを抱えるシステムの視点——セキュリティ、パフォーマンス、可用性（システムの信頼性）——がより高い水準で求められる環境に身を置くようになりました。

監視・運用も含めたシステムの信頼性を保つ役割、いわゆるSRE（Site Reliability Engineering）的な業務を担当する中で、私が学んだことをまとめてみました。

前職の環境 💼

まずは正直に前職での私のスキルセットと環境を振り返ります🙈

  • 主な開発言語: Java、VBA、SQL
  • ネットワーク: 社内に閉じた環境での構築がほとんど
  • セキュリティ意識: ほぼゼロ
  • パフォーマンス意識: ほぼゼロ
  • AWS: AWS実技試験などで独学
  • バージョン管理: SVNを使用（基本的に一人開発）

転職後の環境 🌍

その後、AWSインフラエンジニアとして転職しました。

現在は、既存AWSシステムのリプレイスを担当しており、要件定義から構築、維持保守までインフラのライフサイクル全体に関わっています。

課題1: セキュリティとパフォーマンスという世界 🔐

転職して最初に気づいたのは、自分に足りていなかった視点の多さでした。

  • セキュリティ: 社内システムでは「社内の人間しか基本アクセスしない」という前提でしたが、公開システムでは悪意のあるアクセスを前提とした設計が必要でした
  • パフォーマンス: 限られたユーザーが使う前提から、「何千人が同時にアクセスしても安定して動く」ことを考える必要がありました

特に反省したのは、インフラのメトリクスとアプリケーションコードの関連性を全く理解していなかったことです。

例えば、CPUアラートが鳴った時。

【前職の自分】
CPUが高い → 「サーバーのスペックが低いのかな」で終わり

【今の自分】
CPUアラート発生
  ↓
他のメトリクスを確認（メモリ、ディスクI/O、ネットワーク…etc）
  ↓
データベースのスロークエリを調査
  ↓
アプリコードを確認
  ↓
ボトルネックを特定して改善

監視ツールで見える数値と、実際のコードがどう繋がっているのか、その関連性について少しずつ理解を深めていきました。

「この視点を早く持てていれば、過去にもっと良いコードを書けたかもしれない…🥲」と反省するとともに、負荷を前提に考える視点を持つことで、同じ要件でも設計やコードの書き方が変わってくることに気づきました。

課題2: インフラとアプリの関係性の理解 🔗

前職の環境ではWebサーバーの詳細な設定や、インフラ設計に触れる機会がほとんどありませんでした。

実際にシステムを構築・運用していく中で、Webサーバーの設定やインフラ設計には、アプリケーションの処理内容の理解が不可欠であることを、さまざまな場面で実感しました。

ここでは、具体的な例をいくつか紹介します。

2-1. タイムアウト設定とアプリの処理内容

ある時、アプリケーションのエラーレスポンスが返ってくる問題に直面しました。調査していくと、複数のレイヤーにまたがる要因が絡んでいることがわかりました。

[ユーザー]
    ↓
[ALB] ← タイムアウト設定
    ↓
[Webサーバー] ← タイムアウト設定、接続数制限
    ↓
[アプリケーション] ← 処理時間、メモリ使用量
    ↓
[データベース] ← クエリの効率、コネクション数

Webサーバーのタイムアウト設定を調整するだけでは解決できません。 「アプリがどんな処理をしているのか？」「どれくらい時間がかかるのか？」 をアプリチームに相談したり、コードを読んで確認したりする必要がありました。

それぞれのレイヤーが独立しているのではなく、すべてが繋がって一つのシステムを構成していることを、身をもって理解しました。

2-2. 冗長化とアプリの処理方式

アプリケーション層の理解が必要になるもう一つの場面が、冗長化です。

サービスを停止させたくない要件があるシステムについては、サーバーが1台だけだと障害時にサービスが止まってしまう可能性があります。

ただ、ここで「じゃあサーバーを増やせばいいんだな」と単純に考えていたら落とし穴にはまります🕳️

セッション管理の問題

例えば、セッションをファイルに保存していると、複数のWebサーバー間でセッション情報が共有できません。ユーザーがログインしても、次のリクエストで別のサーバーに振り分けられたらログイン状態が失われてしまいます。そのため、Redisなどの外部ストアに保存する必要があります。

バッチ処理の排他制御

また、バッチ処理が動いている場合、複数サーバーで同じバッチが同時実行されないように排他制御が必要です。

このように、アプリの処理方式を理解していないと、インフラ設計の判断ができないことを学びました。

課題3: IaC（Infrastructure as Code）の世界 ⚙️

「インフラエンジニアになるとコーディングする機会が減るのかな…」と思っていましたが、実際には毎日コードを書く日々でした。

転職先は、Webサーバーからインフラ、監視設定まですべてをコードで管理している会社でした。

なぜIaCが必要なのか❓

システムの信頼性を保つには、手作業による設定ミスを防ぎ、「いつ・誰が・何を変えたか」を明確にする必要があります。

インフラをコード化すれば、GitHubでのレビュー体制が整い、万が一問題が起きても即座に前のバージョンに切り戻す（ロールバック）ことが可能です。つまり、「変更管理の徹底」がシステムの安定性に繋がります。

具体的には以下のツールを使い分けています。

  • AWS CDK: AWSのインフラ構成をTypeScriptでコード化
  • Terraform: マルチクラウド管理やSaaS（New Relic等）の監視設定
  • 構成管理ツール（Ansibleなど）: サーバー設定の自動化

私にとってIaCの1番の魅力は 「環境構築のスピード感」 です。

コード化には労力がかかりますが、一度書き上げたコードは、新しい案件でも流用可能な資産となります。これをベースにすることで、ゼロから手動で構築する作業と比べて効率良くインフラを構築できます。

苦労して書いたコードが次の仕事でも流用でき、あっという間に環境が立ち上がる様子を見るのは、本当に気持ちが良いものです🥰

課題4: GitHub ・ CI/CDという文化 🚀

前職ではSVNでの単独開発が主でしたが、現職ではGitによるチーム開発が基本です。最初の頃はコンフリクトや破壊への恐怖が強く、上司に「いきます！」と宣言して見守ってもらいながらコードをpushしていました💦

徐々に慣れていく中で、GitHub Actionsを使ったCI/CDにも触れることができました。

なぜCI/CDが必要なのか❓

システムの信頼性を担保するためには、アプリケーションコードだけでなく、リリースプロセス自体の信頼性も必要です。手動デプロイに伴う「設定漏れ」や「テスト忘れ」といったリスクは、システムの安定性を脅かします。

CI/CDを導入し、テストからデプロイまでを自動化することで、「誰がやっても同じ品質で、安全にリリースできる状態」 を作ることができます。

「コードを書いて終わり」ではなく、「コードが自動でテスト→デプロイされる仕組み」までを設計する。
これもまた、信頼性を守るエンジニアの大切な役割だと学びました。

この1年で得た最大の学び 💭

セキュリティ、パフォーマンス、可用性、監視、IaC、CI/CD——これらすべてを経験する中で、この1年で最も大きく変わったのが自分の視点でした。

【前職の自分】

  • 「仕様通りに動けばOK」で完結

【今の自分（まだまだ勉強中）】

  • Webサーバー・アプリ・データベース、すべてのレイヤーの関連を見て、調査・改善する
  • 監視：メトリクスとアプリコードを紐付けて考える
  • 可用性：アプリの処理方式を理解してインフラを設計する
  • 自動化：IaCとCI/CDでコードとインフラを一体管理

「システムの信頼性を保つには、インフラとアプリを一体で考えることが不可欠」 という当たり前のことを、ようやく理解できたように思います。

おわりに 🙏

正直、この1年は本当に大変でした。

学ばなければいけないことが次から次へと出てきて、パンクしそうな時期もありましたが周りの方々に助けてもらいながら、なんとか少しずつ前に進むことができました。

今まで知らなかったこと、できていなかったことばかりですが、引き続き日々学びながら成長していきたいと思います。

ここまで読んでいただき、ありがとうございました！

Discussion