※このストーリーは、noteで発信した記事を転載しています。

こんにちは！株式会社カンリー、エンジニア部の本間です。
私はインフラ・SREチームに所属しており、カンリーが提供する各プロダクトのインフラを構築/運用したり、SREとしてサービスの信頼性を向上させる活動を担当しています。

私は元々バックエンドエンジニアとして入社し、半年くらいはWEBアプリ開発をしていました。
入社するまでインフラは未経験の状態でした。

この記事では、バックエンドエンジニアがインフラ未経験の状態から今に至るまで、どのような方法でインフラの理解を深めていったのか紹介していきます！

この記事が

• バックエンドエンジニアからキャリアアップしたいと考えている
• 今後はインフラも習得したいが、何から学習すればいいかわからない
• インフラに触れる抵抗感があったり、とっつき辛さを感じている

と考えている方の参考になれば幸いです。

目次

1. この記事の要約
2. １．脳内にインデックスを作る
3. ２．バックエンド⇔インフラを繋ぐ技術から始める
4. RDS、ElastiCache（Redis/memcached）
5. S3
6. Github Actions（CI/CD）
7. ３．インフラの基礎の理解を深める
8. ４．以降、足りないと思った知識を足していく
9. バックエンドとインフラ両方知っていて良かったこと
10. さいごに

この記事の要約

先に結論として、何をして理解を深めたかを紹介します。その後、各部分の詳細を深掘りします。
まず結論がこちらです。

1. 脳内にインデックスを作る
2. バックエンド⇔インフラを繋ぐ技術から始める
3. インフラの基礎の理解を深める
4. 以降、足りないと思った知識を足していく

また、最後にバックエンドエンジニアからインフラエンジニアへのキャリアを進んで良かった点を紹介します。

それではここから詳細を深掘りします。

※注意点
・あくまで私の経験に基づくもので、個人の主観です。
・カンリーではAWSを利用しているため、記事内容もそれに沿ったものになっています。

１．脳内にインデックスを作る

インフラ未経験の状態で、まずは基本的な用語や、AWS等のサービス名とその目的を把握し、会話の意味がわかる/会話ができるようになるところから始めました。

私はこの部分を「インフラに絡む会議はとにかく耳だけでも参加して聞く」ことでインデックスを作りました。（カンリーでは、開発の会議はオープンになっており、他チームの会議でも好きに出入りできます👍）

最初は会話の流れについていけず、聞くだけでも1回の会議で脳がヘトヘトになるくらいでした笑

徐々に慣れてくるにつれて、
「〇〇のサービスは、△△な場面で役立つんだな」とか
「■■を使う時は××に注意しないとインシデントに繋がるな」とかがわかってくるようになりました。

また、緊急対応でインフラ側の調査や修正が入るときは担当者の作業に同席させてもらい、どんなコマンドを打ったか、どんな手順で調査していたか等をメモしたりもしました。
これをやっていたことで、脳内インデックスは勿論、私自身が実際に作業するときの心理的な負担が軽くなる効果もあったと思います。

他にも、もし可能であれば「インフラに強い業務委託の方のマネージメントをする」ことが有効だと思います！
進捗確認をしたり、業務委託の方が行った作業を展開する際に社内に説明する必要があるので、半ば強制的に理解することができるようになります。

これらは狙ってやったというより、"インフラ未経験なりに出来ることやった結果、こうなった"というが正しいかもしれません。

２．バックエンド⇔インフラを繋ぐ技術から始める

ここからは技術的な話です。
気になったサービスをまず使ってみるのも有りだと思いますが、インフラ未経験であればバックエンドのコードと深く関わる以下のサービスを最初に使うことをおすすめします。私もまずは既存環境で以下のサービスをメンテナンスすることからスタートしました。

• RDS、ElastiCache（Redis/memcached）
• S3
• Github Actions（CI/CD）

（あえてEC2やECSなどの仮想サーバーは除いています）

ここからは各サービスの簡単な説明と、バックエンド⇔インフラの繋ぎの観点について見ていきます。

RDS、ElastiCache（Redis/memcached）

RDSはAWSのマネージドリレーショナルデータベースのサービスで、ElastiCacheはAWSのインメモリキャッシングサービスです。

DB内に保存されているデータの活用方法は、バックエンドエンジニアがよく理解していると思います！それを強みにして、インフラ観点であるDBの置かれている場所（ネットワーク）や運用方法にも目を向けてみるといいと思います。

使っていくと以下のようなケースに遭遇すると思いますが、対応するたびインフラの理解が深まると思います。

• データ操作をミスったのでリストアしたい
• • → スナップショット？クローン？エンドポイント？
• パフォーマンスを出すために設定変更したい
• • → パラメータグループ？メンテナンスウィンドウ？
• ダウンタイムをなくしたい
• • → 冗長化？リードレプリカ？フェイルオーバー？Aurora？

ElastiCache（Redis/memcached）も同様です。
速度改善やDBへの負荷軽減の文脈で、キャッシュは必ずと言っていいほど選択肢にあがると思います。何をキャッシュしたらより高速に応答を返せるのか理解していることを強みにして、インフラ観点に目を向けてみるといいと思います。

また、DBもインメモリもローカルで動作させた後で、それをAWSに乗せる場合どういうサービス構成になるか？どんな設定が必要か？という意識で取り組んでみるといいのではないでしょうか！

S3

AWSのクラウドストレージサービスです。ファイルを置くだけで使えますので、インフラ未経験でも最初に試しやすいサービスだと思います。

お使いの言語のSDK（ソフトウェア開発キット）が提供されているなら、さらに簡単に使えると思います。

試しにまずやってみることとして、バックエンドからファイルをS3バケットに保存してみて、AWSコンソール上からどう見えるのか確認しましょう。
それができたら消してみたり、階層を深くしてみたり、他のAWSアカウントのS3に保存（クロスアカウントアクセス）してみたりすると、理解が深まると思います。

インフラ観点でさらに踏み込むなら、暗号化やライフサイクル、S3 Glacier等を調べてどういうケースで使うべきか考えてみるといいと思います。FTPクライアントソフトからS3バケットに接続してみるのもいいかもしれません。

また、S3はAWSの各サービスを使ってログを出そうと思った時にたびたび現れるので、今のうちに仲良くしておいた方がいいと思います！🤝

Github Actions（CI/CD）

AWSから離れますが、Githubが提供するCI/CDサービスです。

こちらを最初に取り組むのにおすすめな理由ですが、CI/CDで書きたいコードは基本的にバックエンドエンジニアが知っているからです！知っている部分が多ければ、初めてでも抵抗感が少ないと思います。

本番環境にデプロイする際は、お使いのフレームワークが用意しているマイグレーションコマンドや、システムを動かすのに必要なファイルをビルドしたり、テストが正常に通るかをチェックしないといけませんよね？
CI/CDでは上記を満たすコマンドと、デプロイ用のコードをyamlで書くだけです。

ローカルで試しづらいので（※）最初は取っ付き辛さを感じるかもしれませんが、まさにインフラへの繋ぎになる技術なので、ぜひ取り組んでみてください。
（※actというツールを使えば、ローカルで動かすことも可能です）

また、弊チームの井上が書いた記事でGithub Actionsで脆弱性診断をやってみる記事があります。
よければ試してみてください！

３．インフラの基礎の理解を深める

次にやったことは、基礎の理解を深めることでした。インフラ未経験の状態からサービスをまず触ってみて、ここで一度基礎に立ち返ります。

前章でいくつかサービスを紹介しましたが、実際は"このサービスだけ"を使っても機能しないことがほとんどです。
他に何が必要かというと、例えば仮想ネットワークであるVPCや、アクセス許可を管理するIAMやロールです。

こういった「前提としてこれがないと動かない」系が、上記の例だけでなく色々なところに潜んでいます。それを公式ドキュメント等を読んで理解することが、次の1歩になると思います。

（前章であえて紹介しませんでしたが、そもそもとして、書いたコードを動かすEC2やECSなどの仮想サーバーは必須ですよね）

また、クラウドインフラならではでいうと冗長化、コスト、監視やログについても学んでいきましょう。
特にコストの計算方法は把握しておいた方がいいでしょう。

４．以降、足りないと思った知識を足していく

ここまできたら、あとはご自身で興味のある領域や、足りないと思った知識等を深めていければ良いと思います！

個人的には実際にインフラの業務をやっていて、Docker、DNS、暗号化、セキュリティ、簡単なシェルスクリプト、Linuxの調査コマンドあたりは知っておいた方がいいと感じました。

バックエンドとインフラ両方知っていて良かったこと

最後にこちらを紹介して終わりたいと思います。メリットは、

• システム全体像を掴みやすい
• 障害時の原因切り分けが早くできる
• アプリ/インフラ両観点のウィークポイントがわかる（これは特に監視設定を入れるときに役立つ）

などです！
悪かったことはあまりないですが、強いて言うなら障害時に呼ばれやすいところでしょうか…笑

さいごに

以上、インフラ未経験からバックエンドエンジニアがジョブチェンジした話を紹介しました。
長くなりましたが読んでいただきありがとうございます。キャリアアップの一助になれば幸いです。

株式会社カンリーでは一緒に働く仲間を募集しています！
カンリーのバリューに共感できる方、ちょっと話を聞いてみたいという方、ぜひご応募ください！