バックエンドエンジニアがインフラ兼務ができるようになるには

はじめに

プロダクト開発部の マサ と申します！
普段はRuby on Railsでの開発を行いつつ、インフラ業務も少しですが担当しています。
今回はバックエンドエンジニアだけどインフラエンジニアの業務に興味がある方向けに、
どうしたらインフラ業務ができるようになるのかについて書いていきたいと思います。

インフラどのくらいできる人なの？

私の普段の業務はバックエンドの開発でRuby on RailsやGoでプログラミングをするのがメイン業務です。

インフラエンジニアとしての業務は週1日程度しか行っていませんが、
これまでに、Auroraのバージョンアップ(MySQL5.6から5.7)、Glueを用いた分析用データの抽出、
AWS Well-Architectedフレームワークの優先度が高い項目への対応などを行ってきました。

AWSのサービスでよく使われるサービス(VPC, S3, Route53, ECS, RDSなど)については、基本的な操作方法はできます。
マイベストではこれらのAWSサービスを使用して開発を行っているため、
日常的に行うインフラの業務について何とかこなすことができるかなと思っています。

インフラエンジニアに対するイメージ

私は今までに何社でバックエンドエンジニアとして業務を経験してきましたが、
どの企業でもインフラエンジニアまたはインフラを業務レベルで出来る人は、バックエンドエンジニアに比べたら少ないかなと感じています。
これにはインフラエンジニアに対する以下のようなイメージがあるからなのではと思っています。

• 仕事量が多い(残業が多そう)
• 難しそう
• 覚える事が多い
• 責任が重い(障害が起こった時など)
• 何から初めたらいいのかわからない

これらに関しては会社によるかと思いますが、決して当てはまることは無いかなという印象です。

仕事量が多い

インフラエンジニアは人数が少ないため、一人がこなす作業量が多くなりがちと思われているかもしれないですね。
インフラというのはシステムが安定して動けばいいので、これを達成してしまえば極論として後は何もしなくて良さそうです。

そしてインフラは1度作ってしまえば後は保守作業がメインになってくるので、実はそれほど作業は発生しません。

さらにクラウドでは機器の故障はすべてAWS側が担保してくれるので、私達が行うのはシステムを乗っける土台の用意だけです。
もちろんこれは最低限のやるべきことなので、開発チームの要望によっては、デプロイ機能の用意や検証環境の作成など、

様々な業務が発生してきますが、システムの安定稼働さえ出来ていれば緊急性は高くないものが多いため、毎日残業というほどのことが発生することは無いかと思います。

難しそう、覚えることが多い

これは確かにその通りです。ですがAWSでは簡単な操作でサーバが起動できるので敷居は以前よりは低くなっています。

まずは、簡単な事から覚えていき、徐々に色々なサービスに触れていき、その都度わからないことを調べて学習していくと、
いつの間にか結構できるようになっています。

私自身もAWSサービスをほとんど理解できていませんが、都度必要なことをインプットして、試しています。

サーバーサイドの開発でも同じで、わからないことは都度発生するものなので、必要に応じて解決していける能力を磨く方が大事かと思います。

責任が重い

これは想像よりもそんなに責任が重いことはないかと思っています。

障害が発生するケースで多いのはプログラミングのバグが多いので、インフラが起因しているケースはそんなに多く無いかと思います。

さらに障害が発生した場合では、皆で協力して対応するというのが普通なので、一人が責任を負う状況は起こりません。

また誰か一人に責任を問うより、どうしたら次に発生しないのかを検討して改善することの方が重要だと思います。

バックエンドエンジニアはインフラ知識はいらない？

インフラエンジニアがいる企業では、バックエンドエンジニアがインフラのことについて関わる機会はあまり多くないかと思います。

バックエンドエンジニアはより自分の責務であるプラグラミングや設計に注力できるようになっています。

バックエンドエンジニアにはインフラ知識はなくても支障がないのではという事を思うかもしれないですね。

インフラ知識はバックエンド開発の役に立つ！

今はDockerで開発を行うのが、よく行われているかと思います。

自分のPCに開発環境を用意するのに Dockerの知識があると、何かエラーが起こった際にすぐ対応できるようになります。
最近はECSのように、Dockerコンテナを起動できるサービスがあるので、
より開発環境と本番環境を近づけることができるようになったかと思います。

開発と本番の環境が近いということは、本番で起こったことが開発環境で再現できる可能性が高いことになります。
よって開発環境を詳しく知ることで、原因調査や再現性確認がよりスムーズにできることかと思います。

普段どうやってインフラ知識を勉強しているのか

主な情報収集先としては以下になります。

• ブログや記事、AWSのドキュメント
• AWSのドキュメント
• YouTube(AWS公式チャンネル: https://www.youtube.com/channel/UCnjKWUK2t5QJYfeqqilhJhQ)
• 技術書
• AWSの開催するセミナー・イベント

普段はブログや記事から情報収集することが多いです。
AWSは情報が多すぎて、本に載ってないことも数多くあります。
なので、基本的なことは本から取得して、補完的に記事から情報を取得するのがよさそうかなと感じています。

あとはAWSが定期的にイベントをやっているので、それに参加することや、
YouTubeに上がっているAWSの動画なんかも参考になることが多いので、学びの場所は多いのかなと思います。

AWSの場合は文字だけの情報だと、なかなか覚えるのが大変なので、
AWSのコンソールに入って、自分で操作してみるとより知識が定着すると思います。

インフラを業務としてできるようにするには

ECSでアプリを動かすレベルまでは、今は本や動画が充実しているので、独学で覚えられるかと思います。
あとはできればTerraformで組めるようなところまでくれば、業務で何とかなるレベルじゃないかと思います。

業務だと本やネットの情報には無い作業などを行う場合がありますが、
ECSまで動かせるぐらいのAWSの知識があれば、あとは実際にAWS上でネットで断片情報を集めて試してみることで、何とかなることが多いので、覚えることは多いかもしれませんが、少しづつやっていけばできないことではないので、がんばりましょう！

私のおすすめのAWSサービスの覚える順は以下になりますので参考にしてみてください！

1. IAM
2. VPC
3. EC2
4. Route53
5. S3
6. RDS
7. ECR
8. ECS

興味がある箇所からやるのが一番なので、順番は前後しても大丈夫です！
ECRをやる前にDockerの勉強をしておいた方がスムーズに理解が進むかと思います！

マイベストのインフラ業務について

現在インフラで行っている業務は以下のものがあり、これらを普段担当しています。

• 不具合が起こった際の調査対応
• インフラ以外を担当しているメンバーからインフラに関連する質問への回答
• ドキュメントの整備
• デプロイ速度やコスト面の改善
• ミドルウェアやSaaS(DataDogなど)の選定・仕様調査
• AWSのシステムバージョンアップへの対応

全部説明すると長くなりそうなので、わかりづらい箇所をピックアップして説明します。

不具合が起こった際の調査対応

そこまで発生件数は多くありませんが、開発環境やステージング環境での不具合でインフラに起因するものの原因調査を行うことです。

例えば、ステージング環境にデプロイができなくなってしまった、開発環境が起動しなくなってしまったなどです。

原因がアプリケーションに起因している場合もあるので、まずは原因となっているログを追いかけるところから初めて、インフラで変更が必要な箇所があればAWSコンソールやTerraformを使って修正していく形になります。

ドキュメントの整備

ドキュメントはインフラの構成が変わった時に変更するのではなく、色々と準備しないと行けない情報が多いかと思います。例えば以下のようなものがあります。

• 何か操作する際の手順(サーバへログインする方法など)
• インフラ構成・設計図

AWSでは新機能の導入やバージョンアップで新たな項目が追加されたり、無くなったりするので、
それに応じてドキュメントも更新していく必要があります。

デプロイ速度やコスト面の改善

日々開発を行っていくと、テストの数やDBのデータ量が変化していくので、
それによって、デプロイの速度が遅くなってしまう場合があります。
デプロイ速度は開発速度の低下につながるので、どうしたらもっとデプロイ速度を上げられるのか工夫をしていく必要があります。

またアクセス量が増えていくと、インフラのスペックを上げたりして対応していきますが、当然コストも増えていきます。
AWSのサービスでコストを下げれそうなものを検討したり、他のSaaSなどを使うとコストを下げられる可能性があるので、定期的にコスト改善を行うメリットは大きいかと思います。

AWSのシステムバージョンアップへの対応

RDSやFargateなどは定期的にバージョンアップがあり、古くなったバージョンはサポートが終わってしまいます。
このためサポートが切れる前にバージョンアップを行う必要があります。

バージョンアップを行うと、サービスにどう影響が出るのかの調査、どうやって行うかの手順を検討するのが主な作業になってきます。

インフラ構成

下図がマイベストのAWSで構成しているインフラ構成になります。

これ以外にもデプロイシステムやDatadogなどのSassを利用していますが図からは除外しています。
ECSを使った一般的なRailsアプリの構成になっているかと思います。
インフラは一部を除き、Terraformでコード化しているのでメンテンナンスがしやすい状況にはなっています。

現状ではこの構成で負荷に応じて、ECSやRDSのスケールアップ・スケールアウトを行い対応を行うことで負荷状況に応じたインフラを構成することができています。

現在の課題

「システムの成長に合わせて最適なインフラ構成をアップグレードする」が課題になってくるかと思います。
現在弊社の規模のアプリでは現状のインフラ構成で何とかなっていますが、
もっと規模が大きくなり、どんどん機能が実装しなければならない状況になった場合に、
どういうインフラ構成にしていくのがベストなのかを考えていかなればなりません。

インフラを担当しているメンバーが社員が私一人と業務委託の方が一人の計二人なので、
この人数では、今後の開発に影響が出る可能性があります。

システムの成長に合わせて、インフラチームも成長していく必要があるので、
将来のインフラチームはどういう人数で、どういうスキルを持った人が居たらいいのかなど、
判断が難しいことを考えていく必要があるかなと思っています。

今後何をやっていきたいか

開発のエンジニアも増えているので、より快適に早く開発をしていける環境を整えていきたいと思っています。
そのためにはインフラになにが必要なのかを考える必要があり、そこが面白いポイントになってきます。

まだやったこと無いことに挑戦になるので、環境をしっかり整備できれば、
目に見えて変わってくることもありそうです。
それを体験できるのはインフラエンジニアとしてのやりがいに繋がってきそうです。

さいごに

インフラエンジニアは一般的に大変そう・難しそうなイメージがあり、なりたい人はそんなに多くないのかもしれません。
しかし最近ではDocker、AWSなど技術が進歩して、より必要な知識が少なく、
また情報もネットを探せば見つかることが多いので、インフラエンジニアになりたい人にとっては敷居が下がっていんじゃなかと思います。

またバックエンドエンジニアがインフラを見るのは多くなって来ていて、そのメリットも大きいので、
興味がある方はぜひ目指していってインフラが出来る人が増えればいいなと思っています。